回归测试

不详，欢迎补充

只要代码发生了改变，就可能给带来问题，并且可能会对关联的很多模块甚至整个系统造成影响。所以需要回归测试来重新验证已有的功能，以确认代码的变化是否损害原有的正常功能。

在软件生命周期中的任何一个阶段, 只要发生了代码改变，无论是新功能、缺陷修复、配置改变、代码重构等，都可能带来问题，都需要回归测试。

但考虑成本和效率，不一定每次都需要/来得及做充分的回归测试。

通常在产品迭代发布之前需要全面的回归测试以保证上线质量。

在瀑布开发中，一般是周期性进行回归测试。一般到了项目快要交付的时候，对代码改动的控制极其严格，任何代码改动都要做回归测试。

在敏捷开发中，每个迭代产生的增量都是潜在可交付的，也就都需要通过回归测试。 使用持续集成工具和自动化测试可以更好的支持短周期迭代的频繁的回归测试。

大致步骤

(1) 制定回归测试策略（范围、频率、触发条件等）;
(2) 生成测试用例库;
(3) 识别出软件中有修改的部分；
(4) 基于回归测试策略，从基线测试用例库中，选择适用的测试用例集；
(5) 执行回归测试，生成测试报告；
(6) 别忘了更新基线用例库，添加必要的新用例，并去除或优化旧用例。

回归测试策略

回归测试策略需要兼顾有效性和效率。常用策略包括：
（1）全量回归测试策略

全量回归是选择基线测试用例库中的全部测试用例，这是一种安全系数最高、风险等级最低的策略，但测试成本最高。全量回归测试虽然有效，但不高效。

（2）非全量回归测试策略

随着功能增加，测试用例会越来越多，回归测试的工作量越来越大。在时间和质量等各种条件下，选择非全量回归测试策略，使用部分测试用例进行回归测试。

这种策略的核心思想就是测试用例集的选取和优化，提高测试效率，减少资源投入。

但是这种策略有漏测风险，应该结合基于业务风险驱动，从业务关键度与故障可能性这两个维度的风险分析结果采用相应的测试用例集进行回归测试。

• 基于风险
  从业务风险和技术风险两方面考虑，基于一定的风险标准来从基线测试用例库中选择回归测试集。首先运行最重要的、关键的和可疑的测试，而跳过一些非关键的、优先级别低的或者高稳定的测试用例。

• 基于操作剖面（操作主流程）
  如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。

• 基于代码修改的关联关系
  在进行局部修改时，如果对局部化有足够的信心，可以通过相依性分析修改的影响范围，将回归测试局限于被改变的模块和它的接口、以及关联功能等。回归测试尽可能覆盖受到影响的部分。

• 基于指标
  先确定一个要达成的指标，如系统的性能指标、所修改代码的覆盖率，与修改有关的接口的覆盖率等，基于这些指标选择最小的回归测试用例集。

回归测试用例集

当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。回归测试的用例可以根据回归测试策略从基线测试用例库中选取合适的测试用例组成回归测试集。

为了保证测试用例库中测试用例的有效性，必须对测试用例库进行维护，删除或优化旧用例，追加新功能的新用例。测试用例的维护是一个不间断的过程，需要持续进行。

回归测试集的选择

在软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当大，这使每次回归测试都重新运行完整的测试集变得不切实际，所以需要基于回归测试的策略，选择一个缩减的回归测试集来完成回归测试。回归测试策略考虑业务和技术角度的风险和优先级，使用代码相依性分析等安全的缩减技术，尽量平衡回归测试的有效性和效率两个方面。

可以参考以下方面选择回归测试用例：

• 经常出现缺陷的测试用例

• 用户更容易看到/使用到的功能

• 验证产品核心特性的测试用例

• 经历了更多和最近的变化的功能的测试用例

• 所有集成测试用例

• 所有复杂测试用例

• 边值测试用例

• 成功测试用例

• 失败测试用例

自动化回归测试

由于回归测试是一个反复的过程，并且大量重复相同测试用例，使用自动化的方式是最高效的。

需要从业务流驱动、数据与用例分离、组件技术、统一的平台等多维度出发，进行长期建设。

回归测试常用工具：

• Selenium：是用于自动化Web应用程序的，可用于基于浏览器的回归测试。

• QTP（Quick Test Professional)：是一个自动化功能和回归测试用例的自动化软件。

• Robot Framework，等等
  欢迎大家补充

1. 每次代码提交都要进行回归测试吗？
   不一定，回归测试的触发条件和测试范围需要根据测试策略来设定。
   使用敏捷开发的持续集成和每日构建实践，可以支持更频繁的自动化回归测试，又不会增加太多成本。

2 . 缺陷修复后的重新测试(Bug fix验证) 和 回归测试的区别？
重新测试是针对缺陷修的，即当开发修复了缺陷后，需要再次测试这处功能或错误以确保代码确实已修复。
重新测试的范围是在缺陷本身。
而回归测试并不用于验证缺陷修复。回归测试虽然也会被缺陷修复所触发，但范围是更大更全面的，以确保修所改变的代码不会影响软件的其他部分。

2. Regression-Testing

3. 知乎 - 什么是回归测试

4. 知乎 - 大佬眼中的回归测试

使用gitlab持续集成，每日构建，每天晚上执行主流程的自动化回归测试。
版本发布前执行更全面的回归测试。

欢迎补充更多案例。