用例图经常被分组来显示涉众们的需求集合(请看图 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 用例能够定义前任继承者关系，并为驱动因素示例特征。
文章来源于领测软件测试网 https://www.ltesting.net/
