测试技能总结

测试用例的设计方法

1. 等价类划分：根据输入域或者输入条件，分为有效等价类和无效等价类。在等价类中选取test data。做到覆盖完整。

一个无效等价类为一个case

2. 边界值分析：测试用例来自等价类的边界。分析来自输入输出范围的边界值，选取刚好等于，刚好大于，刚好小于的值。也就是注意两侧。

3. 错误推测：凭借经验和直觉推出所有可能发生错误的情况

使用各种测试方法的综合策略：

-在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。

-必要时用等价类划分方法补充一些测试用例

-用错误推测法再追加一些测试用例

-对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例

-如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法

测试用例的设计步骤：

-构造根据设计规格得出的基本功能测试用例（UI&function）

-边界值测试用例（function）

-状态转换测试用例（function）

-错误猜测测试用例（function）

-异常测试用例（non-function）

-性能测试用例（non-function）

-压力测试用例（non-function）

优化测试用例的方法：

－利用设计测试用例的8种方法不断的对测试用例进行分解与合并

－采用遗传算法理论进化测试用例

－在测试时利用发散思维构造测试用例

软件测试用例设计的基本原则

在测试用例设计时，除了需要遵守基本的测试用例编写规范外，还需要遵循些基本的原则。

1、尽量避免含糊的测试用例

含糊的测试用例给测试过程带来网难，甚至会影响测试的结果。在测试过程。测试用例的状态是惟一的，通常情况下，在执行测试过程。良好的测试用例一般会有二种状态：通过(PAss)、未通过(Failed)以及未进行测试(Not Done)，如果测试术通过，一般会有测试的错误(bug)报告进

行关联：如未进行测试，则需要说明原因(测试用例本身的错误、测试用例目前不适用、环境因素等)，因此，清晰的测试用例使测试人蚰在测试过程中小会出现模棱两可的情况，不能说这个测试用例部分通过，部分未通过，或者是从这个测试用例描述中小能找到问题，但软件错误应该出现在这个测试用例巾。这样的测试用例将会给测试人员的判断带来团难，吲时也不利于测试过程的跟踪。

例如，还用上断的例子来说明，对用户登录的页面校验测试进行测试用例设计：

● 输入JF确的用户和密码，输入错误的用户和密码，程序会弹出对话框。

在L而这样的测试用例设计，未能清楚地描述什么样是程序正常工作状态，什么样是程序不正常工作状态，这样含糊不清的测试用例必然会导致测试过程问题的遗漏。

2、尽量将具有相类似功能的测试用例抽象并归类

一直强调软件测试过程是无法进行穷举测试的，因此，对相类似的测试用例的抽象过程显得尤为重要，一个好测试用倒应该足能代表组或者一系列的测试过程。

3、尽量避免冗长和复杂的测试用例

这样做的主要目的是保证验证结果的惟一性。这也是和第一条原则相一致的，为的是在测试过程执行过程th确保测试用例的输出状态惟性，从而便于跟踪和管理在一些很长和复杂的测试用例设讨过程中，需要将测试用例进行合理的分解，从而保证测试用例的准确性。在某些时候，测试用例包含很多类型的输入或者输乩或测试过程的逻辑复杂而币连续，此时需要对测试用例进行分解。张实际的测试用例设计中，需要将前述的基本原则和考虑凶素结台起来，遵循基本的测试用例编写规范。按照实际测试的需求灵活地组织设计测试用倒。在测试例设计监考虑白盒测试用例年u黑盒测试用例。

测试用例的概念：测试用例是包含输入项、预期输出的程序的标识。

测试用例的作用：执行测试、发现缺陷；重复执行、重现缺陷；回归测试、验证缺陷修复；管理测试过程。

测试用例的编写方式：操作步骤法、表格矩阵法；

测试用例的编写原则：客观准确（语言描述客观、操作客观、执行结果客观）、简洁、可重用（可多次执行、可维护）、适用（可执行）、可跟踪（组织管理及标识）、纯净（能返回到初始状态、不影响系统的使用）

测试用例评估标准：测试用例要素是否完整（用例标识、输入、预期输出，其他如：测试环境、前置条件、可能影响等）、测试用例编写依据是否准确（相关需求、开发/测试设计文档、测试计划、测试规范、文档模板等）、能否发现多的错误、测试覆盖率、用例冗余性、测试用例的依赖关系、用例执行的先后顺序及优先级

测试用例粒度控制：相关因素有所测试的功能的特点（复杂程度、重要程度等）、产品/项目特点（可延续性、客户的质量要求、需求明确的程度）、测试阶段（不同测试阶段执行测试的内容和重点不同）、测试资源（包括时间、人员、技能等）

注：公司内，或者同一测试组内，对同一项目的测试用例粒度应达成共识。

场景法：可用于典型业务及典型功能的测试设计。

一个业务只存在一个基本流，如果有两个相当的基本流，一般需要拆分业务。

分支流的起点和终点：分支流的起点可以是基本流，也可以是其他分支流；分支流的终点可以结束操作，也可以汇总到基本流或者其他分支流，汇总原则，向大的、常用的操作汇总。

关于软件质量

1、软件Bug少不代表质量高。

2、测试人员无法保证软件的质量。

3、质量是双方一定价格下的一个妥协（这个就像我说的买卖衣服一样）。

用例检查清单：

1）测试用例是否按照公司定义的模板进行编写的；

2）测试用例的本身的描述是否清晰，是否存在二义性；

3）测试用例内容是否正确，是否与需求目标相一致；

4）测试用例的期望结果是否确定、唯一的；

5）操作步骤应与描述是否相一致；

6）测试用例是否覆盖了所有的需求；

7）测试设计是否存在冗余性；

8）测试用例是否具有可执行性；

9）是否从用户层面来设计用户使用场景和业务流程的测试用例；

10）场景测试用例是否覆盖最复杂的业务流程；

11）用例设计是否包含了正面、反面的用例；

12）对于由系统自动生成的输出项是否注明了生成规则；

13）测试用例应包含对中间和后台数据的检查；

14）测试用例应有正确的名称和编号；

15）测试用例应标注有执行的优先级；

16）测试用例包含相关的配置信息：测试环境、数据、前置测试用例、用户授权等；

17）每个测试用例步骤应<=15 Step；

18）自动化测试脚本必须带有注释（注释应包括：目的、输入、期望结果等）；

19）非功能测试需求或不可测试需求是否在用例中列出并说明？

域分析法是针对输入域进行的，输出域分析法是通过输出反推输入，以达到对测试特性输入域的测试进行补充，提高测试覆盖率。

测试用例的设计思路是：先从穷举法开始，如果测试特性输入不是太多，我们可以用穷举法把每一种可能的情况都测试一遍，以达到100%的覆盖率，但是我们知道，在测试行业，达到100%的测试覆盖率几乎是不可能的。一是现实中测试特性的输入一般都是很多，用穷举法测试代价太大，执行起来也不现实；二是即使是很少的测试特性输入，但是要把现实中的各种情况都测试一遍，执行起来也比较困难。这个时候，就出现了各种测试用例设计方法，利用这些方法对大量的测试用例进行裁剪，达到我们可以接受的范围，当然这是以牺牲测试充分性为代价的，我们要做的就是用尽可能少的测试用例来达到最大的测试充分性。这里要注意尽可能少的测试用例不是指越少越好，有时候我们为了提高测试覆盖率，就不得不增加测试用例数；这里指将测试用例裁剪到我们现实中可以执行完成的范围，达到这个范围后，再考虑测试覆盖率的问题，在测试用例数和测试覆盖率之间寻求一种平衡。

先来看等价划分法，它是对系统的输入域进行等价划分为若干部分，然后从这若干部分

中选择少数测试输入数据代表该部分执行测试，以减少大量的测试用例。使用此方法我们有4个有用的分解数据的启发式关注点：数值的范围，变量的相似度，唯一数值和特定数值。但是用这种方法设计的测试用例不充分，因为它没有考虑输入域划分时的边界情况，这时就可以用边界分析法对其进行补充，以提高测试覆盖率。为达到上面同样的效果，有人将等价划分法和边界值分析法结合起来便形成了现在的域分析法，域分析法通过引入上点，离点和内点的概念可以用更少的测试用例达到与等价类和边界值分析法相同的测试效果。为了提高测试的充分性，可以在测试过程中引入输出域分析法对测试用例进行必要的补充。

这里简要说一下域分析法与输出域分析法的关系，域分析法是针对输入域进行的，输出域分析法是通过输出反推输入，以达到对测试特性输入域的测试进行补充，提高测试覆盖率。

上面的设计方法主要是针对单个因子输入的情况，但是现实中我们经常遇到需要覆盖多个变化参数因子的场景测试，更多的是要求对各组合的测试。组合分析和正交试验法就是对多输入因子的设计方法，组合分析原理是每个参数的每个值只需要和其他参数至少配对一次就行了，侧重在随机组合，即把每个因子的状态列出来，用PICT工具完成随机组合，把这些组合转化为测试用例；而正交试验法更多是对任意多个因素取值组合实施“等概率”覆盖，以便我们得到的实验样本均匀的分布在样本空间，即把每个因子的状态罗列出来，对其进行加权，为减小测试用例，删减权值较小的，再对照正交表，把各因子的状态填到正交表中，即可得到各测试用例。有时候，分类树方法也可以用在多因子输入设计测试用例中，先对各因子对象进行分析，然后分析每个因子的输入空间，对其输入空间进行分类，画出分类树，组合测试用例，这个过程中掺杂着对单个因子输入情况的测试用例设计方法：等价类，边界值以及域分析法。对于多个变化参数因子的场景测试也可以用分类树法，先识别出测试对象并分析输入空间，再对测试对象的输入空间进行分类，最后画出分类树组合测试用例。分类树法更加直观，再辅以分类树工具CTE，设计测试用例更加方便实用。

以上不管是对单个因子输入还是多因子输入情况的测试用例分析方法，更多的关注的是对输入域的分析。这些分析方法不需要深入了解测试对象的执行流程及各输入因子以及输入输出之间的联系，但这会给后期执行测试用例带来一些麻烦，当执行测试用例过程中，如果发现了bug，不好定位问题，各测试因子之间的联系不直观，不知道哪个环节出现了问题。这时可以用一些侧重于图形化或者流程的测试用例设计方法，如流程分析法，因果图法，判定表，状态转换法等。

对于系统测试，感觉流程分析法与状态转化法，除了在画流程图和状态转换图中遵循的规则不同外，差别不大。可能流程分析法，更多关注流的流向，状态转换法注重测试对象的各个状态和转换条件，有时候感觉状态转换法要考虑的测试对象更多，这两种方法都要求对测试对象的执行流程很熟悉。各个因子之间的关系也很直观明了，有助于对后期执行测试用例发现BUG后，定位bug。

因果图法一般是和判定表结合使用的，因果图法的结果就是产生判定表。对于多输入因子的测试对象，先标识输入和输出（包括各种情况）----》画出因果图----》将因果图转换为判定表---》简化判定表-----》生成测试用例。这个过程中也可以单独使用判定表，根据条件桩和动作桩写出各种条件项和动作项，这个过程跟穷举法类似，然后通过把无效的测试用例去除，并把相似的列进行合并，减少测试用例。单独使用判定表过程简单，但是对各输入因子之间，输入输出之间的约束关系不够直观明确；使用因果图法+判定表的结合方法，过程有点繁琐，但是输入输出，以及输入和输出之间的因果关系，输入和输入之间的约束关系比较明确。这个要根据个人喜好，选择其设计方法。

最后介绍下场景法和错误推测法，这两种方法可以对采用上面方法设计的测试用例进行补充，以达到充分测试。软件是用事件触发达到控制流程的，事件触发时的情景形成场景，而同一事件不同的触发顺序和处理结果形成事件流，这个事件流就是场景法。有些人认为场

景法可以作为独立的测试用例设计方法，我不赞同这种看法，场景法要求测试人员充分发挥对用户实际业务场景的想象，但是人毕竟不是机器，再缜密的想象也很难设计出覆盖性较强的测试用例，可以把它作为其他他测试用例设计方法的补充，利用测试人员的实际业务场景的想象思维，对测试用例的遗漏点进行必要的补充。错误推测法，是一种基于测试人员经验和直觉来推测软件中可能存在的各种错误，从而有针对性的设计测试用例的方法。利用错误推测checklist，对测试用例进行补充。

通过上面分析知道，当穷举法设计的测试用例在现实中不可能执行时，我们就应该采用其他设计方法在尽量不影响测试覆盖率的情况下对测试用例进行裁剪。各种方法有各种方法的特点，使用时考虑的角度，考虑的点不同，总的来讲就是在设计测试用例中，不断的优化设计流程，用最少的测试用例达到最大的测试覆盖率。