前言
又到了毕业季，我们将会迎来许多需要面试的小伙伴，在这里呢笔者给从事软件测试的小伙伴准备了一份顶级的面试文档。
1、什么是 bug? bug 由哪些字段(要素)组成?
1)将在电脑系统或程序中，隐藏着的一些未被发现的缺陷或问题统称为 bug
2) bug 由标题、前置条件、严重程度、优先级、操作步骤、预期结果、实际结果、bug 截
图或日志等组成
2、你所在的上家公司规定 bug 的严重程度有几级，分别是如何划分的?
1) Bug 分为 4 级(致命级、严重级、一 般级、轻微级)
2)致命 urgent: 通常表现为:主流程无法跑通，系统无法运行，崩溃或严重资源不足，应
用模块无法启动或异常退出，主要功能模块无法使用。
严重\高 hight：通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响
到系统稳定性
一般/中等 medlumao：通常表现为:界面、性能缺陷，比如：1.边界条件下错误 2.大数据
下容易无响应 3.大数据操作时，没有提供进度条
轻微/低 low：通常表现为:易用性及建议性问题
3、日常编写 bug 有那些好的建议？
1)包含重现缺陷的必要步骤
2)如果有些特殊的前置条件要进行说明
3)提供出现 bug 的页面的相关截图后、后台日志信息
4)缺陷(说明文)提交时不带有任何证毁开发或批评开发的词语
5)提交缺陷一定不要带有对缺陷有相关疑问的语句
6)及时提交缺陷(有一种场合: 新人正式执行测试的前 1 个月)
7)遇到小缺陷也要提交
4、有争议的缺陷如何处理?
开发把缺陷状态改为不予解决、设计如此、外部原因等
1)再次根据测试用例和需求文档确认是否是缺陷(还是觉得是 bug)
2)再把相应的需求给开发查看(开发会说需求人员临时通知的)
3)跟相应的需求人员确认，如果确认开发所说无误，把问题填写原因并置为关闭状态(确认
需求人员没有告知测试部门)
4)事后在晨会或者工作时间把问题给老大汇报一下
5、开发不想改的小缺陷如何处理?
1)把小缺陷稍微讲的严重一点，比如不改会对用户造成哪些影响
2)拿同类型的产品进行比较
3)必须提交到测试管理工具
6、随机缺陷如何处理?
随机缺陷偶尔出现或者在测试过程中只出现一次的现象
1）随机缺陷要提交到测试管理工具（发现 bug 的第一时间就要保存截图和相关日志，作为
证据或者开发解决 bug 的思维方式）
2）回想出现该 bug 是的操作步骤，尽量能重现出来
3)让开发帮忙分析，开启出现 bug 相关模块的日志记录
4)重新出现该随机缺陷的时候让开发过来测试机前面分析(保留现场)
7、测试用例之外的缺陷如何处理?
测试过程中出现类似情况很多
1)提交 bug
2)维护用例，把出现 bug 的操作步骤编写成测试用例
8、缺陷重复提交如何处理?
1)开发把缺陷置为重复 bug
2)测试人员确认是重复 bug 后进行原因说明并关闭
9、缺陷重复提交的原因以及如何解决?
1)测试部门分工不明确、或者交叉测试没有关注缺陷库、模块有相交的部分测试人员分配
不明确
2)如何解决:分工明确:交叉测试的时候问题先用文档提交给对应模块的负责人
10、缺陷的状态中，哪种状态的缺陷对于开发影响大， 对于测试影响大的缺陷状态是?
重新打开对于开发影响大 不是问题对于测试影响大
11、如何区分是前端缺陷还是后端缺陷?(如何定位 bug 是前端还是后端)
1)发现 bug 之后，重现 bug 的时候使用 fiddler 抓包去分析
2) 如果前端提交的数据在 fiddler 中显示有误，那么返回的数据肯定是有误的，所以就是
前端开发的 bug
3)如何前端提交的数据在 fiddler 中显示无误，而返回的数据是有误的，那么就是后台开
发的 bug
除了 fiddler 等抓包工具外，还可以通过后台的日志去判断
12、版本上线前，bug 的状态?
处于关闭或延期解决的状态。后者留待下一个版本再测。打开和新建状态不存在。
13、遇到阻碍测试的问题如何处理?
通知开发立即解决并更新最新的补丁包，在开发修复的时候看是否还有其它的测试工作，
先完成其它的。完善的冒烟测试执行一般不会出现这种情况。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取