测试用例设计规范

1、百胜百胜 FIS 2.0 CMD 测试用例规范测试用例规范 目录目录 1本系统功能测试本系统功能测试.2 1.1模块功能测试 .2 1.1.1测试用例属性.2 1.1.2测试用例功能设计原则.2 1.2模块间数据交互测试.7 1.2.1关联点（前置条件、后置条件） .7 1.2.2数据交互.7 1.3兼容、安全、UI 测试.7 1.3.1兼容测试.7 1.3.2UI 测试.7 1.3.3安全测试.8 2系统间接口测试系统间接口测试.8 3测试用例执行测试用例执行.8 4附录附录.10 4.1场景法设计 .10 4.1.1定义.10 4.1.2场景设计.10 4.1.3设计步骤.15 4.2边界

2、值设计 .15 4.2.1定义.15 4.2.2设计方法.15 4.3等价类划分设计 .15 4.3.1定义.15 4.3.2设计方法.16 1 本系统功能测试本系统功能测试 1.1 模块功能测试模块功能测试 1.1.1 测试用例属性测试用例属性 测试用例属性测试用例属性QC 中是否使用中是否使用EXCEL 中是否使用中是否使用备注备注 模块名称 测试场景 用例编号 用例名称 角色 前置条件需要的模块必须指出 Description 操作步骤 预期结果 创建人测试人可选 测试结果EXCEL 中是“通过” /“不通过” 测试时间可选 BUG 编号 1.1.2 测试用例功能设计原则测试用例功能设计

3、原则 设计测试用例的方法参考本文档的附录设计测试用例的方法参考本文档的附录 1.根据需求文档划分测试场景，按照测试场景命名测试步骤名称。如下图所示： 2.用例编号的命名规则为“模块名称（缩拼） ”+“-”+“4 位编号” ，编号自 0001 号开始。例如：基础 信息模块的用例编号，JCXX-0001；【注】该条为 EXCEL 测试用例书写规则 3.对于 XX 点的测试需求，至少需要确定两个测试用例。一个测试用例代表预期的条件，它可用于核 实行为是否正确或符合预期结果（正面测试） 。另一个测试用例代表不可接受的、异常的或意外的条 件，它可用于核实是否以预期结果实现（负面测试） ； 4.每条测试用

4、例是该页面中唯一的检查项； 5.每条用例描述的系统默认状态、默认数据也是该页面唯一的检查项。 1.1.2.1 数据输入数据输入 本系统中需输入的类型包括：文本框、下拉框、复选框、单选框、日期控件 公共用例公共用例 A.文本框/文本域（100、1000 个字符）：长度校验、类型校验、是否必填项校验 1)超出数据库长度、页面定义的长度均不允许输入 2)当定义的长度“数据库长度页面长度”时，超出页面长度则不允许输入 3)禁止输入的文本框，默认禁灰显示 B.下拉框：选择数据后是否有联动效果、点击后下拉显示数据内容、点击空白后下拉框收缩 C.单选框：选中、更换 D.复选框：选中、取消 E.日期控件：弹出

5、位置、选中后日期按格式要求显示在日期输入框、输入日期后点击日期控件自 动定位到所选择的的日期 F.分页：下拉框条数选择、首页、上一页、下一页、尾页、GO、输入框页数 各模块需书写的用例各模块需书写的用例 A.文本框：字符长度限制校验、输入类型校验、描述是否必填 B.下拉框：是否有默认值、选择项数据来源（需描述来源是：页面固定、数据库调用（描述出来 源的数据表） ） 【注】前期可以不需要描述数据表、后期确定后需补充 C.单选框：个数、显示方式（例如：是、否） 、默认项 D.复选框：个数、显示方式、是否默认勾选 E.日期控件：是否有选择范围控制 1.1.2.2 需求覆盖需求覆盖 测试用例中的测试点

6、要覆盖需求规格说明书中的业务场景以及业务规则（具体内容如下） ，且书写的测试 操作步骤、预期结果（正确、是否类词语不能出现）无歧义。 A.页面通用功能，如：通知、讨论、日志、导出、上传附件、返回； B.页面基本功能，如：新增、删除、修改、查询、保存； C.特定页面的功能，如：呈递、审批、重置、清空、同步、锁定； 1.1.2.3 功能点分类（讲述时加上背景）功能点分类（讲述时加上背景） 按照模块的“一级菜单(一级目录)、二级菜单（二级目录） 、页面名称（三级目录） 、TAB 页名称（四级 目录-如果页面中存在 TAB 页签） 、页面按钮/链接操作（用例的名称） 、步骤/测试数据” ，如下图所示：

7、 用例设计编写如下：用例设计编写如下： 1.页面元素检查： 页面标题； 页面所有控件及对应的字段名称（按钮、文本框、下拉框、单选框、复选框、日期控件） ； 控件是否有默认值显示以及对应的数据来源； 控件是否可编辑； 必填项校验（必填项的显示效果检查） ； 校验控件的格式、长度（有则需描述，无则略过） ； 页面包含的列表字段名称（有则需描述，无则略过该条件） ； 【注注】页面检查在查询、新增、编辑、审批页面需要添加描述页面检查在查询、新增、编辑、审批页面需要添加描述 2.查询： 列表默认数据（如果无数据显示是否有提示信息） ； 列表默认排序； 哪些字段支持排序功能； 单条件查询（每个查询条件均需

8、编写用例，需描述是否支持模糊查询） ； 全条件查询； 3.新增： 必填项效果检查（未填写保存后的提示效果，如：弹出必填提示信息，点击后光标定位到必填 项文本框等） ； 保存功能（必填项未填写，保存弹出提示） ； 1)全部字段信息填写； 2)只填写必填项； 保存成功提示语； 保存成功后停留在那个页面（新增页面、列表页面） ； 新增成功后需检查信息被添加至列表页面； 列表页面显示的字段信息为新增时填写的信息； 4.编辑： 字段需显示之前填写的信息； 必填项效果检查（未填写保存后的提示效果，如：弹出必填提示信息，点击后定位到必填项文 本框等） ； 字段是否可编辑； 单字段修改； 全部字段修改； 保存

9、功能（必填项未填写保存弹出提示；单字段修改保存成功后编辑页面/列表页面只是单个字 段的信息被修改） ； 保存成功提示； 保存成功后停留在那个页面（新增页面、列表页面） ； 修改成功后需检查信息被添加至列表页面； 列表页面显示的字段信息为修改时填写的信息； 5.删除： 信息是否被引用； 单个删除； 批量删除； 复选框的选中/取消； 删除弹出的提示； 删除成功的提示； 6.呈递： 呈递后的审批人； 呈递后添加一条信息至列表页面； 呈递审批列表页面查看下一节点的接收人； 呈递审批列表显示目前流程的进度； 呈递审批列表显示审批单的状态； 发送任务给审批人； 7.审批：（分审批通过、审批拒绝 2 种结果

10、书写） 页面需显示呈递的信息； 单个审批； 批量审批； 必填项效果检查（如：审批拒绝，须填写拒绝原因） ； 审批后添加一条信息至呈递审批列表页面； 呈递审批列表页面可查看下一节点的接收人； 呈递审批列表显示目前流程的进度； 呈递审批列表显示审批单的状态； 发送任务给审批人；（每个节点审批均需要检查） 终节点的审批人，审批通过需发送一条通知给申请人 每个节点的审批人，审批拒绝需发送一条通知给申请人（每个节点审批均需要检查） 8.上传附件： 页面特殊的附件需描述； 链接跳转至那个页面需描述； 附件个数； 新附件是否覆盖之前的旧附件； 附件格式筛选； 附件提示； 附件上传成功在列表页面显示信息； 附

11、件的操作； 9.通知： 候选人； 已选人； 单选功能； 全选功能； 通知后列表页面添加通知信息； 列表可查看通知的人员； 通知后我的工作室有一条通知信息； 点击通知链接可以跳转至对应的页面； 10. 讨论： 必填项效果检查（未填写发送后的提示效果，如：弹出必填提示信息，点击后定位到必填项文 本框等） ； 候选人； 已选人； 单选功能； 全选功能； 讨论后列表页面添加讨论信息； 列表可查看讨论的人员； 列表可查看讨论的信息内容； 发送讨论后我的工作室有一条通知信息； 点击通知链接可以跳转至对应的页面； 11. 日志： 查看日志记录； 核对字段记录信息； 关闭日志记录； 12. 返回： 返回至 X

12、X 页面； 链接跳转是否正确； 要求：要求： 1)按照特有的条件（如：不同类型的餐厅、不同角色）分开书写测试用例步骤 2)按照“查看页面、操作页面、保存页面、辅助功能的操作”的顺序书写测试用例 1.2 模块间数据交互测试模块间数据交互测试 1.2.1 关联点（前置条件、后置条件）关联点（前置条件、后置条件） 模块间存在的关联点，需描述出在 A 模块中的功能以及对 B 模块的影响。例如：A 模块的某个审批单在 审批之后才开启 B 模块中的页面。 1.2.2 数据交互数据交互 1.模块间存在数据交互，设计测试用例时需描述数据在 A、B 模块中的一致性。例如：A 模块的数据 是审批通过的某个定额，数

13、据在 B 模块显示时，数据必须与 A 模块中显示的一致。 2.模块间存在状态变更的，需描述在 A 模块修改状态之后，关联模块的 B 模块状态也随之修改。 1.3 兼容兼容、安全、安全、UIUI 测试测试 1.3.1 兼容测试兼容测试 不同浏览器版本在对同一处功能点显示时，会有不同之处。测试用例设计时，高版本浏览器和低版本浏 览器需分别设计测试用例。例如：用户 IE8 的浏览器需要显示 IE9 的特点时，需针对 IE8 浏览器设计不同的 测试用例。 1.3.2 UIUI 测试测试 对不同的页面都需要描述界面检查，检查内容如下： 1. 窗口切换、移动时正常吗？（公共用例，思考） 2. 各种界面元素

14、的文字正确吗？（如标题、提示等） 3. 各种界面元素的状态正确吗？（如正常、退出等状态） 4. 各种界面元素支持键盘操作吗？ 5. 各种界面元素支持鼠标操作吗？ 6. 对话框中的缺省焦点正确吗？ 7. 数据项能正确回显吗？ 8. 对于常用的功能，用户能否不必阅读手册就能使用？ 9. 执行有风险的操作时，有“确认”、“取消”等提示吗？ 10. 操作顺序合理吗？ 11. 分页显示，翻页、跳页是否实现？ 12. 界面各元素美观合理吗？ 1.3.3 安全测试安全测试 1.应用程序级别的安全性：检查角色只能访问其所属用户类型已被授权访问的那些功能或数据。 2.系统级别的安全性：检查只有具备系统和应用程序

15、访问权限的角色才能访问系统和应用程序。 3.对于各别页面需取消权限限制。例如：报表通知某些人员，这些人员点击链接是可以访问无权限查 看的页面。 4.无权限访问的页面，拷贝有权限访问人员的有效 URL 地址，检查无权限人员是否能访问 2 系统间接口测试系统间接口测试 1.设计接口测试用例时，需描述接口间交互的类型（如：删除、新增、修改） ，分类型书写测试用例； 2.同步接口时是否需要准备数据以及所准备数据的格式等，需详细描述；（如：.Csv 文件） 3.XX 系统的业务流程审批完成，下一步需接口测试的，需描述出此时的同步状态； 4.接口同步成功、同步失败反馈的状态、备注等信息需描述； 5.涉及金

16、额类数据接口测试时，需描述出检查接口同步前与同步后的金额、数量数据是否一致。 6.接口测试的数据部分需在数据库中检查时，需在接口测试用例中描述并给出具体的数据库名称或者 查询语句。 （限 QC 中书写测试用例） 3 测试用例执行测试用例执行 A.单元测试（此处单元测试指本系统中单模块测试）： 版本号版本号版本说明版本说明 V0.1 V0.2 V0.3 V0.4 V0.5 对所有主要功能进行测试 V0.6 V0.7 V0.8 执行所有功能、UI、控件测试用例 B.集成测试： C.系统测试： V0.9 V1.0 BUG 回测 说明：第一轮测试 5 个版本，第二轮测试 3 个版本，第三轮 2 个版本

17、，共计 10 个版本 版本号版本号版本说明版本说明 V0.1 V0.2 V0.3 V0.4 V0.5 执行所有的集成测试用例 V0.6 V0.7 V0.8 回测 BUG 以及执行页面 UI 以及页面控件测试用例 V0.9 V1.0 BUG 回测 说明：第一轮测试 5 个版本，第二轮测试 3 个版本，第三轮 2 个版本，共计 10 个版本 版本号版本号版本说明版本说明 V0.1 V0.2 V0.3 V0.4 V0.5 在不同客户端环境下进行全面测试 V0.6 V0.7 V0.8 BUG 回测 V0.9 V1.0 进行上线前的全面测试 说明：第一轮测试 5 个版本，第二轮测试 3 个版本，第三轮

18、2 个版本，共计 10 个版本 4 附录附录 4.1 场景法设计场景法设计 4.1.1 定义定义 现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触 发顺序和处理结果就形成事件流。用例场景要通过描述流经用例的路径来确定，这个流经过程要从用例开始 到结束遍历其中所有基本流和备选流。由此会产生很多组场景，如下图所示： 基本流：经过测试用例最简单的路径。 备选流：一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选 流 1 和 3） ；也可能起源于另一个备选流（如备选流 2） ，或者终止用例而不再重新加入到某个流（如 备选流 2 和

19、4） 。 4.1.2 场景设计场景设计 上图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示， 是经过用例的最简单的路径。每个备选流自基本流开始之后，备选流会在某个特定条件下执行。备选流可能 会重新加入基本流中（备选流 1 和 3） ，还可能起源于另一个备选流（备选流 2） ，或者终止用例而不再重新 加入某个流（备选流 2 和 4） 。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景： 场景 1基本流 场景 2基本流备选流 1 场景 3基本流备选流 1备选流 2 场景 4基本流备选流 3 场景 5基本流备选流 3备选流 1 场景 6基本流备选流

20、 3备选流 1备选流 2 场景 7基本流备选流 4 场景 8基本流备选流 3备选流 4 注：为方便起见，场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。 生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。 例如，假定上图描述的用例对备选流 3 规定如下： “如果在上述步骤 2输入提款金额中输入的美元量超出当前帐户余额，则出现此事件流。系统将显示一则警 告消息，之后重新加入基本流，再次执行上述步骤 2输入提款金额，此时银行客户可以输入新的提款金额。 ” 据此，可以开始确定需要用来执行备选流 3 的测试用例： 测试用例 ID 场景条件预

21、期结果 TC x场景 4步骤 2 - 提款金额 帐户余额在步骤 2 处重新加入基本流 TC y场景 4步骤 2 - 提款金额 帐户余额不执行备选流 3，执行基本流 TC z场景 4步骤 2 - 提款金额 = 帐户余额不执行备选流 3，执行基本流 注：由于没有提供其他信息，以上显示的测试用例都非常简单。测试用例很少如此简单。 下面是一个由用例生成测试用例的更符合实际情况的示例。 示例：示例： 一台 ATM 机器的主角和用例。 下表包含了上图中提款用例的基本流和某些备用流： 基本流本用例的开端是 ATM 处于准备就绪状态。 准备提款 - 客户将银行卡插入 ATM 机的读卡机。 验证银行卡 - AT

22、M 机从银行卡的磁条中读取帐户代码，并检查它是否属于可以接收的银行卡。 输入 PIN - ATM 要求客户输入 PIN 码（4 位） 验证帐户代码和 PIN - 验证帐户代码和 PIN 以确定该帐户是否有效以及所输入的 PIN 对该帐户来说是 否正确。对于此事件流，帐户是有效的而且 PIN 对此帐户来说正确无误。 ATM 选项 - ATM 显示在本机上可用的各种选项。在此事件流中，银行客户通常选择“提款” 。 输入金额 - 要从 ATM 中提取的金额。对于此事件流，客户需选择预设的金额（10 美元、20 美元、50 美元或 100 美元） 。 授权 - ATM 通过将卡 ID、PIN、金额以及

23、帐户信息作为一笔交易发送给银行系统来启动验证过程。对于 此事件流，银行系统处于联机状态，而且对授权请求给予答复，批准完成提款过程，并且据此更新帐户 余额。 出钞 - 提供现金。 返回银行卡 - 银行卡被返还。 收据 - 打印收据并提供给客户。ATM 还相应地更新内部记录。 用例结束时 ATM 又回到准备就绪状态。 备选流 1 - 银行卡 无效 在基本流步骤 2 中 - 验证银行卡，如果卡是无效的，则卡被退回，同时会通知相关消息。 备选流 2 - ATM 内 没有现金 在基本流步骤 5 中 - ATM 选项，如果 ATM 内没有现金，则“提款”选项将无法使用。 备选流 3 - ATM 内 现金不

24、足 在基本流步骤 6 中- 输入金额，如果 ATM 机内金额少于请求提取的金额，则将显示一则适当的消息， 并且在步骤 6 - 输入金额处重新加入基本流。 备选流 4 - PIN 有 误 在基本流步骤 4 中- 验证帐户和 PIN，客户有三次机会输入 PIN。 如果 PIN 输入有误，ATM 将显示适当的消息；如果还存在输入机会，则此事件流在步骤 3 - 输入 PIN 处重新加入基本流。 如果最后一次尝试输入的 PIN 码仍然错误，则该卡将被 ATM 机保留，同时 ATM 返回到准备就绪状态， 本用例终止。 备选流 5 - 帐户不 存在 在基本流步骤 4 中 - 验证帐户和 PIN，如果银行系统

25、返回的代码表明找不到该帐户或禁止从该帐户中 提款，则 ATM 显示适当的消息并且在步骤 9 - 返回银行卡处重新加入基本流。 备选流 6 - 帐面金 额不足 在基本流步骤 7 - 授权中，银行系统返回代码表明帐户余额少于在基本流步骤 6 - 输入金额内输入的 金额，则 ATM 显示适当的消息并且在步骤 6 - 输入金额处重新加入基本流。 备选流 7 - 达到每 日最大的 提款金额 在基本流步骤 7 - 授权中，银行系统返回的代码表明包括本提款请求在内，客户已经或将超过在 24 小 时内允许提取的最多金额，则 ATM 显示适当的消息并在步骤 6 - 输入金额上重新加入基本流。 备选流 x - 记

26、录错 误 如果在基本流步骤 10 - 收据中，记录无法更新，则 ATM 进入“安全模式” ，在此模式下所有功能都将 暂停使用。同时向银行系统发送一条适当的警报信息表明 ATM 已经暂停工作。 备选流 y - 退出 客户可随时决定终止交易（退出） 。交易终止，银行卡随之退出。 备选流 z - “翘起” ATM 包含大量的传感器，用以监控各种功能，如电源检测器、不同的门和出入口处的测压器以及动作检 测器等。在任一时刻，如果某个传感器被激活，则警报信号将发送给警方而且 ATM 进入“安全模式” ， 在此模式下所有功能都暂停使用，直到采取适当的重启/重新初始化的措施。 在第一次迭代中，根据迭代计划，我

27、们需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了下面的 事件流： 基本流 - 提取预设金额（10 美元、20 美元、50 美元、100 美元） 备选流 2 - ATM 内没有现金 备选流 3 - ATM 内现金不足 备选流 4 - PIN 有误 备选流 5 - 帐户不存在/帐户类型有误 备选流 6 - 帐面金额不足 可以从这个用例生成下列场景 场景 1 - 成功的提款基本流 场景 2 - ATM 内没有现金基本流备选流 2 场景 3 - ATM 内现金不足基本流备选流 3 场景 4 - PIN 有误（还有输入机会）基本流备选流 4 场景 5 - PIN 有误（不再有输入机会）基

28、本流备选流 4 场景 6 - 帐户不存在/帐户类型有误基本流备选流 5 场景 7 - 帐户余额不足 基本流备选流 6 【注】为方便起见，备选流 3 和 6（场景 3 和 7）内的循环以及循环组合未纳入上表。 对于这 7 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。 下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每 个测试用例，存在一个测试用例 ID、条件（或说明） 、测试用例中涉及的所有数据元素（作为输入或已经存 在于数据库中）以及预期结果。 通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景

29、，至少要确定包含执行场 景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效 的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用） 表明这个条件不适用于测试用例。 TC（测试用例） ID 号 场景/条件PIN 帐号 输入的金 额 （或选择 的金额） 帐面金额 ATM 内 的金额 预期结果 CW1.场景 1 - 成功的提款VVVVV成功的提款。 CW2.场景 2 - ATM 内没有 现金 VVVVI提款选项不 可用，用例 结束 CW3.场景 3 - ATM 内现金 不足 VVVVI警告消息， 返回基

30、本流 步骤 6 - 输 入金额 CW4.场景 4 - PIN 有误 （还有不止一次输入 机会） I Vn/aVV警告消息， 返回基本流 步骤 4，输 入 PIN CW5.场景 4 - PIN 有误 （还有一次输入机会） I Vn/aVV警告消息， 返回基本流 步骤 4，输 入 PIN CW6.场景 4 - PIN 有误 （不再有输入机会） I Vn/aVV警告消息， 卡予保留， 用例结束 在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例 CW1 称为正面测试用例。 它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只 有在符合条件的

31、情况下才执行基本流。这些负面测试用例由 CW2 至 6 表示（阴影单元格表明这种条件下需 要执行备选流） 。虽然 CW2 至 6 对于基本流而言都是负面测试用例，但它们相对于备选流 2 至 4 而言是 正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例（CW1 - 基本流） 。 每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景 4 正是这样的一个示例。要全面地 测试场景 4 - PIN 有误，至少需要三个正面测试用例（以激活场景 4）： 输入了错误的 PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤 3 - 输入 PIN。 输入了错误的 PIN，而且不

32、再有输入机会，则此备选流将保留银行卡并终止用例。 最后一次输入时输入了“正确”的 PIN。备选流在步骤 5 - 输入金额处重新加入基本流。 【注】在上面的矩阵中，无需为条件（数据）输入任何实际的值。以这种方式创建测试用例矩阵的一个 优点在于容易看到测试的是什么条件。由于只需要查看 V 和 I（或此处采用的阴影单元格） ，这种方式还易 于判断是否已经确定了充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例 还不完全，如场景 6 - 不存在的帐户/帐户类型有误和场景 7 - 帐户余额不足就缺少测试用例。 一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适

33、度，并取消多余或等效 的测试用例。测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据。 TC（测试用 例）ID 号 场景/条件PIN 帐号 输入的金 额 （或选择 的金额） 帐面金额 ATM 内 的金额 预期结果 CW1.场景 1 - 成功的提款4987809 - 49850.00500.002,000成功的提款。 帐户余额被更 新为 450.00 CW2.场景 2 - ATM 内没有现金4987809 - 498100.00500.000.00提款选项不可 用，用例结束 CW3.场景 3 - ATM 内现金不足4987809 - 498100.00500.0070

34、.00警告消息，返 回基本流步骤 6 - 输入金额 CW4.场景 4 - PIN 有误（还有不 止一次输入机会） 4978 809 - 498n/a500.002,000警告消息，返 回基本流步骤 4，输入 PIN CW5.场景 4 - PIN 有误（还有一 次输入机会） 4978 809 - 498n/a500.002,000警告消息，返 回基本流步骤 4，输入 PIN CW6.场景 4 - PIN 有误（不再有 输入机会） 4978 809 - 498n/a500.002,000警告消息，卡 予保留，用例 结束 以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测

35、试用例包括： 场景 6 - 帐户不存在/帐户类型有误：未找到帐户或帐户不可用 场景 6 - 帐户不存在/帐户类型有误：禁止从该帐户中提款 场景 7 - 帐户余额不足：请求的金额超出帐面金额 在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例： 无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等） 无法读卡（读卡机堵塞、脱机或出现故障） 帐户已消户、冻结或由于其他方面原因而无法使用 ATM 内的现金不足或不能提供所请求的金额（与 CW3 不同，在 CW3 中只是一种币值不足，而 不是所有币值都不足） 无法联系银行系统以获得认可 银行网络离线或交易过程中断电 在确定功能性测试用例时，确保满足下列条件： 已经为每个用例场景确定了充足的正面和负面测试用例。 测试用例可以处理用例所实施的所有业务规则，确保对于业务规则，无论是在内部、外部还是在边 界条件/值上都存在测试用