关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集上周一个做测试的哥们儿半夜找我喝酒。三杯下去才开口他被离职了。老板看了一场 AI 测试工具的 demo觉得以后点点点就能出用例、自动跑、自动出报告留两个“会操作 AI 的”就够了。整个测试团队 20 个人一个月内裁得只剩 2 个应届生。他没多说但我听出来了那个老板不是个例。最近半年类似的事我直接、间接听了不下十起。有的公司还在犹豫有的已经动手。很多人已经开始感觉到这波 AI 替代测试的声势跟以往任何一次“自动化取代手工”都不一样。可诡异的是真正大规模裁掉测试团队的公司线上质量数据不但没变好反而崩得一塌糊涂。这就回到了这篇文章真正想拆开来看的东西当我们在说“用 AI 做测试”时我们到底在说什么。目录裁掉的是人丢掉的是判断力测试的本质不是“点”是“决策”AI 能生成 1000 条用例但分不清哪 3 条才是关键两个血淋淋的对比把边界看清工程落地把 AI 当外骨骼别当替身最后一个值得追问的问题裁掉的是人丢掉的是判断力这件事的吊诡之处在于很多老板是被“全自动化测试”这个概念击中的。他们看到的 demo 通常是这样的给一个页面AI 自动识别元素自动生成脚本自动跑自动截屏对比。整个流程看着像魔法。但他们没看到的是demo 选的永远是“登录页面”“搜索框”这类确定性极高、变体极少的场景。一旦落到真实业务系统变量是指数级上涨的。一个真实的电商后台光一个订单状态的流转就有 17 种正常路径、40 多种异常分支其中至少 1/3 根本没有被任何文档记录只存在于老测试的脑子里。AI 拿到的需求文档、UI 截图里根本不会出现“支付回调超时后如果用户恰好点了取消再立刻重新支付”这种场景。这就是第一个要命的问题AI 只能基于已表达出来的信息工作而测试最值钱的那部分恰恰是对未表达、未穷举、模糊地带的判断。一个测试老人被裁掉带走的不只是“会写用例”这层技能而是整个系统数年内积累的风险直觉。这种直觉没法通过 API 传递。测试的本质不是“点”是“决策”很多人以为测试就是“执行用例”“点页面”“写脚本”。这是对测试最大的误解。测试活动的本质工程上讲是持续获取质量信息并做出风险决策的过程。每一轮测试你其实在做三个动作选择“测哪里、测多深”判断“看到的结果是不是问题”决定“以当前信息量敢不敢发布”AI 目前勉强能参与第 2 个动作里的极小一部分——比如做图像对比、断言返回值。但也仅限于已知的、可预先定义的“对”与“错”。而真实世界里大量缺陷是不是缺陷是需要结合业务上下文判断的。一个按钮颜色偏了两个色值在后台系统可以忽略在 C 端活动页就是事故。AI 没有这个上下文。第 1 和第 3 个动作完全是决策密集型活动依赖对架构风险、业务影响、用户行为的综合判断。这恰恰是当前基于统计概率的大模型最不擅长的。本质变化是AI 把测试的执行成本打下来了但测试的决策成本不但没降反而因为引入 AI 的不确定性涨了。用一个不好听但准确的说法AI 让“跑错方向”这件事变得极其高效。AI 能生成 1000 条用例但分不清哪 3 条才是关键技术上拆一下当前 AI 测试工具的核心机制。市面上主流方案底层通常是大语言模型加上传统自动化框架的封装。流程大致是输入需求文档、页面结构或接口定义让模型通过 prompt 生成测试用例或自动化脚本执行层对接 Selenium、Appium、Requests 等结果做断言比对或截图差异分析这个链路最脆弱的一环是用例生成的质量评估和筛选目前几乎全靠人。 模型输出的本质是基于语料概率的序列预测它不知道哪些路径在真实业务里意味着“高风险”。举个例子让 AI 测一个带优惠券的订单提交。它大概率会生成一堆参数组合测试券过期、券已用、券面额为零、不选券等等。这些有用吗有一点。但真正能造成线上故障的往往是“多张券叠加时的优先级计算与最后一步优惠分摊的金额精度”这种需要跨越多个微服务才能推出来的逻辑从来不会被单独写在 PRD 里。结果就是你得到了一千条“看起来很全”的用例但真正能发现致命缺陷的那三条一条都没有。更糟糕的是这一千条用例会持续消耗你大量的执行时间和结果分析精力把团队拖死在低价值的“绿色报告”里。AI 擅长在已知的轨道上加速但测试的使命是探索未知的悬崖。两个血淋淋的对比把边界看清案例一秒杀的“超卖”AI 完全沉默一家中型电商用 AI 测试平台替代了大部分手工测试。大促前跑完了一整套自动化回归全部 pass。上线当晚秒杀开始后第 12 分钟超卖 300 单。复盘发现AI 生成的用例全是单用户顺序操作。而真正触达缺陷的路径是库存扣减的 Redis 操作和数据库写操作之间存在一个 80ms 的窗口在高并发下两个请求同时读到旧库存同时扣减成功。这种多线程时序竞争问题AI 既不会设计并发测试模型也无法理解执行结果中偶发的不一致属于致命缺陷。测试的缺失环节不是“没跑”而是“根本没人意识到该这样测”。案例二需求文档里没写“不应该出现”的事一个管理后台的改版需求只说“优化了页面布局功能不变”。AI 生成的用例全集中在原来的功能点增删改查分页搜索。跑完一切正常。上线后运营发现批量操作按钮下多出了一块空白区域点进去是 404 页面——前端模板残留了一个旧的路由入口。这个缺陷AI 既不会在用例生成阶段“无中生有”地探测也不会在结果分析阶段识别“多了一块空白”背后的风险。而一个有经验的测试页面打开 30 秒就会说“这儿不对。”这两个例子说明的其实是同一件事测试工具不会为质量负责只有人会。工程落地把 AI 当外骨骼别当替身不是说 AI 没用。恰恰相反用对了地方AI 能让一个测试团队的生产力翻倍。关键在于你得搞清楚人和机器的能力分界线。一个合理的工程化分工是这样的这个闭环的核心思路就一条让 AI 干“算力密集”的让人干“判断密集”的。具体来说AI 适合这四类活大批量回归执行与兼容性覆盖接口层面的参数扰动和边界值组合日志异常检测与错误模式聚类测试数据生成尤其是要符合复杂约束的而人必须死守的是测试策略本轮测什么、不测什么、为什么测试模型如何抽象业务让 AI 可理解探索性测试基于直觉和经验的随机游走结果判断哪些异常是真实的 bug哪些是环境噪声没有反馈闭环的 AI 测试就是一场精准的赌博。你每次让 AI 跑完直接出报告而不做人工审计就等于在赌“这次模型没犯傻”。短期可能赌赢长期一定输。对于测试团队来说这不是一个“要被替代”的危机而是一个“重新定义自身价值”的窗口。那些只会按用例执行的执行者确实会被替代。但能设计测试策略、建模业务、做风险决策的人只会更贵。最后一个值得追问的问题回到开篇那个哥们儿。他后来回去了条件是老板必须接受一套新规则团队缩编但保留核心设计岗引入 AI 做执行端建立人工审核的反馈机制。半年后他们的自动化覆盖率到了 85%线上缺陷反而降了 40%。老板没再提“用 AI 换掉测试”这句话。故事讲完了留一个问题给现在正在读这篇文章的你——不管你是一线测试、开发还是正在裁人的那个角色你现在的团队离得开“人的测试判断力”吗关于我们霍格沃兹测试开发学社隶属于 测吧北京科技有限公司是一个面向软件测试爱好者的技术交流社区。学社围绕现代软件测试工程体系展开内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试以及人工智能测试与 AI 在测试工程中的应用实践。我们关注测试工程能力的系统化建设包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法沉淀可复用、可落地的测试开发工程经验。在技术社区与工程实践之外学社还参与测试工程人才培养体系建设面向高校提供测试实训平台与实践支持组织开展 “火焰杯” 软件测试相关技术赛事并探索以能力为导向的人才培养模式包括高校学员先学习、就业后付款的实践路径。同时学社结合真实行业需求为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务用于个性化能力提升与工程实践指导。