自动化测试空间: http://www.automationqa.com/ 性能测试讨论群:119821036

bug定位入门

上一篇 / 下一篇  2011-10-11 15:09:26

方法一:分解法

【适用场景】:最终结果依赖与其他用应用或者产品线的请求响应。

【方法】:先排查发出的请求是否正确;在排查响应端的响应结果是否正确;最后分解,缩小排查范围,帮助开发有效定位bug

【举例】:

Bug描述:多次请求,每次返回的推荐关键字均不相同。

问题定位

(1)           通过查看源码,分词正常成功发送匹配请求

(2)     通过firfox找到请求的响应

 (3)     通过向该suggest链接重发请求发现,suggest对相同的分词匹配到的数据,时有时无

因此判断,问题不是出现前端应用, 而是出现在suggest不稳定。

方法二:代码走读debug法

【适用场景】:数据,环境正常,对应代码可见

【方法】:先走读整个代码,重点review与操作功能对应的处理代码;很多隐蔽性的bug通过第一步的review是查不出来的,这个时候就需要debug代码

【举例】:

Bug描述:批量处理进入市场的时候失败。

问题定位:

(1)      Review对应的方法,业务逻辑正确,没有问题

(2)      在代码中设置断点,使用问题数据,进行debug,发现

即map定义为了string,string型,而变量market却是Long型,因此获取market获取时,没有认识long型的market,做了空值处理。

方法三:排除法

【适用场景】:没有任何的头绪,errormassage不能提供任何有用的信息,拿不到对应的代码

【方法】:先排除掉自己想到的可能性,步步为营,层层分离,剩下不确认的,一般便是问题所在,即便是不能完全定位到问题,但是也可以有效的缩小需要进一步定位的范围。

【举例】:

Bug描述:在相同条件下,发布可成功,但编辑失败。

定位过程

(1)数据库中校验当前数据正常

(2)     查看用户信息正常

(3) 同一个用户可发布成功

(4) 排除上面的各个因素之后,可以推测到:在发布和编辑接口对用户信息的处理不一致

(5) 而发布和编辑都调用的同一个c,应该是c的问题


TAG:

 

评分:0

我来说两句

Open Toolbar