通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果。
场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。
为什么场景法能如此清晰的描述整个事件？因为，现在的系统基本上都是由事件来触发控制流程的。
在面向对象的软件开发中，事件触发机制是编程中经常遇到的
（一）场景原理
现在的软件几乎都是用事件触发来控制流程的。像GUI软件、游戏等。事件触发时的情景形成了场景，而同一事件不同的触发顺序和处理结果就形成了事件流。这种在软件设计方面的思想可以引入到软件测试中，可以生动地描绘出事件触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。
在测试一个软件的时候，在场景法中，测试流程是软件功能按照正确的事件流实现的一条正确流程，那么我们把这个称为该软件的基本流；而凡是出现故障或缺陷的过程，就用备选流加以标注，这样的话，备选流就可以是从基本流来的，或是由备选流中引出的。所以在进行图示的时候，就会发现每个事件流的颜色是不同的。
基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流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
下面是场景法的基本设计步骤:
· 根据说明，描述出程序的基本流及各项备选流
· 根据基本流和各项备选流生成不同的场景
· 对每一个场景生成相应的测试用例
· 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值
（二）场景法例子
1、在线购物系统
我们都在当当网或china-pub华章网上书店都订购过书籍，整个订购过程为：用户登录到网站后，进行书籍的选择，当选好自己心仪的书籍后进行订购，这时把所需图书放进购物车，等进行结帐的时候，用户需要登录自己注册的帐号，登录成功后，进行结帐并生成订单，整个购物过程结束。
那么我们通过以上的描述，从中确定哪是基本流，哪些是备选流：
| 基本流 |
用户登录到网站，书籍的选择，进行订购，把所需图书放进购物车，等进行结帐的时候，登录自己的帐号，登录成功后，生成订单 |
| 备选流1 |
帐号不存在 |
| 备选流2 |
帐号错误 |
| 备选流3 |
密码错误 |
| 备选流4 |
无选购书籍 |
| 备选流x |
退出系统 |
根据基本流和备选流来确定场景：
| 场景1-购物成功 |
基本流 |
|
| 场景2-帐号不存在 |
基本流 |
备选流1 |
| 场景3-帐号错误 |
基本流 |
备选流2 |
| 场景4-密码错误 |
基本流 |
备选流3 |
| 场景5-无选购书籍 |
基本流 |
备选流4 |
我们来设计用例
对于每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。
下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。
本例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。
通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。
| 测试用例ID |
场景/条件 |
帐号 |
密码 |
选购书籍 |
预期结果 |
| 1 |
场景1：购物成功 |
V |
V |
V |
成功购物 |
| 2 |
场景2：帐号不存在 |
I |
n/a |
n/a |
提示帐号不存在 |
| 3 |
场景3：帐号错误 |
I |
V |
n/a |
提示帐号错误，返回基本流步骤2 |
| 4 |
场景4：密码错误 |
V |
I |
n/a |
提示密码错误，返回基本流步骤3 |
| 5 |
场景5：无选购书籍 |
V |
V |
I |
提示选购书籍，返回基本流步骤5 |
我们看到以上表中，是把每个场景成立的条件进行了分析，基本上已经明确了测试用例的数量，现在只要把真实数据填充上，那么整个测试用例就完成了。
| 测试用例ID |
场景/条件 |
帐号 |
密码 |
选购书籍 |
预期结果 |
| 1 |
场景1：购物成功 |
xu |
123456 |
《书》 |
成功购物 |
| 2 |
场景2：帐号不存在 |
zhang |
n/a |
n/a |
提示帐号不存在 |
| 3 |
场景3：帐号错误 |
zhou |
123456 |
n/a |
提示帐号错误，返回基本流步骤2 |
| 4 |
场景4：密码错误 |
xu |
123$%^ |
n/a |
提示密码错误，返回基本流步骤3 |
| 5 |
场景5：无选购书籍 |
xu |
123456 |
空 |
提示选购书籍，返回基本流步骤5 |