你是否遇到这样的场景?
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跨域问题？
是否是前后台接口不一致问题？
是否是字符编码带来的问题？
... ...
