回归测试是在软件发生修改（如修复 bug、新增功能、优化代码）后，**重新执行原有测试用例，验证修改是否引入新缺陷或导致已有功能退化**的测试活动。 其核心目标是保障软件在变更后，原有正常功能依然稳定可用，避免 “修复一个问题，带出多个新问题” 的情况。 ### 回归测试的核心特点 1. **针对性强**：测试范围聚焦于与 “修改内容” 相关的功能模块，而非对全量功能无差别测试。 2. **依赖历史用例**：主要复用之前已设计好的测试用例，无需大量新增用例，降低测试成本。 3. **重复性高**：软件迭代过程中会多次修改，回归测试需伴随每次修改重复执行，常通过自动化工具提升效率。 ### 回归测试的常见触发场景 - **bug 修复后**：验证 bug 是否真正解决，同时确认修复操作未影响其他关联功能。 - **新增功能后**：检查新增功能是否与原有功能冲突，确保原有功能正常运行。 - **版本迭代前**：在软件发布新版本前，对核心功能进行回归测试，保障整体稳定性。 - **环境变更后**：如服务器升级、数据库版本更新等，验证软件在新环境下原有功能是否兼容。 ### 回归测试执行流程 1. **确定回归测试范围** - 根据变更内容（新增功能、Bug 修复、优化代码）分析可能受影响的模块。 - 结合需求文档、代码改动记录、风险评估，确定测试范围（核心功能优先）。 2. **选择回归测试用例** - 从测试用例库中筛选与变更相关的用例，避免全量回归造成资源浪费。 - 对重要功能可保留全量用例，对低风险功能可选择抽样用例。 3. **准备测试环境与数据** - 搭建与生产环境尽量一致的测试环境（硬件、软件版本、配置）。 - 准备真实或模拟的测试数据，确保覆盖不同场景。 4. **执行回归测试** - 按优先级执行测试用例（先核心功能，再次要功能）。 - 记录测试过程、输入数据、实际输出与预期结果。 5. **缺陷分析与回归验证** - 若发现新缺陷，记录 Bug 并提交开发修复。 - 修复后再次进行回归测试，确认 Bug 已解决且无新问题。 6. **回归测试总结** - 汇总测试结果、缺陷数量与严重程度。 - 分析本次回归测试的有效性与改进点。 ### 回归测试注意事项 - **回归测试不是一次性活动**：每次代码变更后都应执行。 - **测试用例要维护更新**：随着功能迭代，过时的用例要删除或修改。 - **优先自动化**：重复性高的回归测试适合用自动化工具执行，提升效率。 - **关注关联模块**：修改一个模块可能影响多个依赖模块，需全面评估范围。 - **保留历史记录**：记录每次回归测试的结果，便于后续追溯和分析。