回归测试漫谈(2)

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

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

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

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

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

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

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