场景法主要用于测试软件的业务过程或业务逻辑,是一种基于软件业务和用户行为的测试方法。
1.概念:前几篇讨论的测试方法侧重于数据的选择,不涉及操作步骤,无法对涉及用户操作的动态执行过程进行覆盖测试。当在系统功能层面上进行测试时,不仅设计测试数据的问题,更侧重要的是如何从系统整个业务流程的全部角度对系统进行测试。场景法运用场景对系统的功能点或业务流程进行描述,然后设计测试用例,从而提高了对系统主要功能和业务流程的测试效果。场景法适合测试业务流程清晰的系统或功能。
2.基本流和备选流
考虑用例从开始到结束所有可能的基本流和备选流的组合,可以确定不同的用例场景。例如,根据上图,可以确定以下用例场景。
基本流和备选流的区别:
基本流 | 备选流 | |
测试重要性 | 重要 | 次要 |
数量 | 一个 | 一个或多个 |
初始节点位置 | 系统初始状态 | 基本流或其他备选流 |
终止结点位置 | 系统终止状态 | 基本流或系统终止状态 |
是否构成完整的业务流程 | 是 | 否,仅为业务流程的执行片段 |
能否构成场景 | 能 | 否,需要基本流共同构成场景 |
3.场景法步骤及实例
根据场景法设计测试用例的步骤如下:
(1)根据说明,描述出程序的基本流及各个备选流;
(2)根据基本流和各个备选流生成不同的场景
(3)对每一个场景生成相应测试用例
(4)对生成的所有测试用例重新审查,去掉多余的测试用例。测试用例确定后,对每一个测试用例确定测试数据值
实例:某旅馆住宿系统支持网上预定业务。游客访问网站进行房间预定操作,选择预定日期、合适的房间后,进行在线预定。此时需要使用个人账号登陆系统,待登录成功后,进行定金支付。订金支付成功后,生成房间预订单,完成整个房间的预定流程。系统允许的预定期限为30舔,订金为400元。
(1)确定基本流和备选流
类型 | 描述 | 类型 | 描述 |
基本流 | 选择预定日期 | 备选流1 | 预定日期超限 |
选择房间 | 备选流2 | 无空余房间 | |
登陆账户 | 备选流3 | 账户不存在 | |
订金支付 | 备选流4 | 密码错误 | |
产生预定订单 | 备选流5 | 用户账户余额不足 |
(2)根据基本流和备选流生成不同场景
(3)用例设计
用例 | 场景/条件 | 预定日期 | 房间 | 账号 | 密码 | 账号余额 | 预期结果 |
1 | 场景1 | V | V | V | V | V | 成功预定,提示预定成功,余额减少 |
2 | 场景2 | I | n/a | n/a | n/a | n/a | 提示“预定日期无效”,重选预定日期 |
3 | 场景3 | V | n/a | n/a | n/a | n/a | 提示“预定日期房间已满”,重选预定日期 |
4 | 场景4 | V | I | I | n.a | n/a | 提示“账号不存在”,重新输入账号 |
5 | 场景5 | V | V | V | I | n/a | 提示“密码错误”,重新输入密码 |
6 | 场景6 | V | V | V | V | I | 提示“账号余额不足请充值” |
在上表中,无须为条件输入任何实际的数值,这样做的优点是只需要查看各条件的“V”和“I”的设定情况,如果某个条件不具备“I”的取值情况,则说明还未测试该条件无效的情况,提示测试用例还不够充足
(4)确定测试用例数据值(假定UserOne为已注册用户,密码为MyPass;UserTwo是未注册用户)
用例 | 场景/条件 | 预定日期 | 房间 | 账号 | 密码 | 账号余额 | 预期结果 |
1 | 场景1 | 一个有效日期 | 未满 | UserOne | MyPass | 800 | 成功预定 |
2 | 场景2 | 一个超出期限的日期 | n/a | n/a | n/a | n/a | 日期超限 |
3 | 场景3 | 一个有效日期 | 已满 | n/a | n/a | n/a | 无空余房间 |
4 | 场景4 | 一个有效日期 | 未满 | UserTwo | n/a | n/a | 账号错误 |
5 | 场景5 | 一个有效日期 | 未满 | UserTwo | NoPass | n/a | 密码错误 |
6 | 场景6 | 一个有效日期 | 未满 | UserTwo | MyPass | 200 | 余额不足 |
原文:https://www.cnblogs.com/yzy1314/p/11684315.html