您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试管理 > 缺陷管理 > 正文

软件测试之BUG分析定位概述

发表于:2017-08-07 作者:lazy test 来源:

  你是否遇到这样的场景?
  QA发现问题后找到DEV说:
  不好了,你的程序出问题了!
  DEV(追查半小时之后):
  唉,是你们测试环境配置的问题
  唉,是你们数据不一致
  唉,是你们**程序版本不对
  唉,是**产品线的问题
  当时的日志呢?
  当时cpu有异常么?
  可以复现么?
  这里就应该是这样啊!
  你是否期待这样的场景?
  QA发现问题后,经分析判断,胸有成竹的找到DEV说:
  你的程序出bug了,初步断定是XX类的XX判断分支有问题,应该把某某的判断一改就好了!——==定位精准==
  你的程序出bug了,过去某某产品线就曾经出现过类似的问题,都是某某函数用错了,导致前端某某输入的情况下,会导致某某异常,你检查一下吧!——==经验丰富==
  你的程序出bug了,应该是某某的问题。页面截屏、日志、系统资源情况、复现步骤我都记录在bug系统了,请尽快修复——==有理有据==
  RD说:
  赞,和你合作很愉快!
  QA做BUG定位的意义是什么?
  1、明确一个“问题”是不是真的是“BUG”
  ——问题:与预期不符,表象
  ——BUG:代码错误,实质
  2、避免来回扯皮,提高测试修复效率
  ——误报降低、原因明确
  3、有助于理解产品内部逻辑流程
  ——知其然,也知其所以然
  4、提升DEV对QA的信任度
  ——靠谱!
  QA做BUG定位的几个误区:
  1、心态误区:不明觉厉,与己无关
  —— BUG定位没那么高大上,三板斧会用就行
  2、手段误区:定位必须看代码
  ——大部分定位还用不上代码能力
  3、目标误区:所有问题都该被当做BUG定位
  ——问题不一定是BUG,即便是也得考虑性价比
  4、分工误区:DEV不需要帮助QA的bug定位
  ——大家目标是一致的,DEV需提供可测性支持
  QA定位BUG的大体流程:

  BUG定位经验建议:
  1、碰到问题,别忙定位,首先请:
  ——保存犯罪现场(截图)
  ——确认能复现
  2、先排除QA低级问题,避免被鄙视:
  ——被测程序版本/配置项/网络环境,是否ok?
  ——是不是自己理解错误,本来就该如此
  3、手段多样化,别钻牛角尖,注意性价比:
  ——多观察日志,多熟悉工具,搞不定就放
  4、建设自己的BUG历史知识库:
  ——有助于温故而知新
  5、小版本的新BUG,可通过代码diff定位:
  ——代码DIFF的部分是罪魁祸首,很快
  6、要求DEV提高可测性
  ——合理的debug日志、中间结果dump
  ——方便可控的逻辑开关
  BUG定位手段:
  普通青年
  ——日志、返回码、异常值
  文艺青年
  ——各种非侵入式观察工具
  NB青年
  ——代码走查、JPDA远程调试
  WEB项目BUG定位
  明确是浏览器端问题还是服务端问题
  —— 用Fiddler/Firebug看HTTP内容是否正确
  —— 到这一步,其实就可以算阶段性结论了!
  浏览器端问题:
  —— 用Firebug做进一步定位
  服务端问题:
  —— 通过观察日志和接口内容缩小怀疑范围
  —— 高级手段:JPDA远程调试
  一般系统的定位调试

  浏览器端常见问题
  是否是浏览器设置问题?
  是否是浏览器兼容性问题?
  用其他数据是否可以复现?
  是否是cookie相关的问题?
  是否正确发出了请求?
  是否得到了正确的应答?
  是否是网络硬件原因?
  是否是JS跨域问题?
  是否是前后台接口不一致问题?
  是否是字符编码带来的问题?
  使用Firebug 和 Fiddler
  Firebug教程视频:
  http://www.56.com/u13/v_NjQzMjcwMzQ.html
  Fiddler教程:
  http://wenku.baidu.com/view/32b6052f6c85ec3a87c2c5af.html
  后台服务定位手段
  输入条件构造
  网络通信包(驱动、桩、真实的上下游模块)
  数据文件
  配置文件(包括词表,黑白名单等)
  共享内存
  输出检查
  网络通信包
  数据文件
  日志(尤其是异常日志)
  监控:
  系统监控:cpu、句柄、IO、内存
  模块级监控:内存结构体信息
  调试DEBUG
  JPDA打断点
  后台服务常见问题
  自顶向下排查(从系统入口模块开始)
  是内部逻辑问题还是下游数据问题?
  是否是某些配置下发生的问题?
  日志中是否发现线索?
  系统资源情况中是否发现线索?
  是否是边界值、并发等问题?
  下游模块是否交互正常?
  是否是多线程下的问题?
  是否是大压力下的问题?
  是否是不同模块间接口的定义不一致?
  是否和服务器软件版本及设置有关?
  自底向上排查(从系统末端模块开始)
  最底层的模块是否正常收到了请求?
  是内部逻辑问题还是上游请求问题