测试面试：AI 生成的测试用例怎么确认没测错？需求对齐、断言有效性验证与统计口径分列

《核心观点》

1. 面试官问「AI 生成的测试用例怎么保证质量」，只回答「生成后跑一遍，再人工看一下」等于没答——他没有听到你到底在检查什么。有效的答法是拿一条具体用例，把需求、脚本、结果三者连起来说。
2. 先核对用例对应哪条需求、前置数据是什么、预期值从哪里来。AI 可以整理候选场景，但不能把系统这一次实际返回的内容直接当成标准答案；需求没写清的地方标成待确认，不让模型自己补一个看起来合理的规则。
3. 接着检查脚本能不能测出错误。在可控的练习环境里故意改错一项预期，确认断言会失败，恢复后再用正常数据跑通。这一步专门用来发现没真正执行的断言、被吞掉的异常，以及只做操作不检查结果的脚本。
4. 正常流程通过之后再看异常和边界有没有缺口。以验证码登录为例：过期、验证码错误、空值这些情况要按实际需求逐条核对。
5. 多生成几种说法不等于多覆盖了几个风险，语义重复的场景要单独识别出来——否则用例数量涨了，风险覆盖并没有变。
6. 报告里的数字必须分开：生成了多少条、人工核过多少条、实际执行多少条、首次通过多少条、重试或修改后通过多少条。可运行比例、通过率、业务覆盖范围各有各的口径，不能用一个「95%」把它们合在一起。
7. 执行后要保留失败记录，并区分是脚本问题、数据问题、环境问题还是产品问题——归错类会让修复方向整个跑偏。
8. 面试时用一条自己亲手校正过的用例最具体：原来哪里不对、依据什么修改、修改后怎样证明测到了目标行为。没做过的步骤留作下一次实践，不要写成项目成果。

《参考解析》

判断 AI 用例好坏的第一问是「预期从哪来」。 这是整条链路里最容易失守的地方。如果预期是从被测系统的输出反推的，那用例只能验证「行为没有变化」，不能验证「行为是对的」——两者在回归测试里都算有用，但价值完全不同，面试时要主动说清你用的是哪一种。可靠的预期来源有三个：需求文档与验收标准、接口契约（schema、状态码、字段约束）、业务方确认过的规则。

故意改错预期是验证断言有效性的标准手段，值得展开讲。 做法是在练习或本地环境里把某一项预期值改成明显错误的，然后跑一遍：如果用例仍然通过，说明这条断言根本没生效（被跳过、被 try-catch 吞掉、或者断言写在了执行之前）。这个动作成本很低，却能一次性筛掉一大批「看起来有测试、实际上没测」的用例，是回答这道题时最能体现动手经验的一句。

覆盖缺口要按需求维度查，不按用例条数查。 具体做法是把需求里的每个条件分支、每个边界值、每个异常码列成清单，再反过来看哪些有用例覆盖、哪些没有，而不是数生成了多少条。仍以验证码登录为例，至少要有：验证码正确且未过期、正确但已过期、错误、为空、重复提交、以及过期后重新获取再登录这几类；数量多少不重要，这几类缺了就是有风险。

重复用例的识别不能只看文本相似度。 两条措辞不同但操作步骤、前置数据、断言都一样的用例，本质是同一条。更实用的判据是「如果这条用例失败，我能定位到的缺陷是否与另一条相同」——相同就合并，并把它记成场景复用而不是覆盖率。

统计口径这件事在面试里非常能加分。 可以把漏斗写成：生成 N 条 → 人工核对后保留 M 条（说明淘汰原因：与需求不符、重复、不可执行）→ 可执行 K 条 → 首次通过 P 条 → 修正断言或数据后通过 Q 条。可运行率反映生成质量，首次通过率反映用例与当前实现的贴合程度，而真正的质量信号藏在「修正后才通过」的那部分里——那里通常混着真实缺陷和被放宽的断言，需要逐条看过。

人工审核真正要花时间的地方是三处。 一是业务语义：模型可能把「仅自己可见」理解成「仅好友可见」，脚本跑得通但语义错了；二是数据前置：AI 常凭空造出系统里并不存在的用户、订单、权限关系；三是断言粒度：模型倾向于断言「页面有内容」这种弱条件，而真正要断的是具体的字段值、提示文案或状态流转结果。把这三处讲出来，就比「人工再看一遍」具体得多。

最后别忘了和回归自动化接上。 通过审核的用例要能进 CI 稳定跑：数据自备自清理、用例之间不互相依赖、失败信息带上足够定位的上下文。否则这批生成出来的用例只会停留在一次性的脚本里，下次需求一变就全部失效。