回歸測試（regression testing）是在系統修改後，重新檢查原本正常的功能，確認它們仍然運作如常。所謂「回歸」，是指原本正確的功能在更新後出現問題，而出問題的地方往往不是今次打算修改的部分。對企業來說，這可能是預約確認頁不再顯示、某個瀏覽器無法登入，或者報表的總數突然出錯。
為甚麼沒有改動的地方也會出問題
業務系統由多個互相連接的部分組成。一處小修改的影響範圍，可能比預期大：
- 程式碼共用：處理日期格式或計算價錢的同一段程式，可能同時被多個頁面使用。為一個畫面修正它，另一個畫面的結果也可能隨之改變。
- 資料結構改變：新增欄位、更改狀態名稱或修改資料庫規則，都可能影響讀取同一批資料的報表、匯出功能和系統整合。
- 相依元件更新：程式庫、框架、瀏覽器和手機作業系統都會更新，現有程式的表現可能因而改變。
- 外部服務改變：付款、訊息或 ERP 系統可能更新 API 或運作方式，負責與它們對接的部分便需要調整。
只測試新功能，無法發現這些連帶影響。回歸測試檢查的，是原本已經正常的部分。
回歸測試檢查甚麼
回歸測試會重複執行一組議定步驟，再把結果與預期結果比較。最值得納入的，是對業務和用戶影響最大的流程，例如：
- 登入及重設密碼；
- 提交表格、預約或訂單，並收到確認；
- 角色權限，例如確認員工帳戶無法進入只限管理員使用的畫面；
- 涉及金額或存貨的計算，例如價錢、折扣或結餘；
- 與其他系統之間傳送的資料。
以下示例僅供說明：團隊修改預約頁面的版面，加入一個推廣橫額。橫額顯示正常，但在較小的螢幕上，這次修改令一個按鈕移位，用戶無法再點按。如果有一項回歸檢查會以手機螢幕尺寸完成整個預約流程，這個問題便可在客戶遇到之前被發現。
人手與自動化回歸測試
回歸測試可以由測試人員按書面清單逐步執行，也可以由自動化程式在瀏覽器或手機 App 上重複同一組步驟。兩者可以互相配合。
- 人手檢查適合經常改動、需要人為判斷，或很少執行的流程。效果取決於測試人員有沒有足夠時間，以及每輪是否按同一步驟執行。
- 自動化檢查適合穩定而重要、需要多次重複的流程，例如每次發布前都要檢查的步驟。它每次以同一方式執行，並可保留截圖和步驟記錄等證據；不過，當流程本身有意改變時，測試亦要相應更新。
不少團隊會先為最重要的流程寫一份簡短的人手檢查清單，再把最常重複的部分自動化。
從哪裡開始
要測試每一個畫面和按鈕，通常並不實際。較可行的做法是：
- 列出關鍵流程：即一旦失效，便會令銷售、預約、付款或日常營運停頓的步驟。
- 寫下每一步的預期結果，令「正常」有清楚定義。
- 準備安全的測試資料和帳戶，避免檢查時產生真實訂單、發出真實訊息或涉及真實款項。
- 決定執行時間：每次發布前、相依元件或系統整合更新後，以及在議定情況下，於正式環境按時間表執行不具破壞性的檢查。
- 議定由誰跟進失敗結果，以及如何通報。
回歸測試做不到的事
通過回歸測試，只代表已檢查的步驟在測試環境中符合預期，並不能證明系統沒有任何錯誤。回歸測試亦不等同安全、效能、無障礙或易用性測試，這些都需要各自的方法。應把它視為多重保障之一，並在系統改變時檢視測試範圍。
如果系統已有支援安排，可以在軟件支援 SLA 中寫明發布前會重新檢查哪些流程。連接多個系統的項目，亦應在每個整合位置加入回歸檢查，可參閱系統整合解說。
如需了解服務範圍，可參閱 technine.io 的自動化 UI 及用戶流程測試服務。
常見問題
回歸測試和測試新功能一樣嗎？
不一樣。測試新功能是確認新加入的行為正確；回歸測試則是確認原有功能在修改後仍然正常。一次發布通常兩者都需要。
回歸測試應該多久執行一次？
最少應在修改交到用戶手上之前執行。不少團隊在更新程式庫、平台或外部服務後，也會再執行一次。合適的頻率視乎系統改動有多頻密，以及失效會造成多大損失。
中小企需要自動化回歸測試嗎？
不一定。如果系統很少改動，為幾個關鍵流程準備一份書面清單，可能已經足夠。當發布越來越頻密，或者同一組檢查用人手重複需時太長，自動化的作用便會更明顯。