疫情中诞生的原创 AI 测试工具：ai-webdriver

起源

故事起源于一次真实的经历:

那是一次官网的升级换代，全部的页面都须要从新设计并进行开发。

在那一次迭代测试中，某人花费了一个下午时间对比页面以及设计稿，找出了近百个页面样式缺陷。

虽然当时他并未着手解决这个测试效率的问题，但此次经历像一颗种子通常埋在了他的心里深处。

因而借着此次疫情宅家的机会，他花了两天两夜，写出了一个 "AI" 测试小工具......

正文

要解决什么问题？

要解决的问题其实很简单，

如何经过机器代替人工去 测试指定地址中是否存在符合设计稿的图像 ？

这个工具备什么用？

很是低的使用门槛，只须要给定测试地址做为入参。

很是低的维护成本，只须要维护 "设计稿" 。

有哪些技术难点？

1. 以什么方式获取 url 中全部的图像可能性？

2. 用什么算法去对比图像？

3. 测试阈值如何设置？

4. 如何对比动态页面？

5. 如何处理登陆问题？

6. 如何处理不一样入参所致使的不一样图像？

7. ( 太多了 )......

某人的思考

在知足实用性与易操性的前提条件下, 程序应当越简单越好。

因此咱们不妨先将问题想的简单点, 先达成最小的目标：

程序可以探索到全部可能的 ( 且无参数限制的 ) 子页面。

程序设计

将设计稿中的每个图像都当作是一个测试用例，

在程序执行的过程当中不断匹配当前页面图像以及每一个测试用例, 最终输出图像差别以及测试结果。

既然越简单越好，那必填入参只有一个，那就是 url 。

origin_url = '我是一个url'
复制代码

程序也很简单，探索指定 url 中的图像并与设计稿进行比对， 最终输出图像差别以及测试报告。

# 探索页面中的图像
search_handler.traverse_images(origin_url)
# 生成图像差别图
search_handler.generate_diff_between_base_line_and_screen_shot()
# 输出报告
search_handler.export_picture_comparison_result()
复制代码

遇到的问题

开发过程当中固然也遇到了不少问题:

1. 图像加载过多致使的内存泄漏；
2. 图像大小不一致致使没法进行匹配；
3. 图像结构化匹配算法耗时过长；
4. 无效或重复的子页面地址；
5. ...

不过不用担忧，某人面无表情地解决了。

执行效果

由于没有现成的设计稿，因此决定先录制一遍页面图像后再进行测试，

自动录制效果示例:

在程序调试过程当中录制并测试了某人的我的博客, 发现程序将其备案地址（子页面）也归入了探索范围。

讲道理, 测试刚录制的 "设计稿" 应该是百分百经过的，但却发现测试先后的备案地址图像并不彻底一致：

"设计稿" 中的图像差别图（箭头是某人本身画的）：

探索到的最类似的图像的差别图（箭头是某人本身画的）：

有点意思，两张图片的不一致是由于每次页面访问人数随时在变化，而图像识别捕捉到了这肉眼难以发现的微小差别。 这些差别有时候对人来讲并不决定测试结果。因此如何设置测试阈值也将是一门学问。

总结

人类广泛使用肉眼去验证被测页面是否符合 "设计稿" ，而机器可使用自动探索与图像识别算法进行侦测。 这样看，某人写的程序的执行过程与人工很是相近。

在此将此程序命名为 ai-webdriver。

对比传统基于元素定位的测试来讲，虽然 ai-webdriver 目前没法执行精准的流程测试，但其可进化性 和简易程度是传统 UI 自动化测试没法比较的。

固然如今的自动探索算法还很是的初级，但只要不断进化自动探索算法，某人相信 ai-webdriver 总有一天能够帮助 UI 测试更进一步。

革命还没有成功，某人仍需努力。