?
Bug 生命周期
?
對 Bug 的處理
開發(fā)組長
/
經(jīng)理
每天對
Bug
進行分配,標注處理意見,給定優(yōu)先級(發(fā)版前必須三方:需求、開發(fā)、產(chǎn)品共同確定)。問題分配時,應盡可能將咨詢類、理解錯誤類等問題處理掉,而不是留給開發(fā)人員。有可能是需求的問題,分配給需求人員。定期對
Bug
庫分析,找出常出錯的模塊,進行代碼審查
開發(fā)人員
分析
Bug
,寫出問題原因,修改
Bug
;實行
Bug
優(yōu)先原則,嚴重程度
B-Major
類或緊急程度
3-High
類以上(包含)
bug5
個或
5
個以上,停止新功能的開發(fā)。
需求人員
解釋需求,給出處理意見,將
Bug
庫中的建議整理成需求文檔。評審確定后列入開發(fā)計劃
測試人員
不參與問題的優(yōu)先級的定位,只用
Bug
級別反映
Bug
的嚴重程度。驗證
Bug
是否已被解決
測試組長
/
經(jīng)理
審核測試人員提交的
Bug
。定期對
Bug
庫進行分析,描繪出曲線圖等,報告現(xiàn)狀、預測趨勢。在測試總結(jié)報告中給出意見
產(chǎn)品人員
可以對優(yōu)先級和處理意見等進行審核,如果有意見,和項目組商量定奪
Bug 狀態(tài) (Status) :指缺陷通過一個跟蹤修復過程的進展情況。包括 New 、 Open 、 Reopen 、 Fixed 、 Closed 及 Rejected 等
New |
為測試人員新問題提交所標志的狀態(tài)。 |
Open |
為任務分配人(開發(fā)組長 / 經(jīng)理)對該問題準備進行修改并對該問題分配修改人員所標志的狀態(tài)。 Bug 解決中的狀態(tài),由任務分配人改變。對沒有進入此狀態(tài)的 Bug ,程序員不用管。 |
Reopen |
為測試人員對修改問題進行驗證后沒有通過所標志的狀態(tài);或者已經(jīng)修改正確的問題,又重新出現(xiàn)錯誤。由測試人員改變。 |
Fixed |
為開發(fā)人員修改問題后所標志的狀態(tài),修改后還未測試。 |
Closed |
為測試人員對修改問題進行驗證后通過所標志的狀態(tài)。由測試人員改變。 |
Rejected |
開發(fā)人員認為不是 Bug 、描述不清、重復、不能復現(xiàn)、不采納所提意見建議、或雖然是個錯誤但還沒到非改不可的地步故可忽略不計、或者測試人員提錯,從而拒絕的問題。由 Bug 分配人或者開發(fā)人員來設置。 |
Bug 嚴重級別 (Severity , Bug 級別 ) :是指因缺陷引起的故障對軟件產(chǎn)品的影響程度。由測試人員指定。
A-Crash |
錯誤導致了死機、產(chǎn)品失敗(“崩潰”)、系統(tǒng)懸掛無法操作; |
B-Major |
功能未實現(xiàn)或?qū)е乱粋€特性不能運行并且不可能有替代方案; |
C-Minor |
錯誤導致了一個特性不能運行但可有一個替代方案; |
D-Trivial |
錯誤是表面化或微小的(提示信息不太準確友好、錯別字、 UI 布局或罕見故障等),對功能幾乎沒有影響,產(chǎn)品及屬性仍可使用; |
E-Nice to Have (建議) |
建設性的意見或建議。 |
Bug 優(yōu)先級 (Priority) :指缺陷必須被修復的緊急程度。由 Bug 分配者(開發(fā)組長 / 經(jīng)理)指定。
5-Urgent |
阻止相關開發(fā)人員的進一步開發(fā)活動,立即進行修復工作;阻止與此密切相關功能的進一步測試 |
4-Very High |
必須修改,發(fā)版前必須修正 |
3-High |
必須修改,不一定馬上修改,但需確定在某個特定里程碑結(jié)束前須修正 |
2-Medium |
如果時間允許應該修改 |
1-Low |
允許不修改 |
功能模塊 (Subject) : TD 中需在 Test Plan 頁中定義好 Subject ,才能在 Defects 頁中使用。
問題描述 、 附件附圖 請參見后面第四部分‘ Bug 描述要求 ’的有關內(nèi)容。
處理意見 : 開發(fā)組長 / 經(jīng)理 ( 或具體 Bug 分配人員 ) 在審核新 Bug 時、將 Bug 分配給開發(fā)人員解決前,需要給出該 Bug 的處理意見。
Fixable |
可修改。表示 Bug 可以被修復或更正 |
Duplicated |
重復。表示該 Bug 已經(jīng)被其它測試人員找出來了(‘純粹’重復),或者開發(fā)認為原因是相同的(但從測試來看,認為出現(xiàn)的地方有所不同、表現(xiàn)有所不同等) |
Postponed |
延后。由于時間、進度、重要程度或者技術(shù)
/
需求等方面的原因,認為不能解決、須延期解決、或者本版不做留待到后續(xù)版本解決的
Bug
。
|
By Design |
因設計結(jié)構(gòu)問題無法修改。測試人員認為是 Bug ,不符合邏輯,也不符合用戶的要求,但開發(fā)人員則認為是按照設計做的、只能如此處理,否則修改代價太大 |
Can ’ t Reproduce?? |
不可復現(xiàn)。不能重現(xiàn)(如因
Bug
出現(xiàn)的環(huán)境重現(xiàn)不了了),或以前出現(xiàn)的某個
Bug
自動消失了(可能是在處理其他
Bug
的時候把這個
Bug
一并修復掉了)。
|
Disagree With Suggestion |
不同意所提意見或建議,不采納 |
Not Error |
不是問題。測試人員提錯了 |
Won ’ t Fix |
這個 Bug 是一個錯誤,但還沒有重要到非要更正不可的地步,可以忽略不計 |
說明:
1.
定為
Duplicated
的
Bug
,必須注明和
XXXbug
重復
2.
測試人員對標明為
Duplicated
的
Bug
復測,需要
XXXBug
修改后方可進行
3.
定期回顧
Can't Reproduce,Postponed
4.
定期整理
By Design
其它一些字段(及所定義的枚舉值)的定義解釋,供有需要用到的組參考:
測試狀態(tài)( TestState ) :新提交的 Bug 定位標準。由測試人員指定。一般有 8 個(提交 Bug 時給出)
1 - New Defects (或?qū)懗? Defect ) |
新 Bug |
2 - Second Defects (或?qū)懗? SB ) |
復測時新出現(xiàn)的 Bug |
3 - Faculative |
偶發(fā)性 |
4 - Reappear |
原來修改過的問題又重新出現(xiàn) |
5 - By Requirement |
需求要求但沒有做的功能 |
6 - Suggestion |
需求需要完善 |
7 - Differ With Requirement |
與需求不一致 |
8 - By Design |
設計要求但沒有做的功能 |
復測狀態(tài) (ReTestState) :復測時給出的狀態(tài),測試人員對于經(jīng)過驗證的 Bug 應按以下幾種標準進行定位。由測試人員指定。一般有 1 - OK 、 2 - PD 、 3 - DV 、 4 - NB 、 5 - NR 、 6 - AR 。
OK |
正確 |
PD |
此問題懸而不決 |
DV |
有錯誤可以暫時不考慮 |
NB |
不是錯誤 |
NR |
不能復現(xiàn)的錯誤 |
AR |
需求不明確 |
問題定位:
Calculate_error |
計算錯誤,指計算過程中、計算結(jié)果錯誤。 |
Data_error |
數(shù)據(jù)錯誤,指非計算結(jié)果類的數(shù)據(jù)錯誤。 |
Graphics_error |
圖形錯誤,指繪圖、圖形顯示、圖形編輯時發(fā)生的錯誤。 |
Interface_error |
界面錯誤 |
Requirement_error |
需求錯誤 |
Function_error |
功能錯誤 |
Unknown_error |
未知錯誤 |
缺陷來源 (Source) :指引起缺陷的起因。
Requirement |
由于需求的問題引起的缺陷 |
Architecture |
由于構(gòu)架的問題引起的缺陷 |
Design |
由于設計的問題引起的缺陷 |
Code |
由于編碼的問題引起的缺陷 |
Test |
由于測試的問題引起的缺陷 |
Integration |
由于集成的問題引起的缺陷 |
類型 (Type) :是根據(jù)缺陷的自然屬性劃分的缺陷種類。
F- Function |
影響了重要的特性、用戶界面、產(chǎn)品接口、硬件結(jié)構(gòu)接口和全局數(shù)據(jù)結(jié)構(gòu)。并且設計文檔需要正式的變更。如邏輯,指針,循環(huán),遞歸,功能等缺陷 |
A- Assignment? |
需要修改少量代碼,如初始化或控制塊。如聲明、重復命名,范圍、限定等缺陷 |
I- Interface? |
與其他組件、模塊或設備驅(qū)動程序、調(diào)用參數(shù)、控制塊或參數(shù)列表相互影響的缺陷。 |
C- Checking |
提示的錯誤信息,不適當?shù)臄?shù)據(jù)驗證等缺陷。 |
B- Build/package/merge |
由于配置庫、變更管理或版本控制引起的錯誤 |
D- Documentation? |
影響發(fā)布和維護,包括注釋。 |
G- Algorithm? |
算法錯誤。 |
U- User Interface |
人機交互特性:屏幕格式,確認用戶輸入,功能有效性,頁面排版等方面的缺陷 |
P- Performance |
不滿足系統(tǒng)可測量的屬性值,如:執(zhí)行時間,事務處理速率等。 |
N- Norms |
不符合各種標準的要求,如編碼標準、設計符號等。 |
(以上依各組實際情況可以作適當調(diào)整)
項目組各角色在 Bug 庫中的權(quán)限
管理員
:全部權(quán)限
測試組長
/
經(jīng)理
:全部權(quán)限
測試人員
:可添加
Bug
、不能刪除
Bug
、可添加注釋評論
(R&D Comments)
、不可修改他人所提
Bug
、可調(diào)整:
Bug
概要
(
題目,
Summary)
、問題描述、附件附圖
(Attachments)
、
Bug
狀態(tài)、
Bug
級別、測試版本、測試產(chǎn)品、功能模塊、測試狀態(tài)、問題定位、復測狀態(tài)、注釋評論
(R&D Comments)
、復測人、復測日期、修改人
開發(fā)人員
/
需求人員
:不能刪除
Bug
、可添加注釋評論
(R&D Comments)
、可調(diào)整:注釋評論
(R&D Comments)
、是否復現(xiàn)、
Bug
狀態(tài)(不過無法直接標為
closed
)、問題描述、處理意見、待測版本、修改人、修改日期。可添加
Bug
。
開發(fā)組長
/
經(jīng)理
/
需求經(jīng)理
:除了開發(fā)人員的權(quán)限,還可調(diào)整:優(yōu)先級別、責任人、
Bug
概要
(
題目,
Summary)
、附件附圖
(Attachments)
項目經(jīng)理
:可添加
Bug
、可添加注釋評論
(R&D Comments)
、可修改字段:
Bug
概要
(
題目,
Summary)
、問題描述、附件附圖
(Attachments)
、
Bug
狀態(tài)(不過無法直接標為
closed
)、修改人、優(yōu)先級別、問題定位、處理意見、注釋評論
(R&D Comments)
、是否復現(xiàn)、責任人、待測版本。也可刪除
Bug
,但要與測試組長
/
經(jīng)理協(xié)商。
不屬于項目組成員的其他人
如研發(fā)中心經(jīng)理組成員等,有必要查看
TD
庫的話,可分配給其帳號及查看的權(quán)限。
Bug 描述要求
Bug 描述的要求 為分類準確、敘述簡潔、步驟清楚、有實例、易再現(xiàn)、復雜問題有據(jù)可查(截圖或其它形式的附件)。測試組長 / 經(jīng)理把關,以開發(fā)人員的角度來審查 Bug 描述,看其是否描述清楚了 Bug ,不好描述的把工程文件或截圖作為附件提交。具體要求為:
- 問題描述一般格式:問題描述時,建議分幾步描述:模塊或功能點 => 測試步驟 => 期望結(jié)果 => 實際結(jié)果 => 其它信息,可依實際情況調(diào)整;
- 單一:盡量一個報告只針對一個軟件缺陷,報告形式應方便閱讀。在主報告之后應注明不同的條件;
- 簡潔:每個步驟的描述應盡可能簡潔明了。只解釋事實、演示和描述軟件缺陷必要的細節(jié),不要寫無關信息;
- 再現(xiàn):問題必須在自己機器上能復現(xiàn)方可入庫(個別嚴重問題復現(xiàn)不了也可入庫,但需標明);
- 復雜的問題應附截圖補充說明或直接通知指定的修改人;考慮到網(wǎng)絡數(shù)據(jù)傳輸效率,截圖的文件格式建議用 JPG 或 GIF ,不建議用 BMP ;抓圖可用 TestDirector 自帶的功能,亦可用 HyperSnap 之類的專用抓圖工具。
- 報告中不允許使用抽象詞句:比如“有錯誤”之類;
- 有關操作系統(tǒng)特征問題:應在不同操作系統(tǒng)上進行操作,看是否能重現(xiàn),并在 Bug 報告中標識;
- Bug 描述示例:
例一
|
例二(模塊或功能點也可在‘功能模塊’字段中規(guī)定,則
Bug
描述中就不必寫了)
|
例三(程序員知道期望結(jié)果的情況下)
|
例四(建議、需求類)
|
注:所有項目采用 TestDirector 進行 Bug 管理,該工具能從測試步驟自動生成 Bug 報告,因此對于 Bug 描述要求在測試方案用例設計(在 Test Plan 頁中)階段就可以進行控制。
附:好的 Bug 報告應滿足以下幾方面的要求:
- 結(jié)構(gòu)清晰
- 復現(xiàn)故障再寫報告
- 隔離 Bug :更改條件復測
- 歸納:是否其他模塊也有相同的
更多文章、技術(shù)交流、商務合作、聯(lián)系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯(lián)系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
