面对测试人员bug定位方法

Bug定位方法流程分解

         在开始发现一个bug的时候就要根据具体的问题和反应，根据我们前面说的如何定位前端bug，首先判断是属于前端bug还是开发的bug，当明确了是开发的bug后，可以开始使用如下的bug定位方法了。

一般定为bug的流程：

一、看Log日志-日志定位为基础

Log日志：主要用于记录程序运行的情况，以便于程序在部署之后的排错调试等等！也有利于将这些信息进行持久化（如果不将日志信息保存到文件或数据库，则信息便会丢失）

清楚日志存放的地址：/home/a；/home/admin/ 详细见下文log的查看方法

log的级别(level)

DEBUG < INFO < WARN < ERROR < FATAL

Debug级别可以输出所有，info只能输出 它的级别以上的信息。

开发的时候一般用debug，部署的时候用warn

log.error：错误信息

log.debug：详细的程序逻辑信息，一般用在本地，线上不用，原因，信息量过大，日志会爆

log.info：自己定义的一些信息，方便自己查看

log.warn：警告提示信息，一般不影响主流程，不算做错误级别

Log的查看方法

通过查看程序日志可以发现错误所在的类甚至代码行。下面介绍日常环境下查看logging的

方法：

1、  安装secureCRT 。

2、  页面上查看日常环境服务器，通过ping机器名的方式获取服务器ip。

3、  将获取的ip填入，用户名

4、  输入密码

5、  cd 到log目录，log的目录一般是/home/admin/应用名/logs ，如hesper是：/home/admin/hesper/logs

6、  cat 打开日志文件，如:cat hesper.log   也可以用 tail –f hesper.log 打开文件（实时显示文件更新）

然后就是日志分析：

1、  一般只关注warn以上级别的日志。

2、 错误都会先报出来, 然后 Caused by ….  那些都是引起错误的地方, 但是插入点应该是一开始

3、 有提示类的日志问题

Caused by: java.lang.IllegalArgumentException: TurbineRunData not found in request attributes

  at com.alibaba.citrus.util.Assert$ExceptionType$1.newInstance(Assert.java:228)

  at com.alibaba.citrus.util.Assert.assertNotNull(Assert.java:74)

  at com.alibaba.citrus.util.Assert.assertNotNull(Assert.java:62)

  at com.alibaba.citrus.turbine.util.TurbineUtil.getTurbineRunData(TurbineUtil.java:29)

       at com.alibaba.citrus.turbine.util.TurbineUtil.getTurbineRunData(TurbineUtil.java:18)

一般caused by 下第一行为错误方法

可以用自下而上法，先查看发布结果，为成功或者失败，如果失败再往上找到原因

org.jboss.deployment.DeploymentInfo@c6b2e6df { url=file:/D:/workspace/dianping/dianping-web/target/exploded }

  deployer: org.jboss.deployment.JARDeployer@15fb38

  status: Deployment FAILED reason: URL file:/D:/workspace/dianping/dianping-web/target/exploded/dianping.war/ deployment failed

  state: FAILED

  watch: file:/D:/workspace/dianping/dianping-web/target/exploded

  altDD: null

  lastDeployed: 1309405050921

  lastModified: 1309404985890

  mbeans:

然后往上找到最近的deployment failed的cause by 信息来排查问题，cause by存在层级关系由上级影响下级，最后一个cause by一般为根源问题。它是导致上一个cause by的原因。通过cause by的信息能找到出错的方法或者类，然后到代码和源码中进行review排查问题，并且修复问题。

4、正常日志无提示和错误的情况分析：有可能程序中，没有异常打印，只是catch掉了。如果要处理需要调试，找到对应位置添加捕获条件。

5. 对日志问题的判断

报错的地方：通过最直接的日志反应和提示能直接发现错误和问题，已经提示中都会提供给我们对应位置行数的信息

a)    内部问题，一般是有行数

b)    外部问题，一般无行数。例如依赖其他关系，其日志信息可能只能反映为超时，为空，无返回结果等，也是一个基本的划分方式

方法局限：

只能验证代码没有运行时的错误，不能证明业务逻辑正确。只是一种排查的手段供大家参考。

二、检查代码，调试程序(内部问题)—熟悉代码是必备

通过查看日志可以发现问题代码的行数，在查看和调试，需要对代码的熟悉程度很高，很清楚代码的逻辑方式，对于测试人员能提供给开发对应的行数或者功能块就已经达到目标，如果要帮助深入和查到对应串的什么问题，怎么修改，就看个人的时间投入和精通程度了。在这里不做强求

看代码（调试）的常用工具，我们可以采用

清楚各个区块代码之间的相互关系和先后顺序已经处理逻辑，该块内容没有捷径，需要非常熟悉实现的代码，基本都是具体问题具体排查。

1. 方便Debug调试方法技巧：

关联第三方源码，方便debug

在调试中，使用工具eclipse，可以动态改变参数的值，来更好的调试各种边界值的影响，定位到细节中

方法一：代码走读debug法

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

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

【举例】：

Bug描述：spu对应的类目以进入3c垂直市场，已进入3c垂直市场的spu退出，通过批量处理进入垂直市场的时候，不能成功进入。

视图：

问题定位：

(1)  Review spu进入垂直市场的方法，spuSetVerticalMarketFlag（），业务逻辑正确，没有问题

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

reConvertMap.get(verticalMarket) 在此步时，获取到的是空值，但是变量verticalMarket确实有值的

查看reConvertMap和verticalMarket的定义，发现

public static Map<String,String> reConvertMap = new HashMap<String, String>();//用于垂直市场的Map转换类目上的vm这个feature

Long verticalMarket＝0；

即map定义为了string，string型，而变量verticalMarket却是Long型，因此reConvertMap.get(verticalMarket)获取时，没有认识long型的verticalMarket，做了空值处理。

开发最终解决方案：

reConvertMap.get(verticalMarket+”") 做字符串处理

方法二：排除法

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

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

【举例】：

Bug描述：在标准垂直类目和垂直属性下，编辑已有的网游宝贝，系统提示异常。

定位过程：

(1)  数据库中校验垂直类目和属性，property_id=5386502andcategory_id=50016910正常

(2)       查看用户信息user_id=175754661.查看cache中用户的user_tag信息为1549070721，正常

(3)  同一个用户在，相同的垂直类目和属性下发布网游宝贝，发布成功

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

(5)  而发布和编辑都调用的是vic，应该是vic的问题

开发最终解决方案：

网游用的ic客户端，对发布操作没有配置全类目消保（必须开店），但是对编辑配置了全类目消保

重新打一个包

三、检查第三方关系(外部问题)—其他方的数据正确性是依赖

1. UIC、IC、数据库：  

查看数据库&查看UIC/IC中的数据，是否一致。

2. 查引擎

查看引擎返回的数据信息是否正确

对开发人员帮助最大和减少他们工作量的数据信息提供和问题排查定位的信息，主要在1个2，如果测试人员在定位bug时，发现搜索结果或者返回结果不正确时，能够提供1,2的数据库校验的结果信息，将大大减少开发人员定位外部问题所需要的时间

3. CRM：其他依赖都是数据的比对校验

4. Forest: 查前台类目和后台类目的表信息

5. 在出现以上排查手段检查的问题都正确的情况下，还是有错误。我们就需要考虑架包问题

1. 架包是否丢失

2. 架包版本是否有重复或者多版本导致的冲突

定位bug最重要的因素还是要熟悉代码和熟悉业务处理，这是bug定位的成本和准确关联最大的影响因素。