测试用例 Agent 的门禁落地：一条需求缺口，应该挡住哪些用例？
用一个提交申请的合成示例，说明如何关联需求缺口与测试用例、限制依赖范围，并在规则确认后重新校验，避免局部缺口阻塞全部生成或被悄悄写成确定预期。
AI Eval 系列 #12
上一篇：需求不完整时，测试用例生成的 Gate 应该怎么判？
测试用例生成遇到一条未确认的业务规则，应该停止到哪里？
停止全部生成，会让与缺口无关的内容也无法交付；全部放行，又可能把猜测变成测试依据。要处理这个问题，需要知道：缺口影响什么断言，哪些用例依赖这条规则，以及当前准备执行什么动作。
上一篇讨论了草稿生成与正式交付的区别。这篇把问题缩小到一条需求缺口，给出一种可从表格开始实施的处理方式。以下业务规则、编号和产物都是合成示例；字段与判定逻辑是设计建议，不代表已经验证的项目实现。
一、从一个不完整的“提交申请”需求开始
假设当前读取到的需求包含三条明确规则：
| 编号 | 已明确的规则 |
|---|---|
| R-01 | 申请名称为必填项 |
| R-02 | 申请名称最多 50 个字符；测试数据使用普通汉字，避免引入字符计数歧义 |
| R-03 | 合法申请提交成功后，生成一条申请记录，状态为“待审核” |
文档没有明确说明：用户连续点击两次提交，系统应该怎样处理。
由此可以提出一个待确认问题 G-01：“重复提交是拒绝、合并，还是允许形成多条记录？”
不能因为存在 G-01，就认定名称必填检查没有意义；也不能直接写出“提示请勿重复提交，且只生成一条记录”。后一种写法已经替业务方决定了处理方式和提示文案。
这里还有一个前提：单次提交规则与重复提交缺口是否确实能够分开。如果提交机制本身尚未明确，或者无法区分一次业务提交与多次请求，单次提交场景也可能受影响。按局部放行之前，必须先确认依赖范围。
二、先把缺口关联到断言，再关联到用例
用例通常包含多个断言。用例引用了哪一段需求，并不足以解释每个预期结果的来源。
例如，“合法申请提交成功”可能同时检查记录数量、初始状态、提示文案和页面跳转。前三条需求只支持其中一部分；不能因为用例整体引用 R-03，就把其余预期也视为有据可查。
更细的追溯关系可以这样记录：
| 用例或候选测试点 | 预期或待确认内容 | 依据 | 当前处理 |
|---|---|---|---|
| 名称为空时提交 | 必填校验阻止提交；具体文案待确认 | R-01 | 保留有依据的断言 |
| 名称为 50 个普通汉字时提交 | 名称长度校验通过；其他必填字段需合法 | R-02 | 形成可评审草稿 |
| 单次提交合法申请 | 生成一条记录，状态为“待审核” | R-03 | 确认不依赖重复提交规则后形成草稿 |
| 连续点击两次提交 | 第二次提交行为与最终记录数量未确认 | G-01 | 保留候选测试点，等待规则确认 |
这张表不意味着前三项已经获准执行。它只说明已知部分能够形成草稿，后续仍需检查前置条件、操作步骤和人工评审状态。
实际落地时，可以先在现有用例表中增加“规则依据”和“待确认项”两列。只有当缺口经常跨用例传播、人工维护关系容易漏掉时，再考虑自动维护依赖关系。
三、业务规则没写，和 Agent 没读到，处理方式不同
发现重复提交规则缺失时，首先需要核对读取证据。
如果只读了功能描述，没有读取提交接口或异常处理部分，更准确的记录是“当前读取范围未找到相关规则”。这时应执行一次有目标的补查，或者说明尚未检查的范围。
如果已经检查了约定范围及相关引用，仍然没有得到规则，再把问题交给需求评审。即使如此，也应保留检查范围，避免把“在本次范围内未找到”扩写成“整个项目没有定义”。
一个缺口记录可以是：
{
"gap_id": "G-01",
"question": "连续点击两次提交时，第二次提交如何处理？",
"checked_scope": [
"spec-v1:提交功能",
"spec-v1:异常处理"
],
"status": "pending_confirmation",
"affected_test_points": ["TP-04"]
}
这里的章节名称是假设已经检查过的范围。真实运行必须填入实际读取位置，不能让生成器为了满足格式而补齐读取证据。
重试也应根据问题类型安排。工具读取失败，可以在预算内重试；规则未确认，需要新增证据或人的决定。反复生成一份更像完整需求的文本，并不会解决这个缺口。
四、Gate 应判断具体动作
同一个候选测试点，在不同出口的处理可以不同。
| 准备执行的动作 | TP-04 尚有关联缺口时的处理 |
|---|---|
| 输出测试分析草稿 | 允许保留测试意图、缺口编号与问题 |
| 输出确定预期的可执行用例 | 阻止受缺口影响的部分 |
| 输出覆盖报告 | 展示为待确认项，不能计入已完成验证的范围 |
| 导入用例管理平台 | 检查平台是否保留待评审状态、缺口及来源；无法保留时限制导入 |
| 标记为评审通过 | 要求缺口处理完成，相关用例完成适用的复检与评审 |
“允许输出”与“允许执行”应分别判定。一个候选测试点能够帮助评审讨论，却未必有足够信息判断产品对错。
如果现有系统只有一个“通过/失败”字段，也不必立即重建整条链路。先让报告明确当前动作和未完成条件，再逐步拆开出口判定。
五、局部放行最容易错在共享前提
一条缺口看起来只属于一个场景，实际可能影响许多用例。
例如，未确定的如果是“谁有权提交申请”，名称校验、单次提交和重复提交都可能依赖同一权限前提。此时只阻塞重复提交用例，会遗漏其他场景的不确定性。
局部放行前，可以检查三个问题：
- 缺失规则是否会改变这条用例的预期结果？
- 缺失规则是否会改变前置条件、测试数据或可执行路径？
- 是否还有其他用例使用了同一个未确认前提？
只要其中一项无法回答，就应先把相关范围标为依赖待核对。不能仅凭“用例没有引用 G-01”来证明它不受影响：引用关系也可能漏建。
这也是这种方案的局限。它依赖需求拆分与关系识别的质量，单靠状态字段无法保证隔离准确。初期值得优先人工核对共享前提，尤其是权限、状态流转和跨模块规则。
六、规则确认后，要复检受影响的产物
假设评审补充了规则：“同一申请提交处理中，再次提交不得创建新记录。”
这可以解决部分预期，但仍不能推出确切提示文案，也不能直接扩展成“提交完成后永远不能再次提交”。新规则的适用时间和对象边界仍需保留。
处理顺序可以是：
- 记录新规则的确认来源及版本。
- 找出依赖 G-01 的候选测试点和已有用例。
- 根据确认规则补齐步骤、数据和有依据的预期。
- 检查前置条件及断言，再完成适用的人工评审。
缺口已经确认，只说明输入获得了补充。新生成的用例可能仍有步骤不完整、范围扩大或断言无来源的问题，因此不能自动继承“评审通过”。
如果后续需求变更影响 R-03，同样需要找出关联用例重新检查。初期可以人工筛选；关键是让关系可查询、可复核。
七、用小样本验证门禁是否挡对了地方
验证这类 Gate，不能只看总体通过率。更有用的是构造一组结果明确的对照样本。
| 样本 | 应观察到的行为 |
|---|---|
| 重复提交规则未确认，名称必填规则明确，且两者独立性已核对 | 生成名称校验草稿；重复提交保留待确认状态 |
| 文档已有重复提交规则，但解析器漏读 | 暴露读取缺口，补查后重新判定 |
| 生成器编造了重复提交提示文案 | 拦截无依据的确定断言 |
| 权限规则未确定，所有提交场景均依赖它 | 限制相关场景，避免机械局部放行 |
| 缺口已经确认，但用例仍包含超出规则的预期 | 继续拦截受影响断言 |
| 规则确认且用例修订完成，但尚未人工评审 | 保持待评审状态 |
每次调整门禁，都保留应该放行和应该阻塞的样本。否则，修复一次误拦截时，可能顺带放过原本必须阻塞的内容。
对“无依据断言”的检查也要区分能力边界：脚本能够核对引用是否存在、关联缺口是否关闭；判断引用是否真的支持断言，往往还需要语义核对或人工评审。结构校验通过，不能直接当作语义正确。
八、下一次运行先交付一份能复核的结果
如果当前链路还在卡住，下一步可以从一个小功能开始，交付四项内容：
- 有来源的用例草稿。
- 影响确定预期的待确认问题。
- 缺口与用例的对应关系，包括尚未核对的依赖范围。
- 本次允许与阻止的动作，以及相应理由。
先检查：已有依据是否被误挡，未知规则是否被补成事实，共享前提是否被漏掉。这三个问题能够具体回答之后，再扩大文档范围和自动化程度。
对测试用例 Agent 而言，一次有用的运行可以交付局部成果，也可以留下业务问题。交付报告需要让评审者知道哪些内容有依据、哪些还不能执行，以及下一步需要补什么。
继续阅读
继续阅读这个系列
AI Eval：从大模型评测到 Agent Reliability →- 大模型评测到底在评什么？Benchmark、Eval、业务评测一次讲清
- 排行榜第一，为什么到了你的业务里可能不好用？
- Model Eval 和 Agent Eval 有什么区别？从单次输出到完整执行轨迹
- 怎样构造一套真正有用的业务 Eval Dataset？
- LLM-as-a-Judge 怎么做才靠谱？从 Rubric、偏差到人工校准
- Eval 指标怎么设计？为什么 Pass Rate 远远不够
- Offline Eval 和 Online Eval 有什么区别？一套 AI 系统为什么两个都需要
- 线上失败怎么变成 Failure Corpus？从一次事故到持续回归
- Agent Trace Grading 怎么设计？结果正确，过程也可能已经失控
- 怎么把 AI Eval 接进 CI / Quality Gate？让评测真正阻断坏版本
- 需求不完整时，测试用例生成的 Gate 应该怎么判？
- 测试用例 Agent 的门禁落地：一条需求缺口，应该挡住哪些用例？ · 当前篇
沿着问题继续探索
从执行机制走向验证与交付。