一.軟件熱身題
第一印象，相對比較重要，考察軟能力，比如表達能力，理解能力，協調能力
1.自我介紹
我叫，，，18年畢業於，從事軟件測試兩年，擅長接口測試，熟練使用python，sql，了解java，linux
2.介紹下你負責的公司項目
智能測試系統，把所有的測試用具進行線上管理，產生的數據進行分析處理，把主要的數據呈現出來，以供測試的優化。系統分為13個模塊，我做的部分為治具管理，機台管理，程式管理，備品管理
現公司：互聯網金融業務、銀行核心、理財、保險
3.你有什么優點和缺點？
優勢：分析能力較強，對業務的需求分析比較透徹，業務熟悉度和測試功底比較扎實，執行力、推動力、溝通協作能力比較強
4.在同一個項目組內，你認為你怎么做會比另外一名測試更加優秀？
業務熟悉度更高, 架構理解更深入, 代碼能力要更好, 協調推動能力更強
5.你為什么離開上家公司？離職原因（這個會在最后問）
多經歷一些，多進步一些，離家近一些
二.測試理論基礎
基本能力，會的再多也不過分，不扎實的話就會拉低評價，畢竟大家都會，不會的話不算是一個合格的測試工程師了，不會問太多，但是大眾化的要了解。
1.描述下你上個公司的測試流程？
需求評審
編寫測試用例
評審測試用例
發起case評審，提供准入測試用例給開發
提測后先進行准入測試，不通過打回，通過則進入story測試，集成測試，系統測試，性能測試，穩定性測試，安全測試，（uat：客戶在測試環境驗收），生產驗證，發布
2.請描述下bug的幾個要素？
標題，前提條件、測試環境、操作步驟、預期結果、實際結果、嚴重等級、版本信息，出現概率，必要時附上截圖、視頻、日志等
3.白盒和黑盒的區別，你是怎么運用的？
白盒是從代碼層進行測試，黑盒是對業務層進行測試。 白盒可以從單元測試、代碼review、架構方面入手。
內部實現邏輯可以看代碼，也可以請開發講給你聽，知道了怎么實現，能在設計用例時構造不同數據cover邏輯覆蓋
4.你是如何做測試分析？
確認需求，先定性，再定量
定性：顯性需求，隱性需求，功能，性能安全
定量： 功能要測， 那么有哪些功能，每個功能點是什么， 入口是什么，出口是什么，precondition是什么，數據哪里構造等等
1
2
3
4
如果是分析並制定測試內容，首先會根據需求文檔，了解功能交互和規則，再去和開發討論實現原理，通過交互和原理兩個緯度進行分析，並確定測試內容。
如果是測試問題分析，出現問題后，首先會抓包，看看是后端返回的問題，還是前端代碼或者請求的問題，如果后端涉及多個子系統，可以通過查看日志的方式看看具體是環境問題還是后端哪個子系統的問題。
5.如何設計測試用例？什么樣子的測試用例是好用例？
需求分析，架構理解，覆蓋功能、性能、安全等維度
功能拆解：aa的環境，bb的界面，用了cc的工具，做了dd的操作，達到了ee的效果
計用例原則上好的用例各有千秋（不外乎邊界值，等價類，流程圖，正交法，判定表等
6.功能測試在 beta 版本對外的上線標准是什么？
功能上線標准每個公司不一樣，大致如下：
1.所有功能點(需求)都被用例覆蓋到了
2.所有用例執行過至少一遍
3.所有發現的bug被修復並驗證，做過regression了。
4.不能修復的記錄了/關閉了/known issue了。
5.bug曲線區域平穩了
功能指標：
Bug通過率 >＝95%
嚴重級別bug通過率＝100%
case通過率 >＝95%
p0和p1級別case通過率100%
自動化工具通過率達到標准
接口、安全、兼容、性能、穩定性達到要求
產品驗收通過
三.測試管理題
1.如果項目周期很短，測試人力匱乏，你是怎么協調的？
依據代碼review的結果和影響范圍，對測試內容進行適當的裁剪。
借助自動化工具的支持，提高測試案例的執行效率。
調整組內任務的優先級，進行人力協調，優先投入最緊要的項目。
必要的情況下加班
2.描述下你團隊的測試分工
測試技術組和業務測試組：
測試技術組主要進行工具考研、工具開發和工具維護，為業務測試效率提升和基礎建設做支撐。
業務測試組主要進行具體業務測試和工具的落地使用，具體測試內容覆蓋功能、性能、兼容、穩定性、接口等
3.對於團隊成員，你是如何打kpi的？
一方面制定KPI的時候根據團隊成員的職級和能力進行區分，制定合理且細化明確的指標，指標包含測試質量保證、測試效率提升、自動化事務、培訓分享。
進行KPI考核的時候一方面依據KPI的指標達成度、達成時效打分，另一方面不在 KPI內的創新型事務會作為加分項。
四.移動測試相關
移動端的天下，一般都會問到
概念題：
1.描述下web測試和移動應用測試的相同點和區別？
Web 測試和移動應用測試的共同點在於：都要覆蓋接口、功能、兼容、性能、穩定和安全的測試。
差異點在於：兼容考慮的范圍不一樣，web重在PC系統和瀏覽器。移動重在機型分辨率和系統版本。 另外移動用戶要考慮手機特性相關的影響，網絡、沖突、耗電和流量。
2.你是如何做應用的兼容性測試的？
硬件兼容：機型、分辨率、系統、版本、網絡
軟件兼容：輸入法鍵盤、相機、安全清理工具類
數據兼容：低升高、高降低的用戶信息和數據的兼容，還有跨平台的數據兼容
3.請講出客戶端下 3 個常用的性能指標的名稱與具體含義？
cpu利用率
內存使用率
並發量：多個用戶同時調用單個接口的相應時效
響應時間：用戶從客戶端發出請求，並得到響應，以及展示出來
加載速度：通俗的理解為頁面內容顯示的快慢。
電量：APP的耗電量。
流量：APP所消耗的流量
4.iOS應用和Android應用測試有什么側重點？
android運行基於虛擬機，ios則是沙盒機制
android是真后台，ios是偽后台，所以安卓才會卡
分辨率：iOS 覆蓋的分辨率和系統是有限的。
兼容性：Android 比較碎片化，覆蓋的機型版本比iOS 更多android有各種定制rom，手機型號太多。
權限：安卓還要特別考慮權限，6.0是分水嶺
應用安裝渠道：安卓比較多
5.請講述移動應用的灰度是怎么做的？
內部二維碼下載
白名單用戶方式
國內小市場先上，國外用 Google Play的 β版，默認開放5%
后台控制的方式，開放給一定比例的用戶
實踐題：
1.應用的閃退通常是什么原因造成的？如果應用閃退，Android 和 iOS 上是分別怎么抓取日志的？
內存超載
后端服務或動態鏈接庫未找到
應用初始化時無法正確讀取到用戶數據
系統兼容問題
日志抓取：ios
通過iTunes Connect（Manage Your Applications - View Details - Crash Reports）獲取用戶的crash日志
通過Xcode從你的設備上獲得崩潰日志
自己在程序中添加崩潰捕捉代碼，如果應用集成第三方SDK，如百度統計
Android：
通過集成第三方SDK，如百度統計、友盟統計等
發版時使用加固工具，他們也會收集錯誤日志，如360加固
在程序中添加程序異常崩潰的捕捉代碼，保存到本地文件中
2.請簡述移動應用在升級安裝時候應該考慮的場景？
APP有新版本時，打開APP是否有更新提示。
當版本為非強制升級版時，用戶可以取消更新，老版本能正常使用。用戶在下次啟動app時，仍能出現更新提示。
當版本為強制升級版時，當給出強制更新后用戶沒有做更新時，退出APP。下次啟動app時，仍出現強制升級提示。
不刪除APP直接更新，檢查是否能正常更新，更新后能否正常工作。
刪除老的APP，重新下載APP，能不能正常工作。
不刪除APP直接更新，檢查更新后的APP和新安裝的APP提供的功能一樣。
檢查在線跨版本升級能否成功，版本過老是否提示用戶重裝。
更新成功后，用戶數據有沒有丟失，各個配置項是否還原。
3.給你一個應用，請簡述你會從哪些方面去測試？
UI
頁面布局設計是否和產品原型一一致
頁面文案是否正確
功能
正向功能驗證
單個功能項驗證
交互驗證
接口驗證
性能
服務端的性能
APP客戶端性能
安全
注入攻擊
加密
權限
兼容
app：平台，廠商，系統版本，分辨率
web：瀏覽器，分辨率
關注內容：頁面展示正確，功能正確
易用
功能操作是否簡單
頁面布局是否合理
提示語相關信息是否容易理解
app要點：
網絡
中斷
系統權限
web要點：
鏈接測試
多個瀏覽器同時訪問
4.請描述下微信朋友圈發小視頻的用例設計？
功能：
入口圖標的標識度
進入和退出操作簡易度
取景框大小
拍景和自拍切換
視頻的像素限制
視頻的時長限制
發送的進度提示
性能：
發送的時間
操作是否卡頓
兼容：
不同機型分辨率
不同系統版本
不同網絡情況
不同流量情況
5.如果讓你來測試掃碼支付，你會考慮哪些場景？
卡的類型（一類戶：借記卡、信用卡、各個開戶行）
二類戶：虛擬賬戶如微信里的零錢賬戶、支付寶的余額寶、電子賬戶
二維碼的商戶類型（微信、支付寶、匯宜、銀聯）
支付限額（單筆限額、累計限額、日累計、月累計、支付筆數）
退款（退款入口、退款進度、退款結果）
對賬：資金流動（我方扣款數額正確，對方收款數額正確）數額及時效
支付結果展示、交易明細
支付接口安全性、接口的性能
異常情況（卡異常、余額不足）
連續掃碼支付，每天的掃碼支付次數限制及數額限制
二維碼有效期
有無相機權限
前后置攝像頭
像素低端的手機能否掃碼成功
兼容性（不同手機廠商自帶相機功能實現不一致）
6.如何測試一個應用的登錄場景
性能：響應時間、並發量
安全性：加密傳輸
各種登錄方式優先級
不同設備之間切換登錄方式
登錄的有效時長
服務端測試：
1.請問你們公司是如何做接口測試的？
接口規范拿到
設計接口測試用例
發送的數據格式
返回的數據格式
了解接口實現邏輯，實現邏輯覆蓋
接口能並發執行嗎：采用工具或者自寫代碼來驗證，HTTP接口一般SoapUI， Jmeter， Fiddler， Postman等都能驗證，自己寫更好。web service接口一般要寫代碼來調用。根據測試用例自動化
發現問題跟功能測試一樣，該報bug報bug，該跟蹤狀態跟蹤狀態
2.接口測試質量評估標准是什么？
接口表現與接口文檔的一致性
請求參數：必選和非必選、長度、字符類型、為空、缺失、組合、重復
返回參數：正常和異常
性能，1000以內並發時小於3s
3.請問你們公司是如何做性能測試的？請講訴性能測試的相關指標？
拿到測試需求，確定測試軟硬件環境/測試指標
使用測試工具(Loadrunner, jmeter)錄制或者編寫測試代碼，逐步加壓，直到測試目的達成
調優（一般都是開發的事）
相關指標：
服務器系統資源方面 CPU占用率，內存占用率 磁盤的讀寫指標
網絡的占用情況 基礎吞吐率
事務處理速度 如平均登錄時間，操作平均響應時間等
4.壓力測試和負載測試的區別
一個（壓力測試）把最后一根稻草仍你身上，一個（負載測試）就剩最后一根稻草沒仍，或者仍給你指定數目稻草。
壓力測試是在高負載情況下對系統的穩定性進行測試。是在高負載（大數據量、大量並發用戶等）下的測試，觀察系統在峰值使用情況下的表現，從而發現系統的功能隱患。
負載測試：多用戶，用戶數漸增，持續同時發同一業務請求，產出最大TPS
壓力測試：多用戶，資源使用飽和，持續同時發同一業務請求，產出系統瓶頸或使用極限
5.服務器中一般要監控哪些數據，如何監控的，怎么從監控數據中發現問題？
CPU， 內存， 網絡， I/O， 數據庫。等等。 一般用工具監控，另外Windows上有性能監視器
基礎監控和應用監控。基礎監控包括機器是否死機，cpu，內存，磁盤使用率等
應用監控包括日志監控、端口監控、進程數監控等
發現問題：
一般要關注閾值，比如CPU利用率超過85%，說明server壓力太大了
6.假設系統A調用系統B，我把B的接口都mock了，進行性能測試，這樣有什么好處和壞處？
好處是去掉的依賴，可以在B沒有好之前測試A，並且B的任何改動/錯誤/失效不會影響我測試A
壞處是真實性能要比測出來的性能差， 性能指標不准確。 因為Mock的服務再真也不能代替真實服務
7.有一天早上打車高峰，滴滴服務端掛了大概30分鍾，工程師搶修之后，馬上上線，之后又掛了，請問有哪些原因會造成這個情況？
還是考測試思維， 一定記得先確認需求，再定性，定量。 一般都要反問， 服務器是哪個服務器？后端應用服務器？數據服務器？緩存系統服務器？中間件服務器？文件系統服務器？
不說就自己假定一個， 然后第一次掛第二次掛分開說，先問有沒有錯誤碼，日志有嗎，有就看日志，沒有就猜 是應用服務器掛了啊，是不是高峰期頂不住這么大並發訪問啊？是數據庫服務器啊，是不是頻繁讀寫受不了啊，讀寫有分開嗎？同步還是異步啊
第二次掛，可能更多了，是不是代碼弄錯了，改壞了
服務器內存不夠
服務器超出負載
並發量太大
遇到惡意攻擊
五.自動化相關
加分項，這一塊包括，自動化一些理念和自動化的工具使用
理念和概念：
1.如何看待自動化和手動測試？怎樣的一個比例才是健康的？
項目較成熟時自動化比例可適當提高。開發並維護自動化case成本較高，所以不是自動化比例越高越好。要根據具體的項目及項目所處的階段來定。投入產出比要先評估好。
2.你們公司的自動化投入產出比怎樣？效益怎樣？
自動化和業務測試人力1:5
自動化測試發現新bug的效益很低，主要用在回歸測試上，減少測試工作量。接口測試可就不一樣了，可以小步快跑，也可以集團作戰。
3.自動化測試用例的覆蓋率多少？
拿金融產品的自動化來講，大概覆蓋33%左右
4.完整運行一次自動化用例需要多久時間？
Google說它們分鍾級或者秒級別， 為毛我們都是小時級別
5.什么是分層自動化？
金字塔結構， 最底層UnitTest，往上接口API/集成起來的service， 最上面UI自動化
6.你的測試數據是怎么准備的？
寫在腳本里/外部文件（excel， XML）/數據庫， 逼格逐級提升
7.測試腳本的維護成本是怎么樣的？
不壞就不要修
終身追責，誰污染誰治理
8.工具使用
9.接口自動化時上一次執行的數據如何清理掉？（如開戶或注冊，同一個賬號只能使用一次，如何清洗數據能讓case下次繼續跑？提供新的數據？mock？mock的層級，mock過多的話等同於未做測試）
WebDriver 相關：
1.請問你的定位策略是什么？
ID， Clas， CSS， XPath， jquery腳本， 總之能不麻煩開發就不麻煩開發
2.請問如何實現用例失敗或者異常時候需要截圖？
框架自帶， python+webdriver里是get_screenshot_as_file，
一般寫一個裝飾器，放在要執行的類上，try， catch下
3.請問如何分布式執行webdriver用例？
兩種策略：
1.利用Jenkins等，部署部分代碼到多個機器上執行
2.RemoteWebDriver
4.如何在腳本中執行 JavaScript 代碼？
driver.execute_scripts(‘腳本’)
移動應用相關：
1.Appium 的定位策略有哪些？
driver.find_element_by_id() –元素的 resrouce-id 屬性
driver.find_element_by_AccessibilityId() – content-desc屬性，替代以前的name。
driver.find_element_by_xpath() –比css定位慢
driver.find_element_by_class_name() –元素的 class 屬性
driver.find_element_by_css_selector()
driver.find_element_by_link_text() –鏈接元素的全部顯示文字
driver.find_element_by_tag_name() –元素的標簽名
driver.find_element_by_partial_link_text() –鏈接元素的部分顯示文字
2.請簡述Appium的原理
Appium是C/S架構的，更像是一個proxy，連接其被測移動平台和測試腳本。
appium是基於 webdriver 協議添加對移動設備自化api擴展而成的。
3.iOS 和 Android 的 UI 自動化的原理是什么？
iOS 9.3 and above: Apple’s XCUITest
iOS 9.3 and lower: Apple’s UIAutomation
Android 4.2+: Google’s UiAutomator/UiAutomator2
Android 2.3+: Google’s Instrumentation. (Instrumentation support is provided by bundling a separate project, Selendroid)
4.當定位策略都失敗的時候，你該怎么做？
80%是你元素定位的不對
那么多定位方法，一個不行換另外一個
直接不能定位，先定位父元素，再循環找子元素。
一般來說XPATH都能定位到，無非是可閱讀性不強。
真的全部失效，請求開發幫你改個元素屬性好了。
5.請問Monkey測試的優缺點？
6.如果使用monkey發現了一個畢現閃退，請問怎么使用monkey重現它？
Jmeter
1.你用jmeter做什么測試？
接口，性能。
2.如果有一個登錄接口需要服務端返回參數，再帶着這個參數去請求才能完成登錄，用jmeter 怎么做
可以利用Regular Expression Extractor傳參
作者：冬季戀歌1218
鏈接：https://www.jianshu.com/p/d1791f17d8c6
來源：簡書
原文鏈接：https://blog.csdn.net/dream_back/java/article/details/105041647