如何更高效的进行回归测试？（08-12-1）（获奖名单已公布）
项目频繁的改动,我们在做回归测试的时候若选择完全重复测试.把所有的测试用例,全部再完全的执行一边,以确认问题修改的正确性和修改后周边是否受到影响,但是如果把全部用例全部执行,会增加项目成本,也会影响项目进度.若选择性重复测,不能确保周边受影响的能测试到,请问如何更高效的进行回归测试?感谢会员sumohan提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单奖项获奖名单奖励答案链接一等奖archonwang当当购物卡50元2#二等奖hjjlearning300论坛积分17#土土的豆豆8#三等奖rolei100论坛积分
23#zhangjm168829#
再倒一次。。。上周问题又忘了答。。。。
本次补上。
=========================================================================================
：受到刺激，先行回答
以下内容源自自己以前的回归测试方案设计，部分内容源自网络摘录。
-----------------------------------------------------------------------------------------------------
1.
回归测试基本策略及其评价
基于以上基本原则的阐述，回归测试的基本策略目前有如下几种，现一一进行阐述。
1.1
回归测试方式1.1.1
GTRT：全面用例回归测试选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度（即使在引入了回归测试自动化来缓解回归测试的工作强度及时间进度压力）。
1.1.2
BRRT：基于风险的回归测试可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要特征。
1.1.3
BORT：基于操作剖面的回归测试如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性，但实施起来有一定的难度。
1.1.4
BIRT：基于影响面分析的回归测试当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。
1.2
回归测试基本策略评价具体的回归测试基本策略评价表如下所示：
GTRT
BRRT
BORT
BIRT
适用情况
时间宽裕人员充足
后续变更不多
进度紧张人员不足
对后续变更无特殊要求
基于客户操作习惯
持续更新长期维护
功能内外关系分析透彻深入对后续变更无特殊要求
回归实现难度
容易
相对容易
相对容易
困难
测试人员投入
大量
适中
少量
少量
流程及规范性要求
一般
不需遵照流程规范
较高
规范较严格
较高
流程较严格
高
严格遵照流程规范
测试人员能力要求
一般
项目经验丰富
业务知识丰富
技术能力强
能很好理解业务
测试维护成本
很高
一般
一般
较低
自动化引入可行性
易引入
可引入
较难引入
很难引入
脚本开发维护量
巨大
视后续变更
一般
少量
图表2
回归测试基本策略评价表
全面用例回归测试的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略，进行缩减的回归测试。某一个项目的回归测试往往是针对具体的情况，分别引用不同的执行策略而确定的。
1.
系统回归测试解决方案
1.1
回归测试基本策略在系统的引用说明1.1.1
备选策略：全面用例回归测试具体介绍如前。就如以上所言，其优势在于回归覆盖率，但是对目前的系统而言，无论是作为手工测试还是自动化测试，其前期的投入巨大，在短期内可能无法取得良好的效果。就中长期建设，可考虑该方案。
1.1.2
备选策略：基于风险的回归测试具体介绍如前。基于风险的回归测试在系统中的实施难度在于前期的功能风险筛选。自动化实施难度一般，但缺乏业务连贯性是该策略的致命问题。
1.1.3
备选策略：基于操作剖面的回归测试具体介绍如前。基于操作剖面的回归测试可以有效降低前期投入，在开始的初期，可以筛选特定的测试案例库用以进行回归测试，其优点在于业务面方向性明确，可以有效保障在用系统的核心关键业务问题可及早发现，但其缺点也是较明显的：覆盖率不足，且自动化实施的难度偏大
1.1.4
备选策略：基于影响面分析的回归测试具体介绍如前。基于影响面分析的回归测试是单元级测试。在系统上，基于影响面分析的回归测试的主要优点是可以大幅降低测试案例库的大小，但是，基于业务层面的考虑，在线系统一般都很少考虑使用该策略。同时，该策略在实施的分析阶段内要求较为规范的开发流程，以使测试开发人员能实现回归测试自动化。从目前的情况看，在系统实施该项测试的可能性不大。
1.2
系统回归测试策略模型综合评定了以上四种基本策略在系统上的引用说明，现提出如下的策略选择方法参考解决当前系统回归测试问题，提升业务系统的品质保障，规避更新升级可能带来的故障风险。该策略模型的基本思想如下：
实现基础：
1. 基于系统测试用例库，并对测试案例按策略进行划分及补充
综合策略：
1. 以BORT为主策略
2. BIRT及BRRT为辅助型策略，支持BORT主策略，对相关的回归测试集合进行补充
3．当持续运维到一定阶段后，将逐步形成GTRT策略的覆盖
见图表3所示：
图表3
系统回归测试组合策略模型
[ 本帖最后由 archonwang 于 2008-12-1 10:54 编辑 ] 原帖由 archonwang 于 2008-12-1 10:09 发表 http://bbs.51testing.com/images/common/back.gif
再倒一次。。。上周问题又忘了答。。。。
本次补上。
=========================================================================================
::ysssn:::
沙发王子 站茅坑……
最近做了好多回归测试
看我时间了~有时间的话就过来答题 追求最高性价比，既然不能避免损失，我们要做的就是把损失降到最低。 这个题目就是对我现在项目的总结，呵呵
占位先
回复 3# 的帖子
老大，改天坐地毯。。。。。。:$我答回归测试
回归测试作为软件生命周期的一个组成部分,在整个软件测试过程中占有很大的工作量比重,软件开发的各个阶段都会进行多次回归测试.在渐进和快速迭代开发中,新版本的连续发布使回归测试进行的更加频繁.一先说下为什么会有回归测试.
在软件生命周期中的任何一个阶段,只要软件发生了改变,就可能给该软件带来问题.
1 软件的改变可能是源于发现了错误并做了修改,也有可能是因为在集成或维护阶段加入了新的模块.
2 当软件中所含错误被发现时,如果错误跟踪与管理系统不够完善,就可能会遗漏对这些错误的修改;
3 开发者对错误理解的不够透彻,也可能导致所做的修改只修正了错误的外在表现,而没有修复错误本身,从而造成修改失败;
4 修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题,使本来工作正常的功能产生错误.
5 同样,在有新代码加入软件的时候,除了新加入的代码中有可能含有错误外,新代码还有可能对原有的代码带来影响.
因此,每当软件发生变化时,我们就必须重新测试现有的功能,以便确定修改是否达到了预期的目的,检查修改是否损害了原有的正常功能.同时,还需要补充新的测试用例来测试新的或被修改了的功能.为了验证修改的正确性及其影响就需要进行回归测试.
二通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的.
1测试用例库的维护
为了最大限度地满足客户的需要和适应应用的要求,软件在其生命周期中会频繁地被修改和不断推出新的版本,修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化.随着软件的改变,软件的功能以及软件的实现发生了演变,测试用例库中的一些测试用例可能会失去针对性和有效性,而另一些测试用例可能会变得过时,还有一些测试用例将完全不能运行.为了保证测试用例库中测试用例的有效性,必须对测试用例库进行维护.同时,被修改的或新增添的软件功能,仅仅靠重新运行以前的测试用例并不足以揭示其中的问题,有必要追加新的测试用例来测试这些新的功能或特征.因此,测试用例库的维护工作还应包括开发新测试用例,这些新的测试用例用来测试软件的新特征或者覆盖现有测试用例无法覆盖的软件功能或特征.
测试用例的维护是一个不间断的过程,通常可以将软件开发的基线作为基准,维护的主要内容包括下述几个方面.
(1)删除过时的测试用例
因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统,这些测试用例就会过时.例如,某个变量的界限发生了改变,原来针对边界值的测试就无法完成对新边界测试.所以,在软件的每次修改后都应进行相应的过时测试用例的删除.
(2)改进不受控制的测试用例
随着软件项目的进展,测试用例库中的用例会不断增加,其中会出现一些对输入或运行状态十分敏感的测试用例.这些测试不容易重复且结果难以控制,会影响回归测试的效率,需要进行改进,使其达到可重复和可控制的要求.
(3)删除冗余的测试用例
如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试,那么这些测试用例是冗余的.冗余测试用例的存在降低了回归测试的效率.所以需要定期的整理测试用例库,并将冗余的用例删除掉.
(4)增添新的测试用例
如果某个程序段构件或关键的接口在现有的测试中没有被测试,那么应该开发新测试用例重新对其进行测试.并将新开发的测试用例合并到基线测试包中.
通过对测试用例库的维护不仅改善了测试用例的可用性,而且也提高了测试库的可信性,同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上.
2 回归测试包的选择
在软件生命周期中,即使一个得到良好维护的测试用例库也可能变得相当大,这使每次回归测试都重新运行完整的测试包变得不切实际.一个完全的回归测试包括每个基线测试用例,时间和成本约束可能阻碍运行这样一个测试,有时测试组不得不选择一个缩减的回归测试包来完成回归测试.
回归测试的价值在于它是一个能够检测到回归错误的受控实验.当测试组选择缩减的回归测试时,有可能删除了将揭示回归错误的测试用例,消除了发现回归错误的机会.然而,如果采用了代码相依性分析等安全的缩减技术,就可以决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏.
三选择回归测试策略应该兼顾效率和有效性两个方面.常用的选择回归测试的方式包括：
1 再测试全部用例
选择基线测试用例库中的全部测试用例组成回归测试包,这是一种比较安全的方法,再测试全部用例具有最低的遗漏回归错误的风险,但测试成本最高.全部再测试几乎可以应用到任何情况下,基本上不需要进行分析和重新开发,但是,随着开发工作的进展,测试用例不断增多,重复原先所有的测试将带来很大的工作量,往往超出了我们的预算和进度.
2 基于风险选择测试
可以基于一定的风险标准来从基线测试用例库中选择回归测试包.首先运行最重要的,关键的和可疑的测试,而跳过那些非关键的,优先级别低的或者高稳定的测试用例,这些用例即便可能测试到缺陷,这些缺陷的严重性也仅有三级或四级.一般而言,测试从主要特征到次要特征.
3 基于操作剖面选择测试
如果基线测试用例库的测试用例是基于软件操作剖面开发的,测试用例的分布情况反映了系统的实际使用情况.回归测试所使用的测试用例个数可以由测试预算确定,回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例,释放和缓解最高级别的风险,有助于尽早发现那些对可靠性有最大影响的故障.这种方法可以在一个给定的预算下最有效的提高系统可靠性,但实施起来有一定的难度.
4 再测试修改的部分
当测试者对修改的局部化有足够的信心时,可以通过相依性分析识别软件的修改情况并分析修改的影响,将回归测试局限于被改变的模块和它的接口上.通常,一个回归错误一定涉及一个新的,修改的或删除的代码段.在允许的条件下,回归测试尽可能覆盖受到影响的部分.
再测试全部用例的策略是最安全的策略,但已经运行过许多次的回归测试不太可能揭示新的错误,而且很多时候,由于时间,人员,设备和经费的原因,不允许选择再测试全部用例的回归测试策略,此时,可以选择适当的策略进行缩减的回归测试.
四回归测试的基本过程
有了测试用例库的维护方法和回归测试包的选择策略,回归测试可遵循下述基本过程进行:
(1). 识别出软件中被修改的部分;
(2). 从原基线测试用例库T中,排除所有不再适用的测试用例,确定那些对新的软件版本依然有效的测试用例,其结果是建立一个新的基线测试用例库T0.
(3). 依据一定的策略从T0中选择测试用例测试被修改的软件.
(4). 如果必要,生成新的测试用例集T1,用于测试T0无法充分测试的软件部分.
(5). 用T1执行修改后的软件.
第(2)和第(3)步测试验证修改是否破坏了现有的功能,第(4)和第(5)步测试验证 修改工作本身.见下图
五 ...
六 ...
七 阿七落款 :P
[ 本帖最后由 阿七 于 2008-12-7 12:12 编辑 ] 汗 时间差到8了 :L :L :L :L :L :o 我整天都在回归测试，占位准备答。
---------------------------------------------
最近一个月俺都在做回归测试。
每个公司要求不一样，我做回归测试都是手工功能测试，不按照测试用例（工作接近半年，公司还算信任我）
因为是小公司，真正的测试人员只有我一个，我也是跟着项目在跑，平常也很看重项目的背景知识（包括需求）和应用；
因为要对一个软件很好的进行功能测试，这几点是不能少的。
其实熟悉一个软件后，做回归测试是很快的，因为当初自己写的测试用例以及别人写的测试用例（确保执行guo，基本上已经在脑袋里了，
当你看到一个功能点的时候，大概都能想起，这几个功能点当初写用例的时候有哪些需要测到，不晓得大家是否有同感？
测试用例在脑袋里了，看着功能点，执行！OK，有没有问题，创建一个excel表格记录就可以了！
不过我说的这个也是因人，因公司而异的，仅供参考。:loveliness: :loveliness:
[ 本帖最后由 猫猫的拖鞋 于 2008-12-1 14:06 编辑 ] 好久没来啦，这个话题比较难定义，随便谈谈自己的体会吧……
题目要求还是老传统——“高效”！那就意味着必须有的放矢的实施工作，不能一股脑儿都重新来一遍。而“回归”的核心并不是“执行”测试，其实是回归测试前需要做的准备和测试后的结果分析。
1、回归测试的前提
在第一次乃至第二次、第三次测试过程中，应该保存下来每次测试的缺陷记录单和详细缺陷描述表。且缺陷应该适当进行归纳和等级划分。这个是定位回归测试点“轻重”的前提条件。且必须考虑修正缺陷后，原有缺陷是否会给系统带来相应功能模块的连带影响，孰轻孰重、及其范围的大小。
2、回归测试的执行
有了清晰的测试重点，那么对症下药很容易对先前出现过的缺陷再进行测试。而大型系统肯定是基于较完整的测试用例库和测试脚本来执行测试的。利用自动化工具，对系统做一个完整回归执行，可以明显减少诸多成本。
3、回归测试的分析
测试完了，结合工具跟踪后得到的报表或统计分析图，看原有缺陷的修正情况，以及该缺陷覆盖周边的最可能已经触发的新缺陷。这点比较关键，测试开始前理清思路，现在分析时就一目了然。一般情况下，测试工程师回归自己发现的缺陷很容易，如同楼上所说，仅靠脑袋里想法和自身累积的项目经验即可完成回归测试工作。
4、工具的结合使用
开发工程师往往只会对测试工程师发现的缺陷修正。然而，其他一系列新问题还是可能发生了，只找原发现的缺陷，肯定片面，还是会遗漏诸多新问题。如，回归后，对系统带来的新的严重的问题。所以，最好还是利用原先录制好的用例和脚本对全局进行完整的自动化操作。否则，缺这补那，永远难以结束复杂的“回归”之路。性能测试更需使用工具来执行测试，不是么？
以上只是个人想法，请诸位不吝指正，谢谢！ :) 我是新人如有说错之处还请各位多多指教。
首先，项目必然存在阶段性的改进。
每个阶段我们需要做的案例的收集和测试报告的维护工作，并记录哪些方面存在问题。在阶段性项目内容发生变更后，测试人员需要及时了解项目的重心是哪些内容，（我是个喜欢抓重心的人），针对已经修改的部分进行全局性的测试（仅是对时间非常紧迫的情况下）。
个人认为，测试重要，但更重要是设计软件的人员，设计过程是否存在系统问题，这可能是测试人员所想不到，也是潜在将会发生的问题。测试人员对项目的业务流程需要非常的熟悉，这样才能提高工作效率。:loveliness: 感觉楼上的说的太专业了，我所经历的回归测试是：
回归测试种类：
1. 集成测试中在集成了某个新的功能模块后的回归测试
2. 系统测试中在修复了bug后的回归测试
回归测试策略：首先测试新增模块的功能是否准确，在此基础上
再测试新增模块对原有系统可能造成影响部分的关联测试，时间允许的话再
对整个系统核心功能做一跑测
对于bug修复后的回归测试，可使用自动化工具QTP，也可手动测试根据流程管理工具像TD的TestLab执行关联用例进行。
[ 本帖最后由 JerryYe 于 2008-12-2 17:30 编辑 ]
希望能有些帮助
http://www.51testing.com/?1592/action_viewspace_itemid_83107.html 很久没有写东西了，都是金融危机惹的祸，说说个人想法，最近正在整理一些流程规范的东西，回归测试正是需要考虑的部分。说到回归测试，可以说每个做测试的人都做过，重复，无聊，消耗时间等可能是大家做回归测试的记忆。也许实施自动化测试可以解决一部分回归测试，但不是所有的测试都可以自动化，也不是所有的公司都有能力实施自动化，下面写的内容不涉及自动化内容。
从三方面来讨论做回归测试：
一、 测试流程方面
一般通用的测试流程都是“测试计划”—“测试设计”—“测试执行/分析”—“测试报告”，贯穿与整个项目，和开发流程相对应。由于本人做游戏测试方面，需求变更对游戏行业来说是很频繁，很正常的，在做游戏行业测试不能和通用软件测试流程一样，游戏测试流程应该是螺旋式的，单元测试，模块功能测试，集成测试，系统测试，性能测试，压力测试等是测试的一个过程，“测试计划”—“测试设计”—“测试执行/分析”—“测试报告”应该实施在每个阶段，实施在单元测试阶段，实施在模块功能测试阶段等，这样才能达到螺旋效果。而在每一次螺旋测试结束后，实施下一次螺旋测试前都应该进行回归测试，回归测试在螺旋测试中应该贯穿与每个螺旋阶段，而不是只贯穿与项目测试。
二、 测试用例设计方面
有了上面的回归测试流程计划，下面要实施的就是回归测试的重点——测试用例。在设计测试用例中就应该把回归测试用例考虑进去，可以通过设置用例优先级做为后期回归测试用例的挑选条件，也可以是其他的。
测试用例一般在项目中分为三种，单元测试用例，功能测试用例，性能测试用例。
1、 在不能阶段设计测试用例，挑选回归测试用例是不同的，单元测试用例设计一般选择具有编程能力的测试人员设计，功能测试用例设计选择熟悉业务知识的测试人员设计，性能测试用例设计一般需要与开发人员商讨才能设计。也就是说只有选对设计测试用例的人员，才有可能在后期挑选出好的回归测试用例。
2、 项目中的拳头功能，亮点，用户大量使用的功能应该是重点保护的地方，这方面可以交给小组核心人员进行设计。
......
欢迎访问：http://www.51testing.com/?18049/action_viewspace_itemid_98870.html
[ 本帖最后由 hjjlearning 于 2008-12-8 17:59 编辑 ] QTP 高效的完全回归测试方法。。。对修改的模块进行周边回归测试验证是否引起水波效应 :) ，看了收获还不小。 来看看,学点经验.
页:
[1]
2
