在测试中使用用例的论点
用例多年来一直是软件开发人员的一种工具。一个用例清楚地描述了一个被指定的用户是如何执行一个指定的过程，从而向用户交付指定的结果的。正确地指定用例能够提供一个直接的连接，来帮助用户和开发人员开发一个系统用户需求的共同理解。它们是一个被证明有效的软件开发工具。

测试组织还应该充分利用用例提供的利益。测试人员是通过将用例转换为效率高的，有效的，阶段性适合的测试，从而充分利用用例执行带来利益的受益者。测试人员重新利用这些用例，对于用户和开发组织不需要额外的工作或者支出，为测试估计和测试用例的生成提供一个完备和一致的基础，将生成比预期更好的质量测试解决方案。

测试人员能够实现所有的这些利益，因为用例和相应的支持工件提供了根源和驱动，从而为测试人员在几个有疑问的区域创建了牢固的基础。因为用例早已经交付，并且它们能被项目上所有资源所理解，测试团队在这个项目中能够比用行项目需求收集方法更早地执行更加准确的测试估计工作。此外，用例驱动了更清楚的沟通，加强了这些用户需求开发的理解。它们的简单性改善了全球地域分布的风险，和虚拟解决方案交付团队。用例还提供了简化需求跟踪的机会，从而确保更完整的测试覆盖率。

测试团队能够利用新的用例，为增强覆盖率和有效性改善技术，同时获得更精确的范围定义和测试优先权。这些综合的利益终导致更有效，更严格的测试过程和更有预见性的测试结果。

由于用例提供了许多利益，测试组织应该积极主动地确保每个用例都能够被正确地构建。如果需要的话，这个项目团队应该能够管理一个或者几个用例的工作空间，包括在所有的测试阶段雇用测试编写人员。每个用例必须经历静态的测试来确保它包含清晰而且有利的信息，根据这些信息测试人员可以为指定的测试阶段构建适当的测试用例。通过重新使用构建良好的用例和支持性工件，测试组织能拥有目标明确的、有效的测试。

什么是用例？
自从20世纪八十年代中期，当这个概念第一次由 Ivar Jacobson 描述后生成了用例。 1 Jacobson 是一位早期基于组件设计概念的先锋者之一。他还是统一建模语言(UML) 和 IBM®Rational® Unified Process®，或者 RUP®的主要创始人。他感兴趣的是软件开发佳实践引导他开发用例概念，从而更好地识别和描述软件需求。

尽管这些用例的概念自从二十多年前已经生成，实际上许多软件从业者从没使用过它们或者甚至从来没有了解过他们。业务转型方法论越来越普遍，这很大程度上取决于过程规则，其实正在改变这个状况。普遍的工具比如 IBM Rational RequisitePro®(用来支持 RUP) 结合用例的生成作为需求定义过程的一部分。UML 的引入为软件描述设定了标准，已经进一步促进了用例的采用。

用例主要强调涉众需要这个系统交付什么，而不是描述如何实现终的结果。用例采用“黑盒”接近这个系统。 2 它应该陈述将要发生什么行为，但是并不陷入关于行为如何被实现的具体细节中。将一个用例看作是来自参与者观点导向的结果。只要结果被实现，这个参与者实际上并不真正在意这个行为是怎样执行的。因此，一个用例必须代表支持对参与者有重要价值的结果。

UML 将一个用例定义为“一个系统执行的一系列行为的描述，包括变量，它将生成特殊参与者所得值的可观测结果。” 3 当决定一个用例的构成时，这个“价值”的概念十分重要。如果您不想识别这个将由参与者识别的具体值，那么这个行为可能对一个用例来说不是一个很好的候选。 4

一个用例可以是图形的，也可以是文本的，但理论上两者都是用例。 5 用例可以创建为只读文本的格式，但是初都储存在像 Microsoft Word 这样的工具中。长期以来，在用例图中以图形的格式表示变得越来越普遍。使用 UML 和支持 RUP 的工具来构建用例模型是为常见的方法。这样的工具支持文本描述和支持图的多样性，从而更好地图解化此系统是如何被使用的。

用例图经常被分组来显示涉众们的需求集合（请看图 1中的例子）。在这个图中，任何一个直接与系统联系的单位通常都被看作是一个“参与者”。一个参与者可以是一个人或者代表一个或者多个人的角色。它还可以是另一个计算机系统。一个参与者通常由一个“人性图标”代表，即使当这个参与者是另一个计算机系统时也是这样。每个用例都由一个椭圆形代表，用描述这个用例将要执行什么样的行为的说明型陈述进行标注。这个陈述作为这个用例的名称。它应该简洁，但是描述的行为应该被执行。还可以绘制沟通连线来显示参与者与用例之间的关系。


图 1：用例图

用例可以由用例描述来支持，包括关键属性，比如先决条件，和一系列的事件。一个用例模型由这个用例的图，参与者定义构成，也可能包括这个用例的描述。 6

一个团队开发用例初目的是，识别用户涉众们想要从这个系统中获取的所有的核心功能。一旦他们确定了这些功能，这个团队可以开始展开每个关键功能相关的细节，他们也开始关注可能与每个被识别的用例相关的可选过程流程及例外条件。

在用例的开发过程中，通常假设这个核心功能将有一个正面的或者成功的结果。这通常被看作是“基本路径”或者“快乐路径”。例如，如果使用“搜索一个产品”，这个正面的结果将是被搜寻产品的结果。大量的可选择流程，包括例外情况和错误，也可能存在。比如，如果这个产品没有找到该怎么办呢？或者，这个产品目录所在的系统没有反映该怎么办呢？或者，一个消费者在这个搜索区域中键入了无效的信息该怎么办呢？这些还是有效的路径，应该在文档中可以获取。

用例文档细节的层次和类型在不同的组织或者公司中有很大的区别，甚至从一个项目到同一个组织中的另一个项目也有很大的差别。这些差别可能会受到许多不同因素的影响，包括这个项目的预算或者范围 (尤其当这个解决方案本质上是面向对象时)，可利用资源的技术组合，UML 的使用，以及 RUP 或者其它方法的使用。

正如上面所提到的，用例可能完全是不带支持的基于文本的图，或者它们可能仅仅使用简单的用例图来描述，如图 1所示。根据对象管理组织， UML 2.0 有十三种不同类型的图。 7 这些图被分成了三个类别：结构图，行为图，以及交互图。结构图，比如类图，代表静态应用软件的构架。行为图，比如用例和活动图，代表普通类型的行为。交互图，比如一系列的图，代表交互作用的不同方面。除了团队可以生成的各种图外，团队还可以创建其它支持型工件，比如一个词汇表或者特设需求文档（例如，一个非功能型的需求）。 8

一个项目用例的开发通常被看作是促进需求收集过程的一种方法，从而加速应用软件的开发。大多数出版物看起来似乎主要强调的用例的这些方面。而大多数软件测试出版物并不会参考用例，实际上这些用例在许多区域的驱动改善方面，对测试组织具有极其重要的价值。

用例对测试组织的利益
正如我们在下面部分将要显示的，用例为改善测试质量和效力提供了引人注目的利益。
估计估算

用例在测试估计领域提供了令人兴奋的机会。John Smith 9 详细说明了利用 Constructive Cost Model (COCOMO) 将一个用例转化为源代码行(SLOC) 的详细过程，反之，利用这个信息开发 Rough Order of Magnitude (ROM) 的估计。 10 这种方法的成功是假定那个低层次工作产品，比如构架和数据设计，先前已经生成了。 11

另一个估计技术，用例功能点(UCFP) 评估，是功能点计算方法的改编。它与 COCOMO 方法有相同的风险。由于支持评估的这两种比较旧的方法基础存在一定的缺陷，想连接细节层次与分解之间的鸿沟，被认为是很难有效地被克服。然而，由于 ROM 估计有被锁定的趋势，并在项目早期考虑到了后果，因此任何提供可靠信息的并且与测试估计相关的工具，在此过程早期仍然有一定的价值。

这个用例点方法(UCPM) 似乎为有效测试估计提供了高的潜能。这种方法的开发是建立在更新的设计方法基础上的，而不是被更新来处理用例的使用的。1992年 Gustov Karner 介绍过，这个评估是由用例的元素驱动的。 12 通过一些修改，这个方法可以直接被测试组织所利用。 13 如果测试组织被越多黑盒、工作流所驱动，主要的用例文档越能有效地在估计中运用。因此，有了 UCPM 用户的验证或者系统的整合，团队能够生成更精确的比其它测试阶段更早的评估。由于任何估计工具或者方法都会依赖于输入的准确度，历史的估计数据，当它们逐渐变得可利用时，将在这些评估技术中提供更高的信任度。

开发输入

用例能够促进开发测试组织所依赖的更高质量的输入和代码。由于用例开始具体化，这些用户或者参与者的需求也按照目的进行讨论。这个过程迫使开发者将重点集中在所使用的开发模式外部的功能需求之上。 14 这个方法将开发人员拉进用户的思维过程中 (比如，他们的目标)，开发人员能看到这种环境下的需求。这个过程将促使开发人员更彻底地了解这个系统将希望做什么，因此，能够向测试人员交付一个构建良好的解决方案。

尽管这个过程需要进一步的技术分析，但是这些用例能够为可靠的测试要求的输入到其它工作产品中而被分解。从这一点看，这些相关的或者黑盒情景已经被转换成白盒工具。 15 分析设计建模输出与驱动它的用例直接相连接。此外，用例驱动用户体验建模，为确保用户界面在整个解决方案过程中的一致性设置了相应的阶段。在面向对象的编程用例中，这些模型清楚地展示了连接到用例地类和方法。低层次文档中任何变更的影响都能够连接到返回到任何高层次用例。 16

可追溯性

在一个解决方案所有质量因素中关键的是跟踪开发和交付过程所有阶段的需求能力。IEEE 引用从一个工件到另一个工件的连接元素，并用这种定义作为这个练习中单纯证明。 17 用例能够定义前任继承者关系，并为驱动因素示例特征。

然而，对于可追溯性纯粹的经济变量是，它提供证明来执行一个具体的测试。大家都知道每个测试用例都可以被追溯，终到一个业务需求，测试计划者可以确保测试是由当前财政所负担的，而不是其它机构所负责。相反，这个方案的发起者能够直接识别这个方案正向他们提供业务价值的证据。

用例可以很大程度地提高一个测试人员的能力，从而调解开发缺陷清单。从请求者，到执行者，到验证者是一条线路。Booch et al. 的总结：在这个解决方案整个交付过程中没有沟通需求跟踪的已经制定好的标准。 18 关键的应用软件对于一个单一的需求如何连接到每个工件的通信相关性要求有更严格的方法。 19 然而，即使一个典型的非关键系统也应该要求相关性关系有简单的识别。这个将消费者需求转换成用例的基本过程在测试交付结果中提供了可跟踪性。当用例驱动方案测试时，您应该知道为什么要测试以及测试什么，为这个方案能够满足消费者期望提供信任度。

为适当的阶段开发适当的测试

没有用例，开发满足特定阶段目标的测试用例的问题将变成一个复杂而且模棱两可的运作，因为不同的测试团队会从相同的源文件中生成测试。这样会导致多余的或者不合适的测试和覆盖区域。有了用例驱动开发，每个测试水平使用工件的不同分组，从而有助于使测试保持在这个阶段适当的范围内。由于用例是根据用户目标来表达的，所以需要为执行所创建的额外的工件是方案更加完整。例如，当创建用例和支持性工件时，一个单元测试人员可以恢复合适的类来验证。对于功能测试人员，用例与支持性工件一起创建这个功能目的和有效测试输入的完整画面。他们能够访问通过查看设计信息支持的特殊值。系统集成测试阶段回到主要用例，识别整个用例中交替可变路径的合适编码。后，用户验收测试团队可以执行有效的直接回应解决方案问题的测试用例。

覆盖有效性

当利用这些用例模式时，测试人员可用更有效地设计和执行测试。用例模式允许测试人员从视觉上识别他们地测试用例，尤其是当这个过程包括一个用例图时。

有时它会被引用作为不同的分支、路径，或者变异性识别，在测试设计者识别各种方法的所有用例中，用户或者外部的系统都可以执行这个用例。在这个过程的这一点上，用例为识别有效测试，清除多余路径，以及在不用猜想的情况下设计黑盒测试提供了一个方法作为覆盖范围。通过识别整个用例的所有可变路径，测试人员能够指出在哪些地方路径覆盖了其它情景。覆盖的或者多余的路径是从计划测试用例执行库中清除的候选者。Clay Williams 通过研究行为和序列确定了一种优化测试用例生成的方法。 20 当清除多余区域时，叫作“Method and System for Generating an Optimized Suite of Test Cases”的用一种算法可以使覆盖区域达到少的测试用例。

无论是利用一种已经建立好方法，还是创建一种“民众的”方法来达到少复制更完整覆盖的目的，利用基于用例的方法比用行式项目需求方法有更大的优势。

优先级

将要执行的测试用例进行排序是测试组织十分关键的一种管理工具。有好几种确定优先级的方法，要选择合适方法，对于不同的项目、团队和开发方法有不同的方法。不管测试优先级是如何操作的，用例都会提供一个比旧的需求方法更精简的过程。

测试人员可能会通过考虑用户社区中功能的临界性来对测试优先性进行排序。用例通过允许发起者清楚地识别结果来支持这种方法，然后可以直接跟踪功能一直到这些结果。这样明显优于通过传统地分解行式项目需求的方法，传统的方法好像失去了焦点或者跟踪性，因为它需要的是一种多个步骤且并不直接的过程。

在传统的过程中，测试人员被迫将附有高水平用户结果的技术与需求团队连接起来。用这种方法决定测试优先权浪费时间而且容易出错，因为它需要将用户的心里印象和/或者多个测试用例的重组逆转回到发起者开始想要表达的的基于情景的目标。利用用例，这些容易出错的行为几乎不存在。因为它们直接映射到测试下功能想要的结果中， 测试可以很容易地被按照发起者先前建立的关键需求的顺序来排序。每个测试有了目标以后更容易被识别，优先级难的点变成了使业务发起者按照重要程度处理新的或者变更的功能的排序问题。

简单的处理测试用例优先权的方法是关键路径的识别。关键路径是为了解决方案对终的用户有价值而使面向用户的功能按照一定的顺序进行操作的需求。关键路径在回归测试和其它有严格时间控制的测试中十分有用。然而识别关键路径，尤其是对于有许多需求的大量释放，可以说是一项令人敬畏的任务。证明用例（尤其是用例图）十分有利是另一个区域的讨论范围。由于用例图开始识别正面的，或者“令人愉快的”，路径，然后分支显示可选的流程和例外条件，它们提供了一种识别整个应用软件中大多数直接路径的方法。这个技术还提供了允许快速决策的信息，这些信息是关于哪些可选流程和例外重要的。

用例实现打开了一扇通往更精细更有潜在可能性的有效优先权测试方法的门。例如，ranTest initiative for Software Engineering 2006 利用加权特殊标准的用例。 21 ranTest 技术针对发布版本完全使用了用例，并静态地对它们进行优先权排序。然后测试组织按照那个顺序来执行测试用例。预算或者时间表如果没有覆盖整个测试单元，那个会省略一些关键的用例。 此外，这个技术还支持动态的优先排序。当在基于静态的优先级团队执行识别的测试时，风险区域也会被识别。这样，测试用例优先权的第二层也被创建，它重点是证明关键的功能是与高可靠性并存的。终的产品是一种有效的测试方法，提供了确保解决方案能够满足消费者目标需求具体水平的有效测试方法。

用例还提高了缺陷优先处理的精确度。当一个测试失败了，基于用例的方法可以迅速确定问题的分类和优先权，因为这个用例的整体重要性已经被建立。测试人员可以直接依赖发起者在制定需求规范时赋予这个具体用例的值，而不是对缺陷进行主观地评估。缺陷优先排序几乎变成瞬间而且无可争议了。而且，在缺陷发现和它的优先权确定的时间也大大减少了。

应对全球化资源挑战

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

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

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

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

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

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

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

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

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