软件测试用例建模指南[3]

软件测试用例建模指南[3] 软件测试用例

关键字：用例建模 指南

　　2.3 描述用例规约

　　应该避免这样一种误解――认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。除此之外，我们还需要描述每一个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述――用例规约所组成的。RUP中提供了用例规约的模板，每一个用例的用例规约都应该包含以下内容：

　　简要说明 (Brief Description)

　　简要介绍该用例的作用和目的。

　　事件流 (Flow of Event)

　　包括基本流和备选流，事件流应该表示出所有的场景。

　　用例场景 (Use-Case Scenario)

　　包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。

　　特殊需求 (Special Requirement)

　　描述与该用例相关的非功能性需求(包括性能、可靠性、可用性和可扩展性等)和设计约束(所使用的操作系统、开发工具等)。

　　前置条件 (Pre-Condition)

　　执行用例之前系统必须所处的状态。

　　后置条件 (Post-Condition)

　　用例执行完毕后系统可能处于的一组状态。

　　用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也可以选择使用状态图、活动图或序列图来辅助说明。只要有助于表达的简洁明了，就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如活动图有助于描述复杂的决策流程，状态转移图有助于描述与状态相关的系统行为，序列图适合于描述基于时间顺序的消息传递。

　　2.3.1 基本流

　　基本流描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。我们建议用以下格式来描述基本流：

　　(1) 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。

　　(2) 用一句简短的标题来概括每一步骤的主要内容，这样阅读者可以通过浏览标题来快速地了解用例的主要步骤。在用例建模的早期，我们也只需要描述到事件流步骤标题这一层，以免过早地陷入到用例描述的细节中去。

　　(3) 当整个用例模型基本稳定之后，我们再针对每一步骤详细描述参与者和系统之间所发生的交互。建议采用双向(roundtrip)描述法来保证描述的完整性，即每一步骤都需要从正反两个方面来描述:(1)参与者向系统提交了什么信息;(2)对此系统有什么样的响应。具体例子请参见附录。

　　在描述参与者和系统之间的信息交换时，需指出来回传递的具体信息。例如，只表述参与者输入了客户信息就不够明确，最好明确地说参与者输入了客户姓名和地址。通常可以利用词汇表让用例的复杂性保持在可控范围内，可以在词汇表中定义客户信息等内容，使用例不至于陷入过多的细节。

原文转自：http://www.ltesting.net