在创建一个测试用例之前,你需要为所给用例确定全部的场景。一个场景是用例的一个实例。它描述了一个贯穿事件流的特殊路径。图 6是一个假设的图表,它描绘了一个拥有基本流程B和可选流程A1, A2, A3, A4的用例。为了找到全部的场景,我们需要画出贯穿于此图的所有场景。
图6. 在用例中找到场景
每一个可选流程都有一个场景,并且每个结合的可选流程都有一个场景。显然,这里场景多于可选流程,因为一个场景用于A1,另一个场景用于A2,还有一个场景用于这两个的结合。
描述场景最简单的方法是提供一系列的可选流程,例如,做两遍流程A2,然后做一遍流程A6:
SC16:A2,A2,A6。
另一种描述场景的方法是列出它的所有步骤,但是这种方法既困难又未必详细。
如果你陷了无限循环(向后循环),这时该怎么办?理论上它将产生无限的场景。图 7显示了一个无限循环。
图7. 无限循环。
最合理的方法是做一遍基本流程,一遍循环流程,然后再做一遍循环流程。如果程序能为这两个循环都工作的话,你能假设它能为所有的循环工作。
书籍订阅的例子中包含了一个基本流程和8个可选流程。它们中的4个向前走,另外4个向后走。如果你想描述全部可能的用例结合,你将有超过4000个场景 (这里有8个可选流程,我们想让其中4个做两次,因为他们向后循环,所以是2的(8+4)次幂,,等于4096。很明显,我们不需要把他们全部做完。
选择能代表这四千个场景的一个合理子集。通常,明智的做法是选择一个基础流程,一个覆盖了每一个可选流程的场景,以及一些合理的可选流程的结合。使用表 1的例子,做一个包含流程A1和A7的场景也许没有什么意义,因为它们在图标上分隔太远以至于不能互相影响。但是,做A1和A2是有意义的,因为他们互相紧埃,之间互相影响。
表 2 图解了选择的场景:一个代表基本流程,8个代表每一个可选流程,6个反射可一些流程的结合(特别是那些拥有两个距离很近的向后循环)。
以下15个场景值得测试:
表2. 值得测试的场景
表2:获取选择的场景 | |
---|---|
场景 1 基础流程 | 场景 9 A8 |
场景 2 A1 | changjing 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 |
在RequisitePro中如何创建一个场景
在RequisitePro中场景不是一个标准的需求类型,所以你需要增加它成为一个新的需求种类。为了完成它,去Project Properties,选择Requirement Types 标签,然后点击 Add。接下来,填充到适当的区域 (如图 8所示),然后点击OK。
图8. 增加一个需求类型场景
创建了这个需求类型之后,我们应当输入全部的场景并设置从用例到这些场景的追踪,如图 9所示。
图9. 从用例到场景的追踪
在RequisitePro中,你可以用用例的名字和一系列可选流程的名字为场景命名(例如:UC1, A6, A7)。
既然你有了所有的场景,你就需要获得测试用例。这里需要完成4个步骤:
为用例的每个步骤确定变量
为每个变量有效地确定不同的选项
在测试用例中测试结合选项
为变量赋值
以下部分描述了这些步骤的细节。
步骤1:为每个用例步骤确定变量
在所给场景的所有步骤中你需要确定全部输入的变量。例如,在某些步骤中,如果用户输入了用户ID和密码,这就产生了两个变量。一个变量是用户ID,另一个变量是密码。变量也可以被用户选择(例如,保存更改或取消)。
这里是书籍订购例子的全部变量:
在步骤B2中,这里有两个变量:电子邮件地址和密码。它们全是字符串。在步骤B3中,搜索一本书,这个变量是一个搜索字符串,因此它也是字符串。 在步骤B4,我们需要从系统返回的目录中选择一本书。在步骤 B8中,我们需要选择送货方式。Amazon.com 提供了4个选择。
步骤2:为每个变量有效地确定不同的选项
如果它们引发不同的系统行为,选项将是"明显不同的"。例如,如果我们选择大概6到10的字符长的用户id,以下的输入显然是不同的 :
Alex ——因为太短,我们希望显示一个错误的信息
Alexandria ——因为它是一个有效的用户id
Alexandrena ——因为太长,我们期待系统可以阻止我们输入如此长的id
然而,"Alexandria" 和 "JohnGordon" 却不是明显不同,因为它们都是有效的用户id,可以使系统有相同的反应。
以下的指导方针描述了一些特殊的例子。
一个选项可以认为是非常不同的,如果:
它引发了不同的程序流程 (通常是一个可选流程)
例如
输入无效的密码将会引发可选流程2
它引发不同的错误信息
例如
如果电子邮件太长,信息就会是 "电子邮件应当在50个字符以内"
如果电子邮件没有包含 @ 符号,信息就会是:"无效的电子邮件地址"
它显示了不同的用户界面
例如
如果付费的方式是信用卡,在区域里显示的是信用卡号输入号码,产品有效期和持卡人的姓名。
它使得在下框中有不同的选则可以使用
例如
顾客注册界面包含了 "国家和州/省"的下拉框。"州/省"的下拉框一般是基于国家的选择:比如美国,它包含了全部的州,加拿大是全部的省,其他国家是缺省的。它创建了3个不同的选项:
美国
加拿大
其它国家
一些商业规则的输入
例如
假设这里已有一项规则 "如果实下午6点以后下订单是,用户选择头天晚上送货,将会通知这本书将会在后天到达。",我们有两个:独立的选择
头天晚上发货,在下午6点之前下订单
头天晚上发货,在下午6点以后下订单
这里有一个边缘情况
例如
因为密码应当包含至少6个字符,我们因该测试:
5个字符的密码
6个字符的密码
改变某些事情对使用默认
例如
在信用卡支付界面,持卡人的名字通常是订货人的姓名。这就产生了2个独立的选项:
保持默认持卡人的姓名
改变持卡人的姓名
没有明确定义输入格式,不同的用户有不同的理解
例如
不同的人有不同的书写电话号码的方法:
使用括号 (973) 123 4567
使用破折号 973-123-4567
数字间使用空格 973 123 4567
不同的国家有不同的规则