大家有兴趣的话,一起来讨论一下如何更好的进行回归测试

myfellow_2008

Sample Text我做测试工作已经有两个月了,主要是web页面的测试;总是掌握不好如何更好的进行回归测试的方法.我也看过一些资料,但不知采取哪个方法好?如果只检查返回的bug,风险就比较大,但效率可以提高;如果再次进行全面测试,效率就会下降;所以在测试过程中比较矛盾.在此,想请教一下各位.谢谢!!!

xyanbin

软件测试从这里开始Page 44
Last saved by yanbin 晏斌<xyanbin@gmail.com>2006 
回归测试
回归测试是在软件维护阶段，在软件设计错误修正、设计修改以及软件升级后，对软件
进行修改之后进行的测试（主要针对软件修改、影响部分）。其目的是检验对软件进行的修
改的正确性。修改的正确性有两重含义：一是所作的修改达到了预定目的；二是不影响软件
的其他功能的正确性、不产生新的缺陷。
回归测试概述
回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化
的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测试用例，然后就可以进
行回放和比较。
回归测试集包括三种不同类型的测试用例：
 能够测试软件的所有功能的代表性测试用例。
 专门针对可能会被修改影响的软件功能的附加测试。
 针对修改过的软件成分的测试。
回归测试是测试实施过程中最为重要的环节之一，回归测试做得好与坏，直接影响到测
试工作的效果。而且，回归测试的工作量占测试实施的工作量的5 成以上。
回归测试类型
一般回归测试
一般回归测试：适用于各个系统测试阶段中，验证前一次系统测试中失败的用例，和产
品的有效性。
一般的回归测试可以在一段时间就使用一个更新了的版本(基于测试用例的测试)，但是
一般说来在一个回归测试中尽量保证被测版本不变是有益的。
 最终回归测试
最终回归测试：适用于产品正式发布前的创建版本，验证发布版本的有效性。
在执行最终回归测试的时候要求被测试的版本在一段时间内是固定不变的，也就是在产
品发布中经常说到的“cook－time”。在这段时间里面，产品会被反复的测试。某些测试用
例可能要被执行几次，以确认在发布版本中不会存在用户在使用过程中会遇到Bug。所有的
基于发布版本的Bug 修改工作应当在最终回归测试前完成。由于它测试的对象是将要发布
给用户的版本，所以最终回归测试是相当重要的。因为通过最终回归测试的版本就是用户将
要使用的版本。
回归测试策略
对测试用例库(在给定的预算和进度下，尽可能有效率和有效力)进行维护并依据一定的
策略选择相应的回归测试包。
为什么？
在软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当大，这使每次
回归测试都重新运行完整的测试包变得不切实际。测试组不得不选择一个缩减的回归测试包
来完成回归测试。
回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回
归测试时，有可能删除了将揭示回归错误的测试用例，消除了发现回归错误的机会。然而，
如果采用了代码相依性分析等安全的缩减技术，就可以决定哪些测试用例可以被删除而不会
让回归测试的意图遭到破坏。
有些回归测试中，往往维持一个“不变化的测试用例集合”，换句话说就是每次回归测
试使用的测试用例都是固定不变的，回归测试用例的集合应该按照修改了的bug 和这些
bug 的类型来确定。如果维持一个不变的测试用例集合，那么有可能在测试中发现不到修改
一个bug 给整个系统带来的副作用，因为测试人员的精力被分散了。如果我们可以分析测试
用例和修改bug 之间的关联的话，则可以显著的提高回归测试的效率。
测试用例库的维护
测试用例库的维护主要包括以下几个方面：
 删除过时的测试用例
因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统，这些测试用例
就会过时。例如，某个变量的界限发生了改变，原来针对边界值的测试就无法完成对新边界
测试。所以，在软件的每次修改后都应进行相应的过时测试用例的删除。
 改进不受控制的测试用例
随着软件项目的进展，测试用例库中的用例会不断增加，其中会出现一些对输入或运行
状态十分敏感的测试用例。这些测试不容易重复且结果难以控制，会影响回归测试的效率，
需要进行改进，使其达到可重复和可控制的要求。
 删除冗余的测试用例
如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试，那么这些测试
用例是冗余的。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例
库，并将冗余的用例删除掉。
 增添新的测试用例
如果某个程序段、构件或关键的接口在现有的测试中没有被测试，那么应该开发新测试
用例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。
通过对测试用例库的维护不仅改善了测试用例的可用性，而且也提高了测试库的可信
性，同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。
回归测试包的选择
测试包的选择原则
在选择回归测试用例的时候更多的是要考虑修改bug 可能产生问题的严重性，而不是单
纯的考虑一个bug 本身的严重性。在修改一个minor 等级的bug 时，修改工作产生的副作用
可以会导致一个major 的bug 产生。而在修改一个严重等级的bug 时候，修改工作可能对其
他代码一点影响也没有。所以测试人员在选择回归测试用例的时候需要综合的考虑上面2
方面的因素。
在选择测试用例的时候需要避免的是选取那些必定Fail 的用例和那里同bug fixes 没有
多少关系的用例。在最终回归测试用例的选择上“positive”的用例应该多于“negative”用
例，因为过多的“negative”干扰测试的重点和开发人员的精力。在一般性的回归测试中则
应该选取“positive”和“negative”混合的测试用例。前面中说道的“negative”用例可以解
释为那些以系统出错为目的的用例。
测试包的基本属性
 为回归测试选择用例的时候需要初步具备分析修改方法和分析修改过程对系统的影响
的能力
 选择的用例要求能够覆盖缺陷的多发区域
 选择的用例能够覆盖到代码经常修改，变动的区域
 产品中用户的可见部分在选择用例的时候一定要覆盖到
 用例要覆盖到用户在需求中提及到的核心特性。
测试包的选择方式
选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括：
 再测试全部用例
选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再
测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用
到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例
不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。
 基于风险选择测试
可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、
关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用
例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征
到次要特征。
 基于操作剖面选择测试
如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映
了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可
以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有
助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的
提高系统可靠性，但实施起来有一定的难度。
 再测试修改的部分
当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并
分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定
涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的
部分。
再测试全部用例的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示
新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用
例的回归测试策略，此时，可以选择适当的策略进行缩减的回归测试。
回归测试的基本过程
有了测试用例库的维护方法和回归测试包的选择策略，回归测试可遵循下述基本过程进行：
(1)识别出软件中被修改的部分；
(2)从原基线测试用例库T 中，排除所有不再适用的测试用例，确定那些对新的软件版本依
然有效的测试用例，其结果是建立一个新的基线测试用例库T0。
(3)依据一定的策略从T0 中选择测试用例测试被修改的软件。
(4)如果必要，生成新的测试用例集T1，用于测试T0 无法充分测试的软件部分。
(5)用T1 执行修改后的软件。
第(2)和第(3)步测试验证修改是否破坏了现有的功能，第(4)和第(5)步测试验证修改工作本
身。
软件测试从这里开始Page 47
Last saved by yanbin 晏斌<xyanbin@gmail.com>2006

myfellow_2008

谢了,这份资料我以前看过,我也按照他的方法试过.有时候时间比较紧的话,可能就会采用效率高的方法.但每次都会有一些问题会漏掉.不得不再做一次全面的测试.所以浪费了很多的时间.我想听听大家自己是如何进行回归测试的.

walker_lai

谢谢了

panxiaoyan

回归测试的方法：有选择的执行以前的测试用例。
常用的用例选择方法分为3种：
1、局限在修改范围内的测试。即这类回归测试仅根据修改的内容来选择测试用例，这部分测试用例仅保证修改的缺陷或新增的功能被实现了。该方法在进度压力很大，或者系统结构设计耦合性很小的状态下使用。
2、在受影响的功能范围内回归。这类回归测试需要分析当前的修改可能影响到哪部分代码或功能，对其对应的测试用例都将被回归。如何判断哪些功能或代码受影响依赖于开发过程的规范性和测试分析人员的经验。对于开发过程有详细的需求跟踪矩阵的项目而言，在矩阵中分析修改功能所波及的代码区域或其他功能是比较简单的，同时有经验的开发人员和测试人员能够有效地找到受影响的功能或代码。对于单元测试而言，代码修改的影响范围需要充分考虑到一些对公共接口的影响。该方法是业界推荐的方法，适合一般项目。
3、根据一定的覆盖率指标选择回归测试。该方法一般是在相关功能影响范围难以界定的时候使用。最简单的策略是规定修改范围内的测试是100%。