辽宁省网站建设_网站建设公司_ASP.NET_seo优化

目录

• • 一、测试用例开发的总体方法论框架
  • 二、第一性原则：先建「覆盖模型」，再写用例
  • • 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）测试用例设计决策树（快速选方法）