我們經常會碰到這樣的現象，同樣的被測對象不同的人去測試發現的缺陷不盡相同？有的人會遺漏測試深度層面的缺陷，有的人會遺漏測試廣度上的缺陷？
一.什麼是測試的深度和廣度？
如下圖，如果把測試類比爲捉蟲。同樣的被測對象/特性，如果你分析並執行的測試點越多，相當於你織的網越密，你的測試廣度越大。但是有些蟲子如果藏在草叢下（隱藏很深的缺陷），僅靠這張網的單一平面可能就無法捕獲了。
回到具體測試中，假設你在測試某款通訊設備上IPSec特性，你可以從廣度上考慮各種參數配置組合，考慮各種組網場景，從廣度上對其進行覆蓋。也可以從IPSec SA協商流程，從協議工作細節着手，在測試深度上下功夫，然後再各個擊破。
二.關於深度或廣度上的遺漏？
對於捕蟲這件事情，網是不是要織得無線大，無限密，然後要掘地三尺才能把捕蟲這件事情做OK?首先從測試的經濟學上來講，不可能將被測對象的所有測試點全部考慮並測試。另外每個測試人員的knowledge base（知識體系）是有差異的，對被測對象的認知也是有差異的。所以有遺漏在所難免。
那麼應該怎麼辦？
1>儘可能缺點廣度和深度上的邊界：
還是需要秉承MFQ的一貫理念，多交流學習。多和BA，PO或者更靠近用戶的人進行交流。在廣度上更多的確定用戶使用的場景和功能點；在深度上和DEV和BA上多確定實現細節（還是以通訊協議測試爲例），被測對象依賴的協議我們到底是實現了協議的子集還是全集？哪些地方是和標準協議不一致的？哪些是我們在標準協議基礎上擴展的？標準協議在我們產品架構上實現的方式等等……確定我們在深度上需要關注的內容。這樣我們儘可能在廣度和深度上確定好測試的邊界。然後還需要通盤考慮交付時間點、人力、測試資源等因素，在廣度和深度上都進行一些取捨。
2>灰色地帶進行探索:
上面提到了要儘可能的確定廣度和深度上的邊界。但是往往需求提出者對於需求應用的場景也說不清楚，DEV對於特性實現的能力邊界也講不清楚怎麼辦？這樣會產生大量的“灰色地帶”。我覺得可以先集中精力根據對被測產品、行業的瞭解，對於被測對象/特性最核心的必須要滿足的功能點進行驗證，然後對於灰色地帶進行探索性測試，探索一下產品它的能力到底如何，將疑問/問題通過測試報告的方式記錄下來反饋給PO或項目經理，讓他們來決策是否要解決疑問測試人員反饋風險的基本工作也就達到了。
3>團隊協作和分工：
測試人員在輸出TCO之後儘可能的組織一下評審，包括整個測試團隊的其他測試人員，DEV和BA儘可能的減少遺漏，減少高風險測試點的遺漏。
有些深度上的測試Idea可能通過ST的方式測試的代價太大或不具備可測試性，可以通過協商通過UT/FT的方式完成。網織的面積大到一定程度之後，可能很多測試是屬於功能交互測試，可以考慮和其他團隊功能來完成（對於大型的軟件項目，測試可能是分不同團隊來完成的，分爲前後端測試或者通過不同模塊來劃分測試團隊）。