-
1 电子教材
-
2 PPT
-
3 实训任务
1. 建立用例模型
如图 9-2 所示，对于一个ATM 系统来说，它有 3 个参与者（ Actor ) ，即客户、 ATM 操作员和银行系统。其中，客户可以执行“提款”、“转账”和“存款”的操作： ATM 操作员可以执行“启动系统”的操作．因此，用例模型包括 4 个用例：提款、转账、存款和系统启动。此外， ATM 与银行系统通信，完成相应的功能。
图 9-2 ATM流程示意图
2. 用例场景分析
建立了用例模型之后，需要对每个用例进行场景分析，发现所包含的基本流和备选流。表9-2包含了图9-2中提款用例的基本流和某些备用流。
表9-2 提款用例的基本流和某些备用流
基本流/备选流 | 场景 |
基本流 | 本用例的开始是ATM处于准备就绪状态 1. 准备提款——客户将银行卡插入ATM机的读卡机 2. 验证银行卡一一ATM机从银行卡的磁条中读取账户代码，并检查它是否属于可以接受的银行卡 3. 输入PIN——ATM要求客户输入PIN码（4 位） 4. 验证账户代码和PIN——般账户代码和PIN，以确定该账户是否有效以及所输入的PIN该账户来说是否正确。对于此事件流，帐户是有效的，而且PIN对此账户来说正确无误 5. ATM选项——ATM显示在本机上可用的各种选项。在此事件流中，银行客户通常选择“提款” 6. 输入金额一一要从ATM中提取的金额。对于此事件流，客户需选择预设的金额（ 10 元、 2O 元、50元或 100 元） 7. 授权——ATM通过将卡 ID、 PIN、金额以及账户信息作为一笔交易发送给银行系统来启动验证过程。对于此事件流，银行系统处于联机状态，而且对授权请求给予答复，批准完成提款过程，并且据此更新帐户余额 8. 出钞——提供现金 9. 返回银行卡——银行卡被返还 10. 收据——打印收据给客户。 ATM还相应地更新内部记录 用例结束时ATM又回到准备就绪状态 |
备选流1——银行卡无效 | 在基本流步骤2中，验证银行卡，如果卡是无效的，则卡被退回，同时会显示相关消息通知客户。 |
备选流2——ATM内没有现金 | 在基本流步骤5中，如果ATM内没有现金．则“提款”选项将无法使用。 |
备选流3——ATM内现金不足 | 在基本流步骤6中，如果ATM 机内金额少于请求提取的金额，则将显示一条适当的消息，并且在步骤6输入金额处重新加入基本流。 |
备选流 4——PIN 有误 | 在基本流步骤4中，客户有3次机会输入PIN 。如果 PIN输入有误， ATM 将显示适当的消息；如果还存在输入机会，则此事件流在基本流步骤3输入PIN处重新加入基本流。如果最后一次尝试输入的PIN码仍然错误，则该卡将被ATM机保留，同时ATM返回到准备就绪状态，本用例终止。 |
备选流 5 - 帐户不存在 | 在基本流步骤4，如果银行系统返回的代码表明找不到该帐户或禁止从该账户中提款，则ATM显示适当的消息并且在步骤9返回银行卡处重新加入基本流。 |
备选流 6——账面金额不足 | 在基本流步骤7，银行系统返回代码表明帐户余额少于在基本流步骤6输入金额内输入的金额，则ATM显示适当的消息并在步骤6输入金额处重新加入基本流。 |
备选流 7——达到每日最大的提取金额 | 在基本流步骤7，银行系统返回的代码表明包括本提款请求在内，客户已经或将超过在24小时内允许提取的最多金额．则ATM显示适当的消息并在步骤6输入金额处重新加入基本流。 |
备选流x——记录错误 | 在基本流步骤10，如果记录无法更新，则ATM进入“安全模式”，在此模式下所有功能都将暂停使用。同时向银行系统发送一条适当的警报信息表明ATM已经“暂停工作”。 |
备选流y——退出 | 客户可随时决定终止交易（退出）。交易终止，银行卡随之退出。 |
备选流z——“翘起” | ATM包含大量的传感器，用以监控各种功能，如电源检测器、不同的门和出入口处的测压器以及动作检测器等。在任一时刻，如果某个传感器被激活，则警报信号将发送给警方而且ATM进入“安全模式”，在此模式下所有功能都暂停使用，直到采取适当的重启/重新初始化的措施。 |
在第一次迭代中，根据迭代计划，需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了下面的事件流。
1）基本流 ― 提取预设金额（ 10 元、 20 元、 50 元、 100 元）。
2）备选流 2 - ATM 内没有现金。
3）备选流 3 - ATM 内现金不足。
4）备选流 4 - PIN 有误。
5）备选流 5 ― 账户不存在，账户类型有误。
6）备选流 6 ― 账面金额不足。
从以上所描述的提款用例的基本流和备选流，可以生成用例的场景，如表9-3所示。
表 9-3 提款用例的场景
用例场景 | 基本流/备选流 | |
场景1——成功的提款 | 基本流 | |
场景2——ATM内没有现金 | 基本流 | 备选流2 |
场景3——ATM内现金不足 | 基本流 | 备选流3 |
场景4——PIN有误（还有输入机会） | 基本流 | 备选流4 |
场景5——PIN有误（不再有输入机会） | 基本流 | 备选流4 |
场景6——账户不存在/账户类型错误 | 基本流 | 备选流5 |
场景7——账户余额不足 | 基本流 | 备选流5 |
注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入表中。
3. 提款用例的测试用例设计
首先确定执行用例场景所需的数据元素，然后构建测试用例矩阵，针对每一个场景，确定包含执行场景所需的适当条件的测试用例，如表9-4所示。在该矩阵中，V（有效）表示这个条件必须是有效的，才可执行基本流；I（无效）表示在这种条件下将激活所需备选流；n/a（不适合）表示这个条件不适用于测试用例。
表9-4 提款用例的测试用例矩阵
测试用例ID | 场景/条件 | PIN | 帐号 | 输入金额 | 账面金额 | ATM内的金额 | 预期结果 |
CW1 | 场景1——成功的提款 | V | V | V | V | V | 成功的提款 |
CW2 | 场景2——ATM内没有现金 | V | V | V | V | I | 提款选项不能使用，用例结束 |
CW3 | 场景3——ATM内现金不足 | V | V | V | V | I | 警告信息：返回基本流步骤6——输入金额 |
CW4 | 场景4——PIN有误（还有不止一次输入机会） | I | V | n/a | V | V | 警告信息：返回基本流步骤4——输入PIN |
CW5 | 场景4——PIN有误（还有一次输入机会） | I | V | n/a | V | V | 警告信息：卡被保留，用例结束 |
CW6 | 场景5——PIN有误（不再有输入机会） | I | V | n/a | V | V |
在上面的矩阵中，6个测试用例执行了4个场景。对于基本流，上述测试用例 CW1称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。这些负面测试用例由 CW2~CW6 表示。虽然 CW2~ CW6 相对于基本流而言都是负面测试用例，但它们相对于备选流2~备选流4而言是正面测试用例。而且对这些备选流中的每一个而言，至少存在一个负面测试用例，就是 CW1（基本流）。
每个场景只有一个正面测试用例和负面测试用例是不充分的，场景4正是这样的一个示例。要全面地测试场景4（PIN 有误），至少需要3个正面测试用例，以激活场景4。
1）输入了错误的 PIN ，但仍存在输入机会，此备选流重新加入基本流中的步骤3（输入 PIN ）。
2）输入了错误的 PIN ，而且不再有输入机会，则此备选流将保留银行卡并终止用例。
3）最后一次输入时输入了“正确”的PIN ，备选流在步骤5（输入金额）处重新加入基本流。
注意，在上面的矩阵中，无需为条件输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看V和I，这种方式还易于判断是否已经确定了充足的测试用例。在表9-3中可以看到测试用例还不完全，如场景6（不存在的账户／账户类型有误）和场景7（账户余额不足）就缺少测试用例。
4. 确定测试数据
一旦确定了所有的测试用例，还应该对这些测试用例进行评审和验证，以确保其准确和适度，并取消多余或等效的测试用例。测试用例一经认可，就可以确定实际数据值（在测试用例矩阵中）并且设定测试数据，参看表 9-5 。
表9-5 带测试数据的测试用例矩阵
测试用例ID | 场景/条件 | PIN | 帐号 | 输入金额 | 账面金额 | ATM内的金额 | 预期结果 |
CW1 | 场景1——成功的提款 | 4987 | 809-498 | 50：00 | 500：00 | 2000：00 | 成功的提款 |
CW2 | 场景2——ATM内没有现金 | 4987 | 809-498 | 100：00 | 500：00 | 0：00 | 提款选项不能使用，用例结束 |
CW3 | 场景3——ATM内现金不足 | 4987 | 809-498 | 100：00 | 500：00 | 70：00 | 警告信息：返回基本流步骤6——输入金额 |
CW4 | 场景4——PIN有误（还有不止一次输入机会） | 4978 | 809-498 | n/a | 500：00 | 2000：00 | 警告信息：返回基本流步骤4——输入PIN |
CW5 | 场景4——PIN有误（还有一次输入机会） | 4978 | 809-498 | n/a | 500：00 | 2000：00 | 警告信息：卡被保留，用例结束 |
CW6 | 场景5——PIN有误（不再有输入机会） | 4978 | 809-498 | n/a | 500：00 | 2000：00 |
以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括以下内容。
1）场景 6 一账户不存在／账户类型有误，未找到账户或账户不可用。
2）场景 6 ― 帐户不存在／账户类型有误，禁止从该账户中提款。
3）场景 7 一账户余额不足，请求的金额超出账面金额。
在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：
1）无效卡（所持卡为挂失卡、被盗卡、非承兑银行卡、磁条损坏等）。
2）无法读卡（读卡机堵塞、脱机或出现故障）。
3）账户已销户、冻结或由于其他原因而无法使用。
4) ATM 内的现金不足或不能提供所请求的金额（与 CW3 不同，在 CW3 中只是一种币值不足，而不是所有币值都不足）。
5）无法联系银行系统以获得认可。
6）银行网络离线或交易过程中断电。
总之，所有从事软件测试和即将从事软件测试的人大都是从黑盒测试做起的，每种类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是非常重要的，它能极大地提高测试效率和测试覆盖度，认真掌握这些方法的原理，有效提高测试水平，积累更多的测试经验，这是测试人员最宝贵的财富。
场景设计法需要测试人员充分发挥对用户实际业务场景的想象。例如，图9-3所示为单据审批流程。
可以想象用户在实际工作中会发生的审批过程，至少能考虑到下面几个需要进行测试的要点。
（1）用户编辑申请单，然后必须先确认申请单的有效性，确认动作是编辑者本人，确认的目的是让系统帮助编辑者校验申请数据的正确性、是否满足逻辑约束，避免生成一份无效的申请单。
图 9-3 某单据审批流程图
对于这个场景，测试人员需要考虑验证一份正确输入数据的申请单，系统可以正确地通过确认。还需要考虑验证一份错误输入数据的申请单，系统会检查出相应的错误，并提示用户。因此可以设计出正反两个场景的测试用例。
（2）对于一份通过确认的申请单，如果用户此时发现误录了一些数据，应该可以取消确认。因为此时单据尚未提交审批，应该给用户纠正错误的余地。因此，测试人员需要设计一个测试用例，执行确认动作后，再立即执行取消确认动作。看系统是否允许重新编辑申请单。
（3）申请单审批通过则系统自动生成申请报告，否则退回给申请人重新编辑。对于这样一个过程，测试人员首先需要设计一个测试用例来验证审批通过后，系统是否正确地生成了相应的申请报告。其次，确认审批不通过，申请单的状态是否会变成退回状态，在申请单编辑人的界面是否能看到被退回的申请单据，并且状态表明审批不通过，被退回。
在线购物的实例：用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用帐号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。
第一步，我们来确定基本流和备选流：
第二步，我们根据基本流和备选流来确定场景：
第三步，我们来设计用例。
对于每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。
下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。
本例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。
通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。
第四步，我们来设计数据，把数据填入上面的用例表中。
以上写到的测试用例只是购物的一部分测试用例。
场景法是通过构成基本流和备选流，生成场景进而得到测试用例的测试方法。该法主要用于功能测试。
场景法的主要难点在于如何根据业务实际提炼出基本流，以及如何将备选流的数量控制在一定范围内。设计测试用例时应注意一个场景可能需要设计多个测试用例。场景法测试仅针对输入域展开分析，不适于从输出域来展开测试。
