如何看待測試過程當中的漏測發生

漏測，相信對於每一個測試同窗而言，都是「談虎變色」的事，可是實際工做中，咱們稍有不謹慎便會和它來一次「親密接觸」，那麼，如今咱們來聊聊測試中的漏測。

漏測將會產生的影響

一方面，會讓他人對你的技術、業務能力產生懷疑，並且發生屢次後，甚至會質疑你存在的價值；

另外一方面，本身心裏會很愧疚和自責，擔憂下次測試任務還會漏測，內心壓力倍增，以致於影響下次測試任務的順利進行；

再者，由於本身漏測而致使的公司損失，我的或團隊都會受到一些處分，輕者警告批評、扣績效，重者可能被迫勸退離職。

因此對於測試同窗而言，漏測真的是讓人特別難受的事。

爲何會產生漏測現象

看到這裏，也許你也和我同樣，必定有不少話要說，甚至大堆的吐槽。其實大可沒必要，下面以我限有的工做經驗，我們客觀的聊下產生漏測的可能緣由：

• 測試的工做在公司不被重視，測試定義的測試標準徹底被無視；
• 環境差別，測試環境沒問題，可是在生產環境就各類問題；
• 沒有明確的需求，老是說改就改；
• 沒有測試流程概念，需求評審階段由於沒作到及時溝通，致使產品經理、開發、測試需求理解不一致；
• 測試徹底沒有上線的話語權，沒有版本概念，說上線就上線，不經過測試直接上線，有遺留問題仍是須要測試背鍋；
• 開發由於本身開發時間不夠，壓縮測試時間；
• 一句話需求，沒有明確的需求文檔和原型圖，開發未理解透徹，直接開始幹了，幹着幹着開發以爲需求不合理私自改了，大多數在不影響大功能狀況下是默許的；
• 一我的負責多個項目，少則四個，多則8到10個，不少項目一旦衝突並行，不免漏測，畢竟一我的精力有限，我想說的是，老闆，咋那麼扣呢，就不能多請我的？
• 測試同窗自身緣由，好比業務理解不透徹、用例設計覆蓋不全等等。

以上爲我以爲可能產生漏測的緣由，若是還有遺漏，還請後臺留言給我，一塊兒討論學習。

漏測究竟是誰的責任？

我我的以爲應該理性看待，具體問題，具體分析。

當上線後，出現bug後，確定第一時間應該找測試，測試同窗查看是否能復現這個問題，定位漏測問題緣由。

若是爲頁面有錯別字、頁面樣式重疊嚴重的、功能不可用，用例覆蓋不全面，業務理解不到位致使的這種很是淺顯能夠復現的問題，出了問題，找到測試，無可厚非。

若是是「不可預測、未知」的問題，好比說性能測試中，給出指標並已經測試10000人併發，並已告知開發人、產品測試併發量的狀況，而開發、產品人員均沒有提出異議。

但結果那天因爲銷量超好，併發量達到100000，系統崩潰了，這並非咱們能預測到的，因此是漏測，也不是一我的責任。

因此要對問題定位分析以後才能定位出來，是什麼緣由，是需求不明確，理解歧義，開發引入，或是其餘緣由，而後及時補救，最後再去定責。

如何避免漏測？

吃透業務需求

需求評審階段，產品經理、開發、測試在開會以前，通常都會收到一份需求文檔和原型圖。在開會前，研讀好需求文檔後，作好理解不明確和產生歧義的地方。

待產品經理組會來說解需求時，針對不懂的地方進行提問，認真記錄。

提升用例質量

提升用例覆蓋率，結合業務設計有效業務場景，保證測試有效性。

用例評審

測試人員結合用例對需求進行反串講，把對需求的理解講一遍，列出全部的測試點和測試場景，產品和開發同事評審是否有遺漏場景，若是沒有異議，這樣就能夠很大程度的避免漏測了。

交叉測試

一我的精力畢竟有限，若是條件和時間容許，能夠把測試過的功能交給你的搭檔，讓他幫忙在測試一下，畢竟每一個人的測試思路不同，也許也有收穫也不必定呢。

迴歸測試

梳理主流程用例，尤爲隨着版本迭代和功能的增長，回顧測試用例極爲重要，畢竟每次發版時，要保證主流程沒問題吧，主流程都有問題，難道還敢上線？

可能有的同窗說了，那麼多用例，也執行不完呀，不是有web自動化嗎，自動化跑唄，可能有的同窗說不會呀，我們學能夠嗎？

bug仲裁

在上線前，查看還有哪些問題，是未解決的，與產品、開發、測試經理商量，哪些bug是容許帶到線上的，若是三方達成一致，那麼線上再出問題，也是已知的，就沒什麼問題了。

作好漏測覆盤

對待漏測態度上必需要重視，分析爲什麼會漏測，是哪一個環節出了問題，是流程問題仍是技術問題？

一樣的坑別踩第二次，技術不足的學習補齊，流程不足的規範流程。

把它當作一次提升的機會，也正由於此次機會，讓你印象越深入，可以避免下次不會再犯一樣的錯誤。

總結

不得不說一句的是，漏測是不可能絕對避免的，咱們能作的只能是儘可能減小漏測現象，只要不出大問題，漏測現象會隨着工做經驗增長而逐漸減小。因此測試的時候，必定要仔細、細緻、認真，畢竟一次漏測可能會影響不少人，因此萬萬馬虎不得呀。