AI 时代测试策略:4 步把火力打在刀刃上

凌晨一点多，我又在翻那份季度缺陷复盘。

线上一共漏了 11 个缺陷，其中 3 个是高危。团队这季度跑了将近两万条用例，自动化覆盖率拉到 89%，看数字漂亮得很。可那 3 个高危，没有一个是被这两万条里的哪一条逮住的——全是用户在生产环境帮我们"测"出来的。

我盯着那张表看了很久。问题不在测得不够多。是测错了地方。

这两年我跟同行聊测试策略，听到最多的一句话是："现在有 AI 了，用例随便生成，我们准备把覆盖率往 95% 冲。"每次听到，我都想拦一句。 AI 确实让写测试这件事变便宜了——便宜到你会忘记，测试策略要解决的从来不是"测多少"，而是"先打哪、什么时候停"。

弹药管够，不等于你会打仗。

一、"测全"是个永远到不了的终点

先把一句老话摆出来：只要你没能覆盖软件所有可能的情况，软件就是有风险的。

这话听着像废话，但它其实在说一件挺残酷的事——你永远覆盖不全。一个有 10 个布尔参数的函数，输入组合就是 1024 种；再叠上状态、时序、并发，组合数直接爆炸。把全世界的测试工程师都拉来，跑到地球毁灭也跑不完。

所以测试从第一天起，干的就不是"消灭风险"的活，是"管理风险"的活。

打个仗的比方。没有哪支军队的目标是占领地球上每一寸土地——那既不可能，也没必要。将军要做的，是判断敌人主力在哪、命门在哪，然后把炮火集中过去。测试也一样。你不是要测到每个角落都亮绿灯，你是要确保最该守住的那几个阵地没失守。

AI 来了之后，这件事被搅浑了。

到 2024 年，已经有 72.3% 的测试团队在探索或落地 AI 测试工作流。蚂蚁、天猫、得物都公开过他们用 prompt+RAG 搭的用例生成智能体，简单需求下，用例编写时间能省掉将近 40%。生成成本一降，很多人的第一反应是：那我多生成点，把覆盖率冲上去不就行了？

这就是 AI 给的最大幻觉——它让"测全"这个不可能的目标，看起来好像突然变可能了。

弹药白菜价，于是开始无差别洗地。可你有没有想过：满地的绿灯，到底守住了哪个阵地？

二、漏到用户手里，才是最贵的那一炮

为什么我们这么怕"漏"？因为漏出去的代价，是阶梯式往上翻的。

Boehm 那条经典的成本曲线，现在看依然不过时：以需求阶段发现并修复一个缺陷的成本为基数，到编码阶段是 5 ～ 10 倍，到系统测试阶段是 10 倍，等它溜进生产环境被用户撞上——10 到 100 倍。

100 倍是什么概念。需求评审时多问一句话能解决的事，等用户投诉、舆情发酵、紧急回滚、跨三个部门拉群复盘走一遍，成本就是这么滚上去的。早期那一下，只有开发自己在电脑上改两行；晚期那一下，是一整条协作链在为它买单。

所以测试策略的第一性目标，不是"少漏 bug"，是"别让最贵的那一炮漏出去"。这两句话不一样。前者求量，后者求准。

我见过一个团队，季度测试报告写得花团锦簇，执行了一万八千条用例，通过率 99.2%。结果支付链路一个边界条件没覆盖，上线当天对账差了几千块。一万八千条用例的"勤奋"，抵不过一个高风险点的"疏忽"。

判断哪一炮最贵，就是测试策略真正的手艺。

三、先侦察，再开火：风险评估决定火力往哪倾

既然测不全，又必须守住命门，那顺序就只有一个：先侦察，再开火。

落到测试上，"侦察"就是上手测之前先做风险评估——哪个模块改动最频繁、哪条链路一旦出错损失最大、哪部分代码历史上 bug 最密集。把这些标出来，火力就往这倾斜。低风险的边角，抽测、冒烟，甚至放过，都行。

这恰恰是 AI 现在帮得上忙的地方，而且帮的不是生成用例，是侦察。

机器学习能拿历史缺陷数据训练，预测出代码库里哪些区域最可能出问题，让你把有限的测试资源优先压上去。还有测试影响分析（ TIA ）——代码一改，它只挑出受这次变更影响的那批关键用例来跑，而不是每次都把全量回归从头到尾犁一遍。这才是 AI 该干的活：不是让你测得更多，是让你测得更准。

但这里有个反转，必须说。

AI 在帮你侦察的同时，自己也开辟了一片新的不可测区域。当你测的对象是大模型应用，它的输出本身就是概率性的、带幻觉的——同一个输入，今天答对，明天可能一本正经地胡说。有数据说，超过 68% 的企业在 AI 落地中遭遇过幻觉问题，其中 32% 的案例因为错误一点点累积，最后演变成系统性风险。

传统软件你还能指望"同样输入得到同样输出"，到了 AI 应用这儿，这条地基都松了。

所以风险评估的版图变大了。你不光要评估业务模块的风险，还得评估"AI 本身会不会抽风"的风险。有句话我很认同：与其追求零幻觉，不如学会管理不确定性。测试策略在 AI 时代的核心，从"消灭意外"变成了"把意外摁在可控范围里"。

四、子弹便宜了，但你得知道什么时候停

最后一个，也是最反直觉的一个：知道什么时候收手。

测试有个绕不开的经济学问题——测试量越大，发现的剩余缺陷越少，但每多挖出一个 bug 的成本越来越高。理论上的最佳测试量，就是"再投钱进去的收益"和"剩下没抓到的缺陷的风险"打平的那个点。过了这个点还在猛测，是浪费；没到这个点就收手，是冒险。

AI 把这道题彻底搅了一下。

它大幅压低了"生成和执行用例"的成本——子弹便宜了，理论上你能往后多测一阵。但它没有降低、甚至还抬高了另一项成本：判断"这些测试到底测对没有"的成本。 AI 一口气生成两千条用例容易，可这两千条断言写得对不对、有没有把代码当前的错误输出直接抄成期望值，得有人一条条审。

于是终止测试的标准，得换一换了。

过去你可能看"用例跑了多少、覆盖率到没到 90%"。现在我更看一个问题：那几个最高风险的阵地，是不是都用可信的断言守住了？守住了，剩下的边角哪怕覆盖率只有 60%，也可以停。没守住，覆盖率 95% 也别上线——那 95% 可能全堆在没人会出错的地方。

停手的依据，从"测了多少"变成"该守的有没有守住"。这是 AI 时代我觉得最该改的一条认知。

写在最后

回到开头那 3 个高危缺陷。

后来我复盘，根子不在工具，不在人手，在策略——我们那季度根本没做正经的风险评估，用例是照着功能清单一条条堆的，堆得很满，却没人问一句"哪块最容易出大事"。两万条用例，火力撒得到处都是，唯独没压在该压的地方。

AI 给了我们前所未有的弹药量。但弹药越多，越考验一件事：你到底知不知道该打哪。

留一份清单，下次定测试策略时可以照着走一遍：

最后留个问题给你。

你团队上一次定测试策略，是先做了风险评估，还是先排了"这季度要写多少条用例"？

评论区聊聊，我挺好奇大家是怎么决定"打哪"的。