当原始功能发生重大变化时，可以在新版本上执行回归测试。它确保即使发生更改，代码仍然可以工作。回归意味着重新测试应用程序的那些未更改的部分。
回归测试也称为验证方法。测试用例通常是自动化的。测试用例需要多次执行，并且手动一次又一次地运行相同的测试用例，既费时又乏味。
如何进行回归测试？
当软件维护包括增强、纠错、优化和删除现有功能时，就需要回归测试。这些修改可能会影响系统功能。在这种情况下，回归测试变得很有必要。
可以使用以下技术执行回归测试：
1.重新测试：
重新测试是进行回归测试的方法之一。在这种方法中，所有的测试用例套装都应该重新执行。在这里，我们可以将重新测试定义为测试失败，并且我们确定失败的原因是软件故障。报告故障后，我们可以期待修复缺陷的新版本软件。在这种情况下，我们需要再次执行测试以确认故障已修复。这称为重新测试。有些人将其称为确认测试。
重新测试成本非常高，因为它需要大量的时间和资源。
2.回归测试选择：
（1）在这种技术中，将执行选定的测试用例套件而不是整个测试用例套件。
（2）选定的测试用例套装分为两种情况
·可重用的测试用例
· 过时的测试用例
1）可重用的测试用例可以用于后续的回归周期
2）过时的测试用例不能用于后续的回归周期
3. 测试用例的优先级：
根据业务影响、关键和经常使用的功能确定测试用例的优先级。测试用例的选择将减少回归测试套件。
什么是回归测试工具？
回归测试是 QA 过程的重要组成部分；在执行回归时，我们可能会面临以下挑战：
· 回归测试需要大量时间才能完成。回归测试再次涉及现有测试，因此测试人员对重新运行测试很头疼。
· 当需要更新任何产品时，复杂的回归测试也很复杂；测试清单也在增加。
沟通业务规则
回归测试可确保现有产品功能仍处于正常工作状态。与非技术领导者就回归测试进行沟通可能是一项艰巨的任务。高管希望看到产品向前发展，并在回归测试上投入大量时间，以确保现有功能能够正常工作。
·确定影响区域
· 测试用例通过发布增加发布
· 更少的资源
· 没有准确性
· 重复任务
· 单调的工作
回归测试过程
可以跨构建和发布执行回归测试过程。
跨构建的回归测试
每当缺陷修复时，我们重新测试缺陷，如果有任何依赖模块，我们会进行回归测试。
例如，如果我们有不同的构建，如构建 1、构建 2 和构建 3，我们如何执行回归测试，它们具有不同的场景。
构建1
首先，客户将提供业务需求。
然后开发团队开始开发功能。
之后，测试团队将开始编写测试用例；例如，他们为产品的第 1 版编写了 900 个测试用例。
然后，他们将开始实施测试用例。
产品发布后，客户将进行一轮验收测试。
最后，产品被移动到生产服务器。
构建2
现在，客户要求添加 3-4 个额外（新）功能，并提供对新功能的要求。
开发团队开始开发新功能。
之后，测试团队将开始为新功能编写测试用例，他们编写了大约 150 个新测试用例。因此，两个版本的测试用例总数为 1050。
现在测试团队开始使用 150 个新测试用例测试新功能。
一旦完成，他们将在 900 个测试用例的帮助下开始测试旧功能，以验证添加新功能是否损坏了旧功能。
在这里，测试旧功能称为回归测试。
测试完所有功能（新旧）后，将产品移交给客户，然后客户将进行验收测试。
验收测试完成后，产品将移至生产服务器。
构建3
在第二个版本之后，客户想要删除销售等功能之一。
然后他将删除所有属于销售模块的测试用例（大约120个测试用例）。
然后，测试其他功能，以验证删除销售模块测试用例后所有其他功能是否正常工作，此过程在回归测试下完成。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
