三、基于測(cè)試流程上的缺陷管理系統(tǒng)

1、三、基于測(cè)試流程上的缺陷管理系統(tǒng),缺陷的定義軟件沒有達(dá)到產(chǎn)品說明書表明的功能軟件出現(xiàn)了產(chǎn)品說明書中不一致的表現(xiàn)軟件功能超出產(chǎn)品說明書的范圍軟件沒有達(dá)到用戶期望的目標(biāo)(雖然產(chǎn)品說明書中沒有要求)測(cè)試員或用戶認(rèn)為軟件的易用性差不是所有缺陷都會(huì)修改市場(chǎng)的壓力使得產(chǎn)品最終發(fā)行有時(shí)間限制測(cè)試員錯(cuò)誤理解或者不正確操作引出的缺陷(FAQ)錯(cuò)誤的修改影響的模塊較多，帶來的風(fēng)險(xiǎn)較大（遺留）修改性價(jià)比太低(FAQ，遺留）缺陷報(bào)告中提出

2、的問題很難重現(xiàn),Founder R&D,3.1 缺陷報(bào)告管理系統(tǒng),是測(cè)試流程在工具上的固化通過權(quán)限控制來實(shí)現(xiàn)流程監(jiān)控記錄了缺陷識(shí)別到關(guān)閉過程中的所有數(shù)記錄了版本變更的信息是開發(fā)和測(cè)試之間溝通的信息平臺(tái)實(shí)時(shí)的數(shù)據(jù)和信息的更新度量和統(tǒng)計(jì)分析，為改進(jìn)產(chǎn)品提供依據(jù),Founder R&D,Founder R&D,采用Lotus Notes作為bug管理平臺(tái)完全電子化的信息傳遞統(tǒng)一管理和備份,具備數(shù)據(jù)統(tǒng)計(jì)和

3、查詢功能能夠進(jìn)行個(gè)性化二次開發(fā),方正測(cè)試缺陷跟蹤與管理系統(tǒng),3.1.1 系統(tǒng)測(cè)試缺陷處理流程,Founder R&D,Bug報(bào)告準(zhǔn)則如何重現(xiàn)錯(cuò)誤-使用最少步驟重現(xiàn)現(xiàn)象描述沒有歧義盡量簡(jiǎn)單-一個(gè)bug一個(gè)報(bào)告可以提出對(duì)錯(cuò)誤的解決建議開發(fā)人員拒絕修改的bug程序員無法重現(xiàn)或者現(xiàn)象難以捕捉?jīng)]有明確的報(bào)告以說明重現(xiàn)bug的步驟程序員無法讀懂的bug報(bào)告用戶很少使用或者不符合用戶使用習(xí)慣的操作出錯(cuò)由不受信任的測(cè)試人

4、員提出,缺陷報(bào)告,Founder R&D,3.1.2 集成測(cè)試缺陷處理流程,Founder R&D,4.1 缺陷分析的關(guān)注點(diǎn)：,1、對(duì)軟件問題的功能域分布進(jìn)行分析，找出系統(tǒng)的薄弱環(huán)節(jié)要詳細(xì)采集每個(gè)功能模塊或系統(tǒng)構(gòu)件的bug數(shù)據(jù)，并按功能、錯(cuò)誤類型、嚴(yán)重程度等分類比較實(shí)際發(fā)現(xiàn)的軟件bug是否與預(yù)期的問題分布相吻合二八定理：80%的軟件問題總是發(fā)生在大約20%的功能模塊（系統(tǒng)構(gòu)件）中。,Founder R&D,

5、缺陷分析的關(guān)注點(diǎn),2、對(duì)bug的注入階段的分布進(jìn)行分析，并與歷史數(shù)據(jù)相比較。應(yīng)按不同的開發(fā)階段詳細(xì)采集bug的數(shù)據(jù)要求軟件各開發(fā)階段的缺陷密度小于本單位過去的平均值而且要求需求分析、設(shè)計(jì)和代碼復(fù)查階段的缺陷排除率之和大于或等于規(guī)定值（例如75%）。（同行評(píng)審）,Founder R&D,Founder R&D,缺陷分析的關(guān)注點(diǎn),3、應(yīng)對(duì)軟件缺陷類型進(jìn)行分析，以便針對(duì)各自的特點(diǎn)，先修復(fù)嚴(yán)重缺陷?？蓞⒖糚SP中缺陷類

6、型標(biāo)準(zhǔn)（如下表），其中缺陷類型是按照問題的復(fù)雜度來排列的，類型10到40是比較簡(jiǎn)單的編碼缺陷，類型50到100是比較復(fù)雜的設(shè)計(jì)缺陷。,缺陷分析的關(guān)注點(diǎn),4、應(yīng)動(dòng)態(tài)采集每個(gè)測(cè)試周期中發(fā)現(xiàn)的bug數(shù)，并有效地控制缺陷的修復(fù)率。5、應(yīng)密切觀察bug的狀態(tài)，并及時(shí)跟蹤其狀態(tài)的變化，以檢查測(cè)試和開發(fā)人員的工作情況,Founder R&D,缺陷分析的關(guān)注點(diǎn),6、應(yīng)該采集bug不同方式的修復(fù)數(shù)據(jù)，以便檢驗(yàn)軟件產(chǎn)品是否滿足交付規(guī)則分析修改

7、代碼、改變?cè)O(shè)計(jì)、封掉功能遺留以及下一版本解決的bug數(shù)約占缺陷總數(shù)的比例。在有嚴(yán)密和有效的質(zhì)量保證體系條件的監(jiān)控下，常常會(huì)引起有較高比例的延期解決的缺陷數(shù)，這是因?yàn)樵S多細(xì)微的或枝節(jié)性的問題被測(cè)試出來，經(jīng)過評(píng)價(jià)證明不會(huì)造成大的質(zhì)量影響，但可為產(chǎn)品進(jìn)一步升級(jí)提供有價(jià)值的參考。,Founder R&D,4.2 測(cè)試人員的績(jī)效評(píng)價(jià),評(píng)價(jià)標(biāo)準(zhǔn)：1、bug數(shù)量：同一個(gè)項(xiàng)目組內(nèi)，提交bug數(shù)量的多少是衡量測(cè)試人員工作效率的一方面；另一個(gè)

8、衡量指標(biāo)是每人日提交的bug數(shù)。2、bug嚴(yán)重程度：Bug的嚴(yán)重程度是衡量bug的質(zhì)量的一個(gè)重要因素，好的bug應(yīng)該是極端嚴(yán)重的，對(duì)系統(tǒng)造成極大危害的。3、bug價(jià)值：Bug的雙方面評(píng)判，對(duì)于bug的價(jià)值開發(fā)人員在另外一個(gè)角度上進(jìn)行評(píng)判以上三個(gè)因素的加權(quán)平均才能更有效的評(píng)價(jià)測(cè)試人員的績(jī)效！,Founder R&D,4.3 缺陷統(tǒng)計(jì)分析工具介紹,Founder R&D,測(cè)試結(jié)果分析和評(píng)價(jià),缺陷密度:基本的缺

9、陷測(cè)量是以每千行代碼的缺陷數(shù)(Defects/KLOC)來測(cè)量的。稱為缺陷密度(Dd)，其測(cè)量單位是defects／KLOC。可按照以下步驟來計(jì)算一個(gè)程序的缺陷密度：累計(jì)開發(fā)過程中每個(gè)階段發(fā)現(xiàn)的缺陷總數(shù)(D)。統(tǒng)計(jì)程序中新開發(fā)的和修改的代碼行數(shù)(N)。計(jì)算每千行的缺陷數(shù)Dd=1000*D/N。例如，一個(gè)29.6萬(wàn)行的源程序總共有145個(gè)缺陷，則缺陷密度是：Dd＝1000*145/296000=0.49 defects／KLOC

10、。在計(jì)算缺陷密度時(shí)，最重要的是要使用正確的規(guī)模測(cè)量。,Founder R&D,測(cè)試結(jié)果的分析和評(píng)價(jià),輸出《測(cè)試綜合報(bào)告》：測(cè)試過程的總結(jié)測(cè)試數(shù)據(jù)分析（按照嚴(yán)重程度等方式分類統(tǒng)計(jì)的分析，包括測(cè)試密度等）產(chǎn)品主要問題和總體評(píng)價(jià)遺留的問題總結(jié)最終的測(cè)試結(jié)論,Founder R&D,測(cè)試結(jié)果分析和評(píng)價(jià),為了了解和控制缺陷帶來的費(fèi)用，很有必要測(cè)量缺陷排除的效果測(cè)量：一種測(cè)量方法是計(jì)算每小時(shí)排除缺陷的個(gè)數(shù)；一種是計(jì)算

11、缺陷排除效益，即測(cè)量通過某一排除方法所發(fā)現(xiàn)的缺陷的百分比。,缺陷排除效益是45%,,100個(gè)缺陷,開始測(cè)試,,,測(cè)試,,發(fā)現(xiàn)45個(gè)缺陷,,missing 55 defects,,Founder R&D,測(cè)試結(jié)果分析和評(píng)價(jià),測(cè)試覆蓋率測(cè)量語(yǔ)句覆蓋率測(cè)試經(jīng)歷語(yǔ)句數(shù)/總語(yǔ)句數(shù)分支覆蓋率測(cè)試經(jīng)歷支路數(shù)/總支路數(shù)簡(jiǎn)單路徑覆蓋率測(cè)試經(jīng)歷簡(jiǎn)單路徑數(shù)/總簡(jiǎn)單路徑數(shù)功能覆蓋率界面數(shù)菜單數(shù)輸入/輸出的數(shù)據(jù)元數(shù)構(gòu)件、模塊

12、…,Founder R&D,4.5軟件測(cè)試經(jīng)驗(yàn)分享,所有的測(cè)試都應(yīng)追溯到需求。因最嚴(yán)重的錯(cuò)誤是導(dǎo)致程序無發(fā)滿足需求的錯(cuò)誤；軟件開發(fā)人員和管理人員首先應(yīng)該盡早地和不斷地進(jìn)行各種軟件質(zhì)量保證活動(dòng)（如需求和設(shè)計(jì)階段同行評(píng)審和走查等）;軟件開發(fā)人員應(yīng)避免檢查自已的程序，利用同行評(píng)審的方式對(duì)代碼進(jìn)行審查；(自己檢查容易依照原有的程序設(shè)計(jì)思路進(jìn)行，往往查不出問題)在設(shè)計(jì)測(cè)試用例時(shí)，必須明確預(yù)期的輸出結(jié)果，否則對(duì)實(shí)際的輸出結(jié)果很

13、難有檢驗(yàn)的標(biāo)準(zhǔn)，測(cè)試失去意義。測(cè)試用例應(yīng)由輸入數(shù)據(jù)和與之對(duì)應(yīng)的期望輸出結(jié)果這兩部分組成，在輸入數(shù)據(jù)中，應(yīng)當(dāng)包括合理的輸入條件和不合理的輸入條件；在進(jìn)行各種分析和修復(fù)工作中，要充分注意修復(fù)工作所產(chǎn)生的影響效果和波及效果。,Founder R&D,軟件測(cè)試經(jīng)驗(yàn)分享,統(tǒng)計(jì)表明大約有60%的錯(cuò)誤是在設(shè)計(jì)階段之前注入的，并且修正一個(gè)軟件錯(cuò)誤所需的費(fèi)用將隨著軟件生存期的進(jìn)展而上升。錯(cuò)誤發(fā)現(xiàn)得越晚，修復(fù)它的費(fèi)用就越高，而且呈指數(shù)增長(zhǎng)的趨勢(shì)

14、。測(cè)試后程序中殘存的錯(cuò)誤數(shù)目與該程序中已發(fā)現(xiàn)的錯(cuò)誤數(shù)目（即檢錯(cuò)率）很可能成正比；(編碼規(guī)范、需求理解、技術(shù)能力、內(nèi)部耦合性是引起這些現(xiàn)象的原因)程序中的大部分錯(cuò)誤往往是在一小部分模塊中發(fā)現(xiàn)的，遵循普遍適用的“二八定理”（即80%的錯(cuò)誤往往是由20%的模塊所造成的），例如，IBM公司的OS/370操作系統(tǒng)中，47% 的錯(cuò)誤僅與該系統(tǒng)中的4%的程序模塊有關(guān)；要嚴(yán)格執(zhí)行測(cè)試計(jì)劃，排除測(cè)試的隨意性，這樣才能消除各種無序操作所造成的副

15、作用；測(cè)試設(shè)計(jì)決定了測(cè)試的有效性和效率，測(cè)試工具只能提高測(cè)試效率應(yīng)當(dāng)對(duì)每一個(gè)測(cè)試結(jié)果做全面的檢查，這樣才有可能找到真正的出錯(cuò)原因，為今后的調(diào)試工作奠定基礎(chǔ)。,Founder R&D,結(jié)束語(yǔ),產(chǎn)品越復(fù)雜，測(cè)試花費(fèi)的時(shí)間就越長(zhǎng)，費(fèi)用就越大，測(cè)試發(fā)現(xiàn)缺陷的效率也就越低。缺陷會(huì)掩蓋或加重其它缺陷。也就是說，當(dāng)一個(gè)程序有許多缺陷時(shí)，由于缺陷相互作用，使得發(fā)現(xiàn)和修復(fù)缺陷的過程更加復(fù)雜。這使得一些缺陷很難查找和修復(fù)。一個(gè)缺陷可能掩蓋其它