● 缺陷的定義
→ 軟件沒有達(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)告中提出的問題很難重現(xiàn)
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ù)
方正測(cè)試缺陷跟蹤與管理系統(tǒng)
● 采用Lotus Notes作為bug管理平臺(tái)
● 完全電子化的信息傳遞
● 統(tǒng)一管理和備份

具備數(shù)據(jù)統(tǒng)計(jì)和查詢功能
能夠進(jìn)行個(gè)性化二次開發(fā)

1.1 系統(tǒng)測(cè)試缺陷處理流程

缺陷報(bào)告
● 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)象難以捕捉
→ 沒有明確的報(bào)告以說明重現(xiàn)bug的步驟
→ 程序員無法讀懂的bug報(bào)告
→ 用戶很少使用或者不符合用戶使用習(xí)慣的操作出錯(cuò)
→ 由不受信任的測(cè)試人員提出
1.2 集成測(cè)試缺陷處理流程

● 缺陷分析的關(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)件)中。
2、對(duì)bug的注入階段的分布進(jìn)行分析,并與歷史數(shù)據(jù)相比較。應(yīng)按不同的開發(fā)階段詳細(xì)采集bug的數(shù)據(jù)
→ 要求軟件各開發(fā)階段的缺陷密度小于本單位過去的平均值
→ 而且要求需求分析、設(shè)計(jì)和代碼復(fù)查階段的缺陷排除率之和大于或等于規(guī)定值(例如75%)。(同行評(píng)審)
3、應(yīng)對(duì)軟件缺陷類型進(jìn)行分析,以便針對(duì)各自的特點(diǎn),先修復(fù)嚴(yán)重缺陷。
→ 可參考PSP中缺陷類型標(biāo)準(zhǔn)(如下表),其中缺陷類型是按照問題的復(fù)雜度來排列的,類型10到40是比較簡(jiǎn)單的編碼缺陷,類型50到100是比較復(fù)雜的設(shè)計(jì)缺陷。

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ā)人員的工作情況
6、應(yīng)該采集bug不同方式的修復(fù)數(shù)據(jù),以便檢驗(yàn)軟件產(chǎn)品是否滿足交付規(guī)則
→ 分析修改代碼、改變?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à)值的參考。
● 測(cè)試人員的績(jī)效評(píng)價(jià)
→ 評(píng)價(jià)標(biāo)準(zhǔn):
1、bug數(shù)量:
同一個(gè)項(xiàng)目組內(nèi),提交bug數(shù)量的多少是衡量測(cè)試人員工作效率的一方面;另一個(gè)衡量指標(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ī)效!
缺陷統(tǒng)計(jì)分析工具介紹

●測(cè)試結(jié)果分析和評(píng)價(jià)
缺陷密度:
→ 基本的缺陷測(cè)量是以每千行代碼的缺陷數(shù)(Defects/KLOC)來測(cè)量的。稱為缺陷密度(Dd),其測(cè)量單位是defects/KLOC。可按照以下步驟來計(jì)算一個(gè)程序的缺陷密度:
→ 累計(jì)開發(fā)過程中每個(gè)階段發(fā)現(xiàn)的缺陷總數(shù)(D)。
→ 統(tǒng)計(jì)程序中新開發(fā)的和修改的代碼; height:28px;">