如何设计或者挑选有效的回归测试用例？（08-05-23）（获奖名单已公布）
随着系统的逐步成熟，每个版本包含的新特性越来越少，但是新功能对原系统的影响有多大是我们在测试时需要重点考虑的问题。此时，就势必要进行回归测试。而且系统越成熟，回归测试的比重也会越大。这将会对测试工作带来不小的挑战。在实际工作中，经常是一方面求全，希望覆盖面尽量广，避免漏测。另一方面求产出，大量的回归测试用例，可能只发现很少的问题，投入与产出不太匹配，会影响测试人员的士气，甚至测试管理者也会对这种投入产出有所质疑。并且，设计大量的自动化测试脚本，会占用大量的时间。
引子就说这么多，看看大家对这一普遍问题有什么看法和建议。
感谢会员RandyQi提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
非常感谢各位会员积极参与，截止至5月30日17：30分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。
获奖名单奖项获奖名单奖励答案链接一等奖卖烧烤的鱼当当购物卡50元7#二等奖godn_1981300论坛积分9#
love笨笨12#三等奖bzfyhfyh100论坛积分
2#windone8#xxxxwjj15# 呵呵，沙发！
以前在网上看到过很多的关于选择回归测试用例的文章，总结下来也就是下面几点：
对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。
回归测试需要时间、经费和人力来计划、实施和管理。为了在给定的预算和进度下，尽可能有效率和有效力地进行回归测试，需要对测试用例库进行维护并依据一定的策略选择相应的回归测试包。
1、测试用例库的维护
为了最大限度地满足客户的需要和适应应用的要求，软件在其生命周期中会频繁地被修改和不断推出新的版本，修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。随着软件的改变，软件的功能和应用接口以及软件的实现发生了演变，测试用例库中的一些测试用例可能会失去针对性和有效性，而另一些测试用例可能会变得过时，还有一些测试用例将完全不能运行。为了保证测试用例库中测试用例的有效性，必须对测试用例库进行维护。同时，被修改的或新增添的软件功能，仅仅靠重新运行以前的测试用例并不足以揭示其中的问题，有必要追加新的测试用例来测试这些新的功能或特征。因此，测试用例库的维护工作还应包括开发新测试用例，这些新的测试用例用来测试软件的新特征或者覆盖现有测试用例无法覆盖的软件功能或特征。
测试用例的维护是一个不间断的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括下述几个方面。
(1)、删除过时的测试用例
因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统，这些测试用例就会过时。例如，某个变量的界限发生了改变，原来针对边界值的测试就无法完成对新边界测试。所以，在软件的每次修改后都应进行相应的过时测试用例的删除。
(2)、改进不受控制的测试用例
随着软件项目的进展，测试用例库中的用例会不断增加，其中会出现一些对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制，会影响回归测试的效率，需要进行改进，使其达到可重复和可控制的要求。
(3)、删除冗余的测试用例
如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试，那么这些测试用例是冗余的。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库，并将冗余的用例删除掉。
(4)、增添新的测试用例
如果某个程序段、构件或关键的接口在现有的测试中没有被测试，那么应该开发新测试用例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。
通过对测试用例库的维护不仅改善了测试用例的可用性，而且也提高了测试库的可信性，同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。
2、回归测试包的选择
在软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当大，这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例，时间和成本约束可能阻碍运行这样一个测试，有时测试组不得不选择一个缩减的回归测试包来完成回归测试。
回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归测试时，有可能删除了将揭示回归错误的测试用例，消除了发现回归错误的机会。然而，如果采用了代码相依性分析等安全的缩减技术，就可以决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。
选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括：
(1)、再测试全部用例
选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。
(2)、基于风险选择测试
可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要特征。
(3)、基于操作剖面选择测试
如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性，但实施起来有一定的难度。
(4)、再测试修改的部分
当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。
再测试全部用例的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略进行缩减的回归测试。
3、回归测试的基本过程
有了测试用例库的维护方法和回归测试包的选择策略，回归测试可遵循下述基本过程进行:
(1). 识别出软件中被修改的部分；
(2). 从原基线测试用例库T中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0。
(3). 依据一定的策略从T0中选择测试用例测试被修改的软件。
(4). 如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分。
(5). 用T1执行修改后的软件。
第(2)和第(3)步测试验证修改是否破坏了现有的功能，第(4)和第(5)步测试验证 修改工作本身。
另外，回归测试集（要进行的测试的子集）包括三种不同类型的测试用例：
·能够测试软件的所有功能的代表性测试用例。
·专门针对可能会被修改影响的软件功能的附加测试。
·针对修改过的软件成分的测试。
[ 本帖最后由 bzfyhfyh 于 2008-5-23 17:47 编辑 ]
个人愚见
我个人认为,回归测试,主要是要测试接口模块.增加上去的新功能,有可能会在接口处影响到另一个模块的功能.所以应该重点放在整个流程上的测试.
同时,测试用例在书写时,也要重点观注数据流程方面. 为了保证系统的正确性,回归测试全部的测试用例是不可避免的.
但是考虑到问题检出的效率,应该考虑测试的顺序.
1,先测变更的部分,以确保变更代码的正确性
2,再测有会影响的部分,当然影响范围的确定是关键,
除了有直接调用关系的部分外,对于非显性存在的
关联,就要靠对系统充分了解同时有丰富经验的人来
判断了(这种关联性在设计阶段就应该被很全面的考虑).
3,上面两项测试完成后,再对全部测试用例进行回归测试,
来检出那些隐藏得很深的关联性问题 原帖由 51testing 于 2008-5-23 17:37 发表 http://bbs.51testing.com/images/common/back.gif
随着系统的逐步成熟，每个版本包含的新特性越来越少，但是新功能对原系统的影响有多大是我们在测试时需要重点考虑的问题。此时，就势必要进行回归测试。而且系统越成熟，回归测试的比重也会越大。这将会对测试工作带 ...
对标题回到不及各位大大，因此不发表意见。但是对于这段话不得不说两句。工作本身就是无聊的重复。又何必在意一次又一次的重复呢？况且做为测试人员本身就要有足够的耐心。忍不住寂寞怎么能发出最凌厉的一招呢？开发就素那小绵羊。我就素那大灰狼。。。。忍一时之苦。沙子里面也许还是有金子的 当一个版本的产生后，要根据当前版本的修改点，或是新功能点，进行了解－－当然了解的手段可以是多种多样的，
主要是做到，根据新的版本的修改点或是新功能点，查看其对应的需求文档及概要设计文档，了解其真实需要及本功能点的实现原理。在有条件的基础之下，最好能跟相关研发人员再进行一些沟通，从他们的角度去探索一些有可能出现问题的点。
在此基础之上，对以往的测试用例进行补充，删除，或是增加。
在些都做完后，可就自己的经验，将本版本的测试用例优先级别较低的（主要指一些，单独功能点的表象检查的一些用例，如：在做web测试时，所编写的一些针对，表单中各输入框，必填项等单点验证的测试用例），或是与本次修改毫无关联的功能点的用例剔除，剩下的即可作为本次的回归测试的主要用例群。
[ 本帖最后由 豆子 于 2008-5-26 13:59 编辑 ] 最近刚到新公司上班，面临的比较突出的问题是人力紧张，由于公司的产品用在Windows mobile，MTK，Kjava，Symbian，website几部分，测试人员<5(+上我)，如何高效的组织测试团队确实是个挑战？回归测试属于软件测试环节比较重要的部分，所以花费了一些时间总结此文，希望能给测试人员稀少，产品或项目众多的公司，提供一些建议:
也欢迎大家来的我的博客探讨软件测试：卖烧烤的鱼的测试博客：http://mayingbao.cnblogs.com/
所谓回归测试，即就是在软件生命周期中，只要软件发生了改变，就可能给该软件产产生问题；所以，每当软件发生变化时，
我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否破坏原有的正常功能。
其实仅单纯从英文单词Regress很好理解:return to a worse or less developed state.即是退化，衰退的意思，
检查软件从正常的稳定状态退化或是衰退到不正常工作的不稳定状态。
注意：回归测试不仅仅是针对在系统测试阶段，而是在软件生命周期中^_^
如果以上的定义均明确后，有效的回归测试应从这几方面：
其实最有效的回归测试方法建立在开发测试库的基础上；开发在创建测试库，每次生成程序的新版本时都可以运行这些用例。
只有有效的从源头避免风险才能有效的进行回归测试(目前国内的公司，能从事此级别的，太少）
1 强调单元测试时加强回归测试，引入代码评审，引入自动测试;
2 集成和系统级的测试时，加强测试用例评审，回归测试用例的选择；
具体的选择可以参考以下几点：
1 开发设计测试用例时制定优先级，如高，中，低，方便以后自动化或是策略选择；
2 配置管理时，引入测试用例基线管理，有效管理测试用例；
3 定期维护测试用例增，删，保持最新状态；
回归测试时需考虑效率和覆盖度有效配合，通常的策略有以下几种：
基于风险选择测试：
哪些功能是软件的特色？
哪些功能是用户最常用的？
哪些功能出错将导致用户不满？
哪些程序是最复杂、最容易出错的？
哪些程序最容易扩散错误？
哪些程序是开发者最没有信心的？
备注：只有有效的避免最大的风险，用户反感的问题，回归测试可以说达到了70%任务!
基于Regress衰退概念的测试：
开发人员修改的局部程序时，可能已经处理了症状，所以主要测试其被改变的模块和它的接口上；
但是也可能存在未触及到根本原因，所以需要测试周边程序及相互依赖性的部分；
错误本身可能得到了修复，但修复也可能造成其他错误，所以有必要为每个修复的错误，设计回归测试。
基于全面测试策略：
如果时间充足，资源齐全，可以进行全面测试,最低的遗漏回归错误的风险，但测试成本最高，非上策!
其它的回归测试：
1 基于GUI方式的自动化回归测试技术
2 基于Ad Hoc 回归测试：增加随机测试，避免回归测试肓点
备注：Ad Hoc Testing可参考:卖烧烤的鱼的测试博客：http://www.cnblogs.com/mayingbao/archive/2006/04/25/384160.html
3 基于交叉测试：多人互动的回归测试，尤其在核心的功能点，交互性比较的
[ 本帖最后由 卖烧烤的鱼 于 2008-5-26 16:53 编辑 ] 我是做嵌入式软件测试的。
关于回归测试，在项目前期，如单元测试阶段，一般会借助测试工具。后期的系统测试，则只能靠手工了。
我理解的回归有2种类型：
一个是测试出的软件bug，开发人员只需要更改软件就行，一般来说是小范围的修改，比较严重的设计bug，需要动的模块会多些，但是基本功能还是不变。
还有一种就是测试出发现系统的需求就不合理，这样设计出来的产品也肯定不合理，这个在自研项目中出现的机率较多。遇到这种需求变更，当然也可大可小，小的好说，大的估计会影响整个项目的成本，有些差不多要重新设计，那么回归的任务是相当的重了。相当于再做一个新的项目的测试了。
回归测试的难点在于难以分析出软件修改的影响范围。特别对于安全性，实时性要求高的嵌入式产品，没有人有把握说我这个修改只对这个模块产生影响。
所以在系统集成测试回归的时候，一般是全部回归。除非项目很紧张，没有时间做完整的回归，这个时候至少要把所有与这个模块直接接口的模块功能都测到。
最好是做一个数据流分析和控制流分析，这样对代码修改的影响力能够有一定的把握。在不能完整回归的时候，这种分析可以作为一种判断依据和心里安慰。
关于单元测试的回归，一般不会涉及到需求的变更，主要是功能点的测试，适合采用自动化工具。我公司使用的自动化工具是VectorCAST。这款工具能够展示每个用例执行到的代码路径。所以在单元测试回归的时候，我们主要精力是在关注涉及到代码语句修改过的单元测试用例上，看这些用例是否还能顺利通过，当然在必要的时候需要对原来的用例进行修改或是删减/增加。其他的用例，执行的语句在回归中没有改变，虽然借助工具也能运行，但是缺乏回归的意义。
以上是我的一些工作实践，欢迎大家指正。
这个问题问得很好啊~
这个问题问的很好，大多数的测试者都有这样的苦恼。我给出的药方在：http://www.51testing.com/?1592/action_viewspace_itemid_83107.html
就不在这里复制粘贴了~~
欢迎访问我的blog，会让你觉得没有白来~~:lol :lol
回归测试全面攻略
我个人认为回归测试是一套复杂完整的测试， 用来测试嵌入在 PostgreSQL 里的的 SQL 实现． 它同时测试标准 SQL 操作和PostgreSQL的扩展SQL． 这个套件最初是 Jolly Chen 和 Andrew Yu开发的，并且由 Marc Fournier 和 Thomas Lockhart 进行了大量的改进和重新封装． 自 PostgreSQL 6.1 以上开始，这个回归测试包含在每个正式发布版本里．回归测试可以就一套已经安装好并且在运行的服务器进行测试， 也可以就制作树里面临时安装的服务器进行测试．详细些说，有 "并行"和"串行"运行测试之分．串行模式顺序运行每个测试，而并行模式激活多个服务器进程， 并行地运行一组测试． 并行测试使我们对进程内部通讯和锁的正确工作有足够的信心．由于历史原因，串行测试通常对一个现存的安装进行测试，而并行 测试是"独立"的，不过这么做没有什么技术原因．
每当一个新的模块被当作集成测试的一部分加进来的时候，软件就发生了改变。新的数据流路径建立起来，新的I/O操作可能也会出现，还有可能激活了新的控制逻辑。这些改变可能会使原本工作得很正常的功能产生错误。在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一遍，以保证上述改变不会传播无法预料的副作用。
在更广的环境里，（任何种类的）成功测试结果都是发现错误，而错误是要被修改的，每当软件被修改的时候，软件配置的某些方面（程序、文档、或者数据）也被修改了，回归测试就是用来保证（由于测试或者其他原因的）改动不会带来不可预料的行为或者另外的错误。
回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测试用例，然后就可以进行回放和比较。回归测试集（要进行的测试的子集）包括三种不同类型的测试用例：
·能够测试软件的所有功能的代表性测试用例。
·专门针对可能会被修改影响的软件功能的附加测试。
·针对修改过的软件成分的测试。
在集成测试进行的过程中，回归测试可能会变得非常庞大。因此，回归测试应当设计为只包括那些涉及在主要的软件功能中出现的一个或多个错误类的那些测试，每当进行一个修改时，就对每一个程序功能都重新执行所有的测试是不实际的而且效率很低的。
一、 概述
在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改；而开发者对错误理解的不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败；修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。
回归测试在软件生命周期中扮演着重要的角色，因忽视回归测试而造成严重后果的例子不计其数，导致阿里亚娜5型火箭发射失败的软件缺陷就是由于复用的代码没有经过充分的回归测试造成的。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。
二、 回归测试策略
对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。
回归测试需要时间、经费和人力来计划、实施和管理。为了在给定的预算和进度下，尽可能有效率和有效力地进行回归测试，需要对测试用例库进行维护并依据一定的策略选择相应的回归测试包。
1、测试用例库的维护
为了最大限度地满足客户的需要和适应应用的要求，软件在其生命周期中会频繁地被修改和不断推出新的版本，修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。随着软件的改变，软件的功能和应用接口以及软件的实现发生了演变，测试用例库中的一些测试用例可能会失去针对性和有效性，而另一些测试用例可能会变得过时，还有一些测试用例将完全不能运行。为了保证测试用例库中测试用例的有效性，必须对测试用例库进行维护。同时，被修改的或新增添的软件功能，仅仅靠重新运行以前的测试用例并不足以揭示其中的问题，有必要追加新的测试用例来测试这些新的功能或特征。因此，测试用例库的维护工作还应包括开发新测试用例，这些新的测试用例用来测试软件的新特征或者覆盖现有测试用例无法覆盖的软件功能或特征。
测试用例的维护是一个不间断的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括下述几个方面。
(1)、删除过时的测试用例
因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统，这些测试用例就会过时。例如，某个变量的界限发生了改变，原来针对边界值的测试就无法完成对新边界测试。所以，在软件的每次修改后都应进行相应的过时测试用例的删除。
(2)、改进不受控制的测试用例
随着软件项目的进展，测试用例库中的用例会不断增加，其中会出现一些对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制，会影响回归测试的效率，需要进行改进，使其达到可重复和可控制的要求。
(3)、删除冗余的测试用例
如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试，那么这些测试用例是冗余的。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库，并将冗余的用例删除掉。
(4)、增添新的测试用例
如果某个程序段、构件或关键的接口在现有的测试中没有被测试，那么应该开发新测试用例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。
通过对测试用例库的维护不仅改善了测试用例的可用性，而且也提高了测试库的可信性，同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。
2、回归测试包的选择
在软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当大，这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例，时间和成本约束可能阻碍运行这样一个测试，有时测试组不得不选择一个缩减的回归测试包来完成回归测试。
回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归测试时，有可能删除了将揭示回归错误的测试用例，消除了发现回归错误的机会。然而，如果采用了代码相依性分析等安全的缩减技术，就可以决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。
选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括：
(1)、再测试全部用例
选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。
(2)、基于风险选择测试
可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要特征。
(3)、基于操作剖面选择测试
如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性，但实施起来有一定的难度。
(4)、再测试修改的部分
当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。
再测试全部用例的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略进行缩减的回归测试。
3、回归测试的基本过程
有了测试用例库的维护方法和回归测试包的选择策略，回归测试可遵循下述基本过程进行:
(1). 识别出软件中被修改的部分；
(2). 从原基线测试用例库T中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0。
(3). 依据一定的策略从T0中选择测试用例测试被修改的软件。
(4). 如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分。
(5). 用T1执行修改后的软件。
第(2)和第(3)步测试验证修改是否破坏了现有的功能，第(4)和第(5)步测试验证 修改工作本身。
三、回归测试实践
在实际工作中，回归测试需要反复进行，当测试者一次又一次地完成相同的测试时，这些回归测试将变得非常令人厌烦，而在大多数回归测试需要手工完成的时候尤其如此，因此，需要通过自动测试来实现重复的和一致的回归测试。通过测试自动化可以提高回归测试效率。为了支持多种回归测试策略，自动测试工具应该是通用的和灵活的，以便满足达到不同回归测试目标的要求。
在测试软件时，应用多种测试技术是常见的。当测试一个修改了的软件时，测试者也可能希望采用多于一种回归测试策略来增加对修改软件的信心。不同的测试者可能会依据自己的经验和判断选择不同的回归测试技术和策略。
回归测试并不减少对系统新功能和特征的测试需求，回归测试包应包括新功能和特征的测试。如果回归测试包不能达到所需的覆盖要求，必须补充新的测试用例使覆盖率达到规定的要求。
回归测试是重复性较多的活动，容易使测试者感到疲劳和厌倦，降低测试效率，在实际工作中可以采用一些策略减轻这些问题。例如，安排新的测试者完成手工回归测试，分配更有经验的测试者开发新的测试用例，编写和调试自动测试脚本，做一些探索性的或ad hoc测试。还可以在不影响测试目标的情况下，鼓励测试者创造性地执行测试用例，变化的输入、按键和配置能够有助于激励测试者又能揭示新的错误。
在组织回归测试时需要注意两点，首先是各测试阶段发生的修改一定要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段。其次，回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改，集中回归。
在实际工作中，可以将回归测试与兼容性测试结合起来进行。在新的配置条件下运行旧的测试可以发现兼容性问题，而同时也可以揭示编码在回归方面的错误。 个人谈谈对于回归测试问题的理解。
首先，回归测试应该是在版本基本稳定的情况下进行。
这点尤为关键！倘若开发人员不断发布待测版本，即版本控制不当，对于回归测试本身，除了工作量明显增加外，更会使得测试人员消息对待每一次发布的测试版本。因为也许会想，不必回归很仔细，反正过两分钟又会发布新的测试版本。当bug发现较多、需求变更过大的情况下，回归测试过程趋向于无穷大，直至等于一次全新的测试活动。
其次，回归测试也可以说是一个完整的测试过程。
具体要看项目组及需求方对于测试要求的定位。回归测试可以选择先前存在的问题进行复测，但是要注意些细节。就是修改或者新添加模块与其他模块及整个系统接口间的“集成测试”。因为哪怕动了一个小的地方，对于版本的稳定和全局性能上都有很大影响。所以回归测试主要是在完成必要功能测试的基础上，多进行性能、安全、稳定、兼容性方面的测试。
再者，利用自动化工具进行回归测试。
如上所述，用工具必须有先前条件，即版本较为稳定，回归测试脚本基于稳定完整的测试用例。否则自动化工具无从入手，你录入每个测试点的过程，其实已经等于完整进行了一次全局的手动测试活动。
以上就是回归测试需要的注意点。也许有人会说我根本没有说到回归测试“用例”。我所说的用例是个通用术语，存在任何的测试阶段。回归过程只是整个测试过程的一个子集，用到的部分用例基于原先模块功能。而设计有效的用例，可以参照我们前期的“每日一贴”^_^
详情可见：http://bbs.51testing.com/thread-110874-1-1.html 关于这个问题楼上的达人们都回答得非常好了！
我随便说说我的看法，只是练个手:loveliness:
在回答这个问题之前，首先我们要搞清楚回归测试的目的、要达成的目标是什么！
在我们的软件开发过程中，只要软件发生了改动，不管是功能的变更、模块的增加或者bug的修改，都会对现有的软件造成影响，也就可能带来问题。当软件的bug被发现提交后，有可能发生以下几种情况：a、追踪系统不够完善，该bug被疏忽没有得到修改；b、开发对于bug的理解不同，造成修改后的结果与期望仍不一致；c、理解不够深入，只修改了bug描述的表面现象，深层原因没有找到； d、bug被修改，但没有考虑到与此问题关联的其他模块；e、本bug被修改，之前被本bug掩盖的其他错误得以显现出来。 回归测试正是为了检查以上情况是否发生，检验已经被发现的缺陷有没有被正确的修改和修改过程中有没有引发新的缺陷，以确保修改达到了预期的目的。
由此我们可以看出进行回归测试的必要性，但在每一次回归测试中遍历所有的用例又是不现实的，特别是在测试后期，所以选择正确的回归测试策略来改进回归测试的效率是非常有意义的，现在就回到我们本次的问题上来。
针对上面列出的几种情况，总结归纳出几种选取回归测试用例的方法：1、发现缺陷的用例，这些用例可以验证发现的缺陷是否得到正确修改，可以完全检测出上述a、b中情况，在一定程度上也可以发现c；2、发现缺陷用例所在模块的其他用例；3、出错模块周边以及与其有联系模块的用例，这些模块的识别可以寻求开发人员的帮助；通过方法2、3，可以基本检测出c、d；另外，通过执行方法1、2、3选取的用例，也基本可以检测e的情况。4、软件的核心用例，这些用例应该在设计测试用例的时候就被定义出，它们体现整个软件的核心流程、必须实现、完成的重要功能点，回归测试时执行它们是为了确定本次修改对核心流程和重要功能是否造成影响；5、如果时间、精力、资源允许，可以再执行全部用例，不过一般很难碰到“时间、精力、资源允许”的实际情况。:L
回归测试一项很重要、但也很费时且重复性很多的活动，同时由于该阶段处于后期，也许错误都被正确的修复好了、也许没有引入新缺陷、执行了很多测试用例都没有再发现新问题（很遗憾，这些情况一般都不会发生），这当然是我们理想的状态，但也容易给测试人员带来疲惫感，所以我认为在回归测试中引用自动化是一项不错的选择，这里的自动化主要针对4中描述的软件核心用例，对于这些每一轮测试都必须执行的用例使用自动化，可以提高不少的效率！
回复 1# 的帖子
最好是向开发询问一下.如果能拿到设计文档就更好了.这样测试人员从文档上就能大致分析新加功能对其它模块的影响了.如果没有文档就与开发讨论,询问关联哪些模块.以方便更有效的设计回归测试用例.
回归测试时,重点就要放在新加模块上.
同时,模块之间的接口也要重点测试,一个也不能漏
再就是数据流程上进行测试
最后按业务流程走一次系统,看是否存在问题.
如果这些都通过了,时间还剩下很多时,可以将之前的用例选择重点进行测试;
如果时间来不急了,就只能放弃了.
对于原系统的部分功能用例可以放在最后面进行测试,如果时间来不急时可以跳过. 回归测试用例包括3种不同类型的测试用例：
1.能够测试软件的所有功能的代表性测试用例，即预测试用例。
2.专门针对可能会被修改影响的软件功能的附加测试。
3.针对修改过的软件成分的测试。 回归测试是个重复繁琐的工作，如果直接选择大量用处不大的用例，直接影响测试人员的心情，效率低下，严重时还遗漏bug，即浪费了时间、浪费人力，又得不到好的效果;
如果回归的用例不足，人、时间当然节约了，但是质量就得不到保障了.
实际工作中进行回归测试前，
首先需要知道哪些地方改过，哪些地方没有改过，改过的地方会对其他地方有什么影响（相关联的地方）
如果能知道可能会引起什么问题那是最好的（必需对软件非常的了解）
针对这些地方再去选择用例，进行回归测试，这样即保证了效率有保证了质量。
对于质量要求高的软件，那就必须进行完全的回归了，这时可以选用自动化工具（公司有条件可以自己开发工具），可以选用QTP,WR等
在软件没有完全稳定的时候可以选用描述性编程。
时间紧迫也可以采用80/20原则，把用户经常操作、还有bug经常发生的地方进行完全的回归或选择有效的用例回归，然后只要保证剩余的模块不出现高等级的bug，其他的地方可以等时间空下来的时候测试人员再进行测试
如果软件几经发布，发现bug以补丁形式发布。
[ 本帖最后由 xxxxwjj 于 2008-5-29 10:09 编辑 ] 现在通用的办法就是，在设计测试用例时，为用例区分优先级，在回归时，只过某一个级别的用例，达到了就算测试完成
这样比较有效，减少冗余测试，又可以保证主要流程。
回归测试因素
回归测试因素一，BUG验证。因素二，需求或设计的更改。BUG验证：只需要运行设计好的用例即可。需求或设计更改后回归：要重新设计或修改用例。
在制定回归测试计划时就要制定回归测试策略，包括时间、人力、财力。根据实际情况来选择回归测试策略：全部回归、修改部分回归、修改及修改可能影响的部分回归。 回归测试目的：提高效率，节省资源，测试以前发现过的问题
适用于重复活动比较多，周期长，功能稳定的项目:victory: 最近正好在考虑如何用少量的人力进行全面的回归测试
首先理解回归测试,现在我们的系统是B/S结构,用户看到的在于B,S是我们维护,回归测试,即修改完BUG和变更需求后,对系统整个一个验收测试;
其次,前期工作,整理出这次的改动点,通过分析,知道这次改动涉及到的模块;
主要工作.使用最新的案例测试改动的模块,其它模块可以在保证流程正常流转下的最小化测试. 当前问题：如何设计或者挑选有效的回归测试用例？
由于需求的频繁变更和修复BUG后确保系统的其它模块没有产生BUG，所以我们要做回归测试，在一个大的系统里面要做完完全全的回归测试在通常的项目里面几乎是不可能。该如何设设或者挑选有效的用例来做高效的选择性测试。
以下本人就说一个解决方案，如果说得不好的地方请大家多多指教。
我们开始逐步来解决以上的问题。
我们如果解决需求变更带来颠覆性测试问题。
一． 拟定需求跟踪矩阵表：把需求规格说明书里面的分析出需求项然后根据需求项分析出需求子项，然后根据需求子项来编写设计测试用例
二． 拟定用例关联表：用来记录用例之间的互相影响关系,这我们就知道那些用例的改变会发现BUG要执行那些对应的用例!
页:
[1]
2
