从用例到测试用例的追踪 3
信用卡有效日期的格式在美国和加拿大就不同
如果我们测试数字，我们会考虑以下选项：
常规的以及从应用观点上是合理的数字
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：将待测试选项合并到测试用例中
在前面的步骤，你确定了所有的选项。在此步骤，你需要在一系列的测试用例中使它们结合在一起。
图 10用图描述了测试的选项。每一个纵队都有一个需要测试的变量，每一行是一个选项：R 是正常， E 是空, 然后是一个字符，50个字符，51个字符，等等。 "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 描述了图11中每列包含不同的测试用例。每一行相应的是用户输入的变量。
步骤 4：为变量赋值
在此步中，你替换如"一个非常长的名字" 或"扩展很长的电话号码"这样的占位符为像"Georgiamitsopolis" 和 "011-48 (242) 425-3456 ext. 1234"这样实际有价值的东西。在此步，你还可以分裂表 4所示的表格中的测试用例，为每个测试用例创建独立的表格。
如书籍订购使用用例的测试用例 1，你就可以创建一个像表 5这样的表格。这就给你的测试者创建一个文档。测试者将跟随总队2和3的方向，并且记录纵队5，6，7的结果。
表 5：最终的测试用例
| 步骤号 | 变量或选择 | 值 | 预期结果 | 实际结果 | 通过/失败 | 注解 |
|---|---|---|---|---|---|---|
| B1 | 网站 | www.amazon.com | 登陆界面 | |||
| B2 | 电子邮件地址 | jsmith@hotmail.com | ||||
| B2 | 密码 | Johnsm | 主界面 | |||
| B3 | 搜索字符串 | “Rational” | 书本列表 | |||
| B4 | 书本选择 | 第一次选择 | 书本详情 | |||
| B5 | 行为选择 | 添加到购物车中 | 购物车的内容 | |||
| B6 | 行为选择 | 进行结帐 | 地址提示 | |||
| B7 | 送货地址 | 确认地址信息 | 送货提示 | |||
| B8 | 购物方式 | 5 天 | 支付提示 | |||
| B9 | 支付方法 | 确认信用卡信息 | 确认提示 | |||
| B10 | 行为选择 | 下订单 | 订单号 |
RequisitePro再一次帮助你创建追踪关系。在产生了全部的测试用例以后，你可以设置从场景到测试用例的追踪。
图 12显示了全部的场景：从不同的可选流程合并中产生21个场景。
图12 ：追踪矩阵
在设置了场景和测试用例之间的追踪关系后，我们可以创建一个显示从用例到测试用例全部追踪方法的追踪树。
