亚洲免费在线-亚洲免费在线播放-亚洲免费在线观看-亚洲免费在线观看视频-亚洲免费在线看-亚洲免费在线视频

Bug生命周期及其管理

系統(tǒng) 1553 0

?

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
(注:因‘ Bug 狀態(tài)’字段中也有該值,根據(jù)各組各自使用情況,可以只保留一個,或者開發(fā) / 測試各有側(cè)重地使用這兩個 Postponed

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 一并修復掉了)。
(注:因 TD 本身亦帶有‘是否復現(xiàn) (Reproducible) ’字段,根據(jù)各組各自使用情況,可以用它來標識,或者不用它而在‘處理意見’字段中用該值標識出)

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 描述示例:

例一
河北 98 土建標準換算
操作
1.
輸入 9-24
2.F8
3.
F8 輸入 10
期望結(jié)果 :進行換算
實際結(jié)果 :提示“輸入的厚度應大于 20

例二(模塊或功能點也可在‘功能模塊’字段中規(guī)定,則 Bug 描述中就不必寫了)
操作:
1.
打開新建向?qū)В?
2.
在“新建”中的“項目名稱”中輸入 >80 個字符;
3.
點擊“下一步”
期望結(jié)果 :“項目名稱”應 <=80 個字符,輸入大于 80 個字符,點擊“下一步”應有錯誤提示
實際結(jié)果 :進入“比重調(diào)整”界面

例三(程序員知道期望結(jié)果的情況下)
云南 98 土建
操作:
1.
輸入 13-170
2.F5
3.
F5 中修改 3240008 的名稱 , 處于編輯狀態(tài)
4.
到人材機 , 再回來
實際結(jié)果 F5 中變白板
:若 3 不處于編輯態(tài)切換則正常

例四(建議、需求類)
功能 :預算頁,子目排序后可恢復原順序
用途 :用戶誤操作后可復原

注:所有項目采用 TestDirector 進行 Bug 管理,該工具能從測試步驟自動生成 Bug 報告,因此對于 Bug 描述要求在測試方案用例設計(在 Test Plan 頁中)階段就可以進行控制。

附:好的 Bug 報告應滿足以下幾方面的要求:

  • 結(jié)構(gòu)清晰
  • 復現(xiàn)故障再寫報告
  • 隔離 Bug :更改條件復測
  • 歸納:是否其他模塊也有相同的

Bug生命周期及其管理


更多文章、技術(shù)交流、商務合作、聯(lián)系博主

微信掃碼或搜索:z360901061

微信掃一掃加我為好友

QQ號聯(lián)系: 360901061

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

【本文對您有幫助就好】

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描上面二維碼支持博主2元、5元、10元、自定義金額等您想捐的金額吧,站長會非常 感謝您的哦!!!

發(fā)表我的評論
最新評論 總共0條評論
主站蜘蛛池模板: 国产欧美精品一区二区三区 | 成人另类视频 | 日韩精品久久不卡中文字幕 | 色爱区综合激情五月综合激情 | 亚洲精品欧洲一区二区三区 | 深夜福利成人 | 日本亚洲视频 | 奇米888影视 | 欧美视频色 | 久久精品国产欧美日韩99热 | 在线人成精品免费视频 | 97视频久久 | 日韩毛片高清在线看 | 看看一级毛片 | 欧美色爱综合 | 青春草国产成人精品久久 | 日韩国产欧美成人一区二区影院 | 日韩大片 | 成人久久久久 | 久久精品国产69国产精品亚洲 | 国内精品视频一区 | 国产亚洲精品成人a在线 | 国产精品国产自线拍手机观看 | 在线观看国产久青草 | 国产或人精品日本亚洲77美色 | 成熟热自由日本语亚洲人 | 免费不卡视频 | 九九视频在线 | 日韩 欧美 自拍 在线 视频 | 日本一本久道 | 欧美一区a| 亚洲伊人国产 | 夭天干天天做天天免费看 | 操综合网 | 久久国内精品视频 | 亚洲婷婷网 | 国产 麻豆 欧美亚洲综合久久 | 久久99亚洲精品久久99 | 久久综合色网 | 一区二区三区乱码 | 毛片毛片毛片毛片毛片 |