有效缺陷分類管理_第1頁
有效缺陷分類管理_第2頁
有效缺陷分類管理_第3頁
有效缺陷分類管理_第4頁
有效缺陷分類管理_第5頁
已閱讀5頁,還剩30頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

缺陷的有效管理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ā)明完成基本理論體系建設ODC:OrthogonalDefectClassification正交缺陷分類法5/24軟件缺陷:指的是軟件工作產(chǎn)品的不足或不完美之處。軟件工作產(chǎn)品:指的是軟件過程所創(chuàng)造的一切產(chǎn)物,包括計算機程序、計劃、流程、及所有相關(guān)的文檔和數(shù)據(jù)。軟件過程:是人們用以開發(fā)和維護軟件工作產(chǎn)品的一系列活動、方法、實踐和轉(zhuǎn)換。

軟件故障:指的是軟件缺陷在一定的輸入條件下被激活的結(jié)果,它在無適當容錯措施的情況下造成失效。軟件失效:指的是軟件執(zhí)行過程中系統(tǒng)行為與用戶需求的偏離。何謂正交?0xXYZXY正交缺陷分類法ODC在高層次上,是幫助獲取缺陷信息的一個缺陷分類方案。它不僅僅是一個分類方法,ODC是一個軟件過程的度量系統(tǒng),它是建立在包含于缺陷流中的語義信息基礎(chǔ)上的。它可以幫助我們評估測試的效力和效率,可以進行錯誤跟蹤,通過ODC背后的分析機制評估顧客的滿意度。6什么是ODC?ODC技術(shù):結(jié)合了根原因分析和統(tǒng)計建模(StatisticalModeling)兩種軟件缺陷分析技術(shù)的優(yōu)勢。提供了一套用于捕獲缺陷數(shù)據(jù)關(guān)鍵特性的方案,并給出對分類的缺陷數(shù)據(jù)集進行分析的指導??梢詭椭覀?nèi)媪私馊毕?,從而采取最有效的措施來改進軟件開發(fā)過程中的不足,不斷地提高軟件產(chǎn)品質(zhì)量。ODC統(tǒng)計分析可以:準確確定產(chǎn)品主要質(zhì)量問題區(qū)域識別缺陷引入和去除過程的重點改進對象實現(xiàn)對過程和產(chǎn)品的精確改進指導7/24正交缺陷分類法適用對象開發(fā)生命周期相對來說是一個很漫長的過程,包括后續(xù)的改進工作。例如,這個項目包括多個軟件版本或者一個版本有多次迭代。潛在的缺陷數(shù)目是相當大的。缺陷數(shù)目越多,客觀的分析結(jié)果也越多,對了解軟件質(zhì)量越有好處。這個項目已經(jīng)將“高可靠”設定為它的主要目標之一。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年提出。它通過給每個缺陷添加一些額外的屬性,利用對這些屬性的歸納和分析,來反映出產(chǎn)品的設計、代碼質(zhì)量、測試水平等各方面的問題。從而得到一些解決辦法來進行改進。ODC的工作流程分為四部分:“缺陷分類”,“校驗已被分類的缺陷”,“評估數(shù)據(jù)”以及“采取行動來改進工作”。下面我們將逐一進行講解。缺陷分類16/24分類,是ODC工作流程中的第一步,即需要測試和開發(fā)人員分別對每一個缺陷填寫ODC屬性。對于團隊成員來說,正確的了解每個屬性的值尤為重要,這樣才能保證他們在分類時盡量選擇正確的選項。在填寫之前,需要缺陷管理工具進行改進,配置額外的屬性。常用的缺陷管理工具包括ClearQuest(CQ)和ConfigurationManagementVersionControl(CMVC)等。需要增加的8個ODC相關(guān)屬性分別是:Activity:表示在做哪種測試時發(fā)現(xiàn)的缺陷。Trigger;表示采取哪種方式觸發(fā)的該缺陷,不同的activity對應不同的trigger類型;Impact:表示該缺陷的發(fā)生會對客戶造成的影響;缺陷分類17/24Target:表示開發(fā)人員為了修復這個缺陷,需要在哪方面做修改。比如可以修改的方面包括:產(chǎn)品設計、相應的代碼和文檔等;DefectType:缺陷類型;Qualifier:表示該缺陷是由于丟失相關(guān)代碼、還是代碼不正確造成的?;蛘呤怯捎诘谌教峁┑拇a造成的;Source:表示該缺陷的來源是由于內(nèi)部編寫的代碼引起的問題,還是由外包公司提供的代碼引起的等;Age:表示該缺陷是由新代碼產(chǎn)生的還是由于修改其它缺陷而引發(fā)的,或是在上一個發(fā)布版本中就已經(jīng)有的問題等;(ContentType:表示修復文檔的類型。僅對文檔類的缺陷有效。)測試人員進行分類從下圖

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

校驗員在校驗完某個缺陷并確認相關(guān)人員已經(jīng)完成修改后,校驗工作還并沒有結(jié)束。為了在下一階段,即評估階段中,僅僅對已被校驗過的缺陷進行分析,就需要在缺陷管理工具中有地方進行標識,用以過濾掉未校驗過的缺陷。22評估階段在確保輸入的ODC數(shù)據(jù)正確性的前提下,就可以對這些缺陷進行分析了。根據(jù)ODC的不同屬性進行分類統(tǒng)計,可得出不同方面的結(jié)論。以此來反映測試、開發(fā)或產(chǎn)品設計方面的問題,指出潛在的改進的機會。比如:缺陷被發(fā)現(xiàn)的如何、產(chǎn)品是否穩(wěn)定等。下面選擇測試工作的評估方法進行說明。23對測試工作的評估利用不同的ODC屬性的組合,可以從多方面來評估測試工作的完成情況。例如利用測試階段和activity屬性來評估是否應在某一測試階段中發(fā)現(xiàn)的缺陷卻被在下一測試階段中才發(fā)現(xiàn);利用activity和trigger屬性來評估是否每個activity都使用了足夠多的與之對應的trigger來發(fā)現(xiàn)缺陷;利用時間和trigger屬性來評估是否隨著時間的推移測試變得更加復雜等。下面就利用第一種評估方法來進行舉例。24對測試工作的評估不同的測試階段有不同的測試重點。例如在功能測試階段,所對應的activity就是FunctionTest(功能測試)。而在系統(tǒng)測試階段,所對應的activity就是SystemTest(系統(tǒng)測試)。我們可以通過統(tǒng)計在每種測試階段中發(fā)現(xiàn)缺陷的activity來判斷是否本應在該測試階段中發(fā)現(xiàn)的缺陷被遺留到了下一測試階段。以此來評估測試工作的完成情況。如圖

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

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論