起源

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

那是一次官网的升级换代，所有的页面都需要重新设计并进行开发。

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

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

于是借着这次疫情宅家的机会，他花了两天两夜，写出了一个 "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 测试更进一步。

ai-webdriver 已经被某人打包成了 .exe 文件，有兴趣的伙伴可以加入 QQ 群 276661532 进行下载