AI测试用例生成为何漏掉异常流？一份补齐异常流盲区的实践指南

最近我在推进一个内部测试提效项目时，把一批接口测试用例交给了AI生成。产出速度确实让人惊喜——几百条用例几分钟就出来了，覆盖率报告也是一片鲜绿。可当我和一位干了十几年测试的负责人一起过评审时，他翻了不到十分钟就皱起眉头：“这些用例全是顺风局，一场逆风局都没有。”他说的逆风局，就是异常流。

AI测试用例生成是目前研发提效里最热的方向之一，它能快速消化接口定义、业务描述和代码结构，输出格式工整、断言完整的用例。但当我从“能不能跑通”切换到“扛不扛得住”这个视角后，异常流的缺失变得非常扎眼——非法参数、超时重试、状态冲突、重复回调这些真正会捅出线上故障的场景，AI要么完全想不起来，要么只是象征性地写一两条。这件事让我开始重新审视：AI测试用例生成这个工具，我们大概率还没用对。

这篇文章会把我的踩坑记录、分析过程、以及最终沉淀的方案全部摊开。适合正在做AI测试落地的测试工程师、测试架构师，以及想评估“AI生成的用例到底敢不敢用”的技术负责人。如果你觉得“AI生成的用例看起来都对，但总感觉不放心”，这篇文章应该能给你一些启发。

1. 为什么AI总在“不该出事的地方出事”——异常流缺失的三层成因

1.1 训练数据里的“幸存者偏差”

大语言模型能生成测试代码，本质上是拿海量公开代码库喂出来的条件概率。问题就出在这个“海量”上：GitHub上大部分开发者写的测试，验证的是功能正常、主流程跑通、核心算法的输出符合预期。真正系统化地构造异常流测试的团队，比例低得可怜。

我做过一个粗略的抽样统计：在几个知名开源Java项目里，对同一个方法，正常路径的测试用例数量和异常路径用例数量的比例，普遍在5:1甚至10:1以上。更关键的是，那些最有价值的异常流经验根本不写在代码里——它们分布在故障复盘文档里、告警工单里、测试同学的口口相传里。模型在训练阶段完全接触不到这一层信息。这导致的直接后果是：AI从代码里学到的是“正常情况下代码怎么走”，而异常场景下的分支处理、边界保护、防御逻辑，它见过太少，学不成稳定的模式。

1.2 生成策略偏好的“主流路径陷阱”

训练数据只是底层原因，推理阶段的策略选择也在放大偏差。用大模型生成测试用例时，如果参数设置得比较保守，模型会倾向于走概率最高的输出路径——而概率最高的路径永远是主流程。

我在实际使用里观察到，让AI生成“全面的测试用例”时，它理解的“全面”是覆盖更多参数组合、更多子功能点，而不是覆盖更广的错误空间。你让它对某个接口生成用例，它常常会把这个接口的每个成功分支都照顾到，看起来数量很足，但拉开一看全是同一路径上的变体——换一组用户名、换一个ID数值、换一种合法的状态组合。

还有一个容易被忽略的因素：大模型在安全对齐（RLHF）阶段被强化了“不做危险动作、不输出可能引发问题内容的倾向。这种“乖顺”本来是好事，但投射到测试场景里就变味了。当我让AI生成“故意构造非法输入”“模拟对系统发起恶意请求”这类异常流用例时，它会不自觉地打折扣，甚至试图把用例改得“温和”一些。一个被调教得过于礼貌的助手，在写测试用例时天然不擅长当坏人。

1.3 使用者的提示词本身就不够“刁钻”

最后一层责任在我自己。复盘需求阶段，我发现自己写提示词的方式也有问题。多数人的提示词是“用JUnit给XX接口生成测试用例”，或者“给XX方法补充单元测试，要求行覆盖率超过90%”，但我很少在提示词里定义“我要的异常是哪几类”。模型没有默认的“全面”标准，你问得越宽泛，它回答得越模板化；你不告诉它应该从哪些维度扫描异常，它就默认沿着代码的主干逻辑一路写下去。

拿一个最常见的登录接口举例。用普通的提示词让AI生成用例，它大概率会覆盖：用户名密码正确、密码错误、用户不存在。完了。至于账号锁定、验证码错误次数达到上限、重复提交、参数类型不匹配、请求体缺失、时间戳过期、验证服务超时——这些统统想不起来。而这些东西，恰恰是测试工程师经验里“真正容易出事”的地方。

所以我在标题里写了“一场未被教导的盲区”。AI不是故意漏掉异常流，而是从来没有人系统地教过它：异常流是有结构的，是需要按维度逐项扫描的。这个“没有被教导”，既是模型的盲区，也是我们这批使用者的盲区。

2. 那些看着合理却漏掉关键路径的失败案例复盘

2.1 案例一：订单状态流转测试的“全绿假象”

先讲一个让我印象最深的案例。我们有一个支付回调服务，核心是一套订单状态机：待支付、已支付、已取消、退款中、已退款。当时我让AI基于状态机描述生成单元测试，它确实很漂亮地覆盖了每条正常迁移路径——待支付到已支付，已支付到已退款，断言清晰、执行全绿。

漏洞出在哪里？我们的一位老测试只问了我三个问题：

• 支付成功的回调重复到达，订单会变成什么状态？
• 一个已经处于终态“已取消”的订单，收到支付成功回调，系统是否还能正确处理？
• 退款中和支付成功两个事件几乎同时到达，幂等和锁能不能扛住？

这些问题AI一条都没有生成。原因很清晰：代码的正向状态迁移逻辑太清晰了，AI从主流程代码里学到“这个状态可以走向那个状态”，但它看不到状态机内部的保护逻辑——那些重复回调拦截、状态回跳保护、分布式锁防并发，往往散落在底层方法或框架代码里。AI没有经历过重复支付带来的资损，没有处理过状态错乱导致的投诉，所以它不会主动去想这些场景。

这一条漏掉，线上发生一次就是P0事故。覆盖率再绿，也掩盖不了异常流的空白。

2.2 案例二：一个从未被触发的catch块

第二个案例来自一个消费消息队列的任务处理函数。代码大致长这样：

public void handleMessage(Message msg) { try { Order order = parseAndValidate(msg); orderService.process(order); sendSuccessCallback(order.getId()); } catch (Exception e) { log.error("handle message failed, msgId={}", msg.getId(), e); retryQueue.push(msg); } }

AI生成测试用例时，非常自然地构造了一个格式正常的消息，断言处理成功。测试执行全绿，但覆盖率报告里清晰地显示：catch块是红的，一次都没进去过。这个问题的潜在危害比前一个还隐蔽——因为你不知道catch里的告警和重试逻辑到底对不对，等它真正触发时，可能根本拉不起来这条消息。

我当时的排查思路是：要让catch块被触发，必须让parseAndValidate或orderService.process在运行时抛异常。但AI生成消息时，默认消息一定是“结构合法”的——它不会主动去思考“如果消息里的某个业务字段值无法解析会怎样”“如果数据库里的订单状态和消息体不一致会怎样”。后来我在提示词里显式追加了一层要求，让它先分析“这个函数可能以哪些方式失败”，再把catch块的代码位置也喂给AI，它才补出了几条像样的异常用例。

只要模型能看见“这段代码里有失败分支”，它是有能力构造的。问题是它默认不去找，我们需要逼它一下。

2.3 从案例里提炼的共性：AI擅长定义域，不擅长例外域

把这两个案例放到一起，加上我在其他项目里的观察，可以归纳出一个结论：AI测试用例生成在定义域内能做到很完整的覆盖——你给它一个接口，它能枚举参数的所有合法组合，写出漂亮的正例和规范的格式反例；但一到例外域，它就明显缩水。例外域指那些让代码路径分叉的边界条件：状态冲突、依赖超时、重复请求、脏数据、安全攻击。

定义域是接口文档里写清楚的部分，例外域是系统在真实恶劣环境下才会暴露的部分。大模型从训练数据里学到的主要是前者，但线上系统的可靠性，恰恰更依赖后者。这也是为什么“AI生成的用例行覆盖率很高，上线事故却依然频发”这个反直觉现象经常出现——AI把好走的路都铺平了，难走的路一条没修。

3. 补齐异常流的第一步：把“异常知识框架”灌进提示词

既然问题是“没教过”，第一步自然就是“补教”。我试过很多办法，最有效、见效最快的是在提示词层面对AI进行系统性的异常分类教育。

3.1 一套可复用的异常分类枚举法

给AI教异常流知识，不是跟它说“要关注异常”就完了，得给它一张可执行的清单。我后面大量项目里都在用一套六分类的异常框架，不管是接口测试还是单元测试都能套：

这套框架看起来简单，但它给了AI一个明确的“扫描任务”。有了分类之后，你会发现生成结果完全变了个风格，异常用例的密度和精度都上来了。

3.2 提示词模板示例：让模型逐项扫描异常空间

基于上面的分类，我沉淀了一个提示词模板。现在团队内部做任何接口测试用例生成时，都是拿这个模板做底座再按业务调整：

你现在是一名有十年经验的测试架构师。 请为以下接口/方法设计测试用例，要求： 1. 正例3条，覆盖核心成功路径。 2. 按以下六类异常分别生成用例，每类至少2条，并标注分类名称： - 参数与格式异常：如类型错误、空值、越界、重复提交 - 业务状态异常：如状态机非法迁移、数据不存在、状态冲突 - 依赖与服务异常：如下游超时、返回错误、连接池不可用 - 并发与时序异常：如并发写、重复回调、乱序请求 - 权限与安全异常：如未鉴权、水平越权、参数注入 - 环境与数据异常：如字段漂移、超大数据量、时区差异 3. 每条异常用例必须写清楚：触发方式、前置条件、预期结果、断言点。 禁止只写“期望抛异常”这种空泛描述，预期结果需要具体到响应码、状态字段或数据库影响。 接口描述：{这里放入接口描述} 相关代码：{这里放入代码}

模板里“预期结果具体化”这个点，是踩了好几次坑才想明白的。AI生成的异常用例经常出现这种情况：它预期“系统会抛异常”，但根本没说明抛什么类型的异常、异常之后数据应该处于什么状态。这种用例拿到执行阶段就是废的。所以我在模板里加了一条硬性约束，效果很直接——生成出来的用例质量高了一个档次。

3.3 和静态分析结果联动，让模型看见“死代码”

提示词工程有一个天花板：模型对代码的理解上限取决于你喂给它的上下文。代码里那些没执行到的catch块、空分支、幂等判断逻辑，如果只靠人眼读代码，很容易漏掉。

我最近的实践是：把覆盖率报告或静态扫描结果作为附加上下文一起喂给AI。比如：“该类当前行覆盖率90%，但第45行catch块、第78行空分支、第120行幂等判断尚未被覆盖。请针对性生成能触发这些分支的异常用例。”

这样做的好处是把“异常流关键词”从抽象的“可能有问题”变成了具象的“这里肯定没测到”。AI不擅长自己定位盲区，但它很擅长根据命令精确执行。覆盖率报告和静态扫描工具负责找出“代码的哪个角落没人去过”，AI负责根据这些线索倒推“什么样的异常输入能走到那里”。这两个环节一结合，效果比我单独调提示词强了不止一个量级。

4. 私有化场景语料：教AI认识你们系统真正摔过跤的地方

通用的异常分类框架解决了“AI想不到要测异常”的问题，但还解决不了另一个问题：每个业务系统都有自己独特的异常敏感点。这类知识长在业务的血脉里，向上看接口文档看不到，向下看通用代码也看不全。

4.1 从缺陷库和故障复盘里提炼few-shot样例

我试过最有效的方式，是把历史缺陷库转化成AI能理解的样例语料。每个团队过去几年都会积累一批有分量的线上故障、P0/P1缺陷单，这些单子里往往记载着最真实的异常触发场景。把这些内容脱敏并结构化，就能变成非常有价值的样例。

一个样例的结构大概是这样：

【历史故障】用户重复点击“确认收货”按钮时，系统未做状态校验，返回“操作成功”并重复发放优惠券。 【根因分析】接口缺少状态机前置校验，终态订单未做重复操作拦截。 【测试要求】构造已处于终态（已签收）的订单，发起重复确认请求，期望返回业务错误码，且不可触发重复发券动作。

这类样例放一两条到提示词的few-shot区域，比写一百句“请多关注异常”都管用。大模型是典型的学习者——你给它看什么例子，它就照着那个标准来完成。当你给它的示例来自你们系统真实的故障史，它生成的用例就会明显带有“懂行人会写的那种感觉”。

我当时推进这件事时，从过去两年的P0/P1单里抽了大概20条，按模块做了归类，写成一个不起眼的Markdown文件。做某个模块的AI用例生成时，就从里面挑相关的三到五条塞进提示词。效果立竿见影，测试的同事看生成结果时，说的第一句话从“这不像我们系统的用例”变成了“这确实像我们的用例”。

4.2 微调之外的轻量做法：动态样例注入

会有人问：要不要拿私有语料做模型微调？这是一个可行的方向，但从工程投入产出比来看，我不建议一开始就上微调。微调的维护成本高、迭代周期长，业务在变、故障在变，模型不可能每次出现新故障就重训一次。

更轻量的做法是动态样例注入：在请求时，先把历史缺陷库里跟当前模块相关的样例检索出来，拼进提示词上下文里再让AI生成。样例库规模上来之后，还可以考虑做一个简单的RAG（检索增强生成）流程：把历史缺陷样例向量化存起来，当要测试某个接口时，先做语义检索，抽出最相似的三到五条历史伤害经验，让AI参考这些经验去生成用例。

这套流程本质上把团队通过真金白银换来的教训沉淀成了可复用资产。以前这些经验只存在于老测试的脑子里，现在它变成了一套能持续喂养AI的语料体系。它解决的是“当我们组最懂业务的人离职了，AI还能不能记住这些坑”的问题。

4.3 经验提醒：别让模型把旧bug当成新需求

历史缺陷样例确实有用，但副作用也很明显，这里需要重点提醒几个坑：

第一，不是所有历史缺陷都适合当样例。有些故障根因是临时性的，比如一次配置变更导致的问题、一次数据补偿造成的脏数据、某个大促峰值触发的性能瓶颈。这类案例如果被当成通用样例喂进去，模型会在正常接口上疯狂构造“阴间用例”，把每个接口都当成有问题的对象来打，生成结果反而没法看。

第二，样例必须按模块、按优先级做好标签管理。不然容易出现上下文污染：一个支付模块的接口，模型在做用例时被塞入了订单模块的老故障样例，它就会去写一些和当前接口定义完全无关的用例，白白浪费成本。

第三，也是最容易被忽视的一点：旧缺陷的预期结果会随版本演进而改变。一个之前“应该返回错误”的接口，可能在新版本里被重构成了“允许并幂等处理”。如果你把几年前的旧样例直接喂进去，模型就会按旧逻辑生成一条和当前需求完全相反的用例。这个坑我自己踩过，现在对缺陷样例的时效性审查非常敏感——任何一条进入知识库的历史缺陷，都要标注它对应的版本和当前有效性。

5. 建立异常流的“红队评审”：AI生成用例的人类质检工序

即便提示词优化了、私有样例也接入了，AI生成的用例依然不能直接全盘信任。AI的能力上限决定了它的输出是“看起来极其合理，但可能隐藏系统性盲区”的东西。所以必须设置一道人类的质检工序。

5.1 一套异常流覆盖评审检查单

过去评审测试用例的质量，依赖老测试的个人直觉——“我看一眼就知道这里没写到位”。但这个能力不是每个人都有，也不是每时每刻都稳定。把个人直觉显式化成一张检查单，团队里的每个人都能执行，效率会高很多。

我现在在评审时用到的核心检查项大概是这样的：

这个检查单有两个用法：一是给评审人当参照系，防止漏看；二是反向喂给AI，让生成用例时就按这个标准逐项对齐。现在我的标准流程是先让AI按检查单生成，再由测试人员拿着同一张单子去做差异比对。

5.2 AI生成的“脏数据”用例，需要在隔离环境里先跑一遍

AI生成异常流用例，意味着它一定会构造各种异常输入——恶意格式的参数、越权访问的描述、破坏状态的请求。这类用例本身没问题，但如果不加控制地进入共用的测试环境，可能引发连锁反应。

我的建议是给AI生成用例设计一条独立的执行通道：所有由AI生成且涉及权限攻击、状态破坏、大量脏数据写入的用例，一律先放到隔离的沙箱环境里执行。等结果确认无误，再由测试人员决定是否纳入常规回归集。另一个必须执行的纪律是数据脱敏：AI可能生成它没见过的“账号密码”“手机号”“身份证号”，这类数据在进入用例库前要统一用假数据替代，不能在测试环境里真实发送涉及敏感信息的内容。

这一条看起来是工程细节，但它决定了AI测试提效项目能不能走远。把AI生成的用例当真实用例不加区分地执行，等于跳过评审期埋雷，和这件事的初衷相违背。

5.3 人类测试工程师在AI时代的核心增量

站在这个项目推进了大半年之后再回头看，我对AI生成测试用例的看法稳了很多：它能把人从海量的、重复的正例用例中解放出来，让我们有空去思考更有价值的问题——越权的访问路径是什么、状态的并发冲突怎么模拟、依赖的故障注入怎么做、哪些历史教训值得沉淀成规则再教回给AI。

异常流这块，恰恰是测试工程师在AI时代不应该让渡出去的核心能力。AI可以学会覆盖率追踪、学会按接口定义构造请求、学会从代码里读出分支结构，但它很难学会“一个业务在真实世界里受到诡异操作时的行为预期”。这个知识长在业务里、长在系统长期的运行数据里，也长在你对它的理解里。

所以，想让AI生成出真正有杀伤力的异常流用例，关键动作从来不是调参数、换模型，而是先把自己的工程经验和AI对齐。你得先知道你们系统的软肋在哪里，才有可能让AI帮你把软肋周围的围栏修好。把异常分类框架写进提示词，把历史故障样本沉淀为语料，把评审检查单变成团队默认动作，走完这三步，AI用例生成从“能看”到“能用”之间的距离，就没有想象中那么远了。