導讀： 在 ToB 業務快速迭代與新版本釋出過程中，開發和 QA 提測面臨著大量人工測試場景。那麼如何實現智慧迴歸測試，實現測試用例到程式碼邏輯的精準記錄和雙向追溯？如何能更高效的提升測試效率？這都是自動化測試平臺的重點探索。
文｜趙衝
網易雲信資深移動端開發工程師
背景
業務場景的複雜化
隨著 B 端方案交付場景增多，版本需要快速迭代。單端平臺的自動化已經無法做到效率上的提升，人工迴歸更多的是在主觀上去評價改動的影響面，為了確保版本的穩定性，全量回歸測試的挑戰會拉長 B 端 SDK 和方案發布規劃。傳統的自動化測試校驗結果只是單一性的校驗。移動端的 API 和 UI 自動化場景複雜，新舊版本相容性用例管理，指令碼化實現用例管理效率較低。因此對於網易雲信來說，基於移動端較全場景的多端互通平臺的測試是必不可缺的。
思考與挑戰
通過平臺抽象基礎能力，以外掛化能力的方式支撐全流程自動化測試。
執行器鏈路環境
- 用於執行測試用例的執行器資訊；
- 用於執行測試用例的執行產物的構建鏈路；
- 用於執行測試用例的掛機測試裝置被排程；
雲斷言規則
- 執行結果的校驗根據規則全字端對比；
- 統一執行結果的比較規則定義，以關鍵詞方式支援；
- 持久化斷言引數，根據多端資料計算校驗結果；
元用例模型
- 根據自動化生成介面後設資料屬性，進行基礎用例和 AI 用例推薦標識；
- 根據碎片化複用組合和自定義用例，構建業務場景模型；
- 多端多平臺用例引數上下游基於平臺持久化資料進行；
- 執行集模組化配置資源包；
結果統計模型
- 執行任務結果缺陷定位分類報告；
- 覆蓋率分析；
- 歷史資料聚合模型分析；
解決方案
結合背景和思考，自動化平臺的設計策略中包含了：執行器鏈路環境、雲斷言規則、元用例上下游，場景建模、覆蓋率分析、缺陷定位及報告。
平臺架構方案
元用例提取過程
程式碼自動化提取，對映對應的基礎用例。
通過配置資源包和規則檔案，結合工具解析待測產物，自動生成測試程式碼和對應的介面用例。在平臺上選擇待測元素的方法和自定義的屬性，組合成元用例。元用例的方法屬性是不可編輯的，它是精準測試程式碼的對映產物，後續構建業務模型的基石就是基於用例的後設資料。客戶端的介面無法像服務端這樣熱更新介面行為。釋出出去的版本 API 一定是固定的介面行為。
構建業務模型
細化場景業務，做基線沉澱，提取測試執行集。
執行鏈路流程
結合 QA 本地除錯的流程，本地除錯用例的鏈路是需要支援自定義裝置資源進行除錯用例。
智慧用例推薦
真實使用者的持久化資料日誌，通過關鍵詞日誌鎖定用例鏈路執行軌跡，生成對應的用例。
實踐
縮短程式碼完成和使用者反饋之間的時間，最大限度地降低正在進行的工作的成本，這也是呈現程式碼到客戶最終價值，需要更快更安全的交付版本，達到版本的最大收益。
自動化的成本與收益（ROI）
自動化的收益與迭代次數成正比，以下是個新產品的簡化公式：
自動化的收益 = 迭代次數 * (全手動執行成本 - 維護成本) - 首次自動化成本落地專案
目前在工程線解決方案和即時通訊（IM1 和 IM2）落地實行。
每日掛機測試
通過上游 Job 完成構建任務，下游 Job 進行自動化任務。不阻塞打包工程任務如果不能觸發上下 Job，可以在業務執行 Pipeline 中寫入 node 節點執行
未來展望
前期只是針對 ToB 業務解決方案領域中移動端多平臺探索實踐落地，後續希望能夠做到真實提效的同時，提高平臺的易用性和擴充套件性。希望通過本文，能對其他團隊有所啟發，接下來的時間裡一起繼續前行探索。
作者介紹
趙衝，網易雲信資深移動端開發工程師，熱衷於研究跨平臺開發技術以及工程提效，目前主要負責視訊會議元件化 SDK 的相關研發工作