【可实战】Bug的判定标准、分类、优先级、定位方法、提交Bug（包含常见面试题）

一、Bug相关概念

（一）bug判定标准

在这里插入图片描述

（二）常见 Bug 分类

在这里插入图片描述

（三）bug优先级

在这里插入图片描述

1.bug严重程度与优先级的关系

在这里插入图片描述

有些很严重的Bug，只在极端的条件下才出现，用户碰到的概率很低，这种情况优先级就没那么高
有些不是很严重的Bug, 比如界面类的，拼写错误，但如果是公司名称，产品名称拼写错了，虽然不是很严重，但优先级就很高，需要立即处理

二、Bug 定位方法

（一）为什么需要掌握 Bug 定位

提交 Bug 时候追加更多有用信息，方便研发更快的解决问题
分析 Bug 形成原因，进行溯源并建立特征进行批量追踪

（二）Bug从技术层次分析

1.Bug 展现层

条件：测试数据
过程：测试步骤
结果：测试结果
在这里插入图片描述

2.技术架构层次

视图层 View：

Web UI html css
App activity view

控制器层 Controller：

Web：chrome、devtool
App：dalvik art objectc-runtime

模型层 Model：

模型的传递方式 http tcp rpc 串口
模型的形式 json xml binary
模型定义 schema
在这里插入图片描述

3.MVC 三层分析方法

View 层：运行平台、应用调试机制、链路分析
Controller 层：运行平台、应用调试机制、链路分析
Model 层：运行平台、应用调试机制、链路分析

（1）View 层常用分析方法

UI【用户界面】人工测试自动化测试
UE【用户体验】人工测试（主）自动化测试（辅）
UI Diff 自动化分析

（2）Controller 层常用分析方法

运行平台日志：log
应用调试日志：debug trace hook profile

（3）Model 层常用分析方法

运行平台 log
app 调试机制
链路分析：代理抓包嗅探抓包

（三）Web Bug分析方法

1.Web UI View 层 Bug 分析方法

主要依赖于 html css js
可以使用 chrome 开发者工具【F12】 elements 与 style
在这里插入图片描述

2.Web Controller 层分析方法

console 可以了解 js 的输出与报错信息
source 模块可以对 js 进行 debug
在这里插入图片描述

在这里插入图片描述

3.Web Model 层分析方法-分析数据传递方式与结构

运行平台 log

chrome network
链路分析
代理 proxy: fiddler charles mitmproxy
网络层协议 network: tcpdump wireshark

（四）App Bug分析方法

1.App View 层 Bug 分析

UI 界面交互
UX/UE 用户体验
UI Diff：uiautomator dump
在这里插入图片描述

2.App Controller 层分析

通过 logcat 分析 app runtime 日志
在这里插入图片描述

3.App Model 层分析方法

运行平台 log
应用：应用日志
链路分析：

代理抓包：charles fiddler mitmproxy
嗅探抓包：wireshark tcpdump

4.Andorid Profiler 网络分析

在这里插入图片描述

5.使用代理工具分析

在这里插入图片描述

6.网络协议层分析

在这里插入图片描述

（五）性能Bug分析方法

1.H5 性能分析方法

在这里插入图片描述

2.利用 Chrome 分析 Web 性能

在这里插入图片描述

3.分析性能瓶颈使用 Profile 进行代码剖析

在这里插入图片描述

4.代码覆盖率分析方法

在这里插入图片描述

（六）总结

明确 Bug 问题的现象与复现步骤
分层分析关键过程的数据与问题特征
积累 Bug 特征与问题根源特征，丰富测试经验，提高 Bug发现的能力

三、提交Bug

在这里插入图片描述

四、经典面试题

（一）如果开发认为你提交的bug不是一个Bug，怎么办？

（考察对bug是否有判断，以及在工作中的软实力：处理问题解决问题的思路）

在什么情况下开发会认为你提交的bug不是一个bug呢？

1.测试人员对bug描述不清楚，比如复现步骤描述不清楚，或者bug概述没描述好，开发没看懂，所以就认为提交的bug不是一个Bug——解决办法是：提高测试人员编写bug报告的能力，复现步骤要清晰，无歧义。提交的bug有截图，录屏，或者日志信息

2.提交的bug并不是每次都出现，是偶现的。——解决思路是先提交bug（标成偶现），重要的截图，日志信息要保留下来，后续再关注这个问题，如果再次触发这个bug, 再提交更多的日志信息，帮助开发定位解决。

3.有争议性的Bug，比如建议类的（美观性的问题，易用性问题，与竞品比较觉得不太好的地方）——解决思路：可以先把自己建议类的bug提上去，然后跟产品，开发讨论，说出自己的理由，把自己的理由，建议说清楚。至于是否要改，就听上一级决定

4.功能性Bug， bug出现的原因可能是开发跟测试对需求的理解不一致。有可能是开发理解错需求了。——解决思路：把需求文档对应的说明给开发看。

（二）怎么判断一个bug到底是前端的bug还是后端的bug？

判断一个bug是前端还是后端的bug通常需要以下几个步骤：

1.复现bug的过程：首先需要详细记录或复现bug的具体步骤和条件，包括在何种情况下出现bug，具体的操作流程等。

重现现场：在处理bug时，重现bug是非常重要的。如果问题可以通过重新执行特定操作或复现特定场景而重现，那么可能是前台bug。如果问题出现在某个特定请求或特定数据条件下，那么很可能是后台bug。

2.查看错误信息：查看控制台输出、日志或错误信息，确定bug发生的具体位置以及错误提示内容，从而判断是前端代码出错还是后端代码出错。

错误日志：查看错误日志是判断bug类型的有用方法。前台bug通常会生成前台错误日志，如前端开发工具（如Chrome浏览器）的控制台输出。后台bug则会在服务器端生成错误日志，例如在服务器日志文件中或开发框架提供的调试工具中查看错误日志。通过查看错误日志，可以确定bug出现的位置和相应的修复方法。

3.网络请求和响应分析：检查网络请求和响应，查看前端与后端的数据传递是否正常，在哪一步出现了异常现象。

调试和测试：在开发过程中，可以通过调试和测试来判断bug类型。使用开发工具的调试功能可以帮助定位前台bug，如在浏览器的开发者工具中断点调试JavaScript代码。对于后台bug，可以编写单元测试或集成测试用例来验证后台功能和逻辑，以确定问题是否出现在后台。

4.根据表现特征判断：根据bug的表现特征来判断。比如，如果是页面显示异常、交互功能问题，可能是前端bug；如果是数据请求失败、数据错误等，可能是后端bug。

前后台交互：首先需要检查bug是否与前后台的交互有关。前台指的是用户可见的界面以及用户的操作，后台指的是服务器端的处理和数据操作。如果问题出现在用户界面或用户操作时，很可能是前台bug。如果问题出现在服务器端的数据处理、数据传输或服务器配置方面，很可能是后台bug。

5.协作与通信：前端和后端开发人员之间进行有效的协作和沟通，共同分析bug的根本原因，找出解决方案。

需要注意的是，有些问题可能涉及前后台交互的复杂性和互相依赖性，可能需要综合多个因素才能做出正确的判断。在解决bug时，团队合作和跨部门协调也是非常重要的，以确保及时修复问题并改进软件质量。

6.修改并测试：根据初步的判断，前端和后端各自修改代码，并在本地测试，确认修复后bug是否得以解决。

7.集成测试：在修复后，前端和后端一同进行集成测试，确认问题是否彻底解决。

通过以上步骤，可以较为准确地判断一个bug是前端还是后端的bug，并采取相应的措施解决问题。同时，建议开发人员之间保持密切的沟通，协作解决bug，提高团队的效率和开发质量。希望对您有帮助！

（三）项目上线后发现bug，测试人员应该怎么办？

通常，如果线上出现bug，用户会通过业务方反馈到项目组这边，项目经理会根据功能模块的负责人，分给对应的开发与测试。

作为测试人员，遇到此类情形先不要慌，我们可以这样处理：

（1）首先，评估bug严重级别

如果严重，则申请紧急变更上线；如果不严重，申请等bug修复好后跟下个版本一起上线。

（2）然后，积极推动解决bug

编写对应的测试用例，在测试环境中重现和定位bug，提交bug交给开发进行修复，完成后进行bug的复测。如果测试环境无法重现，可以导入生产环境的包到测试环境中测试。如果还是不能复现，可以尝试查看生产环境的日志去定位问题。

（3）最后，复盘总结

分析bug产生的深层原因，查漏补缺，总结经验教训，避免后续出现同类问题。

如何做好复盘总结，参见下方面试题（四）

（四）线上问题如何复盘？

从这几个角度去回答：

1.复盘频率，多久复盘一次（when）
2.复盘会参与成员（who）
3.如何复盘（how）

复盘频率

频率通常都是跟着版本周期走的，比如一个版本测完上线，基本在稳定之后，下个版本开始测试之前，一个team，都能抽出来2个小时的时间去开。定期复盘非常重要，一定要有一定的频率。不能偶尔只做几次，一定要有节奏。

参与成员

至少要包含相关功能的所有测试人员
如果复盘出结果，需要其他团队参与的，一定要落地到位。所谓落地到位就是：
1.是否通知
2.对方反馈
3.最终是否实施。

举个例子，如果在复盘过程中发现是因为研发随意提测，导致测试效率下降，那么就要拉项目经理或测试的老大。

1.向对方提出问题
2.磋商一个解决方案，比如制定提测规则
3.要求研发团队按照规范行事。

如何复盘

一般复盘会去复盘问题问题也有基本方法论，有一个方法叫做5why法，有两个基本原则：

1.刨根问到底
2.对事不对人

比如线上出现了生产事故，这是问题的思考路径：

1.生成事故是由什么问题导致的？
2.这个问题测试时为什么没有发现？
3.假设是因为测试漏测，为什么会出现漏测？
4.假设是因为没有考虑到这个场景，就要考虑是否还有同类型的场景，并补充测试用例。

在提出问题和解决方案之后，有一个很重要的步骤就是落地。把问题形成一个闭环。才能避免下次问题再次出现。

总结

面试碰到这个问题，心里一定要有大概思路不要想到什么说什么。重点在于方式方法，不要过分纠结于细节。把从问题的发现、提出，到如何规避。要有一套完善的体系，能尽量确保问题不再出现