[测试篇] bug排查技巧 | 小技巧

如下总结以web测试为例，其余类型测试可参考。前端

提问

相信有很多人测试在发现bug以后，立马给开发提了bug，不多去排查bug产生的缘由。web

在开发准备修复bug的时候，发现测试提的“bug”描述不清，不知道如何复现，只能本身琢磨或者叫QA来演示一遍，最尴尬的是，可能在测试演示完以后，才发现这个并不是bug，而是因为QA的不规范致使的。这样就会引发开发的不满，以为测试在浪费他们的时间。后端

因此在咱们发现问题的时候，首先要作的第一件事就是须要确认一下是不是咱们自己测试的不规范致使的。若不肯定，可再尝试进行复现。bug描述必定要写具体，不然不只浪费开发的时间，也会浪费本身的时间。缓存

说明bug要么开局一张图，要么一句话，开发复现bug全靠蒙。服务器

开发：markdown

正确姿式： 问题应该有详情的描述，图文并茂，场景说明，以及bug出现的流程，对应帐号密码等。app

bug瞎指派。前端的bug指给后端，后端的bug指给前端。测试

开发：ui

正确姿式： 分析错误产生的缘由，分析是前端仍是后端产生的bug，123砸过去😌url

老是测一些生产环境中根本不可能存在的状况。甚至有些需求就是如此设计，无论三七二十一直接提bug。 开发：

正确姿式： 先把需求理清楚，设计用例的时候，把一些实际不可能发生的事情剔除掉。

步入今天的正题，来，跟着我，从个人世界走一走。

新上一个功能时，发现前端页面展现仍是旧的，发起请求还报错？
- 若是部署没问题的话，那么大几率是前端存在缓存，可清除缓存试试。这里就有个问题：若是功能发到live，可是因为前端存在缓存，用户没没有清除缓存，那们从前端向后端服务器请求时，一直报错，一旦被投诉，那这个锅就是你来背了。
分辨是前端的锅仍是后端的锅。前端的锅不只仅只有UI的问题，须要发起请求，处理请求，并渲染到前端。
- 出现问题时，可先判断接口是否有错误，返回的结果是否符合预期。若接口无错误且接口返回符合预期，但前端展现不符合预期，应该由前端负责修复。
- 若接口有报错，可优先确认，前端有没有按照约定的格式向后端发起请求，若是没有，那么前端须要负责修复。
- 若接口报错，前端也按照约定的格式发起请求，那么锅就在后端了，接着可继续往下走，继续排查问题出现的缘由。

可经过接口返回的错误信息去猜想错误的来源

响应码。可根据返回的响应码去定位问题。须要你们熟悉这些响应码。

响应头。通常后端返回的错误信息会放在响应头中，若是大家不会将错误信息放在响应头的话，可忽略这个。
响应体。若是请求报错的话，接口通常会返回错误信息以及错误码，可经过这些去定位问题。在源代码中输入错误信息定位报错的具体位置（全局搜索），再根据先后调用去分析具体缘由。

从日志入手，查看具体的日志信息

从日志入手的话，那么就须要学会在哗啦哗啦的日志中寻找具体且有用的关键信息，相信大部分同窗都用过grep这个命令，相比awk，sed而言，这个命令使用起来更简单，足够知足咱们的需求了。推荐grep的几个经常使用参数：

-a<显示行数>	-a10：处理显示符合结果的那一行外，还显示该行以后的20行
-b<显示行数>	-b10：处理显示符合结果的那一行外，还显示该行以前的20行
-c<显示行数>	-c10：处理显示符合结果的那一行外，还显示该行以前以及以后的20行
-v “”	-v "INFO" 反向匹配。就是匹配到的都不显示，只显示不含有INFO的行。
-i/--ignore-case	忽略字符的大小写
-e	grep -ev "info" -e "error" info.log :至关于or，查看info.log不包含info的行但包含error的行。
-c	统计匹配的行数
-E	正则匹配。使用这个须要了解正则匹配规则。

再不济，可本身本地调试（固然，这个是在时间相对充分的状况下，若是前面两步还没法找到具体缘由的话，可直接交由开发处理）
- 能够先把bug提给开发，而后本身在本地调试查找具体的问题。若是你仅仅是功能测试，想转测开，这个步骤对本身能力提高也颇有帮助。可是若是你只想点点点的话，那这步骤就免了。