软件测试面试经典题目与见解--概念技术篇_软件测试面试题 亮点

1、请先介绍一下自己。

首先，面试的第一个问题就是自我介绍了，个人认为，软件测试岗的自我介绍，必然是要从自己做过哪些工作，会哪些技能，能承担什么类型的工作的角度出发的，至于自己的兴趣爱好之类的则是次要，其他与测试工作无关的话题更是不用提。

举例：

面试官你好，很高兴获得此次面试的机会，我是XXX，来自XX市，大学计算机专业毕业已有五年，从大四进入一家软件公司实习至今，已有6年的测试经验。此期间，我呆过两家软件公司，工作范围包含功能测试、接口测试、自动化测试、性能测试等。

在第一家公司，我是以实习生的身份入职的，从普通的功能测试开始，编写测试技术文档、测试用例、执行功能测试，后来因为业务需要还去学习了性能测试（这里可以写其他合适的，要做到闭环）的技能并实际帮助开发定位到性能问题，在不断的工作和学习中，第三年的时候我被提拨成了部门经理。

后来因为个人原因，我去了另一个公司xxx，这是一个xxx类型业务的企业，在这里，我的成长很快速，经过之前工作经验的积累和不断的学习，我在新公司可以熟练地使用Linux语句进行系统部署，可以熟练使用SQL语句来操作数据库辅助功能、性能测试，使用Jmeter接口测试工具做接口测试、性能测试、使用selenium+python模式做UI自动化测试等。

我个人是一个不愿意被行业抛下的人，平时除了工作、生活，都会不停地学习新的知识，以确保自己是与时俱进的。

以上就是我的自我介绍，如果您还有什么想要了解的，欢迎继续交流。

2、可以大概说说你之前公司的测试流程吗？

这个问题，我之前面试过的公司都问到了，虽然我面试的公司不太多（个人找工作还是挺快的^_^），但我觉得这是很能够体现出个人语言组织能力和辨别工作经验真实程度的题目。

举例：

我之前呆过的2家软件公司，测试流程大同小异，基本都是从参加需求评审会开始，在会后测试需要给出大概的测试时间，然后产品经理在会后更新需求文档后，测试负责人开始做测试计划，包括时间、人力、设备等资源的计划和测试方案的设计，然后就是项目的测试人员开始写自己负责模块的测试用例，在提测后执行测试，bug跟踪管理、回归测试，最终达到上线标准了就会写测试总结报告，以邮件和企业微信的形式通知所有相关人员。第二家公司在上线之后还需要做专门的线上验证。

3、你觉得一个好的测试用例，应该是什么样子的？

作为一名测试人员，不管你是做功能测试、性能测试、接口测试、自动化测试、安全测试等等，这都是一个绕不过去的问题，用例就是测试有灵魂，必须要会。

举例：

我觉得写测试用例，第一个原则就是要全面覆盖需求，严格遵循需求；

然后写用例的思路要清晰，比如说有一个总--分--总的思路，首先总体分析系统有多少个模块，每个大模块又包含多少小模块，划分到最小的模块单位后，将所有功能点提取出来，一一编写用例，最后将所有有业务关联的模块串连起流程测试用例。

第三点，就是需要保持用例的独立性，用例与用例之间，不要有依赖，如果确实有关联的，可以在前置条件那里描述清楚本用例所依赖的数据是如何得来的。

然后就是几个很重要的点，用例标题清晰明了，见名知义；步骤清晰可操作；预期与需求一致。

还有就是用例的颗粒度要适中，不要一句话描述完整个故事，也不要太过详细。

最后也是很重要的一个点，就是你要站在用户的角度去思考问题，虽然有时候需求文档没有描述清楚，但是自己假设自己是用户，会怎么操作这个系统呢，有哪些业务痛点呢？会有哪些误操作的可能之类的。

4、你们一般测试几轮？每一轮测试的重点是什么？

这是一个没有固定答案的题目，面试官想考察的可能就是你对测试的理解，实际工作中是怎么做的（我估计）。

举例：

我之前做过了很多项目，不同的开发负责人会直接影响到测试轮数的多少。不过我总结一下，大概都在三到五轮左右。

在正式的测试之前，我们做做一个冒烟测试，确认主流程无大阻碍之后进入第一轮测试。

第一轮：需要把所有用例都执行完，重点流程重点测试。

第二轮：先把第一轮发现的bug回归，根据实际修复情况关闭bug或激活，然后把测试用

例再执行一遍。（有些公司在时间很紧急的时候，只关注第一轮有问题的和主流程测试）

第三轮：把前面两轮的所有bug都回归，然后打开需求文档、原型等进行扫描式测试，以防漏测，之后，之后会做一些兼容测试、弱网、断网、长时间不操作等专项测试，如果没有问题就结束，否则继续（可能会因为一个bug继续很多轮）。

如果业务有需求，可能还会做接口、性能等测试。

特殊性况，例如春节前，还会做封包测试。

5、你认为是bug，开发认为不是bug，如何解决？

这个问题也是比较多被问到的，因为测试本身是需要跟开发人员紧密合作的，这个问题，要做到坚定测试的立场、原则，又需要跟开发做有效的沟通、协调（即不能跟开发打起来...）

举例：

首先我会去仔细研读需求文档，并且与产品经理求证，如果确实是一个bug，我会以我对需求的理解跟开发讲明白，然后说明产品经理也是认同的，如果开发认可，修改bug，即进入bug跟踪管理流程，如果开发仍然不认同，那我会请他说明他是如何理解的，如果我觉得他说的有道理，我也会找产品经理一起进来讨论，最终得出结论。如果最终确实是bug，开发坚决不改，那我就会找他的领导说明，让领导处理，不处理的话就写进测试报告里。

6、你在公司会写测试文档吗？一般会写什么文档？怎么写？

做测试，文字功底是要用的，毕竟你需要写用例，写bug，写文档，如果你写的bug，开发根本看不懂，那如何是好？然后测试一般都要写一些技术文档，例如计划、报告、有些公司还要求测试写用户手册等。

举例：

我在公司除了写测试用例、bug等，还需要编写测试计划和测试报告。

首先测试计划，这是在开完需求评审会之后需要定下来的，这个公司会有对应的模板，我往里面套内容就行了，需要根据项目实际情况做对应的调整。主要是包括以下内容：

• 测试目标与测试范围；

• 执行计划的角色与职责；

• 任务的进度安排与资源分配；

• 风险评估和应急计划；

• 测试的准入/准出标准。

然后测试报告也是有模板来套用的，主要包括以下内容：

• 测试目标与测试范围；

• 测试过程与结论（测试了多少轮，发现了多少问题，修复多少了，还有多少遗留，如何处理等）；

• 系统是否完全符合产品需求说明书的描述；

• 是否达到上线标准；

• 是否存在风险。

7、你们公司的bug等级是怎么划分的？有什么依据吗？

这个也是没有标准答案，我想把大体的说得差不多，面试官应该就知道你确实是有自己的理解了吧，我自己整理了一个稍微全面一点的说法，不过我面试的时候，也没能背下来，都是用自己的语言说个大概。

举例：

不同的公司，有不同的分法，不过相差不大，我们之前，Bug一般分四个等级：

1）一级：致命bug

• 测试时直接导致系统奔溃、死机、蓝屏、挂起或是程序非法退出；

• 存在安全缺陷，点击导致重要数据丢失、损坏，且无法恢复；

• 主要模块、功能点没有实现。

2）二级：严重bug

• 被测试系统的次要功能点没有实现，或者没有安需求实现；

• 软件某个功能点出错，导致无法完成完整流程测试（阻碍性bug）；

• 主要界面上存在明显并且影响很大的UI错误。

3）三级：一般bug

• 与预期结果不一致的功能bug,只影响到本功能；

• 软件交互性不好，导致用户难以理解、操作；

• 条件较为严苛的前提出现的较严重的bug；

• 界面上出现的文字等描述错误，造成用户误解。

4）四级：建议性bug

• 实际功能与预期结果有较小的差异；

• 条件较为严苛的前提出现的普通等级的bug；

• 界面、程序或提示等存在文字描述问题，但影响不大；

• UI与设计图有较小的差异；

• 程序易用性建议、用户体验优化建议。

8、你印象最深刻的一个bug

这个问题，我感觉有点送命题的意味，普通的bug，也没啥好印象深刻的，都是造成了不好的后果才会印象更深刻吧，说浅了人家说你假，说深了，人家会不会嘀咕，你在我这里不会也出这种“事故吧？”。。。。那到底要怎么说呢，我觉得最好不要把自己负全责并且造成惨重后果的bug拿出来讲，最好讲讲自己在这个bug的总结，进步吧。

举例：

之前我在xxx公司测试一个商品后台系统的时候，有一次线上报回来的个bug，即是商品后台修改了出入库相关的功能后，我针对需求测试是没有问题，没有去关联的移动端验证售卖功能就直接上线了，当时我们是有专门的测试人员做移动端的测试的，我这边是只负责后台的功能的，但是那段时间那位同事是在另一个办公区的，她请假了我也不知道，项目就直接上线了，导致商品后台改动影响到前端售卖，并且给客户造成了一定的损失。这个bug的最根本原因就是我们公司的分工机制以及信息不同步导致的，后来，为了避免以后再次出现这种情况，我就录制了一份接口自动化脚本，每次有新的需求上线，我都会跑一次后台、前台的所有主流业务流程的接口，确保没有问题了再上线。

去面试测试岗位的时候，会遇到各种各样的问题，除了一些经典问题之后，还有一些专项基础题，比如说专门问数据库的、Linux命令的、自动化的、python相关的题目，后面有空再整理一些。