有效的用例编写规则-3

第第页有效的用例编写规则有效的用例编写规则

发表于：2023-06-01来源：：点击数：标签：用例有效规则编写

第一章什么是高质量的用例1.1为什么要使用用例用例提供了一种用于构建故事的半形式框架；在每个用例和所有描述层次中，用例都描述了错误情况的系统需求；虽然本质上是一种功能分解技术，但用例已经成为面向对象软件开发的一个流行元素；用例提

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

1.1为什么要使用用例

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

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

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

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

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

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

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

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

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

用户界面太多，用户界面应属于设计范畴，鼠标、按键等内容不应出现在用例中；

较低目标层次上的用例太多，无法展示系统将会给其最终用户提供什么功能；

使用用例表示非行为信息，性能需求、业务规则等不要在用例中描述；

太冗长，最好在3~9步；

目标实现不完整，尤其是错误处理；

句子片断，主、谓、宾尽量完整；1.3为什么使用用例模式语言

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

1.4什么是模式

模式是质量标志和策略；

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

模式提供了一个关于其自身和模式内容的完整方法；只起补充作用

使用模式肯定会成功；

模式为老问题提供了新的解决方案；只是经常出现的问题的通用可靠方案

模式适用于所有情况；仅是处于某种上下文中的问题的解决方案1.6模式组织

模式分类子类开发模式

团队组织：判断和改进用例团队组织方式的质量的模式；过程：判断和改进团队用来创建用例的方法质量的模式；编辑：随着潜在需求的变化和编写人员知识的增加，判断和改进单个用例的质量；结构模式

用例集：判断和改进用例集质量的模式；用例：判断和改进单个用力质量的模式；场景和步骤：判断和改进用力场景以及这些场景中的步骤质量的模式；用例关系：判断和改进集合中用例之间的结构关系质量的模式；1.7用例的读者和编写者

有两组不同的认阅读和使用用例：（1）最终用户或业务专家；（2）程序员。

用例编写组必须包括：

至少一位具有编程背景的认，以获得描述所要求的准确性和精度；

至少一位熟知业务规则的认；

至少一位熟知在实际中如何使用系统的认；第二章团队

2.1SmallWritingTeam

原因：

用例要求具有不同观点和专业知识的人编写；

将一大组人聚集在一起是困难的；

理论上，在用例上投入的人越多，就能越快的完成用例编写工作；

大的团队会变得低效；

大型编写团队可能会通过集体讨论的形式开发用例，添加许多不必要的特性；所以：

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

可以使用几个SmallWritingTeam，但应当制定一位用例设计师，以保证所有用例与愿景一致。

最终目的是使过程保持在可管理状态，大的团队将在管理上投入更多的精力。

2.2ParticipatingAudience

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

2.3BalancedTeam

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

因此，为小组配备具有不同专长的人员，以维护开发过程中涉众的利益，确保团队中包括开发人员和最终用户。

最大好处是使编写人员在用例中使用常见的、可理解的术语。

第三章过程

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

3.1BreadthBeforeDepth

原因：

需求收集是一个发现过程，用例编写是一个迭代过程；

人们很早就开始编写用例的细节；

人们浪费了精力或陷入了太多的细节，通常都会失去重点，无法描述所有可能的扩展条件；

从早期获得概述是有益的；

最初编写的细节越多，在了解系统后必须进行的改变也就越多；所以：

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

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

3.2SpiralDevelopment（螺旋式开发）

原因：

理解系统的行为可能会花掉大量时间，要求渐进式分析；

拖延是昂贵的。要尽快完成用例的编写；

对需求进行分析后，需求很可能会发生变化；

需求