跟我一步一步学写测试用例 2

cntesting.com原创，转载请注明作者和出处。

点击这里查看原文

好了，现在案例有了，我们来看看测试用例是什么？下面是对测试用例的关键字解释：

测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

以上解释引用pennychueng，大家可以通过这个联结和他联系。

实际上不同的应用虽然都有测试用例，但是它们的侧重点不一样，今天我们面对的是ATM取款机，这样某些测试用例就要设计的非常“与众不同”了。你现在马上就要动手写吗？No，No，好的设计来自于更多的思维，如果是我我习惯在一张纸上先把业务的流程画出来，它可能是这样的：




看起来有点歪歪扭扭的，当然了这是我想得随手画出，其实这里面肯定有某些方面的逻辑错误和遗漏，不过这样做算是我对要测试物粗浅的理解好了。正规流程是我们先找到这个ATM取款机的用例（UserCase），也可以是详细设计文档，也可以是需求规格说明等等，反正你要找到描述这个ATM取款机业务逻辑和操作逻辑的文档，不然只是靠想象100%做不好测试，第一份用例是这样的：

ATM取款机系统

用例规约

登录ATM取款机用例

版本：草案

修订历史记录

日期     版本 说明   作者
21/Dec/98 草案 草案版本 Fastpoint

目录

1. 简要说明
2. 事件流
  2.1 基本流 - 输入用户密码
  2.2 备选流
    2.2.1 密码后台验证
3. 特殊需求
4. 前置条件
4.1 插卡动作
5. 后置条件
6. 扩展点

登录ATM取款机用例

1. 简要说明
本用例允许普通用户登录ATM取款机系统。本用例覆盖用户密码后台验证。

本用例的主角是普通用户。

2. 事件流
ATM取款机初始化完毕插卡后，本用例就开始使用了。

基本流 - 输入用户密码
1. 初始界面，等待用户密码输入。
2. 普通用户点击键盘“1”。
3. 普通用户点击键盘“2”。
4. 普通用户点击键盘“3”。
5. 普通用户点击键盘“4”。
6. 普通用户点击键盘“5”。
7. 普通用户点击键盘“6”。
8. 系统后台验证普通用户密码，正确。
9. 系统切入ATM取款机普通用户个人帐户界面。
10. 系统后台验证普通用户密码，错误。
11. 系统显示普通用户个人帐户密码错误，返回步骤1。

备选流
1. 密码输入错误内部计数超过3次，普通用户个人帐户封存。
2. 密码后台验证。

特殊需求
特殊需求将在下次迭代中确定。

前置条件
1. 插卡
在本用例开始前，普通用户要登录插卡。

后置条件
后置条件将在下次迭代中确定。

扩展点
业务用例的扩展点将在精化阶段中确定。


 好了，到此为止我们终于看到用例了，该用例模式来自于RUP，比较干净缺点就是以后的文档分支联结过多，下一步我们就要看如何根据用例写测试用例了。