为什么定位问题如此重要？

• 可以明确一个问题是不是真的“bug”

  很多时候，我们找到了问题的原因，结果发现这根本不是bug。原因明确，误报就会降低

• 多个系统交互，可以明确指出是哪个系统的缺陷，防止“踢皮球”，提高问题解决的效率

• 增强开发对测试的信任度，沟通更有效，配合的更好，开发修改bug时效增强

• 更有效的了解系统的内部逻辑、数据流处理流程，更能提高测试人员的水平，缺陷修复后，影响的测试范围评估更精准，复测更准确

• 可以降低缺陷率

  这个可以说是最重要的。在bug系统中，会要求开发人员记录bug产生的原因。只有我们自己对bug有一个较全面的认识，才会判别出开发写的是不是真正的原因，也才能有助于我们后续对bug进行分析归类，根据bug分析，有针对性地未雨绸缪，进而提升产品质量，降低缺陷

01 定位原因之前

遇到问题时，先别急着去定位原因。

1、保存bug产生的记录：

首要做的是保存bug产生的记录，保证可以复现。

为什么要保存记录？因为如果以后不能复现，那就不能证明bug的存在。

2、排除低级问题：

然后是排除QA的低级问题，常见的低级问题：

• 【hosts不对】

  hosts文件主要是加快某个域名或者网站的解析速度，从而达到快速访问的作用，也可以屏蔽网站。

  hosts异常可能会导致部分网页无法访问，能够加载，但是网页无法正常显示。

• 【网络不通】：抓包、ping

• 工具的影响导致的，例如fiddler

• 以及操作姿势不正确等。

3、排除数据问题（脏数据）：

有时候会遇到服务端报500错误，查看日志后，报空指针，那么很有可能就是数据库中关联表的数据被人为删掉导致的。

• 脏数据：从目标中取出的数据已经过期、错误或者没有意义，这种数据就叫做脏数据

• 脏读：读取出来脏数据就叫脏读

02 定位问题的思路

排查顺序：

用户环境层面 -> 展示层面 -> 逻辑控制层面 -> 服务层面 -> 数据库层面

1、用户环境层面

主要是指基础环境是否可以使用。比如：

• 网络是否ping通

• ip和端口配置是否正确

• jdk版本是否符合标准

  有可能是由于jdk版本不兼容导致系统运行异常，这种问题根据实际情况来决定要不要兼容。

• 网络设了代理

• 弱网（如js/css未加载完全、请求超时）

• 浏览器不支持

• 系统版本不支持

• 数据库被删除

• 测试环境脏数据

• 项目配置开关

• 测试环境切了分支等

检查完成后，可以转到第二步

2、用户展示层

用户在使用过程中，通过查看等操作发现的一些问题：

• 页面样式（css样式问题）

• 交互过程中js的提示（js交互问题）

• 终端控制的提示信息

• 文本的展示（html文本问题）

3、逻辑控制层

用户操作过程中，业务的处理逻辑有没有按照前期的设计实施。或者中间环节出现异常，比如缓存服务器（如redis）、消息中间件（如rabbitMQ）、数据存取中间件等。

4、服务层

服务层往往检查服务器的配置，如可能是tomcat配置、nginx配置、jdbc配置等的问题。测试人员最好能够了解下它们的各项配置。

5、数据库层

可能出现测试环境和正式环境数据库版本不同，前后端数据格式、长度限制不同。用户操作完成后，交易流程非常顺畅，这样也不代表整个交易没有问题，还需要测试人员检查数据库登记的表和字段是否正确

• 如果发现登记的字段与预期的结果不一致，则可以查看日志，检查请求报文送的字段是否正确，是否与前台填写的一致

• 有的一个操作会登记多张表，所以要检查多张表登记或者更新的是否正确，测试人员也需要对被测系统的数据表结构熟悉

6、经验法则

有经验的测试人员对于有部分bug已经见过多次，能够很快找到根源，直奔主题，迅速报告或者解决bug

7、其他

常见的bug可能还有构建方面的原因

• 比如代码本身没错，但是合并代码到主干后出现了问题

• 比如代码存在冲突时手动解决的情况

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取