【转载】Bug定位入门

上一篇 / 下一篇  2014-03-31 10:53:42 / 个人分类:相关知识

【转载】Bug定位入门

上一篇 / 下一篇  2014-02-10 16:24:23 / 个人分类:软件测试

法一:分解法

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

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

我来说两句

日历

« 2024-03-24  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 27001
  • 日志数: 29
  • 书签数: 2
  • 建立时间: 2013-05-17
  • 更新时间: 2015-01-16

RSS订阅

Open Toolbar