test-strategy-doc

测试策略文档技能

根据功能规格、PRD 或系统描述，制定完整的测试策略，涵盖测试范围、测试类型、风险领域、覆盖要求和按优先级排序的测试用例概要。

必需输入

如果用户未提供，请询问以下信息：

• 被测功能或系统（粘贴规格说明、PRD，或用通俗语言描述）
• 技术栈（语言和框架，例如 TypeScript + React、Python + FastAPI）
• 现有测试覆盖情况（例如“我们有单元测试，但没有 E2E 测试”“我们已经在使用 Jest + Playwright”，或“从零开始”）
• 部署节奏（例如持续部署／每周发布／每季度发布——这会影响哪些内容必须自动化，哪些可以手动测试）
• 风险等级（低／中／高／严重——这会影响测试深度和覆盖要求）
• 时间安排（计划何时发布——这会影响优先级）
• 团队情况（由谁负责测试——开发人员／专职 QA／两者共同负责）

输出格式

1. 测试范围

范围内：

• [被测的具体功能]
• [涵盖的集成点]
• [包含的用户流程]

范围外：

• [此处明确不测试的内容及原因]
• [由其他团队负责的依赖项]

假设：

• [测试策略所依据的前提——例如服务已模拟、测试数据可用]

2. 风险评估

优先识别风险最高的领域——它们决定测试深度和覆盖范围：

领域	风险等级	原因	测试优先级
[例如：支付处理]	高	涉及资金流转和监管要求	P0 — 全面测试
[例如：用户身份验证]	高	安全边界	P0 — 全面测试
[例如：电子邮件通知]	中	外部依赖	P1 — 覆盖正常流程和关键故障
[例如：UI 文案变更]	低	仅涉及视觉效果，且可回退	P2 — 仅做冒烟测试

3. 测试类型和覆盖范围

单元测试

• 内容： 隔离测试单个函数和方法
• 编写者： 开发人员
• 覆盖率目标： [例如：新增代码的行覆盖率达到 80%／关键路径达到 100%]
• 工具： [例如：Jest、pytest、go test]
• 此功能的重点： [需要进行单元测试覆盖的具体逻辑]

集成测试

• 内容： 服务交互、数据库操作、API 契约
• 编写者： 开发人员／QA
• 覆盖率目标： [所有正常流程 + 关键故障模式]
• 工具： [例如：Supertest、pytest + testcontainers]
• 重点： [有风险的具体集成点——例如第三方 API、数据库架构变更]

端到端测试

• 内容： 从浏览器／客户端到数据库的关键用户旅程
• 编写者： QA／开发人员
• 覆盖率目标： [列出排名前 N 的用户旅程]
• 工具： [例如：Playwright、Cypress、Selenium]
• 重点： [最关键的 3–5 个用户流程]

性能测试 (如果“风险评估”表格中任一行将性能列为风险因素，则无论总体风险等级如何，都应包含此项)

• 内容： 负载、压力或延迟测试
• 目标： [具体数值——例如：每秒 200 个请求，p95 < 200ms]
• 工具： [例如：k6、Locust、JMeter]

安全测试 (仅在风险等级为高或更高时包含)

• 内容： 与此功能相关的 OWASP Top 10 检查
• 重点： [身份验证绕过、注入、数据暴露]
• 工具： [例如：OWASP ZAP、手动渗透测试、Snyk]

4. 测试用例大纲

按优先级排序的具体测试用例：

P0 — 合并前必须通过：

测试用例	类型	预期结果
[例如：用户可以使用有效凭据登录]	E2E	[重定向到仪表板，创建会话]
[例如：无效登录返回 401]	Integration	[显示错误消息，不创建会话]
[例如：密码绝不会以明文形式存储]	Unit	[数据库中存储 bcrypt 哈希]

P1 — 发布前必须通过：

测试用例	类型	预期结果
[例如：数据库宕机时，登录会平稳失败]	Integration	[用户看到友好的错误提示，返回 503]
[例如：连续 5 次登录失败后，速率限制生效]	Integration	[返回 429，标记账户]

P2 — 应当通过；已知问题有跟踪记录时可发布：

测试用例	类型	预期结果
[例如：登录页面在移动设备上正确呈现]	E2E	[布局符合设计]

5. 测试数据要求

• [所需的具体测试数据——例如：不同状态的测试用户账户]
• [所需的外部服务桩或模拟对象]
• [数据库种子数据要求]
• [任何 PII 相关注意事项，以及测试数据如何处理这些信息]

6. 完成定义

满足以下条件时，测试即告完成：

• 所有 P0 测试用例均通过
• 所有 P1 测试用例均通过
• 代码覆盖率达到规定目标
• 没有尚未解决的严重或高严重级别缺陷
• 达到性能目标（如适用）
• 已完成安全检查（如适用）

质量检查

• 已填写风险表，并据此确定测试优先级（而非泛泛填写）
• 风险评估表中的每个“P0 — 全面测试”条目，至少对应一个 P0 测试用例
• “范围之外”部分至少明确列出一项排除内容（不得留空）
• 每种测试类型都指定了具体工具（不能只写“某个测试框架”）
• 完成定义可衡量（不能只写“QA 满意时测试就算完成”）

反模式

• 不要在缺少用于确定测试优先级的风险表时编写测试策略——泛泛的覆盖率目标不算策略
• 不要将“范围之外”部分留空——每份测试策略都必须明确说明不测试哪些内容及原因
• 不要在未为每种测试类型指定具体工具的情况下说明测试类型——“某个测试框架”不可执行
• 不要制定不可衡量的完成定义——“QA 满意”不是完成标准
• 不要创建没有对应 P0 测试用例的 P0 风险领域——风险评级必须与测试覆盖相对应

使用示例

• “为 [功能] 编写测试策略” + [粘贴规格说明或 PRD]
• “为 [系统] 创建测试计划”
• “我们应该如何测试 [功能]？”
• “我需要为本次冲刺制定 QA 计划”
• “我们需要为 [X] 编写哪些测试？”