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

　　关键词：用况驱动；系统测试；测试用例设计

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

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

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

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

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

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

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

　　与传统系统测试用例设计相比，强调用况驱动的思想会体现出一定的优越性。

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

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

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

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

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

　　1．功能性测试

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

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