开发自测的原则

我是一名开发

在咱们开发的时间中,其实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 反序列化时需要无参构造方法

 

参考:http://www.tuicool.com/articles/nA3aeyn