关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集
上周，一个做测试的哥们儿半夜找我喝酒。三杯下去才开口：他被离职了。老板看了一场 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 换掉测试”这句话。
故事讲完了，留一个问题给现在正在读这篇文章的你——不管你是一线测试、开发，还是正在裁人的那个角色：
你现在的团队，离得开“人的测试判断力”吗？
