本期，我们通过经典案例——ATM机的操作，来为大家详细说说如何撰写对应的测试用例。
【案例】
在我们日常生活中，ATM机是个大家都非常熟悉的事物。银行为了提高工作效率，方便客户随时办理基础的储蓄和提现业务，于是，ATM机就诞生了。我们都知道，所谓用户取款业务，就是指为用户提供插卡、校验和取款操作的全过程。那么，围绕用户取款业务，我们应该如何为之设计测试步骤呢？
【解析】
在这一场景下，我们首先需要做的，就是构造基本流和备选流。详情如下：
1）基本流
对于ATM机来说，它的基本流的初始状态是：荧幕出现欢迎页面，表示系统已经准备就绪，可以开始自主操作。接下来，它的业务处理流程基本如下：
① 插卡：用户将银行卡插入ATM机的卡槽；
② 卡校验：系统读取被插卡的账户代码，判断该卡是否为本系统可接受的卡。
▷▷在基本流中，插卡校验顺利通过后，即表示这是一张系统可以识别接受的ATM卡。因此，此处对应第1个校验点。
③ 密码输入：系统自动读取卡的账户，获取其预设密码，并要求用户输入6位数字取款密码。
④ 密码校验：系统根据卡账户的预设密码，并与用户输入的密码比较，判断二者是否一致。
▷▷对基本流而言，输入的密码正确，表示可接受该银行卡接受后续操作。所以，此处对应第2个校验点。
⑤ 取款交易选择：基于我们是针对用户取款业务做的场景测试，因此，我们将在这一测试处，简化操作流程。默认我们直接选择取款交易，且该银行卡处于活期账户状态。在此处，我们暂时忽略系统还支持存款、查询余额、修改密码等其他操作，并忽略银行卡可能属于定期、冻结账户等状态；
⑥ 取款金额设置：系统要求用户输入要取款的金额数。注意，取款的金额应为50的整数倍，且应受到数目上的各种限制；
⑦ 取款校验：系统将账户、密码、交易类型（本例为“取款”交易）及金额数作为一笔交易发送给银行系统，启动校验过程。
▷▷对于基本流而言，系统处于联机状态，对用户的授权请求予以答复，且批准完成取款，并更新账户余额。此处对应第3个校验点。
⑧ 出钞：系统从现金槽中提供现金钞票。
⑨ 凭条打印选择：一般在处理完成一次事务后，系统会再次提示选择交易类型，为了简化流程，本案例中我们暂且忽略这个步骤。而是认为完成交易后，直接提示是否进入后续交易凭条打印环节。
▷▷对于基本流而言，用户选择打印交易凭条。此处对应第4个校验点。
⑩ 提供交易凭条：系统从ATM机的小票卡槽中提供交易凭条，并更新ATM机内部记录。
⑪ 退卡：系统返还用户的ATM卡。
▷▷用例至此结束，这时ATM机再次回到准备就绪状态。
2）备选流
基本流中得到4个关键校验点如下：
校验点1：对应步骤②，对卡的有效性进行校验，判断卡是否有效；
校验点2：对应步骤④，对用户输入的密码进行校验，判断输入的密码是否匹配预设密码；
校验点3：对应步骤⑦，对输入的取款金额进行校验，判断取款金额设置是否有效；
校验点4：对应步骤⑨，对凭条打印进行选择，判断是否需要打印交易凭条。
根据上述4个校验点，我们可以分别得到各个校验点的备选流。对此，我们可以做出如下的分析判断：
① 备选流1：卡错误
在基本流步骤②处触发，在校验ATM卡时，发现该卡无效，则应提示无效卡并将卡退回。退回后，系统回到准备就绪状态，本用例终止。
② 备选流2：密码错误
在基本流步骤④处触发，校验密码时有3次输入密码的机会，当第一次或第二次密码输入错误后，仍有继续输入密码的机会，则系统提示密码错误，要求用户再次输入密码，系统返回密码输入状态，在步骤③处重新加入基本流。
③ 备选流3：密码失败
该备选流仍在基本流步骤④处触发，校验密码时，当密码第3次输入错误后不再有输入机会，此时系统提示密码失败，并直接吞掉用户的ATM卡，并提示用户到银行柜台办理相关取卡事宜，系统返回准备就绪状态，本用例终止。
▷▷值得我们注意的是，备选流2、3是由相同事件触发的（密码输入错误），区别只是在于触发次数问题。多次触发后，将导致系统产生不同的处理结果。这与程序执行中的循环结构，其实是非常类似的。
④ 备选流4：输入金额错误
在基本流步骤⑦处触发，校验用户输入的取款金额时失败，禁止取款，要求用户重新输入取款金额，系统返回金额输入状态，在步骤⑥处重新加入基本流。
▷▷这里需要注意的是，取款金额错误可分多种情况。包括：取款账户的余额不足；金额格式错误；ATM机现金不足；达到账户单次取款的最大金额等等。但是，机智的小伙伴可能发现了，我们比昂没有针对所有可能出现的错误情况，分别构建不同的备选流，这是为什么呢？感兴趣的小伙伴，可以在留言区告诉小编你的答案。
⑤ 备选流5：不打印凭条
在基本流步骤⑨处触发，选择是否打印交易凭条时选择不打印，则直接退还用户的ATM卡。
小结：我们通过上述所有的基本流与备选流，可以得出一张清晰的画像，如下图：
值得一提的是，在卡密码校验处，一旦用户3次输入密码错误，系统将会把用户的卡没收。之后，ATM机仍会回到系统欢迎画面。这似乎应从基本流的退出状态来结束？但事实上，由于此处包含了一个吞卡的动作，因此，与备选流1和备选流5的执行结果不完全一致。所以，备选流3的执行结果是不同于备选流1和备选流5的。
【场景设计】
根据取款业务的基本流和5个备选流得到的场景集合如下：
场景1（取款成功，且打印凭条）：基本流；
场景2（卡错误）：基本流 备选流1；
场景3（密码错误）：基本流 备选流2；
场景4（密码失败）：基本流 备选流3；
场景5（取款金额错误）：基本流 备选流4；
场景6（取款成功，不打印凭条）：基本流 备选流5。
【测试用例设计】
虽然每个场景对应系统业务流程（从开始到结束状态）的一系列执行过程，但实质上，它仍然是对应测试用例的一组输入和预期输出。因此，对应每个场景可设计一个或多个测试用例。比如：
（1）根据某场景所包含的执行流程，分析出系统应满足的所有输入条件和预期输出；
（2）当场景中包含备选流时，应确定触发该备选流执行的输入条件，并予以标记。
由此，我们可以得出如下结论：
（“V”表示该条件必须有效才可以执行该用例；“I”表示其是触发对应某个备选流的条件；“N/A”表示此测试用例中不需要设置该输入条件。）
为了保证覆盖准确率，我们可以通过以下途径来判断：
（1）应用独立路径测试的策略，每条独立路径对应一个场景；
（2）检查测试用例表，查看是否所有输入都取到“I”的情况，即曾经作为测试用例的触发条件，只要存在某条件从未取到“I”，就证明测试用例存在漏洞，未覆盖所有的场景。
另外，我们还应注意测试数据的设计。对于测试用例来说，我们可以继续根据边界值、等价划分等方法，为它们一一设计具体的测试数据。举个例子，假设正确密码是8个8，那么，我们会得到如下测试结果：
写在最后
通过上述内容，相信大家对场景测试的内容有了一定的了解，希望大家在实际工作中，也能按照上述方法一步一步去做，通过多次实践，对场景测试有更加深刻的认识。祝大家在测试的道路上越走越顺畅~
,
