在金融APP作自動化這條路上，咱們填過哪些坑？

從市場上金融企業對app的重視程度，天然看出其在市場、用戶和企業眼中的重要性。甚至有測試部門要求拿着圓規比對icon圓是否是正圓，拿着尺子去量icon尺寸是否是正確！軟件質量要求最高的的金融行業，在對待app自動化這件事天然是走在業內前列。

而當前金融行業app作自動化的問題已經不是是否用UI自動化的方式，也不是說是錄製、回放仍是寫腳本的方式。答案很明顯：app最注重用戶體驗，天然要作UI自動化，不能讓測試人員寫腳本。寫腳本對測試人員要求極高，也增長了企業成本。

世人眼中的UI自動化
手工測試人員：UI自動化實現了，測試就能夠不用測了自動工程師：最大的難點是維護成本極高，驗證功能而非UI，能得到多少收益關鍵看被測系統自己的穩定性以及自動化技術能力

今天就來講說，爲了達到必定高的自動化率，咱們都遇到過哪些坑。

在作app自動化過程當中，有兩大通用性問題不可迴避；

一、 屏幕分辨率和系統差別

業內人士必定知道，作app的自動化必定不能依靠座標，最多做爲輔助手段。圖像識別也被人詬病，極客們一般是「從入門到放棄」。緣由是你們用的開源算法，或許作了點優化，但仍然不能適應多樣化的app以及app版本的迭代。

示例：採用座標點擊方式不能適配不一樣機型

所以這種方式必不可取。

二、 iOS&Android兩套徹底不一樣的系統

用例幾乎不分兩套系統，但是這兩套系統卻決定了自動化腳本必須是兩套。

對金融企業科技部來說，要自研這兩套系統的app自動化系統，投入太大時間過久，更不用說操做系統升級後的更新（要知道喬爸爸血統一次更新可能就是換血）。

第一大類：影響自動化執行（操做）準確性

H5技術運用愈來愈多

H5技術的誕生，給開發者帶來了福音，卻給自動化開發者帶來了強烈的衝擊。許多本來已經作好app自動化框架大公司也不得從新考慮。而無論選擇哪一種機制都必然會遇到一些意外：

採用非原生webview控件

爲了使產品更加完美，開發人員使用了各類非原生的webview控件，示例：這是開發人員在頁面設計時調用了騰訊X5的內核瀏覽器，就沒法用統一的技術獲取到頁面layout

諸如此類的問題還有不少，H5的layout獲取不到、不許確，都將致使自動化執行失敗和預期結果檢查出錯。

鍵盤加密、驗證碼獲取

亂序加密鍵盤

這是金融行業最一致的問題，爲了讓每用例腳本互不影響，初始狀態都從登陸開始。這些亂序加密鍵盤不可能獲取到layout，那必須採用特定算法精確找到數字區域並自動點擊。

手勢密碼

還有銀行一般使用的手勢密碼

驗證碼獲取

部分金融企業採用了驗證碼方式：正常驗證碼、藝術驗證碼

都須要用特定技術手段獲取到準確的驗證碼內容，同時自動化工具備靈活機制實時填入。

三、 日期控件，不一樣系統版本、不一樣手機廠商、不一樣app開發團隊

不論是銀行仍是證券，對歷史記錄的查詢是不可缺乏的測試案例。例如測試前幾年某個月的記錄，那就須要滑動、點擊不少次。這就致使執行準確度低、用例執行效率低。

這須要定製化研發一整套（兩套系統，多個版本，多種機型）日期自動化設置小工具，才能實現這些用例的自動化。

第二大類：阻塞結果校驗正確行

提取控件部份內容

示例：如圖所示的alert內容，須要提取做爲預期結果檢查，但合同號「5」是變化的。則只能檢查「您的申請已提交，合同號爲：」。「5」則要單獨提取做爲查詢的索引。

安卓提示採用Toast機制

toast提示難以抓取，就沒法從APP端驗證流程正確性。這是評價app自動化工具強大的一個標準。

特殊計算

示例：須要計算持倉1/四、1/3的整數份。例如：持倉800股（每手爲100股），賣出1/3，則賣出數量爲：800/3（取整）=200股（2手）。

如何有效應對版本更新帶來的批量腳本更新問題

以上問題都創建在app的頁面layout信息不變的狀況，而其實是可能變化的，即便是以穩定爲主的金融企業，也會由於創新業務需求，改變頁面設計。這就致使一個問題，如今已有大量的測試腳本，這種基於layout的錄製方式，頁面設計改動後，如何高效更新大量的測試腳本，讓自動測試真正的快起來？

TestBird眼中的UI自動化（輕量、簡單、高效率）

不寫腳本用例的自動化率達到必定高的程度才能得到收益維護成本必定要下降到可接受範圍app的自動化是適配多終端、多系統的