https://www.cnblogs.com/scios/p/6028094.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。但是這樣的人可遇不可求的。而且通過面試去發現一個人的思維發散度有多好不太現實，我還是更保守的通過看一個人的思維模式來判斷他是不是我想要的人。 我現在所負責的系統架構比較複雜，涉及到方方面面，測試過程中需要思考的問題，跟上面這個案例差不多。一個人是真的懂，還是臨時抱佛腳，可以通過不斷的深挖來發現。所以， 如果想要在面試時“不露馬腳”，仍需要在工作中就培養這樣的思維模式。
最後，國內很多公司存在面試官看“眼緣”決定是否錄用。。。這樣的情況不在本次討論範圍之內。