从用例到测试用例的追踪 2
在创建一个测试用例之前，你需要为所给用例确定全部的场景。一个场景是用例的一个实例。它描述了一个贯穿事件流的特殊路径。图 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
不同的国家有不同的规则
