1、如何体现用例包含所有可能路径
（1）用第二章所提到的条纹裤，缺点是场景的任何一个变化都导致了在其他包含相同文字的场景里都必须做一份拷贝。
（2）使用条件语句，缺点是读者要阅读这些条件语句会很困难，特别是当一个条件句中又嵌套了一个条件句。
（3）将主成功场景从开始到结束，按照时间的顺序写出来，然后在每个分支点写出场景的扩展。
书上提倡用方法（3）
2、扩展通常是这样的，在主成功场景下，对于因为特别条件而出现行为分支的每个地方，写出分支的条件以及处理分支的步骤。大多数扩展以重新与主成功唱机果农汇合而结束。这些扩展最可能出现在系统需求中。开发组通常对主成功场景很了解。而错误处理通常使用并不为开发人员所了解的业务规则。需求分析人员必须研究正确的系统响应，而这样的研究经常会引入新的执行者、新用例或新扩展条件。
3、需求阶段可分为三个阶段:
（1）集中讨论，发现你和同事能够想到的每种可能。
（2）根据准则11、12，评估、删除以及合并所有建议。
（3）详细讨论，并找到处理每一种情况的方法。
4、扩展条件（extension condition）就是在一些条件下系统会完成不同的动作，它不是失败或异常，所以能够包括成功和失败两种条件。
示例1：
……
4．用户要求系统保存
……
扩展：
4a. 系统自动检测中间保存的要求：
4a1……
4b. 保存失败：
4b1……
5、集体讨论所有可能的情况，这些情况中的场景可能失败，或通过其他方式获得成功，仔细考虑下面所有的条目（括号里面内容是例子）：
l 一种可选择的成功路径（职员使用便捷的代码）
l 主执行者操作错误（无效密码）
l 主执行者无任何操作（等待密码超时）
l “系统确认”这个短语的每一次出现，都暗示了将会有一个处理系统失败的扩展（无效的账号）
l 从辅助执行者那里得到不恰当的响应或没有响应（响应超时）
l 作为正常功能的一部分，检测所设计系统的内部错误，并处理（现金分配阻塞）
l 必须处理不期望和异常的内部错误，并产生一个外部可见的结果（发现崩溃的事务日志）
l 必须检测系统关键性能的失败（回答没有在5秒内完成）
6、准则11：用“检测到什么”的方式来编写条件
应该写出系统检测什么，而不仅仅写出发生了什么。如：不要写，“顾客忘记了密码”，应该写，“等待用户输入密码的时间超时或密码输入的时间超时”。
7、合理化是为了使扩展列表尽可能的短。理想的扩展条件列表是所有的而且仅是必须由系统处理的情况。清除那些系统不需要处理的条件，合并那些对系统来说等价的条件，请使用下面的标准：
l 系统必须能够检测到条件
l 系统必须完成条件的检测
8、作为合并等价条件的一部分，从低层用例中提取等价的失败情况，合并到高层用例中。低层失败的合并（rolling up）是我们在高层上避免扩展条件爆炸的一种方法。
9、扩展是一个小型的用例。触发事件是扩展条件；目标是完成用例目标或者覆盖所有可能出现的失败。用例主体是执行步骤集和这些步骤可能的扩展。在用例中，扩展以完成或放弃它的目标作为结束。
10、准则12：条件处理的缩排方式
当我们使用编号方式时，应该缩排那些指明如何处理条件的执行步骤，并在子目后重新从编号1开始。
方式1
扩展
2a. 资金不足：
2a1.系统通知顾客，要求输入一个新的数量。
2a2. 顾客输入新的数量。
方式2
扩展
2a. 资金不足：
.1 系统通知顾客，要求输入一个新的数量。
.2 顾客输入新的数量。
方式2的优点是当编号变化时，例如步骤2变为步骤3，对扩展处理步骤的重新编号变得相当简单。
11、将扩展分离为新的子用例，仅仅需要确定主执行者的目标是什么，给出新用例的级别（可能是子功能级），在新级别中为新用例命名。在以下两种情况下，你可以为扩展创建新用例：
l 扩展在多个地方使用。将扩展转变为用例意味着它可以在同一个地方被跟踪和维护。
l 扩展使得用例难以阅读。我发现两页左右的用例文档和三级缩排是可读性的极限。
这一章着重介绍用例扩展的作用和编写方式，使用扩展可以提高用例的可读性，特别是面对客户的时候，客户也可以看的懂，但是扩展过于复杂，特别出现嵌套情况时，还可以考虑单独提取出一个新用例，这有点像代码重构，姑且可把他叫做用例重构。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。