經驗和建議
- 這個趨勢圖可以按周或月來定期查看趨勢變化；
- 看這個圖時，不能只籠統的看表面所反映的數據，missing 所占的百分比是多少，incorrect 占多少。還應該看到更深層的內容，比如那些 missing 的缺陷到底屬于哪個 defect type? 又是發生在哪些 component? 這樣才能夠發現真正的風險在哪里，以此判斷產品是否穩定。而不僅僅只是看到有多少百分比的缺陷的 Qualifier 是 missing；
- 上圖中的縱坐標是百分比。如果某個時間段里僅發現了很少的缺陷時，這種表現方式會造成誤解。因此看這種類型的評估圖時，既要看用百分比來展現的視圖，也要看用缺陷數作為縱坐標來展現的視圖。
對產品設計和代碼的評估
供開發人員填寫的 ODC 屬性中有一個屬性叫做 target。它表示開發人員為了修復這個缺陷，需要在哪方面做修改。比如可以修改的方面包括：design/code、build、information、language 等。為了評估產品在設計和代碼方面的完成情況，我們可以分析 target 是 design/code 的缺陷，利用其對應的 defect type 和 qualifier 屬性來發現產品在需求、設計和代碼階段的不足，以及在哪個薄弱環節更容易引入缺陷。下面以一個案例來說明如何利用 defect type 和 qualifier 屬性來評估。如圖 7 所示。
圖 7. 利用 Defect type 和 Qualifier 得到的評估圖
從圖 7 中我們可以看到 defect type 為 algorithm/method 的缺陷，qualifier 是 missing 和 incorrect 的比例及缺陷數量都很高。這說明產品的低層次的細節設計描述不完整，同時沒有被開發人員很好的理解；其次是 defect type 為 assignment-initialization 和 checking 的缺陷，它們的 incorrect 比例相對來說比較高，這反映了代碼編寫上還存在欠缺；最后我們看到 defect type 為 interface/O-O messages、relationship 和 timing/serialization 等的缺陷，其 qualifier 為 incorrect 和 missing 的數量都比較少，這說明產品在高層次的設計上和需求分析、理解上都還做得不錯。
經驗和建議
- 根據產品不同的 component，做出圖 7 這樣的評估圖，這樣比籠統的統計整個產品的 qualifier 和 defect type 屬性關系更有意義。因為這樣可以清楚的看到每個 component 的問題，然后針對每個 component 提出改進的解決辦法，以減少缺陷的注入。
4. 行動階段
僅僅發現了問題，是不夠的，還需要解決問題。根據評估過程中反映出的不同問題，有針對性的提出解決方案并讓相關人員采取行動。這一階段也是最能給產品帶來價值的。
經驗和建議
- 測試和開發團隊應該參與到這個過程中，因為他們才是最終行動的實施者；
- 所識別的行動應該是合理的，有可行性的；
- 所識別的行動越具體越好。不要籠統的指出對產品有什么改進行動，最好是能針對某個組件或是模塊，采取行動；
- 利用在評估階段生成的各種評估圖一起分析、衡量出改進的行動方案，不要單憑某一個評估圖來做決定；
- 要采取的行動應該是可以衡量的，這樣可以看出是否該行動對產品有積極的影響。
總結
正交缺陷分類（ODC）是一種缺陷分析方法，合理的把它運用在項目中，可以幫助測試、開發團隊改進工作，從而提高產品質量。明確 ODC 的流程及各階段的工作重點，并借鑒本文中提到的經驗建議，會讓讀者在運用 ODC 時更加得心應手。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
