小小千想和您聊一聊

当前位置: 首页> 技术分享> 软件回归测试

软件回归测试

  一、 回归测试的定义

回归测试 regression  testing

系统或部件选择的重新测试,用以验证修改未引起不希望的有害效果,或证明修改后的系统或系统部件仍满足规定的需求。

——《GB/T 11457-2006 信息技术 软件工程术语》 2.1329

软件修改后,重新测试以前测试过的程序,确保更改没有给软件其他未更改部分带来新的缺陷。软件修改后或使用环境变更后要执行回归测试。

                         ——《软件测试基础教程(ISTQB指定教材)》

  二、 回归测试的目的

测试软件变更后,变更部分的正确性和对变更需求的符合性;

测试软件变更后,软件原有的、正确的功能、性能和其他规定的要求的不损害性。

——《GB/T 15532-2008 计算机软件测试规范》

  三、 百度百科中对回归的说明

  回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。回归测试作为软件生命周期的一个组成部分,在整个软件测试过程中占有很大的工作量比重,软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中,新版本的连续发布使回归测试进行的更加频繁,而在极端编程方法中,更是要求每天都进行若干次回归测试。因此,通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

  1. 维护测试用例库

  对于一个软件开发项目来说,项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中,并对其进行维护和管理。当得到一个软件的基线版本时,用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候,就可以根据所选择的回归测试策略,从基线测试用例库中提取合适的测试用例组成回归测试包,通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本,也有可能是测试用例的手工实现过程。

  测试用例库的维护。为了最大限度地满足客户的需要和适应应用的要求,软件在其生命周期中会频繁地被修改和不断推出新的版本,修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。随着软件的改变,软件的功能和应用接口以及软件的实现发生了演变,测试用例库中的一些测试用例可能会失去针对性和有效性,而另一些测试用例可能会变得过时,还有一些测试用例将完全不能运行。为了保证测试用例库中测试用例的有效性,必须对测试用例库进行维护。同时,被修改的或新增添的软件功能,仅仅靠重新运行以前的测试用例并不足以揭示其中的问题,有必要追加新的测试用例来测试这些新的功能或特征。因此,测试用例库的维护工作还应包括开发新测试用例,这些新的测试用例用来测试软件的新特征或者覆盖现有测试用例无法覆盖的软件功能或特征。

  2. 选择回归策略

  在软件生命周期中,即使一个得到良好维护的测试用例库也可能变得相当大,这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例,时间和成本约束可能阻碍运行这样一个测试,有时测试组不得不选择一个缩减的回归测试包来完成回归测试。

  回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归测试时,有可能删除了将揭示回归错误的测试用例,消除了发现回归错误的机会。然而,如果采用了代码相依性分析等安全的缩减技术,就可以决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。

  选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括:

  (1)、再测试全部用例

  选择基线测试用例库中的全部测试用例组成回归测试包,这是一种比较安全的方法,再测试全部用例具有最低的遗漏回归错误的风险,但测试成本最高。全部再测试几乎可以应用到任何情况下,基本上不需要进行分析和重新开发,但是,随着开发工作的进展,测试用例不断增多,重复原先所有的测试将带来很大的工作量,往往超出了我们的预算和进度。

  (2)、基于风险选择测试

  可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试,而跳过那些非关键的、优先级别低的或者高稳定的测试用例,这些用例即便可能测试到缺陷,这些缺陷的严重性也仅有三级或四级。一般而言,测试从主要特征到次要特征。

  (3)、基于操作剖面选择测试

  如果基线测试用例库的测试用例是基于软件操作剖面开发的,测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定,回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例,释放和缓解最高级别的风险,有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性,但实施起来有一定的难度。

  (4)、再测试修改的部分

  当测试者对修改的局部化有足够的信心时,可以通过相依性分析识别软件的修改情况并分析修改的影响,将回归测试局限于被改变的模块和它的接口上。通常,一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下,回归测试尽可能覆盖受到影响的部分。

  再测试全部用例的策略是最安全的策略,但已经运行过许多次的回归测试不太可能揭示新的错误,而且很多时候,由于时间、人员、设备和经费的原因,不允许选择再测试全部用例的回归测试策略,此时,可以选择适当的策略进行缩减的回归测试。

  四、 ISTQB解释

  ——摘抄自《软件测试基础教程》第2版 3.7.4 与变更有关的测试和回归测试

  当已有的系统发生变化、缺陷被修正或者增加了新功能时,变化的部分必须进行再测试(retest)。另外,还存在变化导致副作用的风险。为了解决这些问题,需要重新执行已有的测试用例。这些测试称为回归测试。

  回归测试是在程序被修改后重新进行测试的过程,以保证这个修改没有引入或暴露故障。

  这样的故障经常是因为程序修改而引起计划外的副作用造成的。这就意味着回归测试可以在所有的测试基本执行,并应用到功能测试、非功能测试和结构测试(structural testing)中。回归测试中使用的测试用例会多次运行,因而必须很好地进行文档化,并使之具有可重用性。因此它们通常是测试自动化(test automation)的对象。

  3. 回归测试的范围

  在进行回归测试的时候,必须决定回归测试的范围。下面是对可能的范围的一些建议:

  (1)重新运行所有发现故障的测试,而新的软件版本已经修正了这些故障(缺陷再测试、确认测试)。

  (2)测试所有修改或修正过的程序部分(功能改变的测试)。

  (3)测试所有新集成的程序(新功能测试)。

  (4)测试整个系统(完全回归测试)。

  方法(1)中只进行了很少的再测试,而方法(2)和方法(3)中只对修改的部分进行再测试,这样的测试是不够的,因为在软件系统中本地代码的修改可能导致系统其他部分(不确定距离)的副作用。

  如果测试只覆盖变化或新的代码部分,那么测试就忽略了修改部分对没有修改部分的影响。软件的麻烦是他的复杂性,在合理的成本下,只能粗略的估计这样的影响可能在哪些地方发生。对于没有充足文档或需求遗漏的系统进行修改就显得尤其困难,不幸的是,这种情况在已有的系统中经常发生。

  除了对修正的缺陷和功能发生变化的部分进行再测试,还应该重新执行已有的所有测试用例。只有这样,现在的测试才和对原程序版本的测试一样安全。如果变化的系统环境对系统的所有部分都有影响的话,还应该运行完全回归测试。

  实际中,完全回归测试通常是非常耗时间,成本很高。因而需要寻找一些标准以帮助选择可以忽略哪些旧的测试用例,而不会丢失太多的信息。在测试过程中,这样通常意味着风险和成本的平衡。决定这种平衡的最好办法就是对变更进行影响分析,尽量决定副作用可能在哪儿发生。下面的策略经常会用以判断:

  ☆ 只重复测试计划中的高优先级的测试。

  ☆ 在功能测试中,忽略特定的变化(特别的例子)。

  ☆ 只针对特定配置进行测试(例如:只对英文产品版本进行测试,只对操作系统的一个版本测试)。

  ☆ 只针对特定子系统或测试级别进行测试。

  这些列出的标准通常主要针对系统测试。在更低的测试级别,回归测试标准可以同样基于设计或架构文档(例如,类层次)或白盒信息。更多信息可见[Kung 95]、[Rothermel 94]、[Winter 98]和[Binder 99]。这些文档中作者不仅描述了在面向对象程序中回归测试面临的特殊问题,还详细的描述了回归测试的通用准则。

  五、 在缺陷跟踪中的位置

  当缺陷修复后,在对新版本的“回归测试”中,验证缺陷是否修复成功,如果缺陷修复成功,将缺陷状态置为“关闭 Closed”,否则置为“重新打开 Reopen”。

上一篇:HTML5工具初识之网页编辑器

下一篇:软件测试质量

QQ技术交流群

千锋软件测试官方①群
858327674

加入群聊