最近公司的新产品经历了几个版本的开发，终于初具模型，测试团队决定近期做一次回归测试。
公司一直是敏捷开发模式，以需求卡进行一次次迭代，几百张需求卡如何界定回归测试范围也是伤透了脑筋，经过一番讨论，确定了以下方案。
回归测试的范围界定综合考量点:
1、本次需求变更的影响范围
需要确定本次需求变更直接影响到的功能模块和代码，这些部分必须纳入回归测试范围。此外，也需要考虑一级或二级跨模块和接口的影响。
2、高风险的功能点
一些业务关键、涉及金融等安全性要求高的功能模块，即使未直接涉及需求变更，也需要高频回归。这些模块的回归测试范围需要不断扩大。
3、近期发现的高危缺陷模块
对近期测试中发现高危缺陷的功能模块，回归测试的覆盖率也需要提高，这类缺陷后续修复可能导致新的问题，必须在后续版本中进行重点回归。
4、用户访问量大的功能点
一些用户访问量大、业务关键的功能模块，其质量变化会立即影响大量用户,这也是回归测试的重点区域之一。
5、上一版本未完全覆盖的功能点
上一版本测试未覆盖的功能点，有可能存在潜在风险，这类功能点也应纳入本次回归测试的考量范围。
除上述主要考量外，还需要结合产品的重要程度、故障影响程度等其它因素综合判断回归测试的范围。
回归测试通常在一下几个阶段进行：需求变更后、版本发布/上线前，后续版本的迭代、缺陷修复后，或者其他特定场景（如重要活动前）。
在不同的回归测试中，测试覆盖率和测试深度会有差异。但关键和高风险的功能点必须在所有的回归测试中涉及，这也是确保产品质量的关键。