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