回归测试范围界定

一、适用对象

测试工程师

二、主题方向

此处的回归测试，为计划的第二轮测试。验证开发工程师在修复一个或多个已知缺陷后，系统的其他功能是否受到了影响。 在验证bug时，回归测试可以确保之前正常工作的功能仍然正常，并且已修复的bug没有引入新的问题。回归测试通常包括运行之前的测试用例，以确保系统的稳定性和一致性。 此文论回归测试成本、质量、时间三者之间的平衡。即在测试用例的范围增加，成本上升，时间上升，质量上升的背景下。建立评估体系，确定修复bug的影响范围，评估需要二轮执行的测试用例，控制二轮成本与时间。

三、案例还原

一、未完全回归质量过低案例 项目名称：*** 计划名称：***。 产生后果：办结前评审发现多个漏出缺陷。 原因分析：，经溯源是修复缺陷后新增问题，非一轮漏出测试。测试人员经过多轮测试后只进行了缺陷验证，因时间限制，未进行完全回归。时间要求紧张，原计划日期：8月27日-9月3日，实际计划日期：9月20日。由于日期紧张，测试人员未进行完全回归测试。 经验总结：只验证bug不可取，优先保障测试质量，与产品沟通新的完成时间，并在可预见周期问题之前发出预警，及时准备应对方案。 完全回归成本过高案例 项目名称：*** 计划名称：*** 产生后果：预算使用超支45%。 原因分析：评估时过于理想化，二轮测试范围大于一轮，多次补充更新后关联流程正向验证，执行轮次过多。 经验总结：二轮验证通过用例，更新后可尝试不再执行，根据每轮次新增缺陷，评估缺陷聚集模块，重点测试。 选择回归范围中和案例 项目名称：*** 计划名称：*** 产生后果：成本在评估范围内，评审无漏出缺陷，发版无漏出反馈。 原因分析：评估时预估了需求变更可能导致的溢出，控制了轮次与测试范围。 经验总结：拆分测试范围的套件，区分出独立单元，测试通过的独立单元不再重复测试。与产品经理确认质量要求，确认套件执行轮次。

四、通用建议

完全回归需占用大量测试时间，不回归测试造成缺陷漏出，在有限成本与时间要求下，测试人员评估剩余时间与当前缺陷验证情况，可用规划套件的方式确定回归测试范围。如果时间实在不够，需要与产品线沟通完成时间，或加班完成，不可因时间紧迫而降低测试质量或简化测试流程，测试质量是第一要求。

回归范围	回归分类	特点	优点	缺点	适用范围
完全回归	完全重复法	每次回归测试都要执行全部测试用例	回归测试充分，覆盖面广，不容遗漏	工作量大，时间长，成本高	时间充裕且测试资源较充分时，第一次和最后一次做回归测试的时候用这种方法
选择性回归	覆盖修改法	每次回归测试时只执行发现错误的用例	时间最短，成本最低，简单效率高	回归测试不充分，漏洞较多	时间较紧且人力资源不足时，中间版本的测试轮次可以使用，关联度比较小的模块和功能
	周边影响法（常规推荐）	每次回归除了执行发现bug的用例外，还要执行与其相关的用例（同一套件）	在考虑了测试成本的基础上有效提高了回归测试的质量 效率	很难确定影响的周边范围，相关用例定位较困难	适合于全局数据结构被修改或公共模块被修改，或核心算法业务被修改时，公用的模块，关系、关联复杂的模块
	指标达成法（常规推荐）	每次回归测试达到规定预期指标（系统实际使用情况）就可以停止测试了	所有的测试都可度量	1指标生成需要很长的周期，很多的项目去累计经验 2要有比较稳定的团队这个指标才有意义	成熟度较高的测试团队应用于指标达成法