编写有效用例笔记-第十四-二十二章

编写有效用例笔记-第十四-二十二章 – tommwq.tech/blog

第十四章 CRUD和参数化用例

基于数据库操作的、关于实体创建、检索、修改、删除的小用例叫做CRUD用例。CRUD用例可以作为独立的用例，也可以组合成一个概要级别的实体管理用例。采用哪种方式需要根据具体情况分析。对于大多数情况，使用实体管理用例的方式更好，更有利于管理用例。

在捕获用例时，有时会发现一些用例是对不同对象执行相同的操作，比如“搜索客户”和“搜索商品”。这样的用例可以一般化为参数化用例。

第十五章 业务过程建模

用例不仅仅可以描述软件的行为。对于任何系统和组织，用例都可以对其行为进行建模。为一个组织编写用例，是业务建模的一个有效方法。业务建模的目的是弄清楚：

• 在组织行为中的项目相关人员。
• 该组织必须满足其需求的外部主执行者。
• 该组织必须响应的触发事件。
• 该组织提供的服务，以及对项目相关人员的成功结果。

第十六章 遗漏的需求

用例只描述了需求中系统行为的部分。对于性能需求、业务规则、用户界面、数据格式、数值精度等，用例都无法反映。

第十七章 用例在整个开发过程中的作用

用例的作用贯彻整个开发过程。用例可用来组织开发任务、指导类设计和界面的设计，启发测试用例的编写。在开发工作的早期，使用执行者-目标列表和评估需求的优先级和工作量，并以此安排和分配开发任务。在类设计阶段，用例中的名词可以启发类的设计，动词可以启发类方法的设计。用例描述的，执行者和系统的交互过程，也隐含了有哪些信息和控制在二者之间传递，这正是界面设计要考虑的。

用户界面可以用高、中、低3种精度级别描述。低精度描述是屏幕导航图，记录了屏幕的名称和屏幕转移事件。中精度是屏幕的缩略图。高精度则详细定义了每个控件的尺寸和行为。

开发团队应当形成一套编写用例的工作习惯。通常用例的编写工作分为两个阶段：

• 制定一份粗略的系统功能图
  • 对系统采用的叙述方式达成共识（团队）。
  • 对应用领域达成共识，集中讨论系统的主执行者和目标（团队）。
  • 编写系统描述（个人）。
  • 收集系统描述（团队）。
• 制定详细的用例视图
  • 集中研讨用例编写（团队）。
  • 对用例格式达成共识（团队）。
  • 编写用例（个人）。
  • 审核用例（个人）。
  • 审核用例（团队）。

第十八章 用例概述和极限编程

略。

第十九章 错误改正

在编写用例的过程中，容易发生下列错误：

错误	描述
没有描述系统行为。	系统也是执行者。用例要避免遗漏任何执行者和相关方。
没有主执行者。	描述用例步骤的句子中没有主语。
过多的界面细节。	用例关注的是执行者的意图，而不是视图。
过低的用户目标。	使得用例过长，没有层次和结构。难以理解或修改。
目标和内容不符。

第二十章 对每个用例的提示

• 每个用例都是一篇散文。
• 让用例易于阅读。
• 适当的包含子用例。
• 以俯视角度编写用例。
• 找到正确的目标层次。
• 不考虑用户界面。
• 每个用例都有两个结局：成功和失败。
• 保证项目相关人员的利益。
• 不要忽略前置条件。
• 使用核对清单检查用例。

编号	核对项目	核对结果
	用例标题
1	确认主执行者目标采用“动词+名词”方式描述。
2	系统能完成这个目标吗？
	范围与层次
3	这些域填写了吗？
	范围
4	用例是把范围内的系统作为一个“黑盒”对待吗？（如果是系统需求文档，那么答案是：是；如果用例是白盒业务用例，那么答案是：否。）
5	如果对范围内的系统进行设计，设计者是只设计范围内的每件事，而不管范围之外的事吗？
	层次
6	用例的内容与描述的目标层次匹配吗？
7	目标是在所描述的目标层次上吗？
	主执行者
8	他有行为吗？
9	他有目标与被讨论系统的服务承诺矛盾吗？
	前置条件
10	它们是强制的吗？它们能在某些地方被所讨论的系统设置吗？
11	在用例中它们真的从来不需要检查吗？
	项目相关人员及其利益
12	他们被分配名字了吗？系统一定能够满足他们所描述的利益吗？
	最小保证
13	所有项目相关人员的利益被保护了吗？
	成功保证
14	所有项目相关人员的利益被满足了吗？
	主成功场景
15	它有3-9个步骤吗？
16	它能从触发事件到交付成果保证运行吗？
17	在执行过程中，它允许适当的改变吗？
	在任何场景中的每个步骤
18	它描述了一个成果目标吗？
19	在它完成后，整个过程明显的向前移动了吗？
20	是否清楚的支出哪个执行者正在操作目标？
21	执行者的意图是否清楚？
22	该步骤的目标层次是否低于整个用例的目标层？它是恰好比用例目标层低一点吗？
23	你确定该步骤没有描述系统用户接口的设计吗？
24	在该步骤内所传递的信息是否清楚？
25	它的“确认”与“检测”条件相匹配吗？
	扩展条件
26	系统能够并且必须发现和处理它吗？
27	它是系统确实需要的吗？
	技术与数据变动
28	你能否确定这不是主成功场景的一个普通扩展行为？
	整个用例的内容
29	对投资者和用户：“这是你们想要的吗？”
30	对投资者和用户：“在交付时，你们能识别出这是你们所要的吗？”
31	对开发者：“你们能实现它吗？”

第二十一章 对用例集的提示

• 用例具有层次结构，从高层次向低层次逐渐展开。
• 业务用例描述业务运作，系统用例描述系统行为。
• 检查用例集质量：
  • 每个用例都是和同一个业务目标相关的吗？
  • 覆盖了项目相关方所关心的全部吗？

第二十二章 处理用例的提示

略。