测试用例的设计和编写

1. 测试用例的概念和作用

如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。

测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。

对一个测试工程师来说,测试用例的设计编写是一项必须掌握的能力，但有效的设计和熟练的编写测试用例却是一个十分复杂的技术，测试用例编写者不仅要掌握软件测试技术和流程，而且要对整个软件不管从业务，还是对软件的设计、程序模块的结构、功能规格说明等都要有透彻的理解。

测试的设计方法不是单独存在的，具体到每个测试项目里都有很多种方法，每种类型都有各自的特点。

1.1. 测试用例的定义：

（1）测试用例是为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据，包括测试输入、执行条件和预期的结果。

（2）测试用例是执行的最小实体。

测试用例的特征：

（1）最有可能抓住错误的；

（2）不是重复的、多余的；

（3）一组相似测试用例中最有效的；

（4）既不是太简单，也不是太复杂。

1.2. 编写测试用例的好处：

在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。

测试用例的使用令软件测试的实施重点突出、目的明确。在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。

功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。

1.3. 测试用例的代表性

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

测试结果的可判定性

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

测试结果的可再现性

即对同样的测试用例，系统的执行结果应当是相同的。

2. 设计测试用例

2.1. 如何设计测试用例？

根据产品规格，测试基本功能；

考虑设计一般用户（非专业人员）的使用方案；

考虑设计稀有或特殊的使用方案；

与系统其他组成部分的配合（如FAX和上网可能要用到MODEM，测试中考虑对设备的共享）；

考虑特殊情况（如内存和硬件的冲突等）；

设计极端情况（如内存泄漏、破坏性测试等）；

好的测试用例集能花费最小的代价（人力、物力、财力、时间）做最好的测试。

2.2. 测试用例的4个特性

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

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

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

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

2.3. 测试用例通常包括以下几个组成元素：

测试用例编号 

测试用例名称 

测试用例设计者

软件版本号

测试目的

参考信息

测试条

测试环境

输入数据

操作步骤  

预期结果

测试结果

测试模块

2.4. 测试用例示例

 

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

功能测试，测试用例设计方法

 

3.1. 等价类划分法

3.1.1. 概念

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

等价类 ：何为等价类，某个输入域的集合，在这个集合中每个输入条件都是等效的，如果其中一个的输入不能导致问题发生，那么集合中其它输入条件进行测试也不可能发现错误。

在寻找等价划分时，考虑把软件具有相似输入、相似输出、相似操作的分在一组。这些组就是等价划分。

3.1.2. 示例

计算两个1～100之间整数的和。

    如果要进行完全测试，一共要设计多少个测试用例呢？

    加数1有1～100共计100个取值，加数2也有1～100共计100个取值，所以他们之间的组合就有100*100=10000种组合可能，但这只是测试了正常范围内的取值。如果用户输入的数据不在1～100之间呢，穷举测试肯定不可能的。由此引入了等价类划分思想。

等价类划分为：

有效等价类：指符合《需求规格说明书》，输入合理的数据集合

无效等价类：指不符合《需求规格说明书》，输入不合理的数据集合

针对从上面的例子进行等价类划分

 

我们将输入域分成了一个有效等价类（1～100）和两个无效等价类（<1,>100），并为每一个等价类进行编号，然后我们就可以从每一个等价类中选取一个代表性的数据来测试，设计如下表所示的测试用例

 

到这里我们的工作似乎结束了，还需要设计其他测试用例吗？刚刚输入的数据都是整数，如果输入小数，甚至字母怎么办？

这说明刚才的等价类还不完善，我们只考虑了输入数据的范围，没有考虑输入数据的类型（我们认为只输入数据，可是最终用户输入什么都有可能）。综合考虑输入数据的类型和范围划分等价类，如下图所示：

 

 

 

3.1.3. 等价类方法总结

等价类划分的步骤

先考虑输入数据的数据类型（合法和非法的）

再考虑数据范围（合法类型中的合法区间和非法区间）

画出示意图，区分等价类

为每一个等价类编号

从一个等价类中选择一个测试数据构造测试用例

确定等价类的方法

在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。

 

在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类。

 

在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。

 

在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。

在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。

3.1.4. 练习案例:

 

划分等价类并编号,下表为等价类划分的结果

 

设计测试用例，以覆盖所有等价类

 

 

 

 

 

 

3.2. 边界值法

3.2.1. 边界值法

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

程序的很多错误发生在输入或输出范围的边界上，因此针对各种边界情况设置测试用例，可以发现不少程序缺陷。

3.2.2. 设计方法：

 确定边界情况（输入或输出等价类的边界）--选取正好等于、刚刚大于或刚刚小于边界值作为测试数据

3.2.3. 确定边界值的方法

如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。

 

如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。

 

如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。

如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。

我们还以等价类中讲的例子来讲解边界值的思想。

输入要求是1 ～ 100之间的整数，因此自然产生了1和100两个边界，我们在设计测试用例的时，要重点考虑这两个边界问题。

 

上面讨论的边界条件最容易找到的。它们在产品说明书中有定义，或者在使用软件的过程中明显。而有些边界在软件内部，最终用户看不到，但是软件测试员仍有必要进行检查。这样的边界称为次边界条件。

2的幂。计算机和软件的基础是二进制数—用位（bit）来表示0和1，一个字节（byte）由8位组成，一个字（word）由四个字节组成，等等。

 

次边界条件

 

3.2.4. 默认、空白、空值、零值和无

另一种看起来很明显的软件缺陷来源是当软件要求输入时—比如在文本框—不是没有输入正确的信息，而是根本没有输入任何内容，可能单单按了Enter键。这种情况在产品说明书中常常忽视，程序员也经常遗忘，但是在实际使用中却时有发生。

好的软件会处理这种情况。它通常将输入内容默认为合法划分中的某个合理值，或者返回错误提示信息。

因为这些值在软件中通常进行不同处理，所以不要把它们与合法情况和非法情况混在一起，而要建立单独的等价划分。

3.2.5. 非法、错误、不正确和垃圾数据

非法、错误、不正确和垃圾数据是很有意思的。如果软件要求输入数字就输入字母。如果软件只接受正数就输入负数。如果软件对日期敏感，就看他在公元3000年是否能正常工作。假如有“肥胖的手指”，同时按下多个键。

此类测试没有实际的规则，只有设法破坏软件。要发挥创造力，要走偏门。在此门中需找乐趣吧。

3.3. 场景法

3.3.1. 测试用例设计的思想

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

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

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

 

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

  场景 1   基本流

  场景 2   基本流 备选流 1

  场景 3   基本流 备选流 1 备选流 2

  场景 4   基本流 备选流 3

  场景 5   基本流 备选流 3 备选流 1

  场景 6   基本流 备选流 3 备选流 1 备选流 2

  场景 7   基本流 备选流 4

  场景 8   基本流 备选流 3 备选流 4

  注：为方便起见，场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。

3.3.2. 银行案例ATM:

 

 

 

 案例分析:

备选流1 - 银行卡无效

    在基本流步骤2 中-验证银行卡，如果卡是无效的，则卡被退回，同时会通知相关消息。

备选流2 - ATM 内没有现金

    在基本流步骤5 中- ATM 选项，选项将无法使用。如果ATM 内没有现金，则“提款”功能不显示。

备选流3 - ATM 内现金不足

   在基本流步骤6 中-输入金额，如果ATM 机内金额少于请求提取的金额，则将显示一则适当的消息，并且在步骤6 -输入金额处重新加入基本流。

备选流4 - PIN 有误

    在基本流步骤4 中-验证帐户和PIN，客户有三次机会输入PIN 。如果PIN 输入有误，ATM 将显示适当的消息；如果还存在输入机会， 则此事件流在步骤3 - 输入PIN 处重新加入基本流。如果最后一次尝试输入的PIN 码仍然错误，则该卡将被ATM 机保留同时ATM 返回到准备就绪状态，本用例终止。

备选流5 - 帐户不存在

    在基本流步骤4 中-验证帐户和PIN，如果银行系统返回的代码表明找不到该帐户或禁止从该帐户中提款，则ATM 显示适当的消息并且在步骤10 – 退回银行卡处重新加入基本流。

备选流6 - 帐面金额不足

在基本流步骤7 -授权中，银行系统返回代码表明帐户余额少于在基本流步骤6 - 输入金额内输入的金额，则ATM 显示适当的消息并且在步骤6 - 输入金额处重新加入基本流。

备选流7 - 达到每日最大的提款金额

      在基本流步骤7- 授权中，银行系统返回的代码表明包括本提款请求在内，客户已经或将超过在24 小时内允许提取的最多金额，则ATM 显示适当的消息并在步骤6 - 输入金额上重新加入基本流。

备选流 x - 记录错误

      如果在基本流步骤9 -收据中，记录无法更新，则ATM 进入“安全模式”， 在此模式下所有功能都将暂停使用。同时向银行系统发送一条适当的警报信息表明ATM 已经暂停工作。

备选流 y - 退出

      客户可随时决定终止交易（退出）。交易终止，银行卡随之退出。

备选流 z - “翘起”

      ATM 包含大量的传感器，用以监控各种功能，如电源检测器、不同的门和出入口处的测压器以及动作检测器等。在任一时刻，如果某个传感器被激活，则警报信号将发送给警方而且ATM 进入“安全模式”， 在此模式下所有功能都暂停使用，直到采取适当的重启/重新初始化的措施。

 

 第一次测试中，根据测试计划，我们需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了下面的事件流：

  基本流-提取预设金额（100 元、200元、500元、1000元）

  备选流2 - ATM 内没有现金

  备选流3 - ATM 内现金不足

  备选流4 - PIN 有误

  备选流5 - 帐户不存在/帐户类型有误

  备选流6 - 帐面金额不足   

 

对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。

  从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。

下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。

本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

 

以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括：

场景 6 - 帐户不存在/帐户类型有误：未找到帐户或帐户不可用

场景 6 - 帐户不存在/帐户类型有误：禁止从该帐户中提款

场景 7 - 帐户余额不足：请求的金额超出帐面金额

 

在将来的测试中，当实施其他事件流时，在下列情况下将需要测试用例：

无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）。

无法读卡（读卡机堵塞、脱机或出现故障）。

帐户已消户、冻结或由于其他方面原因而无法使用。

ATM 内的现金不足或不能提供所请求的金额（与 CW3 不同，在 CW3 中只是一种币值不足，而不是所有币值都不足）。

无法联系银行系统以获得认可。

银行网络离线或交易过程中断电。

3.4. 因果图法

3.4.1. 概念:

因果图法比较适合输入条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。

利用因果图导出测试用例需要经过以下几个步骤:

分析程度规格说明的描述中,哪些是原因,哪些是结果.原因常常是输入条件或输出条件的等价类,而结果是输出条件

分析程度规格说明的描述中语义内容,并将其表示成连接各个原因与各个结果的”因果图”

标明约束条件。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。

把因果图转换成判定表。

为判定表中的每一列表示的情况设计测试用例

3.4.2. 因果图基本图形符号

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

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

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

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

 

3.4.3. 因果图的约束符号

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

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

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

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

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

 

3.4.4. 因果图测试用例

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

分析这一段说明，我们可列出原因和结果

原因(输入)：

投入2.5元硬币；

投入3元；

按“可乐”按钮；

按“啤酒”按钮；

按“奶茶”按钮。

中间状态：  ① 已投币；②已按钮

结果(输出)：

退还5角硬币；

送出“可乐”饮料；

送出“啤酒”饮料；

送出“奶茶”饮料；

 

3.4. 判定表法

 

 

 

 

3.5. 错误推测法

3.5.1. 基本思想

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.总之，就是进行错误的操作。

3.5.2. 测试示例

例如，测试手机终端的通话功能，可以设计各种通话失败的情况来补充测试用 例：

1) 无SIM 卡插入时进行呼出（非紧急呼叫）

2) 插入已欠费SIM卡进行呼出

3) 射频器件损坏或无信号区域插入有效SIM卡呼出

4) 网络正常，插入有效SIM卡，呼出无效号码（如1、888、333333、不输入任何号码等）

5) 网络正常，插入有效SIM卡，使用“快速拨号”功能呼出设置无效号码的数字

4. 测试用例的评审和变更

测试用例并非一成不变。如果软件修改之后发生变化，或者需求发生变更，那么测试用例便不再满足当前版本软件的测试需求，由此需要进行修改和变更操作。

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

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

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

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

3.是否针对需求跟踪矩阵，覆盖了所有的软件需求；

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

 

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

 

测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面对于测试工程师来说也是一个快速提高用例设计能力的过程。

1、需要评审的原因

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

2、进行评审的时机

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

3、参与评审人员

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

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

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

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

4、评审内容

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

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

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

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

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

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

6)是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在"保护"20%的功能实现。

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

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

个人认为，一个"健康"的测试用例至少要通过前5个标准。

5、评审的方式

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

2)通用邮件与相关人员沟通

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

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

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

6、评审结束标准

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

 

 

 

 

 

 

 

5. 测试报告