从用例到测试用例的追踪(2)

发表于:2015-09-08来源:uml.org.cn作者:不详点击数: 标签:测试用例
用例的通用格式是: 简要描述 事件流 基本流程 可选流程 1 可选流程 2 特殊需求 前提条件 后置条件 扩展点 环境图 活动图 基本流程包括最通常的一系列

  用例的通用格式是:

  简要描述

  事件流

  基本流程

  可选流程 1

  可选流程 2

  特殊需求

  前提条件

  后置条件

  扩展点

  环境图

  活动图

  基本流程包括最通常的一系列行为,此步骤发生在每件事正确运转的时候。可选流程表现了流程的变更,包括不很普遍的情况和错误条件。环境图是用例图的一部分,向参与者和其它用例显示了特殊用例之间的关联。活动图是一个解释用例的流程图。环境图和活动图不是必须的,但是可以帮助你可视化用例和它在项目中的位置。

  在我们的在线书店项目中,用例的基本流程的安置顺序也许像这样:

  B1 用户在浏览器输入网站的地址

  系统显示登陆界面。

  B2 用户输入电子邮件地址和密码。

  系统确认正确的登陆,显示主页,并且提示输入搜索字符串

  B3 用户输入搜索字符串—书名的一部分。

  系统返回与搜索标准匹配的全部书籍。

  B4 用户选择一本书。

  系统显示这本书的详细信息。

  B5 用户把这本书放在购物车中。

  购物车中的货物显示给用户

  B6 用户选择"进入到结帐" 选项。

  系统索要送货地址。

  B7 用户确认送货地址。

  系统显示送货选项。

  B8 用户选择送货选项。

  系统询问使用哪种信用卡。

  B9 用户确认储存在系统中的信用卡。

  系统请求最终确认此次订购。

  B10 用户订购。

  系统返回确认数量。

  除了基本流程以外,还有许多可选流程。例如,第一个可选流程描述了当用户是一个新的用户时所发生的事情(不是在线书店的已注册用户)。在基本流程中,用户经常拥有一个用户ID和密码。相反,可选流程 1 描述了当第一次用用户需要注册并提供顾客数据时的情况。可选流程的另一个例子是无效的密码。用户输入了错误的密码,系统显示错误信息。

  表 1 显示了"安置顺序"用例中的可选流程:

  下列约定用于为事件流命名:

  基本流程:B

  可选流程:A1,A2, A3,...

  在基本流程中的步骤:B1,B2, B3, ...

  在可选流程1中的步骤:A1.1, A1.2, A1.3, ...

  在可选流程2中的步骤: A2.1, A2.2, A2.3, ...

  为得到可选流程,使用活动图 5。图 5显示了描述用例的活动图。

  图5. 活动图

  基本流程是一条向下的直线,然而可选流程可以是向前或向后的循环线。

  如何从用例创建测试用例

  在创建一个测试用例之前,你需要为所给用例确定全部的场景。一个场景是用例的一个实例。它描述了一个贯穿事件流的特殊路径。图 6是一个假设的图表,它描绘了一个拥有基本流程B和可选流程A1, A2, A3, A4的用例。为了找到全部的场景,我们需要画出贯穿于此图的所有场景。

  图6. 在用例中找到场景

  每一个可选流程都有一个场景,并且每个结合的可选流程都有一个场景。显然,这里场景多于可选流程,因为一个场景用于A1,另一个场景用于A2,还有一个场景用于这两个的结合。

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

  SC16:A2,A2,A6。

  另一种描述场景的方法是列出它的所有步骤,但是这种方法既困难又未必详细。

  如果你陷了无限循环(向后循环),这时该怎么办?理论上它将产生无限的场景。图 7显示了一个无限循环。

  图7. 无限循环。

  最合理的方法是做一遍基本流程,一遍循环流程,然后再做一遍循环流程。如果程序能为这两个循环都工作的话,你能假设它能为所有的循环工作。

原文转自:http://www.uml.org.cn/Test/200607073.htm