摘 要： 本文通过对测试原则与用况驱动思想的分析，提出了用况驱动系统测试用例设计的思想。从功能性测试、性能测试、回归测试等三方面，阐述了该思想在测试用例设计过程中的必要性和应用方式。并重点以功能性测试为例，给出一些该思想应用于实践的方法和经验。
关键词： 用况驱动；系统测试；测试用例设计

一、 系统测试用例设计原则和优点

软件测试是为了发现错误而执行程序的过程，一般来说横跨软件生命周期的两个阶段：开发阶段和测试阶段。其中开发阶段的测试工作主要是指单元测试和集成测试，一般由开发人员完成；测试阶段是软件生命周期的一个独立阶段，主要的任务是进行系统测试，由专门的测试人员完成。无论单元集成测试，还是系统测试，都应该进行必要的测试用例设计，本文的侧重点在于系统测试的用例设计。

系统测试在待测系统组装到一起并通过了单元和集成测试之后进行，一般采用黑盒测试的方式，侧重于测试软件的功能性需求，兼顾性能、压力等各方面的因素。系统测试的意图在于发现系统与用户期望的差距，通过测试暴露出软件中隐藏的错误和缺陷，权衡并改进系统。Davis曾经提出了一组测试原则，其中包括两点：一是所有测试都应该可以追溯到用户需求；二是穷举测试是不可能的。[1]

正如我们所知，软件测试的目的在于发现错误，而最严重的错误莫过于导致程序无法满足需求的错误。因此测试用例的设计必须充分考虑用户需求，是否正确的满足了用户需求是判别一个软件系统是否能够通过测试，是否合格产品的最重要标准。在实际的测试工作中，追求系统测试用例对用户明示和隐含需求的100%覆盖，试图穷举用户需求进行测试是不现实的。系统测试用例的设计原则应该是尽可能覆盖用户工作中使用本系统的各种工作场景和情况（包括正常方式使用和异常方式使用的情况），至少应完全覆盖用户日常工作使用系统的全部场景和情况。

用况驱动（Use-Case Driven）是统一过程（UP）[2]的核心思想之一，也是其精髓所在。统一过程的目标是指导开发人员有效的实现并实施满足用户需求的系统。统一过程一般被认为是一种OO（面向对象）开发方法，实际上它的思想也同样支持非OO系统的开发。统一过程特点在于：用况驱动、以框架为中心、迭代和增量的。

用况（Use-Case）的目的在于捕获真正的需求和使用适于用户、客户、开发、测试等各方人员理解的形式将捕获到的需求加以描述。它几乎普遍用于捕获软件系统需求。但它的作用不仅如此，还能够驱动整个开发过程，在寻找和确定类、子系统和接口、寻找和确定测试用例、规划开发迭代和系统集成时，均可以将用况作为主要输入。因而可以毫不夸张地说，在应用统一过程思想指导软件开发过程中，用况的驱动作用贯穿整个软件生命周期。

用况驱动设计与开发过程的思想，目前已被软件业内人士广泛接受，并越来越多地付诸于实践；而用况驱动思想在测试领域的实践中却并未得到应有的重视。我们的测试团队也经历了一个对此思想逐步认知的过程，在工作实践中积累了一些相关的思路和方法，并且还在继续摸索，希望能对测试过程持续改进。
与传统系统测试用例设计相比，强调用况驱动的思想会体现出一定的优越性。

首先，利于系统测试用例贴近用户需求。用况描述用户对系统的期望和真正的需求，这恰恰与系统测试的主要目标不谋而合。因此系统测试用例的设计由用况驱动，以用况为输入，实现对用况的追踪与覆盖，是确保系统测试用例设计满足功能和场景覆盖，达到系统测试用例设计的质量要求的捷径。

其次，便于与其它小组沟通，便于对用户需求实施追踪。若该项目的需求、设计、开发、维护等过程同样以统一过程思想、用况驱动的思想作为指导，则在整个项目内部更易形成沟通，在该软件系统生命周期涉及到的各个产物之间能很容易的进行追踪。将以用况为指导形成的系统测试用例应用于测试活动，得到的测试结果直接体现用户需求的实施情况。

二、用况驱动系统测试用例设计实践

用况是需求分析阶段的产物，系统测试用例的质量在一定程度上依赖于用况的质量，只有用况描述的真实、全面、易理解，系统测试用例才有可能达到相应的质量目标。

对于系统测试的分类，业界有很多种说法，不尽相同。最常见的包括：功能性测试、性能测试、回归测试等。下面将主要就功能性测试，说明用况驱动思想在其测试用例设计过程中的作用；同时说明用况驱动思想对性能测试和回归测试用例选取原则的影响。

1．功能性测试

（1）用况驱动功能性测试的组成

传统概念中的功能性测试和性能测试主要是针对功能点进行的，这主要源于传统的软件功能相对单一、独立。当前软件发展趋势，越来越综合化、系统化、全面化，软件系统越来越庞大、复杂，单一、割裂的功能点往往难以满足用户实际需求，将各功能点按用户实际使用场景，以不同的顺序组合起来，才能真正满足用户实际应用的需要。换言之，用户的需求可以体现为一个个用况，而用况在系统中的实现则体现为功能点的有序组合。

传统意义上，功能性测试用例，一般会针对功能点设计，经历从功能点到测试点、再到测试用例的逐步细化、扩充的过程。而用况驱动的功能性测试，除了包含对基于功能点的测试外，还包括对基于场景（用况）的测试。

基于功能点的测试是用况驱动功能性测试的基础，只有通过了基于功能点的测试（通过的意义并不是完全没有缺陷），基于场景测试的实施才是有意义的。因此基于功能点的测试应该是基于场景测试的“前传”。从功能点到测试点的扩充，是基于对该功能在各种场景应用中可能出现的使用、操作上的正向、反向分支的考虑，是该功能测试中所应关注的关键点的体现。从测试点到测试用例的扩充，则主要是对该测试点的不同情况、取值等的考虑，以及对测试中一些细节的描述。

基于场景的测试更倾向于对软件系统能否满足用户需求进行测试，关心用户做什么而不是产品做什么，它意味着通过用况捕获用户必须完成的任务，然后测试时应用它们或它们的变体。基于场景的测试往往在单个测试中处理多个子系统。正如目前软件行业广泛认可的一个观点所述，“最好的软件不是没有缺陷的软件，而是满足用户使用要求的软件”。在实际的测试工作中，试图穷举用户需求进行测试是不现实的，对用户来说实用的系统就是好的系统。因此，尽可能覆盖用户日常工作场景进行测试显得尤为重要。而基于场景测试用例的组织，也要求综合考虑用户业务、用户工作流程、系统实现的功能点等多方面进行，对测试人员的逻辑思维能力和业务理解能力都有较高的要求。

我们遇到的一个比较典型的例子——业务流程正常流转的用况：用户按照自身角色的不同，在流程的不同步骤参与流转，流程流转到某一步时，当前用户需要根据自己的权限实施业务的配置后才能让流程继续流转。我们分别针对给用户指定业务配置权限、给用户指定流程角色、流程正常流转、业务配置等功能点组织了测试用例并通过了测试。而后针对整个流程设计场景测试用例时，包含了指定A用户同时具备流程中与业务配置对应步骤的角色和业务配置的权限。当时应用系统没有通过这个场景测试用例，原因是A用户同时具有的业务配置权限与流程角色发生了冲突，导致业务配置任务无法实施。可见，所有相关的功能点均通过测试，也不表示全部由这些功能点构成的用况能正确实现，因此基于场景的测试是十分必要的。

（2）测试用例与测试包

每个测试场景是由不同的测试功能点按照一定的顺序组合而成的，组合顺序不同，预期结果也有可能会不同。针对每个测试功能点都组织了相应的功能点测试用例，而对于场景的测试用例，如果重复描述构成场景的各个功能点的测试用例内容，会带来一些问题：

1) 加大了测试用例编写的工作量。

2) 给测试用例的维护带来困难。同样的内容的修改要在多处体现，很容易遗漏，从而带来不一致。

3) 测试用例的结构层次不清晰。功能点测试用例和场景测试用例的关系体现不出来。

鉴于上述原因，在场景测试用例的编写过程中，我们引入了测试用例包的概念。测试用例包是测试用例在一定条件下的有序组合。必要的时候，可以将已有的功能点测试用例以适当的顺序组织起来，加上必要的条件限制，构成测试用例包，形成场景测试用例。

（3）测试用例的描述工具和测试用例包的组织形式

1) 测试用例描述工具

实际上，测试用例可以采用自然语言、表格等各种方式加以描述。以UML语言加以描述也是可选的方法之一。

UML（统一建模语言）[3]很好地体现了统一过程思想，因而可以在以统一过程思想为指导的软件开发过程中普遍应用于各个阶段。用况驱动是统一过程思想的核心思想，如果项目的需求分析、设计等工作成果均以UML方式描述，则在以用况驱动的测试活动中，采用UML组织测试用例，会更利于项目内部交流。我们的测试团队曾尝试用UML描述测试用例，以下是对我们试用过的一些方法的说明。

第一种，可采用用况图与活动图结合的方式描述测试用例。例如：图1是用活动图形式描述的日志管理部分功能测试用例的例子。这个活动图中包含7个测试用例，每个end点对应一个测试用例，测试用例编号、测试目的、预期结果、测试数据等测试用例的信息。在相应end点的属性中以文字形式说明。

图1 活动图形式描述测试用例举例

第二种，可在同一张用况图中以分层的方式描述出功能点/场景（用况）-测试点-测试用例的逐级细化关系。例如图2，这是以用况图形式体现的用户权限管理部分的功能点-测试点的细化。

图2 用况图描述功能细化举例

第三种，可采用状态转移图、活动图、顺序图、协作图等方式或者将它们结合以对测试用例加以描述。

2) 测试用例包的组织形式

描述测试用例包中测试用例的顺序和条件限制关系，并不拘泥于具体的形式。我们曾采用过两种方式，即表格形式和动图形式。

例如：前面提到的业务流程正常流转用况的测试用例以及相关功能点测试用例可以以下面的表格形式体现。

在活动图中，使用对子活动的嵌套，可以实现在当前测试用例中对其它测试用例的引用，从而方便的实现了测试用例间的组合重用，完成了测试用例包的组织。

2.性能测试

广义上的性能测试一般包括常态下的性能测试、压力测试和负载测试等，而实际工作中经常遇到的性能测试往往是对典型用户环境下使用情况的模拟，在此基础上所进行并发性和持续性压力测试，而并非考验系统极限值的测试。系统的性能指标和性能测试所遵循的都应该是“适度”原则。系统性能指标优越，性能测试充分当然好，但是这是要付出高昂的代价的。实际上，实际而有效的性能测试也应该是由用况驱动的，是针对用户使用场景所设计的，需要根据用户对各项指标所提出的明确需求，或者根据用户现场的实际情况，结合测试人员的经验设计出相应的性能测试方案和数据，并依照实施。

例如：一个正常情况下最多只有50个并发用户的系统，就没有必要进行1000个用户的并发测试，而一个每天夜间自动重起的系统，就没必要对其实施持续一周的负载测试。

3．回归测试

用况驱动的思想同样指导回归测试用例的选取。由于时间和成本的限制，每次回归测试，都将所有功能和场景重新测试一遍是不现实的，如何能既尽量降低风险，又提高测试效率呢？就需要在测试用例选取的过程中注意把握平衡。

回归测试用例的组织应该是分层次、分优先级的，基于用户最常用的场景的测试用例处于最高优先级。每次执行回归测试时，基于软件修改所影响的范围，根据时间、人员、成本等因素，按照优先级次序抽取适量的相关测试用例，构造一个优化的测试用例组来完成回归测试，才是正确的选择。

三 、结语

用况驱动系统测试用例设计，是软件系统发展的需要，更符合软件生命周期的规律，广泛应用于功能性测试、性能测试、回归测试等各测试领域。用况驱动系统测试用例设计之路尚在探索之中，并无定式，在实践中不断尝试和改进才是提高测试用例设计水平、提高软件质量的正确途径。

参考文献：

[1] Roger S. Pressman. Software Engineering: A Practitioner’s Approach (Fifth Edition)[M]， New York: McGraw-Hill, Inc., 2001

[2] Ivar Jacobson, Grady Booch, James Rumbaugh： The Unified Software Development Process[M]， Boston, MA: Addison-Wesley, 1999

[3] James Rumbaugh, Ivar Jacobson, Grady Booch： The Unified Modeling Language Reference Manual[M]， Boston, MA: Addison Wesley, 1998