有效缺陷分類管理

1、缺陷的有效管理缺陷的有效管理XXXX2016/08/XXXXXX1/24目目錄錄ODC缺陷分類法簡介0102ODC屬性03ODC工作流程04ODC與測試中心2/24目目錄錄ODCODC缺陷分類法簡介缺陷分類法簡介0102ODC屬性03ODC工作流程04ODC與測試中心3/24ODCODC方法的發(fā)展歷史方法的發(fā)展歷史ODC : Orthogonal Defect Classification 正交缺陷分類法4/241990年1997年1998年后在IBM內部和業(yè)界推行，產生數億美元的質量成本收益由IBM的T.J.Watson研究發(fā)明完成基本理論體系建設ODC : Orthogonal Defec

2、t Classification 正交正交缺陷缺陷分類法分類法5/24 軟件缺陷：指的是軟件工作產品的不足或不完美之處。 軟件工作產品：指的是軟件過程所創(chuàng)造的一切產物，包括計算機程序、計劃、流程、及所有相關的文檔和數據。 軟件過程：是人們用以開發(fā)和維護軟件工作產品的一系列活動、方法、實踐和轉換。 軟件故障：指的是軟件缺陷在一定的輸入條件下被激活的結果，它在無適當容錯措施的情況下造成失效。 軟件失效：指的是軟件執(zhí)行過程中系統(tǒng)行為與用戶需求的偏離。 何謂正交？0 xXYZXY 正交缺陷正交缺陷分類法分類法 ODC在高層次上，是幫助獲取缺陷信息的一個缺陷分類方案。 它不僅僅是一個分類方法，ODC是一

3、個軟件過程的度量系統(tǒng)，它是建立在包含于缺陷流中的語義信息基礎上的。 它可以幫助我們評估測試的效力和效率，可以進行錯誤跟蹤，通過ODC背后的分析機制評估顧客的滿意度。6什么是什么是ODCODC？ ODC技術：結合了根原因分析和統(tǒng)計建模結合了根原因分析和統(tǒng)計建模(Statistical Modeling) 兩種軟件缺陷分析技術的優(yōu)勢。兩種軟件缺陷分析技術的優(yōu)勢。提供了一套用于捕獲缺陷數據關鍵特性的方案，并給出對分類的缺陷數據集進行提供了一套用于捕獲缺陷數據關鍵特性的方案，并給出對分類的缺陷數據集進行分析的指導。分析的指導。可以幫助我們全面了解缺陷，從而采取最有效的措施來改進軟件開發(fā)過程中的不可以幫

4、助我們全面了解缺陷，從而采取最有效的措施來改進軟件開發(fā)過程中的不足，不斷地提高軟件產品質量。足，不斷地提高軟件產品質量。 ODC統(tǒng)計分析可以：準確確定產品主要質量問題區(qū)域準確確定產品主要質量問題區(qū)域識別缺陷引入和去除過程的重點改進對象識別缺陷引入和去除過程的重點改進對象實現(xiàn)對過程和產品的精確改進指導實現(xiàn)對過程和產品的精確改進指導7/24正交缺陷分類法適用對象正交缺陷分類法適用對象 開發(fā)生命周期相對來說是一個很漫長的過程，包括后續(xù)的改進工作。例如，這個項目包括多個軟件版本或者一個版本有多次迭代。 潛在的缺陷數目是相當大的。缺陷數目越多，客觀的分析結果也越多，對了解軟件質量越有好處。 這個項目已經

5、將“高可靠”設定為它的主要目標之一。8目目錄錄ODC缺陷分類法簡介01ODCODC屬性屬性0203ODC工作流程04ODC與測試中心9/24ODCODC屬性屬性提出者提出者10ODCODC屬性屬性關閉關閉者者11ODCODC屬性分配屬性分配12/24目目錄錄ODC缺陷分類法簡介01ODC屬性02ODCODC工作流程工作流程0304ODC與測試中心13/24ODCODC使用模型使用模型14ODCODC工作流程工作流程15/24 正交缺陷分類法，Orthogonal Defect Classification（以下簡稱 ODC）是一種缺陷分析方法，由 IBM 在 1992 年提出。它通過給每個缺陷

6、添加一些額外的屬性，利用對這些屬性的歸納和分析，來反映出產品的設計、代碼質量、測試水平等各方面的問題。從而得到一些解決辦法來進行改進。 ODC 的工作流程分為四部分：“缺陷分類”，“校驗已被分類的缺陷”，“評估數據”以及“采取行動來改進工作”。下面我們將逐一進行講解。缺陷分類缺陷分類16/24 分類，是 ODC 工作流程中的第一步，即需要測試和開發(fā)人員分別對每一個缺陷填寫 ODC 屬性。對于團隊成員來說，正確的了解每個屬性的值尤為重要，這樣才能保證他們在分類時盡量選擇正確的選項。 在填寫之前，需要缺陷管理工具進行改進，配置額外的屬性。常用的缺陷管理工具包括 Clear Quest(CQ) 和

7、Configuration Management Version Control(CMVC) 等。需要增加的 8個 ODC 相關屬性分別是： Activity：表示在做哪種測試時發(fā)現(xiàn)的缺陷。 Trigger；表示采取哪種方式觸發(fā)的該缺陷，不同的 activity 對應不同的 trigger 類型； Impact：表示該缺陷的發(fā)生會對客戶造成的影響；缺陷分類缺陷分類17/24 Target：表示開發(fā)人員為了修復這個缺陷，需要在哪方面做修改。比如可以修改的方面包括：產品設計、相應的代碼和文檔等； Defect Type：缺陷類型； Qualifier：表示該缺陷是由于丟失相關代碼、還是代碼不正確造

8、成的?；蛘呤怯捎诘谌教峁┑拇a造成的； Source：表示該缺陷的來源是由于內部編寫的代碼引起的問題，還是由外包公司提供的代碼引起的等； Age：表示該缺陷是由新代碼產生的還是由于修改其它缺陷而引發(fā)的，或是在上一個發(fā)布版本中就已經有的問題等； （Content Type: 表示修復文檔的類型。僅對文檔類的缺陷有效。）測試人員進行分類測試人員進行分類 從下圖 中我們可以看到，ODC Submitter 選項簽中有三個選項，分別是 Activity、Trigger 和 Impact。這三個選項是由測試人員，也就是該缺陷的發(fā)現(xiàn)者來填寫的。18/24開發(fā)人員進行分類開發(fā)人員進行分類從圖 2 中我們可

9、以看到，ODC Responder 選項簽中有六個選項，分別是 Target，Defect Type，Qualifier Source，Age 和 ContentType。這六個選項是由開發(fā)人員，也就是該缺陷的解決者來填寫的。19/24分類常見問題分類常見問題缺陷管理工具對缺陷管理工具對 ODC 的支持不的支持不完善完善有些 ODC 屬性間是有關聯(lián)關系的。例如：在 ODC Submitter 選項簽中，如果在 Activity 屬性中選擇了“Function Test”，那么 Trigger 屬性就只能在“Coverage”，“Sequence”，“Variation”和“Interactio

10、n”中進行選擇。如果在 Activity 屬性中選擇了“System Test”，那么可選的 Trigger 屬性的值又是截然不同的另外幾種選項，分別為：“Workload”，“Recovery”，“Startup/Restart”，“Hardware config”和“Software config”。在缺陷管理工具中，若對這些屬性間的關聯(lián)關系不做限制，選擇每個選項時都會把所有的值列出來供用戶選擇，這樣很容易造成選項間的不匹配。從而導致最后統(tǒng)計 ODC 數據時，結果不合理。20/24分類常見問題分類常見問題測試測試或開發(fā)人員對各自需要填寫的或開發(fā)人員對各自需要填寫的 ODC 屬性不屬性不熟悉

11、熟悉ODC 這種缺陷分析方法并沒有普及到每一個項目中，因此在第一次應用 ODC 的項目中必須在分類階段前，就要在項目內部做好 ODC 知識的系統(tǒng)培訓。不僅僅是簡單的了解，而是需要知道每個屬性所有可選項的含義。21/24校驗階段校驗階段 在第一步中，測試人員和開發(fā)人員已經填寫了 ODC 數據。那么接下來就需要 ODC 專家對這些數據進行校驗。因為填寫不正確的 ODC 數據會導致后面的評估和行動兩個流程步驟沒有意義。因此校驗數據的正確性尤為重要。 校驗結果如何在缺陷管理工具中體現(xiàn)校驗結果如何在缺陷管理工具中體現(xiàn)？ 校驗員在校驗完某個缺陷并確認相關人員已經完成修改后，校驗工作還并沒有結束。為了在下一

12、階段，即評估階段中，僅僅對已被校驗過的缺陷進行分析，就需要在缺陷管理工具中有地方進行標識，用以過濾掉未校驗過的缺陷。22評估階段評估階段 在確保輸入的 ODC 數據正確性的前提下，就可以對這些缺陷進行分析了。根據 ODC 的不同屬性進行分類統(tǒng)計，可得出不同方面的結論。以此來反映測試、開發(fā)或產品設計方面的問題，指出潛在的改進的機會。比如：缺陷被發(fā)現(xiàn)的如何、產品是否穩(wěn)定等。下面選擇測試工作的評估方法進行說明。23對測試工作的評估對測試工作的評估 利用不同的 ODC 屬性的組合，可以從多方面來評估測試工作的完成情況。例如利用測試階段和 activity 屬性來評估是否應在某一測試階段中發(fā)現(xiàn)的缺陷卻被

13、在下一測試階段中才發(fā)現(xiàn)；利用 activity 和 trigger 屬性來評估是否每個 activity 都使用了足夠多的與之對應的 trigger 來發(fā)現(xiàn)缺陷；利用時間和 trigger 屬性來評估是否隨著時間的推移測試變得更加復雜等。下面就利用第一種評估方法來進行舉例。24對測試工作的評估對測試工作的評估 不同的測試階段有不同的測試重點。例如在功能測試階段，所對應的 activity 就是 Function Test( 功能測試 )。而在系統(tǒng)測試階段，所對應的 activity 就是 System Test（系統(tǒng)測試）。我們可以通過統(tǒng)計在每種測試階段中發(fā)現(xiàn)缺陷的 activity 來判斷是

14、否本應在該測試階段中發(fā)現(xiàn)的缺陷被遺留到了下一測試階段。以此來評估測試工作的完成情況。如圖 所示。2526利用測試階段和利用測試階段和 activity 屬性得到的評估圖屬性得到的評估圖對測試工作的評估對測試工作的評估 這個評估方法常用于衡量是否本應該在功能測試階段發(fā)現(xiàn)的缺陷沒有被發(fā)現(xiàn)，而是到了系統(tǒng)測試階段才被發(fā)現(xiàn)。因此該評估方法最好在系統(tǒng)測試開始后使用，因為在此之前的階段使用沒有太大的幫助； 客觀上講，在系統(tǒng)測試階段發(fā)現(xiàn)一些功能測試階段的缺陷是正?，F(xiàn)象，這不會影響系統(tǒng)測試的正常運行。反而如果在系統(tǒng)測試階段沒有任何功能測試階段的缺陷，就說明有問題了。很可能是由于測試人員對 activity 屬性

15、理解不正確導致的錯誤輸入引起的；27ODCODC缺陷分析方法缺陷分析方法28/24ODCODC缺陷分析方法缺陷分析方法29/24行動階段行動階段 僅僅發(fā)現(xiàn)了問題，是不夠的，還需要解決問題。根據評估過程中反映出的不同問題，有針對性的提出解決方案并讓相關人員采取行動。這一階段也是最能給產品帶來價值的。 測試和開發(fā)團隊應該參與到這個過程中，因為他們才是最終行動的實施者； 所識別的行動應該是合理的，有可行性的； 所識別的行動越具體越好。不要籠統(tǒng)的指出對產品有什么改進行動，最好是能針對某個組件或是模塊，采取行動； 利用在評估階段生成的各種評估圖一起分析、衡量出改進的行動方案，不要單憑某一個評估圖來做決定； 要采取的行動應該是可以衡量的，這樣可以看出是否該行動對產品有積極的影響。30目目錄錄ODC缺陷分類法簡介01ODC屬性02ODC工作流程03ODCODC與測試中心與測試中心0431/24ODCODC的好處的好處對于測試團隊，通過 ODC 可以知道測試工作是否變得更加復雜；每一個測試階段，是否利用了足夠多的觸發(fā)條件來發(fā)現(xiàn)缺陷；退出當前測試階段有什么風險；哪個