阿裡QA導讀："大中台小前台"的組織和業務體制已經是網際網路老生常談的問題了，外賣場景作為最火熱的線上線下場景，日均單量動辄千萬量級，想要把交易流量融入到集團統一的中台架構體系中，難度無異于在給高速行駛的汽車換輪胎，對項目組尤其是品質守護同學提出了巨大的挑戰，該如何應戰？本地生活的雨清同學給大家帶來架構更新品質保障的手段和思考，希望對大家有參考價值。
引言
2020年外賣業務經曆了大範圍的架構更新，将外賣的交易流量融入到集團統一的中台架構體系中，前後耗時半年，參與的技術同學超過了200+，代碼量200W+，用例量10000+，從資料上不難看出項目的浩大和緊迫。除此以外，這個半年中，技術團隊照常承接業務需求，大部分項目經曆了在原有的彈外鍊路研發上線之後，在切流前在彈内鍊路追平需求的過程，整個項目過程類似于飛行中切換引擎。一個日均單量幾千萬級的業務，任何的品質問題都會被放大，都有可能引發重大的故障，是以對于測試團隊來說是一個非常大的考驗。從另外一個角度來看，深入參與到這麼具有挑戰的項目的機會是非常少的，在過程中踩過的坑、做過的一些思考也是非常難得的，本文記錄了過程中幾個真實的場景，通過分析當時的目标、遇到的困難、應對的手段和思考，希望能給大家帶來一些有價值的參考。
背景
架構更新項目的目标是通過技術更新将外賣業務融入到中台體系中，與各個BU充分協作形成合力。項目的範圍主要包括了：商品、店鋪、導購、營銷、交易、支付、結算等多個域，簡單來說，就是涉及到交易流程中的各個相關方。
項目的主要挑戰
這一小節簡單說明一下項目過程中遇到的三個主要的挑戰，友善大家了解後面的具體場景下的選擇。這幾個挑戰是貫穿整個項目，也是測試過程中的“上下文”。
團隊協作
因為項目而組合起來的幾百人的技術團隊，來自不同的BU、不同的部門，有各自的工作模式和規範的流程，這帶來了最主要的一個困難是，大家對于研發流程的SOP了解不一緻，對于提測品質的重視程度也不一緻，最終導緻了傳遞品質不合格，對于測試進度的沖擊非常大。
任務重、風險高
就像背景中描述的，項目工程大、時間緊，除此之外，從測試的角度看，品質要求高、保障難度大。一個成熟業務背後的技術更新，必須要保證業務的功能性、可用性、穩定性、安全性等各個方面跟更新前不能有較大的偏差，是以在測試過程需要考慮的東西就會很多；此外，在大流量的背景下，所有的小機率事件（異常場景、極端場景等）都必然會發生，是以對于測試全面性的要求就非常的高。
非常不幸，正如大部分的大型項目都會遇到的頭号風險--進度風險，在這個項目中展現的淋漓盡緻：每一個重要的時間節點上，我們都遇到了非常大的品質挑戰。
意外頻發
項目的過程完全應驗了墨菲定律，幾乎所有可能遇到的狀況，最終都成為了意外狀況。主要有：環境問題突出、傳遞品質不及預期、性能問題、仿真延期、以及各類進度風險等。
其中環境的坑就從頭到腳的踩了個遍：從彈外線下環境下線、彈内預發環境沒有DB資源，到生産環境的中間件資源到位時間不及預期。其中生産環境的單元DB遲遲不能到位，也曾使我們面臨選擇：是等資源到位後在釋出，還是修改TDDL層通過中心化先釋出等到資源到位後再重新改回來？考慮到整體的節奏以及多個BU之間釋出的依賴性，最終選擇了後者。
品質保障架構的取舍
每個項目的品質保障基本都可以劃分為四塊内容：流程優化，基礎建設，線下測試，線上品質，每一塊又根據各個團隊的實際情況劃分為不同的内容，這些内容一旦固定并沉澱下來，就成為測試團隊的“工具庫”，在後續的項目中可以随取随用。外賣入淘項目給原來的品質保障架構帶了非常大的沖擊，基本摧毀了整個“工具庫”。在項目過程中重建這一套保障架構是非常困難的一件事，簡單來說可以概括為三個字：無、難、急。
基礎品質保障
本地生活平台的品質保障架構主要内容部分如下圖所示，通過“流程優化”來規範人的部分，進而保證過程品質、釋出品質；通過“基礎建設”來保證測試的“水電煤”--環境、資料、工具；通過“線下測試”來保障新舊功能；通過“線上品質”來保障線上的穩定性。在每次項目疊代過程中，品質架構中大部分的子產品是現成的可以直接使用，隻有少量需要跟随項目進行部分的更新。
架構更新項目品質保障
本期項目中，由于整個外賣平台的架構進行了更新，測試環境、鍊路、資料、回歸體系、工具建設、線上保障等等全部被推翻，導緻了整個品質保障體系被擊穿。如何在項目過程中重建保障能力，成為了當時最大的一個難點。
無：
- 無規範的研發流程
- 無現成的測試環境
- 無現成的測試資料
- 無回歸體系
難：
- 測試全面性難以保障
- 校驗的全面性難以保障
- 核對監控的正确性難以保障
急：
- 項目周期短，測不完
分析了以上困難後，我們在項目過程中将保障能力劃分為核心保障和基礎保障。簡單來說，核心保障是保命的，必須要在外灰前建設完畢的；基礎保障是不完成，也不會出現大範圍的線上問題或者導緻項目延期的保障能力，基本都放在了外灰之後進行建設。舉個簡單的例子，在9月初的時候，穩定性小組的兩個子項目尋求測試資源，一個是灰階中心、一個是仿真項目。考慮到灰階中心是決策每一筆交易流量走彈内新鍊路還是走彈外老鍊路，如果出錯将是“要命”的，是以灰階中心是需要核心保障的，投入了專門的測試人員；仿真項目，本身是作為測試覆寫的補充，在測試人力吃緊、基于經驗設計的測試用例還在不斷發現bug的前提下，仿真保障的優先級就相對較低，最終沒有投入測試人員（在此，感謝穩定性小組同學的了解和支援）。
圖中紅色部分都是項目過程中重點投入人員保障的部分；藍色部分是在核心保障建設完畢後，才投入保障的部分。需要說明的是，藍色部分并非不重要，而是基于當時的節奏、人力、品質的一種取舍，而每一次取舍都會有相應的收益和代價。基于這樣一個品質架構分時段建設的政策，我們在大促前順利的完成了切流的目标，沒有出現重大的線上故障；同時，我們也付出一些的代價，以圖中“線下測試“中的“異常場景驗證”為例，交易、營銷平台都是對于異常處理非常敏感的平台，由于外灰前沒有進行充分的異常驗證，最終導緻這兩個平台在灰階期間出現的幾十個線上問題中，近一半是異常處理的問題（發生機率低，沒有達到P級）。
另外值得一提的是，本期項目中引入了“基礎建設”下的“資料報表”，并作為了核心保障能力。這是因為，在整個灰階切流過程中，我們需要大量的資料分析來驗證線上的真實情況。以“加購到下單的轉化率”為名額，灰階期間需要精确分析，小到同一個門店下走新鍊路的使用者轉化率和走老鍊路的使用者轉化率，是否出現了較大的差異；大到同一個城市下，是否出現轉化率的差異等等。此外還有非常多的名額，隻有确認每一次增量切流後，各個名額正常，才能計劃下一次的切流。簡單來說，資料報表是切流的依據，也是“生命線”。
總結來說，品質保障體系的建設需要因時、因事而定，需要考慮時間、成本、風險、效果等因素，每一個選擇都有它的利弊，沒有絕對正确的決策，隻有更适合當時情況的選擇。個人的一點建議是，平時需要針對所負責的業務梳理出完整的品質保障大圖，并深刻了解其中每個品質保障專項的内容、成本和效果，這樣在應對大型項目沖擊的時候，能快速的理清利弊，篩選出必要的專項。