漏測通用性定義：
指在產品缺陷在測試過程中沒有被發現（尤其是測試環境可以重現的缺陷），而是在版本發布后或者在用戶使用后發現並反饋回來的缺陷。可以說，漏測的問題是測試管理者最頭痛的問題。因為出現漏測，一來給客戶帶來了不好的影響和印象，二來增加缺陷修復的成本，三來給測試團隊也帶來負面和不利的影響。因此，作為測試管理者，測漏分析和預防是必須要做好。
測試團隊一定要做漏測分析的目的：
就是通過分析開發和測試過程中漏測的缺陷，制定相應的預防措施以避免今后再發生類似的漏測。測試過程的持續改進將提高測試環境的效果和測試執行的效率、降低遺留到用戶處的缺陷數和缺陷解決成本，從而提升軟件的質量、聲譽和銷售。在軟件產品開發過程中重視漏測分析並參與到漏測分析工作中的團隊越多，漏測分析的效果就越好。
漏測管理規范的定義考慮范圍：
（1）團隊內部對漏測的定義？
（2）漏測的原因分析？
（3）如何預防漏測？
（4）漏測問題如何定義嚴重性？如何判定應總結性輸出文檔及有一定的懲罰措施？或只是總結在組內進行分享。
（5）。。。。。。
漏測的原因分析有以下的幾個方面：
-
需求評審質量低，或參評人員能力不足，或過程不規范嚴謹
-
需求變更頻繁，測試用例無及時更新
-
用例設計的過於粗獷，測試步驟不清晰
-
測試用例對需求的覆蓋面不全，考慮不足
-
測試人員測試思維局限，無思考全面
-
測試人員執行過程不規范，人為漏測
-
測試執行人員質量意識不足，發現的缺陷定義嚴重性程度低或不認為是問題
- 測試環境與生產環境有較大出入
- 測試環境或測試數據受限，無法模擬並覆蓋執行所有正常和異常的場景分支
-
功能回歸策略問題
-
測試資源有限
-
……
漏測預防或改進措施有以下幾個方面：
-
需求評審質量的提高
-
需求評審過程必須建立規范的評審流程
-
需求評審至少有需求、開發和測試人員參加
-
需求評審必須安排業務熟悉和測試經驗豐富的測試人員參加
-
測試用例的及時更新維護
-
每當發起了需求變更必須及時更新測試用例庫和做好過程記錄及用例評審
-
在測試過程中啟發的測試用例必須及時更新或錄入到測試用例庫
-
漏測情況出現時，必須分析漏測原因和補充對應的測試用例
-
反饋的運維缺陷問題（軟件部分）必須分析原因，並補充的測試用例庫
-
測試用例質量的提高（顆粒度、需求覆蓋度、冗余度等）
-
測試用例的設計編寫必須由有測試經驗和業務基礎的測試人員設計編寫
-
着重正常流程測試用例，尤其常用和典型的用戶場景和操作的分析
-
建立規范的測試用例評審制度（組長評審、同行評審或組、組之間的交叉評審或發起需求和開發進行評審）
-
建立通用測試用例庫和測試用例框架，建立優質測試用例
-
提前並多方面准備充分的測試數據以覆蓋到所有測試用例
-
測試人員測試思維和測試意識的提高
-
組織部門內部的業務知識培訓
-
組織部門內部的技術技能培訓
-
組織部門內部的測試交流活動
-
測試環境要盡量貼近生產環境
-
保證測試環境數據庫與生產環境的版本和配置一致
-
保證測試環境服務中間件與生產環境的版本和配置一致
-
可以的話，保證測試環境主機配置與生產環境主機配置一致
-
可以的話，保證或模擬測試環境的網絡環境與生產環境的一致
-
要注意環境的兼容性測試問題，如系統、版本、分辨率等
-
測試執行過程的規范性、嚴謹性和策略性
-
測試過程嚴格按照測試用例執行
-
適時進行結對測試和交叉測試
-
適時加入探索性測試或隨機測試
-
測試前，測試人員必須熟悉業務需求，亦要熟悉軟件邏輯
-
測試過程中要不斷補充遺漏的測試用例
-
測試過程盡量貼近用戶實際環境去測
-
如有不影響實際使用的生產環境提供測試，最好在生產的環境和接口上進行測試
-
測試策略的制定與及時調整
-
測試前根據風險定好測試策略，做好測試安排
-
測試過程時刻關注項目進度，隨時做好測試調整的准備
-
如有充足的測試時間，最后一輪應該進行全面的回歸測試
-
如有充足的測試時間，可以進行生產環境的beta測試
-
回歸測試必須重點關注開發的修改范圍，以免遺漏新引入的缺陷
-
漏測的原因分析及分享和漏測財富庫的建立
-
每當出現漏測現象，必須分析原因並組內通報，吸取教訓
-
每當出現漏測，必須將漏測的缺陷及原因分析錄入財富庫
PS：
1、當出現因為漏測反饋回來的問題時，測試管理者必須重視，並積極處理。立刻安排測試人員重現缺陷，並分析漏測原因。
2、漏測時缺陷一定要進行分析原因，思考總結和吸取經驗教訓，並在部門內部公開學習，以免其他成員同樣情況再次發生，盡可能減低缺陷的漏測量。
3、往往實際項目過程中，測試時間一般不會太充分，測試是基於風險和策略去進行測試的。因此，如何在有限的資源（時間，人力等）內進行有效的，充分的測試是每一個測試管理者需要思考的問題。