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

编写有效用例笔记-第十四-二十二章 – 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 对开发者:“你们能实现它吗?”  

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

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

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

略。

猜你喜欢

转载自blog.csdn.net/tq1086/article/details/110426715
今日推荐