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