编写有效用例笔记-第十四-二十二章 – 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 | 对开发者:“你们能实现它吗?” |
第二十一章 对用例集的提示
- 用例具有层次结构,从高层次向低层次逐渐展开。
- 业务用例描述业务运作,系统用例描述系统行为。
- 检查用例集质量:
- 每个用例都是和同一个业务目标相关的吗?
- 覆盖了项目相关方所关心的全部吗?
第二十二章 处理用例的提示
略。