?
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元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
