复杂用例及其编写策略(珍藏版).pdf

复杂用例及其编写策略

1什么是复杂用例？

从直觉上来说，所谓复杂用例是指涉及的页面众多，页面之间的流转关系复杂的用

例。但是，这种说法仅仅是对复杂用例表象的粗糙感知，是不严谨的。

那么什么是复杂用例呢？这是一个首先需要回答的问题。

一般而言，一个用例可能涉及许多页面。但这并不意味着这些页面对用例的实现都是必

要的，对一个用例来说，必要页面是指那些为实现该用例，用户可以向系统提交数据，发

送请求的页面。

以此为基础，针对用例我们来看看页面之间的关系，共计有五种关系：

第一种：时序依赖关系

为实现一个用例，用户可能需要在多个页面向系统提交数据，发送请求。这些页面对

用例而言都是必要页面，它们之间的关系就称为时序依赖关系。

定义时序在前的页面为上位页面，时序在后的页面为下位页面。

第二种：回溯关系

处在下位页面时的用户，可能返回上位页面修改数据和请求。此时上位页面和下位页

面存在回溯关系。

回溯常常是必要的，因为有时用户在上位页面填写或提交了错误的或认为不合适数据

或请求，而这种情况直到用户链接到下位页面时才想到或发现，此时他可能想回去修改数

据或变一种请求方式。

第三种：数据依赖关系

用户为在一个页面完成向系统的一次数据提交或请求，他可能需要链接到其他页面去

提取相关数据。那么前后这两个页面对用例而言都是必要的，它们之间的关系称为数据依

赖关系。

定义链接到其他页面提取数据的页面为主页面，被链接提取数据的页面为次页面。

第四种：等价关系

用户向系统的一次数据提交或请求可以在不同的页面上完成，即在不同的页面可以完

成相同的数据提交或请求。这些不同的页面对用例来说都是必要的，它们之间的关系称为

等价关系。

等价关系常常意味着一个用例有2个或多个初始页面。

第五种：次关联关系。

对一个用例而言，其所有必要页面和其他页面之间的关系都称为次关联关系。

有了对页面关系的界定，我们下面就可以相对精确地定义复杂用例的概念了。

复杂用例：在与一个用例对应的一组必要页面中，如果页面之间存在着较多的时序依

赖关系、回溯关系、数据依赖关系或等价关系，就称该用例为复杂用例。

2问题是什么？

上面我们讨论了什么是复杂用例，这是我们探讨复杂用例的开始。

复杂用例因为它涉及的页面众多，页面之间关系复杂，所以如果需求分析师试图清晰地

描述用例实现的过程，往往需要面对许多困难。即便是写出来了，也难保读用例说明的人

不会感到费解、吃力。

需求分析师希望编写的用例，称为理想用例，其对应的页面流转图如图1所示。

图1理想用例的页面流转图

并且n的取值不要太大，根据经验，最好是不大于3。

此时页面之间仅仅存在时序依赖关系，不存在下位页面和上位页面间的回溯关系，主

页面和次页面之间的数据依赖关系，更不存在等价关系。

但这只是个理想，实际情况复杂的多，图2是一种极端情况。

图2复杂用例的页面流转图

此时，回溯关系、数据依赖关系、等价关系都存在，且n的值大于3。

问题是什么呢？

复杂用例的存在是客观的，不以人的意志为转移的。我们现在的问题就是如何像编写

理想用例一样编写复杂用例呢？

理想用例是不现实的，但它的意义在于指出了编写用例时应该突出过程的主线，一条

清晰的主线。

3问题与策略

有了问题，就要问如何解决这个问题。有了上面的铺垫，问题的解决就相对容易了，

根据经验，可以有如下四条策略：精简、封装、整合、裁减。下面一一述之。

第一条：简化

所谓精简，是指一方面在过程说明中不涉及对用例实现不必要的页面，另一方面不描

写下位页面和上位页面之间的回溯。将页面之间的回溯和次关联关系放到其他说明中去。

第二条：封装

所谓封装，是指将用户从主页面链接到次页面提取数据时与系统交互的过程提炼为一

个用例来看待，形成被包含用例或被扩展用例。

包含用例和扩展用例单独编写，并在包含用例的其他说明中注明可能涉及到的被包含

用例，在扩展用例的其他说明中注明可能涉及到的被扩展用例。

从而在包含用例或扩展用例中，我们只需要关心被包含用例或被扩展用例所能提供的

结果，至于具体的实现细节不需要再陈述和考虑，这和面向对象封装的思想是一致的。