测试中常被忽视的UseCase
我们常说测试以需求为依据。那么我到底如何组织我们的测试是最接近需求呢。以下我提到一非常重要因素：UseCase----什么是UseCase呢？在UML的文档中，UseCase的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实UseCase就是对系统功能的描述而已，不过一个UseCase描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。
在使用UML的开发过程中，需求是用UseCase来表达的，界面是在UseCase的辅助下设计的，很多类是根据UseCase来发现的，测试实例是根据UseCase来生成的，包括整个开发的管理和任务分配，也是依据UseCase来组织的。啊，UseCase，简直太重要了！
UseCase 由以下元素组成：名称、简单描述、事件流、关系、活动图和状态图、UseCase 图、特殊需求、前条件、后条件。
创建USE CASE的原则：1、用例是短文。2、用例可以是一个场景，包括动作和互交。3、用例可以是一组场景，描述不同场景下的行为。这种书写格式可以在任何时候描述有变体的行为，例如黑盒需求，业务流程，系统设计说明。4、用例里不要有系统设计。5、用例里不要有界面设计。6、用例里不要有特性列表。7、用例里不要有测试。8、用例应该描述行为需求。9、用例的主场景不要超过九步。可以在适当的层次上得到子目标和移除设计说明。10、用例的最大价值不在于主场景，而是在于备选行为。主场景可能只占用例长度的四分之一到十分之一。
总的来说：UseCase 是系统提供的功能块，换句话来说UseCase演示了人们如何使用系统。通过UseCase观察系统，能够将系统实现与系统目标分开，有助于了解最重要的部分――满足用户要求和期望，而不会沉浸于实现细节。通过UseCase 用户可以看到系统提供的功能，先确定系统范围再深入开展项目工作。
那么如何从UseCase 生成TestCase 呢？
从UseCase的角度来考虑TetsCase的设计，重点还是要从业务本身的角度来考虑，比如UseCase中的基本流和不同的备选流组成的不同的业务流程，都可以对应到单独的一个TC中去。但TestCase还会考虑来把用户不同情境的基本流/备选流进行细化组织。
