软件生命周期中，如何快速完成回归测试的策略？

介绍

在软件生命周期中，软件经常发生变化，软件开发人员任何代码改动都会有引入故障的风险）。加我VX：atstudy-js 回复“测试”，进入 自动化测试学习交流群~~

为了消除或减小这种风险，在软件迭代开发模式下，回归测试扮演着重要的角色：它能够帮助测试人员验证新增的功能或故障修复后的程序是否满足期望。

目前，常见的具有代表性的回归测试策略主要有两种：

一是重试所有策略，即选择所有已有用例进行测试；

二是最小选择策略，即选取具有代表性的测试用例进行测试。

重试所有策略最大限度地扩大了测试覆盖范围，可以保证在程序修改后原来正确工作的代码不会产生新的错误。但是，随着软件功能的丰富、开发代码的增加，测试用例也随之增多。

当测试用例积累非常多时（比如成千上万条），此时一个新功能开发或故障修复完成后进行回归测试，则会对时间和资源的需求量提出巨大的要求。由于测试资源和时间的限制，如果运行全部存量测试用例和开发新的测试用例进行回归测试，显得不太可取。

最小选择策略可以缩减测试用例集的大小，测试成本较小，但是检错代码错误的能力相对于重试所有策略则削弱很多。最小选择策略的检测错误能力不够完善，但其低成本优越性，使得无数人员争相研究和推进，它已经成为回归测试中最常用的测试策略。

回归上述提及的回归测试策略不难发现，在回归测试活动中，测试用例的选择往往着重于已有测试用例的选择，对于新增功能或功能变动引起的新增测试用例并未提及，而这一部分在回归测试中也占据着重要地位。因此，在有限的时间和资源条件下，如何筛选存量测试用例和设计新增用例，快速地完成回归测试成为了大多数测试人员思考的问题。

本文旨在提出一种快速回归测试用例选择方法，帮助测试人员能够快速地完成回归测试。

该策略主要涉及两个环节：

·存量测试用例的筛选

· 新增用例的设计方法

在存量测试用例筛选环节引入相关性判断，考虑测试用例与功能的相关性、测试用例执行通过率、测试用例的稳定性、测试用例的发现的故障数、测试用例的自动化率等几个方面。

在新增用例设计环节，引入探索式测试方法（包括局部探索式方法和全局探索式方法）设计新增用例。

相关工作

回归测试可被分为两类：递进型回归测试和修正型回归测试。

递进型回归测试是指对原有测试用例进行修改，以适配测试修改后的程序（如新需求引入导致的模块或功能增删）。

修正型回归测试与递进型回归测试相反，主要特点在于原有测试用例不做任何修改。修正型回归测试主要用于修正程序设计错误或缺陷修复后的测试，其目的在于验证程序严格按照测试用例的输入输出描述运行。

在软件开发周期内，递进型回归测试和修正型回归测试活动往往是一起进行的。随着软件开发的深入、功能的不断增多，测试用例数量也会不断增大。此时，在成百上千或上万条测试用例的情况下，在某个开发周期内进行递进型回归测试和修正型回归测试，存量测试用例的选择、新功能测试用例的设计和开发都会成为有限时间和资源下快速完成回归测试的瓶颈。

传统的全部运行存量测试用例进行回归测试的方法，虽然可以保证测试的高覆盖率，但是会消耗大量的时间和资源，尤其是手工用例居多的时候。鉴于此种情形，如何使用最小选择策略去除回归测试用例冗余性，获取代表性用例进行回归测试，成为了很多学者探讨的问题。

最小测试用例集的选择方法有如：基于数据挖掘技术的测试用例选择方法、基于优先级排序的测试用例选择方法、基于启发式模型的测试用例选择方法等等。这些技术为回归测试存量测试用例的选择提供了有效的指导方法，但是它们有的仅是从设计过程选择用例或从执行结果选择用例，未充分考量选取测试用例的全面性。且针对迭代周期内当新增功能或代码变更时，并未提及如何设计新增用例并将新增用例纳入回归测试范围。

本文提出的快速回归测试策略重点在于存量测试用例的选取和新增测试用例的设计环节。

考虑到回归测试类型的差异性：

针对递进型回归测试，测试用例主要为新增测试用例，新增测试用例的设计方法采用探索性测试方法；

针对修正型回归测试，测试用例包含存量测用例和新增测试用例。

在存量测试用例选择时，从用例设计过程和执行结果两个方面出发进行联合筛选。

从用例设计过程出发，考量用例与功能的相关性（直接相关、间接相关），选择相关性强的用例；

从用例执行结果出发，选择稳定性差、通过率低、故障率低和自动化率低的测试用例。 

……

由于作者版权要求，仅展示文章的一部分，如需阅读完整版文章，可以扫描下方二维码获取。

添加微信：atstudy-js  或者扫描下方二维码，备注“博客”邀请你进入Python自动化测试学习交流群~