编写有效用例读后感一

这十天，我阅读了《编写有效用例》这本书。

用例是代表系统中各个项目相关人员之间就系统行为所达成的契约，描述了在不同条件下系统对某一项目相关人员的请求所作出的响应，可以用流程图、顺序图、Petri网或程序设计语言来表示用例。执行者做出请求，系统执行不同的行为序列，每一行为序列为一个场景，一个用例是多个不同场景的集合。

编写一个良好的用例应该有很好的可读性。编写用例有三个很重要的概念：范围、主执行者、层次。范围描述真正被讨论的系统是什么，主执行者有要实行的目标，目标的层次是高还是低。首先要记住以下的定义：执行者是指任何具有行为的人或物，项目相关人员是指被讨论系统的一次交互活动从而达到某一目标的人或物，用例是指规定被讨论系统行为的契约，范围是界定被讨论的系统，前置条件和保证是指在用例执行之前和之后必须满足的条件，主执行成功场景是指一切顺利的情况，扩展是指场景执行过程中出现的不同情况，扩展中的编号是指在主成功场景中不同情况发生时所处的执行步骤号码，当一个用例引用另一个用例时被引用的用例加下划线。

人们在多数情况下没有时间去把用例写的正式、完整、漂亮，而是尽可能将其写的充分，写用例的时候要是附加上业务语境，以表明计算机应用程序如何在一个工作日期间运行，这样不用再单独写一个文件来描写业务过程，既不会影响任何人对用例的理解，又能给相关人员提供必要的信息。不同情况下所提倡的编写风格都会稍有差别，用例编写的主要派生形式，分别使用于不同的编写目的：1.一个集中的工作组在收集需求时，或是一个大型工作组在讨论未来的需求时，编写用例的风格比较随意，相反，一个大型的或是分散的工作组或是正规化的工作组在收集需求时，编写用例的风格就会完整正式，随意的形式简化了用例模板；2.业务过程人员编写业务用例来描述业务操作，而硬件或软件开发人员编写系统用例来描述需求，可能还会需要编写一些系统用例来记录他们的设计结果；3.跟据所需视图的层次，可以有以下几种选择：概要目标描写一个经多次处理才能达到的目标，用户目标描写一个经一次处理就可以完成的目标，子功能描写用户目标的一部分；4.任何一个为将要设计的新系统编写需求时都会编写黑盒用例，这种用例不关心系统的内部细节，业务过程设计者编写白盒用例来描述公司或组织结构的内部过程如何运作。

当几个人聚在一起写用例的时候，会发现每个人对用例编写的某个方面有着不同的看法，这是因为每个人编写用例的目的不相同，要找到一种通用的方法来讨论用例，同时又要突出所有这些不同情况各自的特点，目前能采用的最好的办法是：首先概括地提出问题，随后通过例子本身来说明问题。各个项目的特点不同，所以小组在编写用例时可能会采用不同的方式，有的可能必须要求不同人员采用相同的编写风格，也可能允许不同人员保留自己的编写风格，这两种情况可能都是对的，没有放之四海而皆准的真理。错误的做法是在不需要十分精确和严格的定义的情况下仍然耗费项目组大量的时间和精力来编写用例，所以，只有一个用例模板是不够的，至少要有两个用例模板：一个非正式的，一个完整正式的，前一个在要求不严的项目中使用，另一个则在要求严格的项目中使用。任何项目都要根据自己的实际情况对其中之一加以调整，在一个项目中有效的用例在另一个项目中不一定就有效，应该更详细地说明用例是正式的还是非正式的，模板中哪些部分和格式是必要的，以及用例编写者之间在风格上允许有多大的差异。我们有必要把用例的编写技巧同用例质量和项目标准区别开来。

用例确实是需求，但是用例不是所有的需求用例不需要详细地描述外部接口、数据格式、业务规则和复杂公式。任何组织收集需求都是为了满足自身的满足，但是在任何一个标准中，用例仅仅是所有需求文档中的一部分。用例不是全部需求，而只是描述需求中的行为部分，是必需的功能。