按照常规的做法，当一个缺陷修复完毕后，通常会对修复后的代码进行两种形式的 。首先是确认测试，以验证该修复程序实际上已经修复了缺陷，二是 ，以确保修复部分本身没有破坏已有的功能。需要注意的是，当新的功能添加到现有的应用程序时也适用这一相同的原理。在添加新功能的情况下，测试可以验证新功能的 是否按要求和设计规范，例如回归测试就可以表明，新的代码并没有破坏任何现有的功能。
也有可能应用程序的新版本同时包含了修复先前报告的缺陷以及具有新的功能。对于“修复”部分，我们通常会有一系列的缺陷的测试脚本（DTS）用来运行以确认是否修复，而对于新的功能，我们将有一系列具体的测试脚本用来测试变更控制通知（CCNS） 。
此外，随着新的功能和更多组件的增加，软件应用程序变得越来越大，回归测试包，也就是一个 库，被开发并运用于每次应用程序的新版本发布。
如先前所述，对于每个应用软件的新版本而言，需要执行三组测试集：回归测试，特定版本的测试和缺陷的测试脚本。选择测试用例的回归测试包不是一件容易的事。选择测试集以及回归测试包需要仔细的思考和注意力。
人们会认为，每一个为特定版本的测试而写的测试用例将成为回归测试包的一部分，并在下个版本出来后用于执行。所以，也就是说，随着程序代码越来越多的新版本的出现，回归测试包会变得越来越大。如果我们将回归测试自动化，这并不应该是一个问题，但对于手动执行一个大的回归测试包，这可能会导致时间上的限制以及新功能可能会因没有时间而无法进行测试。
这些回归测试包通常包含覆盖核心功能的测试，在整个应用程序的演变过程中都不发生改变。话虽如此，一些老的测试用例可能会不再适用，因为有些功能可能已被删除，并通过新的功能所取代。因此，回归测试包需要定期更新，以反映应用程序的更改。
回归测试包是来自于针对早期版本的需求规格软件的脚本测试的组合，也包括随机测试。回归测试包应在最低限度涵盖典型的用例场景的基本工作流程。 “最重要的测试”，即对很重要的应用领域的测试应该总是被包含在回归测试包中。例如，一个银行应用程序应该包含对其安全稳健性的测试，而一个高访问量网站的Web应用程序则应该对其进行性能相关的测试案例。
成功的测试案例，即与应用程序早期版本中的缺陷测试相关的测试也是列入回归测试包的很好的候选对象。
在可能情况下，回归测试必须自动化。用相同的变量和条件一遍又一遍的运行相同的测试，不会产生任何新的缺陷。重复的工作会造成执行测试者的丧失兴趣和注意力不集中，可能在执行回归测试的过程中错失发现潜在缺陷的机会。此外自动化回归测试的另一个优点是，可以添加多个测试用例到该回归测试包而不对花费时间产生太大影响。自动回归测试包可以连夜执行或与手动测试并行运行，并能释放资源。
最新内容请见作者的GitHub页：http://qaseven.github.io/