乐趣区

关于软件测试:测试面试题集锦三-计算机网络和数据库篇附答案

jiezi

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

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

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

  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 的常识，理解的不是很多
  • 抛砖引玉，请大家斧正和补充。

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

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

退出移动版