前言

　　在我的上一篇文章中(http://.cnblogs/scios/p/5489933)，里面提到最近半年我面試過數十個測試工程師的應聘者，卻鮮有讓我滿意的。后有讀者留言說不理解為什么會這樣。 我感覺有必要再說些什么，所以有了今天這篇文章。

　　面試場景1

　　依然以小明為例

　　問：“假設你所在的團隊負責研發一款手機計算器程序，你是這款產品的測試負責人，你準備怎么開展工作? ”

　　小明聽我說完后，考慮了些許時間，問到：“是不是要寫測試用例?”

　　旁白：聽到這樣的回答會讓我心涼，因為這個問題我只會對2年以上工作經驗的人提問，所以如果面試者這么回答，說明了這個人起碼理解能力方面有問題。

　　我接著提示：“小明，在答題前，你想一下，作為一個項目的測試負責人，一開始就去設計具體的測試用例，是否太片面了?”

　　聽完我的提示，小明思索了一下，回答道：“我以前工作的時候就是這么做的。”

　　旁白：既然我這樣提示，很顯然就是沒讓你寫測試用例。而這個時候如果再強調以前的做法，是不是在挖坑往里跳呢?

　　眼看提示無效，我換一種方式引導，又問：“那你覺得該怎么設計測試用例呢?”

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

　　我不忍再繼續聽下去，打斷她，問道：“你設想一下，如果用例設計完成了，你準備怎么樣執行這些用例呢?”

　　小明：“就在手機上去執行啊。”

　　我問到：“什么樣的手機?”

　　小明說：“就這樣的手機啊。” 然后晃了晃自己的手機。

　　我說：“是不是拿這部手機就可以了，換一款行不行?”

　　說道這里，小明停頓了一下，若有所思的說：“對啊，你還沒有說我們這個計算器程序應該運行在什么手機上。”

　　我：“現在你是測試負責人啊，你是否應該在設計用例之前，弄清楚這件事啊?”

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

　　我安慰道：“放松，你循著這個思路，重新來制定測試計劃。我以為他會因此開竅，心中竊喜。

　　“我的計劃是，在華為、iPhone、三星、vivo、小米、oppo上執行這些測試用例……”

　　旁白：聽到這樣的回答，差不多可以pass了。

　　我想說的

　　上面這個問題很難嗎?據我所知，這類面試的題目是各大IT企業面試軟件測試工程師的必考題，這類題目可以稱之為測試設計，一般是要求應聘者測試一個大眾化的產品(不局限于軟件產品比如一直筆，一部電梯，一塊表，一臺銀行ATM機等)。題目看起來非常的簡單和直觀，但它能從多個維度全面的考察應聘者作為測試工程師的潛力。正如上面大家看到的真實面試案例，如果應聘者沒有系統了解科學的項目測試理論，就很容易因以前的工作模式陷入思維定勢，無法自拔。

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

　　1.明確測試任務

　　2.分析測試范圍

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

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

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

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

　　我想說，企業招人的目標永遠都是奔著“合適”去的。我這么去面試，自然是因為工作中遇到的實際問題導致我不得不去關注這些。在實際工作中，經常會遇到測試人員接到測試任務以后，什么也不考慮就去測試了，測試完了以后告訴我工作完成了。 然后我問他這次測試任務的范圍是什么?開發為什么要做這些改動?這些改動是開發自己提出來的還是客戶要求的?如果客戶要求的客戶的關注點在哪里?這次改動具體改了什么內容?怎么改的?你覺得這樣的改動合理嗎?改動以前是什么樣子的?...... 這些問題最初的時候我問十個人，九個人都答不上來，還有一個回答的模棱兩可。那么，從一個測試經理的角度，讓我怎么相信這個測試負責人的工作是有效的?怎么讓我相信他的工作覆蓋率是全面的?我無法相信連改動原因、改動內容和改動方法都沒有了解清楚的人，能很清楚的知道測試通過的準則。...... 同理，做測試前先思考是一種習慣，如果這個問題回答不好，我很難相信他在實際工作中會做到我剛說的那些(何況我提問的時候是不斷引導的，這個問題也不會拿去問2年經驗以下的新人)。

　　關于如何跟開發溝通確定測試范圍，可以翻一下這篇博文：http://.cnblogs/scios/p/5624707

　　也許還有人覺得，上面這個案例，提及的知識是一個“知不知道”的范疇。只要有所準備，就能做到從容不迫~

　　我想說的是，我在帶新人的過程中，不斷灌輸這套做事的方法論。他們的確是“知道了”，但是真正用好還花費了很長時間。所以面試的時候也不要過于樂觀，是臨時抱佛腳，還是日常工作中就按照這種方式去工作，作為資深的面試官都能分辨出來。勸君不要抱僥幸心理。

　　也許還有人說，面試時間那么短，面試的時候受限于時間關系想不了那么全。

　　其實，這種情況不也說明面試者的思維不夠敏捷，不是嗎?畢竟面試官做了那么充分的引導。

　　面試場景2

　　問題：假設你是QQ這個產品的測試負責人，你怎么去測試QQ傳文件這個功能?說一下測試點，你可以發揮自己的想象力，不必局限于它現有的功能。

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

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

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

　　也許有人問，這個問題就是考察“測試思維”，實際工作中用不到那么多，或者只要準備一下，也能比較輕松的回答我這個問題。

　　測試人員最重要的素質是什么呢? 的確存在有些人思維發散度很不錯，雖然不會設計用例，但是很會找bug。但是這樣的人可遇不可求的。而且通過面試去發現一個人的思維發散度有多好不太現實，我還是更保守的通過看一個人的思維模式來判斷他是不是我想要的人。 我現在所負責的系統架構比較復雜，涉及到方方面面，測試過程中需要思考的問題，跟上面這個案例差不多。一個人是真的懂，還是臨時抱佛腳，可以通過不斷的深挖來發現。所以， 如果想要在面試時“不露馬腳”，仍需要在工作中就培養這樣的思維模式。

　　最后，國內很多公司存在面試官看“眼緣”決定是否錄用。。。這樣的情況不在本次討論范圍之內。