qa-test-plan

QA 测试计划

根据已完成的需求文档生成结构化 QA 测试计划。生成的测试套件直接对应业务需求和用户角色，让 QA 团队清楚了解每轮交付周期的 QA 测试内容。

前提条件

• {base_directory}/requirements/business-requirements.yaml（/business-requirements-interview 的输出）
• {base_directory}/requirements/technical-requirements.yaml（/technical-requirements-interview 的输出）

用法

/qa-test-plan [base-directory]

如果未提供目录，则在当前目录中查找 requirements/business-requirements.yaml 并自动检测。

如果未找到，则提示用户：“你的需求文档位于哪里？”

等待用户提供路径后再继续。将其存储为 base_directory。

流程

第 1 步：确定基础目录并加载需求

如果未提供目录参数，请检查当前目录中是否存在 requirements/business-requirements.yaml。

• 如果存在，将当前目录用作 base_directory
• 如果不存在，提示：“你的需求文档位于哪里？”并等待用户回复

确定 base_directory 后，从 {base_directory}/requirements/ 读取两个需求文件。提取以下内容：

从 business-requirements.yaml 中提取：

• 功能需求和用户故事
• 用户角色及其主要用例
• 成功标准和指标
• 已知约束和边缘情况

从 technical-requirements.yaml 中提取：

• API 接口（端点、输入、输出）
• 身份验证和授权模型
• 非功能需求（性能目标、正常运行时间 SLA）
• 数据模型约束（必填字段、唯一性、格式）
• 安全要求

第 2 步：确定测试套件

将测试覆盖范围划分为若干套件。每个套件对应一个连贯的功能领域（而非单个里程碑）。直接根据需求确定套件，不要臆造源文档中未包含的功能。

可考虑的标准套件类别（仅包含适用项）：

类别	依据
身份验证	技术需求中的身份验证模型
核心用户流程	用户角色 + 功能需求
数据验证	数据模型约束
API 契约	技术需求中的 API 设计
权限与角色	授权模型
错误处理	需求中的边缘情况 + API 错误状态
性能	非功能性能目标
安全	安全要求
集成	技术需求中的外部依赖

步骤 3：为每个测试套件生成测试用例

为每个测试套件编写测试用例，涵盖：

• 正向 — 正常流程、预期的成功结果
• 负向 — 无效输入、未授权访问、缺少必填字段
• 边界 — 边界值、空状态、并发操作、大型负载
• 安全 — 注入、未授权访问升级、令牌／会话滥用
• 性能 — 预期负载下的响应时间（仅在指定目标时）

每个测试用例必须包含：

• id — 在测试套件范围内唯一（例如 tc-auth-001）
• name — 用通俗语言描述测试内容
• type — positive | negative | edge | security | performance
• priority — high | medium | low
  • high：涵盖成功标准或指定用户角色的主要用例
  • medium：涵盖次要流程或验证规则
  • low：涵盖不太可能影响普通用户的边界／特殊情况
• preconditions — 执行测试前所需的系统状态
• steps — 编号的具体操作
• expected_result — 具体且可验证的结果
• requirement_refs — 此用例所验证的业务／技术需求 ID
• tags — 可选的筛选标签（例如 [smoke, regression, auth]）

步骤 4：计算覆盖率

计算覆盖率指标：

• 功能覆盖率 — 至少有一个 high 优先级测试用例的具名功能需求所占百分比
• 用户角色覆盖率 — 其主要用例有 positive 测试用例的用户角色所占百分比
• 非功能覆盖率 — 每个 NFR 类别（性能、安全等）的布尔值，即是否至少存在一个测试用例

将没有任何测试用例的功能需求标记为覆盖缺口。

步骤 5：生成 qa-test-plan.yaml

写入 {base_directory}/delivery/qa-test-plan.yaml。

如果目录不存在，则创建：

mkdir -p {base_directory}/delivery

步骤 6：差距分析

生成文件后，直接报告：

## QA Test Plan Gap Analysis

**Project:** [name]
**Test Suites:** [n]
**Total Test Cases:** [n] ([n] high / [n] medium / [n] low)
**Functional Coverage:** [n]% ([n]/[n] requirements have high-priority cases)
**Persona Coverage:** [n]% ([n]/[n] personas covered)

**NFR Coverage:**
[✓ / ✗] Performance tests present
[✓ / ✗] Security tests present
[✓ / ✗] Integration tests present

**Gaps:**
- [requirement or persona with no coverage, if any]

**Recommendations:** [none / list]

输出格式

qa-test-plan.yaml 架构

输出文档包含：version、project、generated、sources（参考文件路径）、summary（按优先级统计的测试数量、覆盖率指标）以及 test_suites（每个测试套件包含 id（ts-slug）、name、description、requirement_refs 和 test_cases）。每个测试用例包含：id（tc-suite-nnn）、name、type（positive/negative/edge/security/performance）、priority（high/medium/low）、preconditions、steps、expected_result、requirement_refs 和可选的 tags。

完整的文档规范（包含所有字段、覆盖率计算规则和测试用例结构），请参阅 references/output-spec.md。

完整示例请参阅 references/example.yaml。

输出示例

完整的 QA 测试计划示例请参阅 references/example.yaml。