回归测试漫谈

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

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

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

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

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

　　1>选择全部测试用例

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

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

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

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

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

　　4>再测试修改部分

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

原文转自：http://www.uml.org.cn/Test/200902266.asp