測試人員除了按照需求文檔編寫case外，未添加其他項目計劃、開發文檔等形成的case

二、發生時間段

Always

三、陷阱表現

1.質量需求（易用性、可靠性、健壯性、可移植性、安全性、可維護性等）

2.數據需求（如：統計類需求）

3.接口需求（如：針對叠代需求較少時，容易忽略細微的新增接口，或是測試人員認為不會影響到基線功能）

4.針對異常的系統強制響應（常見的有提交表單時機器卡頓，網絡異常）

四、負面後果

1.基於需求的測試不會表現出疏漏的行為和特征。

2.管理層或其他開發人員認為交付的系統會正常運行。

3.測試人員必須與產品或客戶經常討論測試過程中確定的疏漏的需求。

4.疏漏的需求在測試過程中未發現，交付了部署系統

5.疏漏需求導致架構設計不充分，使開發人員排查Bug更加困難。

五、出現原因

1. 產品人員未經專業培訓，使形成的需求文檔邏輯不足，如不懂質量模型，未描述系統質量特性

2. 發現疏漏需求時，產品人員未及時更新需求池和PRD

3. 測試用例只定義了正常的用例路徑 ，未對故障、失效容錯做充分定義

4. 項目其他管理人員未評審過需求

5. 產品沒有充足的時間和資源對產品進行分析。

六、建議

1. 準備階段

對於識別出的遺漏需求，對產品進行需求過程相關培訓。

2. 啟用階段

為產品人員提供識別遺漏需求的專業培訓。

確保測試進度計劃中包括足夠時間解決測試過程中發現的遺漏需求。

3. 執行階段

（1）識別遺漏需求方法：端到端的任務線程模型、用例建模、質量模型。

（2）需求文檔靜態測試，考慮到錯誤、故障和失效容錯 。

（3）需求文檔和需求池的內容需要經過專家或業務代表評審

（4）測試過程中發現的疏漏需求要及時通知到產品

4. 驗證階段

（1）檢查是否進行了足夠的需求建模

（2）檢查需求是否充分考慮到錯誤、故障和失效容錯

（3）檢查需求池中是否包括適當數量的質量和數據需求

（4）檢查是否需求已由足夠數量的系統相關人員評審

（5）檢查測試過程中發現的所有遺漏需求 ，是否已通知產品人員。

測試過程之需求疏漏缺陷匯總