我是一名开发
在咱们开发的时间中,其实coding的时间所占比例大概为30%,大部分时间都在自测和改bug
但是许多新人觉得coding才是最重要的,而且把大部分精力花在coding上,其他的(自测,改bug,重构)不太重视
自测和改bug,归根结底就是解决问题.
解决问题的第一步,就是了解问题的现象,这是前提.
所以我们解决bug时,经常提到的一个词就是"重现bug",不能重现的bug,我们是没法改的.
那么重现bug之后,我们应该做些什么呢?
有的人一上来不管三七二十一就去看代码!这太冲动了!
因为有可能根本不是代码的问题!
比如可能是url地址不对,或者传入的参数不对,或者服务器压根没有启动,或者断网了,等等
所以看代码只是最后没办法的行为.看代码是最后一步.
那么不马上看代码,我们要做什么呢?
首先,我们要排除最基本的错误:
(a)url 地址是否正确
(b)参数是否正确,是否缺少参数
(c)端口号是否正确
(d)使用的协议是http还是httpS
(e)服务器是否已启动(服务器状态对不对)
(f)运行的git分支是否正确(本来是在develop上修改的,结果运行的是master分支)
(g)网络环境是否正确,是集测,仿真,还是线上
然后,猜测可能的原因,把最有可能的原因列出来,然后按照优先顺序验证
再次,采用单一项原则,保证只有一个因素是变量,其他因素都排除掉或者定死.
还有一个原则:能细粒度测试的就细粒度测试
什么意思呢?
比如在一个项目里面有个bug,然后你也定位了bug相关的代码
那你怎么解决呢?
一般的新人,就会运行整个项目,搭建环境,启动tomcat,从注册开始,一步步执行下去....
其实就为了验证其中一个很小很小的环节.
所以这种方法可行,但是成本非常高.
如果是我,会怎么做呢?
我绝对不会运行整个项目,而是把bug相关的代码摘出来,然后建一个非常简单的页面或非常简单的工程来研究.
这样有3个好处:
(1)避免了不相关模块的影响
(2)速度快,因为我只是一个页面或者一个非常简单的项目(随手创建的)
(3)符合单一项原则
单一项原则,请参看:
http://hw1287789687.iteye.com/blog/2213879
下面列举几个实际经历的案例
(a)前几天,测试同学说在IE9中下单页显示有问题,服务项单位没有显示云云.
于是我让静态页面同学去看,我并没有马上去.
过了一会儿,我去了测试同学那里,静态页面同学说,有个样式得改.
我让她起来,我来看下.
我打开IE 的开发者界面(按F12),看浏览器,发现浏览器的文档模式是IE7.
问题解决:咱们压根不支持IE7
(b)做T+捆绑时,为了改个东西,给一个DTO增加了有参的构造方法,但是没有加上 无参构造方法,当时觉得没有必要.
然后测试同学就给我报了bug,订单列表报错
后来,我一步步排查,发现是我增加了有参数的构造方法导致的.
因为DTO 反序列化时需要无参构造方法
