码迷,mamicode.com
首页 > 其他好文 > 详细

大话重构连载3:在保险索上走钢丝

时间:2014-07-03 16:17:10      阅读:243      评论:0      收藏:0      [点我收藏+]

标签:重构   自动化测试   高质量设计   

当我们开始系统重构的时候,不是着手去修改代码,而是首先建立测试机制。不论什么程序,只要是被我们修改了,理论上就可能引入BUG,因此我们就必须要进行测试。既然是测试就必须要有一个正确与否的评判标准。以往的测试,其评判的标准就是是否满足业务需求。因此,测试人员往往总是拿着需求文档测试系统。

与以往的代码修改不同,重构没有引入任何新的需求,系统原来什么功能,重构以后还是这些功能。因此,重构的测试标准就只有一个,就是与之前的功能完全保持一致,仅此而已。

然而在许多经典的重构书籍中,大师们总是建议我们首先建立自动化测试机制,这已经被我在无数次实践中证明是不现实的。要知道我们现在重构的是一个遗留系统,它往往设计混乱,接口不清晰,程序相互依赖。所有这些都使得最初的自动化测试变得非常困难而不切实际。

因此,从一开始就实现自动化测试是不切实际的,我们所能采用的还是手工测试。在重构之前首先将系统启动起来,执行相应的功能,得到各自相应的输出。然后开始重构,每次重构对代码的修改量不要太大,花费的时间不要太长。因为,修改量太大,花费时间太长,一旦测试不通过,很难定位错误的原因。在这种情况下,我们只能还原代码,将此次修改的工作完全作废。如果此次修改已经花费了你数天甚至数月的时间,这样的损失就实在太大了。

每做一次重构,修改一点儿代码,然后提交,对系统进行一次测试。如果系统依然保持与以往一样的功能,重构成功,继续进行下一次重构。如果不是,你不得不还原回来重新重构。频繁地测试着实让你挺烦的,但却有效减少了重构失败带给你的损失。一个折中的办法就是,平时频繁测试的时候,测试项目少一些,只测试主要项目,定期再进行全面地测试。录制QTP[1]脚本也是一个不错的方式,它虽然有诸多问题,但却可以在系统重构初期有效地建立自动化测试,系统级别的自动化测试。随着系统重构的不断深入,我们的程序开始在改善,耦合变得越来越松散,程序变得越来越内聚,接口变得越来越清晰。这时候,当自动化测试条件成熟时,我们才可以逐渐开始自动化测试,而这种自动化测试才是建立在代码级别的真正的自动化测试。

一旦某个修改测试不通过,则还原回来。这种一次一小步的修改模式,我们形象地称之为“小步快跑”。在测试集成工具的不断监督下一点一点地修改程序,是系统重构异于以往的另外一个特点。通过小步快跑可以使我们在重构的过程中,以最快的速度发现修改的问题,将因修改错误带来的损失减到最小,毕竟是人都不可能避免犯错。


[1] QTP,Quicktest Professional的简称,是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试,主要是用于回归测试和测试同一软件的新版本。

大话重构连载首页:http://blog.csdn.net/mooodo/article/details/32083021

特别说明:希望网友们在转载本文时,应当注明作者或出处,以示对作者的尊重,谢谢!

大话重构连载3:在保险索上走钢丝,布布扣,bubuko.com

大话重构连载3:在保险索上走钢丝

标签:重构   自动化测试   高质量设计   

原文地址:http://blog.csdn.net/mooodo/article/details/36447771

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!