测试计划和测试用例

1.测试用例的基本概念以及作用

测试用例对于一个测试工程师来说是一个必须掌握的能力，而且编写测试用例要对整个软件不管从业务，还是对软件的设计，程序模块的结构，功能规格说明都要理解透彻

​ 编写测试用例也是为了

避免盲目测试并提高效率

，从而

降低工作强度 缩短项目周期

为目的

测试用例的四个特性

代表性：能够代表并覆盖各种合理的和不合理、合法的和不合法的、边界的和越界的以及极限的输入数据、操作等。

​ 针对性：对程序中的可能存在的错误有针对性地测试

​ 可判定性：测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果

​ 可重现性：对同样的测试用例，系统的执行结果应当是相同的。

测试用例通常会包含几组元素

例编号、测试模块、用例标题、用例级别、前置条件、测试输入、执行操作、预期结果,实际结果

示例

​

2.编写测试用例的基本方法

等价类划分法

等价类划分是指分步骤地把海量（无限）的测试用例集减得很小，但过程同样有效。

​ 等价类 ：何为等价类，某个输入域的集合，在这个集合中每个输入条件都是等效的。

​ 一般可分为有效等价类和无效等价类

示例

​

边界值法

对数据进行软件测试，就是在检查用户输入的信息、返回的结果以及中间计算结果是否正确。即使最简单的程序要处理的数据量也可能极大，使这些数据得以测试的技巧是，根据一些关键的原则进行等价类的划分，以合理减少测试用例，这些关键的原则是：边界条件，次边界条件、空值和无效数据。

确认边界值方法

选取正好等于、刚刚大于或刚刚小于边界值作为测试数据

​ 例 输入要求是1 ～ 100之间的整数

（选取值1和100来测试规矩是否符合）

因果图法

因果图法比较适合

输条件比较多的情况

，测

试所有的输入条件的排列组合

。所谓的原因就是输入，所谓的结果就是输出。

因果图基本图形符号

​

恒等：若原因出现，则结果出现；若原因不出现，则结果不出现。

​ 非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现。

​ 或（∨）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。

​ 与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现

因果图的约束符号

​

E（互斥）：表示两个原因不会同时成立，两个中最多有一个可能成立

​ I（包含）：表示三个原因中至少有一个必须成立

​ O（惟一）：表示两个原因中必须有一个，且仅有一个成立

​ R（要求）：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现

​ M（屏蔽）：两个结果，a为1时，b必须是0，当a为0时，b值不定

​

例：有一个处理单价为2.5元的盒装饮料的自动售货机软件。若投入2.5元硬币，按“可乐”、“啤酒”、或“奶茶”按钮，相应的饮料就送出来。若投入的是3元硬币，在送出饮料的同时退还5角硬币。

判定表法

场景法

测试用例设计的思想

​

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用

​ 用例场景是通过描述流经用例的路径来确定的过程

这个流经过程要从用例开始打结束遍历其中所以基本流和备选流

遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：

基本流和备选流的区别

错误推测法

  根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的黑盒测试方法

正交表法

正交表能够在因素变化范围内均衡抽样，使每次试验都具有较强的代表性，由于正交表具备均衡分散的特点，保证了全面实验的某些要求，这些试验往往能够较好或更好的达到实验的目的。

正交实验设计

包括两部分内容：第一，是怎样安排实验；第二，是怎样分析实验结果。

一般应用在界面中多个控件，每个控件多个取值，控件之间可以互相组合的情况

测试用例的评审和变更

首先要清楚内部评审的定义，是测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。

如果是测试组内部的评审，应该着重于：

1.测试用例本身的描述是否清晰；

2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；

3.是否针对需求文档，测试用例是否覆盖了所有的软件需求；

4.是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。

如果是项目组内部的评审，也就需要评审委员会来做了，角度不同，评审的标准也不同。比如收集客户需求的人员注重你的业务逻辑是否正确，分析软件需求规格的人注重你的用例是否跟规格要求一致，开发负责人会注重你的用例中对程序的要求是否合理。

1、需要评审的原因

测试用例是软件测试的准则

，但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。

2、进行评审的时机

一般会有两个时间点。第一，是在用例的初步设计完成之后进行评审第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张，尽可能保证对用例设计进行评审，提前发现其中的不足之处。

3、参与评审人员

这里会分为多个级别进行评审。

1)部门评审，测试部门全体成员参与的评审。

2)公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。

3)客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。

4、评审内容

评审的内容有以下几个方面

1)用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。

2)优先极安排是否合理。

3)是否覆盖测试需求上的所有功能点。

4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。

5)是否已经删除了冗余的用例。

6)是否包含充分的反面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件**。**

7)是否从用户层面来设计用户使用场景和使用流程的测试用例。

8)是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

5、评审的方式

1)召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。

2)

通用邮件与相关人员沟通

3)通用IM(办公通讯)工具直接与相关人员交流

方式只是手段，得到其它人员对于用例的反馈信息才是目的。

无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解，以节省沟通成本。

6、评审结束标准

在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审。

测试用例的变更

备份之前的测试用例然后进行更改， 如果说添加需求我们要和项目经理进行确认是否舒适，重新制定规划时间完成 添加需求分析评审 更改测试用例

测试计划

——-测试时间、工作量、人员

——-由于每个人的思维存在局限性，每项测试最后安排不少于2个人测试，以便交叉测试

进度安排

——-最好能预留一段缓冲时间，用于应对计划的变更，以及让测试员有时间完善和补充测试用例

风险及对策

——-可考虑建立后备机制

测试计划，应该包括:

测试计划模板包含：

确定测试范围，制定测试策略，测试资源安排人员的分配，时间安排，风险分析等

测试用例模板

用例编号、测试模块、用例标题、用例级别、前置条件、测试输入、执行操作、预期结果、实际结果

测试报告模板

测试目标、测试依据、测试范围、测试环境、执行结果、缺陷分布、遗留缺陷、测试结论、建议、附录