如何面試測試工程師？

前言

　　在個人上一篇文章中（http://www.cnblogs.com/scios/p/5489933.html），裏面提到最近半年我面試過數十個測試工程師的應聘者，卻鮮有讓我滿意的。後有讀者留言說不理解爲何會這樣。 我感受有必要再說些什麼，因此有了今天這篇文章。

面試場景1

依然以小明爲例

　　問：「假設你所在的團隊負責研發一款手機計算器程序，你是這款產品的測試負責人，你準備怎麼開展工做？ 」

　　小明聽我說完後，考慮了些許時間，問到：「是否是要寫測試用例？」

　　旁白：聽到這樣的回答會讓我心涼，由於這個問題我只會對2年以上工做經驗的人提問，因此若是面試者這麼回答，說明了這我的起碼理解能力方面有問題。

　　我接着提示：「小明，在答題前，你想一下，做爲一個項目的測試負責人，一開始就去設計具體的測試用例，是否太片面了？」

　　聽完個人提示，小明思索了一下，回答道：「我之前工做的時候就是這麼作的。」

　　旁白：既然我這樣提示，很顯然就是沒讓你寫測試用例。而這個時候若是再強調之前的作法，是否是在挖坑往裏跳呢？

　　眼看提示無效，我換一種方式引導，又問：「那你以爲該怎麼設計測試用例呢？」

　　小明自信地說道：「我要測加減乘除運算，開方運算......」

　　我不忍再繼續聽下去，打斷她，問道：「你設想一下，若是用例設計完成了，你準備怎麼樣執行這些用例呢？」

　　小明：「就在手機上去執行啊。」

　　我問到：「什麼樣的手機？」

　　小明說：「就這樣的手機啊。」 而後晃了晃本身的手機。

　　我說：「是否是拿這部手機就能夠了，換一款行不行？」

　　說道這裏，小明停頓了一下，如有所思的說：「對啊，你尚未說咱們這個計算器程序應該運行在什麼手機上。」

　　我：「如今你是測試負責人啊，你是否應該在設計用例以前，弄清楚這件事啊？」

　　聽到個人話，小明不住的點頭，剛纔的自信開始消失，取而代之的，是眼神中的緊張。

　　我安慰道：「放鬆，你循着這個思路，從新來制定測試計劃。我覺得他會所以開竅，心中竊喜。

　　「個人計劃是，在華爲、iPhone、三星、vivo、小米、oppo上執行這些測試用例……」

　　旁白：聽到這樣的回答，差很少能夠pass了。

 

我想說的

　　上面這個問題很難嗎？據我所知，這類面試的題目是各大IT企業面試軟件測試工程師的必考題，這類題目能夠稱之爲測試設計，通常是要求應聘者測試一個大衆化的產品（不侷限於軟件產品好比一直筆，一部電梯，一塊表，一臺銀行ATM機等）。題目看起來很是的簡單和直觀，但它能從多個維度全面的考察應聘者做爲測試工程師的潛力。正如上面你們看到的真實面試案例，若是應聘者沒有系統瞭解科學的項目測試理論，就很容易因之前的工做模式陷入思惟定勢，沒法自拔。

這類問題怎麼解決/回答？其實方法流程很簡單：

1.明確測試任務

2.分析測試範圍

3.制定測試計劃和測試用例

在上面的案例中，小明在作手機計算器程序的測試設計時，在沒有明確測試任務的狀況下，就盲目的展開測試用例的設計，這樣，會引起諸多問題。

好比，在面試題目中，並無明確產品能夠運行在什麼手機平臺上，對平臺的支持需求不一樣，測試的設計的差別性是很大的，因此，在回答該問題以前，先應該向面試官發問，明確產品支持的手機平臺，以後，纔能有的放矢的開展具體的設計（或者即便不問面試官支持哪些平臺，在回答的時候也要說清楚先跟團隊肯定運行的平臺）。再好比，應該明確產品的研發週期等信息，只有瞭解了項目進度安排等信息，才能制定有效的測試策略，在測試的深度和項目開發時間要求上取得較好的平衡。好比，有的項目是時間驅動的(Date-Driven)，這類項目的特色是預先制定發佈時間，要求到了那天，產品就必定要發佈，對這類項目，咱們在設計測試計劃時，就應該更多的考慮解決和項目發佈相關的質量問題；另外有些項目，多是質量驅動的(Quality-Driven)，這類項目的特色是對發佈時間沒有強行的規定，但要求產品的質量必須達到必定的指標，而且須要在發佈之後，實時監控產品質量，那麼，在測試中，咱們不只要作好項目當下版本的測試工做，還須要考慮構建長期、高效地測試系統和平臺，保障產品質量可以實時度量。另外，明確產品的功能設計、產品的核心競爭力、可用的測試資源等信息，對於接下來作產品測試都是相當重要的。

那麼問題來了，也許有的人會質疑，我招的是測試工程師，不是測試經理，不須要考慮這麼多吧，若是按照我這種要求，怕是一年也找不到一個，何況的確有不少人受公司制約，甚至有人大學剛畢業，確定回答不上來這類問題。

我想說，企業招人的目標永遠都是奔着「合適」去的。我這麼去面試，天然是由於工做中遇到的實際問題致使我不得不去關注這些。在實際工做中，常常會遇到測試人員接到測試任務之後，什麼也不考慮就去測試了，測試完了之後告訴我工做完成了。 而後我問他此次測試任務的範圍是什麼？開發爲何要作這些改動？這些改動是開發本身提出來的仍是客戶要求的？若是客戶要求的客戶的關注點在哪裏？此次改動具體改了什麼內容？怎麼改的？你以爲這樣的改動合理嗎？改動之前是什麼樣子的？......  這些問題最初的時候我問十我的，九我的都答不上來，還有一個回答的模棱兩可。那麼，從一個測試經理的角度，讓我怎麼相信這個測試負責人的工做是有效的？怎麼讓我相信他的工做覆蓋率是全面的？我沒法相信連改動緣由、改動內容和改動方法都沒有了解清楚的人，能很清楚的知道測試經過的準則。...... 同理，作測試前先思考是一種習慣，若是這個問題回答很差，我很難相信他在實際工做中會作到我剛說的那些（況且我提問的時候是不斷引導的，這個問題也不會拿去問2年經驗如下的新人）。

關於如何跟開發溝通肯定測試範圍，能夠翻一下這篇博文：http://www.cnblogs.com/scios/p/5624707.html   

也許還有人以爲，上面這個案例，說起的知識是一個「知不知道」的範疇。只要有所準備，就能作到從容不迫~

我想說的是，我在帶新人的過程當中，不斷灌輸這套作事的方法論。他們的確是「知道了」，可是真正用好還花費了很長時間。因此面試的時候也不要過於樂觀，是臨時抱佛腳，仍是平常工做中就按照這種方式去工做，做爲資深的面試官都能分辨出來。勸君不要抱僥倖心理。

也許還有人說，面試時間那麼短，面試的時候受限於時間關係想不了那麼全。

其實，這種狀況不也說明面試者的思惟不夠敏捷，不是嗎？畢竟面試官作了那麼充分的引導。

 

面試場景2

　　問題：假設你是QQ這個產品的測試負責人，你怎麼去測試QQ傳文件這個功能？說一下測試點，你能夠發揮本身的想象力，沒必要侷限於它現有的功能。

　　這個問題，問過不下五十人，能在面試時回答出超過15個測試點的，坦白說一個沒遇到。

　　多數應聘者都是想到哪說道哪。

　　我更想聽到的答案有兩種，一種是按照傳文件的流程（客戶端A-網絡-服務器-網絡-客戶端B），一種是是按照測試框架回答（好比系統的說明從UI、功能、性能、兼容性、安裝部署、服務器端、網絡、安全。。）。

　　也許有人問，這個問題就是考察「測試思惟」，實際工做中用不到那麼多，或者只要準備一下，也能比較輕鬆的回答我這個問題。

　　測試人員最重要的素質是什麼呢？ 的確存在有些人思惟發散度很不錯，雖然不會設計用例，可是很會找bug。可是這樣的人可遇不可求的。並且經過面試去發現一我的的思惟發散度有多好不太現實，我仍是更保守的經過看一我的的思惟模式來判斷他是否是我想要的人。 我如今所負責的系統架構比較複雜，涉及到方方面面，測試過程當中須要思考的問題，跟上面這個案例差很少。一我的是真的懂，仍是臨時抱佛腳，能夠經過不斷的深挖來發現。因此， 若是想要在面試時「不露馬腳」，仍須要在工做中就培養這樣的思惟模式。

　　最後，國內不少公司存在面試官看「眼緣」決定是否錄用。。。這樣的狀況不在本次討論範圍以內。

　　歡迎關注個人微信公衆號和我的微信，若是以爲個人分享對您有所幫助，歡迎加我微信紅包打賞一下。