跟我一步一步学写测试用例1fastpoint[链接].doc

跟我一步一步学写测试用例 1 FastPoint [ 链接]我知道这里有很多朋友刚刚进入测试，为了减少新朋友们对“如何写测试用例”的问题，特别制作了这个教程。我趋向于使用自己开发的应用做案例，这里使用的是ATM取款机模拟器，我们使用这个案例来描述书写测试用例的整个过程，如图1：图1整个界面是比较干净的，跟银行的路边取款机界面没有什么区别，现在我们来看一下如何操作它。首先模拟插卡动作，这个时候ATM显示器出现这样的状况，如图2：图2现在ATM显示器提醒我们输入用户密码，继续操作选择小键盘输入用户密码，ATM显示器显示“******”，点击“确定”按钮，如图3：图3如果密码正确我们可以进入个人账户主界面，如图4：图4现在我们随意操作，根据平常我取钱的动作我会先查看一下我当前的账户余额，点击ATM显示器右边和“查询”对齐的“”help按钮，进入账户当前余额界面，如图5：图5哇，我这么挥霍无度的人还有5000大元，足够请我的学生吃饭了，呵呵。现在点击和“返回”对齐的“”help按钮，返回个人账户主界面，点击ATM显示器右边和“取款”对齐的“”help按钮，进入账户取钱界面，如图6：图6啊，我要取2000元呢，好像当前快捷操作的只有“100”、“200”、“500”，那只好操作“自定义取款”了，点击ATM显示器右边和“自定义取款”对齐的“”help按钮，进入账户自定义取款界面，点击小按钮“2”，“0”，“00”，点击“确定”按钮，钱就这么出来了，呵呵。如图7：图7再检查一下帐户万一这机器不牢靠，扣多了就亏大了，看看：图8 跟我一步一步学写测试用例 2好了，现在案例有了，我们来看看测试用例是什么？下面是对测试用例的关键字解释：测试用例（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.