用例编写常见问题

fasiondog · · 693次浏览 ·

注:以下用例常见问题来自《编写有效用例》([美] Alistair Cockburn 著)一书。

没有系统

下面是ATM系统取款用例的一部分:

修改前:

  1. 储户插入ATM卡,并输入密码
  2. 储户按“取款”按钮,并输入取款数目
  3. 储户取走现金、ATM卡并拿走收据
  4. 储户离开

修改提示:

用例展示了主执行者(储户)所做的一切,却没有显示系统行为。

修改后:

  1. 【储户】插入ATM卡
  2. 【ATM系统】从卡上读取银行ID、账号、加密密码、并用主银行系统验证银行ID和账号
  3. 【储户】输入密码
  4. 【ATM系统】根据步骤2读出的加密密码,验证储户输入了正确的密码
  5. 【储户】选择“取款”,并输入取款数量
  6. 【ATM系统】输出现金、ATM卡,显示账户余额
  7. 【ATM系统】记录事务到日志系统

没有参与人

下面是ATM系统取款用例的一部分:

修改前:

  1. 收集ATM卡、密码
  2. 收集取款事务类型
  3. 收集提前金额
  4. 验证账户上是否有足够的余额
  5. 输出现金、收据和ATM卡
  6. 复位

修改提示:

本用例从系统角度进行编写,显示了ATM系统的所有行为,但没有涉及参与人的行为。

修改后:

同前一节修改后的用例。

过多的用户接口细节

某网上采购系统买东西:

修改前:

  1. 【系统】显示输入ID及密码屏幕
  2. 【客户】输入ID和密码,然后按“OK”按钮
  3. 【系统】验证客户ID及密码,并在屏幕上显示个人信息
  4. 【客户】输入姓名、省份、城市、街道地址、邮编、电话号码,然后按“OK”按钮
  5. 【系统】验证是否为老客户
  6. 【系统】显示可用商品列表
  7. 【客户】选取所需购买的商品及数量,完成时按“提交”按钮
  8. 【系统】通过库存辅助系统验证购买商品是否有足够的库存

修改提示:

这种错误在用例编写中是最常见的。编写者大量描述用户接口,使得用例变成了用户手册,而不是需求文档。过多的接口细节虽然对用例本身没有什么影响,但这样不利于用例的可读性,使系统需求难以把握。

对用例的修改是:寻找一种描述用户意图的方法,而不是特定的解决方案。这有时需要一些创造性的工作。

修改后:

  1. 【客户】使用ID和密码进入系统
  2. 【系统】验证客户身份
  3. 【客户】提供姓名、地址、电话号码
  4. 【系统】验证客户为老客户
  5. 【客户】选择购买商品及数量
  6. 【系统】由库存系统验证商品有足够的库存

过低的目标层次

某网上采购系统买东西:

修改前:

  1. 【客户】使用ID和密码进入系统
  2. 【系统】验证客户身份
  3. 【客户】提供姓名
  4. 【客户】提供地址
  5. 【客户】提供电话号码
  6. 【客户】选取商品
  7. 【客户】确定购买商品数量
  8. 【系统】验证客户是否为老客户
  9. 【系统】打开到库存系统的连接
  10. 【系统】通过【库存系统】请求当前库存量
  11. 【库存系统】返回当前库存量
  12. 【系统】验证购买商品数量是否足够

修改提示:

显而易见,此用例非常冗长。但和上节用例相比,不能说它对用户接口描述过细。为了缩减此用例,是整个过程更清晰,其缩短步骤如下:

  • 对数据项(3~5步)进行合并,将这些分散的步骤放在一步中完成。“如何概括客户提供的信息呢?”。答案是:“个人信息”。在概括信息别名的基础上,明确其字段,或提供其字段详细定义的引用。
  • 可以把所有处于同一方向上的信息合并为一步(3~7步),参考准则3。
  • 寻找一个更高层次的目标(8~11步)。“系统为什么需要做这些事呢?”那么可以用一句话回答,即“系统试图通过库存系统来验证购买的商品是否有足够的库存。如上所述,如果用这个高层目标来捕获这些需求,则将使用例描述更清晰、更简明。

修改后:

  1. 【客户】使用ID和密码进入系统
  2. 【系统】验证客户身份
  3. 【客户】提供个人信息(包括姓名、地址、电话号码),选择购买的商品及其数量
  4. 【系统】验证客户为老客户
  5. 【系统】通过库存系统验证商品有足够的库存
  6. ……

发表评论

电子邮件地址不会被公开。 必填项已用*标注

我不是机器人*