测试用例的设计

概念

把测试点进行加工，如将测试点“去重”（去掉重复的内容）、“合并”（合并太细的测试点）、“细化”（具体化太泛的测试点），然后再确定各个测试点的测试条件、测试数据和测试结果，这样产生的就是测试用例。在这个过程中使用的方法就叫测试设计方法。路径分析法、判定表、正交分析法、等价类、边界值等都是常见的测试设计方法。

测试点方向分类

1.功能性（功能测试）
2.效率（性能测试）
3.可维护性（可维护性测试）
4.可移植性（可移植性测试）
5.易用性（易用性测试）
6.可靠性（可靠性测试）

测试用例设计的四个步骤

1.建模

建模分为四类，具体如下：

（1）流程

可以绘制“流程图”来建立测试模型。

四步法

• 通过绘制业务流程图来建模
• 路径分析法
  模型建立好之后（即绘出了流程图），就会使用路径分析法覆盖这个流程图，设计基础测试用例。
  所谓路径分析法就是指对能够覆盖流程的各种路径进行分析，得到一个路径的集合，测试时我们只需要按照这个路径集合进行测试即可。常见的覆盖策略有语句覆盖、分支覆盖、全覆盖和最小线性无关覆盖。
  1）语句覆盖
  语句覆盖，又称行覆盖，段覆盖，基本块覆盖是指覆盖系统中所有判定和过程的最小路径集合。语句覆盖常常被人指责为“最弱的覆盖”，它只管覆盖代码中的执行语句，却不考虑各种分支的组合等等。
  2）分支覆盖
  分支覆盖，又称判定覆盖，是指使得程序中每个判断的取真分支和取假分支至少经历一次，即判断的真假均曾被满足。
  3）全覆盖
  全覆盖是指100%地覆盖系统多有可能的路径的集合。
  4）最小线性无关覆盖
  全覆盖路径中有很多被重复执行的路径，最小线性无关覆盖保证流程图中每个路径片段都能够被至少执行一次，去掉了重复执行的路径。

（2）参数

可以通过“输入-输出表”来建立测试模型

四步法

• 使用“输入 -输出表”建模
  “输入 -输出表”是一张分析测试点在某种条件下，特定的“输入”会有怎样“输出”的表。

  
  
  输入-输出表
  
  

  “输入-输出表”的优势就是适合测试点的多个参数之间存在相互关系，需要对这些参数进行“组合”分析的情况。

• 覆盖“输入 -输出表”，完成测试用例
  在建立“输入 -输出表”的时候，会充分考虑各个参数之间的关系和他们的约束条件，所以在覆盖“输入 -输出表”的时候，会进行100%的覆盖，即将“输入 -输出表”的每一行作为一个测试用例。
• 根据经验补充测试用例
  为了让测试更有效，我们可以根据经验再补充一些测试用例，如是否需要考虑一些别的“条件”？有哪些地方容易出问题，是否需要补充一些测试用例？

（3）数据

可以通过“等价类分析表”来建立测试模型

四步法

• 等价类和边界值
  1）等价类划分，就是将测试的范围划分成几个互不相交的子集，他们的并集是全集，从每个子集选出若干个有代表性的值作为测试用例。
  　　例如，我们要测试一个用户名是否合法，用户名的定义为：8位数字组成的字符。
  　　我们可以先划分子集：空用户名，1-7位数字，8位数字，9位或以上数字，非数字。
  　　然后从每个子集选出若干个有代表性的值。
  2）边界值分析法：选出的测试用例，应选取正好等于、刚刚大于、刚刚小于边界的值，例如，对于在区间min，max的值，测试用例可以记为min，min+，max，max-。
• 覆盖等价类分析表完成测试用例
  我们在建立等价类分析表的时候，已经对输入数据分好了类。接下来我们就需要对这些分析好的等价类进行“边界值”分析，确定具体的测试数据，生成测试用例。
• 根据经验补充测试用例
  为了让测试更有效，我们可以根据经验再补充一些测试用例，如是否要在“等价类”中增加一些除“边界值”之外的测试数据？有哪些地方容易出问题，是否需要补充一些测试用例？

（4）组合

可以通过“因子表”来建立测试模型，使用“正交分析法”来生成测试用例。

四步法

• 使用“因子表”来建模
  “因子表”是一张分析测试点需要考虑哪些方面，并且这些方面需要包含哪些内容的表。有时候因子之间可能存在一定的约束关系，如因子A取值为A1的时候，因子B只能取值B1；因子A取值为A2的时候，因子B只能取值B2、B3、B4.

  
  
  因子表
• 根据“因子表”进行合并为测试用例
• 根据经验补充测试用例
  为了让测试更有效，我们可以根据经验再补充一些测试用例，如是否需要增加因子取值组合？有哪些地方容易出问题，是否需要补充一些测试用例？

2.设计基础测试用例

根据第一步建立好的测试模型设计一些基础测试用例，覆盖测试模型。
基础测试用例和测试用例的区别在哪呢？测试用例确定了测试条件（类似“在XX情况下，进行XX的测试”的描述）和测试数据（输入的“参数值”或者数值），而基础的测试用例仅仅只确定了测试条件。
当然对游戏测试用例设计方法来说，可以在覆盖模型的同时就确定了测试数据，这时得到的就是测试用例，这样就不再需要进行第三步了。

3.补充测试数据，完善测试用例

这一步主要是为基础测试用例确定测试输入，补充测试数据，这时基础测试用例就是就升级为测试用例了。

4.扩展补充

模型不能涵盖所有的测试点，不能解决测试设计的所有问题，我们还需要根据测试经验，对容易发生缺陷的地方进行补充测试用例，增加系统的有效性。

• 是否要增加一些需要覆盖的路径
• 是否要增加一些测试数据
• 有哪些地方是容易出问题的，是否还需要补充一些测试用例

测试用例模版

测试用例模版

• 测试用例编号：测试用例的唯一标记。
• 用例标题：概述测试用例的主要内容，明确该测试用例的意图。
• 预置条件：测试用例顺利执行的前提条件，如一些基本的配置。
• 测试数据：测试时使用的测试数据。
• 测试步骤：如何执行这个测试用例，每步的操作是什么。
• 预期结果：和测试步骤对应起来，从此操作后希望系统的返回。
  一般来说，测试用例的使用者是测试执行者，而测试执行者对业务、环境都有一定的了解，所以测试用例没必要非常细致，而应该简洁无歧义，突出测试用例的目的，描述清楚关键的步骤和检查点即可。好的测试用例通过阅读标题就能清楚地知道这个用例的测试目的。和测试目的密切相关的步骤才会放在测试步骤中，基础的操作步骤则应该简介描述在预置条件中，使得执行者能够快速抓住测试的重点，并且预期结果应该是清楚准确、没有歧义的。
  除此之外，需要控制用例的粒度，所谓用例的粒度，通俗来讲就是指一个用例包含的测试内容。从项目的角度来说，我们希望项目中所有测试用例的粒度是基本统一的，这样才便于估计工作量和布置工作任务。从测试执行者的角度来说，过细的测试用例会让执行者感到繁琐、疲惫，过粗的测试用例又容易遗漏掉检查点。下面简单总结了控制测试用例的参考：
• 测试用例标题不要超过30个汉字。
• 测试步骤不要多于7步，不要少于2步。
• 预期结果不要多于5个，不要少于1个。