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 、步骤编号使步骤更清晰,并在扩展部分给出引用的位置。完整的用例格式需要编号。