SDK，是Software Development Kit的縮寫，它是為第三方開發者提供的軟體工具包，是把要單獨接入的應用的功能從應用中剝離出來，可以提供給所有其它應用使用的公共元件，降低工作的複雜度、節約了成本。

和傳統APP測試不同，SDK測試還需要相容多種型別的APP，以易盾手遊反外掛SDK為例，涵蓋了非常豐富的防破解和反外掛功能，並且服務了上億使用者。

那麼，如何在產品快速迭代，功能越來越多，且需要相容各類APP和作業系統，並且測試資源有限的情況下保障SDK測試質量呢？本文將為大家詳細介紹，遊戲反外掛SDK如何保障測試質量。

一、測試流程規範

簡單介紹下，遊戲反外掛的測試流程，如下圖：

1、在需求評審和技術評審的環節，需充分討論需求細節等，確保各個角色都充分理解需求和技術方案；

2、之後的測試用例編寫階段，可以深入瞭解需求和技術方案，並且考慮使用者的真實使用場景和異常場景，設計測試用例，組織會議評審，評審後摘出開發自測用例；

3、編碼並自測完成後，釋出加固版本。加固，區別於傳統的SDK程式碼接入方式，是一種便捷的，只需要一行命令就能接入最新版本的方式，包括反外掛SDK接入和反編譯功能；

4、測試流程：

• 冒煙自動化測試：透過Jenkins平臺構建，執行自動化加固和冒煙功能測試用例；

• 新功能測試：根據測試用例進行新功能測試，包括功能、相容性、效能等。新功能測試完成後，會持續維護進自動化迴歸用例和冒煙用例；

• 自動化迴歸測試：透過Jenkins平臺構建，執行Pytest+Airtest自動化迴歸用例，並且有豐富的斷言方式，保障原有功能正常；

5、上線和驗證：上線後可以對新功能進行手工驗證，原有功能可進行自動化驗證。

二、自動化測試提效

眾所周知，客戶端尤其是Android碎片化嚴重，不同品牌機型、作業系統、CPU架構的執行表現不一樣，所以會有各種各樣的相容性問題。對於遊戲反外掛來說，需要相容不同型別的遊戲和應用。所以單個功能，測試一個APP、一臺手機遠遠不夠。如果僅採用手工測試，效率問題就十分突出了，那麼如何高效地進行多APP測試和多機型測試呢？

首先，我們使用了的自動化冒煙、迴歸測試提高測試效率。另外，還有自動化相容性測試：透過爬取應用市場的應用，近2500個APP樣本，進行批次的APP測試，和多機型相容性測試，保障SDK的相容性。

下面詳細介紹遊戲反外掛的自動化測試。

1.測試框架

遊戲反外掛，採用Jenkins+Pytest+Airtest+Allure的方式進行自動化測試，架構圖如下：

2.用例編寫方式

如何在測試不同的機型和測試APP時簡潔地編寫測試用例呢？

首先，我們把測試機型和APP分類，迴歸時覆蓋不同型別的即可，比如遊戲，可以按引擎分為u3d mono、u3d il2cpp、cocos2d、Neox、其他遊戲引擎；

其次，用到@pytest.mark.parametrize裝飾器，讓測試入參等引數化，只需要傳入測試機list、測試APP list，這樣一個功能點只需要編寫少數幾條用例，但是卻可以測試任意的機型和APP，程式碼簡潔、複用性高。

3.用例執行結果校驗

針對反外掛功能的多樣性，我們的測試結果斷言方式也有很多種，主要分為客戶端校驗和服務端校驗。

【客戶端校驗】

• UI校驗：

遊戲APP不像普通APP，可以捕獲UI控制元件，所以airtest的影像識別就可以派上用場，比如校驗某個圖片是否存在（圖1是vmos_mutiopen的關鍵程式碼，waitingmuticrash是自己寫的查詢圖片函式）。

圖 | vmos_mutiopen的關鍵程式碼

*

*

Python # 引入airtest IDE編輯的資料夾 using('test_android/src/mutiopener.air') from mutiopener import * # 呼叫對應的函式，進行斷言 es_temp = vmos_mutiopen(apk_info.app_name,test_device_id) assert waitingmuticrash(es_temp)

• 程式狀態校驗：

查詢程式是否存在，校驗是否符合期望結果，waitingcrash是自己寫的查詢程式函式。

*

Python assert not waitingcrash(connect, apk_info.app_package_name, pytestconfig)

• logcat日誌校驗：

debug版本會對功能執行情況進行logcat日誌輸出，所以對logcat日誌內容進行斷言如下

*

Python assert log.match_logcat_file(logcat_result)

【服務端校驗】

• ES校驗：

客戶端在執行反外掛功能時，上報資料到服務端ES，這時是否上報成功，需要查詢ES檢查。

*

Python assert not report_es_search()

4.測試報告

執行Jenkins命令時加上--alluredir引數，並且增加allure Report模組後，執行構建，測試完成就可以生成漂亮的測試報告了，相較於原生pytest報告，功能更加強大：用例分類，附加截圖日誌等非常方便。

測試執行完成，可配置Jenkins郵件傳送測試結果，並且自定義郵件內容，這樣無論何時何地執行，都能便捷的關注到測試結果。

5.自動化成效

有了自動化測試的幫助，自動化迴歸從4天時間縮短為6個小時，測試時間大大縮短。並且可以透過Jenkins定時執行，比如定時0點執行，早上上班，就可以看結果。

目前，透過自動化發現9個有效問題，均為增加新功能影響原有功能，每天定期執行，並且在上線之前執行一次自動化用例，上線都更有底氣了呢~

三、自動化測試提效

除了保障功能正常外，還需要相容性+穩定性，所以，我們搭建了小型測試機機房，並且有自研多機型健壯性測試工具。

• 
  

• - 相容性測試

測試機架連線多臺測試機，使用Jenkins構建執行多機型執行安裝和執行指令碼，進行相容性測試。執行20臺測試裝置，幾分鐘就可以完成。

• 
  

• - 健壯性測試平臺

另外我們還自研了一個健壯性測試工具，Jenkins作為執行器，先獲取電腦連線的裝置devices list，然後分發給futures.ThreadPoolExecutor去執行，每個裝置都會執行pytest -count命令，並打一定的標識生成到同個目錄的allure_result，執行的引數支援自定義，可以測試任意的APP執行。

Jenkins引數化構建執行，只需要勾選對應引數即可。

斷言方式，可以組合日誌期望和程式期望進行斷言，and和or的關係都支援，並且日誌斷言，支援正規表示式。

另外count功能也非常強大，其實就是用到pytest-repeat功能，指定count次數就可以重複執行多少次，對於穩健性測試來說真的非常方便，另外配合斷言方式使用，對於復現客戶端偶現問題也非常便捷。

最後，重點介紹下run_type，這裡除了靜置執行，還用到了開源工具 Maxim的智慧monkey，支援原生 monkey、遍歷控制元件、黑白名單等功能，而且也封裝了更加易解析的日誌檔案，也支援多種遍歷方式。

最終彙總成allure測試報告：

思考

測試工作的重中之重是保障質量。怎麼樣在現有條件下更好的保障質量呢，我們需要踐行如下幾點：

1、提升測試質量，需要對業務深入瞭解，用測試的方法論來實踐，來提高測試覆蓋度。

2、提升測試效率，為了更快速發現問題，測試效率就同樣重要，一個bug，發現的越晚，修復的代價越高。首先要有良好的工作習慣，協調能力。另外，我們還需要對重複的測試步驟工作進行提煉，並引入自動化，可以極大的提高測試人員的工作效率。

3、擁有測試思維，也是很重要的一點，測試的思維很重要，要站在使用者的角度、產品的角度、開發的角度，透過正向思考與逆向思考，感染整個團隊的人，從而讓產品更加豐滿。

道阻且長，行則將至；行而不輟，未來可期。