聊聊發版提測和釋出評審

老_张發表於2024-04-10

看到有同學提問關於測試准入準出標準的問題,說自己公司研發測試流程混亂,線上釋出後問題比較多,不知道如何最佳化解決。

其實這個問題一般在初創公司或者新專案出現的比較多,最佳化的方向和方法業內也比較成熟了,這篇文章談談我對於准入準出的理解。

從軟體工程的角度來說,一個軟體產品從無到有要經歷如下幾個階段:

研發階段主要包括編碼實現、測試驗證和運維釋出。嚴格來說,為了控制風險,保障最終交付的軟體產品達到需求預期的質量標準,在整個生命週期的每個階段都應該有對應的准入準出標準。

對應到測試環節,則是我們所說的質量門禁。在質量門禁這一定義中,我個人認為最重要的有兩個環節:發版提測和釋出評審。

發版提測,是軟體從編碼實現環節轉移到測試驗證環節的入口。我們都聽過這樣一句話:質量是設計和實現出來的,不是測試出來的。

同理,提測階段做的如何,對後續的測試工作開展有很大的影響。如果沒有提測這一門禁,有很大可能測試剛開始就會遇到很多問題,比如表結構未同步,介面請求失敗,主流程阻塞,影響整體的進度和測試效率,隨之就會導致加班、多次的返工。

發版提測環節的准入標準,一般要從如下幾個角度去考慮:

  • 功能是否實現:這一點除了開發本地自測以外,很重要的一點是測試用例評審。透過測試用例評審,開發和測試雙方對於本版本要實現的需求功能和準出標準達成一致。
  • 流程是否順暢:一般的做法是測試提供本版本的P0測試用例(主流程直接相關)讓開發進行冒煙測試,測試同學負責驗收,如果冒煙測試不透過,則打回重新提測。
  • 變更是否完成:這裡的變更主要指的是對應的表結構是否同步到測試環境,對應的基準測試資料是否鋪底完成,內外部的呼叫依賴是否通暢(如果是否,則考慮配置mock),以及新服務部署和白名單等配置項。

當然,除了上述幾點強制項之外,還有如下幾點補充項,適度評估是否作為準入標準。

  • 單元測試:確保每個功能模組都經過充分的單元測試,以發現潛在的缺陷(不強制)。
  • 聯調測試:將各個功能模組進行端到端的聯調,確保整個系統的協同工作正常(開發自行組織)。
  • 變更確認:提測前,與開發和產品團隊確認需求是否有所變更,並修改相應的需求文件(建議項)。
  • 介面文件:確保開發團隊準備了完善的介面文件,以便測試團隊進行介面測試(建議項)。
  • 提測範圍:開發需要羅列提測版本、範圍及相關風險清單,確保測試瞭解測試的重點和潛在問題(測試跟進)。
  • 環境準備:在提測前,確保測試環境準備就緒,可以正常跑通(對應上述的變更部分)。
  • 版本控制:使用版本控制系統(如Git)來跟蹤程式碼變更,確保團隊成員都能獲取到最新的程式碼。

除了這些內容,提測時還可能會遇到這些問題:

  • 是否自動化跑主流程用例:根據團隊基礎技術建設和能力以及資源富餘成都決定。
  • 多分支多環境,如何解決:做好程式碼版本管理、請求打標染色、測試環境治理。

經過充分測試驗證後,如果認為軟體質量已經滿足了預期的質量標準(也可能到了釋出時間),就需要考慮線上釋出事項。

線上釋出是軟體生命週期的最後一個環節(一個版本迭代週期內),釋出一般就意味著交付使用者使用,一切成為定局。

因此線上上釋出前,需要透過釋出評審來充分評估整個軟體,確保釋出質量滿足預期要求和質量標準。

釋出評審可以視為測試階段的準出節點,在釋出評審環節,需要考慮如下幾個方面:

  • 功能完整性:所有需求是否都已實現,是否存在遺漏。
  • 安全和相容性:是否存在安全漏洞,是否能相容不同作業系統和裝置。
  • 缺陷修復狀態:已發現BUG是否都已修復並驗證透過,異常場景是否有足夠冗餘。
  • 效能和擴充套件能力:效能指標是否達標,服務是否可以水平擴容,能否支撐線上業務正常執行。
  • 文件完整和準確性:使用者手冊、運維操作指南和相關技術文件是否準備完畢且準確無誤。
  • 釋出計劃和風險預案:線上釋出的詳細計劃,可能出現的問題和對應的解決策略,是否有過演練。

在釋出計劃中,需要包括髮布時間、釋出渠道、釋出方式等內容。重點需要考慮這些因素:

  • 釋出優先順序:應用依賴關係,先發布哪個應用,後釋出哪個應用。
  • 相關配置變更:包括資料庫的表結構變更、資料變更、應用白名單是否新增。
  • 資料準備和線上驗證:快取資料是否已經預熱、線上驗證的指令碼&用例&測試資料是否準備完畢。
  • 風險管理和應急預案:釋出過程出現問題的應對策略,是否回滾、是否限流、是否灰度以及溝通協調策略。

綜合考慮以上各個方面,透過釋出評審這一測試準出標準,可以在最大範圍內保障軟體在釋出時達到預期的質量和業務目標。

相關文章