5、分析缺陷的標準通過收集缺陷，對比測試用例和缺陷數據庫，分析確證是漏測還是缺陷復現。漏測反映了測試用例的不完善，應立即補充相應測試用例，最終達到逐步完善軟件質量。而已有相應測試用例，則反映實施測試或變更處理存在問題。
五、相關問題
1、測試用例的評審測試用例是軟件測試的準則，但它并不是一經編制完成就成為準則。測試用例在設計編制過程中要組織同級互查。完成編制后應組織專家評審，需獲得通過才可以使用。評審委員會可由項目負責人、測試、編程、分析設計等有關人員組成，也可邀請客戶代表參加。
2、測試用例的修改更新測試用例在形成文檔后也還需要不斷完善。主要來自三方面的緣故：第一、在測試過程中發現設計測試用例時考慮不周，需要完善；第二、在軟件交付使用后反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成；第三、軟件自身的新增功能以及軟件版本的更新，測試用例也必須配套修改更新。
一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟件的版本升級更新，測試用例一般也應隨之編制升級更新版本。
3、測試用例的管理軟件運用測試用例還需配備測試用例管理軟件。它的主要功能有三個：第一、能將測試用例文檔的關鍵內容，如編號、名稱等等自動導入管理數據庫，形成與測試用例文檔完全對應的記錄；第二、可供測試實施時及時輸入測試情況；第三、最終實現自動生成測試結果文檔，包含各測試度量值，測試覆蓋表和測試通過或不通過的測試用例清單列表。
有了管理軟件，測試人員無論是編寫每日的測試工作日志、還是出軟件測試報告，都會變得輕而易舉。
開發一個軟件產品，會發布多個版本，伴隨著測試用例（Test case）的不斷維護， 使測試用例不斷完善并與產品功能、特性（features）的變化保持一致，所以測試用例是和產品版本相關聯的。特別是對提供軟件服務的軟件產品，多個版本常常共存，為客戶提供服務，這時多個版本的測試用例也是并存的，所以在新建、修改、刪除測試用例時要十分小心，并有相應的規則。
根據產品特性和test case一致性，分下面幾種情況分別處理：
1. 產品特性沒變，只是根據Late Discovery Bug 或 Remedy Ticket 來完善 test case，只有這時候可以修改Test case， 也就意味著當前修改的test case，對目前和以前的版本都有效。
2. 原有產品特性發生了變化，不是new feature， 而是enhanced features（功能增強）， 這時候原有的 test case 只對先前版本（如version 1.0、2.0） 有效，而對新的版本（如 version 3.0）無效，這時絕不能修改 test case ，只能增加新的 test case，這一點很重要。原有的 test case 依然對原有版本有效（如version 1.0、2.0）。
3. 原有功能取消了，這時只要在新版本上使之對應的test case置為inactive（無效）。
4. 完全新增加的特性，大家比較清楚，增加對應的、新的測試用例。
這樣，新舊版本的相同測試用例得到一致的維護，測試用例數也不會成幾、十幾倍的增加，可以真正保證 test case 的完整性、有效性！
文章來源于領測軟件測試網 http://www.kjueaiud.com/