系统深入分析bug产生的原因

系统深入分析bug产生的原因

​“这个缺陷（bug）不是我们服务端的，这个是前端的缺陷呀”；“哥们，这个不是我们前端的缺陷呀，服务端返回的数据有问题”；“下次提缺陷能不能附带上基础数据呀，我这边复现不了”

你是不是经常听见开发这样抱怨呢？你是不是也在为提bug而发愁呢？今天就来聊聊缺陷的那些事情。

我们首先要明确知道缺陷都哪些等级，这样给开发提bug的时候才不会乱定义缺陷的等级。

特别严重：

主流程无法跑通，崩溃，设计功能与需求严重不符

紧急：

影响操作，主要功能有缺陷，但是不影响主流程

次要：

边界值问题，页面容错性不好

微调：

页面布局，错别字，不影响功能，一些建议性问题

 

由于每个公司使用的工具不一样，所以缺陷定义的字段都不完全一样，不过一些重要的要素还是相同的，这里介绍一下共同的要素

项目、模块、优先级、经办人、概要、描述、附件

概要：

一般就是简要说明一下问题。例如：课程详情页考试时间显示不正确

描述：

【测试步骤】

写上具体的操作步骤

【测试结果】

经过上面的操作步骤，最后呈现出来什么测试结果

【预期结果】

正确的结果应该是什么

【测试数据】

提供当时测试的数据：手机号或者用户id

附件：

提供出现问题的截图，或者是服务端返回的数据，或者是log日志

 

现在我们来分析一下到底是前端问题还是服务端的问题，我们还是用一个例子来说明。

例：在APP的用户中心修改用户姓名（“张三”修改成“李思”）点击提交后，页面显示修改成功，但是我们发现用户名还是“张三”而非修改后的“李思”。

这个问题怎么判断到底Server缺陷还是Client缺陷呢？建议大家可以先简单的思考一下，看看你们都能想到哪些场景，最后对比一下我总结的一些场景，这样收获可能会大一些。

对于上面出现的问题缺陷，我们需要拿出证据才能给对应的开发小哥哥提bug，不能凭感觉。这里需要借助的工具有：Charles（或者Fiddler）、Navicat Premium、rdm和secure CRT

Charles：抓包工具

Navicat Premium：连接数据库工具

rdm：redis查询工具

secure CRT：链接Linux服务器工具

分析正式开始

客户端问题：

猜想：客户端的参数上传有问题，或者页面没有实时刷新

验证：我们通过抓包工具，找到Client发送的请求，首先要看发送的URL是否正确，其次上传参数是不是和接口约定的参数一致，有没有缺少参数；

client上传的参数和Server返回的数据都正确，重新进入用户中心后，用户姓名就变成了修改后的“李思”，这说明修改姓名后，页面没有实时刷新。

猜想：客户端把姓名字段写死在程序中

如果client发放请求参数和Server返回的数据没有问题，页面也实时刷新了，还是显示“张三”，这个时候猜想一下是不是client把姓名写死在前端了。

验证：需要看一下APP的源码，要是你看不了就找开发小哥哥帮忙看一下。

以上的问题就是client问题，bug都给client的小哥哥

服务端问题：

猜想：客户端返回的数据有问题

验证：我们通过抓包工具，（保证client发送的请求和参数没有）找到Server返回的数据，看看返回数据是否按照接口要求，姓名是否返回的是“李思”

如果接口返回的姓名是“张三”而不是李四，这个bug给Server端开发小哥哥肯定是问题的

上述是一个测试最基本判断bug是那一端的最基础的技能。

要是想知道到底是Server哪里出了问题，就需要借助Navicat Premium、rdm和secure CRT工具。

具体分析如下：

通过Navicat Premium链接数据，查看数据库中该用户的姓名是不是修改了，

如果数据库中姓名没有没有被修改，再通过secure CRT连接到服务器上查看log日志，看一下是不是SQL的update的语句有问题；

如果数据库数据库中姓名已经修改了，再通过secure CRT连接到服务器上查看log日志，看一下是不是SQL的select的语句有问题；

要是上述都没问题，但是接口返回的数据还是不对，就看看一下，我们的接口是不是通过redis获取的数据，在修改用户的时候有没有实时更新redis。

最后总结:区分client的bug要看发送的URL和参数是否正确，前端不是把某个字段写死；区分Server的bug就要看在前端请求参数都正确的情况下Server返回的数据是否正确。在提bug的时候一定要谨记一点，步骤一定要描述清楚，提供必要的截图或者附件，再加上出现问题的账号信息。