devdocs-test-cases
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese测试用例设计
Test Case Design
基于需求文档设计测试用例,建立验收标准与测试用例的追溯关系。
Design test cases based on requirement documents, and establish traceability between acceptance criteria and test cases.
语言规则
Language Rules
- 支持中英文提问
- 统一中文回复
- 使用中文生成文档
- Support questions in Chinese and English
- Respond uniformly in Chinese
- Generate documents in Chinese
触发条件
Trigger Conditions
- 用户已完成需求文档
- 用户要求设计测试用例
- 用户需要测试覆盖策略
- User has completed the requirement document
- User requests test case design
- User needs test coverage strategy
前置条件
Preconditions
- 需求文档:
docs/devdocs/01-requirements.md - 系统设计文档:(设计 UT/IT 时需要了解接口签名和模块划分)
docs/devdocs/02-system-design.md - 如不存在,建议先运行前置阶段
- Requirement document:
docs/devdocs/01-requirements.md - System design document: (Required to understand interface signatures and module division when designing UT/IT)
docs/devdocs/02-system-design.md - If not present, it is recommended to run the pre-phase first
核心理念
Core Concepts
测试用例来源
Test Case Sources
功能点 (F-XXX)
│
└── 用户故事 (US-XXX)
│
└── 验收标准 (AC-XXX)
│
├── 单元测试 (UT-XXX) ← 验证内部逻辑
│
├── 集成测试 (IT-XXX) ← 验证组件协作
│
└── E2E 测试 (E2E-XXX) ← 验证用户场景关键原则:
- 测试用例从需求推导,不是从代码推导
- 每个验收标准至少有一个测试用例覆盖
- 测试类型根据验收标准的性质选择
Feature Point (F-XXX)
│
└── User Story (US-XXX)
│
└── Acceptance Criterion (AC-XXX)
│
├── Unit Test (UT-XXX) ← Verify internal logic
│
├── Integration Test (IT-XXX) ← Verify component collaboration
│
└── E2E Test (E2E-XXX) ← Verify user scenariosKey Principles:
- Test cases are derived from requirements, not from code
- Each acceptance criterion must be covered by at least one test case
- Test type is selected based on the nature of the acceptance criterion
测试类型选择
Test Type Selection
| 验收标准类型 | 推荐测试类型 | 示例 |
|---|---|---|
| 输入验证规则 | 单元测试 | "邮箱格式校验" → UT |
| 业务逻辑规则 | 单元测试 + 集成测试 | "密码加密存储" → UT + IT |
| 用户交互流程 | E2E 测试 | "完成注册流程" → E2E |
| 组件间协作 | 集成测试 | "发送验证邮件" → IT |
| Acceptance Criterion Type | Recommended Test Type | Example |
|---|---|---|
| Input validation rules | Unit Test | "Email format validation" → UT |
| Business logic rules | Unit Test + Integration Test | "Password encrypted storage" → UT + IT |
| User interaction flow | E2E Test | "Complete registration process" → E2E |
| Inter-component collaboration | Integration Test | "Send verification email" → IT |
编号规范
Naming Convention
| 类型 | 前缀 | 格式 | 示例 |
|---|---|---|---|
| 单元测试 | UT | UT-XXX | UT-001, UT-002 |
| 集成测试 | IT | IT-XXX | IT-001, IT-002 |
| E2E 测试 | E2E | E2E-XXX | E2E-001, E2E-002 |
| Test Type | Prefix | Format | Example |
|---|---|---|---|
| Unit Test | UT | UT-XXX | UT-001, UT-002 |
| Integration Test | IT | IT-XXX | IT-001, IT-002 |
| E2E Test | E2E | E2E-XXX | E2E-001, E2E-002 |
工作流程
Workflow
1. 读取需求文档
│
▼
2. 提取功能点、用户故事、验收标准
│
▼
3. 为每个验收标准选择测试类型
│
▼
4. 设计单元测试用例 (UT-XXX)
│
▼
5. 设计集成测试用例 (IT-XXX)
│
▼
6. 设计 E2E 测试用例 (E2E-XXX)
│
▼
7. 生成追溯矩阵
│
▼
8. 用户确认1. Read requirement document
│
▼
2. Extract feature points, user stories, and acceptance criteria
│
▼
3. Select test type for each acceptance criterion
│
▼
4. Design unit test cases (UT-XXX)
│
▼
5. Design integration test cases (IT-XXX)
│
▼
6. Design E2E test cases (E2E-XXX)
│
▼
7. Generate traceability matrix
│
▼
8. User confirmation输出文件
Output Files
主文件:
docs/devdocs/03-test-cases.mdMain File:
docs/devdocs/03-test-cases.md文档拆分规则
Document Splitting Rules
当满足以下条件时,应拆分文档:
- 测试用例总数超过 30 个
- 文档超过 300 行
- 单一测试类型用例超过 15 个
拆分方式:
docs/devdocs/
├── 03-test-cases.md # 主文档:测试策略、覆盖率要求、追溯矩阵
├── 03-test-unit.md # 单元测试用例(UT-XXX)
├── 03-test-integration.md # 集成测试用例(IT-XXX)
└── 03-test-e2e.md # E2E 测试用例(E2E-XXX)拆分内容分配:
| 文件 | 包含内容 |
|---|---|
| 03-test-cases.md | 测试策略、覆盖率要求、追溯矩阵、测试用例汇总 |
| 03-test-unit.md | 所有单元测试用例详情(UT-001 ~ UT-XXX) |
| 03-test-integration.md | 所有集成测试用例详情(IT-001 ~ IT-XXX) |
| 03-test-e2e.md | 所有 E2E 测试用例详情(E2E-001 ~ E2E-XXX) |
主文档保留内容:
- 测试策略说明
- 覆盖率目标
- 完整追溯矩阵(F → US → AC → 测试)
- 各子文档的用例范围说明
小型项目:如测试用例较少(< 30 个),可合并为单一文件 。
03-test-cases.md详细模板参见:
- templates/test-cases-template.md
- templates/unit-test-template.md
- templates/integration-test-template.md
- templates/e2e-test-template.md
Split the document when any of the following conditions are met:
- Total number of test cases exceeds 30
- Document exceeds 300 lines
- Number of test cases for a single test type exceeds 15
Splitting Method:
docs/devdocs/
├── 03-test-cases.md # Main document: Test strategy, coverage requirements, traceability matrix
├── 03-test-unit.md # Unit test cases (UT-XXX)
├── 03-test-integration.md # Integration test cases (IT-XXX)
└── 03-test-e2e.md # E2E test cases (E2E-XXX)Content Allocation After Splitting:
| File | Content Included |
|---|---|
| 03-test-cases.md | Test strategy, coverage requirements, traceability matrix, test case summary |
| 03-test-unit.md | Details of all unit test cases (UT-001 ~ UT-XXX) |
| 03-test-integration.md | Details of all integration test cases (IT-001 ~ IT-XXX) |
| 03-test-e2e.md | Details of all E2E test cases (E2E-001 ~ E2E-XXX) |
Content Retained in Main Document:
- Test strategy description
- Coverage targets
- Complete traceability matrix (F → US → AC → Tests)
- Description of test case scope for each sub-document
Small Projects: If the number of test cases is small (<30), they can be merged into a single file .
03-test-cases.mdFor detailed templates, refer to:
- templates/test-cases-template.md
- templates/unit-test-template.md
- templates/integration-test-template.md
- templates/e2e-test-template.md
测试用例概览文档结构
Test Case Overview Document Structure
markdown
undefinedmarkdown
undefined测试用例:<功能名称>
Test Cases: <Feature Name>
1. 测试策略
1. Test Strategy
2. 覆盖率要求
2. Coverage Requirements
3. 追溯矩阵
3. Traceability Matrix
4. 测试用例汇总
4. Test Case Summary
undefinedundefined追溯矩阵
Traceability Matrix
追溯矩阵是核心产出,展示需求与测试、代码的完整关联。
The traceability matrix is the core deliverable, showing the complete association between requirements, tests, and code.
基础格式(设计阶段)
Basic Format (Design Phase)
markdown
| 功能点 | 用户故事 | 验收标准 | 单元测试 | 集成测试 | E2E测试 | 状态 |
|--------|----------|----------|----------|----------|---------|------|
| F-001 | US-001 | AC-001 | UT-001 | - | E2E-001 | ⏳ |
| F-001 | US-001 | AC-002 | UT-002 | - | E2E-001 | ⏳ |
| F-001 | US-002 | AC-004 | UT-003, UT-004 | IT-001 | - | ⏳ |markdown
| Feature Point | User Story | Acceptance Criterion | Unit Test | Integration Test | E2E Test | Status |
|---------------|------------|----------------------|-----------|------------------|----------|--------|
| F-001 | US-001 | AC-001 | UT-001 | - | E2E-001 | ⏳ |
| F-001 | US-001 | AC-002 | UT-002 | - | E2E-001 | ⏳ |
| F-001 | US-002 | AC-004 | UT-003, UT-004 | IT-001 | - | ⏳ |完整格式(开发阶段,含代码位置)
Complete Format (Development Phase, Including Code Locations)
代码位置由自动填充,基于代码中的/devdocs-sync --trace/@satisfies标注扫描。@verifies
markdown
| AC 编号 | 验收标准 | 测试编号 | 入口代码 | 测试代码 | 状态 |
|---------|----------|----------|----------|----------|------|
| AC-001 | 邮箱格式校验 | UT-001 | `src/user.ts:15` | `tests/user.test.ts:20` | ✅ |
| AC-002 | 密码强度校验 | UT-002 | `src/user.ts:15` | `tests/user.test.ts:35` | ✅ |
| AC-003 | 用户名唯一性 | UT-003 | `src/user.ts:15` | `tests/user.test.ts:50` | ⏳ |
| AC-004 | 发送验证邮件 | IT-001 | - | - | ❌ |Code locations are automatically populated by, based on scanning/devdocs-sync --trace/@satisfiesannotations in the code.@verifies
markdown
| AC ID | Acceptance Criterion | Test ID | Entry Code | Test Code | Status |
|-------|----------------------|---------|------------|-----------|--------|
| AC-001 | Email format validation | UT-001 | `src/user.ts:15` | `tests/user.test.ts:20` | ✅ |
| AC-002 | Password strength validation | UT-002 | `src/user.ts:15` | `tests/user.test.ts:35` | ✅ |
| AC-003 | Username uniqueness | UT-003 | `src/user.ts:15` | `tests/user.test.ts:50` | ⏳ |
| AC-004 | Send verification email | IT-001 | - | - | ❌ |代码位置字段说明
Code Location Field Description
| 字段 | 来源 | 说明 |
|---|---|---|
| 入口代码 | | 实现该 AC 的方法位置 |
| 测试代码 | | 验证该 AC 的测试位置 |
| Field | Source | Description |
|---|---|---|
| Entry Code | | Location of the method implementing this AC |
| Test Code | | Location of the test verifying this AC |
状态说明
Status Description
| 状态 | 含义 | 条件 |
|---|---|---|
| ✅ | 完整覆盖 | 有测试用例 + 入口代码 + 测试代码 + 测试通过 |
| ⏳ | 进行中 | 有测试用例,代码/测试部分完成 |
| ⚠️ | 部分覆盖 | 有代码但缺测试,或有测试但缺代码 |
| ❌ | 未覆盖 | 无测试用例或无代码实现 |
| Status | Meaning | Condition |
|---|---|---|
| ✅ | Fully Covered | Has test case + entry code + test code + test passed |
| ⏳ | In Progress | Has test case, code/test partially completed |
| ⚠️ | Partially Covered | Has code but lacks test, or has test but lacks code |
| ❌ | Not Covered | No test case or no code implementation |
矩阵维护流程
Matrix Maintenance Process
设计阶段 开发阶段 同步阶段
│ │ │
▼ ▼ ▼
生成基础矩阵 生成骨架代码(带标注) /devdocs-sync --trace
(AC → 测试编号) (入口 + 测试) │
▼
扫描代码标注
│
▼
填充代码位置列
│
▼
更新状态列Design Phase Development Phase Sync Phase
│ │ │
▼ ▼ ▼
Generate Basic Matrix Generate skeleton code (with annotations) /devdocs-sync --trace
(AC → Test IDs) (Entry + Test) │
▼
Scan code annotations
│
▼
Populate code location column
│
▼
Update status column测试用例格式
Test Case Format
单元测试用例
Unit Test Case
markdown
| 编号 | 验收标准 | 测试对象 | 场景 | 输入 | 预期输出 | 优先级 |
|------|----------|----------|------|------|----------|--------|
| UT-001 | AC-001 | validateEmail() | 有效邮箱 | "test@example.com" | true | P0 |
| UT-002 | AC-002 | validateEmail() | 无效格式 | "invalid" | false | P0 |markdown
| ID | Acceptance Criterion | Test Object | Scenario | Input | Expected Output | Priority |
|----|----------------------|-------------|----------|-------|-----------------|----------|
| UT-001 | AC-001 | validateEmail() | Valid email | "test@example.com" | true | P0 |
| UT-002 | AC-002 | validateEmail() | Invalid format | "invalid" | false | P0 |集成测试用例
Integration Test Case
markdown
| 编号 | 验收标准 | 测试场景 | 涉及组件 | 预期结果 | 优先级 |
|------|----------|----------|----------|----------|--------|
| IT-001 | AC-004 | 密码加密存储 | UserService + DB | 密码以 bcrypt 格式存储 | P0 |markdown
| ID | Acceptance Criterion | Test Scenario | Involved Components | Expected Result | Priority |
|----|----------------------|---------------|---------------------|-----------------|----------|
| IT-001 | AC-004 | Password encrypted storage | UserService + DB | Password stored in bcrypt format | P0 |E2E 测试用例
E2E Test Case
markdown
| 编号 | 用户故事 | 验收标准 | 操作步骤 | 预期结果 | 优先级 |
|------|----------|----------|----------|----------|--------|
| E2E-001 | US-001 | AC-001~AC-003 | 1. 打开注册页<br>2. 输入邮箱密码<br>3. 点击注册 | 注册成功,收到验证邮件 | P0 |markdown
| ID | User Story | Acceptance Criterion | Operation Steps | Expected Result | Priority |
|----|------------|----------------------|-----------------|-----------------|----------|
| E2E-001 | US-001 | AC-001~AC-003 | 1. Open registration page<br>2. Enter email and password<br>3. Click register | Registration successful, verification email received | P0 |覆盖率要求
Coverage Requirements
| 测试类型 | 覆盖目标 | 覆盖要求 |
|---|---|---|
| 单元测试 | 核心业务逻辑 | 行覆盖率 ≥ 80%,分支覆盖率 ≥ 80% |
| 集成测试 | 组件协作场景 | 每个功能点至少 1 个 IT |
| E2E 测试 | 用户故事 | 每个 P0 用户故事至少 1 个 E2E |
| Test Type | Coverage Target | Coverage Requirement |
|---|---|---|
| Unit Test | Core business logic | Line coverage ≥ 80%, branch coverage ≥ 80% |
| Integration Test | Component collaboration scenarios | At least 1 IT per feature point |
| E2E Test | User stories | At least 1 E2E per P0 user story |
约束
Constraints
追溯约束
Traceability Constraints
- 每个验收标准至少有 1 个测试用例覆盖
- 必须生成追溯矩阵
- 追溯矩阵必须覆盖所有 AC
- Each acceptance criterion must be covered by at least 1 test case
- Must generate a traceability matrix
- The traceability matrix must cover all ACs
用例设计约束
Test Case Design Constraints
- 测试用例必须关联验收标准编号
- 每个用例必须有明确的预期结果
- 优先级必须标注 (P0/P1/P2)
- Test cases must be associated with acceptance criterion IDs
- Each test case must have a clear expected result
- Priority must be marked (P0/P1/P2)
覆盖约束
Coverage Constraints
- P0 验收标准必须 100% 测试覆盖
- P0 用户故事必须有 E2E 测试
- 单元测试行覆盖率目标 ≥ 80%
- 100% test coverage must be achieved for P0 acceptance criteria
- P0 user stories must have E2E tests
- Unit test line coverage target ≥ 80%
质量约束(参考 /testing-guide
)
/testing-guideQuality Constraints (Refer to /testing-guide
)
/testing-guide- 测试名称必须描述预期行为
- 禁止弱断言(toBeDefined, toBeTruthy 不能作为唯一断言)
- Mock 只用于外部依赖
- Test names must describe expected behavior
- Weak assertions are prohibited (toBeDefined, toBeTruthy cannot be used as the only assertion)
- Mocks are only used for external dependencies
Skill 协作
Skill Collaboration
| 场景 | 协作 Skill | 说明 |
|---|---|---|
| 需求输入 | | 前置:提供 F/US/AC 作为测试设计依据 |
| 新功能测试 | | 被调用:新功能需要新增测试用例 |
| Bug 回归测试 | | 被调用:Bug 修复需要补充回归测试 |
| 改进测试 | | 被调用:改进建议可能需要测试覆盖 |
| 追溯更新 | | 协作:trace 模式更新追溯矩阵代码位置 |
| 测试质量 | | 协作:编写测试代码时的质量约束 |
| 任务拆分 | | 后续:测试用例转化为开发任务 |
| Scenario | Collaborating Skill | Description |
|---|---|---|
| Requirement Input | | Pre-requisite: Provide F/US/AC as the basis for test design |
| New Feature Testing | | Called: New features require additional test cases |
| Bug Regression Testing | | Called: Bug fixes require supplementary regression tests |
| Test Improvement | | Called: Improvement suggestions may require test coverage |
| Traceability Update | | Collaboration: Trace mode updates code locations in the traceability matrix |
| Test Quality | | Collaboration: Quality constraints when writing test code |
| Task Splitting | | Follow-up: Convert test cases into development tasks |
下一步
Next Steps
完成后建议运行 进行开发任务拆分。
/devdocs-dev-tasksAfter completion, it is recommended to run for development task splitting.
/devdocs-dev-tasks