软件测试中的回归测试漫谈

　　众所周知软件测试这个职业有一个为从业者不悦的一个特点就是有时特别烦琐,要经常做重复性的东西,相信同行或多或少都会有这个感慨,而罪魁祸首就是回归测试.如果每次测试的功能点都是新的,每次执行的测试用例都是未曾执行过的话,我相信同行都不会觉得厌烦反而很有兴致想看下新的功能是怎样的,执行起用例来也特认真.我也是如此,如果做久了一个项目特别是总是推迟发布的话每天就祈祷着当前项目快点了结.一接到新项目就有如获新生的感觉...确实回归测试次数多了,测试员不由变得烦躁起来,特别如果是回归测试策略又不妥当的话简直令人发疯....

　　我深受其害.进新公司近半年来还没有完全是自己负责的项目,除了花了一定的时间做自动化方面的东西外,其它的时间就是执行测试用例了,当然也就有大量的回归测试了.更郁闷的是没有相应的回归测试策略,而且不少测试用例已经不再适用了,数量又多(以前新功能测试的用例),我逐渐变得厌烦,然后是麻木,最后几近崩溃.一个汗啊...痛苦泥潭中的只好搜索相关资料并结合自己的实践,总结下如何更有效地做回归测试,让回归测试做得更有意义.

　　所谓回归测试就是当软件发生改变时,重新测试已经通过测试的测试区域,以验证修改的正确性及其影响.其实我们做测试的大部分工作也是在做回归测试,严格按照定义的话一旦软件作了修改就必须进行回归测试.我想对修改过后的软件要进行回归测试应该就是无可厚非的,无论是教科书上的介绍还是前人的经验总结都知道回归测试的必要性与重要性.那非要做回归测试,那样怎样才能做得更为有效有意义呢?显然这都需要从测试用例着手.

　　首先我们必须有个管理良好的测试用例库,这个用例库中的所有用例必须是有效的,有达到足够的覆盖率,并且是容易查找组织的.这需要有良好的测试管理工具,并有相应的资源(时间与人力)去维护这个测试用例库,务必使其中没有过时,冗余的测试用例,并达到一定的覆盖率.如何管理组织好测试用例已是一个很值得深入研究的课题,在此不再阐述(我也没有很好的见解..)总之,要做好回归测试,组织管理良好的测试用例库是前提.

　　有了测试用例库,那我做回归测试时就执行所有有效的测试用例?这个没有绝对的答案,在很多的时候如果你有足够的资源用全部测试用例来做回归测试是最佳选择. 但现实中呢?有足够资源这个理想状态比较少,并且有些时候也没有必要这样做.如果只是修改了某个警告对话框中的单词就要执行完所有测试例以确保其修改正确性及其影响?或许你会说只有疯子才会那么做,但事实上有时候我们正是那个疯子.基本上很多时候连开发自己都不敢肯定会不会影响到其它部分,所以我们就不得不扩大测试范围.那应该如何选择回归测试使用呢?前人已经总结了很多,主要是如下4种.

　　1>选择全部测试用例

　　选择测试用例库中的所有测试用例作为回归测试用例,这是一个较为保险的方法.在理想的状态下(有足够的资源,测试人员不知疲惫),这种方法绝对是首选.但理想与现实的差距是惨不忍赌的,测试资源缺乏是行内常情,特别是由于进度而导致测试时间极为苛刻,而且测试人员会因多次执行相同用例而产生厌烦,这对测试质量影响是非常大的.所以,无论从现实资源考虑还是从成本上考虑都不可能每次回归测试包都是选择所以测试用例.

　　2>基于风险选择测试用例

　　这是基于一定的风险标准从测试用例库中选择部分测试用例形成测试包.按测试优先级来来选择最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例.这样测试任务会大为减轻但效果并不差,因为由此没有被发现的缺陷是较少并严重性较低的.

　　3>基于操作剖面选择测试用例

　　这种方法适用于测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试时可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。

　　4>再测试修改部分

　　这种是基于开发对修改的影响区域有较大把握时所采取的一个策略.通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上,此时只选择相应的测试用例来做回归测试.此策略风险最大,但成本也是最能低的,通常用于做小回归测试.

　　以上四种回归测试策略各有优缺点,实际应用中应根据项目的资源,进度及项目开发的模式等实际情况来选择最优策略.

　　1>一般情况在在一个非用于基线的build中作了小修改,建议采用策略4,只测试修改部分,因为现在的开发流程中build更新较快特别是极限编程中,要进行完全的回归测试是比较不现实的,即使有自动化工具的辅助亦未必能实现.

　　2>在一个milestone中,一个作为基线的build中则可采用策略2或3,基于一定的风险选择测试,这是一个较为折中的办法,但如果资源允许的话建议进行全回归测试.

　　3>较重要的mileStone或是最终版本,最好选择全回归测试.因为如果一般来说此时软件改动会较大,选择全部测试较为保险.当然这还是要依据当时的实际出发.

　　但无论采取何种策略,回归测试还是让人欲弃之不做却又不得不做的一种测试,因为它重复多并且经常工作量大但经常发现的缺陷相对工作量来说太少.但是谁都不敢承担不做回归测试带来的后果,真是食之无味,弃之不能.所以在做回归测试时我们必须采取一些较为有效的方法来保证做好回归测试.例如安排新的测试者完成手工回归测试,让更有经验的测试者开发新的测试用例，编写和调试自动测试脚本，做一些探索性的或ad hoc测试。或是采取轮流执行不同模块,尽量避免一人一直测试某一模块,不论从测试员感受还是测试效果来看,这都是一个不好的方法.但我觉得最重要的就是基于实际可行的话引进自动化测试,因为机器不会累,可以日夜跑.

　　回归测试这个令人头痛的问题需要根据项目跟测试资源等实际情况来采取更有效的策略来解决.其中需要注意的是必须重视回归测试,在测试计划中有很好的进度安排及选择相应的回归策略,重视测试用例的维护,借助于自动化工具. 

原文转自：http://www.ltesting.net