回歸測試 (Regression Testing)

wiki:

Regression testing is a type of software testing which verifies that software which was previously developed and tested still performs the same way after it was changed or interfaced with other software. Changes may include software enhancements, patches, configurationchanges, etc. During regression testing, new software bugs or regressions may be uncovered. Sometimes a software change impact analysis is performed to determine what areas could be affected by the proposed changes. These areas may include functional and non-functional areas of the system.

The purpose of regression testing is to ensure that changes such as those mentioned above have not introduced new faults.^[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.^[2]

Common methods of regression testing include re-running previously completed tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be performed to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.

In contrast, non-regression testing aims to verify whether, after introducing or updating a given software application, the change has had the intended effect.

回歸測試是軟體測試的一種，旨在檢驗軟體原有功能在修改後是否保持完整。

回歸測試過程[編輯]

1. 識別出軟體中被修改的部分
2. 從原基線測試用例庫「T」中，排除所有不再適用的測試用例，確定對新版本依然有效的測試用例，建立新的基線測試用例庫「TN」
3. 依據一定的策略從TN中選擇測試用例測試被修改的軟體
4. 如果必要，生成新的測試用例集「T1」，用於測試TN無法充分測試的軟體部分
5. 用T1執行修改後的軟體

• 第2和第3步測試驗證修改是否破壞了現有的功能，第4和第5步測試驗證修改工作本身。

觀念[編輯]

• 回歸測試是指重複執行以前的全部或部分相同的測試工作。
• 新加入測試的模組，可能對其他模組產生副作用，故須進行不同程度的回歸測試。
• 回歸測試的重心，以關鍵性模組為核心。

回歸測試的策略

1	完全重複測試	再次測試全部測試案例	最安全	費時/費工
2	基於風險/優先權進行測試	優先運行最重要和關鍵的/可疑的測試，跳過那些非關鍵/優先順序低的/或高穩定的	可管控重大風險的問題	實行起來有一定難度，鑑定風險等級需要技術
3	基於重要/最頻繁的功能進行測試	優先針對最頻繁的/重要的測試用例，釋放/紓解最高級別的風險，有助於盡早發現那些對可靠性有最大影響的故障	可在預算下最有效的提高系統可靠度	實行起來有一定的難度，鑑定何謂重要性需要技術
4	測試修改的部分	當對修改的局部有足夠信心，可通過相依性分析識別軟體的修改情況並分析修改的影響，將回歸測試侷限於被改變的module和他的接口上	最簡易且小規模的測試	範圍不夠全面，只能驗正修改部分是否有問題
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)，將回歸測試發現的問題集中修改，集中回歸。

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