测试工程师拿到一份新的需求文档，最耗时的往往不是执行测试，而是解析自然语言描述——将需求拆解为一条条可验证的测试用例。

举个例子。需求文档中描述“用户登录失败三次后锁定账号 15 分钟”，这句话看似简单，但到了测试环节，需要覆盖的场景就非常丰富：正常锁定、边界值、锁定期间再次登录、自动解锁、手动解锁……这些还不够。失败次数的统计维度，是按用户名还是手机号？这些细节手工拆解既耗时又费力，还容易因个人经验不足而遗漏某些边界条件。

那么，有没有更高效的方法？答案是肯定的。模型能够快速生成一套结构化的测试用例草稿，但仅生成一次仍不够。为了确认覆盖是否完整，还需一个独立的复核环节——本文就围绕这一思路展开。

本次使用 Gemini 3.5 Flash 拆解需求并生成测试用例，再由 Claude Opus 4.8 对照原始需求检查覆盖率。整个流程均在同一工作区内完成。

输入材料：一条待解析的功能需求

先看本次使用的需求。以下是一条经过脱敏处理的模拟用户登录安全需求：

功能：用户登录失败锁定机制

需求描述：
当用户连续登录失败达到3次时，系统自动锁定该账号15分钟。锁定期间，
即使输入正确的用户名和密码也无法登录，系统返回“账号已被锁定，请稍后重试”。
15分钟后系统自动解除锁定，用户可正常登录。

附加说明：
- 连续失败次数以用户名或手机号为维度计算
- 锁定前（第3次失败时）需提示用户“再失败1次账号将被锁定”
- 管理员可在后台手动解除锁定

虽然这段需求不长，但其中包含了多个测试切入点：

• 正常流程：触发锁定、15 分钟后自动解锁。
• 边界条件：恰好失败 3 次、锁定时间到达 15 分钟。
• 异常流程：锁定期间持续尝试登录。
• 权限场景：管理员在后台手动解锁。
• 提示信息：第 3 次失败时显示指定提示语。
• 计数维度：分别按用户名和手机号统计连续失败次数。

其中，管理员手动解锁和锁定前提示是较容易忽略的内容。失败次数的统计维度虽然在需求中明确写出，但若未单独拆成测试场景，也可能仅得到间接验证。

操作流程：分离用例生成与覆盖率复核

这个分工其实很直接：

Gemini 3.5 Flash 负责从需求中提取测试点，并按统一格式生成测试用例； Claude Opus 4.8 则从独立视角重新解析需求，检查用例是否覆盖了全部可测试的约束条件。

将生成与复核拆成两个环节，可避免模型在检查自身输出时沿用原有思路。复核模型无需评价用例是否流畅，只需逐条回答一个问题：需求中的每项约束是否都有对应的测试用例。

第一步：用 Gemini 3.5 Flash 生成测试用例

Gemini 3.5 Flash 于 2026 年 5 月正式发布，是 Gemini 系列中首款融合前沿智能与快速响应的模型，在结构化输出与响应速度之间取得了较好平衡。

测试用例生成需在较短时间内覆盖正常流程、边界值、异常流程和权限等多个维度，这类任务适合使用 Gemini 3.5 Flash 快速生成初稿。

在工具中提交需求文档后，使用以下生成 Prompt：

请根据以下需求描述，生成一份测试用例清单。
要求：
1. 用例覆盖以下类型：正常流程、边界值、异常流程、权限相关、提示信息验证；
2. 每个用例包含：用例编号、测试类型、前置条件、测试步骤、预期结果；
3. 直接引用需求中的具体数字和描述，不自行修改阈值或条件；
4. 需求中未明确的实现细节，在用例中标注“【待确认】”；
5. 需求内容如下：
[此处粘贴需求描述]

这段 Prompt 对输出格式和信息边界均做了限制。

一方面，它要求模型按固定字段输出，便于后续直接整理成用例清单；另一方面，它明确要求保留需求中的数字、阈值和条件，不得自行补充进度或实现细节。对于需求未说明的内容，则统一标注“【待确认】”。

Gemini 3.5 Flash 共生成了 8 个测试用例，覆盖了以下场景：

• 正常触发账号锁定。
• 锁定期间拒绝使用正确密码登录。
• 账号在 15 分钟后自动解锁。
• 恰好失败 3 次时的边界验证。
• 管理员在后台手动解除锁定。
• 第 3 次失败时的提示信息验证。

用例编号从 TC-01 到 TC-08，每条用例均包含前置条件、测试步骤和预期结果。初稿已覆盖需求中的大部分内容，但部分约束仍仅得到间接验证。

第二步：用 Claude Opus 4.8 复核覆盖率

生成初稿后，切换到 Claude Opus 4.8。

Claude Opus 4.8 于 2026 年 5 月发布，是 Claude 系列的旗舰版本，在推理能力方面有全面改进。复核时，将原始需求和 Gemini 3.5 Flash 生成的用例清单一起提交，并使用以下 Prompt：

请逐项核对以下需求描述和测试用例清单，检查用例是否完整覆盖了需求中的所有约束条件。
要求：
1. 将需求拆解为独立的约束条件，逐条列出；
2. 标注每条约束条件是否在测试用例中有对应的用例覆盖；
3. 对未被覆盖的约束条件，说明缺失的具体内容；
4. 标注出用例中存在但需求中未提及的测试点；
5. 需求描述和用例清单如下：
[此处粘贴需求和用例清单]

与生成阶段不同，这个 Prompt 不要求模型继续扩写用例，而是先将需求拆成独立约束，再逐项与现有用例进行对照。这样可以更清晰地区分“已直接覆盖”“仅间接覆盖”和“完全未覆盖”三种情况。

Claude Opus 4.8 将需求拆解成了 7 条独立约束：

1. 连续登录失败达到 3 次后触发锁定。
2. 锁定期间，即使密码正确也不能登录。
3. 账号锁定时长为 15 分钟。
4. 锁定期间返回“账号已被锁定，请稍后重试”。
5. 15 分钟后系统自动解除锁定。
6. 失败次数以用户名或手机号为维度计算。
7. 第 3 次失败时显示“再失败 1 次账号将被锁定”。

逐条核对后， Claude Opus 4.8 发现有两类约束虽然已被初稿涉及，但验证仍不够充分。

失败计数维度缺少独立验证

“失败次数以用户名或手机号为维度计算”这一约束，在 TC-01 中仅得到间接验证。该用例使用同一用户名连续失败 3 次，可证明用户名场景能触发锁定，但无法完整证明用户名和手机号两个维度的计数规则。

Claude Opus 4.8 建议增加两个用例：

• TC-09：使用同一手机号连续登录失败 3 次，验证手机号维度可独立触发锁定。
• TC-10：使用不同用户名分别失败 1 次，验证不同用户间的失败次数不会错误累计。

这样可将原本的间接覆盖拆成两个明确、可执行的测试场景。

15 分钟边界缺少锁定前一刻的验证

原有的 TC-04 验证了账号在锁定满 15 分钟后自动解除，但未验证 15 分钟到达之前，账号是否仍保持锁定状态。

为此， Claude Opus 4.8 建议补充 TC-11：在账号锁定后的 14 分 59 秒尝试登录，预期账号仍处于锁定状态。

这个用例与“15 分钟后自动解除锁定”的用例配合，可同时验证时间阈值的正反边界。

最终交付：补充后的完整用例清单

将复核结果合并到初稿后，最终得到以下测试用例清单：

补充后，用例数量从 8 条增加到 11 条。新增内容未改变原需求中的阈值和条件，而是将原本覆盖不充分的计数维度与时间边界拆成了单独的验证场景。

验收标准

用例清单交付前，可按照以下标准完成最后一次检查：

其中，“无自创需求”尤其需要注意。模型在补充测试场景时，可能会加入一些看似合理但原需求未提及的规则。复核时不仅需检查需求中有、用例中无的内容，也要检查用例中是否出现了需求之外的新条件。

使用时需注意的问题

本次使用的是模拟需求，不涉及真实内部产品信息。实际项目中的需求文档可能包含未公开的业务逻辑、客户信息或内部系统名称，提交给模型前，需确认已完成脱敏处理。

模型生成的测试用例仅作为辅助材料。最终是否纳入测试计划，以及不同用例的优先级如何安排，仍需由测试负责人判断。

若需求涉及安全、支付或合规功能，边界值、安全场景和异常流程还需由具备对应经验的测试工程师确认，不能仅依赖模型生成结果。

在此次处理中， Gemini 3.5 Flash 的主要作用是快速按测试用例模板组织内容。首轮生成的 8 个用例已覆盖需求中的大部分约束，适合用作结构化初稿。

Claude Opus 4.8 的价值则体现在复核阶段。它把“以用户名或手机号为维度”这样的约束单独拆出，并进一步区分了间接覆盖与直接覆盖。通过逐项比对，原本隐藏在综合用例中的约束被转化成了可单独执行和验收的测试场景。

后续可尝试的方向

如果平时经常需要根据需求文档生成测试用例，可将这套流程整理成固定模板：先使用 Gemini 3.5 Flash 快速生成用例初稿，再用 Claude Opus 4.8 复核需求覆盖率。

复核时可重点关注“需求中有、用例中无”和“需求中有、但用例仅做间接验证”两类条目。前者属于明确遗漏，后者虽表面上已覆盖，但在实际执行时可能无法准确定位问题。

经过几轮使用后，还可根据团队常见的需求类型积累测试模板和约束清单。例如，登录安全需求可固定检查次数阈值、时间边界、计数维度、提示信息、解锁方式和权限范围；支付需求则可单独整理金额边界、重复提交、超时和回滚场景。

整个过程可在同一工作区内完成。需求文档仅需提交一次，生成初稿后直接切换模型进行复核，无需在不同平台间反复导入和导出内容。