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