优化回归测试

我对每个版本运行的回归测试套件是否太大了？

是否应该减少回归测试周期以缩短产品推向市场的时间？

是否即使运行完整的回归周期，我仍能发现漏过的测试？

我的回归测试套件是否完备？

是否值得在确定回归测试套件的测试上花时间？

如果上述任何一个问题困扰了你，那么下面给出的说明可能会帮助到你。

企业在每次发表新的版本之前都要花费数百万美元进行回归测试。采用了不同的过程和方法来得到回归测试套件。通过各种统计方法可能是正确的方法来找到回归测试集，但在没有使用统计方法的情况下，如果我们想要拿出的最佳的测试集，我们应该怎么办？

在我们回答上面提出的问题之前，先让我们来看看回归测试是如何定义的？

随着对不同的行业，如银行与金融，高科技，零售，能源，电信，社会化媒体和医疗保健的测试，以及工复杂多样的项目经验，我们找到了以下几类方法来寻找回归测试套件。

1.重要的功能测试：将所有重要的测试案例和功能添加到回归测试套件中。那些不被添加到该套件的测试就认为它们是不重要的。这种做法可能会导致在客户使用方面的问题。通过这个方法，产品上市的时间需求并不高。

2.所有功能测试：这是一种穷举的测试，但会带来一些严重的问题。随着产品的发展，回归套件也将跟着增长。回归测试中的任何失败都将转化并增加周期以及导致较长的上市时间。

3.经验：团队中经验丰富的高级人才会决定每个版本中什么应该进入回归测试套件。他们通常会根据修复的bug来决定哪些测试应该在每次发布时执行。这种方法通常会产生不错的结果，但仍然容易漏过测试。

所有上述方法都具有其自身的缺点。

那么回到在这篇文章开头所提的问题，

如果不使用统计方法，我们该怎么做来获得测试的最佳设置？

或

有相对较低风险并且有较短上市时间的最佳回归测试套件设置应该是怎样的？

为了得到正确的一组回归测试集，我们不只需要有经验的测试人员，还需要发布版本中修改部分的重要信息以及开发人员的指导。

让我们举个例子来说明这一点。

假设有n个模块使用到了通过#define定义的名为NUM_DIRECTORS的变量。假设值为8。这个值在多处被用到，但在一个处开发者认为该值应为6，而不是8。他改变了#define的值为6，但还有另一个开发人员在他的代码中将那个值直接定义为8所以未被更改。

这就带来了代码中的回归。

测试架构师无法找到这种回归，因为他不知道在代码中这个特殊的#define值都在哪里被使用了。聪明的开发人员会要求测试人员来测试所有可能直接用到这个#define值或直接定义这个值的代码部分。

回归测试确定过程

结论：建议回归测试套件确定过程应该是由开发人员和测试工程团队之间协作努力完成的。在回归测试套件质量以及优化上所花费的时间将有助于缩短上市时间，并通过减少遗漏测试来提高产品的质量。

{测试窝原创译文，译者：大头}

译者简介：大头，在读日本九州大学修士，计算机专业，主研究方向为文本挖掘，及自然语言处理。