筆者結合中臺經驗，本文重點談談 App 的質量穩定性該如何做。業務作為 App 的核心服務之一，業務異常監控當然也很重要，這不是本文重點。
質量問題的現狀
對於質量問題，直接以小故事的形式展開。下面是移動中臺年度針對質量覆盤的一些思考
- 技術方案階體現測試用例
對於業務專案來說，會存在測試資源、冒煙用例、精準測試、QA 新業務的業務迴歸、核心業務的 UI 自動化、高鐵階段的 QA 人工迴歸等。這裡簡單講講這些詞語，對於新的業務專案，一定會有測試資源，簡單說就是 QA，新專案在經過 PRD、MRD、需求討論會、Kick-off 之後，技術方案評審後，會經過測試用例評審，產出的結果就是用例指南，到時候 QA 會在用例平臺指配給對應的開發。
敏捷開發思想下，業務需求跟車，而不是針對業務專案開車，每週一建立本週高鐵，需求買票跟著上車。上車之前針對你的開發分支，會走精準測試，產出精準測試報告，分析測試報告，如果覆蓋率比較低，需要分析是兜底程式碼太多，還是 QA 沒有執行完全，針對後者你可以結合用例，是否有遺漏，然後去 push QA 再去迴歸。
針對不變的業務，沉澱出的自動化用例，會走 UI 自動化測試。期間線下效能監控會發現一些效能問題。每週值班 QA 會無差別迴歸業務。
但是啊，這些大多是針對業務，如果是基礎 SDK 的能力和效能，大多是無法定位到問題的，所以針對技術 SDK 可能沒有測試資源，需要中臺開發者在 SDK 階段，去思考基礎 SDK 本身的核心用例，用例需要思考功能用例和效能用例，還需要思考一些開關情況、版本升級等問題。
所以第一個話題，主要是針對基礎 SDK 來說的，不過業務專案，在技術方案階段思考的不是測試用例，而是天網報警（業務異常埋點上報）、業埋點（核心資料）等
- 官方元件引入 BetterMR
經過約定：業務程式碼經過測試之後，才可以從個人分支合併到 dev 分支（注意 dev 分支不是市場分支，release 分支是市場分支）。提交的 MR 必須至少 +2 後才可以合併。其中1個人是同技術棧的老司機，另一個人是同專案的業務開發，做到對齊。
程式碼質量直接關係到產品質量，Code Review 是保證程式碼質量一個最顯著可行的措施之一，而 BetterMR 是我們探索最佳 Code Review 的方式之一。
約定與建議
【約定】後續所有專案與日常均預設走 betterMR 流程，如果相對簡單，可以申請不走 betterMR 流程；
【約定】MR 分級，預設為普通 MR，在 24H 內完成 review；提交者可選擇為緊急 MR，在 2H 內要完成 review；
【約定】在後續規劃中，架構師在工作分配上預留一定時間到 CR 上；
【約定】被 @ 的 reviewer 當自己手頭忙碌無法 review 的情況下，可以選擇在評論中 @ 一位 backup 替自己 review；
【建議】緊急MR發出後，請提 MR 的同學主動口頭或企業微信聯絡和催促 reviewer 快速響應；
【建議】reviewer 手頭忙碌時，可以先 +1 merge，後續再 review 建議；
reviewer 數量與選擇
約定與建議
【約定】每個 MR @ 到兩位同學，其中包含該業務域的 owner，以及另一位適合的同學（熟悉業務或者熟悉程式碼）；
【約定】MR 不要 @ 超過兩位同學；
小MR流程上是否可以更快一些
約定與建議
【約定】質量是核心問題，因此暫時所有走 betterMR 的專案和日常都堅持走 +2 的邏輯；直至我們的質量資料有顯著好轉，代表我們的質量意識有明顯提升，再考慮輕量化；
【建議】提MR的同學和 reviewer 可以通過更有效的描述、註釋、溝通來加速 review 流程，如 UI 部分更快速 review，邏輯部分重點review 等；
MR的程式碼量與有效拆分
約定與建議
【約定】在技術評審與 kick-off 階段對工作量進行MR任務的邏輯拆分，業務域 owner 在這兩個階段進行把關，拆分的任務儘量粒度細化；
【約定】在一個 MR 中儘量將相關邏輯完整提交，有利於程式碼的整體 review；
【約定】在技術評審階段，業務域 owner 對技術方案與拆分做內審，提前熟悉改動面和設計細節，避免在 MR 提交的程式碼之外存在邏輯遺漏；
【建議】在保證子任務MR邏輯完整的前提下，儘量約束每個 MR 的程式碼量，保證 review 效果；
- 業務 SDK 接入精準測試，產出報告必須分析
業務專案我在第一部分說明了會針對業務做哪些測試動作，在中臺角度出發，思考業務中臺（比如商品、訊息）如何保證質量，也可以參考業務專案，接入精準測試，針對每一份測試報告，做進一步的分析，如果覆蓋率比較低，需要分析是兜底程式碼太多，還是 QA 沒有執行完全，針對後者你可以結合用例，是否有遺漏，然後去 push QA 再去迴歸。
技術中臺負責的業務中臺專案，也就是業務 SDK 也需要嚴格管控，否則就是業務異常，從而產生線上問題或者線上資損。
- 業務專案一定接入天網報警，基礎 SDK 關鍵流程接入天網報警
App 質量與穩定性劃分為：效能與質量穩定性、業務穩定性。業務不穩定了就很容易產生線上問題或者資損。針對業務異常，我們對線上問題歸因做了一些梳理，一般可以分為：
方法或介面的引數資料型別不對、引數值不在合法區間、邊界 case 沒有覆蓋、其他（歷史遺留 bug、三方 SDK 升級導致、2端溝通不足需求沒對齊）；
假如我們將第一二類問題解決好，線上問題將會顯著改善。這正好就是天網報警的設計初衷，天網報警用於業務異常監控並報警。天網報警監控並不像 APM 一樣是 SDK 去主動監控的，而是需要開發者自己在當前負責的模組、當前開發的專案、當前開發的日常迭代中去梳理關鍵業務流程和業務場景，對於一些可能存在的異常 case，去埋點上報。
所以制定規範：業務專案一定要接入天網報警，基礎 SDK 比如 IM、商品，Socket 連結有問題，那麼就是線上問題，肯定是業務異常。所以這樣的關鍵環節一定要梳理並上報
- 新 SDK UT 覆蓋率90%以上，老 SDK 基於 BDD 通過
基於資源有限的情況下，歷史遺留的 SDK 可能無法去梳理並編寫單測，那老的 SDK 可以去給予行為去編寫 BDD 測試用例，這裡不展開描述什麼是 BDD 和怎麼實踐。針對新的 SDK 在技術方案階段就需要思考好測試用例並體現出來，開發階段 UT 覆蓋率須大於90%。 - SDK 一定要 Lint 通過
這裡的 lint 並不是針對語法、鎖進等的 OCLint，而是 pod lint。因為發生過一些情況，就是 MR 提交後，去打包系統打包階段， 因為 pod SDK 的問題導致的打包失敗，所以 pod 的 lint 一定要通過，將問題提前解決掉。 - SDK Warning 清理
SDK 內部的 warning 儘量清理掉，比如 UIWebView 或者某個使用的 API 蘋果標記為待廢棄，假如你不按時修改掉，萬一上線後使用者使用的某個功能異常，那就 GG 了 - SDK 核心用例梳理，確保接入 App 整合測試
老的 SDK 梳理核心用例，便於 BDD 測試。SDK 的所有功能需要接入至少2個業務線 App 去驗證功能和效能是否符合預期 - SDK Demo 必須體現開發能力，多端 Demo 對齊
SDK 的功能設計、類的 API 多端對齊，能力一致。且在 Demo 上可以體現出核心功能 - 髒亂差治理並優化
年底統計線上問題原因，經常會發現不管是業務線還是中臺，都有一些遺留或者接手的線上問題，所以不管何種原因，都需要 Owner 意識，髒亂差梳理去修復問題 - 確保測試用例冒煙通過
QA 指派的測試用例一定要冒煙通過，冒煙打回很嚴重的，這是對質量的不認真，也是對 QA 工作的不尊重 - 關鍵功能有限老司機操刀開發，避免形成卡點（進度）或者影響質量，太忙的情況下至少老帶新
核心業務功能，新人很難評估到所有影響面和邊緣 case，所以優先老司機操刀開發，或者新人梳理評估出方案，老司機 review 把關。避免因為不熟悉造成進度落後或者線上質量問題 - 基礎 SDK 交叉測試
業務專案有 QA 資源，基礎 SDK 不一定有測試資源，需要開發者本身去思考測試用例，包括功能和效能方面，最後可以交叉測試，Android、iOS 互測，確保質量。