如何评估特性测试用例的充分性？

测试用例是测试人员的测试设计关键输出，测试人员经常被问的一个问题就是“你设计的测试用例充分吗？”或者“你的测试用例是如何保证起充分性的？”。那么我们测试人员如何回答这个问题呢？用测试用例评估可以吗？比如“这特性，我设计了300个测试用例，所以是充分的？”。用积累的测试基线来评估？比如“我们的基线是XX个用例，这个特性代码估计有10K。因此设计了XX0个用例，所以是充分的？如何评估特性测试用例的充分性，比较困难，尤其对测试新手来说。本文阐述一种思路，评估测试用例的思路。是在日常测试工作中，用于针对测试用例设计和评估充分性的一种方法，写出来，供大家参考。

本文采取日常生活的有关个人银行业务的案例作为辅助说明，为了简化，所列举的例子，并不是一个完整的测试用例设计过程，只是用来阐明思路。

我的方法就是构建完备的测试特性树，及其如何组织测试用例，通过这两个步骤再去评估测试用例充分性。涉及到的设计方法有分层法和测试类型。

首先是分层法，这个方法是分类法和特性建模两种方法的综合。分类法，我们并不陌生，到处可见。学习生物学的时候，就见过下面或类似下面这个图：

全球的生物至少千万，每个生物都有各自的属性，有自己的特点。我们的科学家如何描述生物呢？他们用了上面这幅简单的图，就把这千万种给概括了。先看这颗树的最根处，把生物分为动物界和植物界，当然这幅图不完整，对于菌既不是属于动物界，也不属于植物既，我们知道菌是被命名为真菌界，这个是后来加的，这种方法是根据生物相似但特点来划分的，虽然每个生物之间的差异往往比较大，但很多物种之间相似点很多，这样就可以归类。比如：猫科包括猫属和豹属，猫属下有猫和虎，猫下面还有等等，要描述清猫种就容易得多了，即使有得新多猫种被发现，也不会打乱这颗树。

对于我们的系统来说，有时也很复杂，也有很多大的特性，还有小的特性，但远没有生物种类那么复杂。使用类似生物学上但分类法，足以胜任了。我们参考生物学上的分类法，来描述我们系统的特性。比如个人银行业务，整理出来的树如下（再次说明，这颗树不是完整的）：

我们把系统的特性树建起来，比较容易阐述系统。系统设计人员往往会开发系统场景说明书，可以按照场景说明书来设计特性树。如果没有，就得自己使用特性建模的方法了，把用户应用场景都分析一遍。

使用特性树可以把系统的应用场景给描述清楚。下一步就是把你的测试用例描述清楚。测试用例有成千上万，测试用例有很多属性。其中有一个属性很有用，这个属性就是测试类型，意思就是做类型的测试，比如功能测试，性能测试等等。常见的测试用例类型如下（这里不是完整列表，这是列举）：

用这个图（需要完整的），就可以把你所有的测试用例进行分了个类。你需要做的就是确定被测试的特性需要做哪些类型的测试，有一点可以肯定，测试不是超出这个范围的。这个方法，确定了特性的测试范围。

现在我们把上述两个图给综合成一起，把测试类型放到最后一层特性的节点上，如下图所示：

测试类型有很多，但肯定会有一个范围的，有些特性（细化到最小那个）不需要做完整的测试类型，把不需要给删掉（评审的时候，说明即可）。每个系统的测试类型比较固定，不同系统，测试类型可能会不一样，但会有所侧重。比如单机版的工具类被测系统，是不需要性能测试类型的，可以删除。

上述两大步，我们是能够把特性的上百上千的测试用例给讲清楚，无论测试用例有多少，分解到单个测试类型，其实没有多少个测试用例了。根据经验，上述每个类型的最后一层节点，设计出来的测试用例最多不超过20个。

开发人员一般都会进行单元测试或子系统测试，测过了才交给测试人员。开发做了一定的测试，特性的基本功能出现的问题大大降低了。受限于岗位的特点，开发一般偏重于正常场景的验证（因人而异），异常场景覆盖比较少。所以，我觉得测试人员的测试用例更偏重于异常用例才对。在用例设计过程中，我会把异常测试用例统计出来，看看异常用例数占总用例数的比例。这个比例越高，我觉得用例设计的越充分。这个比例，我认为异常测试用例占总用例数的比例为50～70％，是比较合适的。

通过分层方法构建特性树（每个特性尽可能正交），测试类型作为特性树中最小特性的子节点，测试用例挂在测试类型上，再给出异常用例占比，作为评估测试用例的依据。好处场景不易丢失，也比较容易说清楚，缺点是可能会出现冗余测试用例。

评估测试用例的充分性，很多时候比较主观，但不能撂摊子，不去评估。你可以试试使用这里说明的思路，给周边的同事讲解你的测试设计，看看效果如何。没有任何限制，任何产品任何阶段，都可以采用。哪怕是单元测试用例，都是可以使用这种方法。只不过的被测系统是函数级别的而已。