呆在笼罩在疫情下的英国，某人通宵两夜，写出了一个AI测试小工具
起源
故事起源于一次真实的经历:
那是一次官网的升级换代，所有的页面都需要重新设计并进行开发。
在那一次迭代测试中，某人花费了一个下午时间对比页面以及设计稿，找出了近百个页面样式缺陷。
虽然当时他并未着手解决这个测试效率的问题，但这次经历像一颗种子一般埋在了他的内心深处。
于是借着这次疫情宅家的机会，他花了两天两夜，写出了一个 "AI" 测试小工具......
正文
要解决什么问题？
要解决的问题其实很简单，
如何通过机器代替人工去 测试指定地址中是否存在符合设计稿的图像 ？
这个工具有什么用？
非常低的使用门槛，只需要给定测试地址作为入参。
非常低的维护成本，只需要维护 "设计稿" 。
有哪些技术难点？
-
以什么方式获取 url 中所有的图像可能性？
-
用什么算法去对比图像？
-
测试阈值如何设置？
-
如何对比动态页面？
-
如何处理登录问题？
-
如何处理不同入参所导致的不同图像？
-
( 太多了 )......
某人的思考
在满足实用性与易操性的前提条件下, 程序应当越简单越好。
所以我们不妨先将问题想的简单点, 先达成最小的目标：
程序能够探索到所有可能的 ( 且无参数限制的 ) 子页面。
程序设计
将设计稿中的每一个图像都当做是一个测试用例，
在程序执行的过程中不断匹配当前页面图像以及每个测试用例, 最终输出图像差异以及测试结果。
既然越简单越好，那必填入参只有一个，那就是 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()
遇到的问题
开发过程中当然也遇到了很多问题:
- 图像加载过多导致的内存泄漏；
- 图像大小不一致导致无法进行匹配；
- 图像结构化匹配算法耗时过长；
- 无效或重复的子页面地址；
- ...
不过不用担心，某人面无表情地解决了。
执行效果
因为没有现成的设计稿，所以决定先录制一遍页面图像后再进行测试，
自动录制效果示例:
image
在程序调试过程中录制并测试了某人的个人博客, 发现程序将其备案地址（子页面）也纳入了探索范围。
讲道理, 测试刚录制的 "设计稿" 应该是百分百通过的，但却发现测试前后的备案地址图像并不完全一致：
"设计稿" 中的图像差异图（箭头是某人自己画的）：
image
探索到的最相似的图像的差异图（箭头是某人自己画的）：
image
有点意思，两张图片的不一致是因为每次页面访问人数随时在变化，而图像识别捕捉到了这肉眼难以发现的微小差异。
这些差异有时候对人来说并不决定测试结果。所以如何设置测试阈值也将是一门学问。
总结
人类普遍使用肉眼去验证被测页面是否符合 "设计稿" ，而机器可以使用自动探索与图像识别算法进行侦测。
这样看，某人写的程序的执行过程与人工非常相近。
在此将此程序命名为 ai-webdriver。
对比传统基于元素定位的测试来说，虽然 ai-webdriver 目前无法执行精准的流程测试，但其可进化性
和简易程度是传统 UI 自动化测试无法比较的。
当然现在的自动探索算法还非常的初级，但只要不断进化自动探索算法，某人相信 ai-webdriver
总有一天可以帮助 UI 测试更进一步。
革命尚未成功，某人仍需努力。
ai-webdriver 已经被某人打包成了 .exe 文件，欢迎交流。
image
