软件测试中的BUG分析定位概述（QA如何分析定位BUG）

你是否遇到这样的场景?

QA发现问题后找到DEV说：

不好了，你的程序出问题了！

DEV（追查半小时之后）:

唉，是你们测试环境配置的问题

唉，是你们数据不一致

唉，是你们**程序版本不对

唉，是**产品线的问题

当时的日志呢？

当时cpu有异常么？

可以复现么？

这里就应该是这样啊！

你是否期待这样的场景?

QA发现问题后，经分析判断，胸有成竹的找到DEV说：

你的程序出bug了，初步断定是XX类的XX判断分支有问题，应该把某某的判断一改就好了！——==定位精准==

你的程序出bug了，过去某某产品线就曾经出现过类似的问题，都是某某函数用错了，导致前端某某输入的情况下，会导致某某异常，你检查一下吧！——==经验丰富==

你的程序出bug了，应该是某某的问题。页面截屏、日志、系统资源情况、复现步骤我都记录在bug系统了，请尽快修复——==有理有据==

RD说：

赞，和你合作很愉快！

QA做BUG定位的意义是什么？

明确一个“问题”是不是真的是“BUG”

——问题：与预期不符，表象

——BUG：代码错误，实质

避免来回扯皮，提高测试修复效率

——误报降低、原因明确

有助于理解产品内部逻辑流程

——知其然，也知其所以然

提升DEV对QA的信任度

——靠谱！

QA做BUG定位的几个误区：

心态误区：不明觉厉，与己无关

—— BUG定位没那么高大上，三板斧会用就行

手段误区：定位必须看代码

——大部分定位还用不上代码能力

目标误区：所有问题都该被当做BUG定位

——问题不一定是BUG，即便是也得考虑性价比

分工误区：DEV不需要帮助QA的bug定位

——大家目标是一致的，DEV需提供可测性支持

QA定位BUG的大体流程：