常見問題及建議
缺陷管理工具對 ODC 的支持不完善
有些 ODC 屬性間是有關聯關系的。例如：在 ODC Submitter 選項簽中，如果在 Activity 屬性中選擇了“Function Test”，那么 Trigger 屬性就只能在“Coverage”，“Sequence”，“Variation”和“Interaction”中進行選擇。如果在 Activity 屬性中選擇了“System Test”，那么可選的 Trigger 屬性的值又是截然不同的另外幾種選項，分別為：“Workload”，“Recovery”，“Startup/Restart”，“Hardware config”和“Software config”。在缺陷管理工具中，若對這些屬性間的關聯關系不做限制，選擇每個選項時都會把所有的值列出來供用戶選擇，這樣很容易造成選項間的不匹配。從而導致最后統計 ODC 數據時，結果不合理。
另外，沒有對 ODC 屬性項進行必填操作的校驗，也是缺陷管理工具對 ODC 支持不完善的表現之一。例如：僅填寫了 Activity 屬性，即表明了該缺陷是在何種類型的測試中發現的，但是不填寫 Trigger 屬性，也就是說不指明是在哪種觸發條件下發現的該缺陷，就會造成信息缺失，從而分析出的結果也不會準確。
因此，我們強烈建議在配置缺陷管理工具用以支持 ODC 時，加上對有關聯關系屬性的限制，并對必填的 ODC 屬性進行強制填寫的校驗，強制每個人必須填寫，否則無法提交成功。從而在工具的層面上，保證 ODC 數據輸入的完整性和正確性。
測試或開發人員對各自需要填寫的 ODC 屬性不熟悉
ODC 這種缺陷分析方法并沒有普及到每一個項目中，因此在第一次應用 ODC 的項目中必須在分類階段前，就要在項目內部做好 ODC 知識的系統培訓。不僅僅是簡單的了解，而是需要知道每個屬性所有可選項的含義。這樣就不會在分類階段開始后，一片茫然。另外，由于 ODC 屬性選項眾多，不可能靠之前的幾次培訓就全部記住。建議打印一份類似于 ODC 屬性快速參考手冊的資料。這樣在填寫 ODC 數據時，可一邊參考手邊的文檔一邊填寫。
2. 校驗階段
在第一步中，測試人員和開發人員已經填寫了 ODC 數據。那么接下來就需要 ODC 專家對這些數據進行校驗。因為填寫不正確的 ODC 數據會導致后面的評估和行動兩個流程步驟沒有意義。因此校驗數據的正確性尤為重要。
常見問題及建議
校驗結果如何在缺陷管理工具中體現？
校驗員在校驗完某個缺陷并確認相關人員已經完成修改后，校驗工作還并沒有結束。為了在下一階段，即評估階段中，僅僅對已被校驗過的缺陷進行分析，就需要在缺陷管理工具中有地方進行標識，用以過濾掉未校驗過的缺陷。
可以在 ODC Responder 選項簽中增加一個屬性項，叫做“ODC Validated”。如圖 3 所示。
圖 3. ODC Responder 選項簽中新增加屬性 ODC Validated:
有四個選項可供選擇。
- “空”：默認情況下，該屬性項為空。表示校驗人員還沒有開始進行該缺陷的校驗工作；
- “是”：已被校驗過，并且相關人員已經把錯誤的 ODC 屬性進行了修改；
- “否”：已被校驗過，但是相關人員還沒有進行修改；
- “N/A”：對于無效的缺陷，是不算在最后的統計數據中的。出現無效缺陷的情況可以包括：由于測試人員的問題，開的無效缺陷（User Error）；所發現的問題并不是一個缺陷，而恰恰在產品設計上就是這樣的（As Design）；該缺陷與之前開的另一缺陷重復（duplicate）；
文章來源于領測軟件測試網 http://www.kjueaiud.com/
