前言

京東APP核心購物流程因其重要性，內部稱之為黃金購物流程，公司各大業務事業部都有許多個性化訴求，每個版本承接的需求量很大。研發在保證需求完成數量的同時，還需要保證代碼質量和持續提升開發效率，對於工具的應用就顯得非常急迫。

iOS Mocker是我們部署的一套服務端接口Mock工具，主要用於業務開發過程解耦、測試數據保存和分享、客戶端容錯測試等場景。目前已完成搜索、商詳、購物車等核心購物流程的接入，內部存儲的數據基本覆蓋了這些模塊所有線上可能出現的接口返回場景，為各模塊的版本迭代和代碼重構提供了更全面的數據保障。

現狀和痛點

開發過程客戶端依賴服務端接口進行聯調

在開發階段，客戶端和服務端同時進行需求開發，客戶端在有些需求上可能需要等待服務端需求上線之後再進入開發，這種等待是不必要的，也增加了客戶端後期的工作壓力。

客戶端更便捷的積累和獲取驗證數據

以搜索結果頁的商品列表為例，由於商品種類繁多，特性差異巨大，列表頁中給每個商品的展示區域雖然很小，但是卻希望將每個商品的賣家、好評、促銷等特征信息全面的呈現出來，所以每個商品占位僅有242像素高的cell上總共分出了9個區域。每個區域的展示根據服務端下發配置的不同，不同機型適配邏輯不同，組合成200多種不同的展示形態。手機品類的幾種情況如下圖：

由於cell有復用機制，在線上環境，cell中的每一種布局在理論上都有被回收復用到另一種布局的可能。那麼，我們如何保證每一種布局之間相互復用都不會有問題？如何保證在某個區域新增加一種展示方案後，不會對相關區域造成不確定的影響？這種全面驗證的主要難點在於特殊數據的積累上，需要一個工具來輔助客戶端研發創建和積累這些特殊的驗證數據。數據積累之後，客戶端研發在代碼重構和需求開發時能更方便更快速的進行驗證。

客戶端容錯和健壯性測試

在生產環境，客戶端做好接口容錯處理是必須的。比如接口某字段下發為null時候，進行各種容器操作會導致Crash，或者可能會導致界面顯示不能降級，所以容錯和健壯性測試也是很關鍵的。

Mocker目標

• 去除開發階段客戶端對服務端進度的依賴，研發在Mocker服務器上編輯Json數據，開發時對應接口直接從Mocker服務器上拉取預先編譯好的數據進行解析，完成後續開發和自測，無需在客戶端添加額外的任何測試代碼。

• Mock數據全面覆蓋客戶端所有測試用例需要的接口數據，回歸測試時或者代碼重構之後，可以結合測試的代碼覆蓋率數據，保證完成了工程的全面驗證。

• 有效改善研發和測試的溝通和工作效率，研發在需求提測時候會攜帶驗證的Mock數據ID，測試在功能測試期間不需要依賴預發環境就可以進行測試；測試在發現問題向研發提出時候也會攜帶對應的Mock數據ID，方便研發快速定位問題。

• 為客戶端健壯性測試和自動化測試提供數據源，靈活修改接口下發所有字段的數據結構和數據類型。做到在不修改工程任何代碼的情況下，能夠通過Mocker向客戶端返回任何有可能的數據。

Mocker方案、架構圖、流程圖

具體流程如下圖：

服務端

搭建Mock Server，研發測試人員可上傳接口數據或者使用Json編輯器直接進行編輯，生成接口的返回數據和唯一ID。該條數據在保存時會添加相應的接口名、校驗參數、團隊和模塊等信息，通過此ID可以訪問編輯完成的該條數據。

客戶端

客戶端接入Mocker在網絡層統一實現，可以保證Mocker覆蓋到客戶端的所有接口。並且添加一個可以快速彈出的配置界面，由研發測試人員指定當前需要Mock的接口和數據ID。

1. 客戶端所有接口都應該在配置了Mock ID之後能夠生效，不再訪問預發或者線上環境。

2. 客戶端同一時間可以對1個或多個接口進行mock，其他接口正常訪問預發或者線上環境。

3. 在任何頁面都可以隨時配置需要Mock的接口以及Mock到Server上那條數據的ID。

4. Mocker相關代碼只在客戶端debug模式下觸發，並且在release模式下不會造成影響。

在具體實現上通過監聽搖手機事件來實現配置界面的彈出，當該處理和客戶端其他UI事件沖突的時候，可以設置關閉Mocker的搖一搖監聽。

另外通過hook系統 NSURLSessionConfiguration類的 protocolClasses方法，添加一個自定義的 NSURLProtocol的子類來攔截發起的網絡請求。在攔截之後判斷當前請求的接口名是否在Mock配置列表中存在，如果存在，就取消原始請求操作並重新發起向Mocker的請求來獲取Mock數據。

最後，我們後續還計劃將APP版本接口文檔的編輯和維護也結合到Mocker Server上，並且擴展測試用例數據組的概念，在敏捷開發和自動化測試方面進行更多的探索。