01
自我介紹篇
目的
一般公司第一個問題，主要目的通過自我介紹先了解下你為之后的提問找好切入點，面試官抓緊時間看下你的簡歷大概了解下你的背景經(jīng)歷，還有緩和下氣氛打開話題作準(zhǔn)備。
如何去答
簡單介紹下項目，重點在負(fù)責(zé)的工作是什么，在工作中運用了什么技術(shù)，學(xué)習(xí)到了什么，總結(jié)了什么經(jīng)驗。除此以外，還要把你自己學(xué)習(xí)的一些技術(shù)也說進去，哪怕你工作中沒有用到，但只要你會的，都展現(xiàn)出來，當(dāng)然前提是這個東西你確實自己研究過，禁得起拷問的才行。
舉個栗子
面試官好，我叫xxxx，畢業(yè)于xxx大學(xué)xxx專業(yè)，曾先后任職于xxx公司，最近一份工作是xxx工作，負(fù)責(zé)xxxx，有功能測試經(jīng)驗，性能，自動化，接口等，做過web，app，參與過敏捷項目，xxxx，最后很榮幸有這次機會來xx公司面試，也希望有機會能加入。
不要太詳細(xì)解釋你做的具體項目，因為在接下來的時間會給你機會具體介紹，只需要流水賬似的過一遍你的履歷就行，幾個亮點就夠了。
02
測試計劃篇
“5W1H”原則
堅持“5W1H”的原則，明確測試內(nèi)容與過程
測試范圍和內(nèi)容
明確測試的范圍和內(nèi)容（WHAT）
計劃的設(shè)計者必須對整個項目系統(tǒng)的設(shè)計方法、具體功能分布、性能以及安全性的要求等等，有充分的了解。
大致包括以下內(nèi)容：各功能點、性能、安全性、穩(wěn)定性、兼容性、易用性等等，需要列出上述各內(nèi)容的詳細(xì)內(nèi)容及指標(biāo)。
測試目的
明確測試的目的（WHY要說清楚：我們?yōu)槭裁匆M行該項目測試？針對具體的測試項目,到底測試的“度”該如何把握之類的問題。
測試時間
明確測試的開始和結(jié)束日期（WHEN）
測試開始結(jié)束日期，是建立在開發(fā)的開始結(jié)束日期、測試內(nèi)容、人力資源等綜合因素的基礎(chǔ)之上的，這里需要明確到具體的年月日，并隨開發(fā)進度而波動。時間的安排上，最好能預(yù)留一段的緩沖時間，以便與應(yīng)對計劃的變更，也可以讓測試人員有時間完善和補充測試用例。
測試文檔存放位置
明確給出測試文檔存放位置（WHERE）
整個測試過程中的文檔管理的重要性就不必說了，但是，文檔管理的工作也必須有計劃的進行。計劃中需指出明確的文檔存放位置，以達(dá)到較好的文檔管理效果。方便相關(guān)人員的監(jiān)督和看。
測試人
明確測試人員的任務(wù)分配（WHO）
好的任務(wù)分配，可以提高測試的質(zhì)量和效率。 我覺得，只有充分了解你的團隊的整體實力和團隊中每個成員的特點，這樣才能做出合理的分工。這里需要確定測試人員的時間及參與測試的方式，如果需要新招聘人員，還要考慮招聘計劃。另外，由于每個人的思維方式不同，所以每個項目的測試至少安排兩個或兩個以上的測試人員以發(fā)現(xiàn)更多的BUG。
測試方法和工具
明確指出測試的方法和測試工具（HOW）
結(jié)合不同的測試領(lǐng)域，給出具體的測試方法，以供組內(nèi)成員參考并借鑒。列出測試過程中需使用的測試工具，以便，組內(nèi)相關(guān)成員提前準(zhǔn)備環(huán)境及相關(guān)知識，以提高測試的質(zhì)量和效率。 采用評審和更新機制，確保測試計劃滿足實際需求因為軟件項目是一個漸進的過程，中間不可避免地會發(fā)生需求變化，為滿足需求變化，測試計劃也需要及時地進行變更。之所以采取相應(yīng)的評審制度，就是要對測試計劃的完整性、正確性、可行性進行評估，以保證測試的質(zhì)量。
03
測試策略篇
測試策略是測試計劃中的重要組成部分,測試計劃是從宏觀上說明一個項目的測試需求、測試方法、測試人員安排等因素， 而測試策略則是說明實際測試過程中，應(yīng)該怎樣具體實施。因此測試策略一定要描述詳盡并且重點突出。
要制定出好的測試策略，需要了解軟件的結(jié)構(gòu)、功能分布、各模塊對用戶的重要程度等，從而決定測試的重點、優(yōu)先次序。
為了達(dá)到有效的覆蓋，需要考慮用例的設(shè)計方法（詳細(xì)可參見趙宏梅的《測試用例設(shè)計方法》系列）。 回歸測試也需要充分考慮，根據(jù)項目的進度，版本的迭代率，合理安排回歸測試的方式。結(jié)合各相關(guān)影響因素來制定有效的回歸測試策略，
04
測試風(fēng)險評估篇
對于測試過程中可能遇到的風(fēng)險，也要制定出相應(yīng)的應(yīng)對策略。
通常的風(fēng)險可能是：項目計劃的變更、測試資源（測試人員）不能及時到位等等。 對此，我們要制定相應(yīng)的策略。比如：對項目計劃的變更，可以考慮建立良好的溝通渠道，讓測試人員及時了解到相應(yīng)的變更，以做出適當(dāng)?shù)恼{(diào)整；對于資源的風(fēng)險，我們可以考慮建立后備機制，后備人員前期也可參加項目例會、評審等活動，以便出現(xiàn)資源緊缺時及時調(diào)用。
05
測試用例篇
我覺得首先要確定好面試官跟你描述的功能是什么，主要包括哪些方面，確定好范圍，然后再開始設(shè)計；其次一定要自己多總結(jié)一些通用的功能測試框架，背下來，回答時套用在不同的功能上；而且不要只關(guān)注功能方面，接口、性能、兼容、安全等都要考慮全面，下面是具體我被問到的一些問題
1. 測試朋友圈發(fā)送功能
2. 測試微信的發(fā)送功能
3. 測試輸入框功能
4. 測試數(shù)據(jù)加載過程
5. 測試注冊登錄和驗證碼功能
6. 測試視頻播放
7. 測試直播中的送禮物
06
測試流程篇
需求階段-開發(fā)階段-測試階段-上線階段-上線后
需求階段
需求文檔規(guī)范
首先需求文檔要有規(guī)范，這部分測試可以要求如果產(chǎn)品需求文檔不夠完善標(biāo)準(zhǔn)的話，一個好的需求文檔應(yīng)當(dāng)包含如下幾個方面：
版本信息（包含版本履歷，創(chuàng)建人，修改人，日期等）
需求概述包含背景，目的，影響范圍等
流程圖（包含業(yè)務(wù)流程圖，系統(tǒng)操作流程圖）
具體功能模塊詳解
需求評審前
測試負(fù)責(zé)人拆分需求模塊，分配對應(yīng)的模塊負(fù)責(zé)人
模塊負(fù)責(zé)人進行需求了解、分析，整理需求疑問、建議等，若時間允許，提前發(fā)送郵件或口頭與產(chǎn)品進行確認(rèn)，提前發(fā)送郵件或口頭與產(chǎn)品進行確認(rèn)。
需求評審中
測試需要思考的地方不限于以下幾點
了解需求產(chǎn)生的背景，了解產(chǎn)品人員想要達(dá)到的效果以及要解決的核心問題是什么？
一個新功能添加的必要性需要評估。(產(chǎn)品預(yù)期狀態(tài)是否能夠達(dá)到，投入產(chǎn)出比是否合適，評估這個需求是否合理，從用戶體驗角度考慮)
功能模塊是否與其他模塊需求沖突，沖突時是否有相關(guān)處理方式？
涉及到UI方面，文字，顏色，位置，大小，樣式，布局等是否有詳細(xì)說明，效果是否統(tǒng)一
確認(rèn)之前標(biāo)注的地方得到解答
最后測試需要輸出的：
測試模塊拆分負(fù)責(zé)表，對應(yīng)模塊測試負(fù)責(zé)人，測試所需時間
評審會議所需要輸出的；需求評審會議記錄
需求評審后
項目經(jīng)理根據(jù)會議過程整理出會議記錄公示所有相關(guān)參會人員包括相應(yīng)領(lǐng)導(dǎo)。
測試對應(yīng)模塊負(fù)責(zé)人開始用例設(shè)計，準(zhǔn)備測試數(shù)據(jù)，按照日期監(jiān)督各模塊開發(fā)負(fù)責(zé)人，準(zhǔn)時提測
產(chǎn)品及時更新文檔，確保文檔內(nèi)容是會議三方所述一致
會議記錄至少包括以下內(nèi)容：
會議中沒有解決的疑問地方，產(chǎn)品給出的解決方案（有些地方產(chǎn)品也需要會下跟業(yè)務(wù)再次確認(rèn)）
明確對應(yīng)模塊開發(fā)負(fù)責(zé)人，測試負(fù)責(zé)人，開發(fā)測試對應(yīng)所需要的時間等
需求影響的模塊以及所涉及到的風(fēng)險，上線之后應(yīng)對的容災(zāi)方案，回滾計劃等
需求優(yōu)先級排期：
需求變更：
三方確認(rèn)，如果確認(rèn)一致通過同意變更，產(chǎn)品發(fā)出郵件，產(chǎn)品更新文檔，開發(fā)重新修改研發(fā)時間，測試重新調(diào)整計劃，是否需要延期，測試工作量，人力，時間資源等調(diào)配
跨部門，跨組需要多方配合的需求如何展開測試?
避免以下點即可，如何避免以下問題多溝通多交流，拉到一個群組交流，由項目經(jīng)理牽頭組織，如果沒有測試負(fù)責(zé)。
通過文字郵件等方式確認(rèn)每個模塊開發(fā)測試按時完成，最終進行聯(lián)調(diào)測試。
開發(fā)階段
參與開發(fā)詳細(xì)設(shè)計評審，了解功能實現(xiàn)過程
開發(fā)書寫代碼，完畢之后，有兩種方式一種人工方式進行code review，組內(nèi)leader負(fù)責(zé)檢查code。
另一種提交到系統(tǒng)，由系統(tǒng)通知相關(guān)負(fù)責(zé)人檢查或者借助第三方工具如(Checkstyle，F(xiàn)indBugs，PMD，Jtest），如果review通過則允許提交到svn
開發(fā)在開發(fā)環(huán)境自測，書寫自測報告
測試階段
從需求評審階段就開始，一個是分析需求拆分模塊，每個對應(yīng)的模塊負(fù)責(zé)人書寫測試用例（一個根據(jù)開發(fā)詳設(shè)或還有就是需求文檔），進行測試用例評審，當(dāng)開發(fā)提測之后進行code review環(huán)節(jié)（適當(dāng)補充用例），準(zhǔn)備測試數(shù)據(jù)測試環(huán)境調(diào)試，冒煙測試（不接受一句話提測，對于提測信息不明確或者缺少自測報告或者冒煙不通過給予打回），通過之后進行功能，性能，兼容性，異常測試等（如果有接口測試一定是在客戶端沒提測時候，如果涉及到前后端分離測試，那么都是先測試服務(wù)端，然后測試客戶端），提交bug，驗證fix的bug，回歸測試，最后確定沒有問題，發(fā)送驗收郵件，提交上線申請。
上線階段
上線的標(biāo)準(zhǔn)：
本版本所有需求都已經(jīng)實現(xiàn)
本版本所有測試任務(wù)已經(jīng)執(zhí)行完畢
確認(rèn)所有major級別bug都關(guān)閉，個別問題如果不修復(fù)要有明確說明，bug解決率要達(dá)到95%以上，
app穩(wěn)定性評估，包含以下三個方面
自動化評測
（1）隨機瀏覽自動化評測結(jié)果無新增的未知的Crash發(fā)生；
（2）隨機瀏覽自動化評測中所有已知Crash能夠用修復(fù)的均已修復(fù)。
線上灰度崩潰
（1）線上主進程Crash全部修復(fù)；
（2）線上子進程所有已知Crash均已修復(fù)；
（3）線上子進程沒有新增的密集的崩潰。
與上一版本數(shù)據(jù)對比
（1）對上一版本穩(wěn)定性對比，不差于上一版本。
app性能評估
頁面加載性能
（1）Wifi頁面加載速度與上一版本相比，不能下降。
（2）2G3G頁面加載速度與上一版本相比，不能下降。
冷啟動時間評測
（1）冷啟動時間與上一版相比，不能增加。
（2）向競品看齊，與競品的差距情況公示。
主觀性能感知
（1）高端機不能有非?？ǖ那闆r，有點卡的情況也應(yīng)該控制數(shù)量
（2）高中低端機均不能有較線上版明顯的卡頓內(nèi)容
對于上線出現(xiàn)的問題應(yīng)急措施考慮
出現(xiàn)問題，有完善的應(yīng)急預(yù)案，出現(xiàn)問題能夠及時回滾或者馬上修復(fù)
如果上線失敗，事后復(fù)盤總結(jié)出此次的問題，形成郵件形式發(fā)送相關(guān)人員，避免下次再次出錯
上線之后
線上監(jiān)控新功能運行情況
出現(xiàn)異常情況或者問題，需要臨時發(fā)版重新打補丁包
補丁包提測的內(nèi)容一般是：
修復(fù)線上待修復(fù)的功能邏輯Bug
修復(fù)線上待修復(fù)的崩潰
優(yōu)化線上體驗不好的產(chǎn)品需求
補丁包評估方法
通過工具檢測開發(fā)提交的代碼
三方及時溝通，為何修改，影響范圍，測試需要做的
最后確認(rèn)要發(fā)送補丁包，書寫郵件告知相關(guān)負(fù)責(zé)人補丁包內(nèi)容原因影響范圍等
產(chǎn)品功能復(fù)合需求，產(chǎn)品驗收通過，進入code freeze狀態(tài)，開發(fā)打包發(fā)線上環(huán)境（一般公司除了測試環(huán)境還有會有預(yù)發(fā)環(huán)境模擬）
07
實際項目篇
主要涉及到你簡歷所寫的項目，舉幾個例子自動化，你們怎么做的，你負(fù)責(zé)的是哪塊業(yè)務(wù)
主要考察你自動化技術(shù)水平，同時涉及到的一些技術(shù)點會順帶著一起問出來，比如分層自動化，接口自動化。
有沒有使用編程做一些工具或者工具二次開發(fā)等
團隊協(xié)作如何處理問題的，你項目中你遇到困難如何解決的，還有有沒有做的不好的地方如何改進。
項目架構(gòu)相關(guān)的，現(xiàn)在架構(gòu)都是web／app－站點層－服務(wù)層－數(shù)據(jù)層
09
算法篇
1. 排序（冒泡、堆排序、快速排序等）
2. 二分查找
3. 判斷素數(shù)
4. 單鏈表反轉(zhuǎn)
5. 判斷是否為回文數(shù)（aabb格式）
6. 十進制轉(zhuǎn)換成二進制
7. 判斷IP的有效性
8. 合并兩個有序數(shù)組，生成一個有序的大數(shù)組，要求時間復(fù)雜度最低
9. 堆排序
10. 二叉樹排序
11. 圖的最短路徑
當(dāng)然除了上面這些基礎(chǔ)的算法，有的面試官還會臨時給個有規(guī)律的數(shù)據(jù)，讓你寫出一個算法或給出思路，考驗下邏輯思維能力，當(dāng)然如果不會也不要氣餒，有的面試官會給你提供思路引導(dǎo)你。
10
Linux、mysql篇
以下只是一些例子，但是可能還有更多情況
1) 常用命令有哪些，包括日?？磍og一些命令,查看端口命令，哪個端口被占用，關(guān)閉進程，打壓縮包，vim編輯命令，grep，sed，awk屬于高級命令可以簡單看下。
2) 數(shù)據(jù)庫的增刪改查
3) 數(shù)據(jù)庫的關(guān)聯(lián)查詢
4) 數(shù)據(jù)庫建立索引的優(yōu)點，如何搜索數(shù)據(jù)的
11
Java/Python/shell開發(fā)語言篇
這個問題也是被問到的概率很高，主要是看你簡歷中寫了哪些語言，以下問題都是關(guān)于Java/shell/python的
1）./ 和sh 執(zhí)行shell腳本的區(qū)別
2）shell腳本中的第一行的作用是什么
3）怎么用shell腳本取出日志中倒數(shù)第二列的內(nèi)容
4）lamda函數(shù)是什么
5）Python中的內(nèi)存管理
6）字典、列表、元祖的區(qū)別，在內(nèi)存中都是如何存儲的，想要搜索數(shù)據(jù)時，各自的時間復(fù)雜度是多少
7）python怎么安裝包
8）re模塊中的match和search的區(qū)別
10）sokect編程
11）items，iteritems區(qū)別
12）Java中的collection
13）Java中常用的一些類庫
14）Java中怎么開啟線程
12
操作系統(tǒng)篇
一般公司不太會問這么底層的，但是360面試比較喜歡問
1) 進程，線程，協(xié)程概念區(qū)別
2) 進程同步互斥，進程間通信概念
3) 進程調(diào)度算法，死鎖概念
4) 頁面置換算法，makefile概念
5) 虛存，實存，共享內(nèi)存
13
ADB篇
· android四大組件、activity生命周期、ANR、五種布局、Android動畫原理
· adb server重啟，apk的安裝與卸載
· 文件的push、pull，apk的靜默安裝
· app的啟動停止，app包查找
· 截屏、錄屏，logcat，dumpsys meminfo、dumpsys cpuinfo
14
Monkey篇
· monkey命令，monkey場景重現(xiàn)
· 提取crash、ANR信息的方法，填加throttle參數(shù)，忽略crash和ANR
· monkey執(zhí)行指定類型的事件
15
自動化篇
自動化框架包括；數(shù)據(jù)驅(qū)動，關(guān)鍵字驅(qū)動，數(shù)據(jù)＋關(guān)鍵字混合，分布式，行為驅(qū)動（lettuce），具體結(jié)合自己的項目展開。
接口自動化
怎么做的接口自動化，工具有哪些，你自己怎么寫的
模塊接口測試
1) 檢查接口返回的數(shù)據(jù)是否與預(yù)期結(jié)果一致。
2) 檢查接口的容錯性，假如傳遞數(shù)據(jù)的類型錯誤時是否可以處理。例如上面的例子是支持整數(shù)，傳遞的是小數(shù)或字符串呢？
3) 接口參數(shù)的邊界值。例如，傳遞的參數(shù)足夠大或為負(fù)數(shù)時，接口是否可以正常處理。
4) 接口的性能，接口處理數(shù)據(jù)的時間也是測試的一個方法。牽扯到內(nèi)部就是算法與代碼的優(yōu)化。
5) 接口的安全性，如果是外部接口的話，這點尤為重要。
Web接口
web接口測試又可分為兩類：服務(wù)器接口測試和外部接口測試。
服務(wù)器接口測試：是測試瀏覽器與服務(wù)器的接口。這個很容易理解，我們知道web開發(fā)一般分前端和后端，前端開發(fā)人員用html/css/javascript等技術(shù)。后端開發(fā)人用php/java/python/ruby等各種語言。用戶輸入的數(shù)據(jù)是輸入到的前端頁面上，怎樣把這些數(shù)據(jù)傳遞的后臺的呢？通過http協(xié)議的get與post請求來實現(xiàn)前后端的數(shù)據(jù)傳遞。這也可認(rèn)為是接口測試，調(diào)用的登錄接口還是查詢接口，傳參的是用戶密碼還是搜索關(guān)鍵字。
外部接口測試：這個很典型的例子就是第三方登錄，比如你做的新系統(tǒng)免于新用戶重新注冊的麻煩會提供第三方登錄，那用戶在登錄的時候調(diào)用的就是第三方登錄的接口，由第三方驗證用戶名和密碼并且返回給當(dāng)前系統(tǒng)。
對于web接口測試來說有哪些測試要點：
· 1、請求是否正確，默認(rèn)請求成功是200，如果請求錯誤也能返回404、500等。
· 2、檢查返回數(shù)據(jù)的正確性與格式；json是一種非常創(chuàng)建的格式。
· 3、接口的安全性，一般web都不會暴露在網(wǎng)上任意被調(diào)用，需要做一些限制，比如鑒權(quán)或認(rèn)證。
· 4、接口的性能，web接口同樣注重性能，這直接影響用戶的使用體驗。如果我搜索一個關(guān)鍵字半天結(jié)果都沒返回，果斷棄用。
聯(lián)系客服
