leikegeek/testing

测试策略与执行

核心原则

1. 需求驱动：所有测试场景必须基于需求文档、技术设计文档和代码行为设计。
2. 可落地性：测试方案应服务于实际编写测试，不追求形式化堆砌。
3. 场景完整性：必须覆盖正常、边界、异常场景，并明确不测范围。
4. 依赖可控性：需说明 mock / stub 策略，以及哪些部分更适合集成测试。
5. 主动澄清：需求、行为或依赖不明确时，先提问再生成方案。
6. 生产逻辑优先：测试第一目标是覆盖本次改动点并验证生产逻辑，禁止只断言测试内自造增量、集合非空或恒真条件。
7. 不降标准通过：测试失败时不得通过降低断言强度、删除用例、跳过失败用例或过度 mock 核心逻辑来换取通过。

工作流程

1. 明确被测对象、输入输出和关键依赖
2. 划分正常、边界、异常、状态流转和幂等类场景
3. 判断哪些依赖应 mock，哪些更适合集成测试
4. 输出结构化单测设计文档
5. 在编码阶段指导每个任务的测试编写

测试方案输出模板

## 单元测试方案：{模块/类名}

### 1. 测试概述
- **被测对象**：
- **测试目标**：
- **测试策略**：
- **不测范围**：

### 2. 测试环境与依赖
- **测试框架**：
- **Mock 框架**：
- **关键依赖**：
- **特殊配置**：

### 3. 测试用例设计
#### 3.1 正常场景
| 用例ID | 场景 | 输入 | 预期结果 | 关键断言 |
|--------|------|------|----------|----------|

#### 3.2 边界场景
| 用例ID | 场景 | 输入 | 预期结果 | 关键断言 |
|--------|------|------|----------|----------|

#### 3.3 异常场景
| 用例ID | 场景 | 输入 | 预期结果 | 关键断言 |
|--------|------|------|----------|----------|

### 4. Mock 策略与覆盖风险
- **Mock / Stub 建议**：
- **更适合集成测试的部分**：
- **覆盖风险与缺口**：

### 5. 落地建议
- **优先实现顺序**：
- **可测性问题**：
- **建议先补的测试点**：

执行约束

• 不机械追求 100% 覆盖率
• 不强制所有内容都扩成大表格或长说明
• 若项目对覆盖率有要求，应在方案中单独标注关键路径覆盖情况
• 编码完成后的 B3/V2 测试验证必须由独立 unit-test-reviewer agent 审视测试是否覆盖需求、技术设计和生产逻辑
• 同一个测试点连续两次未通过时，必须反馈给用户查看具体原因，不得继续自行调低测试标准