高效快速的回归测试，如何选择测试用例？

在软件测试工作流程中，回归测试的占比还是比较繁重的，几乎在软件开发的各个阶段都需要进行很多次的回归测试。特别是在今天以敏捷开发、快速迭代开发中，不断出现的新版本发布，使得回归测试工作的进行更加频繁。所以对于回归测试策略的选择将对测试的过程和效率具有很大的参考价值。

回归测试做什么？

回归测试是指对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例，它的目的：一是为了验证之前版本产生的所有缺陷已全部被修复；二是确认修复这些缺陷没有引发新的缺陷。回归测试的成本相对来说比较高，所以很多情况下公司都会选择以自动化方式来完成回归测试。而且回归测试的重要关注点，还是要以关键性模组为核心来进行。

回归测试主要参考依据测试用例，所以测试用例库的不断更新维护势在必行。软件更改可能导致软件问题；

因此，每次软件变更时，都要重新测试已有的功能，以确定修改是否达到预期目的，并检查修改是否违反了原有的正常功能。而且系统相对来说比较成熟，回归测试的任务量就越大。这会给测试工作带来很多挑战。

在实际工作中，往往是追求完整性，希望测试的时候覆盖尽可能广泛，避免漏测。回归测试不仅仅针对系统测试，还贯穿于软件生命周期，再进行有效的回归测试可以从这几个方面进行考虑，其实最有效的回归测试方法基于测试库，相关的测试人员创建的测试库可以在程序的新版本创建时运行这些用例。

只有从根本上有效规避风险，才能有效进行回归测试：

在进行单元测试阶段加强回归测试，引入代码审查、自动化测试等手段；

在集成测试和系统测试时，加强测试用例的完善与审核和回归测试用例的选择；

具体选择可以参考以下几点：

在设计和编写测试用例的时候设置优先级，比如高、中、低，方便自动化测试或者未来的策略选择；在配置管理中，引入测试用例基线管理操作，有效管理测试用例；

定期维护测试用例，及时进行增删改查当前状态；

回归测试时需要增加效率和范围，通常的测试策略可以从这几方面来考虑：

从风险角度选择测试：当开发人员修改程序的一部分时，它可能已经处理了问题，所以主要测试修改模块及其相关接口，但也可能有未触及的根本原因，因此需要对周边程序和相互依赖部分进行测试；

错误本身可能已修复，但修复也可能导致其他错误，因此有必要为每个已修复的错误设计回归测试。基于综合测试策略：如果有足够的时间和资源，可以进行综合测试，将回归错误的风险最低，但测试成本最高，需要斟酌选择。

学习安排上

如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

视频文档获取方式：

这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片进群即可自行领取。