敏捷提供了众多优势，例如更快的上市速度，更快的ROI，更快的客户支持，降低的风险，持续的改进等，随之而来的还有一些非常困难的挑战。在这些主要问题之一中，令人头痛的是在sprint开发和迭代测试之间保持适当的平衡，进行精确的敏捷开发和回归测试。
敏捷开发是一个非常快速且动态的开发过程。周期很短，开发人员在较短时间内推出了许多功能。同样的，测试周期也很短，以跟上项目的发版周期。但实际上大多数时候并非如此。开发是针对一项功能完成的，但是必须对所有新功能和相关的旧功能进行测试。对于每个新版本，都需要确保对代码的新增或改进不会损害现有功能的功能。
但是经过几个大周期后，这些重复测试变得无聊且耗时，并且假设它们必须工作正常，您可能会错过一些发现其他错误的机会。为了避免这种情况，需要通过从开发周期开始就创建适当的回归测试策略来制定“逃脱”计划，并且在每次出现Sprint时都需要修改该策略。
建立回归测试策略之前
在建立该回归测试策略之前，事先收集一些信息。
- 收集所有应执行的测试用例
- 改进永不停止。找出可以在测试案例中实现的所有改进。
- 估计执行测试用例的时间
- 评估什么都可以自动化以及如何自动化？
建立回归测试策略
在敏捷开发中执行回归测试的最大挑战是保持敏捷开发与回归测试之间的平衡。因此，我们需要遵循一些快速有效的方法，以便在不影响质量的情况下执行回归测试。
自动化回归测试
快速跟踪回归测试的最佳方法之一是使回归测试的某些部分自动化。我们可以创建一个回归测试脚本，并应在每次更新时对该脚本进行修改和审查，以确保其正常工作。自动化测试脚本应涵盖所有可能的测试用例，并在将自动化脚本结果移至操作项之前对其进行验证。
确定测试范围
作为一名测试人员，我们知道哪些开发可以导致构建中的哪些更改。换句话说，由于已有代码中的新构建，我们可以掌握引入错误的所有可能性以及范围。但是，这并不意味着您完全依靠猜测。
示例：您正在测试一个电子商务网站，并且在支付网关中进行了修改。现在，您有两种方法，一种是在每次提交付款网关时都要测试整个产品，每半小时一次，另一种方法是找出容易出现的问题。在这种情况下，最容易出现的领域是结帐流程和付款以及电子邮件确认，文本确认，OTP或密码验证等。一旦设置了此付款修复程序，您就可以执行一轮端到端回归测试。
确保您弄清楚聪明工作和辛苦工作之间的区别。尽管辛勤工作总能带来更好的结果，但是在可以通过聪明的工作解决目标的地方，而这些地方往往不是辛勤工作能够解决的。
测试用例优先级
优先级排序可帮助您根据问题的严重性和代码中的最新更改来管理测试用例。严重的错误应以最高优先级进行测试，然后是较低严重的错误。这样，您就可以测试尽可能多的错误，而不会错过高优先级的错误。
获得最高优先级错误的可能性为10％，其次为获得中等优先级错误的可能性为30％，获得优先级较低的bug的可能性为60％。我们需要按顺序处理从最高优先级到最低优先级的所有错误。
敏捷环境中回归测试
当回归测试策略中实现，就能够执行回归测试并保持敏捷开发的步伐。完美的回归测试结果将帮助用户保持对您产品的信任，以便为他们提供更好的产品。
- 郑重声明：文章首发于公众号“FunTester”，禁止第三方（腾讯云除外）转载、发表。
