Files
PromptX/domain/scrum/execution/testcase-best-practice.execution.md

6.5 KiB
Raw Blame History

TestCase设计核心理念

TestCase = 验证问题解决得对不对

TestCase的本质验证问题解决方案的正确性
核心思考:这个问题真的被正确解决了吗?

问题导向框架:
📋 提问题层: Epic → Feature → Story (需求定义)
🛠️ 解决问题层: Task (技术实现)
✅ 验证层: TestCase (质量保证) ← 我们在这里
🎯 价值确认层: Milestone (交付确认)

TestCase的职责边界

  • 验证Story的验收标准是否达成
  • 确保Task的实现符合预期
  • 保证用户问题得到正确解决
  • 防止新问题的引入(回归测试)
  • 不重新定义需求或实现方案
  • 不改变Story的验收标准
# 测试用例设计流程
```mermaid
flowchart TD
  A[Story验收标准] --> B[确定测试层级]
  B --> C[设计测试用例]
  C --> D[准备测试数据]
  D --> E[执行测试验证]
  E --> F{测试结果}
  F -->|通过| G[Story验收]
  F -->|失败| H[缺陷修复]
  H --> E
  
  B --> B1[验收测试]
  B --> B2[集成测试]
  B --> B3[单元测试]
```

## 测试金字塔分层

```mermaid
graph TD
  A[手工探索测试 1%] --> B[UI自动化测试 9%]
  B --> C[集成测试 20%]
  C --> D[单元测试 70%]
  
  style D fill:#90EE90
  style C fill:#FFE4B5  
  style B fill:#FFA07A
  style A fill:#FFB6C1
```
### 测试用例设计方法
#### 1. 基于验收标准设计

```
验收标准 → 测试用例转换规则:
Given [前置条件] → 测试前置条件
When [用户操作] → 测试执行步骤  
Then [预期结果] → 测试预期结果
```

#### 2. 等价类划分策略

| 等价类类型 | 设计策略 | 示例场景 |
|----------|---------|---------|
| 有效等价类 | 正常业务流程 | 标准输入数据 |
| 无效等价类 | 异常处理验证 | 空值、超长、特殊字符 |
| 边界等价类 | 临界值测试 | 最大值±1、最小值±1 |

#### 3. 场景覆盖矩阵

```mermaid
mindmap
  root((测试覆盖))
    功能覆盖
      正常流程
      异常流程
      边界条件
    用户覆盖
      主要角色
      次要角色
      系统角色
    环境覆盖
      不同浏览器
      不同设备
      不同网络
    数据覆盖
      标准数据
      边界数据
      异常数据
```

### 测试用例标准模板

```markdown
## TC-{StoryID}-{序号}: {测试目标}

**前置条件**: 
- 环境状态
- 测试数据
- 用户权限

**执行步骤**:
1. [操作步骤] → [预期结果]
2. [操作步骤] → [预期结果]

**验证点**:
- [ ] 功能验证
- [ ] 界面验证  
- [ ] 性能验证
- [ ] 异常处理

**后置清理**: 清理测试数据
```

### 自动化测试策略

#### 自动化优先级排序

| 优先级 | 测试类型 | 自动化建议 | 维护成本 |
|--------|---------|----------|---------|
| 高 | 回归测试 | 必须自动化 | 低 |
| 高 | API接口测试 | 必须自动化 | 低 |
| 中 | 核心用户流程 | 推荐自动化 | 中 |
| 低 | UI细节测试 | 手工测试 | 高 |
| 低 | 探索性测试 | 手工测试 | - |

#### 自动化工具选型

```mermaid
flowchart LR
  A[测试需求] --> B{测试层级}
  B -->|单元测试| C[Jest/JUnit/PyTest]
  B -->|API测试| D[Postman/RestAssured/Cypress]
  B -->|E2E测试| E[Cypress/Playwright/Selenium]
  B -->|性能测试| F[JMeter/K6/Artillery]
```
1. **测试用例必要性原则** - 每个验收标准必须有对应测试用例 - 关键业务流程必须有端到端测试 - 边界条件必须有专门测试用例 - 异常处理必须有验证用例
2. **测试分层强制要求**
   - 单元测试覆盖率 > 80%
   - 集成测试覆盖关键API
   - UI测试仅覆盖核心用户流程
   - 手工测试聚焦探索和边界场景

3. **自动化测试规范**
   - 回归测试必须100%自动化
   - 自动化用例必须稳定可重复
   - 执行时间控制在合理范围
   - 失败时提供清晰错误信息

4. **测试数据管理规范**
   - 使用独立测试数据集
   - 实现自动化数据准备和清理
   - 避免测试用例间数据污染
   - 敏感数据必须脱敏处理
1. **时间约束** - 单元测试执行时间 < 10分钟 - 集成测试执行时间 < 30分钟 - UI自动化测试执行时间 < 2小时 - 手工测试在迭代时间盒内完成
2. **资源约束**
   - 测试环境资源有限
   - 自动化维护人力约束
   - 测试工具许可证成本
   - 测试数据存储空间限制

3. **技能约束**
   - 团队自动化技能水平
   - 测试工具熟练程度
   - 编程能力限制
   - 领域知识深度

4. **技术约束**
   - 被测系统架构限制
   - 第三方服务依赖
   - 网络环境稳定性
   - 浏览器兼容性要求
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 | |---------|---------|---------|-----------| | 覆盖完整性 | 覆盖所有验收标准和边界条件 | 覆盖主要功能场景 | 覆盖不足缺少关键场景 | | 用例设计质量 | 步骤清晰预期明确可重复 | 基本可执行有明确结果 | 步骤模糊或结果不明确 | | 自动化比例 | 关键流程90%+自动化 | 回归测试基本自动化 | 自动化比例过低 | | 执行效率 | 测试套件执行快速稳定 | 基本满足时间要求 | 执行缓慢或不稳定 | | 缺陷发现能力 | 能及时发现各类缺陷 | 能发现主要功能缺陷 | 缺陷遗漏率高 | | 维护成本 | 测试维护成本低更新及时 | 维护成本可接受 | 维护成本过高 | | 数据管理 | 数据独立清理完整 | 基本数据管理 | 数据污染或泄露 | | 报告质量 | 测试结果清晰可追溯 | 基本测试报告 | 结果不明确难追溯 |