遇到bug怎么分析,这篇文章值得一看(1)，写给互联网大厂员工的真心话_测试人员定位bug和分析

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

工具的影响导致的，例如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可能还有构建方面的原因

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

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

03 定位问题的方法

1、常用的定位策略：

常用的定位策略分为三类：原始类(brute force)、回溯类(backtracking)、排除类(causeeliminations)

原始类定位方法

原始类定位方法是最常用也是最低效的方法，只有在万般无奈的情况下才使用它，主要思想是“通过计算机找错”。

回溯法

回溯法能成功地用于程序的排错

方法是从出现bug征兆处开始，人工地沿控制流程往回追踪，直至发现出错的根源，不幸的是程序变大后，可能的回溯路线显著增加，以致人工进行完全回溯到望而不可及。

排除法

基于归纳和演绎原理，采用“分治”的概念。

首先确定所有与bug出现有关的所有数据，设想一个导致bug的原因，用这些数据证明或反驳它。或者一次列出所有可能的原因，通过测试一一排除。只要某次测试结果说明某种假设已呈现倪端，则立即精化数据，乘胜追击

2、查看状态码

4xx状态码：一般表示是客户端问题（当然也有可能是服务器端配置问题），比如：

发生了401，那么要看下是否带了正确的身份验证信息

发生了403则要看下是否有权限访问

404则要看下对应的URL是否真实存在

5xx状态码：一般表示服务端出现问题。比如：

发生了500错误，则表明是服务器内部错误，这个时候要配合服务器log进行定位

发生了502错误则可能是服务器挂了导致的问题

发生503错误可能是由于网络过载导致的问题

发生504错误则可能是程序执行时间过长导致超时

3、查看服务器日志

如果发生5xx问题，或者需要检查后端接口执行的sql是否正确，我们最常见的排查方法就是去看服务器日志，比如tomcat日志。开发人员一般会打出关键信息和报错信息，从而找到问题所在，所以，测试人员也要养成看日志的习惯。

4、检查配置

很多时候，bug不是代码的问题，而是tomcat配置、nginx配置、jdbc配置等的问题。在这个层面上，测试人员最好能够了解下它们的各项配置，在发现问题后可能就会想到这方面的问题。

5、查看需求文档

有时候，前端和服务端的交互都正确，但是从测试的角度看不合理。这个时候，我们应该翻翻需求文档。如果和需求文档不符，那么就要看下改什么比较合理，是改前端，还是改服务端，或者两者都要改。

这里有一个原则，就是前端尽可能少地去承担逻辑，只负责渲染展现。当然，不要以为需求文档就全部正确，它也可能会有错误，我们也应该去发现需求文档的bug，然后再去协调PM，敦促FE或者RD进行修改。

6、向开发寻求可测性支持

有时候，涉及到开发过程的一些测试，也需要开发提供可测性支持。

比如，要查看接口给另一个接口发的请求是否正确，可以让开发打印出完整的请求log，还有一些逻辑开关、修改页面数据条数等，都属于可测性支持的范畴。

04 bug定位常用工具

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）
[外链图片转存中…(img-TjKTXecu-1713617141730)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！