分析软件应用的场景，从用户的角度出发，从场景的角度来设计测试用例，是一种面向用户的测试用例设计方法。

关心用户做什么，而不是关心产品做什么

优点：实用性强，有效，设计出来的用例有价值

缺点：可能使用的场景不一定能对事件系列进行全面的分析，设计出来的用例不完整。

场景分析是通过描述流经用例路径来确定的过程，这个流经过程要从用例开始到结束遍历其中所有基本流 ：直黑线表示基本流，是最基本、最简单的路径；（软件功能按照正确的事件流实现的一条正确流程无任何错，程序从开始直到结束）

遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：

注：为方便起见，场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。

1.根据说明，画出流程图，确定基本流和备选流；

2.根据基本流和各项备选流确定场景；

3.对每一个场景生成测试用例；

4.对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值。

用户登录到网站后，进行书籍的选择，当选好自己心仪的书籍后进行订购，这时把所需图书放进购物车，等进行结帐的时候，用户需要登录自己注册的帐号，登录成功后，进行付款交易，交易成功后，生成订购单，整个购物过程结束。

第一步：画出流程图，确定基本流和备选流；

基本流：登录在线网站→选择书籍→放入购物车→登录账号→付款→生成订单

备选流１：用户不存在→注册用户

备选流２：密码不正确

备选流３：账户余额不足→充值

第二步：根据基本流和各项备选流确定场景；

场景１（成功购物）：基本流；

场景２（账户不存在）：基本流 备选流１

场景３（账户密码错误）：基本流 备选流２

场景４（账户余额不足）：基本流 备选流3

第三步：对每一个场景生成测试用例；

第四步：对生成的所有测试用例重新复审，补充测试数据值；

以从这个用例生成下列场景

表1-3 提款场景

 注：为方便起见，备选流 3 和 6（场景 3 和 7）内的循环以及循环组合未纳入上表。

对于这 7 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表 测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例 ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵 中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。

表1-4 用例矩阵

在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例 CW1 称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本 流。这些负面测试用例由 CW2 至 6 表示（阴影单元格表明这种条件下需要执行备选流）。虽然 CW2 至 6 对于基本流而言都是负面测试用例，但它们相对于备选流 2 至 4 而言是正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例（CW1 - 基本流）。

每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景 4 正是这样的一个示例。要全面地测试场景 4 - PIN 有误，至少需要三个正面测试用例（以激活场景 4）：

输入了错误的 PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤 3 - 输入 PIN。

输入了错误的 PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。

最后一次输入时输入了“正确”的 PIN。备选流在步骤 5 - 输入金额处重新加入基本流。

注：在上面的矩阵中，无需为条件（数据）输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看 V 和 I（或此处采用的阴影单元格），这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例还不完 全，如场景 6 - 不存在的帐户/帐户类型有误和场景 7 - 帐户余额不足就缺少测试用例。

一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。

测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据。

表1-5 实际用例

以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括：

场景 6 - 帐户不存在/帐户类型有误：未找到帐户或帐户不可用

场景 6 - 帐户不存在/帐户类型有误：禁止从该帐户中提款

场景 7 - 帐户余额不足：请求的金额超出帐面金额

在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：

无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）.

无法读卡（读卡机堵塞、脱机或出现故障）.

帐户已消户、冻结或由于其他方面原因而无法使用.

ATM 内的现金不足或不能提供所请求的金额（与 CW3 不同，在 CW3 中只是一种币值不足，而不是所有币值都不足）.

无法联系银行系统以获得认可.

银行网络离线或交易过程中断电.