这个问题之前测试业界的一位大神“茹炳晟”曾经专门谈过，在这里再给大家总结一下。
在讨论具体什么是“好的”测试用例之前，咱们必须明确定义什么是“好”，否则毫无意义。其实这是一个看似简单实则难以回答的问题，可能很难有非常标准的答案。
在测试的业界，曾经有很多关于“好的”测试用例的定义，比如“发现了软件缺陷的测试用例就是好的用例”，那我可能会反问你一句：比如一个用例之前发现了一个缺陷，但这个缺陷被关闭了，难道这个用例就不是好用例了？或者又有人说，“发现软件缺陷的可能性比较大的测试用例就是好用例”，那这个可能性究竟多大，该怎么来衡量？还有一种常见的说法是，“发现至今未发现的缺陷就是好用例”，那么如何评估是否还存在未被发现的缺陷？如果软件中根本就没有错误了呢？
如果咱们都按照这种思路来去寻找所谓的“好的”测试用例，那其实我们的思路就错了。这就有点类似于“傻子吃烧饼”，连续吃5个吃不饱，吃第6个吃饱了，他后悔了，早知道我就不吃前5个了，直接吃第6个就好了。其实，大家都明白，这6个烧饼是一个整体，少了哪一个，都没法达到最终这个效果，我们无法找到吃一个就能饱的“好”烧饼。
对于测试用例而言，其实也是同样的道理，“好的”测试用例一定是一个完备的集合，它能够覆盖所有业务逻辑中定义的约束和限制，确保重要的业务逻辑都能被测到，而跟是否发现缺陷是无关的。
如果我们把被测软件看做是一个池塘，缺陷就是这个池塘中的鱼，那建立测试用例集的过程就像是在编织一张捕鱼网，“好的”测试用例集就是一张能够覆盖整个池塘的大渔网，只要池塘里面有鱼，这个大渔网就一定能把鱼给捞上来。如果渔网本身是完整的且合格的，那么捞不到鱼，就证明池塘中没有鱼，而渔网的好坏与池塘中是否有鱼无关。
基本道理大家明白了，那“好的”测试用例必须具备哪些特征呢？
一个"好的"测试用例，必须具备以下三个特征：
1. 整体完备性：“好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试业务需求。
2. 等价类划分的准确性：指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
3. 等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别。
做到了以上三点，就可以肯定测试是充分且完备的，即做到了完整的测试需求覆盖。
那么如何才能真正设计出“好的”测试用例呢？
这就要求我们在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计用例。
这其中有几个关键点，
1. 从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的覆盖率。比如，如果你没有识别出用户登陆功能的安全性测试需求，那么后续设计的用例就完全不会涉及安全性，最终造成重要的测试漏洞。
2. 对于识别出的每个测试需求点，需要综合运用等价类、边界值和错误推测法来全面地设计用例。
3. 只有深入理解被测软件的架构，才能设计出“有的放矢”的测试用例集，去发现系统边界及系统集成上的潜在缺陷。
4. 必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑。
5. 需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。
相信以上总结大家对于什么是好的测试用例，已经有了很清晰的认识，这里就不跟大家啰嗦了，如果还有这方面的疑问，欢迎私聊，研讨~