如何编写有效的用例

用例名称 - 订单票

名字不错。 它清楚地表明了用例是什么

目标 –客户成功在网站上预订足球比赛的门票

描述- 演员访问网站，查看
时间表，选择比赛
和座位，预订
门票并支付足球比赛的费用

明确提到了目标和描述。
这将有助于设计师
开发人员了解什么是
他们的设计文档和代码的目标

演员——客户、客户服务代表
前提条件 –系统已启动并正在运行。
触发器 -演员已访问系统以预订门票。
后置条件——演员可以订票。 系统更新信息。

所有其他用例细节，例如演员，
前置条件、后置条件和
提到了触发器，这将有助于
应用程序的设计和开发更容易。

主要流程 - 步骤

1. 演员访问网站并选择订票
2. 系统显示预订信息
3. 演员确认比赛细节（UI规范中的更多细节）
4. 演员确认座位详细信息（UI规范中的更多详细信息）
5. 系统确认可用性
6. 系统呈现表单获取用户信息
7. 参与者提供用户信息（另一个用例中的详细信息）
8. 系统显示付款信息表格
9. 参与者提供付款信息（另一个用例中的详细信息）
10. 系统确认详细信息并提供预订 ID
11. 演员存票
12. 演员退出系统。

包含的用例

- 付款

– 生成预订 ID

扩展用例

– 生成付款失败说明

– 打印票

主要流程中的步骤很清楚，但
UI 细节被忽略了。 用例中的 UI 详细信息
关于座位选择和匹配
选择会使用例变得笨拙。
用例清楚地显示了参与者必须做什么以及系统将做什么
付款流程在a中详细说明
不同的用例，以便任务可以
很容易分解成不同的设计组件。
包含和扩展用例被命名
这样可以
参考它们以获取更多详细信息。

备用流程

-取消门票

1. 演员取消交易
2. 系统取消交易

异常流

- 门票不适用于指定比赛/指定座位

1.系统显示错误信息

详细说明了备用流和异常流。

* 用例可以在引用、备用和异常流方面更详细。 这个例子是为了强调一个写得很好的用例应该包含什么。

用例名称——票务订购

该名称不是从用户的角度来看的，它看起来像是一个业务流程定义。

描述– 演员访问网站、查看赛程、选择比赛和座位、预订门票并支付足球比赛费用

缺少用例的目标。 设计人员、测试分析师和开发人员不会理解为什么必须开发此功能。

演员——客户、客户服务代表
触发器- 演员已访问系统以预订门票。
后置条件——演员可以订票。 系统更新信息。

缺少前置条件。

主要流程步骤

1. 客户访问网站并选择“订票”选项来订票
2. 系统在下拉列表中显示匹配列表。
3. 客户服务代表从下拉列表中选择
4. 系统以座位图显示座位详情
5. 演员选择座位。 如果座位不可用并显示错误消息。
6. 演员提供付款细节
7. 演员订票，否则取消票。
8. 系统使用客户的名字和随机生成的 4 位数字生成预订 ID

包含的用例
- 付款

在用例步骤中，有一些对实际 UI 元素的引用可能会使读者感到困惑。 备用流程写在主要流程中，这使得很难理解整个流程。
演员有很多名字——“客户、演员和客户服务代表，这令人困惑。
这里解释了预订 id 的生成，但与订购票相关的演员无关。
没有备用流程、异常流程，也没有提及所有相关用例。

这个用例缺乏清晰度和细节，不会帮助团队正确开发功能。

1. 姓名
2. 描述/目标
3. 前置条件
4. 扳机
5. 基本流程和备用流程
6. 异常情况
7. 发布条件
8. 如有特殊要求
9. 链接到 UI 详细信息和其他相关模型/图表

1. 实施细节
2. 内部处理
3. 非功能性需求
4. 用户界面细节应与用例同时完成，但在单独的文档中

.