（4）用例（UseCase）及其定义
- 它描述了当主角之一给系统特定的刺激时系统的活动，是主角通过系统完成一个过程时出现的一组事件，最终以实现一种功能。
- 通常，用例侧重于功能，但不重点描述该功能的实现细节。
- 用例的大小划分一般以事件流在10个步骤左右为好。
（5）用例的分类
- 业务用例（Business Use Case）
指系统提供的业务功能与参与者的交互，表现问题领域中各实体间的联系和业务往来活动。它用于建立问题领域的业务用例模型。 - 系统用例（System Use Case）
指参与者与系统的交互，它表现了系统的功能需求和动态行为。
注意：用例确定的只是交流的目的，而不是交流的手段
客户并不需要了解执行者、用例这些概念。用例能告诉开发团队“去向客户了解什么”（目的），不能告诉你如何向客户去了解（手段）；
手段可以有很多种，文档研究、问卷调查、访谈、观察、研究竞争对手、开会、原型、场景演示…，使用用例思维来指导这些交流手段，会使交流更有目的，更加高效。因为以场景方式表达的需求本来就比一条条列出的需求要便于交流。
（6）用例的层次化
按照抽象层次，用例图可以划分为系统层（最高层）、子系统层（可以再细分）和对象类层（最低层）。
- 系统层用例图描述系统提供的全部服务。
- 子系统层用例图描述子系统提供的服务，它的外部交互者可以是其他的子系统或高一层的参与者。
- 对象类层的用例图描述对象类提供的功能片或操作，它的外部交互者可以是其他对象类或高一层活动者。
（7）用例建模的主要步骤
- 确定边界（区分敌我---找出系统外部的活动者和外部系统，确定系统的边界和范围）和参与者
- 确定用例（功能实现的）优线级和相互依赖关系
- 对用例进行分层（适当分解和细化用例，用例需要细化到什么程度？）
- 编写主成功场景，并尽可能列出所有扩展条件。编写扩展处理的步骤。
五、如何编写用例
（1）编写用例时，最应该注意的几种问题
- 编写功能需求，而不是编写使用设想文本
- 描述属性与方法，而不是描述习惯用法
- 编写的用例过于简要并且把自己与用户界面完全隔离
- 回避详细的边界对象名称，同时从第三者的角度而不是用户角度编写用例，并用采用被动式
- 仅仅描述用户交互，而忽略系统响应
（2）用例示例点评
- 错误用例
用例：提取现金
范围：ATM系统
主执行者：储户
1.储户插入ATM卡，并键入密码
2.储户按“取款”按钮，并键入取款数目
3.储户取走现金、ATM卡并拿走收据
4.储户离开 - 修正上面的用例
问题原因：没有系统
修正后：
范围：ATM系统
主执行者：账户持有者
1.通过读卡机，储户插入ATM卡
2.ATM系统从卡上读取银行ID、账号、加密密码，并用主银行系统验证银行ID和帐号
3.储户键入密码，ATM系统根据上面读出的卡上加密密码，对密码进行验证。
4.储户选择取款，并键入取款数量。
5.ATM系统通知主银行系统，传递储户账号和取款数量，并接收返回的确认信息和储户账户余额。
6.ATM系统输出现金、ATM卡，显示账户余额的收据。
7.ATM系统记录事务到日志文件。 -
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
