编写有效用例之三
用例格式
在以往做作业中发现用例格式的重要性，所有特别列出用例格式，备忘：
最基本的一个模板就是完整正式的用例模板：
完整正式的用例模板<名字>
|
<用例名应该是一个用主动语态动词短语来表示的用例目标> 使用语境：<目标较长的描述，如果需要，还包括触发条件> 范围：<设计范围，在设计时将系统作为一个黑盒来考虑> 级别：<概要、用户目标、子功能三者之一> 主执行者：<主执行者的角色名称或主执行者的描述> 项目相关人员和利益：<用例中的项目相关人员和关键利益的列表> 前置条件：<我们所希望的，周围环境已经达到的状态> 最小保证：<在所有退出操作前，如何保证得到必须的信息> 成功保证：<目标完成时环境的状态> 触发事件：<什么引发了用例，可能是时间事件> 主成功场景： <在这里写出从触发事件到目标完成以及清除的步骤> <步骤编号#><动作描述> 扩展： <在这里写出扩展，每次写一个扩展，每一个扩展都指向主场景中的特定步骤> <被改变步骤><条件>：<动作或子用例> <被改变步骤><条件>：<动作或子用例> 技术和数据变化列表： <在这里写出场景总因技术活数据变化而引起的可能分支> <步骤或变化编号#>：<变化列表> <步骤或变化编号#>：<变化列表> 相关信息： <项目所需要的所有附加信息>
|
与这正式的格式相比，程序开发组的往往比较中意一些单列、步骤编号的版本。
用例的单列表格格式
|
用例# |
<用例名应该是一个用主动语态动词短语来表示的用例目标> |
||
|
使用语境 |
<如果需要，写出语境的详细陈述> |
||
|
范围 |
<在设计时将系统作为一个黑盒来考虑> |
||
|
级别 |
<概要、用户目标、子函数三者之一> |
||
|
主执行者 |
<主执行者的角色名称或主执行者的描述> |
||
|
项目相关人员和利益 |
项目相关人员 |
利益 |
|
|
|
<项目相关人员名称> |
<项目相关人员取得的利益> |
|
|
|
<项目相关人员名称> |
<项目相关人员取得的利益> |
|
|
前置条件 |
<我们所希望的，周围环境已经达到的状态> |
||
|
最小保证 |
<在所有退出操作前，如何有效保证项目相关人员的利益> |
||
|
成功保证 |
<如果目标完成时满足项目相关人员的利益> |
||
|
触发事件 |
<触发系统启动用例的动作> |
||
|
描述 |
步骤 |
活动 |
|
|
|
1 |
<在这里写出从触发事件到目标完成以及清除的步骤> |
|
|
|
2 |
<...> |
|
|
|
3 |
|
|
|
扩展 |
步骤 |
分支动作 |
|
|
|
1a |
<引起分支的条件> |
|
|
|
|
<活动或子用例名称> |
|
|
|
|
|
|
|
技术和数据变化 |
|
|
|
|
|
1 |
<变化列表> |
|
还有一些常见的格式有非正式的用例格式、单列表用例格式、双列表用例格式、RUP用例格式、条件语句格式、Occam格式、图形方式、UML用例图。
影响用例书写格式的因素有：
矛盾因素：业务环境、社会作用、不同文化；
当想要描述用例时，可能会遇到突然发现我们总是按照另为一种方式去做事情，或者会在不同的文化背景中存在有偏见的看法等等。
理解层次：
在不同的时间、地点，不同的人对同一件事情会有不同的理解。
项目相关人员的要求：
用户是读者，也是用例的使用者，他们关心用例的顶层描述；
技术人员是编写者或实现者，他们关心细节；
还有其他项目相关人员关注的地方都不尽相同。
经验与格式：
经验：每个小组中都有用例才初学者，但是很快就会成为“有经验”的设计者。有经验的人知道一些捷径；初学者则希望有清晰的方向和一致的指令。
格式：不管对有经验的设计者还是初学者，领导者或部门传统的工作方式都是需要一种正式的（或非正式）的书写格式。
程序设计人员和用户界面设计者需要准确的知道地址意味着什么，地址包括哪些域，每个域的长度，以及地址、传真号、电话号码的验证规则，等等。所有这些信息包含在需求的其他部分中，但不在用例中表示。
用例只是需求文档“第3章”——行为需求，它们不包括系统性能需求、业务规则、用户界面设计、数据描述、有限状态机行为、优先级以及其他相关信息。
事实上，有些信息可以作为用例相关信息附在用例上：比如用例优先级、期望的发生频率、性能要求、交付日期、次要执行者、业务规则（可能）、未解决的问题。可以根据不同项目调整这些信息。报认为重要的信息包好进去。
对每个用例的提示：
- 每个用例都是一篇散文：“就像写散文一样，全部困难在于既要采用单调的写作方式，又要富有完美的表达能力”。
- 使用例易于阅读：要求需求文档短小简明，而且易于阅读。
- 仅适用一种句型：现在时态的句子、在主动语态中用主动动词、描述执行者成功到达的目标、这些目标推动了整个过程的前进。
- “包含”子用例；
- 谁控制球：应该按从上往下的角度，以观察和记录景物的方式来编写用例。
- 正确地得到目标层；
- 不考虑GUI：确定你所写的每一步恰好抓住了执行者的真实意图，而不仅仅是操作用户界面的动作。
- 两个结局：成功和失败。当一个执行步骤调用一个子用例时被调用的用例可能成功或者失败。
- 项目相关人员需要的保证：用例描述了系统在不同环境下怎样通过用户驱动的场景来保护所有人的利益。用例描述了系统提供给这些人的保证。
- 前置条件：用例中的前置条件表明了用例的可运行条件。系统必须保证前置条件为真。编写前置条件是为了以后用例编写中不用再对它们进行检查。
- 对用例进行通过/失败测试；
