第七章 场景和步骤
1、主成功场景就是主执行者完成了目标，所有项目相关人员的利益都被满足了的场景。
2、主成功场景和所有场景扩展都包含的元素
主成功场景 扩展场景
场景执行的条件 前置条件加上触发事件 扩展条件
完成的目标 用例的名称 完成用例目标，或者是在处理扩展场景后重新进入主成功场景
执行步骤集 场景主体
结束条件 结束时完成的目标
作为场景片断的、可能的扩展集 用例模板中的扩展部分 可以嵌入到扩展体中，或者写在扩展体里面，或者就写在扩展体的后面
3、场景主体：每个场景或片段被描述为由不同执行者完成目标的活动序列
序列即无判断和循环，这是用例描述的基本特点。
场景主题必须把这三步描述完成（括号里文字是例子）：两个执行者之间的交互（“顾客输入地址”）——为了保护项目相关人员利益的确认过程（“系统确认PIN密码”）——满足项目相关人员利益的内部变化（“系统从余额中扣除一定数量的金额”）
4、执行步骤时对用例的补充，并且都有统一的语法形式，在一个简单活动中，执行者完成任务或向另外的执行者发送信息。
5、执行步骤的10大准则
（1）使用简单的语法；
句子结构应该非常简单：主语……谓语动词……直接宾语……前置短语
例如 系统……从帐户余额中扣除……一定数量……
（2）明确地写出“谁控制球”；
作者举了踢足球的场景的例子，说明了不管步骤的执行者如何变化，都要遵循（1）描述的格式。
（3）从俯视的角度来编写用例；
从用户的角度来写用例，而不是从系统内部来描述系统
（4）显示过程向前推移；
可能是翻译的问题，意思应该是如果过程繁杂，超过了9步，那么考虑提高目标层次，即“向前推移”
（5）显示执行者的意图而不是动作；
通过操纵系统的用户界面来描述用户的动作，这是在编写用例时常见的一种严重错误，它使得编写的目标处于一个很低的层次。我把它叫做“界面细节描述（interface detail description）”。在需求文档中，我们只关心界面所要达到的意图，总结在执行者之间传递的信息。可将这些低层次的步骤合并成一个步骤。
（6）包含“合理”的活动集；
用例描述为了表现一个事务，分解成了四个步骤，而这些步骤各有其复杂度，书中给出了五种形式，一种比一种分步多，作者倾向于中间第三和第四种形式，不过他也提出要视具体步骤复杂度来确定采用什么形式
（7）“确认”而不是“检查是否”
这是一个经常犯的错误，写用例不是写程序流程，不需要用选择语法，需要选择的时候，在扩展场景里体现。
（8）可选择地提及时间限制；
（9）习惯用语：“用户让系统A与系统B交互”；
要分开来写，用户与系统A怎么怎么样，然后系统A和系统B怎么怎么样，这样用户才能看的懂。
（10）习惯用语：“循环执行步骤X到Y，直到条件满足”；
同（7），但如果需要重复的话，可直接在重复的步骤的前面和后面说明即可。
总之，这10大原则，目的就是为了让用例成为用户和开发人员沟通的桥梁，所以语言要简单易懂，而且要逻辑清晰。
6、步骤编号使步骤更清晰，并在扩展部分给出引用的位置。完整的用例格式需要编号。
第八章 扩展
1、如何体现用例包含所有可能路径
（1）用第二章所提到的条纹裤，缺点是场景的任何一个变化都导致了在其他包含相同文字的场景里都必须做一份拷贝。
（2）使用条件语句，缺点是读者要阅读这些条件语句会很困难，特别是当一个条件句中又嵌套了一个条件句。
（3）将主成功场景从开始到结束，按照时间的顺序写出来，然后在每个分支点写出场景的扩展。
书上提倡用方法（3）
2、扩展通常是这样的，在主成功场景下，对于因为特别条件而出现行为分支的每个地方，写出分支的条件以及处理分支的步骤。大多数扩展以重新与主成功唱机果农汇合而结束。这些扩展最可能出现在系统需求中。开发组通常对主成功场景很了解。而错误处理通常使用并不为开发人员所了解的业务规则。需求分析人员必须研究正确的系统响应，而这样的研究经常会引入新的执行者、新用例或新扩展条件。
3、需求阶段可分为三个阶段:
（1）集中讨论，发现你和同事能够想到的每种可能。
（2）根据准则11、12，评估、删除以及合并所有建议。
（3）详细讨论，并找到处理每一种情况的方法。
4、扩展条件（extension condition）就是在一些条件下系统会完成不同的动作，它不是失败或异常，所以能够包括成功和失败两种条件。
示例1：
……
4．用户要求系统保存
……
扩展：
4a. 系统自动检测中间保存的要求：
4a1……
4b. 保存失败：
4b1……
5、集体讨论所有可能的情况，这些情况中的场景可能失败，或通过其他方式获得成功，仔细考虑下面所有的条目（括号里面内容是例子）：
? 一种可选择的成功路径（职员使用便捷的代码）
? 主执行者操作错误（无效密码）
? 主执行者无任何操作（等待密码超时）
? “系统确认”这个短语的每一次出现，都暗示了将会有一个处理系统失败的扩展（无效的账号）
? 从辅助执行者那里得到不恰当的响应或没有响应（响应超时）
? 作为正常功能的一部分，检测所设计系统的内部错误，并处理（现金分配阻塞）
? 必须处理不期望和异常的内部错误，并产生一个外部可见的结果（发现崩溃的事务日志）
? 必须检测系统关键性能的失败（回答没有在5秒内完成）
6、准则11：用“检测到什么”的方式来编写条件
应该写出系统检测什么，而不仅仅写出发生了什么。如：不要写，“顾客忘记了密码”，应该写，“等待用户输入密码的时间超时或密码输入的时间超时”。
7、合理化是为了使扩展列表尽可能的短。理想的扩展条件列表是所有的而且仅是必须由系统处理的情况。清除那些系统不需要处理的条件，合并那些对系统来说等价的条件，请使用下面的标准：
? 系统必须能够检测到条件
? 系统必须完成条件的检测
8、作为合并等价条件的一部分，从低层用例中提取等价的失败情况，合并到高层用例中。低层失败的合并（rolling up）是我们在高层上避免扩展条件爆炸的一种方法。
9、扩展是一个小型的用例。触发事件是扩展条件；目标是完成用例目标或者覆盖所有可能出现的失败。用例主体是执行步骤集和这些步骤可能的扩展。在用例中，扩展以完成或放弃它的目标作为结束。
10、准则12：条件处理的缩排方式
当我们使用编号方式时，应该缩排那些指明如何处理条件的执行步骤，并在子目后重新从编号1开始。
方式1
扩展
2a. 资金不足：
2a1.系统通知顾客，要求输入一个新的数量。
2a2. 顾客输入新的数量。
方式2
扩展
2a. 资金不足：
.1 系统通知顾客，要求输入一个新的数量。
.2 顾客输入新的数量。
方式2的优点是当编号变化时，例如步骤2变为步骤3，对扩展处理步骤的重新编号变得相当简单。
11、将扩展分离为新的子用例，仅仅需要确定主执行者的目标是什么，给出新用例的级别（可能是子功能级），在新级别中为新用例命名。在以下两种情况下，你可以为扩展创建新用例：
? 扩展在多个地方使用。将扩展转变为用例意味着它可以在同一个地方被跟踪和维护。
? 扩展使得用例难以阅读。我发现两页左右的用例文档和三级缩排是可读性的极限。
总结 ：本章着重介绍用例扩展的作用和编写方式，使用扩展可以提高用例的可读性，特别是面对客户的时候，客户也可以看的懂。
