一次曲折的競品測試自動化之路

前兩天接到一個活，對一款競品的OCR識別結果進行分析統計，要對兩萬多張圖片進行識別，而後統計各個字段的識別正確率，對於手動測試來說，這基本上是不可能的。

　　接到這活後馬上想到如下思路：對競品代碼進行反編譯，在關鍵節點插入本身代碼，對競品選擇圖片和識別結果進行記錄，而後自動化驅動模擬手動測試就好了，這是最快的解決方案。下午搞定，晚上掛上手機次日就坐等結果了，可反編譯後修改完代碼編譯打包失敗，即便反編譯後不進行任何代碼修改從新打包都失敗，之前遇到過相似的包，也google過緣由和解決方案，沒有很好的解決的辦法，這條路算是走不通了；

　　好在這款競品圖像識別的部分是經過JNI調用C++寫的so文件，只要理清邏輯順序，本身寫一個demo一樣調用也行，因而半個小時梳理了一下代碼，他圖片識別前要進行圖片剪切，銳化處理，各類JNI調用要進行十好幾回，果斷放棄了；

　　故事進行到這裏就走不通了，而後adb shell進入手機去看看了緩存文件，發現它識別的一些數據緩存到本地數據庫中了，但數據庫中記錄的文件名稱不是輸入圖片的名稱，是通過剪切銳化處理後的圖片，並且名稱是隨機生成的，因而一個思路誕生了，我只要記錄下圖片輸入的順序，就能把圖片名跟數據庫中相應的記錄一一對應。那怎麼獲取圖片的順序呢？查看了一下logcat輸出，其並無對選擇圖片進行記錄輸出，彷佛又陷入了絕境。

　　那就只有最後一個辦法了，圖片的位置是不會發生變化的，再寫一個自動化程序對圖片進行遍歷，記錄圖片名稱。因而整個思路成了：先把圖片導入手機，運行自動化程序對手機圖庫進行遍歷，獲取圖片名字，而後再運行一個自動化程序，按照圖片遍歷的順序依次模擬手動進行圖片輸入識別，而後拉出數據庫，進行數據提取整理，完成一一對應的過程比對結果，統計分析。這也是最後也是惟一的解決方法了，雖然有點麻煩，但總仍是避免了大量人力浪費在這上邊。

　　對別人的app進行業務上的競品對比，原本就很麻煩，由於你得不到對方開發團隊的任何支持，因此必要的逆向工程技術，開闊的視野，靈活的思路對自動化人員來說很重要。

 

　　附記：作競品測試時必定要注意對本身數據的保護，若是沒有任何保護手段，那此次成功的競品測試就給對手增長了兩萬的真實數據。

　　經過對各類類型的app的逆向工程，我能夠很負責任的說，不偷用戶數據，安全性作得很好的app真的不多。