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

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

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

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

　　（2）测试用例与测试包

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

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

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

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

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

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

　　1）测试用例描述工具

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

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

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

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