BUG是前端的还是后端的

测试工程师发现的bug就像一枚勋章，见证着测试人员的辛勤劳动。当然不是说找出bug是唯一的测试工作目标，但是如果能最大范围挖掘出问题，意味着测试行业已经入门。再往高阶测试的路上，就是要对发现的bug进行快速反馈和修复回归校验。今天分享的就是如何高效反馈。

首先高效反馈的结果能够加快bug修复速度，从而高质高效完成本次测试任务。当你发现一个页面数据展现为空时，你及时的查看查询数据接口，如何发现数据返回为空，那么说明后端问题可能性大直接反馈给后端研发，如果是数据返回正常，那么提交给前端，让前端辅助排查。如果发现问题同时安特所有人，让所有人都去复核一遍，这样的测试效率通常很低，而且可能导致研发对测试的好感逐渐降低。

其次通过对bug所属负责人的甄别，可以慢慢发现研发习惯，对后续迭代测试起到前瞻性指导。前端工程师小红容易丢需求，后端工程师小刚容易接口返回丢字段等。固定时间段内，跟你合作的研发通常是不变的，发现他们的研发习惯对自己的测试也有很好的帮助。

最后能够高效反馈是提升测试工程师上限的必经之路，通过测试技术手段逐步排查问题的根因，找到问题的深层次出处，如果能发现根因，直接反馈给研发，研发会大概率复用你的结果，快速二次排查定位问题，定位问题的速度大大加快，研发只需要修复问题就行了。更厉害的测试，是既能发现根因，同时又给出了解决方案。这样的测试往往研发很愿意合作。

前后端的BUG都有什么特点呢？

首先声明的一点就是，页面交互的bug不一定百分百就是前端的，如果后端接口数据问题，也会引起交互问题。上面给出了大概的排查思路，交互问题可以优先指派给前端去解决。

用户发现前端白屏了，打开控制台F12，同时查看console日志和network接口请求，如果console有error报错就反馈给前端，如果接口请求非200就反馈给后端。

老王抱怨前端经常卡顿，打开控制台F12，查看network,可以查看请求前端资源接口和后端接口的status状态码和时间。后端接口返回很慢或者超时会引起页面卡顿，但是因网络影响前端资源接口很慢的情况也会出现。所以思维不要固化，多观察网络资源请求。

我们会遇到交互异常的场景，首先通过抓包工具可以按前端请求资源时序抓出所有的请求，从头分析页面的请求和交互，查看每一步接口返回的状态码和返回包数据，很多跳转会依赖接口返回的数据errno或者数据data里面的字段值；

对于后端接口返回控制前端交互的场景，只需要按照接口文档，排查接口返回的数据data相应的字段值来明确是后端没给交互字段和正确的字段值，还是后端接口已给双方约定的数据，只是前端没有正确处理交互。

很多情况就是用户所用的操作系统、端、端的版本各不相同，而产品没有做好兼容性引起，"我的正常，你的不正常"的情况出现，搜集用户反馈的端情况，然后做复现，然后再进一步反馈给前端工程师来排查，排查思路就是查看前端抛错和后端接口来定位。

如果是接口返回了错误码，直接去看日志，日志大概率直接定位哪个文件哪一行抛的错，查看代码上下文就能大概判断出是什么问题。如果通过日志没有发现，那就全局搜错误码，并通过接口名称大体判断抛错的问题。

如果接口数据问题，首先定位存储层是否有接口所需的数据，写接口要判断当前存储里面是否插入数据，如果没有插入数据就通过代码断点判断哪里阻塞hang住了；如果是读接口，必要的codereview可以定位数据源是第三方服务还是自身存储层。也可以通过代码debug定位数据封装的返回。快速定位不需要逐行断点，原则是先外层定位函数，然后具体定位。

如果是单接口性能问题，可以增加代码对核心的函数增加时间统计，统计办法就是函数之前增加时间戳，执行函数后增加时间戳，通过时间戳的差值来评估函数的耗时。

对于接口服务的性能，就需要通过性能测试，结合生成火焰图的方式来查看CPU 耗时。火焰图就是看顶层的哪个函数占据的宽度最大。只要有"平顶"（plateaus），就表示该函数可能存在性能问题。