重點摘要#
- 非功能性需求（效能、韌性、正常運行時間等）往往被延遲到開發末期才測試，這是常見的錯誤
- 如果等到專案後期才關注效能，你將失去大量關於效能何時發生變化的資訊
- 及早進行效能測試可以建立基線數據，幫助診斷效能問題的根源
- 效能測試環境的建立本身就耗時費力，越早開始越好
詳細內容#
商業用戶主要透過功能性需求來描述他們的需求。而系統的非功能性面向 — 如效能、韌性、正常運行時間、支援需求等 — 則是架構師的職責範疇。然而，非功能性需求的初步測試往往被延遲到開發週期的很後期，有時甚至完全交給維運團隊。
這是一個非常常見的錯誤。如果你到專案後期才開始關注效能，你已經失去了大量關於效能何時、為何發生變化的寶貴資訊。
為什麼要及早開始效能測試？#
- 縮小問題範圍：當效能出現問題時，你可以聚焦在最近的變更，而非必須重新審視整個架構
- 建立基線數據：早期測試可能無法診斷效能，但能提供趨勢數據，這在後續診斷時極為重要
- 驗證架構決策：及早驗證架構和設計選擇是否符合實際效能需求，對有嚴格需求的系統尤其關鍵
- 漸進式建立測試環境：效能測試環境的建立（環境設定、測試資料、測試案例定義）本身就很耗時
如果你使用兩週迭代的敏捷方法，效能測試最遲應在第三個迭代之前納入流程。
及早測試的時機建議#
在敏捷開發中，效能測試應盡早成為開發流程的一部分。即使早期版本的系統負載不高，建立基線數據仍然是值得的投資。這些趨勢數據在後續診斷效能問題時，將提供極為關鍵的參考依據。
— By Rebecca Parsons