有效缺陷分類管理

缺陷的有效管理XXXX2016/08/XXXXXX1/24目錄ODC缺陷分類法簡介0102ODC屬性03ODC工作流程04ODC與測試中心2/24目錄ODC缺陷分類法簡介0102ODC屬性03ODC工作流程04ODC與測試中心3/24ODC方法的發(fā)展歷史ODC:OrthogonalDefectClassification正交缺陷分類法4/241990年1997年1998年后在IBM內(nèi)部和業(yè)界推行，產(chǎn)生數(shù)億美元的質(zhì)量成本收益由IBM的T.J.Watson研究發(fā)明完成基本理論體系建設(shè)ODC:OrthogonalDefectClassification正交缺陷分類法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)行為與用戶需求的偏離。何謂正交？0xXYZXY正交缺陷分類法ODC在高層次上，是幫助獲取缺陷信息的一個(gè)缺陷分類方案。它不僅僅是一個(gè)分類方法，ODC是一個(gè)軟件過程的度量系統(tǒng)，它是建立在包含于缺陷流中的語義信息基礎(chǔ)上的。它可以幫助我們評估測試的效力和效率，可以進(jìn)行錯(cuò)誤跟蹤，通過ODC背后的分析機(jī)制評估顧客的滿意度。6什么是ODC？ODC技術(shù)：結(jié)合了根原因分析和統(tǒng)計(jì)建模(StatisticalModeling)兩種軟件缺陷分析技術(shù)的優(yōu)勢。提供了一套用于捕獲缺陷數(shù)據(jù)關(guān)鍵特性的方案，并給出對分類的缺陷數(shù)據(jù)集進(jìn)行分析的指導(dǎo)?？梢詭椭覀?nèi)媪私馊毕荩瑥亩扇∽钣行У拇胧﹣砀倪M(jìn)軟件開發(fā)過程中的不足，不斷地提高軟件產(chǎn)品質(zhì)量。ODC統(tǒng)計(jì)分析可以：準(zhǔn)確確定產(chǎn)品主要質(zhì)量問題區(qū)域識別缺陷引入和去除過程的重點(diǎn)改進(jìn)對象實(shí)現(xiàn)對過程和產(chǎn)品的精確改進(jìn)指導(dǎo)7/24正交缺陷分類法適用對象開發(fā)生命周期相對來說是一個(gè)很漫長的過程，包括后續(xù)的改進(jìn)工作。例如，這個(gè)項(xiàng)目包括多個(gè)軟件版本或者一個(gè)版本有多次迭代。潛在的缺陷數(shù)目是相當(dāng)大的。缺陷數(shù)目越多，客觀的分析結(jié)果也越多，對了解軟件質(zhì)量越有好處。這個(gè)項(xiàng)目已經(jīng)將“高可靠”設(shè)定為它的主要目標(biāo)之一。8目錄ODC缺陷分類法簡介01ODC屬性0203ODC工作流程04ODC與測試中心9/24ODC屬性——提出者10ODC屬性——關(guān)閉者11ODC屬性分配12/24目錄ODC缺陷分類法簡介01ODC屬性02ODC工作流程0304ODC與測試中心13/24ODC使用模型14ODC工作流程15/24正交缺陷分類法，OrthogonalDefectClassification（以下簡稱ODC）是一種缺陷分析方法，由IBM在1992年提出。它通過給每個(gè)缺陷添加一些額外的屬性，利用對這些屬性的歸納和分析，來反映出產(chǎn)品的設(shè)計(jì)、代碼質(zhì)量、測試水平等各方面的問題。從而得到一些解決辦法來進(jìn)行改進(jìn)。ODC的工作流程分為四部分：“缺陷分類”，“校驗(yàn)已被分類的缺陷”，“評估數(shù)據(jù)”以及“采取行動(dòng)來改進(jìn)工作”。下面我們將逐一進(jìn)行講解。缺陷分類16/24分類，是ODC工作流程中的第一步，即需要測試和開發(fā)人員分別對每一個(gè)缺陷填寫ODC屬性。對于團(tuán)隊(duì)成員來說，正確的了解每個(gè)屬性的值尤為重要，這樣才能保證他們在分類時(shí)盡量選擇正確的選項(xiàng)。在填寫之前，需要缺陷管理工具進(jìn)行改進(jìn)，配置額外的屬性。常用的缺陷管理工具包括ClearQuest(CQ)和ConfigurationManagementVersionControl(CMVC)等。需要增加的8個(gè)ODC相關(guān)屬性分別是：Activity：表示在做哪種測試時(shí)發(fā)現(xiàn)的缺陷。Trigger；表示采取哪種方式觸發(fā)的該缺陷，不同的activity對應(yīng)不同的trigger類型；Impact：表示該缺陷的發(fā)生會(huì)對客戶造成的影響；缺陷分類17/24Target：表示開發(fā)人員為了修復(fù)這個(gè)缺陷，需要在哪方面做修改。比如可以修改的方面包括：產(chǎn)品設(shè)計(jì)、相應(yīng)的代碼和文檔等；DefectType：缺陷類型；Qualifier：表示該缺陷是由于丟失相關(guān)代碼、還是代碼不正確造成的?；蛘呤怯捎诘谌教峁┑拇a造成的；Source：表示該缺陷的來源是由于內(nèi)部編寫的代碼引起的問題，還是由外包公司提供的代碼引起的等；Age：表示該缺陷是由新代碼產(chǎn)生的還是由于修改其它缺陷而引發(fā)的，或是在上一個(gè)發(fā)布版本中就已經(jīng)有的問題等；（ContentType:表示修復(fù)文檔的類型。僅對文檔類的缺陷有效。）測試人員進(jìn)行分類從下圖

中我們可以看到，ODCSubmitter選項(xiàng)簽中有三個(gè)選項(xiàng)，分別是Activity、Trigger和Impact。這三個(gè)選項(xiàng)是由測試人員，也就是該缺陷的發(fā)現(xiàn)者來填寫的。18/24開發(fā)人員進(jìn)行分類從圖2中我們可以看到，ODCResponder選項(xiàng)簽中有六個(gè)選項(xiàng)，分別是Target，DefectType，QualifierSource，Age和ContentType。這六個(gè)選項(xiàng)是由開發(fā)人員，也就是該缺陷的解決者來填寫的。19/24分類常見問題缺陷管理工具對ODC的支持不完善有些ODC屬性間是有關(guān)聯(lián)關(guān)系的。例如：在ODCSubmitter選項(xiàng)簽中，如果在Activity屬性中選擇了“FunctionTest”，那么Trigger屬性就只能在“Coverage”，“Sequence”，“Variation”和“Interaction”中進(jìn)行選擇。如果在Activity屬性中選擇了“SystemTest”，那么可選的Trigger屬性的值又是截然不同的另外幾種選項(xiàng)，分別為：“Workload”，“Recovery”，“Startup/Restart”，“Hardwareconfig”和“Softwareconfig”。在缺陷管理工具中，若對這些屬性間的關(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ā)人員對各自需要填寫的ODC屬性不熟悉ODC這種缺陷分析方法并沒有普及到每一個(gè)項(xiàng)目中，因此在第一次應(yīng)用ODC的項(xiàng)目中必須在分類階段前，就要在項(xiàng)目內(nèi)部做好ODC知識的系統(tǒng)培訓(xùn)。不僅僅是簡單的了解，而是需要知道每個(gè)屬性所有可選項(xiàng)的含義。21/24校驗(yàn)階段在第一步中，測試人員和開發(fā)人員已經(jīng)填寫了ODC數(shù)據(jù)。那么接下來就需要ODC專家對這些數(shù)據(jù)進(jìn)行校驗(yàn)。因?yàn)樘顚懖徽_的ODC數(shù)據(jù)會(huì)導(dǎo)致后面的評估和行動(dòng)兩個(gè)流程步驟沒有意義。因此校驗(yàn)數(shù)據(jù)的正確性尤為重要。校驗(yàn)結(jié)果如何在缺陷管理工具中體現(xiàn)？

校驗(yàn)員在校驗(yàn)完某個(gè)缺陷并確認(rèn)相關(guān)人員已經(jīng)完成修改后，校驗(yàn)工作還并沒有結(jié)束。為了在下一階段，即評估階段中，僅僅對已被校驗(yàn)過的缺陷進(jìn)行分析，就需要在缺陷管理工具中有地方進(jìn)行標(biāo)識，用以過濾掉未校驗(yàn)過的缺陷。22評估階段在確保輸入的ODC數(shù)據(jù)正確性的前提下，就可以對這些缺陷進(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)定等。下面選擇測試工作的評估方法進(jìn)行說明。23對測試工作的評估利用不同的ODC屬性的組合，可以從多方面來評估測試工作的完成情況。例如利用測試階段和activity屬性來評估是否應(yīng)在某一測試階段中發(fā)現(xiàn)的缺陷卻被在下一測試階段中才發(fā)現(xiàn)；利用activity和trigger屬性來評估是否每個(gè)activity都使用了足夠多的與之對應(yīng)的trigger來發(fā)現(xiàn)缺陷；利用時(shí)間和trigger屬性來評估是否隨著時(shí)間的推移測試變得更加復(fù)雜等。下面就利用第一種評估方法來進(jìn)行舉例。24對測試工作的評估不同的測試階段有不同的測試重點(diǎn)。例如在功能測試階段，所對應(yīng)的activity就是FunctionTest(功能測試)。而在系統(tǒng)測試階段，所對應(yīng)的activity就是SystemTest（系統(tǒng)測試）。我們可以通過統(tǒng)計(jì)在每種測試階段中發(fā)現(xiàn)缺陷的activity來判斷是否本應(yīng)在該測試階段中發(fā)現(xiàn)的缺陷被遺留到了下一測試階段。以此來評估測試工作的完成情況。如圖

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