use case简介

我们常说测试以需求为依据。那么我到底如何组织我们的测试是最接近需求呢。以下我提到一非常重要因素：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 用户可以看到系统提供的功能，先确定系统范围再深入开展项目工作。
        use   case应当细到相当的程度，起码应当细到让一个对业务逻辑不了解的人看过之后能够了解整个业务过程，只有达到这种程度的设计，具体的编码人员才能按照你的设计思想去填写代码。就像盖楼一样，建筑工人是不用（也不太可能）去考虑图纸是如果画成的。
        use   case   大量用来描述系统和外部的交互,而不是把什么都用USE   CASE来做.如果那样,还要时序图,状态机等等干什么呢?总的来说use   case是从高层来描述系统的,你甚至可以用一个USE   CASE来描述你的系统,但大多数情况下是使用多个小的USE   CASE来构成用例模型. 
        use  case是一种UML吗   答案是--不是。   但是use  case可以用UML符号来说明   当然也可以不用。use   case是一种格式化的文档。它是是由用户和系统在一次对话中执行的一个特殊事务序列 。当然我观察这里大多数人都在说use   case的时候   其实他们是在说use   case   diagrams 。  
        use   case需要写的很详细吗 ？  其实这个问题如果这样问，use   case  需要一开始就写的很详细吗？   还有所有的use   case都需要在开始的时候就写的很详细吗？ 我认为这会由于你是不是支持迭代而有所不同  。 而统一的答案是没有的 。
        那么能详细到什么程度呢   实际上对use   case描述的详细程度一直是一个没有统一答案的问题   有各种各异的说法   当然可能在瑞理那里你会得到的答案是统一的   但是你记住use   case不是瑞理私有的一种技术   所以你应该可以建立起符合自己组织实际情况的一套标准     而你这里说的详细标准   我看是指的说明的详细程度   而不是对use   case粒度划分的程度   这不是大问题   其实我看只要你可以把你的业务流程表叔清除   而没有角色和动作的遗漏就可以了   当然不要忘记前置和后置条件  
       use   case实际上是一种需求的分析工具   而且它之停留在系统的外部   而不应该试图去用它来说明系统内部的运行情况。系统内部的运行情况是你的设计工作所要解决的问题   所以你不管对use   case书写多么详细   也不可能代替你的设计   不可能会发生coder看着use   case直接向里面填写代码的事情发生   但是我不知道你指的复杂的逻辑角色是什么   如果你指的是系统运行时候参与的角色   那么我认为你必须在需求中解决这个问题   也就是你必须在use   case中把它们表达清除   而具体如何通过对它们的计算得到最后的结果   则不是use   case所包括的必然部分   当然你给出解决方法(可能是客户现在的解决方法   也或许是你从什么地方找到的方法)会有好处    
        还有我不认为你可能把use   case书写到一个对业务完全不懂的coder看过你的use   case就能了解业务了   这是不太可能的   当然我不排除有这样的例子   但是如果你试图这样做你就要准备把你的use   case书写成一部业务手册   其实use   case还是要和客户的现场答疑   顾问的咨询   业务资料的研读等多种方法结合才可能使coder对业务有一个大概的了解   当然即使是这样你依然部可能要求他们吃完领域专家    
       最后说说用例的粒度问题   这是一个老话题   我在这个地方就回答过多次   我现在依然认为use   case的粒度划分没有一个绝对的标准   你只是要做到适合自己使用就可以了   如果你认为增加记录可以是一个use   case   那么就是一个use   case好啦   这是你的选择   你只是需求对你划分粒度所带来的后果做成评估