你是否遇到这样的场景?
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打断点
后台服务常见问题
自顶向下排查（从系统入口模块开始）
是内部逻辑问题还是下游数据问题？
是否是某些配置下发生的问题？
日志中是否发现线索？
系统资源情况中是否发现线索？
是否是边界值、并发等问题？
下游模块是否交互正常？
是否是多线程下的问题？
是否是大压力下的问题？
是否是不同模块间接口的定义不一致？
是否和服务器软件版本及设置有关？
自底向上排查（从系统末端模块开始）
最底层的模块是否正常收到了请求？
是内部逻辑问题还是上游请求问题
