【无标题】

最近公司的新产品经历了几个版本的开发，终于初具模型，测试团队决定近期做一次回归测试。

公司一直是敏捷开发模式，以需求卡进行一次次迭代，几百张需求卡如何界定回归测试范围也是伤透了脑筋，经过一番讨论，确定了以下方案。

回归测试的范围界定综合考量点:

1、本次需求变更的影响范围

需要确定本次需求变更直接影响到的功能模块和代码，这些部分必须纳入回归测试范围。此外，也需要考虑一级或二级跨模块和接口的影响。

2、高风险的功能点

一些业务关键、涉及金融等安全性要求高的功能模块，即使未直接涉及需求变更，也需要高频回归。这些模块的回归测试范围需要不断扩大。

3、近期发现的高危缺陷模块

对近期测试中发现高危缺陷的功能模块，回归测试的覆盖率也需要提高，这类缺陷后续修复可能导致新的问题，必须在后续版本中进行重点回归。  

4、用户访问量大的功能点

一些用户访问量大、业务关键的功能模块，其质量变化会立即影响大量用户,这也是回归测试的重点区域之一。 

5、上一版本未完全覆盖的功能点

上一版本测试未覆盖的功能点，有可能存在潜在风险，这类功能点也应纳入本次回归测试的考量范围。

除上述主要考量外，还需要结合产品的重要程度、故障影响程度等其它因素综合判断回归测试的范围。

回归测试通常在一下几个阶段进行：需求变更后、版本发布/上线前，后续版本的迭代、缺陷修复后，或者其他特定场景（如重要活动前）。

在不同的回归测试中，测试覆盖率和测试深度会有差异。但关键和高风险的功能点必须在所有的回归测试中涉及，这也是确保产品质量的关键。

实战案例

光学理论是没用的，要学会跟着一起敲，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战案例来学习。

如果对你有帮助的话，点个赞收个藏，给作者一个鼓励。也方便你下次能够快速查找。

如有不懂还要咨询下方小卡片，博主也希望和志同道合的测试人员一起学习进步

在适当的年龄，选择适当的岗位，尽量去发挥好自己的优势。

我的自动化测试开发之路，一路走来都离不每个阶段的计划，因为自己喜欢规划和总结，

自动化测试视频教程、学习笔记领取传送门！！！