知物由學 | SDK API自動化測試與持續整合

自打我接觸測試以來，就獨得各類SDK恩寵，那麼SDK是什麼呢？由以下SDK邏輯構圖可知，它是一種內嵌入各種APP或者Web應用，為第三方開發者提供軟體服務的開發工具包，包括SDK介面、開發文件和Demo示例等。於是秉著和使用者在一起的宗旨，保障SDK這些內容的質量便成為了QA的工作日常。

其中，Demo是SDK提供方用來示例如何呼叫介面實現具體功能的工具，可以幫助第三方開發者直觀感受SDK的接入效果；QA在測試時也可以藉助Demo，採用手工或UI自動化的方式快速有效的覆蓋SDK的主流介面和業務場景，但這種方案更適合重UI介面的SDK。對於某些重介面內部邏輯甚至本身無UI介面的SDK而言，SDK介面作為測試的重中之重，僅僅 依賴Demo層面的覆蓋是遠遠不夠的，痛點主要集中表現在以下幾個方面：

圖1 | SDK邏輯架構圖

1.Demo開發耗時：精心設計的Demo或許可以最大程度的滿足測試所需，但相關功能開發耗時，問題暴露時間滯後；

2. SDK接入測試無法覆蓋：直接採用開發提供的Demo進行測試，無法真正理解開發文件，模擬客戶接入SDK的全流程；

3. SDK測試環境不純粹：為方便測試新增的Demo相關配置程式碼，容易影響SDK本身的測試環境，發現問題定位複雜度增加；

4. SDK測試場景不足：Demo對介面和業務場景的覆蓋有限，不能充分覆蓋介面的輸入輸出引數校驗以及內部各種異常分支；

5. SDK測試被動：SDK採用To-B形式提供服務，不能與C端客戶直接進行互動，具體效果依賴第三方應用，測試比較被動；

6. SDK無法灰度：SDK不可對第三方應用產生侵入，無法透過線上灰度或者崩潰、記憶體洩漏等工具提前感知召回線上異常；

7. SDK注重質量：SDK質量要求要比第三方應用更高，是所有接入SDK各個B端客戶質量要求的總和。

痛定思痛，當基於Demo的UI自動化不能很好的滿足專案所需時，我們便自然而然地想到了測試金字塔中端的API測試。SDK是如何進行API自動化測試，又是如何實現持續整合的呢？

01 SDK API自動化

1.1 專案架構

SDK是一種內嵌入第三方應用的軟體開發工具包，常見的種類有JSSDK、AndroidSDK、iOSSDK以及微信小程式、百度小程式、快應用等，其SDK API測試專案架構如圖2所示：

圖2 | SDK API測試專案架構圖

在測試初期，我們可以根據官方開發文件藉助Demo整合SDK，透過測試框架輸出測試用例。當SDK初始化後，呼叫API介面上傳資料到Server伺服器，並儲存在HBase中供後續資料獲取進行斷言比對，最終將測試結果輸出。在整個自動化測試過程中，底層測試框架決定了上層用例建築的好壞，面對市面上魚龍混雜的各類測試工具，我們應該如何選擇呢？

1.提供測試框架：適合行為驅動型（BDD）的測試風格，根據業務程式碼編寫測試程式碼，組織測試用例；

2. 提供斷言機制：用於判斷測試用例輸出結果是否符合預期；

3. 生成測試結果：用例執行結束後可以明確展示測試結果，包括用例執行失敗原因；

4. 快速執行用例：支援一鍵快速執行全部或單個用例，方便測試執行；

5. 支援環境隔離：每一個測試用例執行或環境變數準備的過程，都是相互隔離的，不能相互依賴；

6. 擁有活躍社群：成熟的測試框架和活躍的社群，在後續使用中遇到困難時可以方便快捷的找到解決方案。

基於以上標準，我們便可以為不同的SDK選擇適合自身專案的API自動化測試框架。比如AndroidSDK可以根據下圖3判斷是否依賴android庫、是否需要mock、是否使用第三方框架等選擇Junit、Mockio、Roboletric、AndroidJunitRunner等測試框架，JSSDK可以選擇Jest、Jasmine、Mocha等，iOSSDK可以選擇XCtest、Kiwi等測試框架分別實現各端SDK的API自動化測試。

圖3 | AndroidSDK API自動化測試框架選型圖

1.2 接入測試

接入測試是我們日常SDK測試中最容易忽略的環節，但它帶來的問題卻不容小覷，主要包括以下幾個方面：

1.2.1 接入文件

好的官方接入文件，可以讓第三方開發者在不求助技術支援人員的情況下順利接入產品，提升產品使用者體驗的同時還能提高產品轉化率。在接入測試中，我們要以黑盒測試的思維站在外部客戶的角度，判斷接入文件是否清晰有效，各個方法是否能達到預期結果，各個欄位是否必填描述是否正確等；還要以白盒測試的思維站在內部開發人員的角度，分析各個方法欄位是否存在冗餘，同步非同步回撥是否正確，是否滿足客戶需求等；此外我們還可以提供一些常見的異常接入幫助文件，降低不同客戶針對同一問題與技術支援人員之間的重複無效溝通，增強使用者體驗的同時提高技術支援人員的工作效率。

1.2.2 安全性問題

SDK接入方式的安全性問題也是我們要測試的內容之一，將SDK統一存放在外部公共平臺由客戶透過程式碼方式動態載入的方案，明顯比SDK放在內部私有平臺由技術支援分別向客戶提供的方式安全性要差好多。在程式碼層面，我們要注意提供給外部客戶的SDK是否經過混淆、加固，特別注意iOSSDK程式碼混淆級別是否會對第三方應用上架造成影響從而導致蘋果拒審等。

在產品層面，我們要注意productNumber、businessId、secretId、secretKey、token、nonce等引數隔離問題，確保不同產品不被攻擊重放資訊不被洩露等。針對AppSDK我們還需額外關注新增許可權問題，儘量採用最少的的許可權獲取最大的功效，避免因許可權問題導致的第三方應用不相容缺陷產生。

1.2.3 打包問題

不管是第三方應用還是SDK自身，在打包過程中都存在簽名、版本、資原始檔等問題需要進行前後交叉相容測試。在確保SDK釋出版本為release的前提下，我們要關注第三方應用分別採用debug、release模式進行簽名整合SDK時是否存在衝突，SDK本身是否可以實現多渠道打包以及SDK是否支援中英文包名打包等。

作為技術人員，還應時刻保持資訊的敏感度，關注各端系統最新動態，確保SDK與第三方應用之間的compileSdkVersion、buildToolsVersion、minSdkVersion、targetSdkVersion、iOS Deployment Target等版本相容，避免因官方系統升級而導致的新系統新機型新API批次不相容的崩潰問題產生。

1.3 介面測試

介面測試是SDK API自動化測試的核心，也是TestSuites的重要組成部分，好的測試用例集能夠以最小的成本覆蓋最多的業務場景，幫助專案儘早發現問題，縮短專案迭代週期，提高系統健壯性。通常情況下，我們可以採用以下多端通用、SDK專用兩種方式進行介面測試用例的設計。

1.3.1 多端通用介面測試場景

圖4 | 多端通用介面測試場景

上圖中多端通用介面測試場景主要包括入參、出參兩大部分，適用於任意介面型別，包括服務端http/https、客戶端各端SDK及各型別介面等。入參測試從引數名稱、引數數 量、引數取值三個角度出發，採用等價類劃分、邊界值分析、特殊值校驗、所有值遍歷等白盒測試思維將所有型別引數進行了劃分，在測試時我們可以邊review開發程式碼邊理解產品需求，儘可能確保介面入參的精準性。

出參測試可以從請求正常、異常兩種響應角度出發，確保各類響應碼、響應資訊描述在正確且方便問題定位的基礎上，增加模糊度以此來降低黑產客戶的攻擊。此外，我們還需要關注異常捕獲、超時重試等機制是否完善，從而提高請求正確率提升使用者體驗。

1.3.2 SDK專用介面測試場景

圖5 | SDK專用介面測試場景

在SDK介面測試過程中，不僅要考慮通用介面測試場景，還要站在不同使用者角度儘可能多的覆蓋可能發生的各類場景。如圖5所示，這類場景包括但不限於SDK上下文例項測試、 產品/業務狀態測試、編譯打包測試、初始化時機測試、初始化次數測試、本地快取測試等。如果說1000個讀者眼中有1000個哈姆雷特，那麼無數個SDK使用者中就會有無數個不同 的使用方式，我們只有在實踐中不斷積累沉澱，做好各類異常管控措施，才能兜底客戶各類異常，為其提供更好的服務。

02 SDK持續整合

SDK API自動化測試到此告一段落，但我們卻不能止步於此，我們更加期待的是將SDK API自動化測試真正融入到專案的持續整合方案中去。當開發人員提交新程式碼走完單元測試後，立即觸發Jenkins執行SDK API自動化測試任務進行冒煙迴歸，測試透過後再觸發提測流程通知QA正式進入測試階段。在測試階段，QA透過修改編寫SDK API測試用例，完成新一輪的功能測試，此外還可以透過SDK API自動化測試的線上配置實現SDK的線上實時監控。SDK持續整合方案如圖6所示： 

圖6 | SDK API自動化測試持續整合方案

2.1 持續執行

SDK API持續整合方案依賴Jenkins進行，當開發人員提交變更程式碼到倉庫生成新的SDK後，可以觸發Jenkins自動構建任務執行已有SDK API自動化測試用例進行冒煙自測，確保新版本SDK的主流程功能正常。在任意測試階段，我們還可以藉助Jenkins透過引數化的方式選擇Git構建分支、SDK版本池版本等，在自動clean、build之後將Demo安裝在目標裝置或瀏覽器，自動執行各類測試用例並將結果輸出。此外透過Jenkins定時任務的設定，還可以輕鬆實現SDK API的線上實時監控測試，第一時間發現線上問題確保線上SDK的穩定執行。

2.2 測試報告

Jenkins任務執行完成後，透過構建日誌可以輕鬆看到單次的測試結果，但每次都需要開啟並登入Jenkins，這對定時任務及專案中其他成員而言並不友好。Jenkins團隊早已想到這個問題，它豐富的內建外掛Editable Email Notification和Allure搭檔便可以完美的解決這一難題。透過Editable Email Notification可以在Jenkins任務執行結束後傳送指定格式內容且帶附件的郵件到指定郵箱，而Allure支援Java、Python、JavaScript、Ruby、Groovy、PHP、Net、SCala等多種語言可以將單次測試報告整合，並以圖表形式直觀的展現在使用者面前。具體接入方式可參考百度，最終示例結果如圖7、8所示：

03 總結 

上述方法論已在易盾反作弊專案得以落地實施並取得了顯著成效，我們透過Jasmine、AndroidJunitRunner、XCTest框架分別實現了反作弊JSSDK、AndroidSDK、iOSSDK的API自動化測試方案，輸出近100條場景用例覆蓋了反作弊專案的全部主要流程。在去Demo化的基礎上實現了SDK打包流程、測試場景的自動化，不僅測試效率提升了99%，還相繼發現了 13個crash類、需求類、快取類等依賴Demo測試難以發掘的缺陷，具體如下圖所示。

此外，透過Karma框架整合Jasmine實現了JSSDK在Chrome、Firefox、Safari、Edge、IE及H5等 多瀏覽器上的一鍵序列自動化，還透過Total Control實現了AndroidSDK批次連線、安裝、執行、解除安裝等多裝置的SDK API自動化執行。SDK API自動化測試相比UI自動化測試而言，更加有效、穩定、實用，是一項值得深入探索的實踐。

圖9 | AndroidSDK API自動化半年發現的缺陷列表

圖10 | AndroidSDK API自動化半年發現的缺陷分佈

圖11 | SDK迴歸耗時比較

SDK API自動化測試與持續整合雖然到此告一段落，但未來還有無限可能，例如，如何在SDK自動化測試的基礎上，實現客戶端專項測試解決效能難題等。歡迎各位看官持續關注並共同探討SDK測試體系。