看到有同學提問關於測試准入準出標準的問題，說自己公司研發測試流程混亂，線上發佈後問題比較多，不知道如何優化解決。
其實這個問題一般在初創公司或者新項目出現的比較多，優化的方向和方法業內也比較成熟了，這篇文章談談我對於准入準出的理解。
從軟件工程的角度來說，一個軟件產品從無到有要經歷如下幾個階段：
研發階段主要包括編碼實現、測試驗證和運維發佈。嚴格來說，爲了控制風險，保障最終交付的軟件產品達到需求預期的質量標準，在整個生命週期的每個階段都應該有對應的准入準出標準。
對應到測試環節，則是我們所說的質量門禁。在質量門禁這一定義中，我個人認爲最重要的有兩個環節：發版提測和發佈評審。
發版提測，是軟件從編碼實現環節轉移到測試驗證環節的入口。我們都聽過這樣一句話：質量是設計和實現出來的，不是測試出來的。
同理，提測階段做的如何，對後續的測試工作開展有很大的影響。如果沒有提測這一門禁，有很大可能測試剛開始就會遇到很多問題，比如表結構未同步，接口請求失敗，主流程阻塞，影響整體的進度和測試效率，隨之就會導致加班、多次的返工。
發版提測環節的准入標準，一般要從如下幾個角度去考慮：
- 功能是否實現：這一點除了開發本地自測以外，很重要的一點是測試用例評審。通過測試用例評審，開發和測試雙方對於本版本要實現的需求功能和準出標準達成一致。
- 流程是否順暢：一般的做法是測試提供本版本的P0測試用例(主流程直接相關)讓開發進行冒煙測試，測試同學負責驗收，如果冒煙測試不通過，則打回重新提測。
- 變更是否完成：這裏的變更主要指的是對應的表結構是否同步到測試環境，對應的基準測試數據是否鋪底完成，內外部的調用依賴是否通暢(如果是否，則考慮配置mock)，以及新服務部署和白名單等配置項。
當然，除了上述幾點強制項之外，還有如下幾點補充項，適度評估是否作爲準入標準。
- 單元測試：確保每個功能模塊都經過充分的單元測試，以發現潛在的缺陷(不強制)。
- 聯調測試：將各個功能模塊進行端到端的聯調，確保整個系統的協同工作正常(開發自行組織)。
- 變更確認：提測前，與開發和產品團隊確認需求是否有所變更，並修改相應的需求文檔(建議項)。
- 接口文檔：確保開發團隊準備了完善的接口文檔，以便測試團隊進行接口測試(建議項)。
- 提測範圍：開發需要羅列提測版本、範圍及相關風險清單，確保測試瞭解測試的重點和潛在問題(測試跟進)。
- 環境準備：在提測前，確保測試環境準備就緒，可以正常跑通(對應上述的變更部分)。
- 版本控制：使用版本控制系統（如Git）來跟蹤代碼變更，確保團隊成員都能獲取到最新的代碼。
除了這些內容，提測時還可能會遇到這些問題：
- 是否自動化跑主流程用例：根據團隊基礎技術建設和能力以及資源富餘成都決定。
- 多分支多環境，如何解決：做好代碼版本管理、請求打標染色、測試環境治理。
經過充分測試驗證後，如果認爲軟件質量已經滿足了預期的質量標準(也可能到了發佈時間)，就需要考慮線上發佈事項。
線上發佈是軟件生命週期的最後一個環節(一個版本迭代週期內)，發佈一般就意味着交付用戶使用，一切成爲定局。
因此在線上發佈前，需要通過發佈評審來充分評估整個軟件，確保發佈質量滿足預期要求和質量標準。
發佈評審可以視爲測試階段的準出節點，在發佈評審環節，需要考慮如下幾個方面：
- 功能完整性：所有需求是否都已實現，是否存在遺漏。
- 安全和兼容性：是否存在安全漏洞，是否能兼容不同操作系統和設備。
- 缺陷修復狀態：已發現BUG是否都已修復並驗證通過，異常場景是否有足夠冗餘。
- 性能和擴展能力：性能指標是否達標，服務是否可以水平擴容，能否支撐線上業務正常運行。
- 文檔完整和準確性：用戶手冊、運維操作指南和相關技術文檔是否準備完畢且準確無誤。
- 發佈計劃和風險預案：線上發佈的詳細計劃，可能出現的問題和對應的解決策略，是否有過演練。
在發佈計劃中，需要包括髮布時間、發佈渠道、發佈方式等內容。重點需要考慮這些因素：
- 發佈優先級：應用依賴關係，先發布哪個應用，後發佈哪個應用。
- 相關配置變更：包括數據庫的表結構變更、數據變更、應用白名單是否添加。
- 數據準備和線上驗證：緩存數據是否已經預熱、線上驗證的腳本&用例&測試數據是否準備完畢。
- 風險管理和應急預案：發佈過程出現問題的應對策略，是否回滾、是否限流、是否灰度以及溝通協調策略。
綜合考慮以上各個方面，通過發佈評審這一測試準出標準，可以在最大範圍內保障軟件在發佈時達到預期的質量和業務目標。