不全将影响用例质量，冗余将影响我们的执行效率。在测试实践中，不漏的价值远大于不重。
接着说，因果图和判定表。
这俩经常在一起使用，所以放一起说。坦白说这么多年我也没见到谁用这俩的，我也不太会，所以一笔带过。
判定表是用来输出用例的。判定表包括输入和输出，它通过排列组合帮我们用正交的方式设计出了最多的用例。
因果图是用来帮助筛选掉不可能出现的组合，去掉判定表中的冗余的。
没事儿，不会无所谓，我也不会。（咦？那我为啥要说？）如果面试有这种题，直接说我不会算了。用不上的东西面个什么面。如果有人在生产中用上了，请在评论区留言，我很好奇什么场景需要？
然后是很有用的流程覆盖法。
我一直没看出来这个方法和白盒测试用例中的路径覆盖在原理上有什么不同，只不过一个是覆盖流程图，一个是覆盖逻辑结构，或者叫控制图？
这个方法是用来帮助我们结构化的保证针对复杂流程的用例的覆盖率的。简单说就是因为流程长而且步骤多，别执行着就给落下一段。
覆盖率可以任意选择，至少也要把流程中所有的步骤都保证覆盖，如果能达到路径覆盖，我也敬你是条汉子（男女通用）。
这个方法同样可以回答“全不全”的问题。
有了这些用例设计方法，你已经可以在之前的面试中自圆其说了。
很有趣的是，我曾经在我的一个回答里写过类似的内容，但是在评论区里，几个测试小伙伴饶有兴致的在你一个我一个的聊等价类。
论关于测试的理论与实际应用！（发散性思维的横向或纵向都行）？
对此我的回答是：不要这么思考问题，这是在穷举。等价类就是在避免穷举。你要先说，一共有多少，然后指明在哪一刀上砍出了数字和字符组合输入。
这个事情说明，穷举就是我们的本能，但是理性的思考能够帮助我们摆脱没头苍蝇一样的瞎蒙。当一个人回答问题的时候说，“首先，其次，最后”，他已经很有条理了，但是测试用例级别的理性要求测试人员张嘴应该是：“依据XXX划分一共有三点”。“一共”是一个有魔力的词，只有统揽全局的人才能说得出来，也只有这样的人，才对自己在做什么有着清醒的认识。
当然，穷举仍然能够帮助我们发现更多的用例。但是针对每一个被直觉发现的用例，你都应该更深入的问问自己，他到底属于哪个等价类，应该如何纳入到我的体系中来。往往这种用例都不是孤立的，它意味着我们的用例缺少一个庞大的等价类。
在我们使用测试用例设计方法选出这些备用的用例后，我们走完了第一步，接着我们要给他们排定优先级。排定优先级的原则我们已经讲过，叫做“客户导向”。
一般来说，所有客户必须且必然会使用的那些用例会作为用例中的最高优先级，也是用例中的骨干。这些骨干在某些团队会叫“BVT”用例；
其他的分支功能，以及可能引起严重事故的那些用例，可以作为下一梯队；
再往后，才是那些理论上需要验证的用例。
在这里，我们才呼应了文章的标题，关注价值。
验证与确认
传统的CMMI模型中，针对测试有两个相关的实践，一个叫验证（Verification），一个叫确认（Validation）。验证是指You build it right（功能正确性）。确认是指You build the right thing（业务正确性）。
简单说，验证就是你在过程中遵循了各种规范要求，它更多的是技术内部的合规；确认是说对于最终用户而言产品是有价值的，它更关注业务目标。
初级工程师学技术，更多的是在学习如何验证；中级工程师学业务，需要学习如何确认。
在软件开发的不同阶段，这两个实践也有不同的用途。在单元开发阶段，我们执行单元测试更多的是要验证这个单元是否合乎设计要求；但是到了用户验收阶段，我们需要关注用户是否可以使用产品完成关键业务。
这也就让我们在设计不同阶段的测试用例时，会选择不同的测试用例设计方法，例如：
- 单元测试阶段，我更建议使用白盒测试用例设计方法，针对程序的逻辑结构进行验证；
- 在组合测试阶段，我会建议使用黑盒测试测试用例设计方法中的等价类和边界值针对接口进行测试，并且应当优先保证确认那些关键业务的关键路径的用例；
- 在系统测试和UAT阶段，我建议使用流程覆盖法针对业务流程进行完整确认。
那么，这两个实践相比，哪个更加重要一些呢？从客户导向的角度，我认为确认更加重要。
如果资源不足，我只能执行一轮测试，我会选择业务流程确认。我也许会让我们的测试人员和我们的最终用户一起验收产品。
这也是因为，只有产品满足了关键业务，我们的产品才对用户产生了价值。一个无法产生价值的产品上线是没有意义的，还不如藏起来。测试人员也应当以为用户产生价值为目的，以客户导向为原则，设计测试用例，安排测试计划。
测试人员的绩效体系设计也应当遵循这样的原则。
到这里，测试用例基本上讲完了。这篇文章有专业知识，也有大量的价值观内容。我认为其中价值观部分的价值远大于知识部分，不知道看到这里的你，是否也有同样的感受呢？
源自公众号 价值驱动软件测试