按照常規的做法，當一個缺陷修復完畢后，通常會對修復后的代碼進行兩種形式的
測試。首先是確認測試，以驗證該修復程序實際上已經修復了缺陷，二是
回歸測試，以確保修復部分本身沒有破壞已有的功能。需要注意的是，當新的功能添加到現有的應用程序時也適用這一相同的原理。在添加新功能的情況下，測試可以驗證新功能的
工作是否按要求和設計規范，例如回歸測試就可以表明，新的代碼并沒有破壞任何現有的功能。
也有可能應用程序的新版本同時包含了修復先前報告的缺陷以及具有新的功能。對于“修復”部分，我們通常會有一系列的缺陷的測試腳本（DTS）用來運行以確認是否修復，而對于新的功能，我們將有一系列具體的測試腳本用來測試變更控制通知（CCNS） 。
此外，隨著新的功能和更多組件的增加，軟件應用程序變得越來越大，回歸測試包，也就是一個
測試用例庫，被開發并運用于每次應用程序的新版本發布。
選擇回歸測試包的測試
如先前所述，對于每個應用軟件的新版本而言，需要執行三組測試集：回歸測試，特定版本的測試和缺陷的測試腳本。選擇測試用例的回歸測試包不是一件容易的事。選擇測試集以及回歸測試包需要仔細的思考和注意力。
人們會認為，每一個為特定版本的測試而寫的測試用例將成為回歸測試包的一部分，并在下個版本出來后用于執行。所以，也就是說，隨著程序代碼越來越多的新版本的出現，回歸測試包會變得越來越大。如果我們將回歸測試自動化，這并不應該是一個問題，但對于手動執行一個大的回歸測試包，這可能會導致時間上的限制以及新功能可能會因沒有時間而無法進行測試。
這些回歸測試包通常包含覆蓋核心功能的測試，在整個應用程序的演變過程中都不發生改變。話雖如此，一些老的測試用例可能會不再適用，因為有些功能可能已被刪除，并通過新的功能所取代。因此，回歸測試包需要定期更新，以反映應用程序的更改。
回歸測試包是來自于針對早期版本的需求規格軟件的腳本測試的組合，也包括隨機測試。回歸測試包應在最低限度涵蓋典型的用例場景的基本工作流程。 “最重要的測試”，即對很重要的應用領域的測試應該總是被包含在回歸測試包中。例如，一個銀行應用程序應該包含對其安全穩健性的測試，而一個高訪問量網站的Web應用程序則應該對其進行性能相關的測試案例。
成功的測試案例，即與應用程序早期版本中的缺陷測試相關的測試也是列入回歸測試包的很好的候選對象。
自動化回歸測試
在可能情況下，回歸測試必須自動化。用相同的變量和條件一遍又一遍的運行相同的測試，不會產生任何新的缺陷。重復的工作會造成執行測試者的喪失興趣和注意力不集中，可能在執行回歸測試的過程中錯失發現潛在缺陷的機會。此外自動化回歸測試的另一個優點是，可以添加多個測試用例到該回歸測試包而不對花費時間產生太大影響。自動回歸測試包可以連夜執行或與手動測試并行運行，并能釋放資源。