UI自动化新思路——持续测试(12)

发表于:2022-9-29 09:45

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:陈磊    来源:51Testing软件测试网原创

分享:
  2.5  UI自动化新思路
  UI自动化测试在很多时候既是测试工程师的技术门槛,又是测试工程实践的“鸡肋”,为什么这么说呢?
  首先,现在各大互联网公司对测试工程师的要求都包含UI自动化测试的内容,无论是Web UI自动化测试还是App UI自动化测试都会有所涉及。但是在各大互联网公司的自动化落地实践中,UI自动化测试的好经验和好案例少之又少,大家都在诟病UI自动化带来的低的投入产出比。UI自动化测试真的就“食之无味,弃之可惜”吗?其实也并不尽然。
  UI自动化测试框架首推Selenium。目前,Selenium已和UI自动化测试开源项目WebDriver合并,合并后的名称为Selenium WebDriver。Selenium并不是第一个UI自动化测试框架,在它之前出现的UI自动化测试框架是Mercury公司开发的QTP。如果你没有听说过QTP,那么你可能了解另外一款测试工具——LoadRunner,目前这些工具几经易主。但是随着Selenium的发展,Selenium逐渐在UI自动化测试中使用的比例最高。Selenium目前已发展到Selenium 3.0。Selenium 3.0其实是网页界面自动化解决方案的统称,包含了Selenium WebDriver、Selenium IDE、Selenium Grid,如图2-9所示。
图2-9  Selenium 3.0
  Selenium能够被广大测试工程师拥护,与它是开源项目分不开。在QTP出现后的一段时间内时,并非所有人都负担得起QTP昂贵的许可费用,这限制了QTP的普及。在广大测试工程师对UI自动化测试工具极度渴求时,免费的Selenium所有人的“及时雨”。
  随着测试工程师在界面自动化测试上的投入越来越多,很多人会发现使用Selenium WebDriver实现UI自动化测试难以起到原本设想的降本增效效果。要说明UI自动化测试的问题,就不得不先介绍一些Selenium WebDriver的基础知识。要使用Selenium WebDriver完成UI自动化测试,首先要选取对应浏览器的WebDriver,目前它支持的浏览器有Chrome、Firefox、Edge、IE、Safari和Opera。项目要支持哪个浏览器,就要下载对应浏览器的驱动程序。下面以Chrome浏览器为例讲解该现象产生的原因。
  首先,需要从官方网站下载对应Chrome浏览器的chromedriver程序。测试流程如下。
  (1)登录百度网站。
  (2)在搜索框中,输入“异步社区”。
  (3)单击“搜索”按钮。
  利用Selenium完成对应的流程,代码如代码清单2-14所示。
代码清单2-14
  这里By.id是页面元素定位器,当前脚本中是以页面元素的id来定位的。页面元素的id可以通过Chrome浏览器自带的开发者工具查找,查找方法如图2-10所示。
  但是,并不是所有前端页面上每个元素都会有一个id,因此Selenium WebDriver提供了多种元素定位方法,如通过id定位,通过name定位,通过XPath定位,通过class定位等。可以想象一下,对于任意一个复杂度较高的系统来说,通过这种方式将全部业务流都使用Selenium WebDriver的自动化测试脚本实现,脚本中必然充斥着大量元素定位器的代码。此时如果前端代码发生变更,UI自动化测试脚本是否还能够正常定位到每一个元素,并完成预制的操作就是一个未知数了。
图2-10  定位器查找方法
  绝大部分情况下,UI自动化测试遇到的都是这种情况:花费了大量人力成本将项目的UI自动化测试脚本编写好、调试通,但是当更新脚本并再次使用时,脚本回放永远是失败的。
  导致上述结果的原因可能如下。
  前端工程师在修改或者开发新需求时,修改了原页面元素定位器使用的定位内容。
  与前端工程师无关,前端框架发生了修改,每次发布后都不一样。
  脚本回放过程中速度过快,每次从客户端发出请求后,服务器端都会在处理完成后将页面的部分信息一起返回给客户端,客户端再通过浏览器的渲染展示给操作者,如果脚本要查找“搜索”按钮,而“搜索”按钮还没有及时展示在页面中,虽然测试流程没有问题,但测试脚本同样会报出no element的错误。
  诸如此类的问题让UI自动化测试的重要性逐渐降低,变成了测试工程师的“鸡肋”。
  既然上面所说的UI自动化测试问题无论在Web界面自动化测试还是在移动端界面自动化测试中都是普遍存在的,那么界面自动化测试就没有工程实践的价值了呢?
  答案是否定的。UI自动化测试大范围落地最大的问题就是业务的快速迭代导致的页面高频次变化和测试脚本精准元素定位之间存在矛盾。如果UI自动化测试不受制于页面的小范围变化,是不是就提高了自动化测试的价值呢?
  一款AIDT(AI Driven Testing,人工智能驱动的测试)框架recheck-web的出现就解决了该问题。下面举例进行说明。
  系统前端升级前测试工程师参照UI自动化测试脚本撰写的页面如图2-11(a)所示,方框圈出来的菜单的定位脚本如代码清单2-15所示。
  如果在某一次升级后,前端发生了变化,这些变化又刚好是UI自动化测试脚本使用的,变成图2-11(b)的样子。这时,原生的Selenium框架脚本就需要修改定位器,具体代码如代码清单2-16所示。
图2-11  recheck-web测试系统
代码清单2-15
代码清单2-16
  如果代码中这样的引用只有一个还好,但是如果有很多就是一个灾难性的修改。PageObject模式可以很好地解决此类问题,测试工程师将页面的Object对应的定位代码修改一下即可。但实际工作中不是这样的,实际工作中要求在线运行自动化测试脚本,发现问题后,要及时找到对应问题,修改定位器的代码后再运行。每次发生变更后,UI自动化测试脚本是否能够顺利通过就变成了一个未知数,定位、修复脚本的成本很高。
  recheck-web能够让测试工程师在不修改脚本的情况下,正确完成上述业务流程,并告知测试工程师哪些地方有了变化,但是没有影响正确的业务流程。
  recheck-web是基于Selenium的加强版本,因此在原来的自动化测试工程中Selenium脚本可以无损地升级到支持recheck-web框架,具体改造点如下。
  首先,加入Maven依赖,如代码清单2-17所示。
代码清单2-17
  然后,在测试代码中导入recheck-web,如代码清单2-18所示。
代码清单2-18
  最后,改造测试脚本,修改后的脚本如代码清单2-19所示。
代码清单2-19
  完成改造后,遇见类似情况的升级后,再次运行UI自动化测试脚本就不会再出现no element异常了,而是正确地执行完全部的自动化测试逻辑,并给出测试通过的结论。同时,测试人员可以从交互提示中知道页面还是有变动的,这样既避免了大量使用UI自动化测试脚本完成测试时,脚本错误导致执行中断,也掌握了不影响业务的页面变更的内容。自动化测试结果如图2-12所示。
图2-12  自动化测试结果
查看《持续测试》全部连载章节
版权声明:51Testing软件测试网获得作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号