GUI自动化测试的前途在哪里？

Posted 2020-09-22

降低自动化测试的门槛是很多自动化测试工具提供商努力的目标。尤其是对于图形界面的自动化测试，就更是这样。 于是，“录制与回放”就成了图形界面自动化测试的主流。不论是 Web 界面的，还是基于 Windows API 界面的，还是 Java GUI 界面的，“录制与回放”的工具，不论是商用的，还是开源的，都不少。在技术上，大家也在“录制”上下足了功夫。 录制就需要先识别。现在 Web 页面的显示技术在向基于客户端的软件的界面靠拢，于是工具要识别各种动态界面的不同组件，不同编程语言实现的动态效果。你能够适应 .NET 和 ASP 编写的界面，我可以使用动态的 javascript, AJAX。 Web 的动态显示技术层出不穷，先是基于服务器端的动态页面显示，再后来又可以把代码传送并放到客户端来由浏览器解释了再动态显示，现在又可以局部更新页面的部分信息，很多页面又开始使用 Flash ，Flash又逐渐被放弃等等。

 

于是，如何自动识别这些动态的显示技术，并保证录制与回放的正确，就成了各个自动化测试工具厂商最求的目标。也就是基本上是在跟着动态显示技术发展的屁股后面跑。然而“录制与回放”有一个大问题，就是“录制”下来的脚本的维护问题。Web 界面的变化是非常频繁的。通常市场部门的一个反馈，界面就要做比较大的调整，而这个调整，会导致之前“录制”好的脚本的重用性变得很差。 需要维护。 如果不想维护，再录制一遍的话也会造成人力的浪费。 毕竟，脚本和真正的程序代码虽然都是编程的产物，但人家代码是公司研发的最终产品，是可以卖钱的；脚本只是测试的一个中间环节，脚本执行的结果才是我们测试人员想得到的东西，花费很大力气来维护一个中间产品，任何一个研发部分都要好好考虑一下投入与产出是否值得了。可维护性差是“录制与回放”技术需要攻克的技术难题。而解决这个难题，需要两方面的努力：脚本良好的封装，与 API （关键字）接口的完整定义 开发人员对于界面元素赋予唯一标示的 ID。 解决图形界面自动化脚本的可维护性，还需要开发的帮助，为界面元素提供唯一的标识。这样，不论以后界面如何变化，只要标识不变，之前的脚本一样可以复用。而良好的脚本封装是“录制与回放”几乎难以逾越的一座技术大山。“录制”决定了前期很少进行软件设计，脚本也是顺序执行的。这与预先设计完整的 API 接口，再进行脚本开发的流程是相违背的。从长远考虑，每一个软件开发企业在图形界面的自动化测试上，都应该力求向关键字编程靠拢，而不是过度的依赖自动化测试工具厂商的“录制与回放”技术。 这，才应该是图形界面测试自动化的未来。

 

>>戳戳，免费下载UI自动化测试工具TestWriter~（零编码、易操作）