疫情中誕生的原創 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 測試更進一步。

革命還沒有成功，某人仍需努力。