从需求生成可复核的功能测试用例

这个场景能帮你做什么

测试用例容易漏掉子模块、前置条件和业务历史问题。WorkBuddy 可以依据规范需求、基线用例与已知缺陷生成候选，由测试人员复核后执行。

开始前需要准备什么

提供有效需求、角色权限、业务流程、数据规则、已有基线和历史踩坑记录。说明产品版本、测试环境和预期输出。视觉稿无法从文字确认的内容单列。

具体怎么做

第一步：先检查需求质量

找输入、处理、输出、边界和验收缺口。规则不清先补问，不能让 AI 一边猜需求一边生成自洽测试。

第二步：按模块与功能点拆分

将每个独立行为对应需求编号，补角色、状态和数据条件。复杂需求先分模块生成，再检查模块间流程，不把整篇 PRD 一次压成几条大用例。

第三步：起草可执行用例

每条包含前置、输入、具体步骤、预期、依据和测试数据要求。参考历史基线与缺陷，避免只覆盖正常路径；没有确定预期的标待确认。

第四步：去重与补覆盖

仅在需求版本、角色权限、前置状态、执行路径、输入和预期均等价时合并重复用例；输入与预期相同但条件不同的变体保留。测试人员核对需求覆盖、可执行性与结果判定，再导入管理工具。

从一条需求得到正常与边界用例

以下为教学示例。已确认需求 R-01 为：“登录且有提交权限的用户，可提交整数数量 1—10；超出范围时显示‘数量应为 1—10’，不生成订单。”这里明确包含上下界和失败行为，因此可以生成：

用例	前置条件及输入	操作	可观察预期与依据
正常值	登录、有提交权限，数量 5	填写后点击提交	成功生成数量为 5 的订单；依据 R-01
下边界	相同前置，数量 1	同上	成功生成数量为 1 的订单
上边界	相同前置，数量 10	同上	成功生成数量为 10 的订单
越界	相同前置，分别输入 0、11	分别提交，独立记录结果	提示指定文案，各次均不生成订单

需求未说明无权限、未登录、小数、空值或重复提交时怎样处理，应列为需求缺口或关联到其他明确规则，不能自行编造预期。“成功生成订单”还需结合系统约定补充可检查的位置，例如订单列表和订单编号；测试数据、环境及清理要求由测试人员确认后补齐。

可以直接交给 WorkBuddy 的完整要求

按附件需求、基线和历史问题生成候选功能用例，先列需求缺口。
按模块/功能点组织，每条列需求编号、角色、前置、输入、操作步骤、预期与依据。
复杂需求分模块处理后补跨模块路径；预期未知标待确认，不自行发明规则。
输出去重后的用例和未覆盖项，不宣称已执行或已达到覆盖目标。

完成后会得到什么

一组可被测试人员复核和执行的用例，以及需求缺口、数据准备和覆盖不足事项。

结果应该怎么检查

实际选几条照着做，检查操作是否明确、预期能否观察。反向从需求查用例，防止有大量用例却遗漏整块功能。

遇到这些情况怎么处理

需求缺失时先澄清。测试数据不能取得时标阻塞。需要视觉或真机判断的结果保留人工验证，不由文本推断通过。

哪些必须人工决定

测试人员确认策略、用例和结果，业务确认预期。AI 起草候选，不以生成文件代替实际测试。