什么才算是“好的”测试用例？
通常，你的第一反应很可能会是“发现了软件缺陷的测试用例就是好的用例”，我可能会反问你“如果说测试用例发现了缺陷就是好用例，那么在该缺陷被修复后，同样的用例难道就不是好用例了吗？”。
你可能还会说“发现软件缺陷可能性大的测试用例就是好用例”，这话看起来还是蛮有道理的，但是我同样会反问你“你打算用什么方法来量化测试用例发现缺陷的可能性？”。
类似地，你可能还会说“发现至今未被发现的软件缺陷的测试用例就是好用例”，那么我想问你的是：如何评估是否还存在未被发现的缺陷？如果软件中根本就没有错误了呢？
其实，是你定义“好的”测试用例的思路错了，这就有点像“傻子吃烧饼”，连吃五个不饱，吃完第六个终于饱了，于是他说：早知道吃了第六个就会饱，何必吃前面五个呢。细想，他吃的六个烧饼其实是一个整体，一起吃下去才会饱，而你无法找到吃一个就能饱的“好”烧饼。
对于测试用例其实也是同样的道理，“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。
一个“好的”测试用例包含以下三个特征
- 整体完备性： “好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。
- 等价类划分的准确性： 指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
- 等价类集合的完备性： 需要保证所有可能的边界值和边界条件都已经正确识别。
三种常用的测试用例设计方法
设计测试用例的方法很多，例如等价类划分法、边界值分析法、错误推测方法、因果图方法、判定表驱动分析法、正交实验设计方法、功能图分析方法、场景设计方法、形式化方法、扩展有限状态机方法等等，但对大多数的软件测试而言，综合使用等价类划分、边界值分析和错误推测这三大类方法就足够了。
- 等价类划分法
等价类中任意一个输入数据对于揭露程序中潜在错误都具有同等效果。后续我们只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
等价类划分方法的另一个关键点是要找出所有“无效等价类”。 使用等价类划分的方法设计测试用例不仅包含“有效等价类”也得包含“无效等价类”。
考试成绩0～100的整数，及格60分，其中有效等价类，0～59，60～100，无效等价类小于0，大于100，0～100之间浮点数，其他任意非整数字符。
- 边界值分析法
边界值分析是对等价类划分的补充，你从工程实践经验中可以发现，大量的错误发生在输入输出的边界值上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
对于考试成绩这个例子，边界值测试用例应该包含-1，0，1，59，60，61，99，100，101。
- 错误推测法
错误推测方法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。
如何设计一个“好的”测试用例
在真实的工程实践中，不同的软件项目在研发生命周期的各个阶段都会有不同的测试类型。
对于每一种不同的测试类型，设计出“好的”测试用例的关注点和方法论可能会有很大的差异，有些可能采用黑盒方法，有些可能采用白盒方法，有些还会采用灰盒方法（比如，微服务架构中的测试），所以很难有一套放之四海而皆准的套路。
深入理解被测软件需求的最好方法是，测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。
在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。
测试用例设计注意两点
- 从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。
- 对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。
用例设计其他经验
- 只有深入理解被测试软件的架构，你才能设计出“有的放矢”的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。
必须对内部架构有清楚的认识，比如数据库连接方式、数据库的读写分离、消息中间件 Kafka 的配置、缓存系统的层级分布、第三方系统的集成等等。
- 必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑。
在具体实践中，可以通过代码覆盖率指标找出可能的测试遗漏点。切忌不要以开发代码的实现为依据设计测试用例
- 需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。
https://time.geekbang.org/column/article/10150