回歸測試 (Regression Testing)

在軟體開發的過程中,一定會不斷的修改程式碼,或是增加新功能的程式碼,每次更改程式碼後,我們就必須重新測試現有功能,我們要如何確保舊有的功能不會出錯?或是新增加的程式碼有沒有引入新的問題?

當軟體一有變更時,我們必須重新測試現有功能,以便確認修改、新加入的部分沒有影響到既有功能,且達到預期的目的。為了驗證修改的正確性及其影響,此時我們就要進行回歸測試。

回歸測試的概念

  1. 回歸測試是指重複執行既有的全部或部分的相同測試。
  2.  新加入測試的 module,可能對其他 module 產生 side effect,故須進行某些程度的回歸測試。
  3.  回歸測試的重心,以關鍵性 module 為核心,以有關聯的 module 為輔。

在軟體開發的各階段,都會進行多次的回歸測試,但由於一些預算或進度的問題,我們不可能每次都進行全面性的回歸測試,因此,我們必須選擇較正確的回歸測試策略,盡可能快速且有效地進行回歸測試。

回歸測試的策略

螢幕快照 2014-02-27 下午4.13.10

* 5. 選擇性重複測試

(1) 覆蓋修改法
針對發生錯誤的 module ,選取這個 module 的全部用例進行測試.這樣只能驗證本 module 是否還存在 defects ,但不能保證周邊與它有聯繫的 module 不會因為這次改動而引發 defects 。
(2) 周邊影響法
除了 ​​把出錯 module 的用例執行之外,把周邊和它有聯繫的 module 的用例也執行一遍,保證回歸測試的質量。
(3) 指標達成法
用量化的角度去分析 module 的質量,比如:經過上面的一系列回歸測試後,看看遺留的 defects 率是否已經在允許的範圍之內了,那麼我們以此為標準可以結束本次回歸測試 。

回歸測試的流程

  1. 在測試策略制定階段,制定回歸測試策略
  2. 確定回歸測試版本
  3. 回歸測試版本發布,按照回歸測試策略執行回歸測試
  4. 回歸測試通過,關閉 defects tracking issue
  5. 回歸測試不通過, 將 defects issue 退回給開發人員,待重新修改後再次做回歸測試

在組織回歸測試時需要注意的地方

  1. 各測試階段發生的修改一定要在本測試階段內完成回歸,以免將錯誤遺留到下一測試階段。
  2. 回歸測試期間應對該軟體版本 freeze (code freeze),將回歸測試發現的問題集中修改,集中回歸。

在實際工作中,可以將回歸測試與兼容性測試結合起來進行。在新的配置條件下運行舊的測試可以發現兼容性問題,而同時也可以揭示 source code 在回歸方面的錯誤。

回歸測試的是重複性高的活動,容易使測試人員感到疲勞或厭倦,降低測試效率。因此可以安排新進人員執行回歸測試,透過這樣的方式讓新進人員快速了解待測軟體,另外安排資深人員去維護、新增 test case、執行 exploratory test 或者撰寫自動化測試。

還可以在不影響測試目標的情況下,鼓勵測試者創造性地執行測試用例,變化的輸入、按鍵和配置,能夠有助於激勵測試者找到新的錯誤。

雖然回歸測試主要是透過既有的測試來確保產品的更動不會影響到舊有的功能,但是還是要維護 test case 資料庫,定期的 review、調整 test case,刪除過時、多餘的 test case,才能讓我們的測試維持在一定的水平之上。

參考網址

  1. 回歸測試(百度)
  2. 關於回歸測試

對「回歸測試 (Regression Testing)」的一則回應

發表迴響

Please log in using one of these methods to post your comment:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s