【51CTO.com快译】有研究表明：在安装了新的应用程序之后，只有四分之一的用户会在次日回到该应用。而大多数用户在首次使用之后就直接将其卸载掉了。造成此类留存率低下的主要原因，便是测试人员对于应用程序的测试不足。由于他们对于重复测试毫无兴趣，因此尽管深知回归测试的重要性，但是他们仍然会在软件项目中选择性地忽略掉测试的环节。
什么是回归测试
简单而言，回归测试(https://www.pcloudy.com/a-brief-overview-of-regression-testing/?utm_source=linkedin&utm_medium=post&utm_term=p&utm_campaign=continuous_testing_wp&utm_source=linkedin&utm_medium=post&utm_campaign=continuous_testing_wp&utm_term=p)可以被定义为：在对计算机程序进行了一些修改之后，对其进行重新测试，以确保所实施的更改不会对现有代码产生不利的影响。可以说，回归测试提高了测试人员尽早检测到那些由更改所引入的程序缺陷，同时也降低了解决缺陷的成本。
可见，回归测试既能够确保软件的正常运行，又能保证软件开发者将产品的最佳版本投入市场。但是，光靠人工来创建和维护那些几乎无休止的回归测试是根本不可能的。这就是为什么大多数软件企业会采用自动化的回归测试方式，以节省时间和精力的原因。
回归测试的类型
一般而言，对于不同的测试阶段，我们会采用不同类型的回归测试。下面让我们来了解一下回归测试的类型：
- 单元测试(Unit Testing)：在完成了对于某个单元的代码变更后，需要测试人员重新测试先前已经通过了的单元测试。通常，我们可以在代码中设置自动化单元测试(https://dzone.com/articles/unit-testing-and-test-automation-two-things-youre)的入口，以提高测试的效率。
- 渐进式测试(Progressive Testing)：当开发人员对软件及应用程序的相关规范进行了更改，并且重新设计了测试用例(https://www.pcloudy.com/17-best-tips-to-write-effective-test-cases/?utm_source=linkedin&utm_medium=post&utm_term=p&utm_campaign=continuous_testing_wp&utm_source=linkedin&utm_medium=post&utm_campaign=continuous_testing_wp&utm_term=p)后，就需要有效地进行此类渐进式测试。
- 选择性测试(Selective Testing)：为了减少重新测试的成本和工作量，测试人员会采用当前测试用例中的一部分。不过，当它所涵盖的程序实体发生变化时，则必须重新运行相应的单元测试。
- 全盘重新测试(Retest-All Testing)：随着时间的推移，就算未对程序代码进行修改，也要重复测试所有的用例。当然，如果应用程序的改动较小，此举则会非常耗时。
- 完全测试(Complete Testing)：在对现有的代码进行了多次修改之后，我们需要有效地进行完全测试。此举不但是为了识别程序中的潜在错误，而且在完成之后，我们便可以将最终的软件直接提交给用户了。
如何选择回归测试计划
因此，每当软件应用程序发生变更、或是有新的版本需要发布之前，开发人员都会选择性地将上述测试类型作为回归测试过程(https://dzone.com/articles/plan-your-regression-testing-strategy-by-asking-th-4)的一部分予以执行。
- 首先，开发人员执行单元级的回归测试，以验证其修改代码的正确性。创建此类新的测试，是为了应尽可能多地覆盖那些新增的软件功能。
- 然后，开发人员通过将修改后的代码合并集成到现有软件中，以创建新的自动化单元测试(AUT)版本。
- 接着，开发人员执行冒烟测试(smoke tests，https://dzone.com/articles/how-to-distinguish-the-differences-between-smoke-s)，以确保前面步骤所产生的构建(build)是正确可行的。
上述测试都可以交由诸如Jenkins之类的持续集成(https://dzone.com/articles/what-is-continuous-integration-11-key-practices-an)服务，来自动执行。一旦确认了构建的正确性，我们就需要通过完整性测试，来确认在扫清了所有已知缺陷的基础上，新增的功能是否能够按照预期运行。
接着，我们可以通过执行集成测试，来验证应用程序的各个单元彼此是否能够顺畅通信，以及是否与后端的服务(例如数据库)进行交互。
下一步，我们需要根据代码的大小和涉及到的范围，来进行部分或全部的回归测试。
在测试过程中所发现的代码缺陷，会以报告的形式提交给开发团队。通过分析、找到解决方案之后，他们也需要为下一轮检测过程设计出新的测试用例。而新的回归测试又会生成新的报告。如此往复，形成了正反馈。
回归测试面临的挑战
自动化回归测试虽然高效且省时，但是它也会面临各种挑战。具体包括如下方面：
成本高
在业务支出方面，软件公司不得不花费大量时间和金钱进行重复性测试。业务方从收益的角度时常会认为：此类回归测试不但复杂，而且并不会产生显著的投资回报。即便是从管理方的角度来看，开展回归测试的理由可能只是为了获取相关的预算。
时间限制
软件企业的业务重点是：开发出高质量的应用程序，并更快地交付给用户。而这就造成了回归测试经常与时间限制相“共生”的状况。为了与规定的时间保持同步，并在最后期限之前完成回归测试的全部过程，测试人员往往需要将精力集中在那些关键性的回归测试环节上，并且选择性地跳过一些细枝末节。那么，在面对此类严峻的挑战时，到底应该跳过哪些不重要的环节，便成了测试人员凭借个人经验进行主观判断的“试验田”。
维护与优化
维护和优化现有的回归测试套件是另一项主要挑战。例如，每当开发人员对其软件代码完成了更新之后，我们就添加、删除或编辑现有的测试用例。而且这些操作往往需要在为回归测试设定截止日期之前就已完成。
进行回归测试的优秀实践
既然已经了解了回归测试所面对的挑战，那么我们该如何通过一些优秀实践来让企业更好地交付高质量的软件呢?
专注于常用路径
常用路径是指：那些在您的应用程序中，最常用到的用例。它们必须包含应用程序中最常见、且最基本的功能。您应该了解自己的核心用户群、以及他们在使用目标应用时，经常用到的程序功能。您的回归测试用例必须确保此类功能能够按照预期完成测试。
定期更新回归包
回归包是各种测试用例的集合。这些测试用例需要在发布新的应用版本、以及执行任何更新操作之前就已完成。为了不再浪费测试人员的时间，去验证应用程序的最新版本是否包含有旧版本的保留功能，回归包中的测试用例应当包含旧版应用的相关规范。当然，后期新增的测试用例也应当被及时更新到回归包之中。
创建一个准进/准出规范
通常，我们在软件开发的生命周期中所遵循的准进/准出规范，同样有助于回归测试的实现。
此处的准入规范是指需要满足的一组固定条件。例如：先执行回归测试，再检查与分析缺陷，然后修复缺陷与错误。而准出规范同样也是一组固定条件，例如：只有确保执行了所有测试，并不再剩下任何未能解决的缺陷与错误后，方可交付软件。
自动化回归测试
由于测试工作往往会涉及到各种重复性的操作，因此使用自动化工具来执行回归测试的好处是业界有目共睹的。同时，测试人员可以通过由自动化回归测试所释放出的资源，去进行更为复杂的测试、以及用例的设计，进而提高企业的投资回报率。
目前，许多企业已开始选用基于云的应用测试平台。此类平台能够模拟数百种设备、以并行的方式，高效地执行各种自动化的回归测试。
总结
领导学专家Robin Sharma曾有句名言：“变革在开始时最为困难，在中间最为混乱，而在结束时最为美好。”这段话恰好体现了回归测试，在应用程序流畅地交付其服务功能时的重要性。如前所述，我们应当克服回归测试中的各种挑战，在测试生命周期的不同阶段，执行不同类型的回归测试。
原文标题：A Brief Overview Of Regression Testing，作者：Bala Murugan
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
