【IT168 技术文章】

    理解测试和质量保证组织是如何通过使用用例技术来提高测试质量的。
 
    测试组织通过利用用例的优势可以实现测试质量的重要利益。几年来，开发人员和业务分析人员一直利用用例模式来捕获需求。测试组织能够通过利用这些相同的用例技术获得巨大的利益。构建良好的用例能够以有效率的，易于跟踪的，以及评估准确性的方式为测试任务提供价值。它们还可以转移部分全球部署虚拟团队的风险。但是从数量上来看，最大的利益则在测试用例的生成中。

    对于识别和创建单元、功能、系统集成，以及用户验收测试来说，用例和相应的支持工件是价值无法估量的驱动。每个测试水平都有唯一的不同输入设置的目标和需求来达到可靠的测试覆盖率，但是所有的测试水平都能够从这个项目的用例中获取一定的价值。通过执行用例方法、工作空间，以及评审，测试组织能够交付定义良好的测试，同时能够获得更高的准确性和更高的效率。

    在测试中使用用例的论点

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

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

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

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

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

    什么是用例？

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

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

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

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

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

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

 
图 1：用例图

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

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

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

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

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

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