Bug生命周期及其管理

1、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)先級的定位，只用Bu

2、g級別反映Bug的嚴重程度。驗證Bug是否已被解決測試組長/經(jīng)理審核測試人員提交的Bug。定期對Bug庫進行分析，描繪岀曲線圖等，報告現(xiàn)狀、預測趨勢。在測 試總結報告中給出意見產(chǎn)品人員可以對優(yōu)先級和處理意見等進行審核，如果有意見，和項目組商量定奪Bug狀態(tài)（Status）:指缺陷通過一個跟蹤修復過程的進展情況。包括New Open Reopen Fixed、Closed 及 Rejected 等New為測試人員新問題提交所標志的狀態(tài)。Ope n為任務分配人（開發(fā)組長/經(jīng)理）對該問題準備進行修改并對該問題 分配修改人員所標志的狀態(tài)。Bug解決中的狀態(tài)，由任務分配人改 變。對沒有進入此狀態(tài)的Bug

3、，程序員不用管。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-Cras

4、h錯誤導致了死機、產(chǎn)品失?。ā氨罎ⅰ保?、系統(tǒng)懸掛無法操作；B-Major功能未實現(xiàn)或?qū)е乱粋€特性不能運行并且不可能有替代方案；C-Mi nor錯誤導致了一個特性不能運行但可有一個替代方案；D-Trivial錯誤是表面化或微小的（提示信息不太準確友好、錯別字、UI布局或罕見故障等），對功能幾乎沒有影響，產(chǎn)品及屬性仍可使用；E-Nice to Have （建議）建設性的意見或建議。Bug優(yōu)先級（Priority）:指缺陷必須被修復的緊急程度。由Bug分配者（開發(fā)組長/經(jīng)理）指定5-Urge nt阻止相關開發(fā)人員的進一步開發(fā)活動，立即進行修復工作；阻止與此 密切相關功能的進一步測試4-Very Hi

5、gh必須修改，發(fā)版前必須修正3-High必須修改，不一定馬上修改，但需確定在某個特定里程碑結束前須修 正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)被其它測試人員找岀來了（純粹重復）， 或者開

6、發(fā)認為原因是相同的（但從測試來看，認為岀現(xiàn)的地方有所不 同、表現(xiàn)有所不同等）Postp oned延后。由于時間、進度、重要程度或者技術/需求等方面的原因，認為不能解決、須延期解決、或者本版不做留待到后續(xù)版本解決的Bug。（注：因Bug狀態(tài)字段中也有該值，根據(jù)各組各自使用情況，可 以只保留一個，或者開發(fā)/測試各有側重地使用這兩個 Postponed ）By Desig n因設計結構問題無法修改。測試人員認為是Bug，不符合邏輯，也不符合用戶的要求，但開發(fā)人員則認為是按照設計做的、只能如此處 理，否則修改代價太大Can' t Reproduce不可復現(xiàn)。不能重現(xiàn)（如因 Bug岀現(xiàn)的環(huán)境重現(xiàn)

7、不了了），或以前岀 現(xiàn)的某個Bug自動消失了（可能是在處理其他 Bug的時候把這個Bug 一并修復掉了）。（注：因TD本身亦帶有是否復現(xiàn)（Reproducible）'字段，根據(jù)各 組各自使用情況，可以用它來標識，或者不用它而在處理意見字 段中用該值標識出）Disagree With Suggesti on不同意所提意見或建議，不采納Not Error不是問題。測試人員提錯了Won t Fix這個Bug是一個錯誤，但還沒有重要到非要更正不可的地步，可以忽 略不計說明：1. 定為Duplicated 的Bug,必須注明和 XXXbug重復2. 測試人員對標明為 Duplicated的Bug

8、復測，需要XXXBug修改后方可進行3. 定期回顧 Can't Reproduce,Postponed4. 定期整理By Design其它一些字段(及所定義的枚舉值)的定義解釋，供有需要用到的組參考: 測試狀態(tài)(TestState ):新提交的Bug定位標準。由測試人員指定。一般有 8個(提交Bug時給 出)1 New Defects （或?qū)懗?Defect ）新Bug2 Seco nd Defects （或?qū)懗?SB復測時新岀現(xiàn)的Bug3 Faculative偶發(fā)性4 Reappear原來修改過的問題又重新岀現(xiàn)5 By Requireme nt需求要求但沒有做的功能6 Suggest

9、i on需求需要完善 m <|vt=r7 Differ With Requireme nt與需求不一致8 By Desig n設計要求但沒有做的功能復測狀態(tài)(ReTestState):復測時給岀的狀態(tài)，測試人員對于經(jīng)過驗證的Bug應按以下幾種標準進行定位。由測試人員指定。一般有 1 OK 2- PD 3-DV 4- NB 5- NR 6-AF。OK正確PD此問題懸而不決DV有錯誤可以暫時不考慮NB不是錯誤NR不能復現(xiàn)的錯誤AR需求不明確問題定位:Calculate_error計算錯誤，指計算過程中、計算結果錯誤。Data_error數(shù)據(jù)錯誤，指非計算結果類的數(shù)據(jù)錯誤。Graphics_e

10、rror圖形錯誤，指繪圖、圖形顯示、圖形編輯時發(fā)生的錯誤。In terface_error界面錯誤Requireme nt_error需求錯誤Fun ctio n_ error功能錯誤Unknown error未知錯誤缺陷來源(Source):指引起缺陷的起因Requireme nt由于需求的問題引起的缺陷Architecture由于構架的問題引起的缺陷Desig n由于設計的問題引起的缺陷Code由于編碼的問題引起的缺陷Test由于測試的問題引起的缺陷In tegrati on由于集成的問題引起的缺陷類型(Type):是根據(jù)缺陷的自然屬性劃分的缺陷種類。F- Fun cti on影響了重要的

11、特性、用戶界面、產(chǎn)品接口、硬件結構接口和全局數(shù)據(jù) 結構。并且設計文檔需要正式的變更。如邏輯，指針，循環(huán)，遞歸， 功能等缺陷A- Assig nment需要修改少量代碼，如初始化或控制塊。如聲明、重復命名，范圍、 限定等缺陷I- I nterface與其他組件、模塊或設備驅(qū)動程序、調(diào)用參數(shù)、控制塊或參數(shù)列表相 互影響的缺陷。C- Check ing提示的錯誤信息，不適當?shù)臄?shù)據(jù)驗證等缺陷。B- Build/package/merge由于配置庫、變更管理或版本控制引起的錯誤D- Docume ntati on影響發(fā)布和維護，包括注釋。G- Algorithm算法錯誤。U- User In terfa

12、ce人機交互特性：屏幕格式，確認用戶輸入，功能有效性，頁面排版等 方面的缺陷P- Performa nee不滿足系統(tǒng)可測量的屬性值，如：執(zhí)行時間，事務處理速率等。N- Norms不符合各種標準的要求，如編碼標準、設計符號等。(以上依各組實際情況可以作適當調(diào)整)項目組各角色在Bug庫中的權限管理員：全部權限測試組長/經(jīng)理：全部權限測試人員：可添加Bug、不能刪除Bug可添加注釋評論(R&D Comments)不可修改他人所提 Bug 可調(diào)整：Bug概要(題目，Summary)問題描述、附件附圖(Attachments)、Bug狀態(tài)、Bug級別、測 試版本、測試產(chǎn)品、功能模塊、測試狀態(tài)、問

13、題定位、復測狀態(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ā)人員的權限，還可調(diào)整：優(yōu)先級別、責任人、Bug概要(題目,Summary)、附件附圖(Attachments)項目經(jīng)理：可添加Bug、可添加注釋評論（R&D Comments）可修改字段：Bug概要（題目， S

14、ummary）、問題描述、附件附圖（Attachments） 、Bug狀態(tài)（不過無法直接標為 closed ）、修改 人、優(yōu)先級別、問題定位、處理意見、注釋評論（R&D Comme nts）、是否復現(xiàn)、責任人、待測版本。也可刪除Bug，但要與測試組長/經(jīng)理協(xié)商。不屬于項目組成員的其他人 如研發(fā)中心經(jīng)理組成員等，有必要查看TD庫的話，可分配給其帳號及查看的權限。Bug描述要求Bug描述的要求為分類準確、敘述簡潔、步驟清楚、有實例、易再現(xiàn)、復雜問題有據(jù)可查（截圖或 其它形式的附件）。測試組長/經(jīng)理把關，以開發(fā)人員的角度來審查Bug描述，看其是否描述清楚了Bug，不好描述的把工程文件或截圖作

15、為附件提交。具體要求為：* 問題描述一般格式：問題描述時，建議分幾步描述：模塊或功能點=測試步驟=期望結果=實際結果=其它信息，可依實際情況調(diào)整；單一：盡量一個報告只針對一個軟件缺陷，報告形式應方便閱讀。在主報告之后應注明不 同的條件；簡潔：每個步驟的描述應盡可能簡潔明了。只解釋事實、演示和描述軟件缺陷必要的細 節(jié)，不要寫無關信息；* 再現(xiàn)：問題必須在自己機器上能復現(xiàn)方可入庫（個別嚴重問題復現(xiàn)不了也可入庫，但需標 明）；復雜的問題應附截圖補充說明或直接通知指定的修改人；考慮到網(wǎng)絡數(shù)據(jù)傳輸效率，截圖 的文件格式建議用JPG或GIF,不建議用BMP抓圖可用TestDirector自帶的功能，亦可

16、用HyperSnap之類的專用抓圖工具。* 報告中不允許使用抽象詞句：比如“有錯誤”之類；*有關操作系統(tǒng)特征問題：應在不同操作系統(tǒng)上進行操作，看是否能重現(xiàn)，并在Bug報告中標識；* Bug描述示例：例一河北98 土建標準換算 操作：1. 輸入9-242. F83. 在F8輸入10期望結果：進行換算 實際結果：提示“輸入 的厚度應大于20”例二（模塊或功能點也 可在功能模塊字段 中規(guī)定，則Bug描述中 就不必寫了） 操作：1. 打開新建向?qū)В?. 在“新建”中的“項 目名稱”中輸入80個 字符；3. 點擊“下一步”例三（程序員知道期望 結果的情況下）云南98 土建操作：1. 輸入 13-1702. F53. 在F5中修改3240008的名稱，處于編輯狀態(tài)4. 到人材機，再回來 實際結果：F5中變白例四（建議、需求類） 功能：預算頁，子目排 序后可恢復原順序用途：用戶誤操作后可 復原期望結果：“項目名 稱”應=80個字符，輸 入大于80個字符，點擊“下一步”應有錯誤提 示實際結果：進入“比重 調(diào)整”界面板注：若3不處于編輯態(tài) 切換則正常注：所有項目采用TestDirector進行Bug管理，該工具能從測試步驟自動生成B