有效的用例编写规则

第一章 什么是高质量的用例

1.1 为什么要使用用例

用例提供了一种用于构建故事的半形式框架；

在每个用例和所有描述层次中，用例都描述了错误情况的系统需求；

虽然本质上是一种功能分解技术，但用例已经成为面向对象软件开发的一个流行元素；

用例提供了可以在其上处理其他项目信息的骨架：

项目经理根据用例进行估计和发布进度；

数据及业务规则制定人员可以把自己的需求和所需用例联系起来；

用户界面设计人员可以进行设计，并将其与相关用例联系起来；

测试人员可以根据用例中描述的成功和失败情况构建测试场景（测试用例）；

1.2 编写用例容易出现的问题

用户界面太多，用户界面应属于设计范畴，鼠标、按键等内容不应出现在用例中；
较低目标层次上的用例太多，无法展示系统将会给其最终用户提供什么功能；
使用用例表示非行为信息，性能需求、业务规则等不要在用例中描述；
太冗长，最好在3~9步；
目标实现不完整，尤其是错误处理；
句子片断，主、谓、宾尽量完整；

1.3 为什么使用用例模式语言

描述了用例的质量标志及其编写过程，提供了能够经受时间考验的用例改进建议；在评审用例初稿和改进其质量的过程中，这个工具能起到很大作用。

1.4 什么是模式

模式是质量标志和策略；

1.5 使用模式语言时错误观念

模式提供了一个关于其自身和模式内容的完整方法；只起补充作用
使用模式肯定会成功；
模式为老问题提供了新的解决方案；只是经常出现的问题的通用可靠方案
模式适用于所有情况；仅是处于某种上下文中的问题的解决方案

1.6 模式组织

1.7 用例的读者和编写者

有两组不同的认阅读和使用用例：（1）最终用户或业务专家；（2）程序员。
用例编写组必须包括：
至少一位具有编程背景的认，以获得描述所要求的准确性和精度；
至少一位熟知业务规则的认；
至少一位熟知在实际中如何使用系统的认；

第二章 团队

2.1 SmallWritingTeam

原因：

用例要求具有不同观点和专业知识的人编写；
将一大组人聚集在一起是困难的；
理论上，在用例上投入的人越多，就能越快的完成用例编写工作；
大的团队会变得低效；
大型编写团队可能会通过集体讨论的形式开发用例，添加许多不必要的特性；

所以：

一个由2人或3人组成的团队足够小，容易交流和达成一致；

可以使用几个SmallWritingTeam，但应当制定一位用例设计师，以保证所有用例与愿景一致。
最终目的是使过程保持在可管理状态，大的团队将在管理上投入更多的精力。

2.2 ParticipatingAudience

没有涉众提供的信息和反馈，就不能满足他们的需要；尽可能使客户和内部涉众积极参与用例开发过程。

2.3 BalancedTeam

由一些个性相似、意见相同的个人组成的团队开发用例，可能会得到一组缺乏创见、范围狭窄的用例，这种用例不能满足每个人的需要。

因此，为小组配备具有不同专长的人员，以维护开发过程中涉众的利益，确保团队中包括开发人员和最终用户。
最大好处是使编写人员在用例中使用常见的、可理解的术语。

第三章 过程

编写好的用例是极其个性化的，每个人都有他自己的风格，每个组织都有根据自己的文化和业务需要做事情的方式，因此，没有创建用例的通用过程。

3.1 BreadthBeforeDepth

原因：

需求收集是一个发现过程，用例编写是一个迭代过程；
人们很早就开始编写用例的细节；
人们浪费了精力或陷入了太多的细节，通常都会失去重点，无法描述所有可能的扩展条件；
从早期获得概述是有益的；
最初编写的细节越多，在了解系统后必须进行的改变也就越多；

所以：

通过首先开发用例的概述来保存精力，然后逐步增加细节，并行开发一组相关用例。

完成概述用例后，随着对系统了解的增多，不断提高用例精度，避免突然开发完所有用例或一次只开发一个用例的倾向。

3.2 SpiralDevelopment（螺旋式开发）

原因：

理解系统的行为可能会花掉大量时间，要求渐进式分析；
拖延是昂贵的。要尽快完成用例的编写；
对需求进行分析后，需求很可能会发生变化；
需求成本的错误是昂贵的；

所以：

以一种迭代的，宽度优先的方式开发用例，每次迭代都会提高用例集的准确性和精度。

基本过程：

从简单的东西开始，如一个参与者/用例列表；
简要描述用力主场景，即高层用例，以包含用例的主要范围；
扩展摘要的子集，并填充细节；
评审并调整；

3.3 MultipleForms

不同的项目需要不同程度的形式化，每个人对模板都有不同的偏好，要求每个人都使用相同的用例模板只会起到相反的作用。

原因：

每个人的个性、经验和经受的锻炼不同，每个开发组织都有其特有的人员、历史和文化；
不同的项目有不同的需要；
不同的编写团队需要不同程度的规范和严格度；
在组织中使用公共的编写形式有助于交流；
在同一个项目上使用不同的模板不是一个好主意；

因此：根据项目相关的风险性、项目特点，和所涉及到的人员选择用例的编写格式，并在该项目的开发过程中的组织内部使用。

3.4 TowTireReview（评审）

许多人都可能需要评审用例，这是一件昂贵耗时的事情。

原因：

对于验证和确认编写及内容来说，评审是必要的；
涉众在用例上有一种既得利益；
使每个人参与编写过程非常昂贵、麻烦并且缓慢；
如果仅由一个小的编写组进行评审，就不会考虑所有涉众的利益；
评审可能是昂贵的、乏味的、耗时的。

所以：

进行两种类型的评审：第一种是由较小的内部小组进行的评审，可能要重复进行很多次；第二种是由整个团队进行的评审，可能只进行一次。

3.5 QuittingTime

开发一个超出了涉众和开发人员需要的用例模型不仅浪费资源，而且会拖延项目进度。

原因：

忽视重要需求的巨大恐惧使构建人员和涉众延长了需求收集活动；
大多数人可以用一种合理的模糊性工作，即不言自明；
详细讲述谎言并不能使他们更为精确；

所以：

在用例完整并且符合参与者的需要后，停止开发用例；
用例模型完整性的检验：完整、可读、逻辑上正确、对开发人员足够详细。
是否识别了所有的参与者和目标并将其编成了文档？
客户及其代表是否承认用例集是完整的，而且每个用例都是可读的和正确的？
设计人员是否能够实现这些用例？

3.6 WriterLicense

小的格式差别并不重要，解决了所有系统问题后，及时还存在一些格式问题，也可以停止编写；

原文转自：http://www.ltesting.net