導讀
Mock是一個介面編輯模擬工具，可以快速手動或者基於YAPI建立Mock介面模擬資料除錯，同時支援場景，場景組的快速切換，方便在開發期和測試階段試驗不同資料返回的UI功能邏輯。
Mooncake資料模擬平臺是得物統一的針對端側（包括前端，客戶端），與服務側聯調Mock的一款工具產品，在平臺內部可以快速的建立各個專案產品的Mock多場景資料。本文主要聚焦Mooncake資料模擬平臺的探索和實踐。
0. 前言
在技術研發過程中，經常會遇到端側前置開發，UI鏈路自測，特殊問題復現等場景，此時往往服務端側資料未準備好，或者難以提供特定場景資料，以及多場景的切換等。而針對服務端造數，存在成本高，鏈路長不穩定等問題，此時UI端側的資料模擬，則會作為開發除錯的必備手段。
現今，在得物技術部，藉助Mooncake資料模擬平臺，已經可以快速地實現介面Mock資料的建立，基於型別定義生成，基於抓包建立，基於自定義函式等方式，同時支援前端，客戶端同學，快速模擬資料測試，驗證頁面，業務鏈路，同時也能快速生成二維碼方便測試和產品同學，前置做產品UI測試和驗收。
Mooncake資料模擬平臺從立項之初，到最終落地，在過程中我們總結了一些探索和實踐總結。今天在此，主要介紹包括三個部分：
- 產品簡單介紹，以及為什麼要做 ？
- 平臺產品是如何設計的，有哪些技術點 ？
- 技術產品的推廣策略是什麼樣的 ，如何落地 ？
1. Mooncake資料模擬平臺
Mooncake資料模擬平臺是得物統一的針對端側（包括前端，客戶端），與服務側聯調Mock的一款工具產品，如下所示，在平臺可以快速的建立各個專案產品的Mock多場景資料。
2. 解決了什麼問題 ？
在Mooncake平臺之前，前端一般使用修改原生程式碼填充Mock資料，或者使用介面路徑轉換方式替換請求路徑來完成Mock，進行測試，這種往往需要對前端程式碼有改造成本，針對一個介面存在多個場景，往往需要進行來回切換驗證，如果一個場景鏈路中，往往需要多個介面返回固定的資料，需要一個個介面替換驗證，沒有線上存檔，難以共享，資料切換，鏈路驗證繁瑣。
基於如上問題，Mooncake平臺著力完成了如下功能，來降低UI側與服務側聯調的造數成本，以及驗收側的溝通成本。主要包括，基於外掛的Mock代理功能，以及視覺驗收流程。
- 借用Mock的多端代理外掛，無侵入進行Mock需求，隨時開啟關閉
- 借用線上平臺，可以方便多人共享，開啟和切換Mock資料的使用場景
- 使用場景鏈路功能，可以方便測試一整條鏈路
3. 產品整體設計
Mock產品整體，包括線上配置平臺，Mock代理層，Mock代理注入（ 僅H5有注入 ）三個板塊。
- 底層線上平臺提供空間資訊，介面，場景，場景鏈路等，並線上上平臺中支援包括超時限流的能力，資料快取能力，以及根據請求路徑，空間，請求方法名返回Mock資料的能力等
- Mock代理層，包括核心請求劫持邏輯，按照不同端，劫持不同部分，如H5一般劫持瀏覽器中的XHR和Fetch物件，SSR端劫持的HTTPClient，Android，IOS，Flutter等劫持了核心的HTTP請求模組
- 產品功能用途上支援YAPI資料生成，自動匹配生成Mock，Mock抓包功能，介面變更通知，鏈路配置驗收等功能
- 最終可以支援如產品UI驗收，測試迴歸，問題場景復現，Mock資料研發等一系列功能
4. Mooncake平臺技術點介紹
Mooncake平臺本身技術並不複雜，但相對於一般的Mock工具，在實現思路上，可能有所差異。在此就Mock外掛代理的主要流程，以及線上平臺中的抓包流程做簡單介紹。
4.1 Chrome外掛Mock代理流程
首先Chrome外掛開啟後將MockProxy.js注入到頁面的Header中，而後Proxy改寫頁面中全域性的Fetch和XHR物件，將頁面發起的請求替換成請求Mooncake平臺的getMockData請求，並帶上請求路徑，請求方法，空間Code，和請求引數等資訊，如果查詢不到資料請求，會再去請求真實介面。
如果可以查詢到Mock資料，Proxy外掛會對返回的配置資料進行處理（包括執行動態JS等），並將最終經使用者配置的預期返回，返回給Fetch和XHR的response，那麼使用者直接拿到的資料即為配置的資料部分。
4.2 H5頁面Mock抓包功能實現
如下圖所示，點選開啟抓包皮膚後，再去操作業務頁面（已注入MockProxy指令碼），抓包皮膚會類似Charles那樣，實時更新當前請求的資料，並用以使用者勾選所需要的介面進行Mock場景的生成。
具體實現如下：
- 首先頁面點選抓包按鈕，開啟抓包皮膚，會呼叫後臺服務，設定當前空間抓取開關標誌位開啟
- 業務頁面在注入劫持指令碼後，請求邏輯會經過Mock服務，Mock服務返回的請求資料裡面，帶有標誌位資訊auto為true
- 則會在業務頁面進行真實請求的資料上報到Mock服務進行落臨時庫
- 而後抓包皮膚會去請求Mock服務端最新的抓包資料資訊
- Mock服務端會輪詢如果有更新的請求資料，進行返回，否則非同步等待
- 如果超時時間過後，沒有資料更新，則會中斷輪詢，停止抓包
整體流程如下所示：
至此，無需配置網路埠代理，就能類似Charles那樣，實現介面的抓包請求。
5. 技術產品推廣運營策略
除了上述產品整體設計，技術方案點的設計開發外，技術產品在上線後，才是主要工作的剛剛開始。往往需要進行長期的使用者宣發，產品迭代完善，直至產品打磨完整，使用者能有一定規模。在此簡單介紹下，Mooncake平臺在推廣的迭代過程中的一些策略方式。
5.1 產品宣發&完善
首先，前期Mooncake平臺通過與各團隊進行溝通，約會組織產品和技術分享，先後組織分享20次以上，從首期功能上線，到大的產品迭代變更，給及時同步到大前端內部的各團隊同學，主要用以收集使用者體驗問題，並排期進行產品功能完善。
這個階段還是以健全功能，完善產品體驗為主，可能會有比較多的答疑工作，需要維護好答疑群，做好使用者文件編寫工作，其中使用者文件，需要能做到以下幾點。
- 分使用者和場景寫文件，而不是分產品選單寫
- 及時更新，對新上線需求及時更新使用
- 足夠易用，錄製操作視訊等
5.2 擴大產品影響力
中期時，主要擴寬產品的使用者面，Mooncake平臺從服務大前端內部，輻射到效率前端，客戶端，測試同學等，在產品功能上進行大的升級，然後期間依舊會通過會議分享、內部宣發，發現潛在使用者。
同時，針對產品使用開始製作資料包表，觀測雙週使用資料情況。同時開始發放產品使用問卷，瞭解進一步的產品體驗提升點，以及後續的產品發力方向。
5.3 基於資料運營
後期在產品推到一定階段後，開始By天，By人，製作報表，瞭解具體產品資料情況，包括使用者使用異常，使用者粘性情況，使用者分佈情況等。
- 比如新增了場景，但是沒呼叫的異常情況，需要人為跟進，是否產品使用存在問題；
- 比如雙週活躍使用者流失了，跟進具體同學，瞭解最近迭代未使用的原因，是最近無Mock需求，做技術迭代了等自然原因，還是其他原因，在此需要儘量避免產品使用層面的可惜流失；
- 比如按板塊關注不同端側的人數與使用數的佔比情況，判斷是否需要在某個使用者組加大推廣力度等。
6. 專案總結&展望
目前Mooncake平臺在內部已經累計幾百使用者，近萬個資料場景，雙週活躍使用者百+，後續產品將通過自動化測試來進一步降低產品UI鏈路驗收人工成本，讓測試提供核心用例，開發同學自動化進行鏈路迴歸；然後與資料服務平臺進行深度融合，減少從介面定義，到Mock資料生成中的產品割裂。
未來的Mooncake平臺會將演變成結合介面文件、服務市場、資料Mock、自動化測試等為一體的綜合研發測試工具平臺。
文/凌瑤
關注得物技術，做最潮技術人！