测试常见面试题之客观题--上岸100%（纯干货分享--手把手教你面试）【1】

11.你们之前的项目测试流程是怎样的？【高频】

我们的测试流程主要有四个阶段：需求分析、测试准备、测试执行，报告复盘。

1、需求分析阶段

        产品会把需求文档给我们自己先去了解一到两天这样，之后我们会有一个需求评审会，我们会把不明白不理解的需求在会议上说出来，包含需求的合理性还有需求的可测性等，产品这边解答，目的是让我们测试这边和开发对需求的理解达到一致。

2、测试准备阶段

        会议结束之后我们开始准备测试工作，我们测试组长会写一个测试计划，分配每个人负责的模块，预估的工时，然后我们就根据自己负责的模块用 xmind(思维导图)进行测试需求分析，业务拆解，分析测试点，以及编写测试用例，之后我们会在自己的组内先进行评审，评审修改之后还会在我们的项目组评审，评审完后进行修改测试用例。

3、测试执行阶段

        开发人员编写好代码之后，他们会把代码包通过 Jelkins 部署到测试环境提测，在正式测试之前我们会先做一个冒烟测试。冒烟测试通过之后我们才转测，在执行测试的过程中，我们如果发现 bug 就会用禅道记录并且提交 bug，也会进行 bug 复测，以及回归测试。

4、报告复盘阶段

        每一轮测试结束之后我们都会写一个测试报告，一般情况下，测试 4-5 轮之后会达到上线要求，当达到上线的标准后，测试报告会认为测试通过，上线前我们会做预发布测试，预发布通过后，由项目组与产品决定时间上线，上线完成，一周左右我们会写一个项目总结测试报告，复盘总结我们在上一个版本中遇到的问题以及今后有哪些地方需要改进，在产品选代过程中，我们会跑自动化用例来进行回归测试。

12.如果你提出的BUG研发不认为是个BUG，你会怎么办？【高频】

1. 首先我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭bug。如果是 bug 再去让其他测试人员看看听下他们的意见，然后自己先再三去复测；
2. 保存好截图和日志，确定这是一个 bug 之后我就去跟开发说明白，并且给他看 bug 重现的截图以及日志；
3. 如果影响较大，但研发不认为是个BUG，可以通知给测试组长或产品，来定夺这个是否需要修复；
4. 如果影响较小，可移到后面迭代修复。

13.你们公司有几套环境？【高频】

一般是3套环境，小公司可能会只有2套，没有预发布环境。

1. test测试环境
2. staging预发布环境
3. production线上环境

14.是否有写过测试计划，其中都包括什么内容？

【愿意说的，参考这个】

测试计划内容：

(1)目的和范围

(2)规程

(3)测试方案和方法

(4)测试的准入和准出

(5)测试计划(流程、时间安排、对应人员)

(6)测试的环境配置和人员安排

(7)交付件

【不想说的很具体，可以参考这个】

        我们公司之前按照考核要求写过测试计划，不过后面老大觉得太耽误工作进度，后面一般都不再写测试计划，而是写版本计划，在版本计划里，每个人的任务列出来，负责人列出来，自己根据自己的情况分配时间，然后汇总，大家一起开个小会评审就可以了。

15.测试用例包含哪些部分，设计测试用例方法有哪些，你一般常用哪些方法？【高频】

        测试用例模板一般包含：用例编号，测试标题，优先级，预置条件，测试步骤，测试数据，预期结果，实际结果。

        黑盒测试用例设计方法：主要是等价类、边界值、错误推测法、判定表、因果图、正交表、

流程分析法、状态迁移法、异常分析法。

        常用的：等价类、边界值、判定表、流程分析法、错误推测法。

        等价类是指某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定。测试某等价类的代表值就等于对这一类其它值的测试，因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据取得较好的测试结果，等价类划分可有两种不同的情况有效等价类和无效等价类。

        边界值的话就是对等价类划分方法的补充。测试工作经验告诉我，大量的错误往往是发生在输入或输出范围的边界上而不是发生在输入输出范围的内部，因此的话针对各种边界情况来设计测试用例，可以查出更多的错误，使用边界值分析方法设计测试用例的话，首先应该确定边界情况，通常输入和输出等价类的边界，就是应着重测试的边界情况应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

        对于错误推断法，这个是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的去设计测试用例的方法的，主要就是列举出程序中所有可能有的错误和容易发生错误的特殊情况去根据这些情况来选择测试用例，例如，在单元测试时曾列出的许多在模块中常见的错误以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为 0 的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况，可选择这些情况下的例子作为测试用例。

        前面介绍的等价类划分方法和边界值分析方法都是着重考虑输入条件但都没有考虑输入条件之间的 联系，相互组合等等的情况。考虑输入条件之间的相互组合，可能会产生一些新的情况，但是要检查输入条件的组合并不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多，因此的话可以考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例，这就需要用到因果图(逻辑模型)。因果图方法最终生成的就是判定表它适合检查程序输入条件的各种组合情况。

        也可结合自己工作中遇到的项目去说。

16.无法重现的BUG，你会怎么做？

        首先，我会多测几次，测了好多次都无法重现的话我就先把 bug 挂起，并且留意一下，看看往后的测试中，如果在后面的测试中重现 bug 就激活，如果经过几个版本都还没发现的话就关闭bug。

17.你们是如何管理BUG的？

        我们之前的bug是用禅道来管理的。

        bug会直接提交给对应的开发人员，对应开发人员修复完成，交给测试复测，复测通过关闭 bug，不通过打回给对应开发。

        提交-开发人员(已激活未确认)-开发进行确认，状态变成已激活，已确认，开发修复完成，标注状态是已修复，测试人员复测通过，已关闭，打回给对应开发，已经激活。

18.BUG提交都有哪些内容？

1. BUG编号
2. Bug 标题
3. 所属项目及模块
4. 影响版本
5. 指派人员
6. 截止日期
7. 严重程度
8. 优先级
9. bug 类型
10. bug 环境
11. 复现具体步骤
12. 附件

19.说说你项目中遇到的困难，你是怎么解决的？【高频】

这道题很多人都答不好，无非面试官想考查几个点：

1. 你个人解决问题的能力；
2. 你在处理问题的时候逻辑是否清晰；
3. 在你眼中的困难是什么等级的；
4. 你曾经做过项目的级别；
5. 你是否真的做过项目。

        答这道题时，可上升问题难度，注重解决问题时的逻辑，包括最后的复盘。而不是寥寥草草说自己在测试的环节出现的问题，反倒容易暴露自己的漏测，从而面试官会反问你，那这算不算漏测呢？或者其他的，可以往研究测试工具，沟通对接上引导，再加以合理的复盘。

20.界面中的乱码会是哪里导致的？

1. 数据库中的编码设置
2. 前端页面编码
3. 后台代码编码

21.bug的级别有哪些，你是如何判断的？

1. 致命：对业务有至关重要的影响，业务系统完全丧失业务功能，无法再继续进行，或业务系统丢失了业务数据且无法恢复，影响公司运营的重要业务数据出错。
2. 严重：对业务有严重的影响，业务系统已经丧失可部分的重要的业务功能，或业务系统丢失了业务数据且可以恢复，一般业务数据出错。
3. 一般：对业务有较小的影响，业务系统丧失了较少的业务功能，例如：界面错误，打印或显示格式错误。
4. 建议：对业务没有影响，不影响业务过程正常进行，例如：辅助说明描述不清楚，提示不明确的错误提示。

22.测试中，如何判断是前端的BUG还是后端的BUG呢？【高频】

        通常可以利用抓包工具来进行分析，可以从三个方面进行分析：请求接口、传参数、响应。

1. 请求接口 url 是否正确。如果请求的接口url 错误，为前端的 bug；
2. 传参是否正确。如果传参不正确，为前端的 bug；
3. 请求接口url 和传参都正确，查看响应是否正确。如果响应内容不正确，为后端 bug；
4. 也可以在浏览器控制台输入 js 代码调试进行分析。

23.线上发现BUG，要怎么处理？

1. 看严重级别：严重还是不严重。
   1. 严重的：紧急变更上线；
   2. 不严重：修复好后跟下个版本一起上线。
2. 用户会通过运维反馈到项目组这边，项目经理会根据功能模块的负责人，分给对应的开发与测试。
3. 测试人员：编写对应的测试用例，测试环境中重现 bug，提交 bug，交给开发进行修复、修复完成 bug、进行 bug 的复测。
4. 如果测试环境无法重现，可以导入生产环境的包到测试环境中测试，还是不能复现，查看生产环境的日志去定位问题。

24.你们项目怎么上线的？

1. 一般我们会选择晚上上线，开发测试还有产品都在场，部署后再进行线上测试；
2. 首先，开发将代码打包到生产环境的服务器中，如果数据表有变化，就会运行 sql 文件，对表的一些操作，接着，我们测试就开始先测试主体业务功能以及新增的功能模块;
3. 测试通过之后，我们会在界面上把上线测试的数据删除，正常上线；
4. 如果发现 bug，开发人员当场修复 bug，修复成功之后我们测试再复测，通过就可以正常上线；
5. 如果发现了 bug 开发人员在上线规定时间之前都还没有修复好的话，就看问题的严重性，如果严重就延期上线，如果我们是迭代版本的话我们还需要版本回滚。如果不严重，产品跟客户觉得可以上线，就正常上线。