什麼是迴歸測試 (Regression Testing)呢? 當受測程式修改後, 重新測試受測程式, 確保 舊有的功能還運作正常, 沒有受到修改的影響.

這邊要提醒大家的, 當你有修改或是新增程式碼時, 很自然的你會去測試變動的部分, 看看你的修改是否作出你想要的行為. 不過至於其他沒改到的部分, 很多人很容易忽略它, 這也就是為什麼改 A 錯 B 會常常出現.

為什麼要進行迴歸測試呢? 主要是因為幾個考量

• 意外產生新問題
正如前面說的, 有時候可能會導致之前對的功能, 現在變成有問題

• 不信任開發人員
因為開發人員可能只是急於改出現在這些東西, 但是會不會很仔細確認影響程度, 這就很難說

• 避免召回(recall)
如果修改的部分造成之前功能無法運轉, 嚴重的話, 可以會讓公司有極大的損失, 導致產品召回.

那什麼時候是合適的時間點, 是需要來進行迴歸測試呢? 通常你會在以下狀況時進行

• 有任何修改
不是只有修改 bug 需要跑, 任何修改都需要. 所以下面是可能的時機點
修復 bug
調整設計
重構
效能調整

• 每當某個功能做完時

• 每當產品要發行前
雖然迴歸測試很重要, 但是對於很多人來說, 要執行迴歸測試還是一件不容易的事情. 主要是因為:

• 時間有限
如果你的測試個案個數不少, 但是時間並不是很多, 這時候要把全部跑完, 那真的是很挑戰.

• 開發人員的習慣不好
如果開發人員沒有先檢查是否能動, 就交由你來測試, 我想很多場景有可能是不動, 這時候可能會讓測試人員很火大, 次數多了, 就不太想測.

另外, 如果開發人員提出的解法是症狀解, 而非整體解. 這時候你初步測試通常是沒有問題的. 像這種的都需要比較長的時間, 比較廣的測試範圍, 你才會知道所帶來的影響

• 文件不清楚或太複雜
修改完後, 開發人員會寫文件說明他改了什麼, 有些狀況下, 當你看不懂那個文件在寫什麼, 或者你誤會他寫的東西, 這時候你就可能會測錯.

或者是這個修改非常複雜, 你很難在短時間了解他真的解什麼, 這時候也很不好測試.

所以從上面看起來, 迴歸測試並不是一件簡單的事情, 最大的挑戰應該是如何在有限時間內, 針對高風險區, 去完成測試. 老實說, 特效藥並沒有, 都是平時要養生. 讓我們來看看可以做些什麼:

• 自動化
所有開發都會跟你說這招, 如果能夠自動化, 真的幫助很大. 但是這些都是要代價. 所以依照前面所說的, 要漸進式來擴大自動化涵蓋的範圍, 開始做總比沒做好.

• 很清楚知道改了什麼
當你沒空弄測試自動化, 可以先做 code review, 和開發人員做深入的討論, 整理出可能影響的範圍. 這樣比較可以不用全測, 尤其是在最後, 最後, 最後一刻的時候.

但是如果是到處暴雷, 很多地方都有 bug, 這樣 code review 式的討論, 投資報酬率就不會太好.

• 風險導向
事前你會準備好模組或是函式的呼叫(calling)關係, 並且會整理出那些地方風險比較大. 這時候就看程式修改在哪邊. 根據呼叫關係和風險高低, 你大概就可以知道哪些地方需要加強重測.

• 有 bug, 加測試個案
有時候我們知道要重跑測試個案, 但是尷尬的是, 我們幾乎沒有測試個案, 或是跟哪個 bug 相關聯的地方都沒有測試個案. 這時候可能就要先補一些測試個案, 並且加上探索性測試來測試. 這些新增的測試個案, 或許現在能幫忙的有限, 之後附近再有修改, 可以幫上忙.

• 對測試個案分類
當你測試個案的個數太多時, 大多是無法全測, 這時候你要做的事情就是挑選合適的個案. 但是如果你事前沒有先對測試個案做好分類, 這時候你要選也會選不出來, 因為你不可能一個個去看他是什麼.

那我們一般都如何怎麼挑選測試個案, 來進行迴歸測試呢？這是我整理的一些做法

1. 全部重測
   當公司文化是不敢承擔責任, 並且會指責別人沒做好的話, 很多測試人員會選擇這個. 他們就是全部重跑, 萬一出事就不會有人怪他們, 為什麼那些個案沒有跑.

2. 重測 有修改的需求 的測試個案
   如下圖所示, 如果你有需求和測試個案的關係圖. 當某個需求被修改時, 你就可以知道哪些測試個案要重跑.

圖 22-1 需求和測試個案的關係

3. 重測 有經過修改的地方 的測試個案
   你可能會說上面的作法, 不是很精準, 要跑的測試個案會很多. 所以有另一種做法, 就是從程式碼的角度去找.

下面表格是, 某個函式被哪些測試個案所經過, 下圖 22-2 則是函式之間的呼叫關係. 當你有這樣的資訊, 某個函式被修改後, 你自然知道哪些相關的測試個案需要重測.

你可能會說這很精準沒錯, 但是要準備這樣的資訊成本很高, 沒錯. 凡事都有代價. 另外, 你也可能會說真的有人這樣做嗎? 有的, 對岸把這個成為精準測試, 在最近 2-3 年內還蠻紅的, 有不少書有提到這樣的觀念. 甚至有書專門講這個.

圖 22-2 模組或函式的呼叫關係

4. 哪些 需求優先順序高, 就重測其測試個案
   有些人只看需求, 哪些需求優先級高, 它就跑那些需求對應的測試個案.

5. 重測 優先順序高 的 測試個案
   有些人會從另一個角度來思考, 他先把測試場景的優先順序排好, 然後只跑這高優先級的場景的測試個案. 他不在意程式碼哪裡被修改, 就只看測試個案.

6. 先分類好測試個案, 然後根據狀況來挑選
   先將測試個案根據它的特性來分類：
   • BVT/ smoke test
   • 主功能
   • 錯誤處理
   • 細部功能
   • L10N/ Security
   • ……

然後再根據你可以有的測試時間, 組合上述類別來進行. 例如:

• 只有半天時間
自動化測試
BVT
探索式測試來驗證 bug, 跟 bug 相關連的功能

• 有 3 天時間
自動化測試
主功能的測試個案
之前失敗的測試個案

• 有一週時間
自動化測試
主功能個案
細部功能
錯誤處理
之前失敗的測試個案
Hot fix 的個案

7. 選擇某些特色的測試個案
   有些挑選測試個案是根據某些特色來選擇, 例如:

• 抓到最多 bug 的測試個案
• 驗證 P1 bug 的測試個案
• 之前執行失敗的測試個案
• 驗證合併進來的 hot fix
• 客戶超級在意的測試個案或是場景