如何设计“好的”测试用例，这一节让我把《软件测试价值提升之路》有关用例设计的观点梳理了一下，分享给大家。
1、什么是“好的”测试用例？
作者的认为，“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。
关于用例的“好坏”，可能有不同的定义和解释，但是基于现在的理解，我觉得用例完备是一个很重要的属性。
关于这个解释作者给了一个很生动的渔网的例子：
如果把测试用例比作渔网，缺陷比作鱼。如果渔网本身是完整的且合格的，那么捞不到鱼，可能是池塘中没有鱼，渔网的好坏与池塘中是否有鱼无关。
《软件测试价值提升之路》这本书也有渔网的图，里面讲到的是，用不同的网分层拦截的缺陷，有兴趣的可以看看。
2、“好的”测试用例必须具备哪些特征？
1）整体完备性
作者提到能够完全覆盖测试需求，并不是专指业务需求或功能需求。
2）等价类划分的准确性
这里其实就是指，你设计的等价类，是否真的等价。
3）等价类集合的完备性
这里指的就是，是否真的识别到所有的影响因子。
3、三种最常用的测试用例设计方法
用例设计的方法有很多，作者认为对大多数的软件测试而言，综合使用等价类划分、边界值分析和错误推测这三大类方法就足够了。
这里也解释了我一直以来的一个疑惑，这三种方法是我工作中最常用的方法，但有时感觉不够高大上，判定表、因果图等都没用过。这次的学习让我了解到，这个现象并不能说明存在问题。
4、如何才能设计出“好的”测试用例？
在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。
这里说明在用例设计阶段，测试分析是很重要的一个环节。正如《软件测试价值提升之路》这本书上也说到，缺陷遗漏大多数是测试分析的时候就没有考虑到，而不是测试执行环节出错。
具体操作时注意事项：
1）从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。
2）对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。
5、用例设计的其他经验
1）只有深入理解被测试软件的架构，你才能设计出“有的放矢”的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。
2）必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑。
3）需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。
个人观点，我是比较重视用例积累及用例设计能力的，面试时也会给一个场景查看面试者用例设计的能力，倒不是期望回答有多标准或完美，主要考核面试者的思维能力及设计用例的思路。
源自公众号 信小慧