AI 写的测试，能替你签字吗

一个版本上线前，测试全部通过。第二天早上，客户打来电话，说昨天的订单金额算错了。

负责的人回头翻记录：测试确实跑过，也确实全绿。写那些测试的，是半年前接进来的 AI 助手。

再往下翻，才发现更麻烦的一层：测试里验的那个数，和代码算出来那个数，错在同一处。

这一篇回答四个问题：绿灯到底证明了什么，AI 写测试容易漏在哪里，省下的时间和没省下的时间各是哪一块，上线前那张签字单该由谁看什么。

一、先把这个下午讲完

出错的是活动订单。规则写着「实付满两百减二十」，代码却按商品金额判断，测试也按商品金额写。

三个环节用的是一份理解，所以测试一路全绿，客户实付的时候却少减了钱。

如果只是代码写错，测试本该拦住它。拦住不了，是因为测试和代码犯的是同一个错。

二、测试通过，证明的是程序照着一句话跑

一条测试做的事很朴素：给一个输入，比一个输出。

它证明的只有一件事，程序在这一点上，按写下来的预期跑了。

预期本身写得对不对，它管不着。需求理解错了，测试会跟着错，然后稳稳地通过。

所以绿灯的意思是「和写下的那句一致」，不是「和业务一致」。这两句话差得很远。

三、人写测试先想业务，AI 先拿到代码

工程师写测试，通常从业务出发：这笔单子该收多少钱，这个客户能不能退。

AI 写测试，手里最先有的是代码。它读实现，看函数怎么算，再照着写断言。

断言就是测试里写死的那个期望值，跑的时候拿实际结果和它比。

这样写出来的测试，和实现天然一致：实现对了测试就绿，实现错了测试也绿。

一致本身不坏，坏在它把「独立核对」换成了「自己证明自己」。

四、同一处错写两遍，最难查出来

举个金额上的例子。合同约定半分钱按四舍五入进上去，代码里按舍掉那半分写。

AI 读这段代码，照着写测试，也按舍掉那半分验。两种写法对得整整齐齐。

上线之后很久，测试一直全绿。到月底对账，也就是把系统记的每一笔和银行流水、客户账单逐笔比一遍，才发现上千笔单子每笔差几毛。

钱不多，麻烦在于已经分不清：是代码写错了，还是测试被改宽了。

这时候要回头查的，不只是那几行代码，还有测试是什么时候跟着变的、谁同意的。

五、覆盖率好看，只能说明代码被跑过

覆盖率是跑测试时被执行到的代码行，占全部代码行的比例。

这个数字量的是哪些行被跑过，不衡量跑出来的结果对不对。

一行代码被跑到，可能只是执行了，没人检查它算出来是多少。

所以覆盖率很高、测试上千条，都可能和「账算得对不对」没有关系。

数字好看的时候，评审的人最容易松手：都这么高了，应该没问题吧。问题常出在没人细看的那几条上，比如退款、手工改价、跨月的订单。

六、测试被悄悄改宽，比代码出错更难查

需求变了，测试跟着改，这是正常的。不正常的是改了没人知道，也没人说为什么。

等出了问题去翻记录，只看到一行：测试已更新。

到这一步，谁也说不清是代码写错了，还是测试被放宽了。

改测试的动作，应当和改代码一样，留下谁改的、为什么改、原来挡住的是什么。

金额、权限、扣款这三类测试，改的时候最好再要一个人看一遍。多花一点时间，出事时省掉的是几个星期的互相猜。

七、给 AI 一份从外面来的答案

只给代码，AI 只能照着代码写，等于让它自己出题自己判卷。

给它一份外面来的答案，情况就不一样：一笔核对过的订单，一张对过账的报表，一份客户签过字的清单。

有了外面的答案，测试才有真正的对照，而不是自己跟自己比。

这份答案从哪儿找：从过去几个月的真实单子里挑，出过问题的那几笔优先。

挑的时候别只挑顺利的，退过款、改过价、断过网的，正是最该拿来对的那一批。

八、专门挑出错的时候验

顺利的路径谁都能跑通，也最容易被写进测试。

真正决定出事时慌不慌的，是另外几类情况。

网络断了重试，会不会扣两次钱；同一个请求提交两次，订单会不会多出一笔；金额是零或者负数的单子，能不能一路走到付款；退款能不能退两次。

这几类有没有测试，决定了问题出现时，是系统先报警，还是客户先打电话。

列检查项的时候，把「正常下单」放最后，把上面这几条放前面。顺序一换，写测试的人就知道该往哪儿使劲。

九、测试也会过期

代码改了，测试却没跟着改，跑起来照样是绿的。这条测试保护的是半年前那个版本。

一个字段上个月从必填改成可选，老测试还写着不能为空。这条测试现在挡住的是新业务，不是风险。

所以隔一段时间要挑几条出来，问一句：它今天还在验什么。

删掉一条测试，和改一条测试一样，也要留理由。不然等到出事，又多一处说不清。

十、省下的是写测试的时间，不是验收的时间

AI 写测试很快，条数涨得也快。过去一个工程师两周写一百条，现在一个下午能出三百条。

省下的是写测试的那部分工时。省不下的是另一部分：谁来确认这三百条验的是对的。

这部分时间如果也省掉，省掉的就是把关本身。

所以别把测试条数当成进度。条数涨了，只说明写得快，不说明挡得住。

十一、进度别问条数，问哪几类错被挡住

周会上听到「测试从八百条涨到一千四百条」，这个数字说明不了什么。

更有用的问题是这个月哪几类错已经被挡住：重复提交不会再扣两次钱，金额为零的单子进不了付款，断网时订单不会丢。

这三条如果能一条一条答上来，测试才算真的长在业务上。

答不上来，条数再多也只是账面好看。

十二、签字的人签的是判断

上线前那张单子，签的不是测试结果，是判断。

签字的人要能回答两件事：最坏会怎样，出了事怎么退。

这两件事工具给不了。工具能给的是材料：跑过什么，没跑什么，哪些地方只有一条测试守着。

结论得人来下。

签字不等于担保不出错。它的意思是：最坏的那种情况，我们想过，也退得回来。

十三、外包项目，验收条款要提前写

系统如果是外包做的，关于测试的那几句，最好在签合同之前写进验收条款。

没写的话，出事后常见的场面是：对方说按合同交付了，你说这根本没测到。两句话都站得住，因为合同里没写什么叫测到。

那时候再坐下来谈，谈的已经不是技术，是钱和工期。

提前写清楚三件事：测试由谁写，改测试要谁批，交付时附一份清单，标明哪些测试用了真实单子。

这几句不长，写进合同，后面少吵很多架。

十四、人和 AI 各管什么

人可以定三件事：定真实样例，定不能碰的红线，签上线那张单子。

AI 可以接三件事：把没覆盖的路径补上，把边界情况列全，每次改动之后把旧功能跑一遍。

分工写进流程里，工具就不会越位，人也不会把该自己看的那一眼交出去。

十五、这周可以问的三句话

第一句，问技术负责人：这次上线，最坏会怎样，退回来要多久。

第二句，问做测试的人：哪几条测试用的是真实单子，给我看一眼。

第三句，问评审的人：这次改动，测试是跟着改的，还是被放宽了。

三句话都不花钱，也不用换工具。

问完这三句，签字这件事就重新回到了老板手里。