有效缺陷分類管理

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內(nèi)部和業(yè)界推行，產(chǎn)生數(shù)億美元的質(zhì)量成本收益由IBM的T.J.Watson研究發(fā)明完成基本理論體系建設(shè)ODC : Orthogonal Defec

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

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

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

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

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

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

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

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

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

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

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

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

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

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