软件测试工程师三次面试失败的血泪教训！！！

把时间用在进步上,而不是抱怨上;其实很多时候,你并不需要做什么,真诚即可。

最近三次面试的经验总结：

1.开始介绍一下你自己

您好，我叫xxx，xx年xxxx学院xxxx专业毕业，毕业至今在xx的软件公司从事软件测试工作3年。最近做过的项目是xxxx，主要做app端和web端测试，我主要负责需求分析、测试用例设计、功能测试、接口和自动化测试的具体执行，作成测试报告文档。我个人擅长功能、接口测试、接口自动化、界面自动化及简单场景的性能测试，熟悉Java、Python编程语言、Linux操作系统和数据库；测试工具像Jmeter，Loadrunner，Fiddler工作中用的比较多；另外，我是一个有较强的自主学习能力，并且有较强的团队协作意识的人。我的自我介绍完毕，谢谢。

建议回答内容：从业时间、教育背景、工作经验、项目经验、擅长技能、你的性格。

2.讲讲你在公司主要负责什么项目

组织架构：产品经理+架构师+美工+前端开发+客户端开发+后端开发+测试人员（国内研发人员和测试人员占比为5:1或3:1）
xxxx电商项目有首页模块、分类模块、购物车模块、订单模块模块（以app为主，也有小程序，还有web端，商家主要是使用web端），整个项目做了大概xx个月，项目性质（外包，为甲方公司做的，并负责后期维护）。我在这个项目中，主要负责需求分析、测试用例设计，参与用例评审，做功能测试和接口测试，也做过一些查询场景的性能测试。项目后期，将稳定的功能做了一些自动化测试。以上就是我的回答，谢谢。

建议回答内容：项目陈述可以先整体后局部，整体可量化（项目规模、时间成本、人力成本），然后测试环境（知道的就说）、最后是角色职责。

3.测试流程是什么

1）产品经理会整理需求原型图，召开需求评审会议，相关的测试和开发人员都要参与。
2）需求评审之后，需求确定会以邮件转发的形式转到每个人的邮箱；
开发拿到需求之后开始实现相应的功能模块；测试拿到确定的需求进行分析、编写测试计划，编写测试计划时，我会评估测试进度、安排相应的测试工作，根据测试计划，开始设计相应需求的测试用例，
3）用例编写完成后，我会召集产品和相关的开发进行用例的评审。
4）用例评审结束后，开始搭建测试环境，然后，在开发需要自测通过，发送提测邮件，我通过jenkins一键构建，实现环境的自动化继承部署，然后开始进行冒烟测试，冒烟测试不通过，驳回给开发。
5）冒烟测试通过的话，开始执行测试用例，发现bug的话，提交到禅道，开发会在这个版本对我提交的bug进行修复，这个版本的bug全都修复后，会转测一个新的版本，我再重新构建环境，对之前的bug进行回归验证，bug解决的话就关闭，bug没解决就重打开，发现新的bug就重新提交。直到所有的bug都得到解决，回归测试才完成。
6）当然，有些时候有一些优化性的bug，由于项目紧急，开发来不及解决，我会安排在下个版本解决。
7）测试完成后，我会编写一个简单的测试报告，给出测试是否通过的结论。通过的话就交付上线。

8）一般上线后如果有bug产生，能快速解决的，我们会快速解决，不能快速解决的，会进行版本回退。
9）最后项目组会召开一个测试复盘会议，对产生bug的原因进行总结。以上就是我的回答，谢谢。

建议回答内容：需求分析、测试计划、测试设计、测试执行、测试评估。

4.tcp和udp有什么区别

(1)TCP是面向连接的（在客户端和服务器之间传输数据之前要先建立连接），UDP是无连接的（发送数据之前不需要先建立连接）
(2)TCP提供可靠的服务（通过TCP传输的数据。无差错，不丢失，不重复，且按序到达）；UDP提供面向事务的简单的不可靠的传输。
(3)UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性比较高的通讯或广播通信。随着网速的提高，UDP使用越来越多。
(4)没一条TCP连接只能是点到点的，UDP支持一对一，一对多和多对多的交互通信。
(5)TCP对系统资源要去比较多，UDP对系统资源要求比较少
(6)UDP程序结构更加简单
(7)TCP是流模式，UDP是数据报模式

5.一个扫码支付功能你会怎么写测试点？

6.你们公司的自动化测试是怎么样的？

软件测试面试题整理(一)之自动化测试题大合集

7.产品发布线上问题是怎么规避的

8.说说fiddler抓包工具

Fiddler工具详解（超详细）

9.你们公司用什么存储数据？mysql和mongo数据库的区别？

两方的优缺点以及特性：
a1.关系型数据库（mysql）：
特性：
关系型数据库是指采用了关系模型来组织数据的数据库；
关系型数据库的最大特点就是事务的一致性
简单来说，关系模型指的就是二维表格模型，关系型数据库就是由二维表及其之间的关联组成的数据组织
优点：
容易理解；
使用方便；
易于维护；
支持SQL，可用于复杂的查询
缺点：
为了维护一执行需要消耗大量的性能，
影响读写
固定的表结构
高并发读写需求
海量数据的高效率读写

a2.非关系型数据库（mongodb)：
特性：
使用键值对存储数据
分布式
不支持ACID特性
非关系型数据库严格上来说，不算是一种数据库，应该是一种数据结构化存储方法的集合
优点：
无需经过sql层的解析，读写性能高；
基于键值对，数据没有耦合性，容易扩展；
存储数据的格式，nosql使用key:val的形式，文档的形式，图片形式等等，而关系型数据库则只支持基础类型
缺点：
不提供sql支持，学习成本高
无事务处理，附加功能和报表支持也不好

10.get和post的区别

(1)get把请求的数据放在地址栏， post把请求的数据放在请求体里
(2)post请求更为安全，通常用于表单提交
(3)get请求发送的数据大小是有限（大小根据浏览器不同而不同，有的8M有的2M通常4M，post理论上是没有大小限制的。http协议规范也没有进行大小限制，起限制作用的是服务器和处理程序的处理能力）
(4)post能发送更多数据类型，get请求的内容浏览器会主动缓存

11.你认为测试人员需要什么能力？

测试岗位所需硬技能：计算机技能、测试技能、业务分析能力，缺陷洞察能力，团队协作能力，专业技术能力；软技能包括:细心耐心、沟通能力、学习能力、解决问题能力等。

12.提了一个bug，但是开发认为不是bug，作为测试你怎么办？

首先确认开发环境是否跟自己测试环境一致，排除因环境或者业务理解不一致而产生的错误bug。保证测试过程中的正确性，确认是实实在在的bug，跟开发保持有效的沟通。严重级别较高的bug，对应需求文档、测试出现的bug截图、bug对产品影响的危害，跟开发说明清楚。若开发仍然不接收bug，需要找上级或产品介入。级别较低的建议性bug，开发不改，暂时不需要花费大量时间去说服修改，有时间再进行集中跟进。以上就是我的回答，谢谢。

建议回答内容：开发不改的原因梳理、bug严重等级去分别处理。

13.你觉得你个人的优缺点是什么？

对于测试岗位来说，我觉得我个人的优点就是具备一定的专业技能和项目经验，能很快适应新工作，有较强的自我学习意识，对于新事物接受能力快，空闲时间也会在网络上了解和学习行业的新技术；我的缺点就是做事比较固执死板，有时容易和人较真。

建议回答内容：优点尽量符合这个行业；缺点的话，回答要有转折性，可以是缺点，但从某一方面来说，也可以成为自身的优点。

14.给你发两道算法题目说一下你的思路？

如果你对编程语言不是很熟千万不要拒绝，就算不会也要体验思考下开口讲讲自己的思路

15.你有什么问题想问我们的

技术面：
想了解下咱们公司的主要项目，目前正在做的项目?
如果有幸入职的话，想清楚我主要负责哪一部分的工作?
想清楚咱们公司的开发团队、测试团队的人员构成?
做什么类型的产品？
有多少测试，主要负责什么工作?
自己如果进去后做什么类型的测试?

HR面：
想了解下咱们公司的企业文化?
如果入职了，想问下有新员工入职培训，像公司介绍、规章制度及岗位职责这种么?
建议回答内容：
不要说没有了，不要问敏感信息，例如私人问题；
提问问题1-3个为好；
建议问关于所做项目、合作团队构成。

面试易踩雷的问题:

1.在上家公司为什么离职？

我的回答：
(1)加班有点多，除了工作日一二四加班到八点半，特别是月底项目迭代发布需要连续一周晚上加班到10-11点多，有一次还直接到凌晨4点，身体吃不消(抱怨情绪严重，那来我们公司了岂不是也不接受加班？)
(2)部门扩大，测试人员剧增，压力大，晋升空间小(就这点抗压能力？)
(3)薪资方面不尽人意(来我们这岂不是薪资要求会很高)
建议回答：
上家公司年龄结构偏大，管理模式比较冗杂，人员趋于饱和，缺乏新鲜血液的注入，我自己已经具备了一定的专业技能和项目经验，希望可以接触更大的平台，迎接更多的挑战。

建议回答内容：总结三点，领导太烂、加班太多、工资太低，回答尽量委婉含蓄，不可直接表述，抱怨太重。

2.你期望的薪资是多少？

我的回答：不低于12k吧，因为我目前公司是12k(其实是我当时是10k，当时面试官就问现在12k咋还期望薪资是12k，我瞬间…)

在这里还是建议大家说一个区间。如：“我期望的薪资是13k到15k。”
一般来说这个区间不能太大，保持在[ 2000~3000 ]块都是比较合理的。
这个区间的下限绝对不能低于你能接受的底线，当HR给出的薪资已经低于你能接受的底线，你就可以直接拒绝。
说区间的原因是因为给双方都留一定谈判的空间。

3.你期望的公司是什么样子的？

我的回答：香港上市公司或者金融方面的(其实与面试公司体质相悖我还一个劲的说…)

在这里还是建议大家面试前了解下面试公司的大概性质和属性，面试期望公司的回答尽量往上面靠