02-如何设计一个“好的”测试用例？

本人在“极客时间”上购买了一套“软件测试52讲”的课程，本文为该课程第二节《02 | 如何设计一个“好的”测试用例？》的课程笔记及自己的一些思考。

---

为了保证软件系统的质量，测试用例的设计不仅需要考虑功能性需求，还要考虑大量的非功能性需求。

1. 什么才是“好的”测试用例？

• 发现了软件缺陷的测试用例就是好的用例（X）
  如果说测试用例发现了缺陷就是好用例，那么在该缺陷被修复后，同样的用例难道就不是好用例了吗？

• 发现软件缺陷可能性大的测试用例就是好用例（X）
  你打算用什么方法来量化测试用例发现缺陷的可能性？

• 发现至今未被发现的软件缺陷的测试用例就是好用例
  如何评估是否还存在未被发现的缺陷？如果软件中根本就没有错误了呢？

• “好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。
  如果把被测试软件看作一个池塘，软件缺陷是池塘中的鱼，建立测试用例集的过程就像是在编织一张捕渔网。“好的”测试用例集就是一张能够覆盖整个池塘的大渔网，只要池塘里有鱼，这个大渔网就一定能把鱼给捞上来。
  如果渔网本身是完整的且合格的，那么捞不到鱼，就证明池塘中没有鱼，而渔网的好坏与池塘中是否有鱼无关。

2. “好的”测试用例必须具备哪些特征？

• 整体完备性： “好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。
• 等价类划分的准确性： 指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
• 等价类集合的完备性： 需要保证所有可能的边界值和边界条件都已经正确识别。

3. 三种最常用的测试用例设计方法

• 常见的测试用例设计方法：等价类划分法、边界值分析法、错误推测方法
  因果图方法、判定表驱动分析法、正交实验设计方法、功能图分析方法、场景设计方法、形式化方法、扩展有限状态机方法等等，

• 从软件企业实际的工程实践来讲，真正具有实用价值并且常用的只有前三种方法。

• 对大多数的软件测试而言，综合使用等价类划分、边界值分析和错误推测这三大类方法就足够了。

（1）等价类划分方法

• 我们只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
• 等价类划分方法的另一个关键点是要找出所有“无效等价类”

（2）边界值分析方法

• 边界值分析是对等价类划分的补充，你从工程实践经验中可以发现，大量的错误发生在输入输出的边界值上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
• 我们继续看学生信息系统中“考试成绩”的例子，选取的边界值数据应该包括：-1，0，1，59，60，61，99，100，101。

（3）错误推测方法

• 错误推测方法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。

4.如何才能设计出“好的”测试用例？

• 在真实的工程实践中，不同的软件项目在研发生命周期的各个阶段都会有不同的测试类型。

  • 比如，传统软件的开发阶段通常会有单元测试，软件模块集成阶段会有代码级集成测试，打包部署后会有面向终端用户的 GUI 测试；再比如，电商网站的测试会分为服务器端基于 API 的测试、中间件测试、前端 GUI 测试等。
  • 对于每一种不同的测试类型，设计出“好的”测试用例的关注点和方法论可能会有很大的差异，
  • 有些可能采用黑盒方法，有些可能采用白盒方法，有些还会采用灰盒方法（比如，微服务架构中的测试），所以很难有一套放之四海而皆准的套路。

• 在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。

• 具体到测试用例本身的设计，有两个关键点需要你注意。

  • 从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。 比如，如果你没有识别出用户登录功能的安全性测试需求，那么后续设计的测试用例就完全不会涉及安全性，最终造成重要测试漏洞。
  • 对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。 这里需要注意的是，要综合运用这三种方法，并针对每个测试需求点的具体情况，进行灵活选择。

5. 用例设计的其他经验

• 只有深入理解被测试软件的架构，你才能设计出“有的放矢”的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。
  作为测试工程师，切忌不能把整个被测系统看作一个大黑盒，你必须对内部的架构有清楚的认识，比如数据库连接方式、数据库的读写分离、消息中间件 Kafka 的配置、缓存系统的层级分布、第三方系统的集成等等。
• 必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑。
• 需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。

6. 总结

• 你需要明白，“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而能否发现软件缺陷并不是衡量测试用例好坏的标准。
• 设计测试用例的方法有很多种，但综合运用等价类划分、边界值分析和错误推测方法，可以满足绝大多数软件测试用例设计的需求。
• “好的”测试用例在设计时，需要从软件功能需求出发，全面地、无遗漏地识别出测试需求至关重要。
• 如果想设计一个“好的”测试用例，你必须要深入理解被测软件的架构设计，深入软件内部的处理逻辑，需求覆盖率和代码覆盖率这两个指标可以帮你衡量测试执行的完备性。