“好的”测试用例
曾经看到“好的测试用例”定义是：
发现至今未被发现的软件缺陷的测试用例
看完这句话后，想到几点：
- 难道发现缺陷的测试用例不是好的用例吗？
- “至今未被发现”基于多少次的测试才能呢？
3.真的发现“至今未被发现”的缺陷，修复优先级高吗？
“傻子吃烧饼”故事能说明上面“好的”测试用例的定义是不正确。“傻子吃烧饼”故事大概是傻子连吃5个烧饼不饱，吃完第6个终于吃饱了，于是他说：“早知道吃了第6个就饱的话，只吃第6个就可以了”。
6个烧饼是个整体，少一个也不能吃饱。“好的”测试用例是一个集合，而非是一个测试用例，这个集合能够覆盖所有等价类以及各种边界值，跟能否发现缺陷无关。
要设计好的测试用例，需要知道好的测试用例有哪些特征，要知其然知其所以然。“好的”测试用例必须具备特征如下：
- 整体完备性。是一个完备整体，能够完全覆盖测试需求。
- 等价类划分的准确性。正确划分等价类，在每个等价类任意选取一个值能测试通过，在这个等价类区间内选取一个值也能测试通过。
- 等价类集合的完备性。确定所有可能边界值和边界条件。
常用三种设计测试用例的方法
在书籍上看到有很多种测试方法，例如：等价类划分法、边界值分析法、错误推测法、因果图方法、判定表驱动分析法、正交实验设计方法等等。
最常用三种设计测试用例方法：等价划分法、边界值分析法、错误推测法。在网上很容易找到这些方法介绍，就不具体介绍，作者也写一篇等价类划分法，有需要的可以点进去看看。
怎样设计出“好的”测试用例？
在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。
上面这句话有点绕，摘取中心词画出流转关系，就会好容易理解：
业务需求—》软件功能需求—》测试需求—》测试用例
在《软件测试52讲》01|你真的懂测试吗？从“用户登录”测试--感悟，讲到“用户登录”测试用例。分别有功能测试用例、安全性测试用例、兼容性测试用例、性能测试用例。以“用户登录”为例，设计用例过程如下：
从上面的看出，测试需求决定测试用例，需要全面地、无遗漏地识别出测试需求。每个测试需求点需要综合运用等价类划分、边界值分析和错误推测的方法设计测试用例。
如果从软件功能需求直接设计测试用例，缺少测试需求分析的步骤。容易出现遗漏某部分测试用例设计，不能得出“好的”测试用例的完备集合。
文章主要讲述三方面内容：1.对“好的”测试用例的定义；2.常用软件测试方法；3.在设计测试用例时需要把业务需求转化为软件功能需求，再到转化为测试需求。
参考：
茹炳晟《软件测试52讲》02|如何设计一个“好的”测试用例
