应对全球化资源挑战

    在一个特定的市场，业务往来发生在文化和法律框架之中。法定的市场行为证明，最接近的文化之外的非常好的成功机会是在类似的文化或者文化体系中。这个行为与当前从全球外包开发和测试的软件交付模式是相冲突的，并经常导致用户和开发者之间的误解。这种继续向更复杂和过程驱动解决方案移动的行为将增加用户和开发者之间“断开”的风险。这些条件联合起来使保证这个方案能适合目标市场的风险变得更加复杂。

    正如 Bittner 和 Spence 指出那样，“用例通过让我们从视觉上明白这个系统将要做什么以及如何利用它来进行操作。”通过使用用例，全球的测试资源挽回一些在跨越文化边境的过程中可能丢失的文化。它们对业务目标有更充分的认识，从而促进应用软件将要被投放的具体市场的需求。

    用例使用户在需求过程中操作，并允许他们与测试人员进行清楚地沟通，了解这个方案是否准确地针对目标市场。这种理解与传统表达需求的方式在不同的个体之间有很大的差别。因为反映具体结果的用例早就被交付，一个全球测试团队有足够的时间来开拓对这个用户目标良好的理解。前面额外的时间允许测试人员来验证他们对实现和想要的结果的理解。当出现这样的挑战因素时，如不能可视化地与需求所有者沟通，不同的时间区域，以及产品将要服务的市场确保功能和性能的挑战，所测试的内容和所交付的内容以及业务真正所需要的时间空缺将十分引人注目。当利用全球性资源团队来交付方案时，用例会提供降低这种需求到实现“转换”风险的动力。

    创建测试用例

    用例实现对测试组织最大的影响是在测试用例的创建过程中。用例创建直接输入到一些高水平测试中去。对于验收测试，当被适当地执行时，用例缩小了测试人员 概念化和用户目标现实之间的距离。尽管最初可交付成果对于单元测试人员是临界值，但是缺乏细节迫使这个方案交付团队随后创建包含低水平测试所必须的输入的支持性工件，比如单元测试。实际上，每个测试阶段都有权输入此阶段或者其它阶段明晰目标所需的合适且完整的信息。此外，由于他们特殊的本质，这些输入十分清晰，而且这些信息很容易就可以转化成适当的测试阶段的测试用例。测试人员不会因为为他们特定的测试阶段而在整个较大的，包括所有类型的文件中搜寻而心烦意乱。这些结果是拥有更好的代码和更好目标的测试。

    一般来说，从一个用例驱动方法来创建测试用例包括以下四个基本步骤：

    识别场景
    识别变量
    为效率和完整性调整适当的覆盖率
    分配数据输入
 
    并不是所有的测试水平都以相同的方式来达到以上的步骤的。下面的部分描述了怎样为用例模型驱动的项目的测试阶段创建合适的测试用例

    为用户验收测试创建测试用例

    因为用例包括参与者真实语言的目标信息，用户验收的测试用例可以在为其它测试阶段创建测试之前编写。用例是从用户的角度来定义的，而不是系统的内部活动，因此验收测试可以直接从用例中创建。此外，用例非常适合于用户验收测试，因为需要验收测试用例来模拟最初从系统涉众中抽取的情景。就像 Lee Copeland 指出的，用例最适合端到端的黑盒测试——更准确地说，是在用户验收测试被执行的条件下。

    验收测试的测试用例的生成在不同的测试阶段是不同的，这是由于这个和其它测试水平潜在的前提之间存在一些明显偏差所导致的。验收测试存在于生命周期的这样一个点上，技术测试团队已经得出此应用软件已经完整且准备交付给消费者了。单个的测试用例是由用例驱动的，而不是附加的，非功能性需求规格。测试用例是上游测试的不同子集。另一个区别是验收团队是通过将最终的结果看作方案完整性来达到获取测试结果的。最后，这个测试人员很像一个“非技术的”普通涉众，并不期望了解潜在的构架，但是要十分熟悉测试中转换描述的目的。

    由于用例是透明且独立于系统，所以对于测试阶段，他们将丢失一些关键的细节信息。用户验收测试用例编写者并不希望用例中有具体的数据。然而，当 Copeland 清楚地被识别时，处理测试，一个验收测试之下的类别失败了，很显然它是依靠数据的。Boris Beizer 支持数据的临界性，规定其生成、捕获，以及用百分之三十到四十的工作来提取数据帐户。这样引导出这样的问题：验收测试到底需要多少具体的数据和脚本。我们的立场是，附有具体数据输入的具体脚本和违反直觉运行用户验收测试总体目标的用户界面步骤是测试用例脚本不需要的。Cem Kaner 和 James Bach 宣称“如果一个脚本的工作是可重复性的，我们可以将这些工作委托给廉价的劳动力。” 有了由超级用户，优异装备或者其它主要领域专家组成的验收团队，用户验收测试用例将不需要低水平用户界面或者类细节。根据这个用例的目标，在测试用例的前置条件或者设置中还需要一些数据输入。

    要开始创建测试用例，用户验收测试资源将需要查看这个用例的流程图。在图 2中，这个基本流程，或者快乐路径，径直穿过这个图。这个可选的流程将被取消。这些代表了额外的测试用例。

 
图 2：用例的流程图

    当从一个带有少量路径的用例开始工作时，您可以合情合理地期望用户验收测试执行所有地路径。对于包含许多可选情景和变量，或者对于那些连接到其它用例的用例来说，为每一个路径进行测试几乎是不可能的。尤其是对非关键的应用软件，这样的路径就好像不被业务用例所支持。此外，这些路径中很多可能是多余的或者甚至是无效的。

    McGregor 和 Major 提供了一种对测试用例筛选可管理的方法，这对用户验收测试社区有格外的吸引力。作者描绘了不用种类的用户，创建了可操作的配置文件。一般采取操作剖面图来筛选路径的方法实际上是优化验收水平测试最好的方法。为了使适合那些操作剖面图的用户执行，测试用例的合成子集将向发起者提供这样的保证：所有的用户社区都可以利用这种方案来达到定期的目标。同时，操作剖面图是一种优化或者减少测试筛选的工具。根据这个测试阶段的目标来看，循环和例外的路径并不是需要的覆盖范围，除非这样的路径通常是由用户社区中一些人执行的。