回归测试（精选5篇）
篇1：回归测试
回归回归散文
听爹说，从前村子筑有围村墙，设四门。专人看守，易守难攻。
那年，张老汉打完三更梆子，进屋，倚在炕头抽旱烟解乏。
“咣，咣，咣……”城门山响。他打个寒颤，吹灭油灯，屏呼吸，辨凶吉。
“咣，咣，咣……”再响，他拎锣拿锤，蹑手蹑脚，耳贴城门。
“我是银盒，开门!”外面，那汉子开始自报家门。乡音浓重而沙哑。
“你，你，你是人是鬼?”张老汉捏铜锣的手都出了汗。
“我是人，不信您点灯。人有影儿，鬼没有”。
张老汉依旧不相信是老街坊归来。
“您老千万别敲锣，兵荒马乱、深更半夜的，别吓着乡亲们。俺城门外蹲一宿也成，就问一句，俺娘和妹子好着吗?”门外汉子知趣等待。
张老汉暗自嘀咕：今儿撞见死人还阳，倒霉运!为壮胆他破口大骂：“你这该死不得活的银盒子，狠心贼，一走五年，你娘早就饿死了!”“我妹子呢?”“改了(出嫁)!”……张老汉话虽狠，手却颤抖着拉开了门栓。
外面汉子一头撞了进来，险些扑倒张老汉。
那汉子在自家门前站定。伸手，他的.手碰到一把锁，冰冷、锈蚀。泪水滂沱。卸门，进院。鼠辈受扰，速逃。借火镰点燃几株干草，环顾家园，蒿草齐腰，门窗大开。
“娘……!妹子……!!”那汉子依墙，嚎啕。
“你娘没死，嚎鬼的丧!还不快去后村你二姐家!”身后，打更人再次骂道。
汉子猛起，抹泪作揖，朝着村后飞奔……
篇2：回归测试
二妮是村小学校长的二闺女，村里公认的听话乖巧的女孩，高中毕业后在村幼儿园工作。
林峰是村长的小儿子，天生爱幻想，用村长的话说，有点好高骛远。高考落榜后，也在村小学代课。
转眼，二妮和林峰都到了谈婚论嫁的年龄。在这个闭塞的.小山村里，要想找一个志同道合又门当户对的对象，还真不是一件容易的事情。
每逢周末，二妮家总会有媒婆上门提亲。林峰呢，周末几乎也都是在县城度过，干嘛去呢?相亲呗!
眼看他们俩都进入剩男剩女的行列，依然都没有找到合适的主。一天，村小学的教导主任跟林峰半开玩笑地说：“林老师，你感觉幼儿园的二妮老师怎么样?”林峰笑着说：“她，很好呀。”主任接着说：“介绍给你做对象如何?”林峰想也没想：“那怎么可能?”主任打破砂锅问到底：“怎么不可能呀?”林峰用手拨了一下自己新梳的发型，坏坏地笑着说：“我们不是一路的人。”
从外表看，二妮的穿着比起在县城里读了5、6年书的林峰是有点土气，但二妮在家里家外都是一把好手，深得全村人的交口称赞;而林峰呢，仗着家底殷实，平时做事多少带有一点眼高手低的习气。
主任想撮合这桩美事的想法让村长知道了，村长连夜去主任家拜托，请主任第二天就到校长家提亲。主任说林峰还没点头同意呢。村长说这个家他来当。
主任去了校长家提亲回来说，二妮全家都没有意见，就看林峰什么态度了。村长说儿子也点头了，要主任去校长家商量择日订婚吧。
主任有点不敢相信自己的耳朵，村长说：“我使出了杀手锏，他不应这门婚事，就跟他断绝父子关系。这招还真灵!”
真是好事多磨。订婚的那一天，村长在家里摆了十几桌酒席，小村里家家户户几乎都请到了，林峰也一改往日的桀骜不驯的做派，笑容可掬的给来参加订婚宴的宾客递烟敬茶。
篇3：面向对象回归测试的方法
软件维护活动成本占软件产品总成本的40%上,回归测试是软件维护活动一个必要组成部分,它用来确保修改后软件的正确性,提高软件产品质量。回归测试成本是昂贵的,它占软件维护活动成本的1/2左右。软件产品在软件维护阶段,由于用户需求或者功能发生变化而需要对软件作出修改,要确保修改后软件的正确,进行的测试被称为回归测试。回归测试需要解决3个基本问题:(1)怎样鉴别那些受到修改影响的部分(修改影响分析);(2)采用什么策略来重测受到影响的部分;(3)测试用例排序,即测试用例的执行顺序。
1 鉴别受到修改影响的部分
作为面向对象软件,类是一个最小单元,以它来创建软件类关系图进行分析软件修改受到影响是比较全面的,本文在类关系图的基础上提供一个有选择策略测试技术。
找出受影响的类从3个方面考虑:(1)统计修改的类以及受影响的类。建立类间关系图,找出修改的类以及影响的类;(2)统计类中成员函数发生的变化的类。建立图类成员函数图,找出相应的继承关系类和应用关系的类,为了考虑程序的安全性,我们除了要考虑全部涉及修改的类以及它的继承类外,还要考虑其引用类;(3)根据所有修改的类,进行测试用例选择。
2 重测受到影响部分的策略
对受到影响部分,重测所有用例会花费不必要的成本,而通过测试选择技术,复用已有用例,从原有用例集中选择部分用例进行测试,可以减少回归测试成本。当测试一个程序时,测试员衡量测试用例集对程序的覆盖范围,这样的工具很多,我们可以用矩阵来表示,如表1所示。
测试用例本文采用的方法是对所有受影响的类,从测试用例集中找出覆盖这些类的测试用例。
从表1中可知:测试用例t1类c1和类c2,测试用例t2覆盖了类c1和类c3,t4覆盖了类c1,c3和c4,而t3没有覆盖任何类。而我们选择最少覆盖的一个类的测试用例,为了精简测试用例,故我们选择测试用例t2和t4就可以测试受影响的类c1、c2、c3和c4。
3 测试用例排序方法
回归测试选择技术存在以下不足:(1)最小策略可能导致用例的错误检测能力下降;(2)在无法对所有被选择的用例进行测试的情况下,不能保证测试可信度。
测试用例排序技术是根据给定的测试准则对测试用例集中排序,对优先级高的优先测试。我们将测试用例排序技术引入回归测试选择技术中,可以有效解决以上不足。(1)测试用例优先排序使用如下准则进行排序;(2)错误检测率,即尽可能早的在测试过程中暴露错误;;(3)覆盖率,即使用例覆盖尽可能多的程序语句、程序流图的边和分支;(4)系统可靠性,即尽可能早的确认系统可靠性;(5)高风险错误检测率,即尽可能早的发现可能导致较高风险的错误;(6)相关代码错误检测率,即尽可能发现与特定代码相关的错误。
本文采用准则1,即错误检测率来作为排序准则。因为高错误检测率有如下优点:(1)有助于开发人员尽早开始程序调试、修改,从而加快版本发布进程;(2)有助于尽早获得对程序修改正确性的反馈,有助于在测试过程意外中断时,尽可能提高测试效率。
本文采用平均错误检测覆盖率来对用例进行排序,考虑测试用例集T,包含A、B、C、D、E,错误检测情况如表2所示:
我们根据表的例子来说明测试用例排序不同,对代码检测率也不同。如测试用例执行的顺序是A-B-C-D-E如图1所示,执行测试用例A后,能够检测出两个错误,还有80%未检测出来,再执行测试用例B后,又多检测出了两个错误,还有60%未检测出来,依次类推,最终未检测的覆盖率为50%。而测试用例排序为C-E-A-B-D如图2所示,执行测试用例C后,未检测错误40%,再执行E后,则全部检测完错误,故未检测的覆盖率为16%。
因此对于测试用例排序是非常重要的,而对于我们找出测试用例t2和t4,如果执行的顺序是t2、t4,则未检测的覆盖率为50%,而t4、t2执行未检测的覆盖率只有25%。
4 结束语
完全回归测试不仅没有必要,而且由于测试成本等原因,也是不可能的。本文对面向对象软件类进行分析,从而产生测试用例,再对测试用例进行排序。这种方法即经济,又可靠和有效。
摘要：对面向对象软件回归测试的方法进行研究,该方法先对类及受影响的类进行分析,找出这些类,然后从测试用例集中找出覆盖所有受影响的类,最后进行测试用例排序进行执行。这种方法有效、经济和安全。
关键词：测试用例,类分析,用例选择,用例排序
参考文献
[1]张志军.面向对象软件的回归测试策略研究[D].中国优秀博硕士学位论文全文数据库(硕士),2005.
[2]陈茹.基于多层次功能模型的软件回归测试技术研究[D].中国优秀博硕士学位论文全文数据库(硕士),2004.
[3]Ren F,Shash F,Tip F,et al.A Tool for Change I mpact Analysis of Java Programs.Technical Report DCS-TR-551,Depart ment of Computer Science,Rutgers University.2004(6).
[4]Rothermel G,Harrold MJ,Dedhia J.Regression Test Selection for C++Software.Journal of Software Testing Verication,and Reliability.2000,106,10(6):77109.
[5]Mary Jean Harrold,James A Jones,et al.Regression test selection for Java software.2001:312-326.
[6]胡岳峰.两两组合覆盖测试用例生成研究及优化[D].中国优秀硕士学位论文全文数据库,2008.
篇4：浅谈软件测试中回归测试
关键词：软件测试；回归测试
中图分类号：TP311.52文献标识码：A文章编号：1007-9599 (2011) 03-0000-01
Regression Testing of Software Testing
Fan Xuedong
(Xi'an Foreign Affairs University,Xi'an710077,China)
Abstract:Regression testing despite the tedious,repetitive,but it must do the test,whether to take automated testing tools,or other test method is the problem discussed in this article.In this paper,the nature of regression testing,discusses the key,importance and testing methods,have their academic and practical significance.
Keywords:Software testing;Regression testing
一、概述
所谓回归测试就是当軟件发生改变时，重新测试已经通过测试的测试区域，以验证修改的正确性及其影响。在软件开发生命周期中，软件发生改变，就会带来问题。改变可能是源于发现了错误并做了修改，也有可能是因为集成或维护阶段加入了新模块。错误跟踪与管理系统不完善；对错误的理解不透彻，只修正了错误的外在表现，从而造成修改失败；修改还有可能产生副作用，从而导致软件未被修改的部分产生新的问题；新加入代码还有可能对原有代码带来影响。因此，我们就必须重新测试，以便确定修改是否达到了预期的目的。同时，为了验证修改的正确性及其影响就需要进行回归测试。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。
二、测试的大部分工作是做回归测试，软件一旦作了修改就必须进行
项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。回归测试需要时间、经费和人力来计划、实施和管理。在给定的预算和进度下，需要对测试用例库进行维护并依据一定的策略选择相应的回归测试包。
（一）首先必须有个管理良好的测试用例库，用例库中的所有用例必须有效，达到足够的覆盖率。这需要有良好的测试管理工具，并有相应的资源（时间与人力）去维护这个测试用例库，使其中没有过时，冗余的测试用例。如何管理组织好测试用例库是一个值得深入研究的课题，要做好回归测试，组织管理良好的测试用例库是前提。测试用例库的维护为了最大限度地满足客户的需要和适应应用的要求，软件在其生命周期中会频繁地被修改和不断推出新的版本，修改后的或新版本软件会添加新的功能或者变化。同时，被修改的或新增添的软件功能，仅靠重新运行以前的测试用例不行，必须追加新的测试用例来测试。
测试用例库维护是一个连续的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括：（1）删除过时的测试用例。因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统，这些测试用例就会过时。（2）改进不受控制的测试用例。随着软件项目进展，库中的用例会不断增加，会出现对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制，影响测试效率。（3）删除冗余的测试用例。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库，并将冗余的用例删除掉。（4）增添新的测试用例。程序段、构件或关键的接口在现有的测试中没有被测试，就应该开发新测试用例。不仅改善了测试用例的可用性，而且也提高了测试库的可信性，同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。
（二）回归测试的实质在于它是一个能够检测到回归错误的受控实验。回归测试包的选择在软件生命周期中，即使一个得到良好维护的测试用例库，也可能变得相当大，这使每次回归测试都重新运行完整的测试包变得不切实际。当测试组选择缩减的回归测试时，有可能删除了将揭示回归错误的测试用例，消除了发现回归错误的机会。然而，如果采用了代码相依性分析等安全缩减技术，就可决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括：（1）再测试全部用例。选择基线测试用例库中的全部测试用例组成回归测试包，这是比较安全的方法，它具有最低遗漏和风险，但测试成本最高。往往超出我们的预算和进度。（2）基于风险选择测试。可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，其严重性也仅有三级或四级。（3）基于操作剖面选择测试。若基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可由测试预算确定，优先选择针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别风险，有助于尽早发现那些对可靠性有最大影响的故障。（4）再测试修改的部分。当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。
再测试全部用例的策略是最安全的策略，但过时回归测试不太可能揭示新的错误，而且由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可选择适当的策略进行缩减的回归测试。
（三）实际工作中，回归测试需要反复进行，回归测试的基本过程有了测试用例库的维护方法和回归测试包的选择策略。回归测试可遵循下述基本过程进行：（1）识别软件中被修改的部分；（2）从原基线测试用例库中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T。（3）依据一定的策略从T中选择测试用例测试被修改的软件。（4）若必要可生成新的测试用例集T1，用于测试T无法充分测试的软件部分。（5）用T1修改后的软件。第b和第c步测试验证修改是否破坏了现有的功能，第d和第e步测试验证修改工作本身。
三、结论
（一）无论采取何种策略，回归测试是必须的一种测试。回归测试时我们必须采取一些较为有效的方法。例如安排新的测试者完成手工回归测试，让更有经验的测试者开发新的测试用例，做一些探索性的测试。但最重要的就是基于实际可行的引进自动化测试，因为机器不会累。实际中，回归测试的重复将非常令人厌烦，因此，需要通过自动测试来实现重复的和一致的回归测试，提高回归测试效率。
（二）在测试软件时，应用多种测试技术是常见的。测试时，测试者希望采用多于一种回归测试策略来增加修改软件的信心。如果回归测试包不能达到所需的覆盖要求，必须补充新的测试用例。回归测试是重复性较多的活动，容易使测试者感到疲劳和厌倦，降低测试效率，在实际中可以采用一些策略减轻这些问题。可以在不影响测试目标的情况下，鼓励测试者创造性地执行测试用例，变化输入、按键和配置能够有助于激励测试者又能揭示新的错误。
（三）回归测试需要根据项目、测试资源等实际情况采取有效计划和组织。其中需要注意的是必须重视回归测试，在测试计划中有很好的进度安排及选择相应的回归，重视测试用例的维护，借助于自动化工具。在组织测试时需注意：首先是各测试阶段的修改一定要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段。其次，测试期间应对软件版本冻结，将测试发现的问题集中修改，集中回归。建议将回归测试与兼容性测试结合起来。在新的配置条件下运行旧的测试可以发现兼容性问题，同时也可以揭示编码在回归方面的错误。
参考文献：
[1]贺平.软件测试教程.电子工业出版社,2010,1
篇5：基于UML的回归测试研究
回归测试是面向对象系统的一个有效测试过程的必要部分。当代码修改或配置改变后，都必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否对软件的其他功能没有产生副作用。同时，还需要补充新的测试用例来测试新的或被修改了的功能。所以回归测试应该包括两部分：对修改部分的测试以及与修改相关代码的测试。对被修改部分的重新测试，如果修改部分的功能以及接口没有发生变化，可以直接运行原来的测试用例。但是如果修改导致功能或接口发生变化，则要根据修改后的功能点或接口的变化增加、删除或改进测试用例。由于程序的修改会对软件产生涟漪效应，因此对与修改部分有交互关系的代码也要进行重新测试，以此来保证修改没有对软件产生不良作用。
在渐进和快速迭代开发中，回归测试会更加频繁，测试用例集不断扩大，回归测试成本也随之剧烈增加。由于测试用例集不断重复，因此对测试用例集的微小瘦身都会对成本带来巨大的收益。
本文将详细介绍面向对象系统回归测试中遇到的问题，从全面测试和高效测试的角度，给出一个基于依赖集和优化技术的回归策略。
1、面向对象的回归测试
1.1 面向对象的测试
面向对象程序设计语言的基本特征是提供了数据抽象、继承和动态绑定等设施。一方面通过软件重用提高了软件生产率和可靠性，但另一方面也影响了软件测试的方法和内容。
在面向对象系统中，系统的基本构造模块是封装了的数据和方法的类和对象，而不再是一个个能完成特定功能的功能模块。每个对象有自己的生存周期，有自己的状态。消息是对象之间相互请求或协作的途径，是外界使用对象方法及获取对象状态的唯一方式。对象的功能是在消息的触发下，由对象所属类中定义的方法与相关对象的合作共同完成，且在不同状态下对消息的响应可能完全不同。系统执行中对象的状态可能被改变，产生新的状态。由于对象中的数据和方法是一个有机的整体，在测试过程中要充分考虑面向对象的特点，不能仅仅检查输入数据产生的输出结果是否与预期的吻合，还要考虑对象的状态。
1.2 回归测试
在软件开发过程采用层次增量模型，需要在整个开发过程采用回归测试。当一个类改变后，对类本身、子类关于继承、多态、动态绑定和封装以及使用该类的应用程序必须进行回归测试。而类的改变主要表现在对象属性或方法的修改；对类属性的修改，需要对所有与该属性有依赖关系的类都必须重新测试。对类方法的修改，要根据修改某方法对类的影响程度，可将其修改分为如下三类形式：
(1) 对某类中方法的内容修改，不影响类中各方法之间的调用关系。
(2) 对方法的修改，影响到类中方法间的调用关系。
(3) 类或类中方法的改变影响了其它类。
对 (1) 情况，重新修改所改变的方法测试用例，而对该类其余部分的测试用例不变；对 (2) 情况，只需对所修改的类进行重新测试，而该类与其它类集成的测试用例不变；对 (3) 情况回归测试应包括两部分：一、必须构造足够的测试用例，按其测试准则（覆盖准则或其它），对该方法进行充分测试；二、找出所有与该方法有依赖关系的类，必须构造新的测试用例并对它们的交互进行充分测试。从上面的分析来看对类方法修改的 (1) 和 (2) 情况回归测试相对简单就不再介绍。本文重点是对类属性的修改和对类方法的修改 (3) ，需要重新测试所有与修改有依赖关系的类。
为修改类构造一个依赖图，根据类依赖图决定选择哪些测试用例。如果依赖性分析是正确的，根据它所产生的回归测试包就是安全的缩减。所以依赖性对回归测试具有重要的意义。
2、构建回归测试的依赖集
2.1 面向对象的类图分析
在基于UML的面向对象系统中，类图表达了面向对象系统分析中的最基本元素--类和类之间联系，UML提供多种描述类与类之间的关系：依赖（Dependency）、关联（Association）、泛化（Generalization）、实现（Realization）等。两个类之间的依赖关系具体体现为一个类的属性和操作与另一个类的属性和操作之间的依赖关系。由于关联、聚集、泛化属于较弱的依赖关系，本文将它们归为依赖关系。这样就可以将类图转化成类之间的有向依赖图，在回归测试的过程中，类图有利于静态地分析和研究面向对象系统间广义的依赖关系。
关联依赖：UML类图G中类间的关联关系描述了给定类的单独对象之间语义的链接，提供了不同类间对象可以相互作用的连接。关联可以是二元的。
聚合依赖：聚合关系是关联关系的一种特殊形式，表示类与类之间的"整体-部分"关系。如果部分类完全隶属于整体类，且部分类与整体类有共同生存期，则这样的聚合关系是强聚合关系；否则为弱聚合关系。
继承依赖：继承是一种机制, 继承类（子类）共享了行为上相关的被继承类（父类）的结构和行为，继承机制既可以避免重复定义属性和方法，同时也使得类间的层次关系变得更加清晰和直观。
以教学管理系统为例，下图显示教学管理中各类之间的关系。
2.2 构建类依赖有向图
对于给定的UML类图G, UML类依赖图是用二元组表示的有向图K=<S, E>，其中：S是类的集合；E是边集。
本文采用邻接表来构建类图，将类图中的每一个类看作一个节点，每个节点都包含类名、属性名、操作名等信息，类中的关联、泛化、聚合等依赖关系看作节点间的边，将类图作为初始条件输入，寻找每个类与其它类的依赖关系来构造依赖有向图。
具体算法实现如下所示：
输入:类图G的邻接表
输出:类依赖图K=<S, E>
初始化:S=覫;E=覫;
(1) For每个c1∈G do
(2) For每个c2∈G并且 (c1≠c2)
(3) If c1和c2之间存在关联时
(4) 就将c1的指针指向c2，构造一条有向边
(5) If c1和c2之间存在c2指向c1的聚合、泛化、依赖关系
(6) 就将c1的指针指向c2，构造一条有向边
(7) End For
(8) End For
2.3 构建类测试依赖集
在类依赖图中，寻找所有与修改类有依赖的类集合。具体是从修改类出发寻找一个没有入点的类，将遍历过的所有类加入集合，就得到该修改类的依赖集。
具体算法如下：
输入:依赖图K和节点 (即修改类) c3
输出:数组T (T中的节点)
(1) 以c3为根节点
(2) 从c3的未被访问的邻接点中选取一个顶点w，从出发进行深度优先遍历。
(3) 重复上述两步，直到图中所有和c3有路径相通的节点都被访问到，并将这些节点存入T。
3、测试用例集的缩减
根据上面构建的依赖集，找出测试该集中类的所有测试用例。运行这些测试用例观察测试结果。但是这些测试集中存在冗余和无效，导致回归测试效率的降低，对提高测试效率的测试工作是不合适的。为了达到减少测试成本，提高测试效率的目的，本文对采用优先技术对这些测试用例进行排序。
首先为基于依赖集的每个测试用例赋予一个优先级，在测试过程中按照测试用例优先级顺序来选择执行测试用例。当被测程序中包含某类错误比较多时，优先运行可以检测这类错误的测试用例就有助于提高测试的效率。在测试过程采用启发式方法来预测那些测试用例应该优先执行。对当前测试无用或冗余的测试用例删除，保证测试用例集的有效性和完整性。
4、结束语
软件回归测试在软件测试中扮演着重要的角色。软件回归测试是花销很大的测试，如何进行有效的回归测试，如何有效减小回归测试用例集是软件回归测试研究的重点和难点。本文给出的回归策略是结合我的工作提出的，它能够提高效率和减少成本。但它不是"万能的"。在回归测试中要充分考虑到各个方面的因素制定好的回归策略。
参考文献
[1].华庆一, 王斌君等译.面向对象系统的测试[M].北京:人民邮电出版社, 2001
[2].方朴, 孙家肃等.面向对象软件回归测试技术研究[J].软件学报, 2001:12 (03)
[3].胡顺仁, 王铮, 邓毅.基于UML构造回归测试依赖集[J].计算机工程与应用, 2003.5
[4].李必信, 王云峰, 张勇翔等.基于简化系统依赖图的静态粗粒度切片方法[J].软件学报, 2001, 12 (2) :204-208