实战 GUI 产品的自动化测试,第 3 部分:如何提高测试结果分析的效率-1
上一篇 / 下一篇 2012-07-24 09:13:43 / 个人分类:自动化测试
简介:
C ~'b(Q-a$ce`"p!~#l051Testing软件测试网 }ZQCt/o5Yx自动化测试技术是保证产品质量的重要手段。随着敏捷开 发方法的盛行和产品发布周期的缩短,产品对测试的要求也相应提高,因此自动化测试也变得比以前更加重要。冰冻三尺非一日之寒,和产品开发一样,产品的自动 化测试系统也需要通过迭代开发不断强化,逐步解决效率瓶颈,更广泛、更灵活的支持产品开发的需求。那么,如何从无到有建立 GUI 产品的自动化测试系统?GUI 产品自动化测试每一阶段的目标是什么?在逐步演化的过程中,我们可能会面对哪些问题?这些又可以如何解决呢?本系列文章希望能够结合我们团队的经验,一一解答。
*tU*h m[t5DU0U$|*S?S0 测试结果的分析对于测试来说非常重要,往往需要收集大量的数据,包括屏幕截图和产品日志,并根据具体需要分析各种不同的信息,例如验证点,测试实际步骤和自动测试调试信息等等。可以通过精心准备测试用例、合理输出验证信息、筛选显示测试结果、自动记录测试实际步骤等手段来全面提高分析测试结果的效率。本篇文章从准备测试用例开始,介绍了验证信息的输出,Notes 自动测试日志的各种功能,并对每项功能的实现原理做深入介绍。
{Rk%q7zt.Z)o:Q-z051Testing软件测试网7Gf*UB Dh6U所谓自动化测试,就是“自动化”+“测试”。自动化本身显然不是自动化测试的全部,在我们解决了测试脚本自动执行的问题之后,还是要回到测试本身,解决 如何进行分析验证的问题。测试结果的分析对于测试来说非常重要,往往需要收集大量的数据,包括屏幕截图和产品日志,并根据具体需要分析各种不同的信息,例 如验证点,测试实际步骤和自动测试调试信息等等。可以通过精心准备测试用例、合理输出验证信息、筛选显示测试结果、自动记录测试实际步骤等手段来全面提高 分析测试结果的效率。本篇文章从准备测试用例开始,介绍了验证信息的输出,Notes 自动测试日志的各种功能,并对每项功能的实现原理做深入介绍。51Testing软件测试网)^(dkef2uO
51Testing软件测试网2SVY[Eo1Axt2l准备准确的测试用例
0C zq/s;{oL'F0\|AOo![;|5_u0 测试用例是测试脚本的基础,不合理的测试脚本既不利于自动化,也不利于测试。而好的测试脚本则要做到描述简洁准确,操作步骤清晰,测试目的明确易懂。由 于在编写测试用例时,产品一般没有完成,测试人员可能并不清楚执行用例的每个步骤,所以用例容易写得很模糊。手工测试人员执行时也许没有太多困扰,因为他 了解设计文档,知道应该执行什么样的步骤,但是自动测试人员并没有这么清楚,依照模糊的用例编写测试脚本往往无从下手。所以,在开始编写测试用例之前,往 往需要跟测试人员沟通,完善并得到准确的测试用例,这样才能做到有的放矢。
5pA8b3T,D8R ^ s051Testing软件测试网wpa7O:g那么什么样的测试用例是描述准确,易于实现的?让我们通过一个测试 Notes 中的打开应用对话框的例子来看一看。51Testing软件测试网#K#IS.H1I*i
图 1. 测试打开文件对话框
(eBN)h.eC$FI0Fw&U+R*|-Vc4}u0例 1A. 模糊的测试用例51Testing软件测试网3`z.? H?/]O
1、打开“Open Application”对话框51Testing软件测试网AszanU}BN
-`'i9R VXS#ps0例 1B. 准确的测试用例51Testing软件测试网0Z8aJ?0W&S#O#oD
Z+NX5Yf7u0显然,对于一个有经验的测试人员,可以很轻松的理解例 1A 中的描述,但是对于自动测试人员来说,这种描述不够细致,并且容易带来歧义的。我们需要知道通过何种途经打开文件对话框?怎样切换到 Server?怎样在 server 上定位到用户邮箱应用?只有当我们把这些都明确下来之后,测试脚本才是准确的,并且易于实现的。51Testing软件测试网3yL#bN*zl1FL
51Testing软件测试网1Q!^O T| H记录关键测试步骤和结果
9|3nu5G;]5fg1`@2F I051Testing软件测试网F BAgq9r&q4h2P准备好了用例,我们就可以开始编写测试脚本。基于准确的测试用例描述和灵活的 IBM 框架支持,我们可以轻松的把测试步骤翻译成测试脚本。同样以脚本例 1B 为例,我们可以可以得到例 2 中的脚本代码:
M~6a[z(N[M r0/x}*^'Tho0 例 2. 初步的测试脚本51Testing软件测试网o.r%gs7D-dwN Jt
:l:t7@-J4ac)dx2X0这是一个新手容易写出的测试脚本,这个脚本遵循 IBM 框架设计,完成了用例要求的步骤,并加入了对测试结果的验证。看起来符合测试用例的要求,不过,这个脚本还不够好。
%u1Z-{R/X!w;ds7i0我们说“自动化测试”=“自动化”+“测试”,作为程序执行正确性的验证工具,我们需要假设执行流程中的每一步都是 可能出现错误的。比如说步骤一的点击菜单动作,就可能因为程序内的菜单映射错误而打开错误的对话框;再比如在步骤三中,可能因为网络超时或程序错误判断自 身为离线状态而无法成功连接到服务器。还是以为回到测试结果的分析这一问题上来,一旦产品有了缺陷或者测试执行出错,我们如何快速定位问题么?很显然,测 试人员不可能一直盯着测试脚本的执行,在自动化测试中,我们需要通过日志记录下关键步骤的执行过程和结果。
0RR7[3A#A)b:^k-U/}0在通过日志分析结果时,通常我们需要知道两点:51Testing软件测试网?+xD;j'OhY
1、步骤是否已执行;
_9P7Mn!O(@02、被测程序是否正确做出反应。51Testing软件测试网i5UTv*Q]
对于第一点,通过在 App Object 层和 Task 层的增强,Notes 自动测试的框架能够自动输出信息,显示出执行了的步骤,这个功能本文后面会做深入介绍。而被测程序是否正确做出反应,则需要我们在测试脚本中进行检测并记 录。实际上,当我们手工验证测试用例时,我们都会不经意的验证每一步的程序响应,并决定下一步的操作。作为“隐藏的验证点”,我们需要把他们补充到测试用 例中。例 3 中给出了经过完善后的测试用例:51Testing软件测试网2P"Q*rl;v(}
例 3. 完善后的测试用例51Testing软件测试网(Ntz;Mx-h-XC-Zd&W-k
9R4pJZ)JO B0相应的,我们在测试脚本的编写过程中也需要加入对各个步骤中程序响应的验证,并将结果记录到日志中。例 4 中给出了我们最终的示例测试脚本:
P(wt/z9q[0例 4. 完善后的测试脚本
O2n k%j$l.X)L051Testing软件测试网JUGIrpj9f8Uh
Logger.logDetail(“1. 点击 File-> Open Application 菜单”); K?)_#i DVn$|.^|1i0Menu.mOpenApplication.pick(); Gup.H&U;^O7A;J0OpenAppDlg dlgOpenApp = new OpenAppDlg(); C[/u+_G+gyi2S;z0Logger.logCompareFatal(true, dlgOpenApp.exist(LocalSettings.shortWaitTime), ~ ~]9V cb5cC0 "验证:‘打开应用’对话框出现");Logger.logDetail("2. 在 Server Combox 中输入服务器地址"); ;o0BfX%kac0dlgOpenApp.getServerCombo().setText(User.mailServer); IZV G;~8G5i6]0Logger.logCompareFatal(User.mailServer, dlgOpenApp.getServerCombo().getText(),51Testing软件测试网2K$H(g[n~ "验证:服务器地址输入正确");Logger.logDetail("3. 切换到 Server"); M"E"K1|Cb#P0dlgOpenApp.getOpenButton().click();51Testing软件测试网 jz*y Wr[2Kza Logger.logCompareFatal(true, isContentOnServer(dlgOpenApp, User.mailServer), Ha x)\Wq0x[!e#H A0 "验证:列表框中显示的内容为服务器上的内容"); #m2H1BDJ1W&k0Logger.logDetail("4. 在 File Name Editbox 中输入邮箱路径名称");51Testing软件测试网]p2T9O\'{ dlgOpenApp.getFileEdit().setText(User.mailPath); hUb"tvt3w0Logger.logCompareFatal(User.mailPath, dlgOpenApp.getFileEdit().getText(),51Testing软件测试网&Dw|.fM6R "验证:邮件路径输入正确"); |