【51CTO.com快译】有研究表明：在安装了新的应用程序之后，只有四分之一的用户会在次日回到该应用。而大多数用户在首次使用之后就直接将其卸载掉了。造成此类留存率低下的主要原因，便是测试人员对于应用程序的测试不足。由于他们对于重复测试毫无兴趣，因此尽管深知回归测试的重要性，但是他们仍然会在软件项目中选择性地忽略掉测试的环节。
什么是回归测试
简单而言，回归测试可以被定义为：在对计算机程序进行了一些修改之后，对其进行重新测试，以确保所实施的更改不会对现有代码产生不利的影响。可以说，回归测试提高了测试人员尽早检测到那些由更改所引入的程序缺陷，同时也降低了解决缺陷的成本。
可见，回归测试既能够确保软件的正常运行，又能保证软件开发者将产品的最佳版本投入市场。但是，光靠人工来创建和维护那些几乎无休止的回归测试是根本不可能的。这就是为什么大多数软件企业会采用自动化的回归测试方式，以节省时间和精力的原因。
回归测试的类型
一般而言，对于不同的测试阶段，我们会采用不同类型的回归测试。下面让我们来了解一下回归测试的类型： 
    单元测试(Unit Testing)：在完成了对于某个单元的代码变更后，需要测试人员重新测试先前已经通过了的单元测试。通常，我们可以在代码中设置自动化单元测试()的入口，以提高测试的效率。 渐进式测试(Progressive Testing)：当开发人员对软件及应用程序的相关规范进行了更改，并且重新设计了测试用例后，就需要有效地进行此类渐进式测试。 选择性测试(Selective Testing)：为了减少重新测试的成本和工作量，测试人员会采用当前测试用例中的一部分。不过，当它所涵盖的程序实体发生变化时，则必须重新运行相应的单元测试。 全盘重新测试(Retest-All Testing)：随着时间的推移，就算未对程序代码进行修改，也要重复测试所有的用例。当然，如果应用程序的改动较小，此举则会非常耗时。 完全测试(Complete Testing)：在对现有的代码进行了多次修改之后，我们需要有效地进行完全测试。此举不但是为了识别程序中的潜在错误，而且在完成之后，我们便可以将最终的软件直接提交给用户了。 
如何选择回归测试计划
因此，每当软件应用程序发生变更、或是有新的版本需要发布之前，开发人员都会选择性地将上述测试类型作为回归测试过程的一部分予以执行。  首先，开发人员执行单元级的回归测试，以验证其修改代码的正确性。创建此类新的测试，是为了应尽可能多地覆盖那些新增的软件功能。 然后，开发人员通过将修改后的代码合并集成到现有软件中，以创建新的自动化单元测试(AUT)版本。 接着，开发人员执行冒烟测试(smoke tests)，以确保前面步骤所产生的构建(build)是正确可行的。 
 
上述测试都可以交由诸如Jenkins之类的持续集成服务，来自动执行。一旦确认了构建的正确性，我们就需要通过完整性测试，来确认在扫清了所有已知缺陷的基础上，新增的功能是否能够按照预期运行。
接着，我们可以通过执行集成测试，来验证应用程序的各个单元彼此是否能够顺畅通信，以及是否与后端的服务(例如数据库)进行交互。
下一步，我们需要根据代码的大小和涉及到的范围，来进行部分或全部的回归测试。 
 
在测试过程中所发现的代码缺陷，会以报告的形式提交给开发团队。通过分析、找到解决方案之后，他们也需要为下一轮检测过程设计出新的测试用例。而新的回归测试又会生成新的报告。如此往复，形成了正反馈。
回归测试面临的挑战
自动化回归测试虽然高效且省时，但是它也会面临各种挑战。具体包括如下方面：
成本高
在业务支出方面，软件公司不得不花费大量时间和金钱进行重复性测试。业务方从收益的角度时常会认为：此类回归测试不但复杂，而且并不会