系统深入分析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的时候一定要谨记一点,步骤一定要描述清楚,提供必要的截图或者附件,再加上出现问题的账号信息。