软件测试教程 第四节 用例篇

---

上一节课讲述的是一次基本的测试过程。在我们开始做了一段时间基础测试，熟悉了业务之后，往往会分配来写测试用例，并且在日常测试中，有时也需要补充测试用例到现有的案例库中。

在这里我们将回答以下问题

• 测试用例的基本要素

• 测试用例的有效性和价值

• 测试用例的设计方法

  • 基于需求的设计方法
  • 等价类
  • 边界值
  • 因果图
  • 正交排列
  • 场景设计法
  • 错误猜测法

• 测试用例的粒度和评价

测试用例的基本要素

回顾测试用例的概念：

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

好的用例是一个对业务不熟悉的人按照用例也能够迅速执行

用例的基本要素可以参加如下例子：

测试用例 ecsp-439: 注册单位用户成功
步骤动作:	期望的结果:
进入注册页面，选择注册	系统展现注册页面
输入符合要求的单位名称、单位邮箱、密码、确认密码、组织机构代码、验证码，并确认同意《用户注册协议》，提交注册信息	系统进行注册操作，发送激活邮件。注册成功后，跳转到注册成功页面，并提示用户进行激活操作。
进入注册用的邮箱，进行激活操作	激活成功
用注册的邮箱和密码，进行登录操作	登录成功，系统展示欢迎页面
测试方式	手工
重要性	重要
测试环境	CHROME,IE10+
测试前提	系统运行正常，邮件服务器已开启
功能模块	注册登录

测试用例的有效性和价值

测试用例的有效性

用例的检查主要包括如下方面：

• 需求覆盖完成性
• 有效性
• 清晰性
• 可理解性
• 可维护性

什么是有效性？

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试

常听一些测试人员在抱怨“今天执行完成多少条用例，但没有发现一个Bug，软件真就那么好吗？真怀疑这些用例的有效性"。难道没有发现Bug的用例，就不是成功的用例，无效的用例吗？通常，大部分用例执行后与预期是一致的，即证明程序是符合需求的，如果说能发现Bug的用例才是有效的用例，那么有效用例未免也太少了。特别是软件开发后期，版本稳定的情况下，能发现Bug的用例更加少，这些用例都是无效的吗？显然不是。

接下来就如何评价用例的好坏，概括如下：

• 用例表达清楚，无二义性。当测试设计人员与测试人员不足同一个人时，可以减少理解错误的可能。
• 用例可操作性强。测试中常会遇到这种情况，执行一条用例，需准备大半天的测试环境，或用例太粗，操作描述模棱两可，测试执行人员很难顺利地往下执行。
• 用例的输入与输出明确。一条用例只有一个预期结果，如果一个用例有n个不同的预期结果，一方面容易使测试人员遗漏观察点，另一方面会造成测试统计不准确。
• 用例的可维护性好。用例的结构、表达，遵循用例的设计规范，犹如开发的编码规范，共同工作的团队有一个统一的风格，方便相互之间的交流。
• 用例对需求的覆盖率高，这一点很重要，可建立一个需求与用例的追溯表来保证每一需求都有对应的用例与之对应。
• 暴露程序Bug的能力强力。“成功的测试是发现了至今为止尚未发现的错误的测试”，而一次成功的测试需要高效的能暴露Bug的用例来支撑。

下面是好的用例和不好的用例的范例。

【案例】
手机拍照测试用倒
用例元素：标题，测试思路、预设条件、步骤、预期输出。
1.存在歧义的用例
●标题：单拍。

●预设条件：闪光强制关闭，电池充足。

●步骤：

(1)镜头对着拍摄对象，按下快门按键。
(2)按向下翻页键，浏览刚拍的照片。

●预期输出：

可见刚拍下的照片，照片正常。

2.明确清楚用例

●标题：单张拍照。

●测试思路：检查从按下快门到拍照结束整个过程的处理是否符合要求。包括拍照指示灯的状态，照片存储过程中屏幕的显示，拍完后照片的正确性检查。

●  预设条件：闪光强制关闭，电池充足。

●  步骤：
(1)用相机镜头瞄准拍摄对象，准备好后，按下快门按键。
(2)注意听按下快门键后的快门声。
(3)照片保存过程中，观察手机屏幕显示的变化。
(4)照片保存的正确性检查。

●  预期输出：
  按下快门后，1秒内听到设置的快门声；
  照片保存过程中，手机屏幕显示正在保存的照片；保存完成后屏幕恢复为照相模式；
  照片为即见即所得。查看照片的像素、色彩等与设置的模式一致；

测试用例的价值

• 优点：

测试执行者的依据

使得工作可重复，自动化测试的基础

评估需求覆盖率

用例的复用

提供测试过程数据

• 缺点：

测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多

• 解决如下问题：

不知道是否较全面的测试了所有功能
测试的覆盖率无法衡量
对新版本的重复测试很难实施
存在大量冗余测试影响测试效率

测试用例的设计方法

基于需求的设计方法

RBT( Requirements-Based Testing)是基于需求的测试方法，会使测试更加有效，因为
它使测试专注于质量问题产生的根源，即需求。

基于需求的测试是一种最根本的软件测试，重点关注以下两大关键问题。
（1）验证需求是否正确、完整、无二义性，并且逻辑一致。
（2）要从“黑盒”的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求。

软件质量差的两大原因是：
（1）软件需求规格说明书的错误
（2）有问题的系统测试覆盖

要获得满意的测试覆盖率是很难的。尤其现在的系统都比较复杂，功能场景很多，逻辑分支很多，要做到完全的覆盖几乎不可能。再者，需求的变更往往缺乏控制，需求与测试用例之间往往缺乏可跟踪性。

在使用基于需求的测试方法的过程中，保持对需求的可追踪性非常重要。保持需求与测试用例及测试之间的可追踪性有助于监视进度、度量覆盖率，当然也有助于控制需求变更。

案例：

**根据《概念篇》的需求样例设计测试用例**
软件需求：

1.1.1.1.1    功能概述

用户可以通过填写邮箱信息在平台注册个人用户。

1.1.1.1.4    输入

| **序号** | **栏位名称** | **栏位说明**            | **长度**  | **类型** | **备注** |
| ------ | -------- | ------------------- | ------- | ------ | ------ |
| 1      | 姓名       | 必填，录入个人姓名           |         | 字符型    |        |
| 2      | 电子邮箱     | 必填，录入电子邮箱           |         | 字符型    |        |
| 3      | 密码       | 必输，输入的密码隐藏*号显示，最短6位 | 6至15    | 字符型    |        |
| 4      | 确认密码     | 必输，输入的密码隐藏*号显示，最短6位 | 6至15个字符 | 字符型    |        |
| 5      | 验证码      | 必填，录入验证码            |         | 字符型    |        |
| 6      | 注册       | 注册操作                |         | 操作型    |        |

1.1.1.1.5    处理

1.1.1.1.5.1   基本事件流

1、 用户选择注册；
2、 系统展现用户协议界面，并请用户确认是否同意用户协议
1)     若用户不同意协议，系统禁止用户注册。
2)     若用户同意协议，用户进行注册信息填写。
3、 用户填写注册信息。
注册个人，填写：姓名，电子邮箱，密码，确认密码，验证码。
4、 用户提交注册信息；
5、 系统提示用户并向用户注册的电子邮件地址发送一封含有激活信息的电子邮件。系统并提示用户，若未收到激活邮件，可使用注册的邮箱和密码登录系统后再次发送激活邮件。
6、 用户可执行激活操作，直接跳转至注册邮箱门户页面。
7、 用户通过接收到的电子邮件中的激活信息激活账号，用户注册完成，流程结束。

1.1.1.1.5.2   扩展事件流
1. 用户注册并激活成功后，第一次登录平台时，提示用户完善信息；
1.1.1.1.5.3   异常事件流
1. 若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。
2. 每次发送的激活邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送激活邮件。

**测试用例**
业务流程：
1、填写正确的信息，并进行激活，注册成功后完善用户信息
2、不同意用户协议
3、填写正确的信息，但是不进行激活，24小时后进行激活
4、关闭邮件发送服务器，用户未收到邮件，开启服务器，再次发送激活邮件，收到邮件激活并注册

5、用户多次发送激活邮件，用最后一封激活？或者用前一封激活?
6、用户激活后再次点击邮件激活链接？
7、24小时链接过期后，再次点击激活？
8、填写正确的信息，并进行激活，注册成功后不完善信息，再次登录，是否提示完善信息？
9、已注册用户再次注册？
10、注册时的密码安全？抓包查看密码是否明文
页面检查：
1、协议显示正确
2、输入项校验正确
3、提示语正确
4、邮件内容正确
5、必填项校验

等价类

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

• 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能

• 无效等价类：根据需求说明书，不满足需求的集合。

等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。

案例：

以上述的需求为例：
| 密码       | 必输，输入的密码隐藏*号显示，最短6位 | 6至15    | 

密码要求为6-15位，那么有效等价类为6-15，无效等价类为两个：<6或者>15，那么可以设计案例为密码输入为<6，6-15,>16

思考一下：假设我们选3,10,20，这样的测试真的可以确认密码是6-15么？

边界值

•上点：就是边界上的点，不管它是开区间还是闭区间，就是说，如果该点是封闭的，那上点就在域范围内，如果该点是开放的，那上点就在域范围外；
•内点：就是在域范围内的任意一个点；
•离点：就是离上点最近的一个点，如果边界是封闭的，那离点就是域范围外离上点最近的点，如果边界是开放的，那离点就是域范围内离上点最近的点。

4-1.PNG

边界值的选择

• 如果输入条件规定了值的范围，则应该取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据；（例如：0-50，0、50、51、-1）
• 如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多1个、比最小个数少1个的数做为测试数据；（例如：运动员的参赛项目为1-3项，则0项、1项、3项、4项）
• 如果程序的规格说明给出的输入域或输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个和最后一个元素作为测试用例；例如：输出的表最多有999行，每50行为一页，则：输出0行、1行、50行、51行、999行

案例：
继续以上述需求为例子
密码要求为6-15
那么边界值上点为6,15，离点为5,16，内点为7-14

在实际的测试设计中，会将等价类和边界值结合起来使用，那么我们最终可以确认的用例设计为：
5,6,10,15,16五个长度的字符的输入值

继续思考：这样的测试真的完整了么？中文？半角？全角？特殊字符

因果图

因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

因果图法设计测试用例的步骤如下。

(1)分析所有可能的输入和可能的输出。
(2)找出输入与输出之间的对应关系。
(3)画出因果图。
(4)把因果图转换成判定表。
(5)把判定表对应到每一个测试用例。

现在举某个项目中的一个业务单据处理规则为例子，看如何通过因果图法设计测试用例。

因果图的需要掌握的基本知识

• 恒等

4-2.PNG

恒等：如果原因为真，那么结果必定为真。
例如：动物园运来大熊猫，动物园一定有大熊猫

• 与

4-3.PNG

只有2个原因都为真，那么结果为真
例如：北京姑娘，必须有车且有房

• 或

4-4.PNG

2个原因中有一个为真时，结果就为真。
例如：长沙姑娘，你有车或者有房

• 非

4-5.PNG

只有原因为假，结果才为真。
例如：你不好好学习，找到好工作

案例一：

假设业务单据的处理规则为：“对于处于提交审批状态的单据，数据完整率达到80%以上或已经过业务员确认，则进行处理”。

1. 对于这条业务规则，首先通过分析所有可能的输入和可能的输出，可以得到如下结果：

   ● 输入：处于提交状态、数据完整率达到80%以上、已经过业务员确认。

   ● 输出：处理、不处理。

2. 然后，进行第二步，找出输入与输出之间的对应关系。通过分析，可以看出有以下的对应关系。

   (1)单据处于提交审批状态且数据完整率达80%以上，则处理。

   (2)如果单据不处于审批状态，则不处理

   (3)如果单据处于提交审批状态，且已经过业务员确认，则处理。

   (4)如果单据处于提交审批状态，数据完整率未达到80%以上，但经过了业务员的确认，则处理。

3. 为了方便画出因果图和判定表，需要对所有输入和输出编号，现在编号如下。

   1：处于提交状态。

   2：数据完整率达到80%以上。

   3：已经和业务员确认

   21：处理

   22：不处理

4. 画因果图

   4-10.PNG

5、画判定表：

4-11.PNG

案例二：

继续以注册的需求为例：

姓名、邮箱、密码、确认密码、验证码必须全部输入，才能进行注册

需要设计多少用例？2x2x2x2x2。

因果法设计测试用例可以帮助测试人员理清输入和输出的关系，但是对于比较复杂的输入和输出，会耗费大量时间

正交排列

因果法设计用例太多怎么办？

正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。

正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。

因素（Factor）：在一项试验中，凡欲考察的变量称为因素（变量）

水平（位级）（Level）：在试验范围内，因素被考察的值称为水平（变量的取值）

正交表的构成：

行数(Runs)：正交表中的行的个数，即试验的次数。

因素数(Factors)：正交表中列的个数。

水平数(Levels)：任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到数“水平数-1”或从1到“水平数”

正交表的表示形式： L行数(水平数因素数)

正交法设计测试用例的步骤：

1、有哪些因素（变量）

2、每个因素有哪几个水平（变量的取值）

3、选择一个合适的正交表

4、把变量的值映射到表中

5、把每一行的各因素水平的组合作为一个测试用例

6、加上你认为可疑且没有在表中出现的用例组合

案例：

以下使用正交设计助手小工具来演示（类似工具可以使用微软的PICT工具）：

继续以上述的注册为例：

1、因素：姓名、邮箱、密码、确认密码、验证码

2、水平：填写、不填写

4-12.PNG

3、表中的因素数>=5；

​ 表中至少有3个因素数的水平数>=2

​ 行数取最少的一个，即试验次数最少的一个

选择正交表，这里选择了L8_2_7。正交表不是随便选择的，而是设计好的

4、生成测试用例

4-13.PNG

5、增补测试用例

姓名、邮箱、密码、确认密码、验证码都不填写

发散一下：实际工作中这种做法会不会常见？在那种项目中需要这样做？实际中我们会怎么做？
不常见
科学实验性更需要
实际中可能会看代码或者想象可能的代码来减少用例

场景设计法

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

典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向

案例：

以注册为例

4-14.PNG

想象注册的场景来设计用例，这与根据需求的业务流来设计差不多。主要是想象各种业务流来设计用例。例如我们可以再想象以下场景：

1、用户激活后再次点击邮件激活链接？

2、已注册用户再次注册？

错误猜测法

错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。

基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。经验可能来自于在对某项业务的测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug也就越多。

案例：
以注册为例
1、校验中特殊字符空格的处理?
2、密码校验中的大小写？
3、姓名中的特殊字符？
4、密码发送是否明文？

测试用例的粒度和评价

测试用例的粒度

测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，
具体到界面元素的操作步骤，指定测试的方法和工具等。

(1)测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。

(2)测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

主要考虑可以参考如下内容：

• 产品的质量要求
• 项目对用例的要求
• 测试时间和资源是否充分

但是不管用例怎么简化，都不应该省略

测试用例的评价

测试用例设计出来了，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。

• 同行评审
• 用户检查

（1）测试用例的检查可以有多种方式
但是最敏捷的应当属临时的同行评审。同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。

（2）除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于如何定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是被定义为对开发提供帮助和支持，那么顾客显然就是程序员了。