第3章 测试用例设计

3.2.5 测试用例内容
测试用例文档由简介和测试用例两部分组成。简介部 分描述了测试目的、测试范围、定义术语、参考文档 、概述等。测试用例部分逐一列示各测试用例。 测试用例的基本元素：测试索引，测试环境，测试输 入，测试操作，预期结果，评价标准。 测试索引包括用例编号、用例名称等信息。 测试环境说明执行该测试用例的软硬件及数据环境。
1）测试用例的描述项，一般人在写的时候根本 不去关心这到底有何用，有的甚至为空，更有甚 者把需求中的几个字直接复制过来，不管是否通 顺与否都放在那里认为就可以了，预置条件可以 说是一个总结语，即你要明白这个用例是要验证 什么的，因为一个功能有很多用例，你不可能每 个描述都是一样的，那这样还不如不要描述。
什么是好的测试用例？
容易发现软件错误 可重复性 清晰定义测试通过/失败标准 没有冗余。
用例覆盖程度 毫无疑问，这一点应该是最重要的，无需多说，覆盖率 最大化是一套测试用例的最重要评价标准，如果漏测就 杯具了。 用例是否已经达到工作量最小化 在满足用例覆盖程度 最大化的前提下，应该尽量减小执行用例所需要的工作 量。这些方面的方法有不少，如条件覆盖，分支覆盖等 方法。面对不同的测试对象，也有不同的方法来保证： 对于网页背后的php逻辑，可以通过在网页上测试后， 用一些工具比如xdebug来统计代码覆盖率；对于向外 提供接口的server，采用的方式就是分析在外面暴露的 接口设计用例，大致的通过接口参数来估计一下分支判 断的情况。
每个判定至少都获得一次“真”值和“假”值。
3、条件覆盖：执行足够的测试用例，使得判定中的 每个条件获得各种可能的结果。
白盒法常用的覆盖标准
4、判定/条件覆盖： 执行足够的测试用例，使得
判定中每个条件取到各种可能的值，并使每个判
定取到各种可能的结果。
5 、条件组合覆盖： 执行足够的例子，使得每个
判定中条件的各种可能组合都至少出现一次。 6、路径覆盖： 执行足够的例子，覆盖程序中所 有可能的路径。
软件测试
2016年3月3日
第3章：测试用例设计
学习目标: 了解测试用例的内容和作用 了解白盒测试用例方法 掌握等价类划分、边界值分析 了解因果图和判定表法 熟悉场景法 掌握测试用例的编写
3.2 开发测试用例
什么是测试用例？
测试用பைடு நூலகம்(Test Case)是为特定目标开发的测试输入、 执行条件和预期结果的集合。 需要在开发的早期准备测试用例。 测试用例的完成并非一劳永逸，因为测试用例是来源 于测试需求，而测试需求的来源包括了软件需求、系 统设计、详细设计，甚至包括了软件发布后，在软件 产品生命周期结束前发现的所有软件错误。
3.2 白盒测试用例设计
白盒测试作为结构测试方法，是按照程序内部的 结构测试程序，对软件的过程性细节做细致的检 查，测试人员利用程序内部的逻辑结构及有关信 息，设计或选择测试用例。
测试如下程序该如何选择测试数据?
Procedure(VAR A,B,X:REAL)； BEGIN IF (A>1) AND (B=0) THEN Y:=X/A ; IF (A=2) OR (X>1) THEN Z:=X+1 END;
□通过
□失败
测试用例示例三
不同组织会定义自己内部的 测试用例格式。
测试用例ID： TC-003 测试用例作者： Henry 测试位臵（路径）：TestServer:C\TestProject\TestSuit\...... 最后版本日期： mm/dd/yy 需求编号： SC001 测试配臵号： ST02 测试用例依赖： 运行该测试前需要先运行测试用例TC-001 测试目标： 验证系统能进行有效的用户注册，对无效的用户注册给出错误提示。 测试过程 测试设臵 None N/A
程序逻辑结构
Procedure(VAR A,B,X:REAL); BEGIN IF（A>1) AND (B=0)
A>1 AND B=0
N Y
X:=X/A
THEN X:=X/A ;
IF (A=2) OR (X>1) THEN X:=X+1 END;
A=2 OR X>1
N Y
X:=X+1
白盒测试用例设计方法
4）预期结果，此项是验证所写用例是结果如何 ，所以如果没有预期结果，在测试时则无任何可 参照的，预期结果与操作步骤的关系相当大，一 般来说，不同的操作步骤能生成不同的预期结果 ，因此在测试测试用例的时候，尽可能的考虑不 同的操作步骤，是否会产生同一个结果，有时在 设定测试用例的时候，根据结果来推断操作步骤 ，这也应该是设计用例时的一种参照方法。在测 试时，预期结果直接导致着测试是否通过。
1、对功能的理解。这个是最重要的，也是能反 映出每个人对同一功能描述而有不同的理解方式 ，故一定要深刻理解功能。 2、编写用例永远要考虑两面性。事物都是两面 的，只有一面的事物那是“怪物”，所以在编写 测试用例时先要心中有数。
3、确定测试用例的目的。如果不了解为何要写 这个用例，那你达到的目的就是按需求或者按任 务来完成而已，这样的用例是否适用还有待于商 榷；只有了解这个功能的来源，为什么要做这样 的功能，希望最后的结果是什么，这些通通考虑 清楚了，就不会为了完成任务而去编写出“普通 ”的测试用例，而是一份优秀合格的测试用例， 这样会大大提高工作效率及审核打回的次数。 4、测试用例所包含的内容：最基本最简单的测 试用例应该包含四项内容，即描述、预置条件、 操作步骤、预期结果。一般为更好的管理及维护 测试用例，我们会增加测试用例的编号及功能。
测试用例示例一
说明 测试用例ID： TC-001 子系统： 用户名字段测试 测试人员姓名： 初始设臵 1．打开注册会话框 2．在用户名字段放入字符“王” 3．确保所有其他输入字段为空 输入 1．将光标臵于用户名字段 2．输入字符“帅” 预期结果 用户名字段出现字符“王帅” 实际结果 软件版本： 操作系统： 测试日期：
测试用例的作用
指导测试的实施。测试用例主要在实施测试时作为 测试的标准，测试人员按照测试用例严格执行用例 和测试步骤，逐一实施测试。 作为编写测试脚本的“设计规格说明书”。有利于 编写自动测试的脚本。 评估测试结果的度量基准。 分析缺陷的标准。
如何确定测试用例中预期结果
项目专家或其他方面的专家（主要的程序员、设计者 、项目经理等）将知道如何确定输出结果。 用户文档可以包含一些用户场景范例。 需求文档也可以提供必要的信息。 其他相关文档也可以提供相关线索。 最终用户也许能够描述所期望的响应结果。
详细步骤 1．在主菜单中点击“注册” 2．在用户名字段输入„„ 3．„„ 测试清除
测试人：XuFang
期望结果 界面上显示用户注册窗口 „„ „„
通过（√） √
None
测试结果 测试日期：mm/dd/yy
N/A
测试结果（P/F/B）：F
测试用例中数据需要和过程分离吗 ？
没有将测试数据和测试逻辑分开的测试用例可能 显得非常庞大，不利于测试人员理解。 将测试用例参数化，可以简化用例，使测试用例 逻辑清晰，数据与逻辑的关系明了，易于理解； 有利于提高测试用例的复用性。
用例是否表明了测试目的 写明用例的测试目的 ，对文档的易于理解性和工作交接的好处不言而 喻，现代软件工程不可能只有一个人在做事情， 项目于人员的变动也是难免的。在过程中留下足 够的信息，可以在后续工作提高很多效率。
测试用例需要很详细吗？
如果对产品不熟悉的人来执行系统测试，测试用例中 测试过程应该写得较为详细，以确保测试步骤能正确 执行。 如果测试人员对产品有较多的了解，测试用例中测试 过程就不必写得太详细。
白盒法又称为逻辑覆盖法，其测试用例选择，是按 照不同覆盖标准确定的。
弱
语 句 覆 盖 判 定 覆 盖 条 件 覆 盖 判 定 条 件 覆 盖 条 件 组 合 覆 盖 路 径 覆 盖
强
白盒法常用的覆盖标准
1、语句覆盖： 选择足够的测试用例，使得程序中 每个语句至少都能被执行一次。 2、判定覆盖： 执行足够的测试用例，使得程序中

设计操作步骤还依赖于测试经验是否丰富，有 些经验丰富的人员设计的测试用例往往会出乎意 料，也是在测试阶段最容易发现问题的用例。比 如很简单的一个编辑功能，要求其内容不能重复 ，一般人在写用例的时候都在编辑中去修改成别 的名字，而有经验的测试人员会直接编辑一下而 不改变内容，一般的程序员是不会考虑到此问题 的，如果说出现提示错误一般都是程序逻辑问题 。
2）预置条件项，任何一个事务都有起源，有始 有终才是一个完整的过程，预置条件也可以说是 一个基础，基础打好了，一切才能顺利动工。预 置条件是为操作步骤服务的，当然有些可能说不 需要预置条件，其实任何用例都是有预置条件的 ，我们说没有预置条件只是隐藏了本身的特点而 已。简单来说，发送一条命令测试用例，前期不 需要预置条件，但其隐藏的就是有号，且通信正 常，还要有MONEY用来发送短信；但实际中我 们并不需要写这些预置条件，因为是这是本身特 点决定的。
4、测试工作量与测试用例的数量成比例。根据全 面且细化的测试用例，可以更准确地估计测试周 期各连续阶段的时间安排。 5、测试设计和开发的类型以及所需的资源主要都 受控于测试用例。 6、测试用例通常根据它们所关联关系的测试类型 或测试需求来分类，而且将随类型和需求进行相 应地改变。
3.2 开发测试用例
□ 通过
□ 失败
测试用例示例二
说明 测试用例ID： TC-002 子系统： 彩色版本 被测系统 开发版本： 02.13 操作系统版本： windows 2000 硬件平台： PC Pentium 初始设臵： 将图像系统配臵为处理256X1024的图像 输入 1．加载并显示图像Flip1024.bmp 2．输入命令„„ 3． 预期结果 1．屏幕显示图像Flip1024.bmp 2．„„ 实际结果 测试记录 测试日期： 结果： 测试人员姓名： 问题报告号： 测试机器：
确定测试用例之所以很重要，原因有以下几方面。 1、测试用例构成了设计和制定测试过程的基础。 2、测试的“深度”与测试用例的数量成比例。由于每个测 试用例反映不同的场景、条件或经由产品的事件流，因 而，随着测试用例数量的增加，您对产品质量和测试流 程也就越有信心。 3、判断测试是否完全的一个主要评测方法是基于需求的覆 盖，而这又是以确定、实施和/或执行的测试用例的数 量为依据的。类似下面这样的说明：“95%的关键测 试用例已得以执行和验证”，远比“我们已完成 95% 的测试”更有意义。
用例的分类以及描述是否足够清晰 用例的分类， 在这里是指相同类型的用例是否放在一起了。例如 ：接口类的用例，参数的取值范围是1-3，但是现在 却传入4；数据类用例，状态机现在位于状态2，却 要求状态跳转到无法到达的4；逻辑类用例，正常 功能的产出等。将相同类型的用例放在一起，有助 于理清思路，清楚了解用例设计是否完备。 用例 的描述，是指描述的清晰程度是否能够形成文档。 例如上面参数取值范围的例子，用例这样写：“传 入错误的值”或者“传入非1-3的值”，明显没有写 成“传入值4”有效。
3）操作步骤是非常重要的一环，与预期结果是 等同的地位。测试用例设计是否高效，由预置条 件及操作步骤决定，在操作步骤中，按正常步骤 来测试，好像都不会出问题，但真正出问题的就 是你想不到的，不是按常规则出牌的才会发现真 正有价值的缺陷，所以在设计测试用例时，不要 嫌麻烦，认为那一项就好了，别的都应该能检测 到，认为写某一项是不必要的，多余的，其实这 些想法是错误的，问题就往往出现在你认为这无 关功能上。
谈谈如何写好测试用例
在测试的过程中，打交道最多的是测试用例，从 需求开始到方案，到形成用例，执行过程中与实 际的出入，测试完成后用例的修改，维护等，没 有一个过程可以说不需要测试用例之说。如何写 “好”测试用例。让人看了一目了然，就看有新 人拿到这个用例，能对程序有一点点基本的了解 ，就可以按照用例完完整整的执行下去。需要关 注以下几点：