目录
- 一、测试用例开发的总体方法论框架
- 二、第一性原则：先建「覆盖模型」，再写用例
- 1）覆盖模型有哪些（通用）
- 三、用例颗粒度怎么把握：1 个用例还是多个用例？
- 1）一个好用例的“边界”
- 2）什么时候拆成多个用例
- 3）什么时候合并成一个用例（可以）
- 四、推荐的颗粒度分层模型：L1 / L2 / L3
- L1 场景用例（Scenario / End-to-End）
- L2 功能用例（Functional / Feature）
- L3 约束/异常/边界用例（Robustness / Negative / Boundary）
- 五、通用测试用例设计方法论：8 大方法（互补组合）
- 1）基于需求的测试（Requirements-Based Testing）
- 2）等价类划分（Equivalence Partitioning）
- 3）边界值分析（Boundary Value Analysis）
- 4）状态迁移测试（State Transition Testing）
- 5）决策表测试（Decision Table Testing）
- 6）组合测试 / Pairwise（Orthogonal Testing）
- 7）异常 / 负向测试（Negative Testing）
- 8）探索式测试（Exploratory Testing）
- 六、如何组合这些方法（关键）
- 七、防漏的核心：风险驱动测试（RBT）
- 风险三要素（通用）
- 用途
- 八、如何确保“测得全面、不漏问题”：一套可落地流程
- 1）先做“覆盖模型”，再写用例（防漏的关键动作）
- 2）通用用例开发流程
- 九、用例颗粒度的通用判定原则
- 十、颗粒度到底在权衡什么？
- 十一、一个用例应该只做“一件事”吗？更准确的定义
- 十二、颗粒度拆分与合并的硬规则
- 1）拆分的硬规则（一票否决）
- 1.1 失败不可唯一定位 → 必拆
- 1.2 前置条件不同 → 必拆
- 1.3 期望结果跨维度 → 必拆
- 1.4 可并行执行 → 倾向拆
- 2）合并的硬规则（同样重要）
- 2.1 前置昂贵（setup dominating cost）→ 倾向合并
- 2.2 自然闭环流程 → 可以合并成场景用例
- 2.3 一次运行可产出多个证据 → 倾向合并
- 十三、颗粒度“量化”评分法（评审很好用）
- 十四、常见陷阱与修复
- 陷阱 A：把一个用例写成“测试脚本”
- 陷阱 B：为了“数量好看”过度拆分
- 陷阱 C：把性能/稳定性揉进功能用例
- 十五、一套可直接落地的颗粒度规范
- 功能回归用例（L2）建议约束
- 异常/故障用例（L3）
- 场景用例（L1）
- 十六、断言（Assertion）：让用例可定位、可执行的关键
- 1）什么是断言——一句话定义
- 2）断言 ≠ 期望结果（常见混淆）
- 3）断言的三要素（工程级）
- 4）断言在用例中的位置（非常重要）
- 5）断言按层次分类（通用）
- 6）断言与颗粒度的关系（核心）
- 7）好断言 vs 坏断言
- 8）断言设计的常见坑
- 十七、《测试用例设计方法论 Checklist / 决策树》
- 1）测试用例设计 Checklist（防漏清单）
- ✅ 覆盖模型检查（写用例前必须过）
- ✅ 方法论组合检查（避免单一思维）
- ✅ 风险优先级检查（资源不足时）
- ✅ 用例颗粒度检查（最常见问题）
- ✅ 可执行性与证据检查（防“假通过”）
- 2）测试用例设计决策树（快速选方法）
在测试实践中，测试人员常常面临两个高度相关的问题：
测试用例的颗粒度如何把握？
是一个功能写一个用例，还是多个功能合并到一个用例？
用例拆得太细，维护成本高；拆得太粗，又难以定位问题。是否存在通用的测试用例开发方法论？
能够适用于不同项目、不同技术栈，并且在资源有限的情况下，尽可能做到测试全面、不漏关键问题。
这两个问题本质上指向同一个核心：
如何用“系统性的方法”，设计“可执行、可维护、覆盖充分”的测试用例集合。
用例颗粒度要服务于“可定位、可维护、可覆盖、可复用”，而方法论要服务于“系统性覆盖 + 风险优先 + 可追溯”。
一、测试用例开发的总体方法论框架
测试用例 = 覆盖模型 × 设计技术 × 风险优先 × 可执行性
任何一个成熟团队，最终都会落在这 4 个支柱上：
- 先建覆盖模型（Coverage Model）—— 不建模型一定漏
- 用多种设计技术组合—— 单一方法一定有盲区
- 风险驱动优先级—— 资源永远不够
