在軟體生命週期中，會由於增加新的功能或增強原有的功能、修正所發現的缺陷而修改軟體，一旦軟體被修改了，就可能引起新的缺陷，使原來工作正常的功能出現了問題。迴歸測試的目的就是在程式有修改的情況下保證原有功能正常的一種測試策略和方法，因為這時的測試一般不需要進行從頭到尾的全面測試，而是根據修改的情況和由修改引起的影響面來進行有效測試。另一方面看，由於擴充和維護的測試案例庫可能變得相當龐大，每次迴歸測試都重新運行完整的測試案例包變得不切實際，時間和成本約束也不允許。所以，需要根據軟體修改所影響的範圍，從測試案例庫中選擇相關的測試案例，構造一個最佳化的測試案例組來完成迴歸測試。
迴歸測試的價值在於它是一個能夠檢測到迴歸錯誤的受控實驗。當測試組選擇縮減的迴歸測試時，有可能忽略了那些將揭示迴歸錯誤的測試案例，而錯失了發現迴歸錯誤的機會。然而，如果採用了代碼相依性分析等安全的縮減技術，就可以決定哪些測試案例可以被刪除而不會影響迴歸測試的結果。選擇迴歸測試方法應該兼顧測試風險（覆蓋面）和有效性兩個方面，根據項目實際情況，達到平衡。
- 基於風險選擇測試，基於一定的風險標準來從測試案例庫中選擇迴歸測試包。首先運行最重要的、關鍵的和可疑的測試，而跳過那些次要的、例外的測試案例或那些功能相對很穩定的模組。運行那些次要用例即便發現缺陷，這些缺陷的嚴重性也較低。
- 基於操作剖面選擇測試。如果測試案例是基於軟體操作剖面開發的，測試案例的分布情況反映了系統的實際使用方式。迴歸測試所使用的測試案例個數可以由測試預算確定，迴歸測試可以優先選擇那些針對最重要或最頻繁使用功能的測試案例，釋放和緩解最進階別的風險，有助於儘早發現那些對可靠性有最大影響的故障。
- 再測試修改的部分。當測試者對修改的局部化有足夠的信心時，可以通過相依性分析識別軟體的修改情況並分析修改的影響，將迴歸測試局限於被改變的模組和它的介面上。通常，一個迴歸錯誤一定涉及被修改的或新加的代碼。在允許的條件下，迴歸測試儘可能覆蓋受到影響的部分。這種方法可以在一個給定的預算下最有效提高系統可靠性，但需要良好的經驗和深入地程式碼分析。
迴歸測試作為軟體生命週期的一個組成部分，在整個軟體測試過程中佔有很大的工作量比重，軟體開發的各個階段都可能需要進行多次迴歸測試。在漸進和快速反覆式開發法中，新版本的連續發布使迴歸測試進行的更加頻繁，而在極限編程方法中，更是要求每天都進行若干次迴歸測試。因此，通過選擇正確的迴歸測試策略來改進迴歸測試的效率和有效性是非常有意義的。
可以參考
測試執行中非常有效策略
再論軟體測試的執行
預知後事如何，請讀下回分解：第16回 不容忽視的安裝或部署測試
著作權，軟體測試演義
——系列討論的目錄，見： 軟體測試演義——中進階系列（序）
