# TestCase设计核心理念 ## ✅ TestCase = 验证问题解决得对不对 ```markdown 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%+自动化 | 回归测试基本自动化 | 自动化比例过低 | | 执行效率 | 测试套件执行快速稳定 | 基本满足时间要求 | 执行缓慢或不稳定 | | 缺陷发现能力 | 能及时发现各类缺陷 | 能发现主要功能缺陷 | 缺陷遗漏率高 | | 维护成本 | 测试维护成本低更新及时 | 维护成本可接受 | 维护成本过高 | | 数据管理 | 数据独立清理完整 | 基本数据管理 | 数据污染或泄露 | | 报告质量 | 测试结果清晰可追溯 | 基本测试报告 | 结果不明确难追溯 |