一、
軟性熱身題
這種題目，考的就是你的軟性能力，比如表達能力，理解能力，協調能力，一個詞概括就是套路。這類題目會在面試開始熱身的時候，問一道兩題，不會多，但是如果你能回答的有條不紊，清晰達意，那么就會給面試官留下非常好的印象，大致的題目如下：
-
自我介紹
-
介紹下你負責的公司項目
-
你有什么優點和缺點？
-
在同一個項目組內，你認為你怎么做會比另外一名測試更加優秀？
工作積累經驗和此份工作的契合度；
硬實力：列舉專業技能
軟實力：協作能力、規划能力等
自己對面試崗位的理解和自己未來能給他們帶來什么
你的測試技能能否發掘出更多問題
你的測試技能是否能提高效能
是否會主動推進問題，讓上級領導省心
你是否可以讓程序更容易接受你的觀點
- 你為什么離開上家公司？離職原因（這個會在最后問）
二、
測試理論基礎題
這類題目就是考測試工程師的基本能力了，比如測試計划，測試流程，如何bug，你做過哪些測試，一般我們認為這些能力做的再好都是應該的，不會有加分，但是只要做的不好，那就是個不合格的測試工程師了。這種題目也不會問的太多，大概題目如下：
- 請描述下你上個公司的測試流程？
需求分析討論-確定測試策略-設計測試用例-測試用例評審-beta測試-uat測試-測試報告
- 請描述下bug的幾個要素？
1.沒有實現需求說明書列出的功能
2.出現了需要說明書提到不應出現的事情
3.實現了需求說明書未提到的功能
4.沒有實現說明書中沒有提到但應該實現的功能
5.難於使用，運轉速度很慢，用戶認為沒有達到預期
- 白盒和黑盒的區別，你是怎么運用的？
黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。利用其檢查功能是否符合需求說明書，能夠正常使用，
白盒測試：已知產品的內部工作過程，可以進行測試證明每種內部操作是否符合設計規格要求，所有內部成分是否經過檢查
利用其檢查程序模塊的內部邏輯走向，主要覆蓋程序內的邏輯。
- 你是如何做測試分析？
掌握邊界值分析、等價類划分、錯誤推測等方法來設計測試用例
是一個完備的集合，它能夠覆蓋所有等價類以及各種邊界值；需要從軟件功能需求出發，全面地，無遺漏地識別出測試需求；最好是代碼覆蓋測試也全面的測試
- 如何設計測試用例？什么樣子的測試用例是好用例？
掌握邊界值分析、等價類划分、錯誤推測等方法來設計測試用例
是一個完備的集合，它能夠覆蓋所有等價類以及各種邊界值；需要從軟件功能需求出發，全面地，無遺漏地識別出測試需求；最好是代碼覆蓋測試也全面的測試
- 功能測試在 beta 版本對外的上線標准是什么？
測試用例全部跑完並且bug都已經關閉，然后業務驗收后可以上線
三、
測試管理題
這類題目就是考驗你作為測試leader或者測試負責人的管理能力了。
- 如果項目周期很短，測試人力匱乏，你是怎么協調的？
依據代碼review的結果和影響范圍，對測試內容進行適當的裁剪。
借助自動化工具的支持，提高測試案例的執行效率。
調整組內任務的優先級，進行人力協調，優先投入最緊要的項目。
必要的情況下加班
- 描述下你團隊的測試分工
測試技術組和業務測試組。
測試技術組主要進行工具考研、工具開發和工具維護，為業務測試效率提升和基礎建設做支撐。
業務測試組主要進行具體業務測試和工具的落地使用，具體測試內容覆蓋功能、性能、兼容、穩定性、接口等。
- 對於團隊成員，你是如何打kpi的？
一方面制定KPI的時候根據團隊成員的職級和能力進行區分，制定合理且細化明確的指標，指標包含測試質量保證、測試效率提升、自動化事務、培訓分享。
進行KPI考核的時候一方面依據KPI的指標達成度、達成時效打分，另一方面不在 KPI內的創新型事務會作為加分項。
四、
移動測試相關
如今是移動互聯網的天下，誰家沒有個應用，所以這一塊基本都會問到，同時也會看你的簡歷，如果你沒有做過，基本也不會問的太深，如果你是專門做這一塊的，那么要好好准備了。
概念題
- 描述下web測試和移動應用測試的相同點和區別？
Web 測試和移動應用測試的共同點在於：都要覆蓋接口、功能、兼容、性能、穩定和安全的測試。
差異點在於：兼容考慮的范圍不一樣，web重在PC系統和瀏覽器。
移動重在機型分辨率和系統版本。 另外移動用戶要考慮手機特性相關的影響，網絡、沖突、耗電和流量。
- 你是如何做應用的兼容性測試的？
硬件兼容：機型、分辨率、系統、版本、網絡
軟件兼容：輸入法鍵盤、相機、安全清理工具類
數據兼容：低升高、高降低的用戶信息和數據的兼容，還有跨平台的數據兼容
-
請講出客戶端下 3 個常用的性能指標的名稱與具體含義？
-
iOS應用和Android應用測試有什么側重點？
iOS 覆蓋的分辨率和系統是有限的。
Android 比較碎片化，覆蓋的機型版本比iOS 更多
android有各種定制rom，手機型號太多。
- 請講訴移動應用的灰度是怎么做的？
內部二維碼下載
白名單用戶方式
國內小市場先上，國外用 Google Play的 β版，默認開放5%
后台控制的方式，開放給一定比例的用戶
實踐題
- 應用的閃退通常是什么原因造成的？如果應用閃退，Android 和 iOS 上是分別怎么抓取日志的？
OOM
代碼異常如除以零、未對返回的列表做判空、數組越界、空指針異常及其他運行時異常
- 請簡述移動應用在升級安裝時候應該考慮的場景？
安裝的途徑：
通過手機助手安裝
通過adb命令安裝
通過應用市場安裝
安裝：
卸載安裝
升級安裝
升級后數據的一致性。如舊版本的賬號密碼仍能登錄到新版本，保存在本地的信息能同步到新版本。如手勢密碼。
- 給你一個應用，請簡述你會從哪些方面去測試？
- 如何測試一個應用的登錄場景？
常規登錄賬戶密碼的字符類型校驗、長度校驗、匹配性校驗
性能：響應時間、並發量
安全性：加密傳輸
各種登錄方式優先級
不同設備之間切換登錄方式
登錄的有效時長
- 請描述下微信朋友圈發小視頻的用例設計？ ？
功能：
入口圖標的標識度
進入和退出操作簡易度
取景框大小
拍景和自拍切換
視頻的像素限制
視頻的時長限制
發送的進度提示
性能：
發送的時間
操作是否卡頓
兼容：
不同機型分辨率
不同系統版本
不同網絡情況
不同流量情況
- 如果讓你來測試掃碼支付，你會考慮哪些場景？
卡的類型（一類戶：借記卡、信用卡、各個開戶行）
二類戶：虛擬賬戶如微信里的零錢賬戶、支付寶的余額寶、電子賬戶
二維碼的商戶類型（微信、支付寶、匯宜、銀聯）
支付限額（單筆限額、累計限額、日累計、月累計、支付筆數）
退款（退款入口、退款進度、退款結果）
對賬
資金流動（我方扣款數額正確，對方收款數額正確）數額及時效
支付結果展示、交易明細
支付接口安全性、接口的性能
異常情況（卡異常、余額不足）
連續掃碼支付，每天的掃碼支付次數限制及數額限制
二維碼有效期
有無相機權限
前后置攝像頭
像素低端的手機能否掃碼成功
兼容性（不同手機廠商自帶相機功能實現不一致）
五、
服務端測試相關
什么都離不開服務端，所以這是你逃不開的，一般來說服務端會問接口測試，性能測試，更深一點，埋點監控止血也會有。
- 請問你們公司是如何做接口測試的？
swagger 、 接口自動化腳本
Jemeter
接口測試質量評估標准是什么？
接口表現與接口文檔的一致性
請求參數：必選和非必選、長度、字符類型、為空、缺失、組合、重復
返回數據：正常和異常
性能，1000以內並發時小於3s
請問你們公司是如何做性能測試的？請講訴性能測試的相關指標？
壓力測試和負載測試的區別
壓力測試是在高負載情況下對系統的穩定性進行測試。是在高負載（大數據量、大量並發用戶等）下的測試，觀察系統在峰值使用情況下的表現，從而發現系統的功能隱患。
負載測試：多用戶，用戶數漸增，持續同時發同一業務請求，產出最大TPS
壓力測試：多用戶，資源使用飽和，持續同時發同一業務請求，產出系統瓶頸或使用極限
服務器中一般要監控哪些數據，如何監控的，怎么從監控數據中發現問題？
基礎監控和應用監控。基礎監控包括機器是否死機，cpu，內存，磁盤使用率等
應用監控包括日志監控、端口監控、進程數監控等。
- 接口測試質量評估標准是什么？
接口表現與接口文檔的一致性
請求參數：必選和非必選、長度、字符類型、為空、缺失、組合、重復
返回數據：正常和異常
- 請問你們公司是如何做性能測試的？請講訴性能測試的相關指標？
1.做性能需求分析，挑選了用戶使用最頻繁的功能來做性能測試，比如：登陸，搜索，提交訂單，確定性能指標，比如：事務通過率為100%，90%的事務響應時間不超過5秒，並發用戶為1000人，CPU和內存的使用率為70%以下
2.性能測試計划，明確測試時間(通常在功能穩定后，如第一輪測試后進行)和測試環境和測試工具的選擇
3.編寫性能測試用例
4.搭建性能測試環境，准備好性能測試數據
5.通過性能測試用例，編寫性能測試腳本
6.性能測試腳本進行調優，設置檢查點、參數化、關聯、集合點、事務，調整思考時間，刪除冗余的腳本等
7.設計性能測試場景，使用nmon工具監控服務器，運行測試場景
8.分析性能測試結果，如果有問題（性能瓶頸），收集相關的日志提單給開發修改
9.開發修改好后，回歸性能測試
10.編寫性能測試報告
相關指標：響應時間、並發數、吞吐率、資源利用率、TPS
- 壓力測試和負載測試的區別
負載測試是模擬實際軟件系統所承受的負載條件的系統負荷，
通過不斷加載（如逐漸增加模擬用戶的數量）或其它加載方式來觀察不同負載下系統的響應時間和數據吞吐量、系統占用的資源（如CPU、內存）等，
以檢驗系統的行為和特性，以發現系統可能存在的性能瓶頸、內存泄漏、不能實時同步等問題
壓力測試是在高負載情況下對系統的穩定性進行測試。
是在高負載（大數據量、大量並發用戶等）下的測試，觀察系統在峰值使用情況下的表現，
從而發現系統的功能隱患
負載測試：多用戶，用戶數漸增，持續同時發同一業務請求，產出最大TPS
壓力測試：多用戶，資源使用飽和，持續同時發同一業務請求，產出系統瓶頸或使用極限
- 服務器中一般要監控哪些數據，如何監控的，怎么從監控數據中發現問題？
基礎監控和應用監控。
基礎監控包括機器是否死機，cpu，內存，磁盤使用率等；應用監控包括日志監控、端口監控、進程數監控等。
- 假設系統A調用系統B，我把B的接口都mock了，進行性能測試，這樣有什么好處和壞處？
好處：防止系統B出錯引起測試錯誤；不會因系統B的開發進度影響測試；mock后可以快速返回結果，提高測試效率
壞處：很多情況下無法完全模擬出服務器的所有可能的返回情況，另外，mock掉了關聯方之后，整個環境的連通性可能測試的不到位。
- 有一天早上打車高峰，滴滴服務端掛了大概30分鍾，工程師搶修之后，馬上上線，之后又掛了，請問有哪些原因會造成這個情況？
服務器內存不夠、服務器超出負載、並發量太大、遇到惡意攻擊
六、
自動化相關
自動化永遠是避不開的，反正你入職的崗位要不要用自動化，你必須得會一點，加分項。這一塊包括，自動化一些理念和自動化的工具使用。
理念和概念：
- 如何看待自動化和手動測試？怎樣的一個比例才是健康的？
自動化適合做為回歸測試的主要方式，新上線的功能一般都是用手動測試方式，
一些極端和用戶習慣操作還是手動測試比較方便。盡可能線上穩定的功能模塊都做成自動化，提供效率
- 你們公司的自動化投入產出比怎樣？效益怎樣？
自動化主要作為回歸測試，減少測試時間。UI自動化么有弄，基本找不到bug 。
-
自動化測試用例的覆蓋率多少？
-
完整運行一次自動化用例需要多久時間？
主要跑的是業務流，所以跑一次需要半個小時左右
- 什么是分層自動化？
金字塔結構， 最底層UnitTest，往上接口API/集成起來的service， 最上面UI自動化
- 你的測試數據是怎么准備的？
提前准備好，在代碼里的yaml文件
- 測試腳本的維護成本是怎么樣的？
業務不變的情況下，一般腳本都是不壞不動的
-
工具使用
-
WebDriver 相關
-
請問你的定位策略是什么？
-
請問如何實現用例失敗或者異常時候需要截圖？
-
請問如何分布式執行webdriver用例？
-
如何在腳本中執行 JavaScript 代碼？
-
移動應用相關
-
Appium 的定位策略有哪些？
-
請簡述Appium的原理
-
iOS 和 Android 的 UI 自動化的原理是什么？
-
當定位策略都失敗的時候，你該怎么做？
-
請問Monkey測試的優缺點？
-
如果使用monkey發現了一個畢現閃退，請問怎么使用monkey重現它？
-
Jmeter
-
你用jmeter做什么測試？
-
如果有一個登錄接口需要服務端返回參數，再帶着這個參數去請求才能完成登錄，用jmeter 怎么做？
---------- 最后，來點硬題，嚯嚯嚯！ ----------
七、
硬 題
所謂硬題就是答案一般都是固定或者標准的，答案也不會模棱兩可，包括：算法，編程，sql，linux
算法：
-
請寫出冒泡排序
-
1~9999數列中數字3出現的次數。用遞推方法解出。
-
從一個數組中找出前4個最大的數，用最優解。
-
寫一段程序，刪除字符串a中包含的字符串b，舉例 輸入a = "asdw",b = "sd" 返回 字符串 “aw”，並且測試這個程序。
-
寫一個方法，把字符串轉為數字，比如 str="1234"，變成 int 1234。並且測試這個程序。
編程：
-
什么是面向對象編程？
-
講下Java多線程的使用
-
有三個線程T1，T2，T3，怎么確保它們按順序執行？
-
Thread 類中的start() 和 run() 方法有什么區別？
-
請寫一個線程安全的單例模型
SQL：
-
說下左連接和右連接
-
介紹下什么是索引
-
使用sql生產10萬條數據
-
給你一張表，根據要求寫sql，這個題目比較多，自己百度吧。
Linux：
-
你常用的命令是什么？
-
用什么查看log？
-
如何查找一個文件大小超過5M的文件
-
如何查看進程？
作者：朱徽
鏈接：https://www.jianshu.com/p/efaa8b5d3dd5
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。