我是一名开发
在咱们开发的时间中,其实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