场景法主要用于测试软件的业务过程或业务逻辑，是一种基于软件业务和用户行为的测试方法。
1.概念：前几篇讨论的测试方法侧重于数据的选择，不涉及操作步骤，无法对涉及用户操作的动态执行过程进行覆盖测试。当在系统功能层面上进行测试时，不仅设计测试数据的问题，更侧重要的是如何从系统整个业务流程的全部角度对系统进行测试。场景法运用场景对系统的功能点或业务流程进行描述，然后设计测试用例，从而提高了对系统主要功能和业务流程的测试效果。场景法适合测试业务流程清晰的系统或功能。
2.基本流和备选流
基本流：采用黑直线表示，是经过用例测试的最简单路径，即无任何差错，程序从开始直接执行到结束的流程，往往是大多是用户最常使用的操作过程，体现了软件的主要功能与流程。同城，一项业务金存在一个基本流，并且基本流仅有一个起点和一个终点
备选流：除基本流之外的各个支流。备选流可能从基本流开始，在某个特定的条件下执行，然后从新加入到基本流中(如备选流1，3)；也可以起源于另一个备选流(如备选流2)；还可以终止用例而不再加入到基本流中(如备选流2，4)，反映了各种异常和错误情况。。
考虑用例从开始到结束所有可能的基本流和备选流的组合，可以确定不同的用例场景。例如，根据上图，可以确定以下用例场景。
场景1：基本流
场景2：基本流→备选流1
场景3：基本流→备选流1→备选流2
场景4：基本流→备选流3
场景5：基本流→备选流3→备选流1
场景6：基本流→备选流3→备选流1→备选流2
场景7：基本流→备选流4
场景8：基本流→备选流3→备选流4
基本流和备选流的区别：
基本流
备选流
测试重要性
重要
次要
数量
一个
一个或多个
初始节点位置
系统初始状态
基本流或其他备选流
终止结点位置
系统终止状态
基本流或系统终止状态
是否构成完整的业务流程
是
否，仅为业务流程的执行片段
能否构成场景
能
否，需要基本流共同构成场景
3.场景法步骤及实例
根据场景法设计测试用例的步骤如下：
(1)根据说明，描述出程序的基本流及各个备选流；
(2)根据基本流和各个备选流生成不同的场景
(3)对每一个场景生成相应测试用例
(4)对生成的所有测试用例重新审查，去掉多余的测试用例。测试用例确定后，对每一个测试用例确定测试数据值
实例：某旅馆住宿系统支持网上预定业务。游客访问网站进行房间预定操作，选择预定日期、合适的房间后，进行在线预定。此时需要使用个人账号登陆系统，待登录成功后，进行定金支付。订金支付成功后，生成房间预订单，完成整个房间的预定流程。系统允许的预定期限为30舔，订金为400元。
(1)确定基本流和备选流
类型
描述
类型
描述
基本流
选择预定日期
备选流1
预定日期超限
选择房间
备选流2
无空余房间
登陆账户
备选流3
账户不存在
订金支付
备选流4
密码错误
产生预定订单
备选流5
用户账户余额不足
(2)根据基本流和备选流生成不同场景
场景1(成功预定房间)：基本流
场景2(预定日期超限)：基本流、备选流1
场景3(无空余房间)：基本流、备选流2
场景4(账号不存在)：基本流、备选流3
场景5(密码错误)：基本流、备选流4
场景6(用户账号余额不足)：基本流、备选流5
(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
余额不足
原文：/yzy1314/p/11684315.html
