前言
王豆豆一直想寫一個有關面試中各類面試題解答系列。
剛好昨天測試群正好討論到這個面試題：如何有效避免漏測？王豆豆覺得應該把此類面試題寫一下，也好給以后面試過程中碰到此類題的面試者一個回答的方向。
首先，分析一下為什么面試官要提出這個面試題。
漏測是軟件測試人員的大忌，也是無比大的鍋懸在測試人員的頭上，讓人不行不緊張。
一旦軟件上線出現問題，基本上都會認定是軟件測試人員漏測了。但這種現象又是完全避免不了的，故漏測是軟件測試人員最為關注的，特別是測試領導。
如何有效避免漏測？
這類問題王豆豆在面試過程沒有遇到十回至少也遇到過九回了，可見這個問題在面試過程中出現的頻率之高。
那在面試過程中遇到我們應該如何回答呢？
答：首先，漏測這種情況不能百分之百地杜絕，所以我們需要使用測試手段或者測試方法來盡量減少漏測現象的出現。
在測試之前：
首先，我們會對需求進行分析，然后再進行需求評審，評審時將產品經理、開發、測試集合在一起開一個評審會議，一起對本次迭代的需求進行講解，通過評審會議之后測試人員一定要將需求吃透，只有需求完全理解到位，測試工作才能順利進行。
理解清楚需求之后，測試人員通過各種用例設計方法編寫測試用例，用例編寫完全后測試小組可以先內部交叉評審后，再聯合產品經理、開發人員進行評審會議，這此評審會議主要是檢查測試用例是否對需求進行了完全覆蓋，此次的評審會議非常重要，這也是避免漏測時最重要的一步。
執行測試之前，測試人員主要要做的就是對需求進行澄清、評審等各種手段來理解需求，掌握需求。
在測試之中：
首先，我們會根據事先已經准備好的測試用例（交叉測試）對軟件進行測試，特別是對測試用例中優先級別高的用例着重進行測試。
注：測試過程中，測試人員不測試自己編寫的測試用例，而測試其他測試人員的用例，達到再次檢驗。
同時在測試過程中，我們會根據測試情況一邊測試一邊修改測試用例，以保證測試用例對軟件的高匹配。
首輪測試后期，我們會進行內部功能模塊交叉測試。
最后我們會進行回歸測試，回歸測試時測試人員也是交叉回歸bug，本輪測試除了回歸bug還需要對上輪測試過程中出現bug頻率高的功能模塊着重測試。
在測試結束后：
測試人員召開總結會議，對出現的bug進行分析和總結。
在面試過程中，可以從這三個方面多維度來回答，並且在回答過程中，最好能結合實際的工作經驗，比如有進行需求評審和未進行需求評審，最終的測試結果對比，這樣就更有說服力。
如果面試官這時還說任務緊沒有時間做這些，那又應該怎么辦？
答：如果任務緊前期的需求分析和評審就更不能省略，如果產品和開發不能集合到一起進行評審，那也要進行測試內部評審。
需求是軟件測試人員最重要的東西，如果需求理解不對，用例設計就不對，那最終的執行結果就會天差地別。
每個測試人員的思維都不一樣，考慮的重點也有所差別，評審和頭腦風暴是最快捷的解決辦法。
如果任務緊，時間不充足，測試用例可以不用寫得很詳細，以前我們針對這種情況就是采用XMIND進行需求點編寫，這樣會省時和省力，編寫完成后測試人員內部評審。
以上都是從技術的實現角度進行分析的，同時這類面試題不能避免面試官還想考察應聘者的抗壓能力，任務緊加班現象基本無法避免。
一個同事說得非常好：
跳出技術層面考慮，有時候面試官其實只是為了考察求職者在面試時的抗壓能力，思考問題的邏輯條理是否清晰。
他要的不一定是技術能力上的實操性答案，而是求職者的工作上的軟素質，看你的臨場應變能力是不是能說服他，至於具體到工作上能不能解決問題，是另外一件事。
所以在回答面試題都需要邏輯條理比較強，王豆豆在面試過程中就喜歡列一二三點去回，這樣說有個好處，可以留時間思考，同時給面試官的感覺是條理很清楚，有時就算說第一點時，第二點還沒想好，等說完第一點時，第二點就自動到嘴邊了。
不管是在面試中喜歡這樣，在實際工作中王豆豆也喜歡這樣分析問題和解決問題。
這也是經常所說的解決問題的思路，在這里舉個簡單的例子，如果連接服務器電腦連接不上，應該怎么解決？
也是通過一二三來解決的：
第一步：先檢查自己的電腦的網絡狀況
第二步：檢查自己電腦的IP和服務器IP是否在同一個網段下
第三步：ping服務器的IP，結果有二，ping得通或者ping不通，一般情況下只要ping得通，連接都沒問題
第四步：ping不通，檢查自己的電腦防火牆是否開啟，如果開啟的，關閉了再ping
第五步…………
這樣依次逐步排出故障，這就是解決問題的思路。
上面提到的“如何有效避免漏測？”的解決辦法在實際工作中也可以使用，這並不只是理論，這完全是來自於實踐，只是在工作中會根據實際項目的情況而調整優先級或者增加新的解決方法。
歡迎關注王豆豆的微信公眾號：資深Tester(zishentester)，了解更多好文，和王豆豆一起成長。