我的ITblog我作主　　关注→　『伊波拉』→　测试　SzDlinXie- ITblog　　 　　

从用例到测试用例的追踪

这篇文章来源于2003 年的 Rtional 用户大会的演讲稿，它阐述了从用例产生功能测试用例的一个正式方法，包括如何去创建一个用例，生成所有的场景，产生合理的测 试用例。它也讨论了如何使用IBM® Rational® RequisitePro®，对用例、场景和测试用例进行追踪。你可以在这篇文章的最后 提供的地址下载演讲稿的原文。

这篇文章介绍一个根据用例生成测试用例的有效途径。作为导言，它以介绍关于需求、可追溯性、以及用例这些基本信息为开端。

要求的类型概览

一个需求被定义为：“系统必须遵循的条件或能力”。它可以是：

• 一种消费者（或参与者）所需要的，用于解决一个问题或者达到某个目标的能力
• 为了满足协议、标准、规范、规章，或者其它文件的形式，系统必须达到或掌控的一种能力。
• 由资产管理者硬性要求的一种限制

图1是不同层面需求的需求金字塔

图1： 需求金字塔

在顶层是资产掌管者的需求。通常，一个项目包含有5-15个这样的高层需求。稍低的层依次是：功能，用例与附属的规范。根据不同层面的需求有不同的细节。层面越往下，需求就越详细。例如，要求可能是这样的：“数据必须是稳定的（长久保存）”。那么功能就要提炼概括这个需求为：“系统必须使用一个关系型数据库”。那么在附属说明层面，这个需求将要被描述得更加准确：“系统应该使用Oracle 9i 数据库”。层面越往下，就要把这个需求描述得越具体。

回页首

需求间的可追溯性

可追溯性是指一种技术，它提供系统内针对不同层面的需求间的关联。这种技术可以帮助你确定任何一个需求的根源。图2就解释了如何从塔顶层到底层跟踪需求。每个需要通常与好几个功能相关联，功能又与用例和补充说明相关联。

图2：可追溯性需求金字塔

用例描述了功能性需求，而补充说明描述非功能性项目。此外，每个用例又与许多场景相关联。也就是说，用例与场景是一对多 的映射。场景与测试用例也是一对多的关系。另一方面，在需要和功能之间，存在多对多 的关系。

可追溯性扮演着很多重要的角色：

• 验证实现满足所有需求：每位客户的要求均已被实现。
• 验证程序只做了所被要求的事：不能实现客户从未要求的事情
• 协助变更管理：当一些需求发生了变化时，我们就要去了解哪个测试用例应该重做，以测试该变化。

可追溯性项是一个项目的要素，它需要从另外的要素跟踪。跟据 IBM® Rational® RequisitePro®它是一个要求类型实例所表现的每件事物。在RequisitePro里，一些需求类型是资产管理者、功能、用例、参与者和术语项的需求。

在RequisitePro里，存在便利的方法，可以在特殊的视窗中显示可追溯性。如图3显示功能与用例间映射的例子。

图3： RequisitePro中的可追溯性

关于箭头应该朝哪个方向还存在一些问题，从较低的层面指向较高的层面还是从较高的层面指向较低的层面。即使在RequisitePro中，两个例子也使用不同的指导方针，这都无所谓，只要你在项目中能够保持一致。

回页首

参与者与用例

参与者是指对系统有影响的人或事物。 用例 是依照一系列动作的系统描述。它应该产生参与者可见的结果或值。下面是一些用例的一些特征，分别是：

• 由参与者发起的
• 模仿参与者与系统之间的相互作用过程
• 描述了一系列的行为
• 捕捉功能性的需求
• 为参与者提供一些值
• 提出一个完整并有意义的事务流

用例的目的是在开发人员、客户、参与者之间达成关于“系统应该做什么”的协议。从某种意义上说，用例成为开发人员与客户间的一种契约。当然它也是基于在设计中扮演着主要角色的现实用例之上的。另外，你可以从用例中制造出 序列图、协作图和类图等图。除此之外，你可以从用例里归纳出客户文档。用例同样有助于迭代的技术内容的策划，及系统的开发者对系统的意图有更好的理解。最后，你还可以将他们作为 测试用例的输入来使用。

用例图展示了参与者与用例之间的关系。在这篇文章里面我们将使用一个在线书店作为项目例子。图4显示项目的用例图。

图4： 用例图

用例的一般格式为：

1. 简要概述
2. 事件流
   1. 基本流
   2. 第一个可供选择的流
   3. 第二个可供选择的流
      ... ...
3. 特殊需求
4. 前提
5. 后置条件
6. 扩展要点
7. 相关图
8. 活动图

基本流 包括最通及的一系列行为，当每件事正确运行时发生的步骤。可供选择的流展现了流的变种，包括一些不经常使用的情况和一些错误的条件。 前后关系图是用例图的一部分，为参与者和其他的用例显示了特殊用例的关联性。活动图 表示一种解释用例的流程图。前后关系图和活动图并非必须的，但是可以帮助你对用例和它们在项目中所处的位置一目了然。

在我们的在线书店项目中，用例place an order 的基本流程看上去是这样的：

B1    参与者在浏览器输入这个网站的地址
         系统显示登录页面
B2    参与者输入电子邮件地址和密码
         系统确认正确的进入，显示主页面，并提示输入搜索串
B3    参与者输入搜索串（例如书名的一部分）
         系统返回所有与搜索条件匹配的书籍
B4    参与者挑选一本书
         系统显示关于这一本书的更加详细的信息
B5    参与者把这本书加入到购物卡中
         系统向参与者显示购物卡的内容
B6    参与者选择切换到结账选项
         系统要求确认送货的地址
B7    参与者确认送货地址
         系统显示送货方式
B8    使用选择送货方式
         系统询问使用哪种信用卡
B9    使用确认自己在系统内所存储的信用卡
         系统询问最后确认以建立定单
B10  参与者确认订单
         系统回一个确认的数量

除了基本流程，还有一些可供选择的流程。比如说，第一个可供选择的流程描述了当一个参与者是新的参与者（没有在网上书店注册过的）时做发生什么。在基本流程里，参与者总有用户名和密码。与此相反，第1个可供选择的流程说明当第一次用户需要注册并提供客户数据的情况。可供选择的流程的另一个例子是无效密码。一个参与者输入错误的密码将会得到错误信息。

表1向我们显示了在用例 place an order所包含的可供选择的流程的顺序：

A1 未注册用户 A2 无效密码 A3 未找到匹配的书籍 A4 书籍下架 A5 在购物卡中存入一本书后继续购物 A6 输入一个新的地址 A7 输入一个新的信用卡 A8 取消定单

表1： 可供选择的流程

下面的约定用于流程命名：

• 基本流程：B
• 可供选择的流程： A1, A2, A3, ...
• 基本流程中的步骤：B1, B2, B3, ...
• 可供选择流程1中的步骤：A1.1, A1.2, A1.3, ...
• 可供选择流程2中的步骤： A2.1, A2.2, A2.3, ...

为了归纳总结可选择流程，使用了活动图。图5显示描述这个用例的活动图

图5： 活动图

基本流程是一条直线向下，而可供选择的流程通常是往复迂回的。

回页首

如何从用例中建立测试用例

在建立一个测试用例之前，你需要确认所给用例的所有场景。一个场景是用例中的一个实例。它表述了穿过事件流的一条特殊的途径。

图6是一个假定的图，它显示了一个用例，它包含基本流程B和可供选择流A1,A2,A3及A4。为了找到所有的场景，我们需要画出通过这张图的所有的可能的线。

图6：在用例里找场景

每个可选流加上一个 可供选择的流程的组合仍然是一个流程。这样，明确的场景就多于可选择的流程，因为一个场景是解决A1的，另外一个是解决A2的，还有一个场景是解决二者组合的。

描述场景的最简单方法是提供一系列的可供选择的流程，例如，走两遍A2，然后走一遍A6：

SC16: A2, A2, A6.

另外一种描述场景的方法是列出所包含的所有步骤，但这既困难又未必详尽。

如果有死循环（周而复始）该怎么办？理论上将会产生无穷的场景。图7显示了死循环。

图7：死循环

最合理的途径是走一遍基本流程，一遍循环流程，然后再走二遍循环流程。如果程序对两个循环都能起作用，你就可以假定它对所有的循环都能起到作用。

书籍订单的例子有一个基本流程还有八个可供选择的流程。其中有四个是向回走，另外四个是向前走。假如你想描术所有可能的用例组合，那么你将有超过四千个场景（这里有8个可供选择的流程，其中有4个我们想让它走两遍，因为它们是向后回环的，因此总共是2（8+4）=4096），很显然，我们并不是都需要。

从这四千多的场景中我们选出一个最合理的子集。通常，明智的做法是选出一个基本流程，一个涵盖所有可供选择流程的场景，和一些合理可供选择流程的组合。在图1中的例子中，包含A1和A7的那个场景可能看起来没有任何意义，因为在图中它们相隔得比较分散以至于它们相互之间不会产生任何影响。但是这个场景可以使A1和A2之间有意义，由于它们之间的顺序是紧密相连，关系密切。

表2向我们讲解了经过选择后的场景：一个基本流程代表，8个单独的可供选择的流程代表，和6个流程组合的反射（尤其是有2个向后回环，并且两者如此接近）

下面的这15个场景值得我们去测试：

场景 1 基本流   场景 9 A8 场景 2 A1   场景 10 A1, A2 场景 3 A2   场景 11 A3, A4 场景 4 A3   场景 12 A4, A5 场景 5 A4   场景 13 A3, A5 场景 6 A5   场景 14 A6, A7 场景 7 A6   场景 15 A7, A8 场景 8 A7

表2： 测试场景

如何在RequisitePro里建立一个场景

在RequisitePro里，场景不是一个标准的需求类型，因此你需要添加它为新的需求类型。怎么做呢，找到 Project Properties，选择Requirement Types 标签，然后点击Add。接下来，填满适当的区域（正如图8所示），然后点击 OK。

图8： 添加一个 场景的需求类型

在建立了需求类型后，我们应该输入所有的场景并建立从用例到这些场景间的可追溯性，正如图9中所示。

图9：从用例到场景间的可追溯性

（点击这里放大）

在RequisitePro里，你可以使用用例的名字和一系列可供选择流程的名称为场景命名（例如：UC1, A6, A7）。

现在你就有了所有的场景，你需要获得测试用例。这里将需要完成4个步骤：

• 用例的每一步都要确定变量
• 有效地确定每个变量的不同选项
• 在测试用例中测试的选项组合
• 给变量赋值

下面详细讲解这些步骤。

第一步：用例的每一步都要确定变量

你需要确定在给定场景中的所有步骤里的所有输入变量。例如，假如在一些步骤中参与者输入了用户名和密码，那么就有两个变量。一个变量是 用户名，另外一个变量是密码。参与者也可以对这些变量做出选择（比如，保存更改或取消）。

这里是书籍订单例子的所有变量：

• 在B2步骤里，有两个变量：电子邮件地址 和 密码。这两个都是字符串。
• 在B3步骤里，搜索一本书，搜索字串就是一个变量，因此它也是字符串。
• 在B4步骤里，我们需要从系统返回的清单中 选择一本书 。
• 在B8步骤里，我们需要选择 送货方式。亚马逊提供了四种选择。

步骤2：有效地确定每个变量的不同选项

如果可以引发不同的系统行为，选项将会是“重要的不同”。

举个例子，假如我们选择了一个 用户名，假设这个用户名可以有6到10个字符长度，那么接下的键入将会是重要的不同：

• Alex -- 由于它太短，那么将会向我们显示一个错误的信息
• Alexandria -- 由于它是一个有效的用户名
• Alexandrena -- 由于它的字符太长，我们希望系统会阻止我们输入那么长的用户名

然而，Alexandria 与 JohnGordon 在特征上是相同的，因为他们俩都是有效的用户名称那么系统会有同样的反应。

下面的指导方针描述了一些特殊的案例。

选项是重要不同的，如果：

1. 它引发了一个不同的过程流（通常是一个可供选择的流）
   例如
   • 键入了一个无效的密码引发可供选择的流程2
2. 它引发了一个不同的错误信息
   例如
   • 如果电子邮件地址太长，返回信息为“电子邮件地址不应超过50个字符”
   • 如果电子邮件地址 没有@符号，那么信息为“无效的电子邮件地址”
3. 它显示了不同的参与者界面
   例如
   • 如果付款的方式 是信用卡，那么屏幕显示的区域会显示参与者可以输入信用卡号，有效日期和信用卡拥有者姓名
4. 它引发了下拉框具有不同的选择
   例如
   参与者注册屏幕或许包含国家和州/省市的下拉框。州/省市通常是基于国家的选择:对美国来说它是州，对于加拿大来说它是省，对于其他国家它是无效的。这样就产生三种不同的选择：
   • 美国
   • 加拿大
   • 其他国家
5. 一些商业准则的输入
   例如
   假设这里有一条规定“假如在下午6点后下订单，并且客户选择 头天晚上出货，那么将通知客户这本书将于后天到达”我们可以分为两种方式：
   • 头天晚上出货，在下午6点前下订单
   • 头天晚上出货，在下午6点后下订单
6. 头天晚上出货，在下午6点后下订单
   例如
   如果密码至少包含6个字符，我们应该测试:
   • 5个字符的密码
   • 6个字符的密码
7. 相对于默认值，需要改变的项
   例如
   在使用信用卡付款的屏幕上，持卡人的姓名通常是订单人的姓名。这样就产生了两种方式:
   • 保留默认的持卡者姓名
   • 把持卡者姓名改变成另外一个不同的姓名
8. 在入口处的格式没有明确定义或强制性时，根据不同的参与者可能有不同的理解
   例如
   不同的人所填写的电话号码也是不同的:
   • 使用括号 -- (973) 123-4567
   • 使用破折号 -- 973-123-4567
   • 使用空格 -- 973 123 4567
   • 无空格-- 9731234567
9. 在不同国家规则也是不一样的
   例如
   信用卡的有效日期在美国和在欧洲就是不一样的。

如果你在验证数字，你将会考虑到下面的情况：

• 从应用观点来看是常规数字，合理性的
• 0
• 负数
• 带两位小数的数字
• 所能够输入的最大的数字（例如，99999999999999 –只要能输入的所有的9）

那么你如何才能知道一个区域所允许输入的最小和最大长度呢？这个需求可以从不同的来源获得。有时是取决于业务分析师或者是一个消费者。例如，假如我们键入一个Dun 和 Bradstreet字母，那么会被看作是一个公司，总是要求包含9个阿拉伯数字。这是商业需求。

然而，它通常并不来自于客户和参与者。假如你问客户名字区应该有多长，他们会回答他们并不关心这个问题，并且会告诉你无论填什么都是合理的。在这个案例中，一个设计步骤比一个需求步骤更能决定变量到底应该有多长。

在另外的一些情况下，或许是有数据分析者或者数据库设计者提供建议——例如说，在一些商业公司的应用软件里，姓名有30个字符长的范围，你的应用也应该符合这个标准。

在我们做测试用例之前，忽略这些需求的来源都要被同意和证明过。

关于刚刚讨论过的应该被证明的那些需求，还有一个问题。在用例增加这类需求的地方称为 Special Requirements 段落。另外一个你可以放置这类要求的地方是术语表或者数据字典。此外，你可以详细解释单独的文档类型，以描述所有的来自应用的变量。如果在众多用例的不同场景里出现同样的变量，这将变得特别有意义，因此你可以在一个文档里说所有的名字截止到30个字符，所有的地址截止到100个字符。然而，假如对于某个用例，它们是特殊的，那最好在那个用例中把它们作为特殊的要求加入进来。

下面，表3，所展示了示例项目基本流程中根据变量所确定的方式

步骤 变量 测试项             B1 站点 实际 URL             B2 电子邮件 规则 空白 允许的最少字符数 (1 个字符) 允许的最多字符数 (50 个字符) 比允许的最多字符数多一个字符 (51 个字符) 非常长 (257 个字符) 无效(没有@) B2 密码 规则 空白 太短(5 个字符) 允许的最少字符数(6 个字符) 允许的最多字符数 (10 个字符) 比允许的最多字符数多一个字符 (11 个字符) 非常长 (257 个字符) B3 查询字串 规则 空白 允许的最少字符数 (1 个字符) 允许的最多字符数 (300 个字符) 比允许的最多字符数多一个字符 (301 个字符)     B4 选择 首次选择 最后选择           B5 选择动作 加入购物卡             B6 选择动作 进行结账             B7 送货地址 确认书面地址             B8 送货方式 5 天 3 天 2 天 当天晚上       B9 支付方式 确认信用卡信息             B10 选择动作 下定单

表3： 被测试的方式

步骤3：在测试用例中测试的选项组合

在前面步骤中你可以确定所有的方式。在这个步骤中，你需要将它们整合成为一系列的测试步骤。

图10图示了测试的方式。在每个纵队，有一些输入的变量将要被测试，每一行都会有一种方式：R 是代表正常的， E 是代表空的，然后是一个字符，50个字符，到此为止。L代表是很大， I 代表不合规定的。

图10： 每个步骤中要测试的方式

在那些有阻碍的方式之后，参与者脱离了基本流程：在可能性流程中出现了一些错误。由于你通常设计测试用例仅仅是为了第一个场景，你可能移动它们（它们将会在其他的场景中被测试）。无论后面剩下多少，你都需要产生一个最小数量的测试用例涵盖所有的条件。

通过连接圆圈产生测试用例，正如图11所示。

图11： 组合选项以建立测试用例

为了建立第一个测试用例，你可以挑选和组织任意方式。当你建立第二个测试用例，挑出没有在第一个案例中所使用的方式。继续添加测试用例直到所有的图标节点都被涵盖进去（如图11所示）。通常你需要从4到6个测试用例涵盖所有的应该测试的方式。然而，一些特别的情况会要求的更多。

测试用例的部署也同样可以组成测试用例部署矩阵图的形式。如表格4所示

步骤号 变量或选择 TC1 TC2 TC3 TC4 B1 站点 实际 URL 实际 URL 实际 URL 实际 URL B2 邮件地址 规则 允许的最少字符数(1 个字符) 允许的最多字符数(50 个字符) 规则 B2 密码 规则 允许的最少字符数(6 个字符) 允许的最多字符数(10 个字符) 允许的最少字符数(6 个字符) B3 查询串 规则 允许的最少字符数(1 个字符) 允许的最多字符数(300 个字符) 规则 B4 选择 首次选择 最后选择 首次选择 最后选择 B5 选择动作 加入购物卡 加入购物卡 加入购物卡 加入购物卡 B6 选择动作 进行结账 进行结账 进行结账 进行结账 B7 送货地址 确认地址信息 确认地址信息 确认地址信息 确认地址信息 B8 送货方式 5 天 3 天 2 天 当天晚上 B9 支付方式 确认信用卡信息 确认信用卡信息 确认信用卡信息 确认信用卡信息 B10 选择动作 下定单 下定单 下定单 下定单

表4： 测试用例部署矩阵图

表格4用矩阵图的形式描述了从图11的每个纵队所包含不同的测试用例。每行相对的是用户所键入的一个变量。

步骤4：给变量赋值

在这个步骤中，你可以替代一些占位符像是“一个非常长的名”或者“一个外延很长的电话号码”只留下真正有价值的，像是“Georgiamitsopolis”和"011-48 (242) 425-3456 ext. 1234" 。

在这个步骤中你同样把所有来自表格4中矩阵图的测试用例分割开来，针对每个测试用例分别形成表格。

针对书籍订单用例中的测试用例1，你就可以利用一个像表格5中所示的表。这样就会形成你给测试者的一个文件。测试者就会随着纵队2和3的方向向前，记录下纵队5、6、7的结果。

步骤号 变量或选择 值 期望结果 实际结果 通过/失败 备注 B1 站点 www.amazon.com 登录界面       B2 Email jsmith@hotmail.com -       B2 密码 密码 主页面       B3 查询串 "Rational" 书本列表       B4 选择书本 首次选择 书本详情       B5 选择动作 加入购物卡 购物卡内容       B6 选择动作 进行结账 地址提示       B7 送货地址 确认地址信息 送货提示       B8 送货方式 5 天 付款提示       B9 支付方式 确认信用卡信息 确认提示       B10 选择动作 下定单 订单号

表5：最终测试用例

一旦再次出现，RequisitePro会帮助你建立一个可追溯性关联。在产生了所有的测试用例后，你可以添加从场景到测试用例之间的可追溯性连接。

图12显示了所有的场景：源于不同的可分选择性连接的21个场景

图12： 可追溯性矩阵图

(点击这里放大)

在场景和测试用例之间建立可追溯性连接后，我们可以产生一个可追溯性根目录显示从用例到测试用例之间所有的方式。

这里有两个场景。第一场景——如图13所示——追踪用例外的，哪个在最高层次显示了用例，并追踪场景和测试用例。

图13： 用例的可追溯性根目录

(点击这里放大)

第二个方法是在测试用例中使用可追溯性连接，如图14中所示。在这个案例的根目录看起来有些不同：你可以从测试用例开始，然后往回追溯场景和用例。

图14： 测试用例的可追溯性根目录

(点击这里放大)

在输入进RequisitePro里需要花大量的时间，但是做这些可追溯性连接的其中一个最主要的原因是为了弄清当事物发生变化的时候相应的哪些应该进行重新测试。可追溯性和所谓的 可疑的关系，如图15所示，向你显示了由于先前的场景和用例发生改变那些测试用例也随之改变。

图15： 可疑关系

回页首

与IBM Rational Unified Process相连接

如何做这些与 IBM® Rational Unified Process® (RUP®)相连接的活动图？大多数都在过程早期的 初始或是 构建阶段 。在你刚刚得到用例时，我们就开始着手场景和测试用例。图16描述了在RUP中哪些地方最适合的活动。

图16： 与RUP阶段相连接的可追溯性活动图

当你着手场景和测试用例时，你可以给用例的设计者一些反馈和归纳所需的要求。这样有助于在过程的中尽早改变一些任务，最终对团队尽快完成项目做出贡献。测试用例要通过复杂阶段的使用，基本上贯穿整个建设阶段。

回页首

总结：

这篇文章描述了源于功能性测试用例到用例的方法。下面是关于这条途径的一些优点：

• 测试用例源于一种更加自动化的方式
• 避免了多重测试
• 较好的测试涵盖
• 简易了测试程序的监控
• 简易了测试者之间的工作负载平衡
• 简易了退后测试
• 通过从构建阶段到产品化阶段删除了一些以任务，从而减少了项目时间
• 为尽早发现要求的缺失做出了贡献

你所建立的测试用例可以用在人工测试，同样也可以用作自动化的测试工具像是 IBM® Rational Robot™。这种方法已经在若干项目中取得成功。

回页首

资源：

1. 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
2. Jim Heumann, "From Use Cases to Test Cases - Ensuring Quality from the Beginning." RUC 2001年。
3. Jim Heumann, "Using Use Cases to Create Test Cases." The Rational Edge, 2001年6月。
4. Dean Leffingwell 和 Don Widrig, "Managing Software Requirements: A Unified Approach". Addison-Wesley, 1999年。
5. Dean Leffingwell 和 Don Widrig, "The Role of Requirements Traceability in System Development", The Rational Edge, 2002年9月
6. Rational Unified Process. Rational 软件公司, 2001年。

点击这里查看本文最初的 RUC 介绍。

 

关于作者

		Peter Zielczynski has authored this article

posted on 2006-12-16 11:37 szdlinxie 阅读(316) 评论(0)  编辑 收藏 引用 所属分类: 测试技术杂志