本文为霍格沃兹测试学院学员学习笔记，进阶学习文末加群。

本系列文章总结演绎了一些软件测试工程师常见的面试题，次要来源于集体面试遇到的、网络收集（欠缺）、工作日常探讨等，分为以下十个局部，供大家参考。如有谬误的中央，欢送斧正。有更多的面试题或面试中遇到的坑，也欢送补充分享。心愿大家都能找到称心的工作，共勉之！

软件测试工程师面试题系列篇 | 目录

  1. 测试常见问题与流程篇
  2. 测试工具篇
  3. 计算机网络常识与数据库篇
  4. Linux 篇
  5. Python 编程篇
  6. 自动化测试篇：蕴含 Selenium、Appium 和接口测试
  7. 性能测试篇
  8. 软素质篇：10 大灵魂拷问
  9. 反诘面试官篇
  10. 计算机网络篇（基础知识）
1.善于哪些开发语言？
  • 学习过 Java，C 等
  • 半精通 Python
2.输出 URL 到网页显示进去的全过程

a. 输出网址
b. DNS解析
c. 建设tcp连贯
d. 客户端发送HTTP申请
e. 服务器解决申请
f. 服务器响应申请
g. 浏览器展现HTML
h. 浏览器发送申请获取其余在HTML中的资源。

3.HTTP 和 HTTPS 的区别
  • HTTPS 外面是要有证书的，HTTP 并没有证书。证书的作用是证实你是这个网站的拥有者。谁去证实？最顶级的 CA 去帮你证实，这些顶级的 CA 都是浏览器、操作系统自身就主动帮你集成，而且主动增加到设置信赖外面去；
  • HTTPS 要兼顾平安+性能的方面，因为对称式加密尽管速度很快，然而安全性特地的低，因为单方要规定对称式加密的秘钥，他人都无奈晓得，但你怎么能确保他人不晓得你的秘钥呢，因而须要有非对称式加密去保障平安，但非对称式加密速度又很慢，如果客户端和服务器端都用非对称式加密，网络得卡死了。所以当单方建设好了非对称加密后，再约定一个随机数，等大家都非对称解密了之后呢，就拿到只有对方晓得的惟一随机数（秘钥），就能够用秘钥来进行对称式加密和解密了；
4.HTTP 的报文构造
  • HTTP申请报文：一个HTTP申请报文由申请行、申请头部、空行和申请数据4个局部组成
  • HTTP响应报文：HTTP响应也由三个局部组成，别离是：状态行、消息报头、响应注释
5.HTTP 常见的响应状态码
  • 200 申请已胜利，申请所心愿的响应头或数据体将随此响应返回。
  • 201 申请曾经被实现，而且有一个新的资源曾经根据申请的须要而建设，且其 - - URI 曾经随 Location 头信息返回
  • 202 服务器已承受申请，但尚未解决
  • 301 （永恒挪动） 申请的网页已永恒挪动到新地位。服务器返回此响应（对 GET 或 HEAD 申请的响应）时，会主动将请求者转到新地位。
  • 302 （长期挪动） 服务器目前从不同地位的网页响应申请，但请求者应持续应用原有地位来进行当前的申请。
  • 303 （查看其余地位） 请求者该当对不同的地位应用独自的 GET 申请来检索响应时，服务器返回此代码。
  • 304 （未修改） 自从上次申请后，申请的网页未修改过。服务器返回此响应时，不会返回网页内容。
  • 305 （应用代理） 请求者只能应用代理拜访申请的网页。如果服务器返回此响应，还示意请求者应应用代理。
  • 307 （长期重定向） 服务器目前从不同地位的网页响应申请，但请求者应持续应用原有地位来进行当前的申请。
  • 401 以后申请须要用户验证。如果以后申请曾经蕴含了 Authorization 证书，那么
  • 401 响应代表着服务器验证曾经回绝了那些证书
  • 403 服务器曾经了解申请，然而拒绝执行它。与 401 响应不同的是，身份验证并不能提供任何帮忙，而且这个申请也不应该被反复提交
  • 404 申请失败，申请所心愿失去的资源未被在服务器上发现
  • 500 服务器遇到了一个未曾意料的情况，导致了它无奈实现对申请的解决。一般来说，这个问题都会在服务器的程序码出错时呈现。
  • 501 服务器不反对以后申请所须要的某个性能。当服务器无奈辨认申请的办法，并且无奈反对其对任何资源的申请。
  • 502 作为网关或者代理工作的服务器尝试执行申请时，从上游服务器接管到有效的响应。
  • 503 因为长期的服务器保护或者过载，服务器以后无奈解决申请。这个情况是长期的，并且将在一段时间当前复原。
6.cookie 和 session 机制的区别
  • cookies 数据保留在客户端，session 数据保留在服务器端；
  • cookies 能够加重服务器压力，然而不平安，容易进行 cookies 坑骗；
  • session 较平安，但占用服务器资源
7.TCP 和 UDP 的区别
  • TCP：面向连贯，牢靠的，速度慢，效率低
  • UDP：无连贯、不牢靠、速度快、效率高
8.TCP 为什么是三次握手和四次挥手
  • 三次握手能保证数据牢靠传输又能进步传输效率。若握手是两次：如果只是两次握手， 至少只有连贯发起方的起始序列号能被确认，另一方抉择的序列号则得不到确认；
  • 要保障单方都敞开了连贯。因为 TCP 是全双工的，就是要等到两边都发送 fin 包确认单方都没有数据传输后才敞开；
9.TCP为什么最初挥手后会有time_wait
  • 为了保障牢靠的断开TCP的双向连贯，确保足够的工夫让对方收到 ACK 包。若客户端回复的 ACK 失落，server 会在超时工夫到来时，重传最初一个 fin 包，处于 TIME_WAIT 状态的 client 能够持续回复 Fin 包，发送 ACK。
  • 保障让迟来的 TCP 报文段有足够的工夫被辨认和抛弃，防止新旧连贯混同。有些路由器会缓存没有收到的数据包，如果新的连贯开启，这些数据包可能就会和新的连贯中的数据包混在一起。连贯完结了，网络中的提早报文也应该被抛弃掉，免得影响立即建设的新连贯。
10.简要阐明 HTTP 申请中的 Post 和 Get 有哪些区别的中央
  • 申请头多了 content-length 和 content-type 字段
  • Post 能够附加 body，能够反对 form、json、xml、binary 等各种数据格式
  • 行业通用标准
  • 无状态变动的倡议应用 Get
  • 数据的写入与状态的批改倡议应用 Post
  • 基于 HTTP 协定：都是申请返回数据，Get 将申请体放在头上，只发一次申请，Post 将申请体放在外部，须要发送两次申请
  • GET 在浏览器回退时是有害的，而 POST 会再次提交申请。
  • GET 申请会被浏览器被动 cache，而 POST 不会，除非手动设置。
  • GET 申请只能进行 URL 编码，而 POST 反对多种编码方式。
  • GET 申请在 URL 中传送的参数是有长度限度的，而 POST 么有。
  • 对参数的数据类型，GET 只承受 ASCII 字符，而 POST 没有限度。
  • GET 比 POST 更不平安，因为参数间接裸露在 URL 上，所以不能用来传递敏感信息。
11.如果一个申请，返回的状态码是 200，然而没有内容，可能产生了什么？
  • 申请头缺失或谬误
  • 参数 length 不符
  • 以上为集体了解，有误请斧正。

数据库篇

1. 工作中常应用的 SQL 语法有哪些？
  • create table、create view、 select from where、insert into、update set values、delete、alter、order by、having
2.数据库存储过程
  • 一组数据库操作命令，当作是本人写的一个办法，一系列步骤本人去封装（集体了解）
3.SQL 常见查问语句编写（此处仅举例常见的查问语句，如有更多坑，心愿补充）
a.查问所有学生的数学问题，显示学生姓名 name, 分数， 由高到低。
SELECT a.name, b.score FROM student a, grade b WHERE a.id = b.id AND kemu = '数学' ORDER BY score DESC；
b.统计每个学生的总成绩（因为学生可能有反复名字）,显示字段：学生 id，姓名，总成绩。
SELECT a.id, a.name, c.sum_score from student a, (SELECT b.id, sum(b.score) as sum_score FROM grade b GROUP BY id) c WHERE a.id = c.id ORDER BY sum_score DESC；
c.列出各门课程问题最好的学生， 要求显示字段: 学号，姓名,科目，问题
SELECT c.id , a.name, c.kemu, c.score FROM grade c, student a,(SELECT b.kemu, MAX(b.score) as max_score FROM grade b GROUP BY kemu) t WHERE c.kemu = t.kemu AND c.score = t.max_score AND a.id = c.id
4.慢查问是什么意思？
  • 开启慢查问日志，能够让 MySQL 记录下查问超过指定工夫的语句，通过定位剖析性能的瓶颈，能力更好的优化数据库系统的性能。
5.导致数据库性能差的可能起因有哪些？
  • 硬件环境问题，如磁盘IO
  • 查问语句问题，如join、子查问、没建索引
  • 索引生效，建了索引，查问的时候没用上
  • 查问关联了太多的join
  • 服务器关联缓存，线程数等
  • 表中存在冗余字段，在生成笛卡尔积时消耗多余的工夫
6.Redis 缓存利用场景
  • 须要将数据缓存在内存中，晋升查问效率
  • 这里心愿大家补充
7.怎么定位 Redis 缓存生效问题（缓存坏了）
  • Redis 的常识，理解的不是很多
  • 抛砖引玉，请大家斧正和补充。

更多内容，咱们在后续文章分享。

收费支付：接口测试+性能测试+自动化测试+测试开发+测试用例+简历模板+测试文档