关于测试用例
Use Case（用例）是一个UML中非常重要的概念，在使用UML的整个软件开发过程中，Use Case处于一个中心地位。
那么，到底什么是Use Case呢？在UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实Use Case就是对系统功能的描述而已，不过一个Use Case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。（唔？Use Case也没什么特别的嘛！怎么这玩意儿会在开发中处于一个中心地位呢？）在使用UML的开发过程中，需求是用Use Case来表达的，界面是在Use Case的辅助下设计的，很多类是根据Use Case来发现的，测试实例是根据Use Case来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。啊，Use Case，简直太重要了！好了，Use Case就吹到这儿，具体的使用还要在实践中去体会，“运用之妙，存乎一心” 也！
对于每个Actor来说，他都要使用系统的某项功能，所以我们识别和分析Use Case是，要 对于每个Actor来逐个进行。对于ToDo User，我们可以轻易的识别出两个Use Case：Add Task和Remove Task。ToDo User主动使用这两个Use Case所描述的系统功能，所以在我们的Use Case图上，ToDo User和这两个Use Case的关系是用从ToDo User发出的箭来表示的。对于FileSystem，我们识别出的也是同样的两个Use Case，不过这次箭头从Use Case指向FileSystem，表示FileSystem是被动的。
Use Case可以用很多方式来描述，我们可以用自然语言（英语，汉语，随您的便），可以用形式化语言（哇！太酷了吧！），也可以用各种图示。在UML中，通常用两种图来描述Use Case，它们就是顺序图（Sequence Diagram）和协作图（Collaboration Diagram）
Use Case由以下元素组成：
名称
简单描述
事件流
关系
活动图和状态图
Use Case图
特殊需求
前条件
后条件
一、谈谈对use case有关术语翻译的看法。
笔者认为“用例”是目前较好的译法，这个词可能来源于大家熟知的“测试用例”。有人认为把use case翻译成“用例”是错误的，理由是：“‘例’是被列举出来以说明某种情况的个别事物，use case是对一项系统功能使用情况的普遍适应的描述，而不是对个别actor或者在个别条件下使用这项功能才适应，它也不是通过举例的方式来描述的”，所以不能叫作“用例”。此种说法不尽全面,而且有些牵强（先不管它正确与否），其实use case到底是个别的，还是群体的（普遍适应），取决于我们的视点。虽然对于单个的scenario来说，use case是多个情节的叠加，是一个整体的复合概念，但是我们知道，一个系统的功能必定是可数的、有限的，而每一个功能都可以表示为一个use case，所以在观察系统提供的所有功能需求的集合这个层面上，use case又是一个一个可数的个体（“椭圆”），每一个都代表了不同的用户目标，适用于个别的actor和个别特定的前置条件。同一个事物既是个体的又是整体的，这种现象并不足怪，例如在UML对象-类-类元关系中，通常对象是类的实例，而类又是类元的实例，对类元来说，类、接口、子系统、use case等等就是一个个个体的概念，类既是其对象实例的集合又是其类元集合的个别元素。可见，把use case的“case”译成“例”并没有错。
有的地方把use case翻译成“用况”，即“使用的情况”之意，意思的确不错（use case的另一种说法是“使用的方式”）！可我总感觉这个词比较突兀、拗口，类似的还有“用案”，把scenario叫作“案况”，大概这些词读起来不太符合大家的习惯（类似地，既然可以叫“用况”，为什么不能叫“用情”呢？），所以现在“用例”的叫法还是越来越多了。
其实“用例”这个译法还有个附带的好处，通过它我们很容易把原本就存在紧密联系的use case和test case（test case来自于对scenario的分析，而scenario是用例的一次执行）从中文名称上也方便地统一起来。不过，这里我们需要做一个小小的改进。中文的“测试用例”到底是指test case（带定语的名词词组）呢，还是指对用例进行测试（testing the use cases，动宾词组）呢？显然这两者不易分辨，而且若“用例”和“测试用例”两个词同时出现在一啰个句子或一段话中，常常会让人感觉嗦和便扭。为了消除歧义，干脆以后把test case都叫做“测例”，这样不但比以前的叫法更加简洁明了，而且无论字面上还是语义上都很贴切。当然，用例和测例是不同层面的“例”。
现在市面上Actor也有多种译法，常见的包括“参与者、执行者、主角”等等。“参与者、执行者”的问题主要是不准确。首先，“参与者” 通常让大家马上想到的词是participant，而且请注意，一个用例的真正参与者决不是只有外部的Actor，它们必然还包括系统本身及其内部的各种元素。“执行者”的问题与此类似：一个用例的真正执行者应该是系统本身！因此严格地讲这样译是错误的，兴许叫作“外部参与者”、“外部执行者”才更为恰当。“主角”的译法同样存在着矛盾。如果把Actor叫作“主角”，那么Primary Actor就应该叫作“主主角”了。看来Actor的译法中是不能含有“主”的，那么就剩下“角”了，而UML已经有了一个专门术语role（角色），我们又不能把Actor直接叫作“角色”。
目前看来，把Actor意译成“使用者”是比较妥当的。在大多数情况下Actor的的确确就是用户（确切地说是系统用户所扮演的一种角色），所以我们可以用“使用者”这个词从字面上与“用户”（user）进行区分，但同时又保持两者语义上的联系。我们还可以把为系统服务的Supporting/Secondary Actor（见下文）叫做“被使用者”（为了简化可以省略“被”字）或“辅使用者”。除了指系统的用户之外，“使用者”还有另一层含义，即Actor是use case的使用者（或被使用者），这种关系在UML用例图上应该可视化地表示为它们之间的连线（关联）。这样解释不但说的通，而且更便于不熟悉软件技术的业务人员理解。
当然，我们也不排除将来会找到“use case”、“actor”等术语更好的译法。
二、USE CASE的来历
Ivar Jacobson在1967年定义爱立信AXE系统的够架时开始书写使用场境usage scenarios。
二十世纪八十年代中期Jacobson花了很多精力来思考过去十多年的工作方法。他造了一个术语anvendningsfall，大意是“使用情况”（situation of usage）或用况（usage case）。但当用英文出版的时候，他发现“useage case”在英语里说不通，所以写作用例“use case”
三、创建USE CASE的原则
用例是短文
用例可以是一个场景，包括动作和互交。
用例可以是一组场景，描述不同场景下的行为。这种书写格式可以在任何时候描述有变体的行为，例如黑盒需求，业务流程，系统设计说明。
用例里不要有系统设计
用例里不要有界面设计
用例里不要有特性列表
用例里不要有测试
用例应该描述行为需求
用例的主场景不要超过九步。可以在适当的层次上得到子目标和移除设计说明。
用例的最大价值不在于主场景，而是在于备选行为。主场景可能只占用例长度的四分之一到十分之一。
四、Use Case事件流
Use Case具有一个基本事件流（可称为"理想路径"）、多个例外流，包括：
基本变化
特殊情况
处理错误情况的异常事件流
五、Use Case说明书
Use Case说明书应包括以下内容：
功能描述
可用性
可靠性
性能
可支持性
设计约束
六、Use Cases将做成多大？
试图决定Use Case的大小是一个很有趣的话题，处理这件事的一个方法是将Use Case的大小跟它的意图和范围关联起来，对于一个真正大的范围来说，一个Use Case并不要在一个系统中处理那么多，但这些系统都用于同一商业领域，称为Business Use Case，它把整个公司看作一个黑盒和Actor关于公司目标的说明。这些Business Use Case的场景不允许假定任何公司内部的结构，一个客户将向公司下一个定单而不是客户服务部门。
对于系统发展而言，Use Case的范围限制一个单一的系统，这是Use Cases最通常的形式，我们称之为System Use Case，它把整个系统看作是一个黑盒，它不指定任何内部结构并且仅受限于问题域的语言描述。
Use Cases的另一范围是设计子系统和系统内部组件的，称为Implementation Use Cases，它把组件看作一个黑盒，并且这些Actors是区分它的成员。例如：可能会用Implementation Use Cases去说明应用系统中email组件的需求。
给出了这些分类，关于Use Case的大小话题变得容易了，设计这些项的范围来调整整个大小。帮助系统设计者，每个Use Case只描述没有大的分支的行为的单个线索。违背这个规定，Use Case看起来通常是不准确的或含糊的，作为测试说明的资源和参考，它也是很难使用的。
七、Use Cases的说明
Use Cases的好处是一些情节能用不同程度的正规化的文字说明。每个情节涉及Use Cases中单一的途径，细节是条件组。
不正规的文本描述也能使用，不过当条件较多和可能失败的情况下它们很难跟随下去。开始试图理解需求时，不正规的叙述风格也是非常有用的，然而随着Use Cases的进展，使用更加正规的机制去说明Use Cases才是有用的。
下面是客户对Use Case“下定单”的粗略概略：
“确定客户，找出需要的并且仓库里还有的物品并检查客户信用额是否够用”
结构化叙述的格式已经被证明是非常有效的。这个格式所做的事是描述每一个情节的行为者：目标语句对顺序的叙述。在这个顺序中，每一个行为者：目标的语句对都假设前一个的目标是成功的，右面是一个简单的范例：
Use Cases认为我们正在设计的系统是一个单一的黑盒，根本没有任何内部结构被记录下来，并且它被认为是一个情节产生的目的及对应单一的行为者（Actor）。这些Use Cases没有表示任何关于系统内部的东东，只是表示系统将达到什么样的目标及由什么（人或其它系统）操作和负责。
八、Use Cases使需求有利于回顾
Use Cases已经得到越来越广泛的应用，它与其它需求捕获技术相比，它成功的原因在于：
1Use Cases把系统当作一个黑盒
2Use Case使在需求中看到实现的决定变得更加容易
最后一点源于第一点的补充，一个Use Case没有指定任何这些需求相关的系统的内部结构，所以说，如果这个Use Case中陈述了"提交改变到定单数据库"、"显示结果到Web页面"等的话，那么内部结构是显而易见的，并造成对设计的潜在约束。
为什么这些需求不指定内部结构的原因是，说明的内部结构给设计者带来了额外的约束，没有这些约束设计者们能更自由地建立一个正确实现客观可见行为的系统，并存在出现突破方案的可能性。
九、Use Cases的图形符号
这里是Use Cases的图形符号描述，UML中一个单一的"Stick-Man"符号标示角色（Actor），用椭圆标示Use Cases，如
（图一）所示。这些图对于你想看到Use Cases之间如何关联的"大图"和获得系统上下文的大体描述来说是非常重要的。
Use Cases图没有显示不同的场景，它们的意图是显示角色和Use Cases之间的关系。所以Use Cases图需求用结构化叙述文本来补充。UML提供一些可供选择的图来显示不同的场景，这些常规的图形有交互图、活动图、顺序图、状态图等（本文暂不讨论这些图）。使用这些图的主要缺点是它们不象文本一样是紧密的，但它们能用于给出Use Case的整体感觉。
十、Use Case的评价标准
是否每个Use Case都包括至少一个actor？
是否每个Use Case都独立于其他Use Case？
是否每个Use Case都有一个简单的行为或事件流？
是否每个Use Case都有一个唯一的、直观的、可扩展的名称，使它不至于在后期被混淆。
用户是否容易理解Use Case的名称和描述。
十一、Use Case模型的评价标准
Use Case模型显示系统中的Use Case与Actor及其相互关系。其评价标准有：
Use Case模型是可理解的吗？
通过对Use Case模型的研究是否能对系统功能有一个清晰的概念。
所有的actor都定义了吗？所有的功能需求都满足了吗？
Use Case模型是否存在多余的行为。
从模型到Use Case包的划分是否是恰当的。
十二、使用Use Case的误区
由于具有简单的图形符号、易理解的自然语言说明书，Use Case在文档系统和软件需求领域成为一 项越来越受欢迎的技术。Use Case对开发小组极具吸引力，即使小组成员对正式的需求文档没有经验，但这些简单性却具有欺骗性，即使项目小组在开始使用Use Case时没有任何麻烦，当他们将其应用于大项目时常常会遇到许多同样的问题。
1使用use case十大误区
1． 系统的boundary没有定义或经常改变；
2． 从系统观点而不是actor观点来定义Use Case；
3．Actor的名称不一致；
4．Use Case定义过多；
5．Use Case和actor之间的关系象蜘蛛网一样错综复杂；
6．Use Case的说明太长；
7．Use Case的说明不清楚；
8．Use Case没有正确的描述功能需求；
9． 用户无法理解Use Case；
10．Use Case无法正常结束。
2如何避免以上问题
清楚的确定系统的boundary.
简单来说，系统的boundary就像一个加了标签的盒子，actor在盒子外，而Use Case在盒子内。我们称之为系统的这个盒子究竟是什么呢？一个计算机系统？一个应用系统？或一个完整的企业？…Use Case可以用来合理地描述任意系统。但一次只能用来描述一个系统，在一个系统中恰当定义的actor和Use Case用于另一个不同的系统中就会出现错误。
使用标准模板书写Use Case说明书
Use Case图形符号已经被标准化并作为对象管理小组UML的一部分，但自然语言的Use Case说明书还没有被标准化。为了成功书写Use Case说明书，我们需要一个标准模板来保证Use Case的一致性。
关注actor的真正目的，从actor的观点而不是系统观点来命名Use Case
面向Use Case的需求与传统的功能性系统需求之间最显著的区别在于actor，以面向Use Case的观点，系统存在是由于actors要通过该系统实现某些目标，actor与系统进行交互来实现其目标，我们将这些交互行为定义为Use Case。
不要将Use Case说明书与用户接口设计相混淆
现在有一种很流行的观点：由于Use Case是actors与系统之间的交互，所以将所有的用户接口设计图放在Use Case说明书中是一个好办法。初看时，这的确很有用，因为它将在说明书中描述的actor/系统之间的交互行为以图的形式表示出来，非常直观。但是这样做的负面影响却远远大于其好处，用户接口设计可能会随着时间而改变，我们不应该让系统需求依赖于用户接口设计，相反地，用户接口设计应该满足Use Case需求。如果我们将用户接口设计置于Use Case说明书中，当需求需要被认可和定为基线时，很自然地，这些设计元素可能仍然在改变，这就使得用户接口设计成为不完整的、不正确的和/或不一致的。
将用户接口设计置于Use Case说明书还会出现另一个问题，为了在Use Case之间和接口之间建立一对一的通信，我们会选择反映用户接口的Use Case块而不是反映用户目标的Use Case块，这样，为了表达一个完整的用户目标，我们使用交互Use Case关系，将不同的、基于用户接口的Use Case联接起来，结果在Use Case模型中，我们得到了一幅类似蜘蛛网的关系图。实际上，这副图是用户接口说明图，虽然它在系统文档中是很重要的一部分，但他属于用户接口设计文档，而不是Use Case需求文档。
实现用户接口和Use Case交互之间的松散耦合
松散耦合是比较合适的，低逼真度的用户接口图有助于理解Use Case，但要注意不要过度的将基本交互与用户界面机制相连，用户界面很有可能会改变。在功能说明书中，要注意actor做些什么（如"提交请求"）而不是交互是怎样完成的(如"双击提交按钮")。
TAG:
