按照常规的做法，当一个缺陷修复完毕后，通常会对修复后的代码进行两种形式的测试。首先是确认测试，以验证该修复程序实际上已经修复了缺陷，二是回归测试，以确保修复部分本身没有破坏已有的功能。需要注意的是，当新的功能添加到现有的应用程序时也适用这一相同的原理。在添加新功能的情况下，测试可以验证新功能的工作是否按要求和设计规范，例如回归测试就可以表明，新的代码并没有破坏任何现有的功能。

也有可能应用程序的新版本同时包含了修复先前报告的缺陷以及具有新的功能。对于“修复”部分，我们通常会有一系列的缺陷的测试脚本（DTS）用来运行以确认是否修复，而对于新的功能，我们将有一系列具体的测试脚本用来测试变更控制通知（CCNS） 。

此外，随着新的功能和更多组件的增加，软件应用程序变得越来越大，回归测试包，也就是一个测试用例库，被开发并运用于每次应用程序的新版本发布。

选择回归测试包的测试

如先前所述，对于每个应用软件的新版本而言，需要执行三组测试集：回归测试，特定版本的测试和缺陷的测试脚本。选择测试用例的回归测试包不是一件容易的事。选择测试集以及回归测试包需要仔细的思考和注意力。

人们会认为，每一个为特定版本的测试而写的测试用例将成为回归测试包的一部分，并在下个版本出来后用于执行。所以，也就是说，随着程序代码越来越多的新版本的出现，回归测试包会变得越来越大。如果我们将回归测试自动化，这并不应该是一个问题，但对于手动执行一个大的回归测试包，这可能会导致时间上的限制以及新功能可能会因没有时间而无法进行测试。

这些回归测试包通常包含覆盖核心功能的测试，在整个应用程序的演变过程中都不发生改变。话虽如此，一些老的测试用例可能会不再适用，因为有些功能可能已被删除，并通过新的功能所取代。因此，回归测试包需要定期更新，以反映应用程序的更改。

回归测试包是来自于针对早期版本的需求规格软件的脚本测试的组合，也包括随机测试。回归测试包应在最低限度涵盖典型的用例场景的基本工作流程。 “最重要的测试”，即对很重要的应用领域的测试应该总是被包含在回归测试包中。例如，一个银行应用程序应该包含对其安全稳健性的测试，而一个高访问量网站的Web应用程序则应该对其进行性能相关的测试案例。

成功的测试案例，即与应用程序早期版本中的缺陷测试相关的测试也是列入回归测试包的很好的候选对象。

自动化回归测试

【英文原文：https://www.londontester.com/best-practices-in-regression-testing/#.VDoANvl_uPy】

{测试窝原创译文，译者：大头}

译者简介：

大头，在读日本九州大学修士，计算机专业，主研究方向为文本挖掘，及自然语言处理。