Test Strategy Designer

测试策略设计 Skill

根据代码变更分析测试影响面，设计按优先级分类的测试策略，帮助选择合适的测试类型和范围。

何时使用

• 代码变更后确定需要测什么
• 新功能开发前设计测试计划
• 评估测试覆盖率缺口
• 选择合适的测试类型（单元/集成/E2E/性能）

不适用：编写具体测试代码、CI/CD 流水线配置、测试环境搭建。

测试类型选择矩阵

输入

输出

• 测试影响面分析
• 按优先级分类的测试策略（P0/P1/P2）
• 每项测试的范围、类型和理由
• 覆盖率缺口分析
• 预估测试工作量

执行步骤

1. 分析变更影响面

分析变更影响面:
  IF 修改了公共 API/接口 → 影响面: 全部消费方, 优先级: P0
  IF 修改了内部工具函数 → 影响面: 直接调用方, 优先级: P1
  IF 修改了配置/常量 → 影响面: 所有引用点, 优先级: P1
  IF 修改了 UI 组件 → 影响面: 渲染路径, 优先级: P2
  IF 修改了测试代码本身 → 影响面: 测试套件, 优先级: P2
  IF 新增了功能 → 影响面: 新功能路径 + 边界条件, 优先级: P0
  IF 修复了 bug → 影响面: bug 路径 + 回归范围, 优先级: P0

2. 映射测试类型

根据变更类型和影响面，查测试类型选择矩阵确定需要的测试类型：

IF 变更涉及纯逻辑 → 单元测试（必须）
IF 变更涉及外部依赖交互 → 集成测试（必须）
IF 变更涉及用户可见行为 → E2E 测试（必须）
IF 变更涉及高并发/大数据 → 性能测试（建议）
IF 变更涉及认证/授权/数据处理 → 安全测试（建议）

3. 评估已有测试覆盖

覆盖率评估:
  FOR each 变更路径:
    IF 已有测试覆盖此路径 → 标记"已有覆盖", 评估是否需要更新
    IF 已有测试但断言不充分 → 标记"覆盖不足", 建议增强
    IF 无任何测试覆盖 → 标记"未覆盖", 建议新增

覆盖率缺口 = 所有"未覆盖" + "覆盖不足"的路径

4. 设计测试策略

## 测试策略

### P0 — 必须测试（阻塞发布）
| 测试项 | 测试类型 | 范围 | 理由 |
|--------|----------|------|------|
| 用户创建接口返回格式 | 单元 + 集成 | POST /users | 公共 API 变更 |
| 新增字段的空值处理 | 单元 | UserService.create | 新增必填参数 |
| 回归: 用户列表分页 | 集成 | GET /users?page= | 修改了分页逻辑 |

### P1 — 应该测试（发布前完成）
| 测试项 | 测试类型 | 范围 | 理由 |
|--------|----------|------|------|
| 错误响应格式一致性 | 集成 | 所有错误码 | 修改了错误处理 |

### P2 — 建议测试（下个迭代补充）
| 测试项 | 测试类型 | 范围 | 理由 |
|--------|----------|------|------|
| 并发创建用户 | 性能 | POST /users | 新增了唯一性校验 |

### 覆盖率缺口
- src/services/UserService.ts: 当前覆盖率 45%, 建议达到 80%
- 新增代码路径未覆盖: 错误码映射逻辑、空值分支

5. 预估工作量

工作量估算:
  单元测试: 每个测试项 ~15 分钟
  集成测试: 每个测试项 ~30 分钟
  E2E 测试: 每个测试项 ~45 分钟
  性能测试: 每个测试项 ~1 小时
  安全测试: 每个测试项 ~1 小时

总计: P0 约 X 小时, P1 约 Y 小时, 全部约 Z 小时

边界与非目标

• 不做编写具体测试代码 — 只设计策略，编写由用户执行
• 不做代码 review — 这是 code-review-checklist 的职责
• 不做重构建议 — 这是 refactoring-planner 的职责
• 不做API 设计审查 — 这是 api-design-reviewer 的职责
• 不做错误模式管理 — 这是 error-pattern-library 的职责
• 只设计测试策略，不涉及 CI/CD 流水线和测试环境

验收标准

• 每个测试项都有明确的测试类型、范围和理由
• P0 测试项覆盖了所有公共 API 变更和 bug 修复路径
• 覆盖率缺口分析指出了具体的未覆盖路径
• 工作量估算基于测试类型和测试项数量
• 没有将低优先级探索性测试标记为 P0