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

　　美国

　　加拿大

　　其它国家

　　一些商业规则的输入例如

　　假设这里已有一项规则 "如果实下午6点以后下订单是，用户选择头天晚上送货，将会通知这本书将会在后天到达。"，我们有两个：独立的选择

　　头天晚上发货，在下午6点之前下订单

　　头天晚上发货，在下午6点以后下订单

　　这里有一个边缘情况例如

　　因为密码应当包含至少6个字符，我们因该测试：

　　5个字符的密码

　　6个字符的密码

　　改变某些事情对使用默认例如

　　在信用卡支付界面，持卡人的名字通常是订货人的姓名。这就产生了2个独立的选项：

　　保持默认持卡人的姓名

　　改变持卡人的姓名

　　没有明确定义输入格式，不同的用户有不同的理解例如

　　不同的人有不同的书写电话号码的方法：

　　使用括号 (973) 123 4567

　　使用破折号 973-123-4567

　　数字间使用空格 973 123 4567

　　不同的国家有不同的规则例如

　　信用卡有效日期的格式在美国和加拿大就不同

　　如果我们测试数字，我们会考虑以下选项：

　　常规的以及从应用观点上是合理的数字

　　0

　　负数

　　带两位小数的数字

　　能输入的最大数字(99999999999999 - 输入最多的9)

　　你怎么知道区域内能够输入的最大和最小的长度?这个需求可以从不同的来源得到。有时，它来自于商业的分析或顾客。例如，如果我们输入Dun 和 Bradstreet 数字，这就被看成是一个公司，它总是包含9个数字。这是商业的需求。

　　然而，它一般不会来自于顾客和用户。如果你问客户姓名区域有多长，它们会告诉你不用担心长度，只要要合理即可。在此例中，设计步骤决定了变量的长度而不是需求步骤所决定的。

　　另一种情形，数据分析师或者数据库设计者会提出建议——例如，在如果公司的全部应用软件中姓名应在30个字符以内，你的申请的用户名就得依照这个标准。

　　不管需求的来源是何处，在我们做测试用例之前它都要被同意并且备份。

　　这里有一个关于上述讨论的需求应该在哪里进行文档化的问题。在用例中一个增加这个需求的地方是被称为 Special Requirements的地方。另外一个可以放置这种需求的地方是术语表或者数据字典。另外，你可以详细说明一个独立的文档类型，在那里你可以描述全部应用程序中的所有变量。在许多用例中如果同样的变量出现在许多界面中时，这就变得特别有意义，因此你可以在一个文档里说的所有名字截止在30个字符以内，全部的地址截至在100个字符以内。然而，如它们对一个用例是特殊的，最好把它们加到那个用例的特殊需求中。

　　表 3显示了在示例项目的基础数据流程中为变量确定的选项：

　　步骤 3：将待测试选项合并到测试用例中

　　在前面的步骤，你确定了所有的选项。在此步骤，你需要在一系列的测试用例中使它们结合在一起。

　　图 10用图描述了测试的选项。每一个纵队都有一个需要测试的变量，每一行是一个选项：R 是正常， E 是空, 然后是一个字符，50个字符，51个字符，等等。 "L" 代表非常大， "I" 代表非法的。

　　图 10：每个步骤的待测试选项

　　后面有妨碍的选项把用户从基本流程中抛离出去：它们表示在可选流程中描述的一些错误。因为你一般为第一个场景设计特殊用例，所以你可以移动它们(在一些其它的场景中测试它们)。 无论剩下了什么，你需要创建最小数量的覆盖全部情形的测试用例。

　　通过连接圈创建测试用例，如图 11所示。

　　图 11：合并选项以创建测试用例

　　为了创建第一个测试用例，你可以选择并连接任何选项。当你创建第二个测试用例时，跳出第一个用例没有使用的选项。继续增加测试用例直到全部图的节点(如图 11所示)被覆盖。通常你需要从4到6测试用例去覆盖全部需要测试的选项。然而，一些特殊的情形需要的更多。

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