测试设计

WHAT - 什么是测试设计

在定义什么是测试设计之前，先定义几个名词：

测试因子：也称为测试变量，相当于待测对象的输入。

测试场景：所有测试变量的特定组合，是测试用例的前提条件。

预期结果：在特定测试场景下，我们预期会得到的结果。

测试用例：一个测试场景和一个预期结果的组合，就是一个测试用例。

在有了上面的基本概念以后，我们可以把测试设计定义为：预先规划测试用例，设计测试场景，定义测试变量和预期结果的过程。

从不同的维度，我们可以将测试分为不同的类别。

根据系统层级的不同，可以分为集成测试、功能测试、单元测试。单元测试是指针对某个函数或一个子功能进行的测试，功能测试是针对一个完整功能的测试，集成测试是从用户的角度，对所有功能进行的整体测试。很多文章可能在这里定义不一样，但大体思路都是一样的，只是层级划分的范围不一样而已。

根据观测指标的不同，可以分为功能测试和压力测试。功能测试的目的是保证功能符合预期，压力测试的目的是保证在使用量增大的情况下，系统运行正常。

根据测试对象的不同，可以分为黑盒测试和白盒测试。黑盒测试指的是，将整个待测对象作为一个整体，不关注其内部实现，只是从输入输出的组合来进行测试。白盒测试指的是，根据系统内部实现进行测试，主要是保证测试的代码覆盖率。

WHY - 为什么要做测试设计

1. 全盘规划，不重不漏

将我们规划的测试用例输出到文档里，可以从全局的角度审视我们的测试设计。对于那些重要或复杂的点，可以多规划几个测试用例；对那些相近的场景，可以进行测试场景合并。测试用例多，测试就更充分，但需要投入的工作量也越多；测试用例越少，虽然能快速完成测试，但可能很多场景都没覆盖到。整体质量和效率，需要从全局的角度来考虑。

2. 好记性不如烂笔头

从测试的角度来说，一个系统(或一个功能)可以被看作是一个具有特定输入输出的盒子。系统的功能越复杂，这个盒子的输入输出组合就越多，最终导致测试用例的数量规模将成指数级增长。对于一个大型的系统来说，将所有的测试用例都装进我们的脑子里，这显然是不可能的。更何况，我们在工作中很难有大块的完整时间来完成一整个测试，因此必须将测试涉及落入到文档中。我们需要做哪些测试，哪些已完成，哪些有问题，哪些还未测试，都需要落到文档中。

3. 用于排优先级

大部分时候，我们都没有足够的时间做完所有的测试。一个未经过完整测试的功能，我们敢不敢上线？上线后心里虚不虚？假如我们做了测试设计，并且已经做完了所有的中高优先级测试，那我们上线的时候心里就可以不虚了，至少我们知道可能会出什么问题，出问题后我们知道该如何挽救。

还有时候，我们幸运的协调到了其他同事来协助我们测试，但问题是其他同学不熟悉这块功能，我们敢不敢将这块测试交给他？如果排了优先级，我至少敢将低优先级的交给他。

4. 过程资料，方便归档和回溯

这里不再详细展开。

HOW - 如何做测试设计

这里我们主要关注黑盒功能测试。在做测试设计时，主要有两个方法：边界值分析和测试因子分析，通常我们都是结合起来使用。

步骤一：测试因子分解

这一步的目的是找出所有影响测试结果的测试因子。测试因子的全面性是第一原则，在测试因子足够全面后，尽量保证测试因子的正交。

在这一步中，我们还需要罗列出该测试因子的所有可能取值。有时一些因子的范围是一些区间，区间内的可能取值是无穷的，这时候就需要用到边界值分析法。如果在一个区间段内的取值，对测试结果不会造成本质的差异，那我们从该区间中随意选取一个值，就能保证对这个区间的测试场景覆盖。如果无法确定边界值的影响，我们还可以将边界值也列入测试因子的待测取值中。

例如：某功能根据用户的不同年龄会有不同的输出，其中对于未成年人(age<18)，输出A；对于中年人(18 <=age<60)，输出B；对于老年人(60<=age)，输出C。那么我们可以得到"年龄"这个测试因子的如下待测取值：[16,30,62]，其中16覆盖了未成年人，30覆盖了中年人，62覆盖了老年人。还可以将边界值加入待测区间，那么最终的待测区间就是：[16,18,32,60,62]。那么该测试因子的整个取值范围都被覆盖到了。

步骤二 测试因子组合

在上一步中，我们得到了一大堆测试因子和他们的待测区间。在这一步中，我们要把这些因子的待测值组合起来。

例如，在上一步中我们得到的测试因子和待测区间为：年龄[16,18,32,60,62]，性别[男,女]，身高[160,175, 190]，那么组合起来的全量测试场景(年龄*性别*身高)就有5*2*3=30种：

步骤三 场景梳理

在上一步中我们得到了全量的测试场景，现在我们再对这些场景做一下梳理。

首先，有些场景是可以进行合并的，比如部分场景拆分的过细，我们很难构造不同的用例；比如有些测试因子不够正交，不同的输入得到了相同的结果。如果这些场景的输入组合在逻辑上是等价的，我们就可以进行合并。例如我们要测试文件上传功能，我们有文件[a.txt，b.txt]，大小[10k，20K]，由于不同文件内容不影响上传，所以我们可以将A.txt+10k和b.txt+10k的场景合并，20k同理。

其次，我们需要给每个用例定义一个TestName，并对列出每个场景的预期结果。如果需要的话，我们还可以给测试用例排个优先级。

一个例子

我们需要存储用户的睡眠数据，用户的一条睡眠数据包含[StartTime、EndTime、Level]三个属性。假设现在数据库中已经存在了一些数据，客户端又上传了一些新数据，我们要实现一个功能，将新旧数据合并起来。主要功能要求为：

• 如果两条数据时间是独立的(没有重合) ，则将两条数据都存下来；
• 如果两条数据时间有重合且Level相同，则新数据的时间为两条数据时间的并集，保持Level不变；
• 如果两条数据时间有重合但Level不同，返回一个错误；

测试因子分解

测试因子组合

场景梳理

在上一步中，我们得到了 6 * 4 * 2 = 48种场景，但很多场景实际上并不存在(比如三个等号，即四个时间都相等，实际并不存在这种情况)，我们将这些场景剔除后，得到了以下的测试用例：