当今世界敏捷大行其道，软件迭代越来越快和发版隔间越来越小，很多公司团队都提倡小步快跑的软件开发模式。其中软件测试时间窗口不断减少，测试团队面临着比以往任何时候都面临的更多挑战，为建立可靠的连续测试策略，以适应需求变化，响应生产环境的反馈等。一些团队利用测试数据分析，而另一些团队则使用机器学习和其他先进技术来优化其DevOps管道。
本文将重点聊一聊在敏捷测试和DevOps环境中制定回回归测试策略的主题。
什么是回归测试？
参考：43种常见软件测试分类
回归测试被定义为一种软件测试类型，以确认最近的程序或代码更改未对现有功能造成不利影响。 从这个定义来看，很明显，这样的测试类型应该集中在通过预定义的计划、触发器或按需执行的全部或部分测试场景中。
如果根据最佳实践正确开发了回归测试并涵盖了足够的功能区域，则它们带来的价值就很高，并且这种测试模型能够发现回归错误，代码更改的副作用或其他意外的问题。
通常，执行回归测试的常见触发因素包括：
- 由于添加了新功能或需求和业务流程发生了更改
- 重大缺陷修复（功能性或非功能性），需要质量保证
- 连续回归测试（每天/每周）以降低风险
敏捷战略中的回归测试
构建测测试自动化是一项具有挑战性的任务，但却是持续测试和回归测试的关键推动力。
如上所述，要确保回归套件具有连续的高价值，必须做好前期准备，并且渐进式地构建它，并专注于健壮的测试方案，高覆盖率和尽可能低的测试维护成本。如果不考虑这些考虑因素，则可能会导致整个测试流程延迟劲儿导致发布计划的失败。
在考虑在敏捷环境中进行回归测试的策略时，需要了解这种环境会不断变化。添加了新平台、功能、缺陷修复等，这意味着回归测试应适应此动态环境以继续有效。
测试工程管理需要专注于回归套件的持续维护并确定以下内容：
- 哪些测试用例已经过验证，需要包含在回归套件中，哪些应该排除在外？
- 回归和子集回归套件的执行时间计划是什么？（每天，每周，每次提交代码，还是其他）？
- 哪些回归测试是从
CI引擎执行的，哪些是从CI之外的其他调度程序执行的？ - 哪些事件触发了回归套件的维护和改进？
- 完成回归测试的时间窗口是什么？是否有足够的平台/资源来适应这些时间限制？
- 不断分析测试的价值，脆弱性等等。
敏捷回归测试建议和基础
在阐明了有关回归测试的一些基本战略考虑和见解之后，以下是一些最佳实践和建议以供参考：
- 将选择性回归测试与完整回归测试周期区分开来。它们的范围，平台覆盖范围，时间窗口和目标各不相同。
- 不断维护回归套件，以包括高价值的功能和非功能方案。
- 请关注测试用例老化问题，并确保将优先级高、价值高的测试用例留在套件中。
- 回归套件是尽量选择稳定的方案，难以自动化和不稳定自动化用例不应该包含在套件中。
- 敏捷迫使功能、要求不断变化（这也意味着对测试套件的不断更改）具有适当的流程来适应修改。
- 确保回归套件报告具有完全的可见性，并具有详细的视图，以评估测试结果和发版风险。
- 考虑在回归套件中对测试方案进行评分，以便正确地确定执行的优先级、执行时间、执行频率等。
充分利用回归测试
高度稳定的测试自动化可实现连续测试，回归测试也越来越依赖于强大而值得信赖的测试自动化。为了确保从回归测试的投入中获得价值，建议优先制定适合本团队的可靠的测试策略，并随着产品的发展对其进行调整。确保回归测试活动的参与方之间正确沟通，并获得总体满意的结果以及避免上线事故的发生。
