敏捷模型下的回归测试

吴扬科

摘 要 敏捷模型是针对传统瀑布模型的弊端而产生的一种新的软件开发模型，目标是提高开发效率和响应能力。它是一种基于用户的需求进化，迭代、循序渐进的开发方法。Scrum是敏捷开发模型的一种，它最大的特点是迅速响应需求变化。Scrum是在最近两年中流行起来，它逐渐取代了传统模型在开发过程中的地位，成为主流的开发模型。在实际工作中，当代码更新后，我们往往要执行一次回归测试。在Scrum模式下，由于其自身迭代十分频繁，所以对回归测试的执行速度和频率都要求十分高。这就要求回归测试不仅要对测试用例进行自动化，而且还要准备一套稳定的持续集成的环境，实现每天执行自动化测试用例。本文针对敏捷模型的特点，对回归测试的实现做出了一些改进。

关键词敏捷模型 Scrum 回归测试 持续集成

中图分类号：TP3 文献标识码：A

近年来随着IT行业的迅速发展，软件已经在人们日常生活中随处可见，而软件行业的竞争也日趋激烈。在激烈的竞争环境中，越来越多的软件企业都期望采用一种开发周期短，质量稳定，投资回报高的软件开发模型。于是敏捷模型逐渐走入人们的视野，并受到越来越过的开发团队的青睐。敏捷开发是一种基于用户需求的，循序渐进的迭代式的开发方法。相对于传统的瀑布式模型来说，敏捷模型具有如下优点：

传统的瀑布模型要求用户需求明确，而且一旦确定下来，在后续开发过程中便不能更改。但是对大多数软件项目来说，用户的需求往往是不断变化的。尤其是项目的初期，用户需求很难明确，甚至有时用户自身也很难有一个清晰的需求。而敏捷模式正是以用户需求为核心的一种开发模式，用户可以在敏捷模式的每一个迭代周期中，不断提出自己新的需求（user story），以不断接近最终的需求目标。

瀑布模型往往开发周期比较长，而且团队成员的利用率不高，比如在设计阶段往往只有设计人员和架构师参与其中，开发和测试人员的参与率很低。而敏捷模式由于其周期短，全体参与者在每个迭代周期内往往各司其职，充分参与到项目中，这就大大提高了开发效率。

敏捷模式可以较早推出可以运行的产品，并在用户的使用中发现问题，改进需求，合理的规避风险。在这一点上瀑布模型是无法做到的，如果一旦瀑布模型生产出的产品最终无法被用户所接受，那么产品将不得不重新设计，从而大大增长整个产品的成本和周期。这种返工的代价是巨大的，而且频繁的返工往往会使整个项目面临失败的风险。

瀑布模型中，测试的阶段往往比较滞后，这就导致有时很严重的问题往往到项目快临近结束的时候才被发现出来。更有甚者，有的项目为了追赶时间进度，会把测试周期缩短以保证产品的按时发布，从而导致产品质量低下，严重影响用户满意度。但在敏捷模式中，每一个迭代周期都会对产品进行集成测试，而且自动化的集成测试可以极大的提高测试效率，使产品的质量得到持续性的保证。敏捷模式经常可以把严重的、优先级比较高的缺陷在早期发现并得到修复，保证上线的产品质量稳定，故障率通常较低。

Scrum是敏捷模型中最常用的一种开发模式。Scrum是橄榄球运动中的一个专业术语，表示争球。 我们可以想象当一个项目团队像打橄榄球一样在开发一个项目，那是一件多么快速，多么富有激情的事情。在Scrum模式下，每一次迭代周期（一般为4个星期）定义为一个Sprint，中文意思即为冲刺，也就是说团队成员要在迭代周期内，以最快的速度完成它。这里我们就不对Scrum的具体流程作详细介绍了， 读者有兴趣可以参阅相关资料。

下面我们来看一下，在Scrum模式下测试通常是如何进行的。首先，在产品开发的过程中，新需求和新功能在迭代中不断涌现，每次迭代结束都会产生一个可工作的软件。这就要求测试人员要尽可能早的展开工作，等待开发人员完全开发完毕在Scrum中属于一种错误的概念。

其次，测试用例要尽可能多地采用自动化。Scrum项目初期，产品停留在初步设计中，产品功能不多，复杂度小，手动测试就可以保证质量。而到了中后期，因不断有新需求、新功能的加入，产品复杂度明显增大。若仍然采用手动测试，恐怕难以覆盖产品的各个功能、非功能点，而且手工测试在面对功能诸多的产品时，就会暴露出执行耗时长，易遗忘等缺点。因此，可以用自动化测试来提高工作效率。

然后就是，测试人员要学会做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发人员。

回归测试（Regression Test）简单来说就是重复测试之前的测试用例。这个环节在很多项目，尤其是那些迭代相对频繁的项目往往会被忽视，或者说做得不够充分，究其原因是由于项目开发周期短，产品上线紧急，从而挤压了回归测试的时间。但是不得不说这个环节对保证产品质量和产品功能稳定是十分重要的。当一个新的功能加入到产品中或是一个已有的功能被修改，往往涉及很多模块的变动，尤其是基类和公共类的改变，这时候就非常容易导致新的功能加入进来，已有的功能却无法正常运行的情况，在耦合度相对较大的项目中这类问题更是尤为突出。

回归测试重要性很明显，但是在敏捷模型下，它执行起来却没有那么轻松。由于敏捷模型自身的特点：开发周期短，迭代频繁，所以相对于传统的瀑布模型，会使测试的压力大大增加。其困难主要集中在两个方面，首先是测试用例的数量，一般来说测试覆盖率和测试用例的数量成正比，因此测试人员会在功能测试中会引入大量的测试用例来提高覆（下转第33页）（上接第31页）盖率，从而提高对产品质量和测试流程的信心。但是在测试用例增加的同时，测试时间也会延长，这就给回归测试带来了难度，测试人员很难在有限的时间里执行大量回归测试。其次，当项目迭代次数很多时，大量的测试用例维护也会占用测试人员很多的时间和精力。一旦维护不及时，往往会使一个缺陷影响很多个迭代周期而不被人们发现。

由于回归测试需要执行大量的测试用例，而这些测试用例的验证步骤往往会有些共同的特点，所以人们往往用编程自动化的方法来实现回归。自动化的回归测试的好处主要有如下几个方面：

减少手动回归的测试量，缩短回归测试的时间。

减少人为执行测试用例时的干扰因素，避免人为执行不充分的影响。

结合持续集成测试方法，保证回归测试持续进行。

对复杂的测试用例可以进行分解，自动化每个单独测试点。

对于测试用例中常用的步骤可以封装成通用的方法，让公共的测试步骤可以复用。

自动化还可以执行一些手动测试很难执行的测试用例，比如对于大量用户和并发用户的模拟。

在敏捷模型中，自动化的回归测试几乎是每个项目都会使用到，但是敏捷模型却有一个特点是自动化的回归测试往往陷入困境。那就是在敏捷模型下，需求的变动非常频繁，测试人员经常需要对已有的测试用例进行修改。针对这个特点，在我们创建自动化测试用 例时，最好可以做到如下几个方面：

将测试用例中的测试数据和测试用例本身分开。

尽量将常用方法封装成公共方法。

将经常变化的参数提取到配置文件中。

减少硬编码和重复的代码量。

这样做不仅能让自动化测试代码在需求变化时，修改程度最小化，而且还能让测试代码变得简洁便于维护。

由于在敏捷模式下，迭代周期很短，有时候甚至会每周就发生一次迭代。这就要求测试人员经常对测试用例进行检查，也就是说我们要经常地执行回归测试。上面我们已经提到了自动化回归测试的方法，现在我们再看一下这种方法应该如何执行，以及它执行的频率。在敏捷模型的项目里，有两种执行自动化回归测试的策略，一种是在代码签入时，另一种是以天为单位来执行。具体选用哪种策略，我们通常是看代码签入的频率，如果代码签入频率很高话，按天执行回归将是很好的选择。测试人员只需要每天检查测试结果的报告就可以发现哪些测试用例出了问题，具体是测试用例需要调整，还是产品功能发生了异常，需要测试人员进行分析。当然如果测试用例的日志足够详细的话，将有助于对问题的分析和定位。

综上所述，回归测试在敏捷模式下的作用非常重要，其测试方法也越来越偏重于自动化的实现方案，相较于过去的开发模型，敏捷模型对测试人员的编程能力要求更高。在敏捷模型下的项目，测试人员要从事大量的自动化编程工作，在一些项目中测试人员和开发人员甚至可以做到角色互换。希望测试人员在敏捷模型下可以转变过去传统模型所固有的思路，将回归测试做得更好。

参考文献

[1] Lisa Crispin and Janet Gregory. 敏捷软件测试：测试人员与敏捷团队的实践指南. 清华大学出版社. 2010年.

[2] Robert C Martin. 敏捷软件开发：原则、模式与实践. 清华大学出版社. 2003年.

[3] 陈能技. QTP自动化测试最佳实践. 电子工业出版社. 2012年.