想進BAT？這些面試題助你一臂之力

1 軟性熱身題

這種題目，考的就是你的軟性能力，好比表達能力，理解能力，協調能力，一個詞歸納就是套路。這類題目會在面試開始熱身的時候，問一道兩題，不會多，可是若是你能回答的有條不紊，清晰達意，那麼就會給面試官留下很是好的印象，大體的題目以下：

自我介紹

我叫XXX，畢業於XXX，從事測試行業已經XX年，我擅長接口測試自動化，測試框架，巴拉巴拉，我共服務過X個公司分別有Y個成就，江湖人稱666.總之，儘可能用

簡介的語言突出本身的優勢，要保持humble，就像我介紹的這樣，嗯：）

介紹下你負責的公司項目

我主導了XXX，協助了YYY，參與了ZZZ。 這個回答你要記清楚，後續的面試確定還有項目細節，甚至技術實現細節。同類的項目說一個足以，重點突出不一樣技術棧或者有管理，對外溝通的項目

你有什麼優勢和缺點？

實際狀況做答，好比優勢是長的好看，缺點是太好看之類的，總之，要謙虛，不要傲。

在同一個項目組內，你認爲你怎麼作會比另一名測試更加優秀？

我我的認爲這個題目頗有迷惑性，若是你只追求比別人優秀，確定很難跟別人合做，若是你沒有別人優秀，那麼我爲何要用你？

要我答的話，我重點會放在如何一點一滴積累技術實力，及用這些實力解決項目組存在的問題上，這實際上也是不少優秀測試人員的必備素質

你爲何離開上家公司？離職緣由（這個會在最後問）

看老闆不爽啊，PM太SB啦喜歡的同事跟開發跑啦等等， 一個都不要說！！！ 我要面試別人，關注的是離職背後的動機，這人是否是被開除的，這人是否是很差相處，這人是否是有明顯性格缺陷，只要不沾這些必死項，其它實際做答吧。

我的以爲軟性題，沒必要要過多關注，除自我介紹外，一般是經過面試後HR關的閒聊題，主要仍是要關注下面的技術問題。

2 測試理論基礎題

這類題目就是考測試工程師的基本能力了，好比測試計劃，測試流程，如何bug，你作過哪些測試，通常咱們認爲這些能力作的再好都是應該的，不會有加分，可是隻要作的很差，那就是個不合格的測試工程師了。這種題目也不會問的太多，大概題目以下：

請描述下你上個公司的測試流程？

實際狀況做答， Scrum模式舉例以下：

1.咱們公司採用Scrum模式開發，測試也跟這個走，在每一個sprint開始前會先後召開grooming meeting， planning meeting， Grooming meeting上把這個sprint可能作的tasks從product backlog裏撈出來， 而後按照優先級排序， planning meeting上估時，作commitments，並確認每一個story的後端，前端，測試。

2.planning後sprint正式開始時，需求，design，UI應該都ready了，測試就能夠設計用例， 經過review後發給全部組成員review。 story ready for test時，開發把代碼放到測試環境，測試開始測試，發現問題jira報bug，linked到story，測試所有完成後標記 UAT GL， 等公司release process開始。

3.Release process開始，不一樣小組把各自代碼放到統一測試環境，繼續測試一次，這輪關注別組不會影響本身。

4.而後還有一輪甚至兩輪 pre release，主要驗證代碼，環境，變量等問題。

5.最後release， 觀察下，有問題回退版本，沒問題繼續走下個sprint

請描述下bug的幾個要素？

ID， Summary， reproduce steps， Priority， Assign to， Sprint info， fix version（due data）等等。這道題我好想回答一句，jira裏都有，你本身不會看呀：）

白盒和黑盒的區別，你是怎麼運用的？

簡單來講一個關注內部實現邏輯，一個只從用戶角度出發，不關注具體實現。具體定義及區別請參考我以往文章。

通常中高級測試都會偏灰盒一些，既關注內部實現邏輯又關注用戶jounery，設計case的時候兩邊參考。

內部實現邏輯能夠看代碼，也能夠請開發講給你聽，知道了怎麼實現，能在設計用例時構造不一樣數據cover邏輯覆蓋。同時也清楚了regression 的scope

你是如何作測試分析？

這題是考察測試思惟，一個應用/功能如何測試的問題，個人原則是肯定需求，先定性後定量。

具體來講，定性， 哪些是顯性需求？那些是隱性需求？功能在scope嗎？性能？可靠性？安全性？兼容mobile平臺嗎？

定量就是， 功能要測， 那麼有哪些功能，每一個功能點是什麼， 入口是什麼，出口是什麼，precondition是什麼，數據哪裏構造等等。

重複上述操做直到分析完成

如何設計測試用例？什麼樣子的測試用例是好用例？

我的以爲上題回答好了，這題不會問了。 設計用例原則上好的用例各有千秋（不外乎邊界值，等價類，流程圖，正交法，斷定表等）， 但壞的實踐要避免，具體以下：

1.一個測試用例驗證多個功能點（A,B,C三個功能一個用例，那麼用例失敗了，究竟是A引發的？仍是B引發的?增長後續開發定位問題的難度，浪費時間）

2.指望結果不明確（例如： make sure every thing works fine. what the f×××？！）

3.不可執行（好比一個配置項組合， 手工要執行的case寫了2000個， 怎麼執行完？）

4.precondition，steps描述不清楚，上手困難（你負責的story可能要由其它測試人員交叉執行）。

5.沒必要要的外部依賴（用例應直指功能核心，無關的入口/步驟/依賴 沒必要要一股腦放進來）

功能測試在 beta 版本對外的上線標準是什麼？

貌似業界對beta的定義不太統一，有人說這個是A/B測試的一種， 但通常認爲專業測試人員完成後，有部分用戶參與的一輪測試即beta測試。通常測試環境爲用戶實際應用環境，目標在於要求用戶使用發現不合理，不符合實際狀況的問題，而後改進。

功能上線標準每一個公司不同，大體以下：

1.全部功能點(需求)都被用例覆蓋到了

2.全部用例執行過至少一遍

3.全部發現的bug被修復並驗證，作過regression了。

4.不能修復的記錄了/關閉了/known issue了。

5.bug曲線區域平穩了

本人認爲此類問題屬於淘汰題，一個問題回答不上來或者深度不夠，直接閒聊而後結束面試。

3 測試管理題

這類題目就是考驗你做爲測試leader或者測試負責人的管理能力了。

若是項目週期很短，測試人力匱乏，你是怎麼協調的？

範圍不變，趕工/增長人手，快速跟進/並行開始任務。 範圍能變，砍低優先級用例，縮小測試範圍。

描述下你團隊的測試分工

實話實說， 好比：

幹活是不可能幹活的，這輩子都不可能幹活的， 作管理又不會作，就是顏值這種東西，才能維持得了團隊這樣子。

對於團隊成員，你是如何打kpi的？

沒錢沒顏你速去，童顏巨 你快來這樣子。

我通常看三點：

1.出活

2.持續出活

3.持續精彩的出活

4移動測試相關

現在是移動互聯網的天下，誰家沒有個應用，因此這一塊基本都會問到，同時也會看你的簡歷，若是你沒有作過，基本也不會問的太深，若是你是專門作這一塊的，那麼要好好準備了。

概念題

描述下web測試和移動應用測試的相同點和區別？

公衆號之前分享過，不贅述，把握如下幾點：

0.任何類型測試先定性，再定量， 範圍， 分類必定，大差不差。

1.web一般不要安裝，移動應用一般要安裝。

2.移動設備存在特殊性，不一樣設備的屏幕/分辨率，系統，定製UI都不相同。

3.移動應用不該該影響移動設備現有功能，如電話/短信等。

4.移動端要重點關注，發熱（電量消耗）， crash， 流量(4G/WIFI/2G)等

你是如何作應用的兼容性測試的？

通常兼容性主要關注：

1.硬件的適配：不一樣手機廠商、硬件性能，不一樣屏幕大小的適配

2.OS版本的兼容。 iOS，Android， 手機，pad， 版本號啊，MUI定製啊等

3.不一樣分辨率屏幕的適配

解決辦法（雲測，此處欠我廣告費），除公司自備主流設備外，需參考：

1.各大廠商發佈的季度/年度手機出貨量，儘可能覆蓋出貨量大的，熱門的機型

2.應用作tracking，記錄本身用戶經常使用機型

3.購買各類雲測服務，解決機型適配問題

請講出客戶端下 3 個經常使用的性能指標的名稱與具體含義？

基本的：

1.CPU利用率

2.內存使用率

3.平均用戶響應時間

獨有的：

1.電量

2.流量

3.首次打開速度

4.競品相應項目質量比較

iOS應用和Android應用測試有什麼側重點？

主要是iOS系統和Android系統的本質形成的：

1.Android運行基於虛擬機，iOS則是沙盒機制

2.iOS是僞後臺，任何第三方程序都不能在後臺運行；而Android是真後臺，安卓中任何程序都能在後臺運行，直到內存不夠才關閉

3.IOS中用於UI指令權限最高，安卓中數據處理指令權限最高。

測試實際應用上來，我的以爲沒有本質區別，要注意如下問題：

1.安全性。 由於Android2的本質，任何程序都就能夠輕鬆訪問其餘程序文件，要關注下有沒有偷偷訪問不須要功能/偷流量/常時間運行佔用內存消耗電量等問題。

2.Android開源，定製版本過多（好比小米系列MIUI）， 要關注定製引發的問題。

請講訴移動應用的灰度是怎麼作的？

灰度發佈做爲A/B Test的一種，通常指發佈新功能到部分用戶，收集反饋/改進，進而發佈到全步用戶的一種策略。

我的經歷過如下方面：

1.新服務發佈到所有服務器，但經過配置項把不一樣特徵用戶的請求打到不一樣的後端服務上去。好比ip是中國的用戶訪點擊某個按鈕，調用的是後端。。。/vi這個API， 而國外ip調用。。/V2

2.新功能的後端服務只發布到部分服務器，只有訪問到這個服務器的用戶才能用新功能。

3.同一個用戶訪問的平臺不一樣，請求的服務就不一樣，好比app的訪問V1， web的訪問V2，能夠經過發佈app版原本實現。

另外這個實現還有不少專業的AB測試平臺能夠實現， 例如（雲測，此處欠我廣告費）。

若是涉及到寫DB操做， 通常都雙寫。即訪問新服務時，寫到新服務的DB數據也要寫到老服務的DB。甚至所有切換至新服務後再並行運行一段時間，才完全切換到新服務，停寫老服務。

實踐題

應用的閃退一般是什麼緣由形成的？若是應用閃退，Android 和 iOS 上是分別怎麼抓取日誌的？

通常閃退緣由以下：

1.內存超載

2.後端服務或動態連接庫未找到

3.應用初始化時沒法正確讀取到用戶數據。

4.系統兼容問題。

日誌抓取的話，iOS：

1.經過iTunes Connect（Manage Your Applications - View Details - Crash Reports）獲取用戶的crash日誌

2.經過Xcode從你的設備上得到崩潰日誌

3.本身在程序中添加崩潰捕捉代碼，若是應用集成第三方SDK，如百度統計

Android：

1.經過集成第三方SDK，如百度統計、友盟統計等

二、發版時使用加固工具，他們也會收集錯誤日誌，如360加固

三、在程序中添加程序異常崩潰的捕捉代碼，保存到本地文件中

請簡述移動應用在升級安裝時候應該考慮的場景？

實際上跟CS架構的升級沒什麼兩樣：

1.APP有新版本時，打開APP是否有更新提示。

2.當版本爲非強制升級版時，用戶能夠取消更新，老版本能正常使用。用戶在下次啓動app時，仍能出現更新提示。

3.當版本爲強制升級版時，當給出強制更新後用戶沒有作更新時，退出APP。下次啓動app時，仍出現強制升級提示。

4.不刪除APP直接更新，檢查是否能正常更新，更新後可否正常工做。

5.刪除老的APP，從新下載APP，能不能正常工做。

6.不刪除APP直接更新，檢查更新後的APP和新安裝的APP提供的功能同樣。

7.檢查在線跨版本升級可否成功，版本過總是否提示用戶重裝。

8.更新成功後，用戶數據有沒有丟失，各個配置項是否還原。

給你一個應用，請簡述你會從哪些方面去測試？

通常答分類， 分類以下： 安裝/卸載測試， UI， 功能， 性能， 安全， 兼容， 易用， 可移植性。切忌東答一下，西答一下。

請描述下微信朋友圈發小視頻的用例設計？

先假設一個需求，徵得面試官贊成，在這個既定需求下說你的用例，仍是那個思想，定性，定量分類， 不展開了，測試用例設計算基本功吧，考察的無非是功能的全面性，邊界/異常條件下的處理， 性能/安全。 主要是有測試思惟/結構化思惟，設計的用例要系統，不能想起那個說那個。

若是讓你來測試掃碼支付，你會考慮哪些場景？

同上，不贅述

如何測試一個應用的登陸場景？

同上，不贅述， 吐槽下，這題改爲如何測試百度的登陸會更好，BAT齊活了 ：） 實際上這3道題有一道就行了。

對中高級測試而言，實踐題也是淘汰題，一項卡殼沒有後續， 但若是在細節上有疏忽，能夠網開一面，進入下個環節

5 服務端測試相關

什麼都離不開服務端，因此這是你逃不開的，通常來講服務端會問接口測試，性能測試，更深一點，埋點監控止血也會有。

請問大家公司是如何作接口測試的？

累死我了， 題要作吐了。 接口測試實際跟通常測試不一樣就是測試用例的設計部分。

1.接口規範拿到。

2.設計接口測試功能用例（主要從用戶角度出發看接口可否實現業務需求，用例設計就是黑盒用例那一套）。

3.各類入參驗證（正常狀況，異常狀況包括輸入參數個數不對，類型不對，可選/必選， 還有考慮參數有互斥或關聯的狀況）。

4.接口返回值各類驗證（符合接口文檔需求）

5.瞭解接口實現邏輯，實現邏輯覆蓋（語句/條件/分支/斷定/。。。。。）

6.接口能併發執行嗎?

6.採用工具或者自寫代碼來驗證，HTTP接口通常SoapUI， Jmeter， Fiddler， Postman等都能驗證，本身寫更好。web service接口通常要寫代碼來調用。根據測試用例自動化。

7.發現問題跟功能測試同樣，該報bug報bug，該跟蹤狀態跟蹤狀態

接口測試質量評估標準是什麼？

接口測試說的接口能夠是模塊接口，也能夠是集成接口，那麼質量評估標準也就轉換爲單元測試裏的接口測試標準，和集成測試裏的集成測試標準。

實際上這題若是我來回答的話會關注：

1.接口功能是否正確，接口功能是否實現了業務需求。

2.接口參數正確性包括實參形參的個數/屬性，是否匹配。

3.接口併發/串行執行時接口返回值的正確性。

4.有沒有性能問題（併發執行），有無安全問題（用戶可否直接訪問該接口，需不須要驗證）

面試答上面的應該夠了， 其實這裏面涉及到單元測試和集成測試評估點，我公衆號之前分享後，在測試基礎知識裏， 總結的更全面，你們可移步查看。

請問大家公司是如何作性能測試的？請講訴性能測試的相關指標？

老規矩，先肯定需求，再定性，定量。

例如：

1.此次測試目的是什麼，是壓力測試/負載測試/疲勞強度測試/BenchMark測試？

2.測試的硬件環境是什麼？軟件是什麼？

3.測試工具用什麼？

4.有哪些測試指標？

5.測試分析調優/測試報告要嗎？

具體來講：

1.拿到測試需求，肯定測試軟硬件環境/測試指標， 使用測試工具(Loadrunner, jmeter)錄製或者編寫測試代碼，逐步加壓，直到測試目的達成。

2.分析測試結果，編寫測試報告，突出性能指標包括成功，失敗狀況，並加以分析。

3.調優（通常都是開發的事）

相關性能指標：

服務器系統資源方面 CPU佔用率，內存佔用率 磁盤的讀寫指標

網絡的佔用狀況 基礎吞吐率

事務處理速度 如平均登陸時間，操做平均響應時間等。

壓力測試和負載測試的區別

一個（壓力測試）把最後一根稻草仍你身上，一個（負載測試）就剩最後一根稻草沒仍，或者仍給你指定數目稻草。

服務器中通常要監控哪些數據，如何監控的，怎麼從監控數據中發現問題？

CPU， 內存， 網絡， I/O， 數據庫。等等。 通常用工具監控，另外Windows上有性能監視器。

發現問題，通常要關注閾值，好比CPU利用率超過85%，說明server壓力太大了，數據量一大DB某條SQL寫入速度變慢了等等等等

假設系統A調用系統B，我把B的接口都mock了，進行性能測試，這樣有什麼好處和壞處？

好處是去掉的依賴，能夠在B沒有好以前測試A，而且B的任何改動/錯誤/失效不會影響我測試A

壞處是真實性能要比測出來的性能差， 性能指標不許確。 由於Mock的服務再真也不能代替真實服務

有一天早上打車高峯，滴滴服務端掛了大概30分鐘，工程師搶修以後，立刻上線，以後又掛了，請問有哪些緣由會形成這個狀況？

仍是考測試思惟， 必定記得先確認需求，再定性，定量。 通常都要反問， 服務器是哪一個服務器？後端應用服務器？數據服務器？緩存系統服務器？中間件服務器？文件系統服務器？

而後面試官說個，不說就本身假定一個， 而後第一次掛第二次掛分開說，先問有沒有錯誤碼，日誌有嗎，有就看日誌，沒有就猜 是應用服務器掛了啊，是否是高峯期頂不住這麼大併發訪問啊？是數據庫服務器啊，是否是頻繁讀寫受不了啊，讀寫有分開嗎？同步仍是異步啊， 把喇叭裏。

第二次掛，可能更多了，是否是代碼弄錯了，改壞了，或者把喇叭裏。

總之套路就是性能測試中可能預見的問題及緣由，這個大家google下吧，本身分類總結下。

性能這部分題，我的認爲除非你面試性能測試工程師，否則都是可選題，答對85%過關確定沒問題，70%也行。關鍵有個概念，知道性能測試怎麼回事，有問題該往哪一個方向想就好了。

6 自動化相關

自動化永遠是避不開的，反正你入職的崗位要不要用自動化，你必須得會一點，加分項。這一塊包括，自動化一些理念和自動化的工具使用。

理念和概念：

如何看待自動化和手動測試？怎樣的一個比例纔是健康的？

見仁見智，一切能提升軟件質量的方法都應該嘗試。

兵無常形，符合本身項目實際狀況是最好的。固然你要面試自動化測試，確定是一切穩定了的功能最好所有自動化掉。 :)

大家公司的自動化投入產出比怎樣？效益怎樣？

實話實說，UI自動化測試發現新bug的效益很低，主要用在迴歸測試上，減小測試工做量。接口測試可就不同了，能夠小步快跑，也能夠集團做戰。

自動化測試用例的覆蓋率多少？

有個50%了不起了吧， 通常核心業務裏的最高優先級用例100%覆蓋，這些用例也是用來跑冒煙的。 另外的看項目資源了。

完整運行一次自動化用例須要多久時間？

Google說它們分鐘級或者秒級別， 爲毛咱們都是小時級別 ：（

什麼是分層自動化？

金字塔結構， 最底層UnitTest，往上接口API/集成起來的service， 最上面UI自動化

你的測試數據是怎麼準備的？

固然是提早準備的了：）

寫在腳本里/外部文件（excel， XML）/數據庫， 逼格逐級提高

測試腳本的維護成本是怎麼樣的？

兩個原則：

1.不壞就不要修

2.終身追責，誰污染誰治理

工具使用

WebDriver 相關

請問你的定位策略是什麼？

啊啊啊，已經兩個小時了，要抓狂了。

ID， Clas， CSS， XPath， jquery腳本， 總之能不麻煩開發就不麻煩開發。

請問如何實現用例失敗或者異常時候須要截圖？

框架自帶， python+webdriver裏是get_screenshot_as_file， 通常寫一個裝飾器，放在要執行的類上，try， catch下。

請問如何分佈式執行webdriver用例？

兩種策略：

1.利用Jenkins等，部署部分代碼到多個機器上執行

2.RemoteWebDriver

如何在腳本中執行 JavaScript 代碼？

driver.execute_scripts(‘腳本’)

移動應用相關

Appium 的定位策略有哪些？

使用Appium-Python-Client狀況下， 除了如下常規八種定位方式外：

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() –連接元素的部分顯示文字

iOS和Android上還有獨特的定位方法：

iOS：

IosUIAutomation –iOS9.3或如下的定位方法

driver.find_element_by_ios_uiautomation(‘.elements()[0]’)

Android：

AndroidUIAutomator， 僅支持 Android 4.2或以上，可支持元素的單個屬性和多個屬性定位。

driver.find_element_by_android_uiautomator(‘new UiSelector().text(「Animation」)’)

關於移動端元素的定位的定位，我公衆號testertalk也發過系列文章，詳細內容請移步。

請簡述Appium的原理

真想跟面試官說，您能幫忙打開官網嗎？Appium對iOS和Anroid的實現原理不盡相同，而且對同一個平臺不一樣操做系統版本的實現原理也不相同。

我傾向你們往簡單了說：

1.Appium是C/S架構的，更像是一個proxy，鏈接其被測移動平臺和測試腳本。

2.appium是基於 webdriver 協議添加對移動設備自化api擴展而成的。

網上有個很清晰的圖，截圖以下：

實際上我我的理解，這個題就是想了解，當你使用一個工具時，你是否關心過它的內部實現，也能夠過渡到當你測試一個應用時，你是否關注它的實現。

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)

當定位策略都失敗的時候，你該怎麼作？

80%是你元素定位的不對，那麼多定位方法，一個不行換另一個，直接不能定位，先定位父元素，再循環找子元素。通常來講XPATH都能定位到，無非是可閱讀性不強。真的所有失效，請求開發幫你改個元素屬性好了。

這題其實仍是」測試sense」問題，擴大點變成了怎麼解決工做中困難。反正別認慫， 最好甭廢話，直接開幹。

請問Monkey測試的優缺點？

沒接觸過，此題不會

若是使用monkey發現了一個畢現閃退，請問怎麼使用monkey重現它？

同上

Jmeter

你用jmeter作什麼測試？

接口，性能。

若是有一個登陸接口須要服務端返回參數，再帶着這個參數去請求才能完成登陸，用jmeter 怎麼作？

能夠利用Regular Expression Extractor傳參。 具體請參考我公衆號testertalk Jmeter 系列文章。

———- 最後，來點硬題，嚯嚯嚯！ ———-

7 硬 題

所謂硬題就是答案通常都是固定或者標準的，答案也不會模棱兩可，包括：算法，編程，sql，linux

算法：

請寫出冒泡排序

1~9999數列中數字3出現的次數。用遞推方法解出。

原本覺得很簡單，寫了一下，2位數能算出來結果，3位數會報遞歸次數太多， 以爲蹊蹺， 仔細一查，尼瑪這題大有來歷，我跪的心服口服。通過查找資料，解答以下：

1位數： 0～9

個位數爲3： 3， 共1次。

故0~9之間，3的個數爲1

2位數： 10～99

個位數是3: 13, 23, 33 ...93, 共9個。

十位數是3： 30， 31， ....39. 共10個。

故0~99之間，3的個數爲1+9+10=20個

3位數： 100～999

個位數是3：

103， 113， ....193 共10個。

203， 213， ....293 共10個。

。

。

。

903， 913， ....993 共10個。

一共9×10=90次。

十位數是3：

130， 132 ....139 共10個。

230， 232 ....239 共10個。

。

。

。

930， 931， ....939 共10個。

一共9×10=90次。

百位數是3： 300， 301， ....399 共100個。

故0~999之間，3的個數爲20+90+90+100=300次

也能夠這樣考慮：

0~999之間：十位個 位共有10個0~99（解釋0～99，100～199，。。。900～999），故有10*20=200次，而百位爲1的有100次，共200+100=300次

300=10*20+100

4位數： 0～9999

個位數是3：

1003，1013，1023， 。。。1093 共10個

1103，1113，1123， 。。。1193 共10個

1203..... 共10個

1903.... 共10個

共9個10，咱們記爲A

還有2003～2903， 3003～3903.。。9003～9903 還有9個同樣的A。

全部一共有10個（A）， 是10×9×10=900

十位數是3：

1030，1031，。。。。。。1039， 共10個。

1131～1139，

1231～1239.

。。。

1931～1939， 共有10×10個=100個。咱們記爲B

還有千位數是2開頭的，到9開頭的，加起來共有9個（B） 9×10*10=900個。

百位數是3：

1300， 1301，。。。。1399 共100個。

2300

.。

9300

共10×100=1000個。

千位數是3： 3000，3001，3999 共 1000次。

故0~9999之間，3的個數爲300+900*900*900+1000=4000

也能夠這樣考慮：

0~9999之間：百位十位 個位共有10個0~999（0～999， 1000～1999， 。。9000～9999），故有10*300=3000次，而千位爲1的有1000次，共3000+1000=4000次

4000=10*300+1000

規律：

0~9：1

0~99：20=10*1+10

0~999：300=10*20+100

0~9999：4000=10*300+1000

0~99999：50000=10*4000+10000

0~999999：600000=10*50000+100000

f（1）=1

f(2)=10*f(1)+10 **1

f(3)=10*f(2)+10 **2

f(4)=10*f(3)+10 **3

..

f(n)=10*f(n-1) + 10*(n-1)

從一個數組中找出前4個最大的數，用最優解。

這個就是排序問題了吧，我想法先排好序，在取前4個，那麼多排序，冒泡啊，選擇啊，快排啊。。這裏面快排最快，用大O算法O (n * log n )。

思想：

少於2個元素的數組不須要排序

找一個元素做爲基數

小於基數的放一個數組

大於基數的放一個數組

針對小於基數的數組作快速排序，暫且叫low

針對大於基數的數組作快速排序, 暫且叫high

最終排序後的 low + 【基數】+ high，就是排好序的數組

其實python裏內置了不少優秀的方法來解決其餘語言很繁瑣的問題，好比本題目能夠直接：

print(sorted([2,2,1,8,5,7,6])[:4])

（聽說python裏sorted實現也是快排，沒有通過求證。）

哈哈，這樣，面試官會不會鄙視我 ：）

我以前也分享過基本的算法，你們能夠去個人公衆號testertalk查看。

寫一段程序，刪除字符串a中包含的字符串b，舉例 輸入a = 「asdw」,b = 「sd」 返回 字符串 「aw」，而且測試這個程序。

編程：

什麼是面向對象編程？

把一切當作對象，三大特性 繼承，封裝，多態

講下Java多線程的使用

java多線程跟別的語言的多線程有區別嗎？

多線程通常用來更好的利用CPU資源，解決諸如程序「在一部分上會阻塞」，「在另外一部分上須要持續運行」的場合。多線程通常用來更好的利用CPU資源，解決諸如程序「在一部分上會阻塞」，「在另外一部分上須要持續運行」的場合。

例若有個程序須要接受多個用戶輸入並向服務器發送數據，那麼若是不用多線程，一旦程序在等待某個用戶輸入時，程序就會阻塞。這段時間其它用戶也不能使用了

有三個線程T1，T2，T3，怎麼確保它們按順序執行？

在主線程中，每個線程start（）後當即join（）

Thread 類中的start() 和 run() 方法有什麼區別？

我的理解start（）會啓動線程，而後調用run（），run（）方法通常要重寫。

網上資料：

調用start（）後，線程會被放到等待隊列，等待CPU調度，並不必定要立刻開始執行，只是將這個線程置於可動行狀態。而後經過JVM，線程Thread會調用run（）方法，執行本線程的線程體。先調用start後調用run，這麼麻煩，爲了避免直接調用run？就是爲了實現多線程的優勢，沒這個start不行。

1.start（）方法來啓動線程，真正實現了多線程運行。這時無需等待run方法體代碼執行完畢，能夠直接繼續執行下面的代碼；經過調用Thread類的start()方法來啓動一個線程， 這時此線程是處於就緒狀態， 並無運行。 而後經過此Thread類調用方法run()來完成其運行操做的， 這裏方法run()稱爲線程體，它包含了要執行的這個線程的內容， Run方法運行結束， 此線程終止。而後CPU再調度其它線程

2.run（）方法看成普通方法的方式調用。程序仍是要順序執行，要等待run方法體執行完畢後，纔可繼續執行下面的代碼； 程序中只有主線程——這一個線程， 其程序執行路徑仍是隻有一條， 這樣就沒有達到寫線程的目的。

記住：多線程就是分時利用CPU，宏觀上讓全部線程一塊兒執行 ，也叫併發

請寫一個線程安全的單例模型

網上搜下吧，java不太熟

SQL：

說下左鏈接和右鏈接

介紹下什麼是索引

使用sql生產10萬條數據

日常沒接觸過這麼大數據量，分批次吧，每次插入1w條，應該沒什麼壓力

給你一張表，根據要求寫sql，這個題目比較多，本身百度吧。

Linux：

你經常使用的命令是什麼？

ls, mkdir, cat, vi, ps touch

用什麼查看log？

watch, tail、cat、tac、head、echo

如何查找一個文件大小超過5M的文件

寫在最後

這68道題目，我花費了2個晚上總結整理，真的收穫蠻大。

從我的角度看，這些面試題很接地氣，不少考題也跟實際工做密切相關，大大增長了篩掉水貨的概率，我也曾用部分類似題來篩選別人。

對於初級測試來講，測試理論，測試基礎都應該掌握，移動端測試，服務器端測試，自動化測試，性能測試，也應該逐漸接觸起來，不會答不要緊，但要大體瞭解，面試官喜歡有追求的人。

對於中高級測試來講，除了硬題及性能測試題，其它題目通過充分準備都不該該丟分，回答正確率要在85%以上，另外，回答的深度很是重要，決定了你是年齡資深仍是技術資深。

對於硬題，雖然大部分的測試，甚至測試開發，工做中用到算法的概率也不高，但你若是都答對了，仍是能讓人眼前一亮的。

對於這部分試題，稍有難度的例如google面試題那個，你有個大體思路也行，對於很是基礎的，二分啊，排序啊，仍是建議多練練，起碼應該作到手寫正確。

如今有能力作好普通測試工做的人太多了，算法也跟學歷，長相同樣，用人單位不得不拿這些篩選掉不少合適的人，有時候你比別人更優秀的能力，也許就來自於你昨天刷了一道面試題。

怎麼說呢，面試造火箭，進來擰螺絲，接受現實吧。