Bug狀態(tài)流程圖

1、Bug狀態(tài)流程圖對(duì)Bug的處理開發(fā)組長/經(jīng)理每天對(duì)Bug進(jìn)行分配,標(biāo)注處理意見,給定優(yōu)先級(jí)發(fā)版前必須三方：需求、開發(fā)、產(chǎn)品共同確定.問題分配時(shí),應(yīng)盡可能將咨詢類、理解錯(cuò)誤類等問題處理掉,而不是留給開發(fā)人員.有可能是需求的問題,分配給需求人員.定期對(duì)Bug庫分析,找出常出錯(cuò)的模塊,進(jìn)行代碼審查開發(fā)人員分析Bug,寫出問題原因,修改 Bug；實(shí)行Bug優(yōu)先原那么,嚴(yán)重程度B Major類或緊急程度3 High類以上包含bug5個(gè)或5個(gè)以上,停止新功能的開發(fā).需求人員 解釋需求,給出處理意見,將 Bug庫中的建議整理成需求文檔.評(píng)審確定后列入開發(fā)方案測(cè)試人員不參與問題的優(yōu)先級(jí)的定位,只用Bug級(jí)別反

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

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

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

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

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

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

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

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

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

11、版本、測(cè)試產(chǎn)品、功能模塊、測(cè)試狀態(tài)、問題定位、復(fù)測(cè)狀態(tài)、注釋評(píng)論R&DComments、復(fù)測(cè)人、復(fù)測(cè)日期、修改人開發(fā)人員/需求人員：不能刪除Bug、可添加注釋評(píng)論R&D Comments、可調(diào)整：注釋評(píng)論R&D Comments是否復(fù)現(xiàn)、Bug狀態(tài)不過無法直接標(biāo)為closed 、問題描述、處理意見、待測(cè)版本、 修改人、修改日期.可添加Bug.開發(fā)組長/經(jīng)理/需求經(jīng)理：除了開發(fā)人員的權(quán)限,還可調(diào)整：優(yōu)先級(jí)別、責(zé)任人、 Bug概要題目,Summary 、附件附圖Attachments工程經(jīng)理：可添加Bug、可添加注釋評(píng)論R&D Comments、可修改字段：Bug概

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

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

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