专栏文章 敏捷回归测试

FunTester · August 01, 2020 · 30 hits

当今世界敏捷大行其道,软件迭代越来越快和发版隔间越来越小,很多公司团队都提倡小步快跑的软件开发模式。其中软件测试时间窗口不断减少,测试团队面临着比以往任何时候都面临的更多挑战,为建立可靠的连续测试策略,以适应需求变化,响应生产环境的反馈等。一些团队利用测试数据分析,而另一些团队则使用机器学习和其他先进技术来优化其DevOps管道。

本文将重点聊一聊在敏捷测试DevOps环境中制定回回归测试策略的主题。

什么是回归测试?

参考:43种常见软件测试分类

回归测试被定义为一种软件测试类型,以确认最近的程序或代码更改未对现有功能造成不利影响。 从这个定义来看,很明显,这样的测试类型应该集中在通过预定义的计划、触发器或按需执行的全部或部分测试场景中。

如果根据最佳实践正确开发了回归测试并涵盖了足够的功能区域,则它们带来的价值就很高,并且这种测试模型能够发现回归错误,代码更改的副作用或其他意外的问题。

通常,执行回归测试的常见触发因素包括:

  • 由于添加了新功能或需求和业务流程发生了更改
  • 重大缺陷修复(功能性或非功能性),需要质量保证
  • 连续回归测试(每天/每周)以降低风险

敏捷战略中的回归测试

构建测测试自动化是一项具有挑战性的任务,但却是持续测试和回归测试的关键推动力。

如上所述,要确保回归套件具有连续的高价值,必须做好前期准备,并且渐进式地构建它,并专注于健壮的测试方案,高覆盖率和尽可能低的测试维护成本。如果不考虑这些考虑因素,则可能会导致整个测试流程延迟劲儿导致发布计划的失败。

在考虑在敏捷环境中进行回归测试的策略时,需要了解这种环境会不断变化。添加了新平台、功能、缺陷修复等,这意味着回归测试应适应此动态环境以继续有效。

测试工程管理需要专注于回归套件的持续维护并确定以下内容:

  • 哪些测试用例已经过验证,需要包含在回归套件中,哪些应该排除在外?
  • 回归和子集回归套件的执行时间计划是什么?(每天,每周,每次提交代码,还是其他)?
  • 哪些回归测试是从CI引擎执行的,哪些是从CI之外的其他调度程序执行的?
  • 哪些事件触发了回归套件的维护和改进?
  • 完成回归测试的时间窗口是什么?是否有足够的平台/资源来适应这些时间限制?
  • 不断分析测试的价值,脆弱性等等。

敏捷回归测试建议和基础

在阐明了有关回归测试的一些基本战略考虑和见解之后,以下是一些最佳实践和建议以供参考:

  • 将选择性回归测试与完整回归测试周期区分开来。它们的范围,平台覆盖范围,时间窗口和目标各不相同。
  • 不断维护回归套件,以包括高价值的功能和非功能方案。
  • 请关注测试用例老化问题,并确保将优先级高、价值高的测试用例留在套件中。
  • 回归套件是尽量选择稳定的方案,难以自动化和不稳定自动化用例不应该包含在套件中。
  • 敏捷迫使功能、要求不断变化(这也意味着对测试套件的不断更改)具有适当的流程来适应修改。
  • 确保回归套件报告具有完全的可见性,并具有详细的视图,以评估测试结果和发版风险。
  • 考虑在回归套件中对测试方案进行评分,以便正确地确定执行的优先级、执行时间、执行频率等。

充分利用回归测试

高度稳定的测试自动化可实现连续测试,回归测试也越来越依赖于强大而值得信赖的测试自动化。为了确保从回归测试的投入中获得价值,建议优先制定适合本团队的可靠的测试策略,并随着产品的发展对其进行调整。确保回归测试活动的参与方之间正确沟通,并获得总体满意的结果以及避免上线事故的发生。


  • 公众号FunTester首发,更多原创文章:FunTester430+原创文章,欢迎关注、交流,禁止第三方擅自转载。

热文精选

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
No Reply at the moment.
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up