| 一、适用对象 |
| 测试工程师 |
| 二、主题方向 |
| 此处的回归测试，为计划的第二轮测试。验证开发工程师在修复一个或多个已知缺陷后，系统的其他功能是否受到了影响。 在验证bug时，回归测试可以确保之前正常工作的功能仍然正常，并且已修复的bug没有引入新的问题。回归测试通常包括运行之前的测试用例，以确保系统的稳定性和一致性。 此文论回归测试成本、质量、时间三者之间的平衡。即在测试用例的范围增加，成本上升，时间上升，质量上升的背景下。建立评估体系，确定修复bug的影响范围，评估需要二轮执行的测试用例，控制二轮成本与时间。 |
| 三、案例还原 |
| 一、未完全回归质量过低案例 项目名称：* 计划名称：*。 产生后果：办结前评审发现多个漏出缺陷。 原因分析：，经溯源是修复缺陷后新增问题，非一轮漏出测试。测试人员经过多轮测试后只进行了缺陷验证，因时间限制，未进行完全回归。时间要求紧张，原计划日期：8月27日-9月3日，实际计划日期：9月20日。由于日期紧张，测试人员未进行完全回归测试。 经验总结：只验证bug不可取，优先保障测试质量，与产品沟通新的完成时间，并在可预见周期问题之前发出预警，及时准备应对方案。
项目名称：* 计划名称：* 产生后果：预算使用超支45%。 原因分析：评估时过于理想化，二轮测试范围大于一轮，多次补充更新后关联流程正向验证，执行轮次过多。 经验总结：二轮验证通过用例，更新后可尝试不再执行，根据每轮次新增缺陷，评估缺陷聚集模块，重点测试。
项目名称：* 计划名称：* 产生后果：成本在评估范围内，评审无漏出缺陷，发版无漏出反馈。 原因分析：评估时预估了需求变更可能导致的溢出，控制了轮次与测试范围。 经验总结：拆分测试范围的套件，区分出独立单元，测试通过的独立单元不再重复测试。与产品经理确认质量要求，确认套件执行轮次。 |
| 四、通用建议 |
| 完全回归需占用大量测试时间，不回归测试造成缺陷漏出，在有限成本与时间要求下，测试人员评估剩余时间与当前缺陷验证情况，可用规划套件的方式确定回归测试范围。如果时间实在不够，需要与产品线沟通完成时间，或加班完成，不可因时间紧迫而降低测试质量或简化测试流程，测试质量是第一要求。 |
| 回归范围 |
回归分类 |
特点 |
优点 |
缺点 |
适用范围 |
| 完全回归 |
完全重复法 |
每次回归测试都要执行全部测试用例 |
回归测试充分，覆盖面广，不容遗漏 |
工作量大，时间长，成本高 |
时间充裕且测试资源较充分时，第一次和最后一次做回归测试的时候用这种方法 |
| 选择性回归 |
覆盖修改法 |
每次回归测试时只执行发现错误的用例 |
时间最短，成本最低，简单效率高 |
回归测试不充分，漏洞较多 |
时间较紧且人力资源不足时，中间版本的测试轮次可以使用，关联度比较小的模块和功能 |
| 周边影响法（常规推荐） |
每次回归除了执行发现bug的用例外，还要执行与其相关的用例（同一套件） |
在考虑了测试成本的基础上有效提高了回归测试的质量 效率 |
很难确定影响的周边范围，相关用例定位较困难 |
适合于全局数据结构被修改或公共模块被修改，或核心算法业务被修改时，公用的模块，关系、关联复杂的模块 |
|
| 指标达成法（常规推荐） |
每次回归测试达到规定预期指标（系统实际使用情况）就可以停止测试了 |
所有的测试都可度量 |
1指标生成需要很长的周期，很多的项目去累计经验 2要有比较稳定的团队这个指标才有意义 |
成熟度较高的测试团队应用于指标达成法 |
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/te-hg/8583.html