在boss和拉钩上投了有几十份简历，其中70%未读状态，30%已读，已读的一半回复要求发送附件简历，然后这周接到面试的有七、八家公司，所以，当前这个大环境真的难

　　这半个月来，每天安排三到四场面试，平均每个公司至少都是两轮面试打底，经此一役，截止今天下午，算是拿到四个offer，两个已经发了，两个口头约定好了。个人比较心仪其中的一家外企，毕竟不太卷，真的国内的互联网公司真的卷怕了，还不稳定，说不定哪天就被优化了，那么今天我就先分享一些此次面试第一面技术面试的经验，希望对大家有所帮助，加油！冲！

　　技术面试题

　　需求宣讲-->需求评审-->技术评审-->测试用例评审-->研发冒烟-->研发提测-->测试提测预检.->测试泳道测试.>发布班车..>测试集成测试(产品验收)->预发环境发布-->生产环境发布(产品测试验收)-->线上数据监控(1-2天)-->业务文档沉淀(我公司是这样，大家根据实际情况说明即可)

　　2.测试流程有没有什么可以改进的地方?这些问题，你有反馈并且拿到结果吗?

　　1)规范发版流程，周二周四窗口期，APP类双周迭代，回收研发线上发布权限；

　　2)规范提测流程，增加提测准入条件，提测打回流程，冒烟不通过惩罚机制；

　　3)规范产品评审，新增需求宣讲，产品完成度90%以上进入评审，需求完成度较低打回；

　　4)引入线上CS机制，PO，P1故院复盘，P3，P4 CS沉淀，记录踩坑经验，反推流程优化或者基础功能建设。

　　3. 需求不明确，通过哪些方式解决?

　　1)根本还是流程机制的问题。团队合作不能依赖个人的靠谱，而是需要一种流程机制来建立，责任人和协作方式是机制运作两个不可或缺的要素。流程机制方面的建立也可以参考敏捷和精益思想。

　　2)从沟通上去突破，项目的高质量和及时交付是产研的共同目标，从共同目标出发去沟通解决合作中的问题。

　　4.测试任务多，时间不够，怎么办?

　　个别项目问题：

　　· 是否测试范围为评估不全，导致估时过于乐观，估时研发测试工时比3:1(加时间)

　　· 是否有阻塞测试进度的问题(bug，测试环境等)，占用测试时间倒排期项目，功能较多，测试时间不足(砍需求，分批上线)2)多数项目问题

　　· 测试效率是否有问题，是否有过多冗余测试用例

　　· 是否经常有并行测试，导致测试节奉达不到预期(资源分配)

　　· 长时间人员负荷大于80%，任务安排是否合理，测试人力是否达到瓶颈(加人)

　　5.介绍一下cookie, session 和token的区别

　　1)session存储于服务器，可以理解为一个状态列表，拥有一个唯一识别符号 sessionId，通常存放于cookie中，服务器收到cookie后解析出sessionld，再去session列表中查找，才能找到相应 session。

　　2)cookie类似一个令牌，装有sessionId，存储在客户端，浏览器通常会自动添加。

　　3)cookie安全性比session差。

　　4)token也类似一个令牌，无状态，用户信息都被加密到token中，服务器收到 token后解密就可知道是哪个用户。

　　6. Get 和 Post请求的区别

　　1)get 是从服务器上获取的数据，post 则是向服务器传送数据。

　　2)get 的参数在 URL 中可以看到，post 的参数用户看不到。

　　3)get 传送的数据量较小，不能大于 2KB。post 传送的数据量较大，一般被默认为不受限制。

　　4)get 安全性比较低，post 安全性较高。

　　7.常见的状态码有哪些?

　　2 代表成功；

　　200:请求正常处理完毕3 代表重定向；

　　301:永久重定向，资源已分配新 URI；

　　302:临时重定向，资源已临时分配新 URI4 代表客户端错误；

　　400:请求报文语法错误，或者参数错误401:需要通过HTTP认证，或认证失败403:请求资源被拒绝；

　　404:无法找到请求资源，服务器无理由拒绝5 代表服务端错误；

　　500:服务器内部错误；

　　501:请求未完成。服务器不支持所请求的功能503:服务器超负荷，或者停机维护。

　　8. HTTP 和 HTTPS 的区别?

　　1)http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

　　2)http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80。

　　9.怎么排查是前端问题还是后端问题或者数据问题?

　　1)通过抓包确认前端是否调用接口，如果接口未调用，那就前端问题。

　　2)如果接口正常返回结果，但是结果不是预期结果，要确认前端传参是否正确，若是传参不对，则是前端问题，若传参正确，但结果返回错误，那就是后端问题。

　　3)如果后端接口返回数据正确，但是页面显示和渲染错误，这也是前端问题。

　　1)手机作为通信工具，来电、去电、接收短信等操作都会对app应用程序产生影响，所以app测试第一个要考虑的属性特征是:中断测试，来电中断:呼叫挂断、被呼叫挂断、通话挂断、通话被挂断短信中断:接收短信、查看短信。

　　其他中断:蓝牙、闹钟、插拔数据线、手机锁定、手机断电、手机问题。(系统死机、重启)

　　2)手机用户对app产品的安装卸载操作:从上一个版本/上两个版本直接升级到最新版本。

　　· 全新安装新版本

　　· 新版本覆盖旧版本安装卸载旧版本，安装新版本卸载新版本，安装新版本

　　· web和app测试，单从功能界面测试来说，没有什么差异。有差异的主要是以下几点:

　　1.系统结构

　　web端，是B/S架构的，服务端有修改的话，客户端会同步更新。

　　app，是C/S架构的，如果服务端有修改的话，客户端必须更新，核心版本的客户端都要重新回归测试。

　　2.性能指标

　　web端:响应时间、CPU、内存、吞吐量。

　　app:响应时间、CPU、内存、吞吐量、手机流量、手机电量。

　　3.兼容测试方面

　　web端:浏览器兼容;PC端的操作系统。(windows、mac、linux)

　　app:手机操作系统(安卓、ios、windows);手机型号;分辨率。(手机屏幕大小)

　　4.相对于web，app有一些专项测试干扰测试(来电、信息、其他应用)弱网络测试、网络切换测试安装、更新、卸载。

　　5.测试工具 app:appium web:selenium

　　web端:屏幕左上角、右下角。

　　app:手势、手机横屏竖屏、触控、前后台切换，边角测试。

　　11. 性能测试关注哪些指标?

　　1)响应时间(RT):响应时间是指系统对请求作出响应的时间。

　　2)吞吐量(Throughput):吞吐量是指系统在单位时间内处理请求的数量。

　　3)并发数:并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。

　　4)OPS:Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

　　5)TPS:是TransactionsPerSecond的缩写，是一台服务器每秒能够出处理的事务数。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

　　12. 请问你们公司是如何做接口测试的?

　　接口测试实际跟一般测试不同就是测试用例的设计部分。

　　1）获取接口规范。

　　2）设计接口测试功能用例(主要从用户角度出发看接口能否实现业务需求，用例设计就是黑盒用例那一套)。

　　3）各种入参验证(正常情况，异常情况包括输入参数个数不对，类型不对，可选/必选，还有考虑参数有互斥或关联的情况)。

　　4）接口返回值各种验证。(符合接口文档需求)

　　5）了解接口实现逻辑，实现逻辑覆盖。(语句/条件/分支/判定/...)

　　6）接口能并发执行吗、安全吗，性能满足要求吗?

　　7）采用工具或者自写代码来验证。

　　8）发现问题跟功能测试一样，该报 bug 报 bug，该跟踪状态的跟踪状态。

　　13.怎么设计接口测试用例?

　　通常，设计接口测试用例需要考虑以下几个方面:

　　①是否满足前提条件。

　　有些接口需要满足前提，才可成功获取数据。常见的，需要登录 Token逆向用例:针对是否满足前置条件(假设为n个条件)，设计 0~n 条用例。

　　②是否携带默认值参数。

　　正向用例:带默认值的参数都不填写，不传参，必填参数都填写正确且存在的““常规”值，其他不填写，设计1条用例。

　　③业务规则、功能需求。

　　这里根据时间情况，结合接口参数说明，可能需要设计N条正向用例和详向思例。