6、场景法

为什么使用场景法

现在的系统基本上都是由事件来触发控制流程的。如：我们申请一个项目，需先提交审批单据，再由部门经理审批，审核通过后由总经理来最终审批，如果部门经理审核不通过，就直接退回。每个事件触发时的情景便形成了场景。而同一事件不同的触发顺序和处理结果形成事件流。终端用户，期望软件能够实现业务需求，而不是简单的功能的组合。对于单点功能来说，利用等价类划分、边界值分析、判定表等用例设计方法就能够解决大部分问题。而涉及业务流程的软件系统，采用场景法比较合适。

业务流组成、场景组合、覆盖原则及识别原则

场景业务流组成：基本流 + 备选流

 

图中经过用例的每条路径都用基本流和备选流来表示，绿色主线表示基本流，是经过用例的最简单的路径，即无任何差错，程序从开始直接执行到结束的流程。通常，一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。

备选流表示通过业务流程时输入错误（或者操作错误）导致流程存在反复，但是经过纠正后仍能达到目标的流程。备选流为除了基本流之外的各支流，包含多种不同情况，例如，一个备选流可始于基本流，于某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可始于另一备选流（如备选流2）；也可终止用例而不再加入到基本流中（如备选流2和4）。

（2）场景组合

按上图组合多个不同的场景：

• 场景1：基本流
• 场景2：基本流 备选流1
• 场景3：基本流 备选流1 备选流2
• 场景4：基本流 备选流3
• 场景5：基本流 备选流3 备选流1
• 场景6：基本流 备选流3 备选流1 备选流2
• 场景7：基本流 备选流4
• 场景8：基本流 备选流3 备选流4

备选流覆盖准则

• 覆盖每个备选流；
• 覆盖一个循环；
• 这两种方法可以看情况选择，到这一步基本的测试用例就出来了，每个场景对应一个测试用例，对每个用例进行评审，删掉重复的。

基本流和备选流的识别原则

• 基本流只有一个起点，一个终点；
• 基本流是主流，备选流是支流；
• 备选流可以始于基本流，也可以始于其它备选流；
• 备选流的终点，可以是一个流程的出口，也可以是回到基本流，还可以是汇入其它的备选流；
• 备选流汇合时，谁汇合到谁，取决于流量大小也即该流程出现的可能性大小，小的汇入大的；
• 如果在流程图中出现了两个不相上下的基本流，一般需要把它们分别当做一个业务看待。

场景法设计测试用例的步骤（How）

• 分析需求，确定业务流程（基本流、备选流）；
• 依据基本流、备选流，生成不同的场景；
• 针对生成的各场景，设计相应的测试用例。可以采用矩阵或者判定表来确定和管理测试用例。每个测试用例包含：ID、条件（或说明）、数据元素、预期结果。通过从确定执行用例场景所需的数据元素入手构建矩阵，矩阵中可用V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。使用的“n/a”（不适用）表明这个条件不适用于测试用例。一旦确定了所有的测试用例，则应对这些测试用例进行复审和验证以确保其准确且适度，并取消多余或者等效的测试用例。
• 测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定数据。

Note：场景法的核心就是“场景”二字，你所需要的就是要找出场景，场景找出来了，测试用例也就水到渠成。当你找到基本流和备选流之后，需要通过构造场景矩阵将场景表示出来。矩阵一旦生成，用例也就一目了然。说起来比较简单，但在使用的过程中会遇到不少的问题。在很多流程图中，有不少备选流其实是隐藏的。希望读者能深入理解两个流的概念，为什么会有这两个流，两个流的特点是什么，为什么要构造矩阵，矩阵的纵向和横向代表什么，V, I又代表什么。

实战演练

ATM机取款流程

Step1.流程图如下：

Step2.基本流如下：

本用例的开端是 ATM 处于准备就绪状态。

1. 准备提款 - 客户将银行卡插入 ATM 机的读卡机。
2. 验证银行卡 - ATM 机从银行卡的磁条中读取帐户代码，并检查它是否属于可以接收的银行卡。
3. 输入 PIN - ATM 要求客户输入 PIN 码（4 位）
4. 验证帐户代码和 PIN - 验证帐户代码和 PIN 以确定该帐户是否有效以及所输入的 PIN 对该帐户来说是否正确。对于此事件流，帐户是有效的而且 PIN 对此帐户来说正确无误。
5. ATM 选项 - ATM 显示在本机上可用的各种选项。在此事件流中，银行客户通常选择“提款”。
6. 输入金额 - 要从 ATM 中提取的金额。对于此事件流，客户需选择预设的金额（10 美元、20 美元、50 美元或 100 美元）。
7. 授权 - ATM 通过将卡 ID、PIN、金额以及帐户信息作为一笔交易发送给银行系统来启动验证过程。对于此事件流，银行系统处于联机状态，而且对授权请求给予答复，批准完成提款过程，并且据此更新帐户余额。
8. 出钞 - 提供现金。
9. 返回银行卡 - 银行卡被返还。
10. 收据 - 打印收据并提供给客户。ATM 还相应地更新内部记录。

用例结束时 ATM 又回到准备就绪状态。

Step3.备选流如下：

 Step4.生成的场景如下：

 

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

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

 Step5.测试用例矩阵如下：

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

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

• 输入了错误的 PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤 3 - 输入 PIN。
• 输入了错误的 PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。
• 最后一次输入时输入了“正确”的 PIN。备选流在步骤 5 - 输入金额处重新加入基本流。

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

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

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

 Step6.测试用例及测试数据如下：

 

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

• 场景 5 – 帐户不存在/帐户类型有误：未找到帐户或帐户不可用
• 场景 5 – 帐户不存在/帐户类型有误：禁止从该帐户中提款
• 场景 6 – 帐户余额不足：请求的金额超出帐面金额
• 在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：
• 无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）
• 无法读卡（读卡机堵塞、脱机或出现故障）
• 帐户已消户、冻结或由于其他方面原因而无法使用
• ATM 内的现金不足或不能提供所请求的金额（与 CW3 不同，在 CW3 中只是一种币值不足，而不是所有币值都不足）
• 无法联系银行系统以获得认可
• 银行网络离线或交易过程中断电

以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。当然在实际的取款过程中，还需要从功能，性能，安全等角度去完善测试用例！