1 軟性熱身題
這種題目，考的就是你的軟性能力，比如表達(dá)能力，理解能力，協(xié)調(diào)能力，一個詞概括就是套路。這類題目會在面試開始熱身的時候，問一道兩題，不會多，但是如果你能回答的有條不紊，清晰達(dá)意，那么就會給面試官留下非常好的印象，大致的題目如下：
自我介紹
我叫XXX，畢業(yè)于XXX，從事測試行業(yè)已經(jīng)XX年，我擅長接口測試自動化，測試框架，巴拉巴拉，我共服務(wù)過X個公司分別有Y個成就，江湖人稱666.總之，盡量用
簡介的語言突出自己的優(yōu)點(diǎn)，要保持humble，就像我介紹的這樣，嗯：）
介紹下你負(fù)責(zé)的公司項目
我主導(dǎo)了XXX，協(xié)助了YYY，參與了ZZZ。 這個回答你要記清楚，后續(xù)的面試肯定還有項目細(xì)節(jié)，甚至技術(shù)實(shí)現(xiàn)細(xì)節(jié)。同類的項目說一個足以，重點(diǎn)突出不同技術(shù)?；蛘哂泄芾?，對外溝通的項目
你有什么優(yōu)點(diǎn)和缺點(diǎn)？
實(shí)際情況作答，比如優(yōu)點(diǎn)是長的好看，缺點(diǎn)是太好看之類的，總之，要謙虛，不要傲。
在同一個項目組內(nèi)，你認(rèn)為你怎么做會比另外一名測試更加優(yōu)秀？
我個人認(rèn)為這個題目很有迷惑性，如果你只追求比別人優(yōu)秀，肯定很難跟別人合作，如果你沒有別人優(yōu)秀，那么我為什么要用你？
要我答的話，我重點(diǎn)會放在如何一點(diǎn)一滴積累技術(shù)實(shí)力，及用這些實(shí)力解決項目組存在的問題上，這實(shí)際上也是很多優(yōu)秀測試人員的必備素質(zhì)
你為什么離開上家公司？離職原因（這個會在最后問）
看老板不爽啊，PM太SB啦喜歡的同事跟開發(fā)跑啦等等， 一個都不要說！?。?我要面試別人，關(guān)注的是離職背后的動機(jī)，這人是不是被開除的，這人是不是不好相處，這人是不是有明顯性格缺陷，只要不沾這些必死項，其它實(shí)際作答吧。
個人覺得軟性題，不必要過多關(guān)注，除自我介紹外，通常是通過面試后HR關(guān)的閑聊題，主要還是要關(guān)注下面的技術(shù)問題。
2 測試?yán)碚摶A(chǔ)題
這類題目就是考測試工程師的基本能力了，比如測試計劃，測試流程，如何bug，你做過哪些測試，一般我們認(rèn)為這些能力做的再好都是應(yīng)該的，不會有加分，但是只要做的不好，那就是個不合格的測試工程師了。這種題目也不會問的太多，大概題目如下：
請描述下你上個公司的測試流程？
實(shí)際情況作答， Scrum模式舉例如下：
1.我們公司采用Scrum模式開發(fā)，測試也跟這個走，在每個sprint開始前會前后召開grooming meeting， planning meeting， Grooming meeting上把這個sprint可能做的tasks從product backlog里撈出來， 然后按照優(yōu)先級排序， planning meeting上估時，做commitments，并確認(rèn)每個story的后端，前端，測試。
2.planning后sprint正式開始時，需求，design，UI應(yīng)該都ready了，測試就可以設(shè)計用例， 通過review后發(fā)給所有組成員review。 story ready for test時，開發(fā)把代碼放到測試環(huán)境，測試開始測試，發(fā)現(xiàn)問題jira報bug，linked到story，測試全部完成后標(biāo)記 UAT GL， 等公司release process開始。
3.Release process開始，不同小組把各自代碼放到統(tǒng)一測試環(huán)境，繼續(xù)測試一次，這輪關(guān)注別組不會影響自己。
4.然后還有一輪甚至兩輪 pre release，主要驗(yàn)證代碼，環(huán)境，變量等問題。
5.最后release， 觀察下，有問題回退版本，沒問題繼續(xù)走下個sprint
請描述下bug的幾個要素？
ID， Summary， reproduce steps， Priority， Assign to， Sprint info， fix version（due data）等等。這道題我好想回答一句，jira里都有，你自己不會看呀：）
白盒和黑盒的區(qū)別，你是怎么運(yùn)用的？
簡單來說一個關(guān)注內(nèi)部實(shí)現(xiàn)邏輯，一個只從用戶角度出發(fā)，不關(guān)注具體實(shí)現(xiàn)。具體定義及區(qū)別請參考我以往文章。
一般中高級測試都會偏灰盒一些，既關(guān)注內(nèi)部實(shí)現(xiàn)邏輯又關(guān)注用戶jounery，設(shè)計case的時候兩邊參考。
內(nèi)部實(shí)現(xiàn)邏輯可以看代碼，也可以請開發(fā)講給你聽，知道了怎么實(shí)現(xiàn)，能在設(shè)計用例時構(gòu)造不同數(shù)據(jù)cover邏輯覆蓋。同時也清楚了regression 的scope
你是如何做測試分析？
這題是考察測試思維，一個應(yīng)用/功能如何測試的問題，我的原則是確定需求，先定性后定量。
具體來說，定性， 哪些是顯性需求？那些是隱性需求？功能在scope嗎？性能？可靠性？安全性？兼容mobile平臺嗎？
定量就是， 功能要測， 那么有哪些功能，每個功能點(diǎn)是什么， 入口是什么，出口是什么，precondition是什么，數(shù)據(jù)哪里構(gòu)造等等。
重復(fù)上述操作直到分析完成
如何設(shè)計測試用例？什么樣子的測試用例是好用例？
個人覺得上題回答好了，這題不會問了。 設(shè)計用例原則上好的用例各有千秋（不外乎邊界值，等價類，流程圖，正交法，判定表等）， 但壞的實(shí)踐要避免，具體如下：
1.一個測試用例驗(yàn)證多個功能點(diǎn)（A,B,C三個功能一個用例，那么用例失敗了，到底是A引起的？還是B引起的?增加后續(xù)開發(fā)定位問題的難度，浪費(fèi)時間）
2.期望結(jié)果不明確（例如： make sure every thing works fine. what the f×××？?。?/p>
3.不可執(zhí)行（比如一個配置項組合， 手工要執(zhí)行的case寫了2000個， 怎么執(zhí)行完？）
4.precondition，steps描述不清楚，上手困難（你負(fù)責(zé)的story可能要由其它測試人員交叉執(zhí)行）。
5.不必要的外部依賴（用例應(yīng)直指功能核心，無關(guān)的入口/步驟/依賴 不必要一股腦放進(jìn)來）
功能測試在 beta 版本對外的上線標(biāo)準(zhǔn)是什么？
貌似業(yè)界對beta的定義不太統(tǒng)一，有人說這個是A/B測試的一種， 但一般認(rèn)為專業(yè)測試人員完成后，有部分用戶參與的一輪測試即beta測試。一般測試環(huán)境為用戶實(shí)際應(yīng)用環(huán)境，目標(biāo)在于要求用戶使用發(fā)現(xiàn)不合理，不符合實(shí)際情況的問題，然后改進(jìn)。
功能上線標(biāo)準(zhǔn)每個公司不一樣，大致如下：
1.所有功能點(diǎn)(需求)都被用例覆蓋到了
2.所有用例執(zhí)行過至少一遍
3.所有發(fā)現(xiàn)的bug被修復(fù)并驗(yàn)證，做過regression了。
4.不能修復(fù)的記錄了/關(guān)閉了/known issue了。
5.bug曲線區(qū)域平穩(wěn)了
本人認(rèn)為此類問題屬于淘汰題，一個問題回答不上來或者深度不夠，直接閑聊然后結(jié)束面試。
3 測試管理題
這類題目就是考驗(yàn)?zāi)阕鳛闇y試leader或者測試負(fù)責(zé)人的管理能力了。
如果項目周期很短，測試人力匱乏，你是怎么協(xié)調(diào)的？
范圍不變，趕工/增加人手，快速跟進(jìn)/并行開始任務(wù)。 范圍能變，砍低優(yōu)先級用例，縮小測試范圍。
描述下你團(tuán)隊的測試分工
實(shí)話實(shí)說， 比如：
干活是不可能干活的，這輩子都不可能干活的， 做管理又不會做，就是顏值這種東西，才能維持得了團(tuán)隊這樣子。
對于團(tuán)隊成員，你是如何打kpi的？
沒錢沒顏你速去，童顏巨 你快來這樣子。
我一般看三點(diǎn)：
1.出活
2.持續(xù)出活
3.持續(xù)精彩的出活
4移動測試相關(guān)
如今是移動互聯(lián)網(wǎng)的天下，誰家沒有個應(yīng)用，所以這一塊基本都會問到，同時也會看你的簡歷，如果你沒有做過，基本也不會問的太深，如果你是專門做這一塊的，那么要好好準(zhǔn)備了。
概念題
描述下web測試和移動應(yīng)用測試的相同點(diǎn)和區(qū)別？
公眾號以前分享過，不贅述，把握以下幾點(diǎn)：
0.任何類型測試先定性，再定量， 范圍， 分類一定，大差不差。
1.web通常不要安裝，移動應(yīng)用通常要安裝。
2.移動設(shè)備存在特殊性，不同設(shè)備的屏幕/分辨率，系統(tǒng)，定制UI都不相同。
3.移動應(yīng)用不應(yīng)該影響移動設(shè)備現(xiàn)有功能，如電話/短信等。
4.移動端要重點(diǎn)關(guān)注，發(fā)熱（電量消耗）， crash， 流量(4G/WIFI/2G)等
你是如何做應(yīng)用的兼容性測試的？
一般兼容性主要關(guān)注：
1.硬件的適配：不同手機(jī)廠商、硬件性能，不同屏幕大小的適配
2.OS版本的兼容。 iOS，Android， 手機(jī)，pad， 版本號啊，MUI定制啊等
3.不同分辨率屏幕的適配
解決辦法（云測，此處欠我廣告費(fèi)），除公司自備主流設(shè)備外，需參考：
1.各大廠商發(fā)布的季度/年度手機(jī)出貨量，盡量覆蓋出貨量大的，熱門的機(jī)型
2.應(yīng)用做tracking，記錄自己用戶常用機(jī)型
3.購買各種云測服務(wù)，解決機(jī)型適配問題
請講出客戶端下 3 個常用的性能指標(biāo)的名稱與具體含義？
基本的：
1.CPU利用率
2.內(nèi)存使用率
3.平均用戶響應(yīng)時間
獨(dú)有的：
1.電量
2.流量
3.首次打開速度
4.競品相應(yīng)項目質(zhì)量比較
iOS應(yīng)用和Android應(yīng)用測試有什么側(cè)重點(diǎn)？
主要是iOS系統(tǒng)和Android系統(tǒng)的本質(zhì)造成的：
1.Android運(yùn)行基于虛擬機(jī)，iOS則是沙盒機(jī)制
2.iOS是偽后臺，任何第三方程序都不能在后臺運(yùn)行；而Android是真后臺，安卓中任何程序都能在后臺運(yùn)行，直到內(nèi)存不夠才關(guān)閉
3.IOS中用于UI指令權(quán)限最高，安卓中數(shù)據(jù)處理指令權(quán)限最高。
測試實(shí)際應(yīng)用上來，個人覺得沒有本質(zhì)區(qū)別，要注意以下問題：
1.安全性。 因?yàn)锳ndroid2的本質(zhì)，任何程序都就可以輕松訪問其他程序文件，要關(guān)注下有沒有偷偷訪問不需要功能/偷流量/常時間運(yùn)行占用內(nèi)存消耗電量等問題。
2.Android開源，定制版本過多（比如小米系列MIUI）， 要關(guān)注定制引起的問題。
請講訴移動應(yīng)用的灰度是怎么做的？
灰度發(fā)布作為A/B Test的一種，一般指發(fā)布新功能到部分用戶，收集反饋/改進(jìn)，進(jìn)而發(fā)布到全步用戶的一種策略。
個人經(jīng)歷過以下方面：
1.新服務(wù)發(fā)布到全部服務(wù)器，但通過配置項把不同特征用戶的請求打到不同的后端服務(wù)上去。比如ip是中國的用戶訪點(diǎn)擊某個按鈕，調(diào)用的是后端。。。/vi這個API， 而國外ip調(diào)用。。/V2
2.新功能的后端服務(wù)只發(fā)布到部分服務(wù)器，只有訪問到這個服務(wù)器的用戶才能用新功能。
3.同一個用戶訪問的平臺不同，請求的服務(wù)就不同，比如app的訪問V1， web的訪問V2，可以通過發(fā)布app版本來實(shí)現(xiàn)。
另外這個實(shí)現(xiàn)還有很多專業(yè)的AB測試平臺可以實(shí)現(xiàn)， 例如（云測，此處欠我廣告費(fèi)）。
如果涉及到寫DB操作， 一般都雙寫。即訪問新服務(wù)時，寫到新服務(wù)的DB數(shù)據(jù)也要寫到老服務(wù)的DB。甚至全部切換至新服務(wù)后再并行運(yùn)行一段時間，才徹底切換到新服務(wù)，停寫老服務(wù)。
實(shí)踐題
應(yīng)用的閃退通常是什么原因造成的？如果應(yīng)用閃退，Android 和 iOS 上是分別怎么抓取日志的？
一般閃退原因如下：
1.內(nèi)存超載
2.后端服務(wù)或動態(tài)鏈接庫未找到
3.應(yīng)用初始化時無法正確讀取到用戶數(shù)據(jù)。
4.系統(tǒng)兼容問題。
日志抓取的話，iOS：
1.通過iTunes Connect（Manage Your Applications - View Details - Crash Reports）獲取用戶的crash日志
2.通過Xcode從你的設(shè)備上獲得崩潰日志
3.自己在程序中添加崩潰捕捉代碼，如果應(yīng)用集成第三方SDK，如百度統(tǒng)計
Android：
1.通過集成第三方SDK，如百度統(tǒng)計、友盟統(tǒng)計等
2、發(fā)版時使用加固工具，他們也會收集錯誤日志，如360加固
3、在程序中添加程序異常崩潰的捕捉代碼，保存到本地文件中
請簡述移動應(yīng)用在升級安裝時候應(yīng)該考慮的場景？
實(shí)際上跟CS架構(gòu)的升級沒什么兩樣：
1.APP有新版本時，打開APP是否有更新提示。
2.當(dāng)版本為非強(qiáng)制升級版時，用戶可以取消更新，老版本能正常使用。用戶在下次啟動app時，仍能出現(xiàn)更新提示。
3.當(dāng)版本為強(qiáng)制升級版時，當(dāng)給出強(qiáng)制更新后用戶沒有做更新時，退出APP。下次啟動app時，仍出現(xiàn)強(qiáng)制升級提示。
4.不刪除APP直接更新，檢查是否能正常更新，更新后能否正常工作。
5.刪除老的APP，重新下載APP，能不能正常工作。
6.不刪除APP直接更新，檢查更新后的APP和新安裝的APP提供的功能一樣。
7.檢查在線跨版本升級能否成功，版本過老是否提示用戶重裝。
8.更新成功后，用戶數(shù)據(jù)有沒有丟失，各個配置項是否還原。
給你一個應(yīng)用，請簡述你會從哪些方面去測試？
一般答分類， 分類如下： 安裝/卸載測試， UI， 功能， 性能， 安全， 兼容， 易用， 可移植性。切忌東答一下，西答一下。
請描述下微信朋友圈發(fā)小視頻的用例設(shè)計？
先假設(shè)一個需求，征得面試官同意，在這個既定需求下說你的用例，還是那個思想，定性，定量分類， 不展開了，測試用例設(shè)計算基本功吧，考察的無非是功能的全面性，邊界/異常條件下的處理， 性能/安全。 主要是有測試思維/結(jié)構(gòu)化思維，設(shè)計的用例要系統(tǒng)，不能想起那個說那個。
如果讓你來測試掃碼支付，你會考慮哪些場景？
同上，不贅述
如何測試一個應(yīng)用的登錄場景？
同上，不贅述， 吐槽下，這題改成如何測試百度的登錄會更好，BAT齊活了 ：） 實(shí)際上這3道題有一道就好了。
對中高級測試而言，實(shí)踐題也是淘汰題，一項卡殼沒有后續(xù)， 但如果在細(xì)節(jié)上有疏忽，可以網(wǎng)開一面，進(jìn)入下個環(huán)節(jié)
5 服務(wù)端測試相關(guān)
什么都離不開服務(wù)端，所以這是你逃不開的，一般來說服務(wù)端會問接口測試，性能測試，更深一點(diǎn)，埋點(diǎn)監(jiān)控止血也會有。
請問你們公司是如何做接口測試的？
累死我了， 題要做吐了。 接口測試實(shí)際跟一般測試不同就是測試用例的設(shè)計部分。
1.接口規(guī)范拿到。
2.設(shè)計接口測試功能用例（主要從用戶角度出發(fā)看接口能否實(shí)現(xiàn)業(yè)務(wù)需求，用例設(shè)計就是黑盒用例那一套）。
3.各種入?yún)Ⅱ?yàn)證（正常情況，異常情況包括輸入?yún)?shù)個數(shù)不對，類型不對，可選/必選， 還有考慮參數(shù)有互斥或關(guān)聯(lián)的情況）。
4.接口返回值各種驗(yàn)證（符合接口文檔需求）
5.了解接口實(shí)現(xiàn)邏輯，實(shí)現(xiàn)邏輯覆蓋（語句/條件/分支/判定/。。。。。）
6.接口能并發(fā)執(zhí)行嗎?
6.采用工具或者自寫代碼來驗(yàn)證，HTTP接口一般SoapUI， Jmeter， Fiddler， Postman等都能驗(yàn)證，自己寫更好。web service接口一般要寫代碼來調(diào)用。根據(jù)測試用例自動化。
7.發(fā)現(xiàn)問題跟功能測試一樣，該報bug報bug，該跟蹤狀態(tài)跟蹤狀態(tài)
接口測試質(zhì)量評估標(biāo)準(zhǔn)是什么？
接口測試說的接口可以是模塊接口，也可以是集成接口，那么質(zhì)量評估標(biāo)準(zhǔn)也就轉(zhuǎn)換為單元測試?yán)锏慕涌跍y試標(biāo)準(zhǔn)，和集成測試?yán)锏募蓽y試標(biāo)準(zhǔn)。
實(shí)際上這題如果我來回答的話會關(guān)注：
1.接口功能是否正確，接口功能是否實(shí)現(xiàn)了業(yè)務(wù)需求。
2.接口參數(shù)正確性包括實(shí)參形參的個數(shù)/屬性，是否匹配。
3.接口并發(fā)/串行執(zhí)行時接口返回值的正確性。
4.有沒有性能問題（并發(fā)執(zhí)行），有無安全問題（用戶能否直接訪問該接口，需不需要驗(yàn)證）
面試答上面的應(yīng)該夠了， 其實(shí)這里面涉及到單元測試和集成測試評估點(diǎn)，我公眾號以前分享后，在測試基礎(chǔ)知識里， 總結(jié)的更全面，大家可移步查看。
請問你們公司是如何做性能測試的？請講訴性能測試的相關(guān)指標(biāo)？
老規(guī)矩，先確定需求，再定性，定量。
例如：
1.這次測試目的是什么，是壓力測試/負(fù)載測試/疲勞強(qiáng)度測試/BenchMark測試？
2.測試的硬件環(huán)境是什么？軟件是什么？
3.測試工具用什么？
4.有哪些測試指標(biāo)？
5.測試分析調(diào)優(yōu)/測試報告要嗎？
具體來說：
1.拿到測試需求，確定測試軟硬件環(huán)境/測試指標(biāo)， 使用測試工具(Loadrunner, jmeter)錄制或者編寫測試代碼，逐步加壓，直到測試目的達(dá)成。
2.分析測試結(jié)果，編寫測試報告，突出性能指標(biāo)包括成功，失敗情況，并加以分析。
3.調(diào)優(yōu)（一般都是開發(fā)的事）
相關(guān)性能指標(biāo)：
服務(wù)器系統(tǒng)資源方面 CPU占用率，內(nèi)存占用率 磁盤的讀寫指標(biāo)
網(wǎng)絡(luò)的占用情況 基礎(chǔ)吞吐率
事務(wù)處理速度 如平均登錄時間，操作平均響應(yīng)時間等。
壓力測試和負(fù)載測試的區(qū)別
一個（壓力測試）把最后一根稻草仍你身上，一個（負(fù)載測試）就剩最后一根稻草沒仍，或者仍給你指定數(shù)目稻草。
服務(wù)器中一般要監(jiān)控哪些數(shù)據(jù)，如何監(jiān)控的，怎么從監(jiān)控數(shù)據(jù)中發(fā)現(xiàn)問題？
CPU， 內(nèi)存， 網(wǎng)絡(luò)， I/O， 數(shù)據(jù)庫。等等。 一般用工具監(jiān)控，另外Windows上有性能監(jiān)視器。
發(fā)現(xiàn)問題，一般要關(guān)注閾值，比如CPU利用率超過85%，說明server壓力太大了，數(shù)據(jù)量一大DB某條SQL寫入速度變慢了等等等等
假設(shè)系統(tǒng)A調(diào)用系統(tǒng)B，我把B的接口都mock了，進(jìn)行性能測試，這樣有什么好處和壞處？
好處是去掉的依賴，可以在B沒有好之前測試A，并且B的任何改動/錯誤/失效不會影響我測試A
壞處是真實(shí)性能要比測出來的性能差， 性能指標(biāo)不準(zhǔn)確。 因?yàn)镸ock的服務(wù)再真也不能代替真實(shí)服務(wù)
有一天早上打車高峰，滴滴服務(wù)端掛了大概30分鐘，工程師搶修之后，馬上上線，之后又掛了，請問有哪些原因會造成這個情況？
還是考測試思維， 一定記得先確認(rèn)需求，再定性，定量。 一般都要反問， 服務(wù)器是哪個服務(wù)器？后端應(yīng)用服務(wù)器？數(shù)據(jù)服務(wù)器？緩存系統(tǒng)服務(wù)器？中間件服務(wù)器？文件系統(tǒng)服務(wù)器？
然后面試官說個，不說就自己假定一個， 然后第一次掛第二次掛分開說，先問有沒有錯誤碼，日志有嗎，有就看日志，沒有就猜 是應(yīng)用服務(wù)器掛了啊，是不是高峰期頂不住這么大并發(fā)訪問??？是數(shù)據(jù)庫服務(wù)器啊，是不是頻繁讀寫受不了啊，讀寫有分開嗎？同步還是異步啊， 把喇叭里。
第二次掛，可能更多了，是不是代碼弄錯了，改壞了，或者把喇叭里。
總之套路就是性能測試中可能預(yù)見的問題及原因，這個你們google下吧，自己分類總結(jié)下。
性能這部分題，個人認(rèn)為除非你面試性能測試工程師，不然都是可選題，答對85%過關(guān)肯定沒問題，70%也行。關(guān)鍵有個概念，知道性能測試怎么回事，有問題該往哪個方向想就行了。
6 自動化相關(guān)
自動化永遠(yuǎn)是避不開的，反正你入職的崗位要不要用自動化，你必須得會一點(diǎn)，加分項。這一塊包括，自動化一些理念和自動化的工具使用。
理念和概念：
如何看待自動化和手動測試？怎樣的一個比例才是健康的？
見仁見智，一切能提高軟件質(zhì)量的方法都應(yīng)該嘗試。
兵無常形，符合自己項目實(shí)際情況是最好的。當(dāng)然你要面試自動化測試，肯定是一切穩(wěn)定了的功能最好全部自動化掉。 :)
你們公司的自動化投入產(chǎn)出比怎樣？效益怎樣？
實(shí)話實(shí)說，UI自動化測試發(fā)現(xiàn)新bug的效益很低，主要用在回歸測試上，減少測試工作量。接口測試可就不一樣了，可以小步快跑，也可以集團(tuán)作戰(zhàn)。
自動化測試用例的覆蓋率多少？
有個50%了不得了吧， 一般核心業(yè)務(wù)里的最高優(yōu)先級用例100%覆蓋，這些用例也是用來跑冒煙的。 另外的看項目資源了。
完整運(yùn)行一次自動化用例需要多久時間？
Google說它們分鐘級或者秒級別， 為毛我們都是小時級別 ：（
什么是分層自動化？
金字塔結(jié)構(gòu)， 最底層UnitTest，往上接口API/集成起來的service， 最上面UI自動化
你的測試數(shù)據(jù)是怎么準(zhǔn)備的？
當(dāng)然是提前準(zhǔn)備的了：）
寫在腳本里/外部文件（excel， XML）/數(shù)據(jù)庫， 逼格逐級提升
測試腳本的維護(hù)成本是怎么樣的？
兩個原則：
1.不壞就不要修
2.終身追責(zé)，誰污染誰治理
工具使用
WebDriver 相關(guān)
請問你的定位策略是什么？
啊啊啊，已經(jīng)兩個小時了，要抓狂了。
ID， Clas， CSS， XPath， jquery腳本， 總之能不麻煩開發(fā)就不麻煩開發(fā)。
請問如何實(shí)現(xiàn)用例失敗或者異常時候需要截圖？
框架自帶， python+webdriver里是get_screenshot_as_file， 一般寫一個裝飾器，放在要執(zhí)行的類上，try， catch下。
請問如何分布式執(zhí)行webdriver用例？
兩種策略：
1.利用Jenkins等，部署部分代碼到多個機(jī)器上執(zhí)行
2.RemoteWebDriver
如何在腳本中執(zhí)行 JavaScript 代碼？
driver.execute_scripts(‘腳本’)
移動應(yīng)用相關(guān)
Appium 的定位策略有哪些？
使用Appium-Python-Client情況下， 除了以下常規(guī)八種定位方式外：
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() –元素的標(biāo)簽名
driver.find_element_by_partial_link_text() –鏈接元素的部分顯示文字
iOS和Android上還有獨(dú)特的定位方法：
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”)’)
關(guān)于移動端元素的定位的定位，我公眾號testertalk也發(fā)過系列文章，詳細(xì)內(nèi)容請移步。
請簡述Appium的原理
真想跟面試官說，您能幫忙打開官網(wǎng)嗎？Appium對iOS和Anroid的實(shí)現(xiàn)原理不盡相同，并且對同一個平臺不同操作系統(tǒng)版本的實(shí)現(xiàn)原理也不相同。
我傾向大家往簡單了說：
1.Appium是C/S架構(gòu)的，更像是一個proxy，連接其被測移動平臺和測試腳本。
2.appium是基于 webdriver 協(xié)議添加對移動設(shè)備自化api擴(kuò)展而成的。
網(wǎng)上有個很清晰的圖，截圖如下：
實(shí)際上我個人理解，這個題就是想了解，當(dāng)你使用一個工具時，你是否關(guān)心過它的內(nèi)部實(shí)現(xiàn)，也可以過渡到當(dāng)你測試一個應(yīng)用時，你是否關(guān)注它的實(shí)現(xiàn)。
iOS 和 Android 的 UI 自動化的原理是什么？
上面已經(jīng)答了，如下：
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)
當(dāng)定位策略都失敗的時候，你該怎么做？
80%是你元素定位的不對，那么多定位方法，一個不行換另外一個，直接不能定位，先定位父元素，再循環(huán)找子元素。一般來說XPATH都能定位到，無非是可閱讀性不強(qiáng)。真的全部失效，請求開發(fā)幫你改個元素屬性好了。
這題其實(shí)還是”測試sense”問題，擴(kuò)大點(diǎn)變成了怎么解決工作中困難。反正別認(rèn)慫， 最好甭廢話，直接開干。
請問Monkey測試的優(yōu)缺點(diǎn)？
沒接觸過，此題不會
如果使用monkey發(fā)現(xiàn)了一個畢現(xiàn)閃退，請問怎么使用monkey重現(xiàn)它？
同上
Jmeter
你用jmeter做什么測試？
接口，性能。
如果有一個登錄接口需要服務(wù)端返回參數(shù)，再帶著這個參數(shù)去請求才能完成登錄，用jmeter 怎么做？
可以利用Regular Expression Extractor傳參。 具體請參考我公眾號testertalk Jmeter 系列文章。
———- 最后，來點(diǎn)硬題，嚯嚯嚯！ ———-
7 硬 題
所謂硬題就是答案一般都是固定或者標(biāo)準(zhǔn)的，答案也不會模棱兩可，包括：算法，編程，sql，linux
算法：
請寫出冒泡排序
1~9999數(shù)列中數(shù)字3出現(xiàn)的次數(shù)。用遞推方法解出。
本來以為很簡單，寫了一下，2位數(shù)能算出來結(jié)果，3位數(shù)會報遞歸次數(shù)太多， 覺得蹊蹺， 仔細(xì)一查，尼瑪這題大有來歷，我跪的心服口服。經(jīng)過查找資料，解答如下：
1位數(shù)： 0～9
個位數(shù)為3： 3， 共1次。
故0~9之間，3的個數(shù)為1
2位數(shù)： 10～99
個位數(shù)是3: 13, 23, 33 ...93, 共9個。
十位數(shù)是3： 30， 31， ....39. 共10個。
故0~99之間，3的個數(shù)為1+9+10=20個
3位數(shù)： 100～999
個位數(shù)是3：
103， 113， ....193 共10個。
203， 213， ....293 共10個。
。
。
。
903， 913， ....993 共10個。
一共9×10=90次。
十位數(shù)是3：
130， 132 ....139 共10個。
230， 232 ....239 共10個。
。
。
。
930， 931， ....939 共10個。
一共9×10=90次。
百位數(shù)是3： 300， 301， ....399 共100個。
故0~999之間，3的個數(shù)為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位數(shù)： 0～9999
個位數(shù)是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
十位數(shù)是3：
1030，1031，。。。。。。1039， 共10個。
1131～1139，
1231～1239.
。。。
1931～1939， 共有10×10個=100個。我們記為B
還有千位數(shù)是2開頭的，到9開頭的，加起來共有9個（B） 9×10*10=900個。
百位數(shù)是3：
1300， 1301，。。。。1399 共100個。
2300
.。
9300
共10×100=1000個。
千位數(shù)是3： 3000，3001，3999 共 1000次。
故0~9999之間，3的個數(shù)為300+900900900+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
規(guī)律：
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)=10f(n-1) + 10(n-1)
從一個數(shù)組中找出前4個最大的數(shù)，用最優(yōu)解。
這個就是排序問題了吧，我想法先排好序，在取前4個，那么多排序，冒泡啊，選擇啊，快排啊。。這里面快排最快，用大O算法O (n * log n )。
思想：
少于2個元素的數(shù)組不需要排序
找一個元素作為基數(shù)
小于基數(shù)的放一個數(shù)組
大于基數(shù)的放一個數(shù)組
針對小于基數(shù)的數(shù)組做快速排序，暫且叫l(wèi)ow
針對大于基數(shù)的數(shù)組做快速排序, 暫且叫high
最終排序后的 low + 【基數(shù)】+ high，就是排好序的數(shù)組
其實(shí)python里內(nèi)置了很多優(yōu)秀的方法來解決其他語言很繁瑣的問題，比如本題目可以直接：
print(sorted([2,2,1,8,5,7,6])[:4])
（據(jù)說python里sorted實(shí)現(xiàn)也是快排，沒有經(jīng)過求證。）
哈哈，這樣，面試官會不會鄙視我 ：）
我之前也分享過基本的算法，大家可以去我的公眾號testertalk查看。
寫一段程序，刪除字符串a(chǎn)中包含的字符串b，舉例 輸入a = “asdw”,b = “sd” 返回 字符串 “aw”，并且測試這個程序。
[圖片上傳失敗...(image-877087-1551538112728)]
編程：
什么是面向?qū)ο缶幊蹋?/p>
把一切看成對象，三大特性 繼承，封裝，多態(tài)
講下Java多線程的使用
java多線程跟別的語言的多線程有區(qū)別嗎？
多線程一般用來更好的利用CPU資源，解決諸如程序“在一部分上會阻塞”，“在另一部分上需要持續(xù)運(yùn)行”的場合。多線程一般用來更好的利用CPU資源，解決諸如程序“在一部分上會阻塞”，“在另一部分上需要持續(xù)運(yùn)行”的場合。
例如有個程序需要接受多個用戶輸入并向服務(wù)器發(fā)送數(shù)據(jù)，那么如果不用多線程，一旦程序在等待某個用戶輸入時，程序就會阻塞。這段時間其它用戶也不能使用了
有三個線程T1，T2，T3，怎么確保它們按順序執(zhí)行？
在主線程中，每一個線程start（）后立即join（）
Thread 類中的start() 和 run() 方法有什么區(qū)別？
個人理解start（）會啟動線程，然后調(diào)用run（），run（）方法一般要重寫。
網(wǎng)上資料：
調(diào)用start（）后，線程會被放到等待隊列，等待CPU調(diào)度，并不一定要馬上開始執(zhí)行，只是將這個線程置于可動行狀態(tài)。然后通過JVM，線程Thread會調(diào)用run（）方法，執(zhí)行本線程的線程體。先調(diào)用start后調(diào)用run，這么麻煩，為了不直接調(diào)用run？就是為了實(shí)現(xiàn)多線程的優(yōu)點(diǎn)，沒這個start不行。
1.start（）方法來啟動線程，真正實(shí)現(xiàn)了多線程運(yùn)行。這時無需等待run方法體代碼執(zhí)行完畢，可以直接繼續(xù)執(zhí)行下面的代碼；通過調(diào)用Thread類的start()方法來啟動一個線程， 這時此線程是處于就緒狀態(tài)， 并沒有運(yùn)行。 然后通過此Thread類調(diào)用方法run()來完成其運(yùn)行操作的， 這里方法run()稱為線程體，它包含了要執(zhí)行的這個線程的內(nèi)容， Run方法運(yùn)行結(jié)束， 此線程終止。然后CPU再調(diào)度其它線程
2.run（）方法當(dāng)作普通方法的方式調(diào)用。程序還是要順序執(zhí)行，要等待run方法體執(zhí)行完畢后，才可繼續(xù)執(zhí)行下面的代碼； 程序中只有主線程——這一個線程， 其程序執(zhí)行路徑還是只有一條， 這樣就沒有達(dá)到寫線程的目的。
記住：多線程就是分時利用CPU，宏觀上讓所有線程一起執(zhí)行 ，也叫并發(fā)
請寫一個線程安全的單例模型
網(wǎng)上搜下吧，java不太熟
SQL：
說下左連接和右連接
介紹下什么是索引
使用sql生產(chǎn)10萬條數(shù)據(jù)
平常沒接觸過這么大數(shù)據(jù)量，分批次吧，每次插入1w條，應(yīng)該沒什么壓力
給你一張表，根據(jù)要求寫sql，這個題目比較多，自己百度吧。
Linux：
你常用的命令是什么？
ls, mkdir, cat, vi, ps touch
用什么查看log？
watch, tail、cat、tac、head、echo
如何查找一個文件大小超過5M的文件
寫在最后
這68道題目，我花費(fèi)了2個晚上總結(jié)整理，真的收獲蠻大。
從個人角度看，這些面試題很接地氣，很多考題也跟實(shí)際工作密切相關(guān)，大大增加了篩掉水貨的幾率，我也曾用部分相似題來篩選別人。
對于初級測試來說，測試?yán)碚?，測試基礎(chǔ)都應(yīng)該掌握，移動端測試，服務(wù)器端測試，自動化測試，性能測試，也應(yīng)該逐漸接觸起來，不會答沒關(guān)系，但要大致了解，面試官喜歡有追求的人。
對于中高級測試來說，除了硬題及性能測試題，其它題目經(jīng)過充分準(zhǔn)備都不應(yīng)該丟分，回答正確率要在85%以上，另外，回答的深度非常重要，決定了你是年齡資深還是技術(shù)資深。
對于硬題，雖然大部分的測試，甚至測試開發(fā)，工作中用到算法的幾率也不高，但你如果都答對了，還是能讓人眼前一亮的。
對于這部分試題，稍有難度的例如google面試題那個，你有個大致思路也行，對于非?；A(chǔ)的，二分啊，排序啊，還是建議多練練，起碼應(yīng)該做到手寫正確。
現(xiàn)在有能力做好普通測試工作的人太多了，算法也跟學(xué)歷，長相一樣，用人單位不得不拿這些篩選掉很多合適的人，有時候你比別人更優(yōu)秀的能力，也許就來自于你昨天刷了一道面試題。
怎么說呢，面試造火箭，進(jìn)來擰螺絲，接受現(xiàn)實(shí)吧。
我本人其實(shí)是反對面試突擊的，所以我公眾號從沒有發(fā)過面試題。 本文目的也不希望大家背答案就面試（面試從來也沒有標(biāo)準(zhǔn)答案，背了估計也面不上 ：0），而是希望大家通過做這些面試題，發(fā)現(xiàn)自己的不足，從而有針對性的提升自己。
感謝大家的閱讀，能讀到這里的都是真粉絲， 歡迎大家提出更好的意見，謝謝。
