Bug狀態(tài)流程圖

1、Bug狀態(tài)流程圖對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級別反

2、映Bug的嚴重程度.驗證Bug是否已被解決測試組長/經(jīng)理審核測試人員提交的Bug.定期對Bug庫進行分析,描繪出曲線圖等,報告現(xiàn)狀、預測趨勢.在測試 總結(jié)報告中給出意見產(chǎn)品人員可以對優(yōu)先級和處理意見等進行審核,如果有意見,和工程組商量定奪Bug狀態(tài)Status:指缺陷通過一個跟蹤修復過程的進展情況.包括 New Open Reopen Fixed、 Closed 及 Rejected 等新建NeW>測試人員報£個新bug并且沒有指派給具體的開發(fā)人員修改是的 狀態(tài).打回(Feedback)開發(fā)人員認為此bug不需要修改,就將其反應.測試人員和開發(fā)人員 討論評估后,決定是否將其關(guān)閉

3、公認(Acknowledged)該bug在大局部模塊中或頁曲中出現(xiàn),將其設(shè)為Acknowledged由開發(fā)人員確認已確認Confirmed開發(fā)人員QA確認存在此bug,并準備修改,將其設(shè)為 confirmed已分派(Assigned)將新建bug指派給某個指定的開發(fā)人員后,狀態(tài)為 Assigned 一般 由工程經(jīng)理做已解決Resolved開發(fā)人員QA確認bug以及解決,測試人員可以進行驗證測試了已關(guān)閉(Closed )確認bug已經(jīng)解決,關(guān)閉新建(New)為測試人員新問題提交所標志的狀態(tài).翻開(Open)為任務分配人開發(fā)組長/經(jīng)理對該問題準備進行確認并修改分派(Assign )為任務分配人開發(fā)

4、組長/經(jīng)理對該問題分配修改人員所標志的狀 態(tài).Bug解決中的狀態(tài),由任務分配人改變.對沒有進入此狀態(tài)的 Bug,程序員不用管.重新翻開Reopen為測試人員對修改問題進行驗證后沒有通過所標志的狀態(tài)；或者已經(jīng)修改正確的問題,又重新出現(xiàn)錯誤.由測試人員改變.已修正Fixed為開發(fā)人員修改問題后所標志的狀態(tài),修改后還未測試.已關(guān)閉(Closed)為測試人員對修改問題進行驗證后通過所標志的狀態(tài).由測試人員改 變.拒絕(Rejected)開發(fā)人員認為不是Bug、描述不清、重復、不能復現(xiàn)、不采納所提意 見建議、或雖然是個錯誤但還沒到非改不可的地步故可忽略不計、或者測試人員提錯,從而拒絕的問題.由 置.Bu

5、g分配人或者開發(fā)人員來設(shè)Bug嚴重級別Severity,Bug 級別：是指因缺陷引起的故障對軟件產(chǎn)品的影響程度.由測試人員指4一宕機Block 引起系統(tǒng)死鎖的錯誤3 崩潰(Crash)引起系統(tǒng)崩潰的錯誤2很嚴重(Major )不屬于系統(tǒng)崩潰和死鎖類的,但很嚴重的錯誤1 小錯誤(Minor)比擬輕的問題,如button位置,數(shù)字格式,文字上的拼寫錯誤Bug優(yōu)先級Priority:指缺陷必須被修復的緊急程度.由 Bug分配者開發(fā)組長/經(jīng)理指定5 特急(Immediate )必須修改,并且需要立即進行修改4-加急(Urgent )一到兩大之內(nèi)必須修改并且版前必須修正3-高(High )將處于5和4優(yōu)

6、先級的bug修改完后再進行修改,但需確定在某個特 定里程碑結(jié)束前須修正2-中(Medium)如果時間允許應該修改1低LoW低優(yōu)先級留到最后解決,如果工程的進度很緊張可以在產(chǎn)品發(fā)布以前 不解決功能模塊Subject : TD中需在Test Plan 頁中定義好 Subject ,才能在Defects頁中使用問題描述、附件附圖 請參見后面第四局部Bug描述要求的有關(guān)內(nèi)容.處理意見：開發(fā)組長/經(jīng)理或具體Bug分配人員在審核新Bug時、將Bug分配給開發(fā)人員解決前 需要給出該Bug的處理意見.未處理OpenBug沒有被解決已修正(Fixed )Bug的修改已經(jīng)登記并經(jīng)過測試重新翻開ReopenBug曾

7、經(jīng)被解決,但是解決方案被認為不正確無法重現(xiàn)(Unable to reproduce )無法重現(xiàn),被指派的開發(fā)人員想要再重現(xiàn)bug進行修改的時候發(fā)現(xiàn)bug始終不能再現(xiàn)的時候?qū)?bug的resolution 設(shè)置為此項無法修復(Not fixable)無法修復這個bug重復問題(Duplicate)與某個已經(jīng)存在的bug重復不是問題(No change required )經(jīng)理和相關(guān)開發(fā)人員經(jīng)過需求和設(shè)計的核實后決定部需要修改暫停(suspended)延期,一般只當前版本不進行修改,下個版本再提供解決方案不做修改Wori t fix 部準備修改這個bugFixable可修改.表不Bug可以被修復或

8、更正Duplicated重復,表不該Bug已經(jīng)被其它測試人員找出來了純粹重復, 或者開發(fā)認為原因是相同的但從測試來看,認為出現(xiàn)的地方有所不 同、表現(xiàn)有所不同等Postponed延后.由于時間、進度、重要程度或者技術(shù) /需求等方面的原因,認 為不能解決、須延期解決、或者本版不做留待到后續(xù)版本解決的 Bug.注：因'Bug狀態(tài)字段中也有該值,根據(jù)各組各自使用情況,可以只保存一個,或者開發(fā)/測試各有側(cè)重地使用這兩個 PostponedBy Design因設(shè)計結(jié)構(gòu)問題無法修改,測試人員認為是Bug,不符合邏輯,也不 符合用戶的要求,但開發(fā)人員那么認為是根據(jù)設(shè)計做的、只能如此處 理,否那么修改代

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

10、XXXbug重復2.測試人員對標明為Duplicated的Bug復測,需要XXXBug修改前方可進行3.定期回憶 Can' t Reproduce,Postponed4.定期整理By Design注意：Status主要是QA來設(shè)置修改,而resolution那么是相關(guān)開發(fā)人員和工程經(jīng)理來進行修改的.工程組各角色在Bug庫中的權(quán)限治理員：全部權(quán)限測試組長/經(jīng)理:全部權(quán)限測試人員：可添加Bug、不能刪除Bug可添加注釋評論R&D Comments、不可修改他人所提Bug、可調(diào)整：Bug概要題目,Summary、問題描述、附件附圖Attachments 、Bug狀態(tài)、Bug級別、測試

11、版本、測試產(chǎn)品、功能模塊、測試狀態(tài)、問題定位、復測狀態(tài)、注釋評論R&DComments、復測人、復測日期、修改人開發(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概

12、要題目,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)理把關(guān),以開發(fā)人員的角度來審查 Bug描述,看其是否描述清楚了 Bug, 不好描述的把工程文件或截圖作

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

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