《编写有效用例》读书笔记－第一章

第一章    引言

1.1    什么是用例？

读本书以前，我是这样理解用例的：用例是一种记录功能需求的工具，它用场景描述的方式记录用户与系统发生的一次交互。现在意识到，很多概念的定义可以有很多种，我这种理解应该也算是正确的吧。书中这样定义用例：“用例是代表系统中各个项目相关人员就系统行为所达成的契约。用例描述了不同条件下，系统对某一项目相关人员的请求所做出的响应“。

“根据执行者做出的请求和请求涉及的条件，系统将执行不同的行为序列，每一行为序列称这为一个场景。一个用例是多个不同场景的集合”。

“用例是一个种编写形式”

1.2    编写好的用例必须掌握的概念

编写好的用例必须掌握的三个概念：

范围（scope）：真正被讨论的系统是什么？

主执行者（primary actor）：谁有要实现的目标？

层次（level）：目标的层次是高，还是低？

感觉书中的“掌握”一词用的不是很好，容易产生歧义，应该写成“必须搞清楚的概念”。

1.3    用例的风格

用例是一种编写形式，可应用于多种情况，例如：

用来描述一个业务工作的流程

用来集中讨论未来系统的需求问题，而不是需求描述

作为系统的功能性需求

将系统设计结果文档化

可能应用于小型的、集中的工作组中，也可能应用于大型的、分散的工作组中

正是因为用例可以被应用于以多种情况，以至于它可以由多种方式编写而成，也可以说用例可以有很多风格或种类：

“随意”或“正式”：随意就是简单，简化了用例模板，编写起来较快，但在一个组织中采用随意型的用例，很难统一风格，可能会导致交流起来比较困难，但是比较集中的团队或者比较默契的团队，而且在要求不是很严格的项目中，倒是可以采用这种随意形式。正式的用例形式容易统一风格，但编写起来也比较耗时。

“系统用例”或“业务用例”：软件开发人员编写系统用例来描述需求，业务人员编写业务用例来描述业务流程。

“黑盒用例”、“白盒用例”：顾名思义，编写黑盒用例不考虑系统或组织的内部运作或实现细节，而白盒用例边同内部的实现细节也一并描述。

“概要目标”、“用户目标”：

错误的做法是，在不需要十分精确和严格定义的情况下仍然耗费项目组大量的时间和精力来编写用例

1.4    用例用来发现需求，而不是记录需求

书中提出了这样一个观点：使用用例来发现需求而不是用文档方式记录需求。并引用了Steve Adolph的一段话来说明。

使用用例来记录需求，只是已经有人创建一个系统，然后使用用例来对这个系统进行描述。如果说现在没有需求，那么使用用例就是去发现需求，去“创建”系统。

先使用用例描述一个较高层次的场景，然后再深入到每个步骤里面去，逐步细化。

1.5    需求和用例

如果把用例当作需求来编写，那么请谨记以下两点：

用例确实是需求。不必将用例变成行为需求的其它形式。如果编写得当，用例可以准确的对系统必须要做什么进行详细描述。

用例不是所有的需求。用例不详细描述外部接口，数据格式，业务规则，复杂公式。用例只是需要收集所有需求中的一部分（可能是1/3），虽然这一部分是非常重要的一部分，便毕竟仅仅是一部分。

用例不是所有的需求还是比较容易理解的。像质量需求、性能需求、系统需求等都不是用例所能发现和记录的。

1.6    用例精确度增加步骤

          执行者和目标

          用例概述和主成功场景

          失败情况

          失败情况处理

1.7    系统使用叙述

系统使用叙述是一个处于运用状态的用例实例，其实可以这样理解：用例是一个类，而系统使用叙述是一个类的实例化—对象。用例中的执行者名称是通用的，如：“收银员”，而系统使用叙述中的执行者名称是真实的，如：“小王”。

书上在编定用例之前，先来一个系统使用叙述“热身”，我现在还是不明白这种热身有什么好处。