感謝大家的蒞臨，小編在文章末尾為大家準備了一些福利，需要的可以獲取哦。

本科畢業(yè)于武漢某二本普通院校，本人 16 年開始工作，曾任職上海嗶哩嗶哩科技有限公司（B 站）高級測試開發(fā)，目前在一家云計算公司擔任測試工程師，日常工作比較繁雜，主要負責功能測試，自動化測試，性能測試以及測試工具的開發(fā)。

工作六年左右，參與大大小小的面試將近 100 多場，拿到過貨拉拉、眾安保險、得物、網(wǎng)易和百度等公司的 offer,所以在測試工程師日常學習、面試等方面具備豐富的經(jīng)驗，又加上最近 “金三銀四”，所以想把最近幾年積攢的部分面試題和答案分享給大家，后期看文章熱門程度，再陸續(xù)分享其他面試題和答案。

一.基礎題

1.測試用例你一般是怎么設計的，怎么可以提高覆蓋率？

有沒有形成自己的 一套方法論？

答：這些都是基礎的理論題。

2.電梯、朋友圈、紅包、登錄功能是怎么測試的？用例設計

答：這些都是基礎的用例設計題目，網(wǎng)上一大堆，建議面試前多準備幾個，總結其中的規(guī)律。

3.假如讓你獨立負責一個大項目，你是如何開展測試的？

答：可以理解為如何保障產品質量，從需求分析理解、用例設計和評審、測試 bug 提交和跟蹤、上線驗證、項目復盤等等方面回答。

4.接口測試你是怎么做的？都發(fā)現(xiàn)了哪些問題，詳細說下定位分析過程。

答：如截圖：

遇到問題如截圖：

5.測試過程中你遇到最難的一個技術問題是什么？如何解決的？

答：面試前重點準備一個類似的題目，比如開發(fā)了測試工具，提高效率，搭建自動化框架或平臺，引入了測試覆蓋率工具、代碼檢測工具等等

6.你們整個測試流程是怎樣的？

答：大致分為以下幾種測試需求分析階段、測試計劃階段、測試設計階段、測試執(zhí)行階段、測試評估階段。

二.網(wǎng)絡相關

http 和 https ,tcp 和 udp 協(xié)議區(qū)別，網(wǎng)絡七層模型，

答：HTTPS 和 HTTP 的區(qū)別主要如下：

tcp 和 udp 協(xié)議區(qū)別:

網(wǎng)絡七層模型：

2.tcp 為啥三次握手，為啥四次揮手，

答：因為當 Server 端收到 Client 端的 SYN 連接請求報文后，可以直接發(fā)送 SYN+ACK 報文。其中 ACK 報文是用來應答的，SYN 報文是用來同步的。但是關閉連接時，當 Server 端收到 FIN 報文時，很可能并不會立即關閉 SOCKET，所以只能先回復一個 ACK 報文，告訴 Client 端，"你發(fā)的 FIN 報文我收到了"。只有等到我 Server 端所有的報文都發(fā)送完了，我才能發(fā)送 FIN 報文，因此不能一起發(fā)送。故需要四步握手。

3.tcp 擁塞算法、滑動窗口、重傳機制、粘包和拆包

答：滑動窗口協(xié)議（Sliding Window Protocol）、重傳機制詳情見

TCP 滑動窗口/快速重傳機制Shawei的博客-CSDN 博客_tcp 快速重傳機制 。

拆包 ：TCP 直接將應用層數(shù)據(jù)包（可以認為就是一個數(shù)組）發(fā)給接收方，并且根據(jù) TCP 協(xié)議，TCP 會將每個發(fā)送的數(shù)據(jù)包編號（序列號），發(fā)送完一個序列號后，接收端收到會回復該序列號，代表已經(jīng)被接受，but 接收端有自己的 TCP 緩存區(qū)，它會將多個包積累在一起再進行處理，這樣的結果是導致包與包之間 “無縫連接”，即所謂的” 粘包 “

粘包:針對此問題，就有了一些解決辦法：哪每個包長度固定：這樣接收端就可以每隔一定長度進行拆包，但缺點是浪費資源,加入頭部信息：每個數(shù)據(jù)包前加入該數(shù)據(jù)包中數(shù)據(jù)的長度值，這樣接收端從緩存中讀取時，通過讀該頭部信息，知道了每個包的長度，這樣就能拆包

4.一些抓包工具如 fidder、tcpdump 的使用，

答：網(wǎng)上都有現(xiàn)成的使用教程，可以選一兩篇去操作下。

5.瀏覽器輸入百度網(wǎng)址發(fā)生了什么？DNS 解析過程

答：這個問題比較寬泛，整個流程也比較長，涉及到網(wǎng)絡 7 層模型、dns 解析、tcp/ip 協(xié)議簇，三次握手、負載均衡、集群架構、數(shù)據(jù)庫，linux 系統(tǒng)狀態(tài)、進程切換等等方面，看你自己對哪塊比較熟悉，重點去說

6.說下 cookies，session 鑒權機制？為什么要引入這套機制？

答：

引入原因：HTTP 是無狀態(tài)的協(xié)議（對于事務處理沒有記憶能力，每次客戶端和服務端會話完成時，服務端不會保存任何會話信息）：每個請求都是完全獨立的，服務端無法確認當前訪問者的身份信息，無法分辨上一次的請求發(fā)送者和這一次的發(fā)送者是不是同一個人。所以服務器與瀏覽器為了進行會話跟蹤（知道是誰在訪問我），就必須主動的去維護一個狀態(tài)，這個狀態(tài)用于告知服務端前后兩個請求是否來自同一瀏覽器。而這個狀態(tài)需要通過 cookie 或者 session 去實現(xiàn)。

三.數(shù)據(jù)庫重中之重

簡單

1、基本的增刪改查語句；

答：insert、delete、update、select sql 編寫。

2、多表聯(lián)合查詢、左右連接區(qū)別、子查詢等；

答：網(wǎng)上都有教程，可以自行查找，在這里不做贅述。

3、聚合、分組、排序 sql 語句編寫、having 和 where 區(qū)別

答：表數(shù)據(jù)

sql 編寫：

SELECT

class 班級名稱,

COUNT(*) 每個班級人數(shù),

MAX(grade) 最高分,

MIN(grade) 最低分,

SUM(grade) 班級總分,

AVG(grade) 平均分

FROM

student

where age <20

GROUP BY

class

HAVING SUM(grade) >=34

ORDER BY

最高分 DESC

執(zhí)行結果：

4、char 和 varchar 區(qū)別等

答：varchar;表示變長字符串,char;定長字符串。

5、三范式是什么？

答：第一范式 (確保每列保持原子性)、第二范式 (確保表中的每列都和主鍵相關)、第三范式 (確保每列都和主鍵列直接相關,而不是間接相關)

中級

1、說一下 sql 是怎么優(yōu)化的？

答：show variables like '%quer%'; 查詢慢查詢日志相關的設置，找出慢查詢的 sql ,用 explain 查詢 sql 的執(zhí)行計劃，該加索引的加索引（要知道索引正確使用場景如下面試題），盡量少 連接查詢、select *、避免類型轉換，減少回表次數(shù)。

2、索引的概念、類型，優(yōu)缺點分析、索引應用場景和索引失效場景；

答：索引是幫助 mysql 高效獲取數(shù)據(jù)的數(shù)據(jù)結構

優(yōu)點：

a）可以保證數(shù)據(jù)庫表中每一行的數(shù)據(jù)的唯一性，

b）可以大大加快數(shù)據(jù)的檢索效率，

c）加速表與表之間的連接，

d）在使用分組和排序子句進行數(shù)據(jù)檢索時，同樣可以顯著減少查詢中分組和排序的時間。

f）通過使用索引對數(shù)據(jù)進行排序，降低數(shù)據(jù)排序的成本，降低 cpu 的消耗，可以在時間查詢的過程中，使用優(yōu)化隱藏器，提高系統(tǒng)的性能。

缺點：

a) 創(chuàng)建索引和維護索引要耗費時間，這種時間隨著數(shù)據(jù)量的增加而增加。

b) 索引會占據(jù)磁盤空間。

c) 以表中的數(shù)據(jù)進行增、刪、改的時候，索引也要動態(tài)的維護，這就降低了整數(shù)的維護速度。

索引類型：

主鍵索引：索引列中的值是唯一的并且不允許有空值

普通索引：mysql 的基本索引類型，沒有什么限制，允許有重復值和空值

唯一索引：索引列中的值是唯一的，但是允許有空值

還有其他索引 譬如全文索引、空間索引、前綴索引等不常見

4、mysql 幾個存儲引擎，innodb 和 MyISAM 區(qū)別

答:MySQL 有多種存儲引，MyISAM、InnoDB、MERGE、MEMORY(HEAP) 等

InnoDB 和 MyISAM 區(qū)別：

1）. InnoDB 支持事務，MyISAM 不支持事務。這是 MySQL 將默認存儲引擎從 MyISAM 變成 InnoDB 的重要原因之一；

2）. InnoDB 支持外鍵，而 MyISAM 不支持。對一個包含外鍵的 InnoDB 表轉為 MYISAM 會失?。?/p>

3）. InnoDB 是聚集索引，MyISAM 是非聚集索引。聚簇索引的文件存放在主鍵索引的葉子節(jié)點上，因此 InnoDB 必須要有主鍵，通過主鍵索引效率很高。但是輔助索引需要兩次查詢，先查詢到主鍵，然后再通過主鍵查詢到數(shù)據(jù)。因此，主鍵不應該過大，因為主鍵太大，其他索引也都會很大。而 MyISAM 是非聚集索引，數(shù)據(jù)文件是分離的，索引保存的是數(shù)據(jù)文件的指針（就是物理地址）。主鍵索引和輔助索引是獨立的 。

注意：MyISAM 無論是主鍵還是非主鍵索引 ，data 存儲的都是這條數(shù)據(jù)的物理地址（地址指針），innodb 主鍵索引的 data 就是這條數(shù)據(jù)，非主鍵索引的 data 是主鍵 id，

高級

1.索引底層機制，B+ 樹特性，和其他數(shù)據(jù)結構（二叉樹、紅黑樹）區(qū)別，

答：這個屬于高級特性，后續(xù)公眾號會重點輸出數(shù)據(jù)庫相關的知識和面試題

2.mysql 事務隔離級別、MVCC 是什么，

答：

MVCC ，Multi-Version Concurrency Control，多版本并發(fā)控制。MVCC 是一種并發(fā)控制的方法，一般在數(shù)據(jù)庫管理系統(tǒng)中，實現(xiàn)對數(shù)據(jù)庫的并發(fā)訪問；在編程語言中實現(xiàn)事務內存

3.數(shù)據(jù)庫鎖類型，什么是數(shù)據(jù)庫死鎖，如何避免？

答：從數(shù)據(jù)庫系統(tǒng)角度分為三種：排他鎖、共享鎖、更新鎖。

從程序員角度分為兩種：一種是悲觀鎖，一種樂觀鎖，等等

避免死鎖方式：

結構化數(shù)據(jù)建模：基于范式原則初級建模

熱點業(yè)務排解：挖出核心業(yè)務模型

應用拆解：降低時間片復雜度

提升性能：優(yōu)化代碼，集群、超時機制、回滾機制

4.主從底層數(shù)據(jù)同步機制、binglog、redolog、undolog 區(qū)別，

答：redo log：確保事務的持久性。防止在發(fā)生故障的時間點，尚有臟頁未寫入磁盤，在重啟 mysql 服務的時候，根據(jù) redo log 進行重做，從而達到事務的持久性這一特性。undo log：回滾日志保存了事務發(fā)生之前的數(shù)據(jù)的一個版本，可以用于回滾，同時可以提供多版本并發(fā)控制下的讀（MVCC），也即非鎖定讀 binlog：二進制日志作用：用于復制，在主從復制中，從庫利用主庫上的 binlog 進行重播，實現(xiàn)主從同步。 用于數(shù)據(jù)庫的基于時間點的還原。

四.開發(fā)語言，java 這塊后續(xù)我會陸續(xù)推出一些 java 基礎專欄，

面對對象三大特性、通俗解釋，八大基本數(shù)據(jù)類型及其大小，循環(huán)、判斷等語法

2.java 集合 如 arraylist、linkedlist、hashmap 等特性和底層實現(xiàn)原理 ；

3.java 鎖類型，線程安全、線程池、juc 并發(fā)組件、反射等；

4.Jvm 內存結構，不同版本區(qū)別，gc 方法，調優(yōu)，命令等等；

5.springboot、spring、mybatis 等框架的使用和常見面試題

6.單例、工廠、適配器等設計模式

7.zk、dubbo、springcloud 等相關 java 框架是否接觸過？底層原理

8.分布式事務、分布式鎖、冪等性等常見分布式問題是否了解？解決方式？

五.自動化，這塊是面試官重點去考察的地方，

1.自己開發(fā)的自動化框架嗎？為啥要開發(fā)這么一個框架呢？市面上很多自動化平臺為什么不用，卻要自己搭建？想過投入產出比嗎？

答：自己搭建，主要是項目每次上線之前，回歸重復的功能占用大量迭代時間，通過自動化框架可以節(jié)約時間，市面上的測試平臺得自己部署和維護，出現(xiàn)問題需要自己去查底層代碼解決，學習門檻較高，并且很多功能幾乎用不到，自己搭建的自動化框架，開發(fā)相對簡單，上手特別快，特別符合當前的項目需要。

2.說下接口自動化分別用了哪些框架，怎么實現(xiàn)的，你主要負責哪些部分？

答：我的主要是 springboot、testng、mysql、okhttpcilent、mq 那套東西。

3.你們這套框架最難的技術點有哪些？搭建框架過程中遇到哪些問題，怎么解決的？

答：難點技術有很多，譬如失敗用例重跑機制，異步接口校驗返回結果，場景測試中前置依賴接口怎么處理，涉及到 mq 怎么操作等等

4.流程場景怎么設計用例的？假如流程比較長，你怎么保障前面流程成功？

答：可以引入失敗用例重跑機制 testng 有接口實現(xiàn)、簡單接口，我們可以直接在數(shù)據(jù)庫造數(shù)據(jù)。

5.數(shù)據(jù)放哪的？數(shù)據(jù)驅動怎么做的？關鍵字驅動怎么做的？

答：看情況，如果是靈活的數(shù)據(jù)，建議放在 excel 里面，做數(shù)據(jù)驅動，如果是賬號、密碼這種修改很少的數(shù)據(jù)，可以考慮放在配置文件中，如果是那種一成不變的可以寫死（盡量別這么做）。

關鍵字驅動：測試用例的步驟 (元素) 和用例分離。關鍵字驅動表示把項目中的一些邏輯封裝成關鍵字 (一個函數(shù)名)。例如 login、 register、order 進行設置變量（Set Viriable）,調用不同的關鍵字組合實現(xiàn)不同的業(yè)務邏輯，從而驅動測試用例執(zhí)行。

數(shù)據(jù)驅動：數(shù)據(jù)和用例步驟分離，通過 excel、yaml 等文件保存數(shù)據(jù)。數(shù)據(jù)驅動是把測試用例里面的數(shù)據(jù)提取到 excel 或者 yam 文件里面，然后通過改變 excel 或 yaml 中的數(shù)據(jù)驅動測試用例執(zhí)行。

6.這套框架覆蓋了開發(fā)多少業(yè)務代碼，怎么統(tǒng)計出來的？多少用例，跑一次多長時間？

答：主要覆蓋所負責業(yè)務的主要流程和一些常見的異常流程，通過 jacoco 覆蓋率統(tǒng)計工具統(tǒng)計出來的，用例大概有 100+ 個，涉及到 30 多個接口，跑一次將近 2 分鐘左右。

7.開發(fā)修改接口和你的自動化代碼怎么同步修改，以保證自動化測試代碼不報錯？

答：依靠規(guī)范、或者技術手段。

六.性能測試重中之重，內容包羅萬象，涉及到性能測試方式、策略、監(jiān)控、分析調優(yōu)等方面

1.你們公司性能測試怎么做的，說一下流程？

答:基本流程就是產研測三方開會、一起定下 tps 基準值，測試設計性能測試計劃和測試用例、用例評審、進行壓測、觀測數(shù)據(jù)找出性能瓶頸，調優(yōu)持續(xù)壓測等等

2.TPS 上不去什么原因，怎么排查？響應時間太長怎么分析？

答：通過各種監(jiān)控技術如 prometheus 、skywalking 等 觀測系統(tǒng)瓶頸，基本上分為一下幾個方面 帶寬、連接池、硬件、垃圾回收機制、數(shù)據(jù)庫等方面去分析。

3.線程阻塞和死鎖問題怎么去定位分析，有什么現(xiàn)象?

答：在發(fā)生死鎖之后，程序卡住沒有任何反應，但程序仍在運行，因此需要借助一些命令來排查，用 JDK 自帶的命令 jstack -pid 去查看線程信息，jstack 很快就幫我們找到了死鎖的位置（在實際運行中，往往 dump 一次信息，還不足以確認問題，建議多 dump 幾次，如果每次 dump 都指向同一個問題，那么就可以確定是這個問題導致的線程死鎖）

4.內存泄露和內存溢出有什么區(qū)別？分別會有什么現(xiàn)象？怎么定位分析？

答：內存溢出（Out Of Memory）：就是申請內存時，JVM 沒有足夠的內存空間。通俗說法就是去蹲坑發(fā)現(xiàn)坑位滿了。

內存泄露（Memory Leak）：就是申請了內存，但是沒有釋放，導致內存空間浪費，通俗點就是占著那啥不那啥。

5.數(shù)據(jù)庫是怎么監(jiān)控的，sql 慢查詢怎么監(jiān)控分析？

答：見數(shù)據(jù)庫 sql 優(yōu)化面試題。

6.如何進行全鏈路監(jiān)控分析，定位性能瓶頸？

答：自行百度

7.壓測線上環(huán)境都會遇到什么問題，數(shù)據(jù)隔離怎么做的？如何減小對生產影響？

答：臟數(shù)據(jù)影響真實的業(yè)務響應和數(shù)據(jù)，可以考慮落入影子庫，mock 對象、或者數(shù)據(jù)帶有明顯標識等手段。

8.測試過程中都發(fā)現(xiàn)了哪些性能問題，怎么定位分析的?優(yōu)化方案是什么？

答：每個人準備的問題不一致，我的就是遇到了 jvm fullgc 頻繁導致接口響應時間慢，通過 java 一些命令定位分析發(fā)現(xiàn) jvm 配置不合理。

9.項目架構是怎么樣的？簡單描述或者畫圖

答：微服務架構，兩個入口、公眾號和 web 端，請求先經(jīng)過 Nginx 做負載均衡、流量均勻的打到項目的 api 網(wǎng)關，后面就是項目的微服務架構（采購單、供應商、庫存、倉庫物流等等）如果對后端采用的架構熟悉，可以順帶提一下，比如用了 springcloud 全家桶、eureka 做服務注冊和發(fā)現(xiàn)，mq 實現(xiàn)異步解耦，redis 緩存有效減少數(shù)據(jù)庫交互等等。

七.中間件相關問題,簡歷如果說了，面試官一般都會順帶問下

1.正向代理和反向代理區(qū)別？Nginx 了解嗎？負載均衡算法

答：Nginx 是一款自由的、開源的、高性能的 HTTP 服務器和反向代理服務器；同時也是一個 IMAP、POP3、SMTP 代理服務器；Nginx 可以作為一個 HTTP 服務器進行網(wǎng)站的發(fā)布處理，另外 Nginx 可以作為反向代理進行負載均衡的實現(xiàn)。

正向代理：服務器位于客戶端和服務器之間，為了從服務器獲取數(shù)據(jù)，客戶端要向代理服務器發(fā)送一個請求，并指定目標服務器，代理服務器將目標服務器返回的數(shù)據(jù)轉交給客戶端。這里客戶端需要要進行一些正向代理的設置的。舉例:翻墻，正向代理中被代理的是客戶端的請求

反向代理：客戶端對代理是無感知的，客戶端不需要任何配置就可以訪問，客戶端將請求發(fā)送到反向代理服務器，由反向代理服務器去選擇目標服務器獲取數(shù)據(jù)后，在返回給客戶端，此時反向代理服務器和目標服務器對外就是一個服務器，暴露的是代理服務器地址，隱藏了真實服務器 IP 地址。

負載均衡算法：輪詢、隨機、最少連接、hash、加權等，說一下具體使用場景

2.mq 是如何測試的？你項目中怎么應用的？mq 的優(yōu)缺點？為什么使用 mq？怎么保障 mq 消息的有序性、冪等性、可靠性（不丟失）

答：消息中間件 具備解耦、削峰、異步的作用，具體可自行百度

3.為什么使用 redis，redis 五種數(shù)據(jù)類型，如何測試 redis 的，項目中如何應用的？

答：基于內存查詢效率高，高并發(fā)情況下保護數(shù)據(jù)庫，string、hash、list、set、zset 五中數(shù)據(jù)類型，項目中主要用于請求 token 保存和失效，防重分布式鎖，冷數(shù)據(jù)（改動量?。┍４妫瑑绲刃孕ｒ灥鹊?。

4.都發(fā)現(xiàn)過哪些緩存方面的 bug，怎么定位的？

答：緩存和數(shù)據(jù)庫數(shù)據(jù)不一致，緩存穿透，擊穿，雪崩等

5.redis 穿透，擊穿，雪崩機制，被問了好幾次......

答：自行百度

八.算法，一些大廠必問，百度、阿里、字節(jié)、騰訊等

1.常見的排序算法，冒泡，快排等

2.數(shù)組，字符串的相關算法操作比如找一個字符串中重復最長的字符串、兩數(shù)之和等

3.簡單的數(shù)據(jù)結構棧，隊列，鏈表的基本的操作等

算法這塊沒有捷徑，需要日積月累，一些常見的算法題，盡量在理解的基礎上去默寫并記熟，有些網(wǎng)站?？途W(wǎng)、LeetCode 刷刷題加強一下。

九.其他

假如測試任務重，時間緊，但是人手不夠你怎么處理？

答：向上反饋真實情況、加派人手、爭取更多時間或削減不必要需求，測試中要充分理解需求，設計用例加強評審，需求排優(yōu)先級等等

2.假如開發(fā)不認可你提出 bug,怎么辦？

答：自己重新復現(xiàn)一下提出的 bug,如果確實是 bug,可以和開發(fā)當面溝通清楚，溝通無效則向上反饋。

3.線上有碰到過漏測的 bug 嗎？怎么處理的

答：碰到過，可以說一個不大不小的漏測案例（前提是別人的 bug 才導致的），重點說下防止下次漏測措施。

4.職業(yè)規(guī)劃，離職原因。

答：這個開發(fā)性題目，離職原因盡量別說上家公司壞話。

福利

為方便大家自學軟件測試，特意給大家準備了一份200G的超實用干貨學習資源，涉及的內容非常全面。關注公眾號【清風酔】自行獲取

主體內容包含：阿里、騰訊、美團、字節(jié)跳動等等測試面試題，功能測試、性能測試、自動化測試等學習視頻等知識內容。

人生是一個逆水行舟的過程，不進則退，咱們一起加油吧！

測試工程師職業(yè)發(fā)展路線圖

功能測試 — 接口測試 — 自動化測試 — 測試開發(fā) — 測試架構師

加油吧，測試人！如果你需要提升規(guī)劃，那就行動吧，在路上總比在起點觀望的要好。事必有法，然后有成。

覺得資源不錯就點個贊吧~