记录关键测试步骤和结果
准备好了用例,我们就可以开始编写测试脚本。基于准确的测试用例描述和灵活的 IBM 框架支持,我们可以轻松的把测试步骤翻译成测试脚本。同样以脚本例 1B 为例,我们可以可以得到例 2 中的脚本代码:
例 2. 初步的测试脚本
这是一个新手容易写出的测试脚本,这个脚本遵循 IBM 框架设计,完成了用例要求的步骤,并加入了对测试结果的验证。看起来符合测试用例的要求,不过,这个脚本还不够好。
我们说“自动化测试”=“自动化”+“测试”,作为程序执行正确性的验证工具,我们需要假设执行流程中的每一步都是可能出现错误的。比如说步骤一的点击菜单动作,就可能因为程序内的菜单映射错误而打开错误的对话框;再比如在步骤三中,可能因为网络超时或程序错误判断自身为离线状态而无法成功连接到服务器。还是以为回到测试结果的分析这一问题上来,一旦产品有了缺陷或者测试执行出错,我们如何快速定位问题么?很显然,测试人员不可能一直盯着测试脚本的执行,在自动化测试中,我们需要通过日志记录下关键步骤的执行过程和结果。
在通过日志分析结果时,通常我们需要知道两点:
1、步骤是否已执行;
2、被测程序是否正确做出反应。
对于第一点,通过在 App Object 层和 Task 层的增强,Notes 自动测试的框架能够自动输出信息,显示出执行了的步骤,这个功能本文后面会做深入介绍。而被测程序是否正确做出反应,则需要我们在测试脚本中进行检测并记录。实际上,当我们手工验证测试用例时,我们都会不经意的验证每一步的程序响应,并决定下一步的操作。作为“隐藏的验证点”,我们需要把他们补充到测试用例中。例 3 中给出了经过完善后的测试用例:
例 3. 完善后的测试用例
相应的,我们在测试脚本的编写过程中也需要加入对各个步骤中程序响应的验证,并将结果记录到日志中。例 4 中给出了我们最终的示例测试脚本:
例 4. 完善后的测试脚本
Logger.logDetail(“1. 点击 File-> Open Application 菜单”); Menu.mOpenApplication.pick(); OpenAppDlg dlgOpenApp = new OpenAppDlg(); Logger.logCompareFatal(true, dlgOpenApp.exist(LocalSettings.shortWaitTime), "验证:‘打开应用’对话框出现");Logger.logDetail("2. 在 Server Combox 中输入服务器地址"); dlgOpenApp.getServerCombo().setText(User.mailServer); Logger.logCompareFatal(User.mailServer, dlgOpenApp.getServerCombo().getText(), "验证:服务器地址输入正确");Logger.logDetail("3. 切换到 Server"); dlgOpenApp.getOpenButton().click(); Logger.logCompareFatal(true, isContentOnServer(dlgOpenApp, User.mailServer), "验证:列表框中显示的内容为服务器上的内容"); Logger.logDetail("4. 在 File Name Editbox 中输入邮箱路径名称"); dlgOpenApp.getFileEdit().setText(User.mailPath); Logger.logCompareFatal(User.mailPath, dlgOpenApp.getFileEdit().getText(), "验证:邮件路径输入正确"); Logger.logDetail("5. 点击确定,打开应用"); dlgOpenApp.getOpenButton().click(); Logger.logCompareFatal(true, dlgOpenApp.waitForNonExistence(LocalSettings.shortWaitTime), "验证:‘打开应用’对话框关闭"); Logger.logCompare(User.name, MailTask.getOpenedMailOwner(), "验证:邮件应用正确打开"); |