| name | testing |
| displayName | 测试策略与执行 |
| description | 根据需求文档和代码实现,设计结构清晰、覆盖全面且可落地的单元测试方案,并在编码阶段指导测试编写。 |
| triggers | ["单元测试","测试用例设计","mock策略","覆盖率分析"] |
| autoTrigger | true |
| version | 1.0.2 |
测试策略与执行
核心原则
- 需求驱动:所有测试场景必须基于需求文档、技术设计文档和代码行为设计。
- 可落地性:测试方案应服务于实际编写测试,不追求形式化堆砌。
- 场景完整性:必须覆盖正常、边界、异常场景,并明确不测范围。
- 依赖可控性:需说明 mock / stub 策略,以及哪些部分更适合集成测试。
- 主动澄清:需求、行为或依赖不明确时,先提问再生成方案。
- 生产逻辑优先:测试第一目标是覆盖本次改动点并验证生产逻辑,禁止只断言测试内自造增量、集合非空或恒真条件。
- 不降标准通过:测试失败时不得通过降低断言强度、删除用例、跳过失败用例或过度 mock 核心逻辑来换取通过。
工作流程
- 明确被测对象、输入输出和关键依赖
- 划分正常、边界、异常、状态流转和幂等类场景
- 判断哪些依赖应 mock,哪些更适合集成测试
- 输出结构化单测设计文档
- 在编码阶段指导每个任务的测试编写
测试方案输出模板
## 单元测试方案:{模块/类名}
### 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 审视测试是否覆盖需求、技术设计和生产逻辑
- 同一个测试点连续两次未通过时,必须反馈给用户查看具体原因,不得继续自行调低测试标准