ARTICLE · 1183979
AI 测试提效-审 AI 写的断言:把期望值故意改错,看它会不会红
一条断言有没有用，取决于它出错时会不会红
先做一个动作。
随便挑一条 AI 写的用例，找到里面的断言，把期望值故意改成错的——比如原来断言「提交成功」，你改成「提交成功XXXX」——然后跑一遍。
如果它红了，这条断言是活的。
如果它还是绿的，那这条断言没在验任何东西。它一直在那里，从来没拦住过任何问题。
这个动作是我目前找到的、检验一条断言死活最省事的办法：不用读代码，不用理解业务，改一个字符跑一遍就知道。一个项目跑下来，通常能捞出一批"看着很完整、其实全空"的断言。
这篇文章讲三件事：这些空断言是怎么来的、怎么一次批量捞出来、以及捞出来之后怎么改。
一、空断言不是 AI 的错，是它没有"怀疑"这个动作
人写断言的时候，期望值是从需求里来的：需求说"提交后订单状态变为已支付"，你断言的就是这个。
AI 写断言的时候，期望值是从程序现在的行为里来的——它跑一遍，看到程序返回了什么，就把那个当成"预期"。这在程序正确的时候没问题；一旦程序本身有 bug，它就会把这个 bug 固化成"预期"。
这就是问题的根：用被测对象去校准测试，得到的永远是「现在是对的」。
空断言通常长成四种样子：
① 恒真断言。expect(x).toBeDefined()、expect(status).toBeLessThan(500)、expect(list.length).toBeGreaterThanOrEqual(0)。这类断言在语法上完全正确，在语义上什么都没验——length >= 0 对任何数组都成立。
② 抄实际输出。 把程序当时返回的值原样写进期望值。程序改对了，它反而红；程序一直错着，它一直绿。
③ 只断状态码。expect(response.status).toBe(200) 就结束。这验的是"接口没崩"，不是"业务做对了"。一个总是返回 200 但把订单金额算错的接口，能一直绿下去。
④ 断到不相关的字段上。 断言了 id 存在、时间戳格式对、返回体不为空——这些都是噪音，跟这条用例想验的业务结果没关系。
四种样子，共同点是：它们都长得像断言。
图 1：四种空断言，各自其实在验什么
二、批量捞出来：三种验活方法
一条一条改太慢。按目的不同，有三种验法：
图 2：想确认什么，就用哪种验法
方法一：让它出错（验"这条断言活不活"）。把期望值故意改错，跑一遍。必须红。不红就是死断言。这一步可以脚本化——把断言里的期望值批量替换成一个不可能成立的值，跑一遍，收集所有仍然通过的结果。
方法二：追问期望值从哪来（验"这个值对不对"）。拿着期望值问一句：它是从哪句话来的？ 能从需求文档、接口契约、或者业务规则里指出来，就是对的；只能回答"程序返回的就是这个"，就是抄来的，要重写。这一步现阶段只能人工，但它比读代码快得多——不用理解实现，只要问出处。
方法三：喂一个已知有 bug 的版本（验"它拦不拦得住"）。这是最硬的一种。拿一个修复前的版本跑一遍，和这条用例对应的断言必须红。不红，说明这条用例根本拦不住这个回归——那它写着也没意义。
方法一是抽样，方法三才是抽检。方法一便宜、能全跑；方法三贵，但只有它能回答"这条用例到底有没有用"。建议：方法一全跑，方法三只覆盖关键路径。
三、捞出来之后怎么改
改的原则只有一条：期望值必须能追到需求，不能追到程序。
再补两条边界：
• 断言写业务结果，不写实现细节。 别断言 SQL 语句长什么样、别断言调了哪个内部函数。这类断言在重构时会大面积假红，很快就会被整批注释掉——比死断言还糟，因为它会让你不再相信红色。 • 别让生成它的那个模型自己审。 写用例和判用例是同一个模型时，它会认为自己的判断是对的。审断言这件事必须换一双眼睛，最省事的做法是规则 + 抽样人工，而不是"再问一次 AI"。
四、今天就能做的七件事
1. 把期望值故意改错，跑一遍。 绿的就是死断言，这是最快的筛查法。 2. 期望值必须能追到需求、契约或业务规则。 追不到就是抄来的，重写。 3. 禁用恒真断言。 toBeDefined、toBeGreaterThanOrEqual(0)、toBeLessThan(500)这几类，直接从模板里删掉。4. 状态码和业务字段两个都断。 只断 200 等于没测业务。 5. 关键路径喂一个有 bug 的版本。 断言必须红，不红就用例重写。 6. 断言里不许出现实现细节。 SQL、内部函数名、类名，一个都不要进断言。 7. 审断言换一双眼睛。 不要让写用例的那个模型审自己的断言。
一句话总结这一篇：断言的价值不在"它写得对不对"，在"它出错时会不会红"。
关于怎么把 AI 用进测试流程，我们一直在做这件事。这一篇如果对你有点用，转给那个正在接收 AI 生成用例、但还没抽查过断言的同事——尤其是第一种验活方法，改一个字符就能跑，几分钟就能知道手上这批用例有多少是空的。想聊技术细节、或者在你们自己的项目上试一遍，欢迎在公众号后台留言，或发邮件到 clzc_ai2026@qq.com。
