前言
在UI自動化測試中，元素被識别出來後，才能更加精确地模拟相關使用者行為，才能更好地開展自動化的其他内容。一般移動端APP會有頁面元素屬性，比如：ID，ClassName，Text等，可以友善定位需要操控的元素控件。對于相對複雜的APP，尤其是移動APP跨平台開發架構的出現比如，比如RN或者Flutter，又比如小程式，可以通過基于chrome devtool protocol方式定位元素屬性，也有通過圖檔相似度比對方式。
這類正常的方式是通過自動化架構識别元素，而這類的UI控件識别架構的結果輸出往往依賴于開發同學在代碼中對控件元素進行合理有效的命名，且一旦這些控件元素被混淆後就很難進行有效的元素定位。
是以，尋找一個更有效地方法，從根本性問題着手，結合現有的端自身的識别能力，把絕大多數的問題解決是否可行的方向出發，從愛奇藝APP的自動化實踐中分享一個通用的方案，友善大家學習和參考。
01 面臨挑戰
挑戰1：自動化架構元素識别能力不足
像現在很多應用在PC端目前就沒有能識别出元素的自動化架構進而無法進行UI自動化測試，而在移動端市場上常用的一些自動化測試架構，比如python-uiautomator2依賴于開發架構和開發對元素的命名才能識别,對RN頁面、H5、小程式等元素的識别支援也不是很好。
挑戰2：多機型多分辨率相容
回歸測試中需要對多機型進行覆寫測試，因機型分辨率的問題，同一個頁面也會因不同的裝置展示效果不一樣，哪怕同樣的元素在不同的裝置上展示的大小會不一緻。
挑戰3：多樣式元素，半透明元素，無屬性元素
像現在很多應用都有皮膚主題，不同的皮膚背景色使用的對應的ICON也有不一樣。在沒有合理的控件元素命名的情況下，如果單純用圖檔比對的方式，很難剔除背景色對圖檔比對結果的影響。
APP在不同裝置不同皮膚下對比
元素顯示：較小
元素中間顯示：淺灰
元素邊緣顯示：淺灰
底部多個tab間距：較寬
元素顯示：較大
元素中間顯示：黑色
元素邊緣顯示：黑色
底部多個tab間距：較窄
02 技術探索
初期方案：
服務端儲存截取後的待識别控件元素小圖，使用多種圖檔比對算法方案。
（1.圖檔Hash 2.模闆比對 3.SIFT特征檢測）
基本滿足單裝置，單背景色的圖檔查找。
當出現複雜背景，元素變化等情況将無法識别，并且也無法滿足多裝置多端的識别需求。
技術攻堅：
經過探索發現AI能進行物體識别，既然經過訓練AI模型能識别人、物、體等，那麼能不能識别APP UI控件元素和圖檔呢？
首先我們要選擇合适的模型，檢測有多種網絡模型。
對大目标難檢測問題的解決——SSD。SSD使用多層特征圖進行檢測，隻是用了高層來進行檢測沒有底層并沒有用來進行物體的檢測，SSD速度很快，但與其他物體相比，對小物體的性能較差。
對于小目标難檢測問題的解決——FPN。FPN中融入了特征金字塔，自下而上生成了高品質的特征金字塔提高了目标檢測的準确率，尤其展現在小物體的檢測。FPN可以更好的檢測小物體；缺點就是時間成本太高。
采用的網絡模型— YOLOv3
YOLOv3吸收了SSD的長處，同時增加了類FPN多尺度預測,能檢測識别大目标也能檢測小目标，同時檢測速度也非常快；缺點是目标位置有偏移，對重疊密集型目标檢測不是很好。
下圖展示一下YOLOv3的資料（來自網絡）
目标檢測效果
與其他模型的資料對比
YOLOv3滿足了我們即要檢測大目标又要檢測小目标，同時速度快的需求，我們要針對缺點進行優化。
03 落地實作
自動收集處理素材
AI訓練需要大量的素材，如何能快速的收集大量素材，從三個方向着手。
1.在回歸測試腳本中增加自動截圖，在執行自動化回歸用例時自動收集并上傳；
2.在新版本APP穩定性測試中，畫面變化截圖自動收集并上傳；
3. 通過AI測試中台提供入口讓使用者自主上傳收集；
為加強訓練召回率，我們統一對圖檔進行MD5去重，并将圖檔調整為訓練需要的尺寸，最後統一将素材儲存到素材庫伺服器。
收集完素材後就進入了我們的訓練階段。
訓練封裝流程圖：
YOLOv3密集型識别能力差的缺點,我們的APP中元素不會密集出現，當出現元素重疊那就是UI的BUG。
解決識别偏移的缺點：
元素識别，提取圖檔
分析圖檔，識别邊緣
去除邊緣
生成傳回中心點
滑動檢視更多
預測接口将傳回給使用者以下資訊：元素的分類代碼，left,top,width,height
元素預測接口落地情況一
在UI自動化測試錄制回放落地
目前UI自動化方案：腳本錄制使用的是我們自研的web版本IDE，腳本回放執行則使用我們封裝python庫。在錄制時，使用者一鍵可以檢測手機裝置上的所有元素，并對其進行操作
從上圖我們可以看到，我們會将AI識别的元素裝置畫面中，同時在右側會有一個LIST展示并可以對元素進行操作，操作時會自動生成腳本，将腳本發送給py庫，如果是點選操作py庫會以元素的中心點坐标為操作。
# 錄制腳本生成的代碼示例
# 判斷搜尋元素是否存在
if iqy.AI(btn=”btnsearch”).exists():
# 搜尋元素存在則點選
iqy.AI(btn=”btnsearch”).click()
# 也可以寫成
iqy.AI(btn=”btnsearch”).click_exists()
# 進階用法
els=iqy.AI(btn=”btnsearch”)
#擷取相關屬性
data=els[0]
print(data["ratio"],"AI預測比對度")
print(data["w"],"矩形width")
print(data["h"],"矩形height")
print(data["x"],"矩形左上x坐标")
print(data["x0"],"矩形左上x坐标")
在錄制回放中最常見的是各種關閉按鈕問題。我們在回歸執行自動化時，經常會遇到突然出現一個彈窗，當遇到這種回放就無法繼續了。
使用iqy.AI(btn="close").click_exists()，可精準處理APP内部各種廣告彈窗。解決了因為活動無法關閉導緻case執行失敗問題。
播放器在播放節目的時候畫面一直在變，而播放器中的播放、暫停按鈕也是高頻使用的。
通過傳統方式比較難識别，使用AI就變得很簡單。
iqy.AI(btn="play")
iqy.AI(btn="pause")
目前我們經過訓練了200+個元素（移動端60餘個，PC端140餘個）。像關閉按鈕的識别召回率達94%,其他按鈕80%+
實際收益：已在錄制回放中廣泛使用，每日自動運作CASE任務穩定率使用AI與未使用對比提升15%
元素預測接口落地情況二
在無屬性頁面中使用（安卓端，IOS端，PC端）。
我們使用元素預測+圖檔算法+文字識别研發出頁面結構拆分功能。
落地APP穩定性測試，PC端穩定性測試中。
頁面拆分功能對無屬性控件的頁面（小程式，RN，H5）的自動化提供了有效的解決方案。
具體實作如下：
原圖處理
元素、圖檔、文字識别
元素聚合
傳回單元素，聚合元素
實際收益：安卓APP 使用AI增強算法與未使用前對比，activity的覆寫率增加60%,bug總量增加30%
04 将AI能力拓展外部
對接其他業務打造部署一體化AI測試中台
AI測試中台給予使用者從自主上傳素材，素材标注，标注稽核到訓練産出模型，一條完整鍊路的操作能力。
AI預測服務調用方隻需要送出一張圖檔或給一個圖檔的URL位址，預測服務就會調用到API接口輸出對應的控件元素分類、坐标等預測結果。
AI測試中台在使用者送出圖檔後，會在畫面上展示預測結果，同時給出Py庫的寫法示例和python請求API示例。
對接手機雲測平台
在雲測平台使用者一鍵點選就可以直接調起AI預測接口。
AI測試中台部署中遇到的難點
1.同等性能的CPU和GPU的價格可能也會接近十倍；
2.同等價格的CPU和GPU速度差可能在十倍以上。
是以我們的AI測試中台的預測接口使用的是GPU環境。
GPU品牌使用較多的是Intel和NVIDIA，在預測接口部署中我們遇到一個重大問題。我們訓練是在Inter的GPU上生産出的模型，部署後發現一直未使用GPU進行計算。這使得請求耗時需要5～10秒，這麼長的請求耗時對使用者來說是較糟糕的體驗。
GPU計算和CPU計算時間相差數十倍。正常情況下GPU預測都在幾百毫秒。經調研發現是模型類型的原因，不同的模型類型對GPU環境有不同的要求；Inter的GPU上訓練出來的YOLOv3模型無法在NVIDA的GPU環境上使用，最終采用轉換模型才解決GPU預測環境耗時過長的問題。
解決方案：YOLOv3 weights模型 轉換Keras模型。
05 後續規劃
AI賦能自動化測試，我們已經邁出第一步，元素識别上相較原始的圖檔對比方案也取得了一定成果，落地也得到了使用者的一緻好評，為更好的服務使用者帶來更大的收益我們也面臨了更大的挑戰。
1.對複雜畫面中與背景融合度高的控件識别數量需增加，需繼續支援更多icon元素識别。
2.對複雜頁面的拆圖能力有限，需增加對懸浮小圖示，層疊圖檔的支援。
3.Card複雜度提升，左中右分欄card,上中下分類card，文字圍繞card都是需要解決的問題。
4.Banner、menus、tabs、input的識别。