1.缺陷標(biāo)識(shí)(Identifier): 缺陷標(biāo)識(shí)是標(biāo)記某個(gè)缺陷的一組符號(hào)。每個(gè)缺陷必須有一個(gè)唯一的標(biāo)識(shí)。
2.缺陷類型 (Type): 缺陷類型是根據(jù)缺陷的自然屬性劃分的缺陷種類。
3.缺陷嚴(yán)重程度 (Severity) :缺陷嚴(yán)重程度是指因缺陷引起的故障對(duì)軟件產(chǎn)品的影響程度。
4.缺陷優(yōu)先級(jí)(Priority): 缺陷的優(yōu)先級(jí)指缺陷必須被修復(fù)的緊急程度。
5.缺陷狀態(tài)(Status) :缺陷狀態(tài)指缺陷通過(guò)一個(gè)跟蹤修復(fù)過(guò)程的進(jìn)展情況。
6.缺陷起源(Origin) :缺陷來(lái)源指缺陷引起的故障或事件第一次被檢測(cè)到的階段。
7.缺陷來(lái)源(Source): 缺陷來(lái)源指引起缺陷的起因。
8.缺陷根源(Root Cause): 缺陷根源指發(fā)生錯(cuò)誤的根本因素。 F- Function :影響了重要的特性、用戶界面、產(chǎn)品接口、硬件結(jié)構(gòu)接口和全局?jǐn)?shù)據(jù)結(jié)構(gòu)。并且設(shè)計(jì)文檔需要正式的變更。如邏輯,指針,循環(huán),遞歸,功能等缺陷。
A- Assignment: 需要修改少量代碼,如初始化或控制塊。如聲明、重復(fù)命名,范圍、限定等缺陷。
I- Interface: 與其他組件、模塊或設(shè)備驅(qū)動(dòng)程序、調(diào)用參數(shù)、控制塊或參數(shù)列表相互影響的缺陷。
C- Checking: 提示的錯(cuò)誤信息,不適當(dāng)?shù)臄?shù)據(jù)驗(yàn)證等缺陷。
B Build/package/merge :由于配置庫(kù)、變更管理或版本控制引起的錯(cuò)誤。
D- Documentation: 影響發(fā)布和維護(hù),包括注釋。
G- Algorithm :算法錯(cuò)誤。
U-User Interface:人機(jī)交互特性:屏幕格式,確認(rèn)用戶輸入,功能有效性,頁(yè)面排版等方面的缺陷。
P-Performance:不滿足系統(tǒng)可測(cè)量的屬性值,如:執(zhí)行時(shí)間,事務(wù)處理速率等。
N-Norms:不符合各種標(biāo)準(zhǔn)的要求,如編碼標(biāo)準(zhǔn)、設(shè)計(jì)符號(hào)等。 軟件測(cè)試錯(cuò)誤嚴(yán)重程度
1.Critical:不能執(zhí)行正常工作功能或重要功能。或者危及人身安全。
2.Major:嚴(yán)重地影響系統(tǒng)要求或基本功能的實(shí)現(xiàn),且沒(méi)有辦法更正。(重新安裝或重新啟動(dòng)該軟件不屬于更正辦法)
3.Minor:嚴(yán)重地影響系統(tǒng)要求或基本功能的實(shí)現(xiàn),但存在合理的更正辦法。(重新安裝或重新啟動(dòng)該軟件不屬于更正辦法)
4.Cosmetic:使操作者不方便或遇到麻煩,但它不影響執(zhí)行工作功能或重要功能。
5.Other:其它錯(cuò)誤。
同行評(píng)審錯(cuò)誤嚴(yán)重程度
1.Major:主要的,較大的缺陷
2.Minor:次要的,小的缺陷 1.Resolve Immediately:缺陷必須被立即解決。
2.Normal Queue:缺陷需要正常排隊(duì)等待修復(fù)或列入軟件發(fā)布清單。
3.Not Urgent:缺陷可以在方便時(shí)被糾正。 1.Submitted: 已提交的缺陷
2.Open :確認(rèn)“提交的缺陷”,等待處理
3.Rejected: 拒絕“提交的缺陷”,不需要修復(fù)或不是缺陷
4.Resolved :缺陷被修復(fù)
5.Closed :確認(rèn)被修復(fù)的缺陷,將其關(guān)閉 1.Requirement:在需求階段發(fā)現(xiàn)的缺陷
2.Architecture:在構(gòu)架階段發(fā)現(xiàn)的缺陷
3.Design:在設(shè)計(jì)階段發(fā)現(xiàn)的缺陷
4.Code:在編碼階段發(fā)現(xiàn)的缺陷
5.Test:在測(cè)試階段發(fā)現(xiàn)的缺陷 1.Requirement: 由于需求的問(wèn)題引起的缺陷
2.Architecture: 由于構(gòu)架的問(wèn)題引起的缺陷
3.Design: 由于設(shè)計(jì)的問(wèn)題引起的缺陷
4.Code: 由于編碼的問(wèn)題引起的缺陷
5.Test: 由于測(cè)試的問(wèn)題引起的缺陷
6.Integration: 由于集成的問(wèn)題引起的缺陷
一般我們都認(rèn)為測(cè)出一個(gè)問(wèn)題就是一個(gè)bug,其實(shí)這是不對(duì)的,假設(shè)測(cè)試10個(gè)問(wèn)題就10個(gè)bug,而修改一出就全解決了,程序員肯定認(rèn)為冤枉自己。
所有軟件是文檔,代碼等組成的,最初的錯(cuò)誤是來(lái)自于這些軟件錯(cuò)誤(software error),如代碼中加法寫(xiě)成減法。軟件錯(cuò)誤導(dǎo)致軟件缺陷(software defect),如設(shè)計(jì)缺陷,代碼缺陷等,可用靜態(tài)測(cè)試,如走查,靜態(tài)檢查,測(cè)試床(軍事軟件用的技術(shù))等,軟件的缺陷導(dǎo)致一個(gè)或多個(gè)軟件故障 (software fault),故障有內(nèi)部故障,外部故障,也就是我們所說(shuō)的bug,軟件故障導(dǎo)致了軟件在功能操作等方面的失效(software failure)。
我們平時(shí)測(cè)的bug實(shí)際上是軟件故障于失效的體現(xiàn)。一旦軟件錯(cuò)誤得到修改,相應(yīng)的故障與失效也就解除了。這樣分有助于我們定位問(wèn)題,找到問(wèn)題。
1、ODC缺陷分析:由IBM 的waston中心推出。
Phontol.com將一個(gè)缺陷在生命周期的各環(huán)節(jié)的屬性組織起來(lái),從單維度、多維度來(lái)對(duì)缺陷進(jìn)行分析,從不同角度得到各類缺陷的缺陷密度和缺陷比率,從而積累得到各類缺陷的基線值,用于評(píng)估測(cè)試活動(dòng)、指導(dǎo)測(cè)試改進(jìn)和整個(gè)研發(fā)流程的改進(jìn);同時(shí)根據(jù)各階段缺陷分布得到缺陷去除過(guò)程特征模型,用于對(duì)測(cè)試活動(dòng)進(jìn)行評(píng)估和預(yù)測(cè)。Phontol.com上面回答中涉及到的缺陷分布、缺陷趨勢(shì)等都屬于這個(gè)方法中的一個(gè)角度而已。
2、Gompertz分析:根據(jù)測(cè)試的累積投入時(shí)間和累積缺陷增長(zhǎng)情況,擬合得到符合自己過(guò)程能力的缺陷增長(zhǎng)Gompertz曲線,用來(lái)評(píng)估軟件測(cè)試的充分性、預(yù)測(cè)軟件極限缺陷數(shù)和退出測(cè)試所需時(shí)間、作為測(cè)試退出的判斷依據(jù)、指導(dǎo)測(cè)試計(jì)劃和策略的調(diào)整; 3、Rayleigh分析:通過(guò)生命周期各階段缺陷發(fā)現(xiàn)情況得到缺陷Rayleigh曲線,用于評(píng)估軟件質(zhì)量、預(yù)測(cè)軟件現(xiàn)場(chǎng)質(zhì)量; 4、四象限分析:根據(jù)軟件內(nèi)部各模塊、子系統(tǒng)、特性測(cè)試所累積時(shí)間和缺陷去除情況,和累積時(shí)間和缺陷去除情況的基線進(jìn)行比較,得到各個(gè)模塊、子系統(tǒng)、特性測(cè)試分別所位于的區(qū)間,從而判斷哪些部分測(cè)試可以退出、哪些測(cè)試還需加強(qiáng),用于指導(dǎo)測(cè)試計(jì)劃和策略的調(diào)整; 5、根本原因分析:利用魚(yú)骨圖、柏拉圖等分析缺陷產(chǎn)生的根本原因,根據(jù)這些根本原因采取措施,改進(jìn)開(kāi)發(fā)和測(cè)試過(guò)程; 6、缺陷注入分析:對(duì)被測(cè)軟件注入一些缺陷,通過(guò)已有用例進(jìn)行測(cè)試,根據(jù)這些刻意注入缺陷的發(fā)現(xiàn)情況,判斷測(cè)試的有效性、充分性,預(yù)測(cè)軟件殘留缺陷數(shù)。 7、DRE/DRM分析:通過(guò)已有項(xiàng)目歷史數(shù)據(jù),得到軟件生命周期各階段缺陷注入和排除的模型,用于設(shè)定各階段質(zhì)量目標(biāo),評(píng)估測(cè)試活動(dòng)。
簡(jiǎn)單說(shuō)下軟件缺陷的最明顯的特征吧知
集結(jié)(二八定理)
缺陷往往喜歡扎堆,一個(gè)模塊已經(jīng)發(fā)現(xiàn)的缺陷比別的模塊多,
通常不是代表這個(gè)模塊已經(jīng)把缺陷暴露完了,而是意味著這
個(gè)模塊還存在有同樣多的缺陷尚未被道發(fā)現(xiàn)。這就是著名的二
八定理:80%的缺陷出現(xiàn)在 20%的模塊。
缺陷抗藥性
測(cè)試進(jìn)行得越多,新缺陷就越難被發(fā)現(xiàn)
1. 因?yàn)橹耙恢笔褂猛瑯拥臏y(cè)試思內(nèi)路,同樣的一套測(cè)試用
例,沒(méi)有新的突破。
2. 某些缺陷天然地只有在很特殊或者很極端的情況下才會(huì)
被觸發(fā)
并非所有缺陷都要修改
p有一些原因,使得有容些缺陷我們不修復(fù)
1. 修復(fù)的風(fēng)險(xiǎn)太大
2. 沒(méi)有足夠的時(shí)間
3. 下一版本修復(fù)
p 所有未修復(fù)的bug都處于“掛起”狀態(tài)
一般我們都認(rèn)為測(cè)出一個(gè)問(wèn)題就是一個(gè)bug,其實(shí)這是不對(duì)的,假設(shè)測(cè)試10個(gè)問(wèn)題就10個(gè)bug,而修改一出就全解決了,程序員肯定認(rèn)為冤枉自己。
所有軟件是文檔,代碼等組成的,最初的錯(cuò)誤是來(lái)自于這些軟件錯(cuò)誤(software error),如代碼中加法寫(xiě)成減法。軟件錯(cuò)誤導(dǎo)致軟件缺陷(software defect),如設(shè)計(jì)缺陷,代碼缺陷等,可用靜態(tài)測(cè)試,如走查,靜態(tài)檢查,測(cè)試床(軍事軟件用的技術(shù))等,軟件的缺陷導(dǎo)致一個(gè)或多個(gè)軟件故障 (software fault),故障有內(nèi)部故障,外部故障,也就是我們所說(shuō)的bug,軟件故障導(dǎo)致了軟件在功能操作等方面的失效(software failure)。
我們平時(shí)測(cè)的bug實(shí)際上是軟件故障于失效的體現(xiàn)。一旦軟件錯(cuò)誤得到修改,相應(yīng)的故障與失效也就解除了。
這樣分有助于我們定位問(wèn)題,找到問(wèn)題。

聲明:本網(wǎng)站尊重并保護(hù)知識(shí)產(chǎn)權(quán),根據(jù)《信息網(wǎng)絡(luò)傳播權(quán)保護(hù)條例》,如果我們轉(zhuǎn)載的作品侵犯了您的權(quán)利,請(qǐng)?jiān)谝粋€(gè)月內(nèi)通知我們,我們會(huì)及時(shí)刪除。
蜀ICP備2020033479號(hào)-4 Copyright ? 2016 學(xué)習(xí)鳥(niǎo). 頁(yè)面生成時(shí)間:3.063秒