标签：笔记 情况 触发事件 时间 并且 编写 成功 简洁 而且
第六章中讲述了前置条件、触发事件和保证这三个方面。
简单来说，前置条件字面理解就是我们经常说的条件，条件成立，结果才有可能发生，此处也类似我们所说的条件。简单来说，创建订单依赖于“已经登录”这个前置条件。也就是说，2的前提是1，1发生2才能发生。这样就比较好理解了。在前置条件中，唯一强调的部分就是“一定要把真正必须的条件的写入前置条件。”这里有一个典型的事例，我们假设在索要保险总金额之前，申请人至少已经提交了一个申请或账单。然而，并不总是这样；系统不能保证这个假设的正确性，实际上这不是一个必要条件。申请人应该能在任何时候索要他们的保险总金额，因此诸如“申请人已经提交了一个账单”这样的前置条件是错误的。
同时，保证这个方面也类似上面说的前置条件，但是，此处保证一定是最小保证且这个语句一定要写成简单的断言形式。这个最简单的断言句就是咱们中文里说的缩句，而且是陈述句甚至是判断句，而不是冗长的各种条件和结果的假设。这样的话，才能够使用例显得更加简洁和已读。
第七章部分，讲到了这本书中，我比较喜欢的一部分，主成功场景部分。尤其是当王老师让我们重新描述一个案例的时候，我几乎是毫不犹豫的使用了这个方法。主成功场景，简而言之，就是一条主线下来，只留下最重要并且成功的部分。然后，在主成功场景下进行补充说明和解释，不断的分支，这样思路会更好的让自己清楚和理解整个事件。主成功场景从开始写到结束，按照时间的顺序写出来，然后使用扩展的方法在每个分支点写出场景的扩展。写扩展的时候，写出分支的条件以及处理分支的步骤。并且大多数扩展以重新与主成功场景回合而结束。某种程度上，需要集中讨论所有可能的失败和可选择的过程。从场景开始到结束以保证能够尽可能的覆盖所有情况。在第一遍完成的时候就会发现，其中有许多考虑步骤的方面，这时候就需要不断的回头重新考虑，至到完成完善整个场景。最后的要求就是：不断修改和替换进入扩展中的步骤，使得当扩展处理结束时，就像完成了原来的步骤一样。同时，0在必须的情况下才能创建扩展用例，因为这些用例不能被人们所理解，也不易维护。为了减少读者的阅读量，尽量的不让他们接触扩展用例。
通过写主成功场景和使用扩展的方法，可以缩短的文档，减少读者的阅读量。
标签：笔记 情况 触发事件 时间 并且 编写 成功 简洁 而且
原文地址：http://www.cnblogs.com/justmaomao/p/6087111.html
