一 Bugzilla的狀態
狀態 說明
unconfirmed | 未確定(針對反饋Bug/需求) |
confirming | 確認中(針對反饋需求) |
new | 新建 |
assigned | 已分配 |
resolved | 已解決 |
verified | 已驗證 |
closed | 已關閉 |
reopened | 重新打開 |
二 Bugzilla的解決途徑
解決途徑 說明
fixed | 已修復 |
waitpacket | 等待打包(已經廢棄,待刪除 ) |
invaild | 無效 |
wontfix | 決定不改 |
later | 後續版本 |
duplicate | 重複 |
worksforme | 無法重試 |
walkaround | 以規避 |
remind | 提醒 |
moved | 已移出 |
三 Bugzilla的提交形式
提交形式 | 說明 |
file | 文件 |
built | 升級包 |
code | 代碼 |
注:提交形式只在狀態爲resolved,解決途徑爲fixed時纔可使用
四 Bug優先級定義
優先級 | 缺陷反饋BUG | 內部BUG |
高 | 1 因我公司設備導致客戶網絡或業務系統中斷或癱瘓;【時限要求】:24小時 2 設備出現嚴重問題或者不可用,並導致客戶網絡或業務系統無法正常工作【時限要求】:48小時 | 1 阻礙測試繼續運行 2 項目測試進度計劃受到極大影響 3 影響結項通過的 4 影響當前測試升級包發佈的 5 已知問題在對外發布版本也存在,並且有導致客戶網絡或業務系統中斷或癱瘓風險的 【時限要求】:48小時 |
中 | 在線串聯設備出現嚴重問題,但客戶網絡或業務沒有受到影響 【時限要求】:72小時 | 從當前時間點上看問題緊急程度不高,時限要求: 1 必須在結項版本解決 2 必須在當前測試升級包發佈版本解決 3 在測試和開發雙方商議的deadline期限內解決 |
低 設備出現問題,但仍可正常運行 問題在時限上沒有特別要求
不影響客戶正常使用 開發有時間則納入計劃解決
【時限要求】一週
注:缺陷的優先級可以隨着時間推移根據實際情況作調整
五 Bug嚴重級別規範
嚴重程度等級 | 定義標準 | 示例 Bug相關產品 |
critical | 1 導致客戶網絡或業務系統中斷或癱瘓 2 系統崩潰/掛起 數據丟失或內存嚴重泄漏等導致系統不可用 3 系統存在易於***且危害高的安全漏洞 | 【公共平臺】Bug 24149:設備外網口疑似LAND***後NAT池資源耗盡導致TCP通訊異常 【eps】bug 10581 發現內存,句柄泄漏現象 |
major | 1 功能嚴重不可用,或影響系統自身業務流程完成 2 系統存在易於***或危害高的安全漏洞 | 【公共平臺】Bug 25432 URL過濾功能失效 【EPS】Bug 13915 代理端口開機5分鐘左右以後,自保護功能失效 |
nornal | 1、功能部分不可用,影響一般:不影響客戶業務系統正常運轉,同時也不影響系統自身業務流程完成; | IPS] Bug 23624:29001號規則誤阻斷風行在線視頻 [公共平臺] Bug 25657:清除報表後,頁面出現http404提示 |
trivial | UI顯示、文本、文字等錯誤,且不影響功能 | |
enhancement | 建議性質的意見 |
六 反饋的缺陷處理說明
6.1 反饋的缺陷處理說明
1) 有關於反饋Bug所涉及的績效統計,參見《績效辭典》。
2) 處於resolved(已解決)狀態的Bug,必須先將狀態變更到verified(已驗證)後,才能將狀態再變更爲closed(已關閉)。變更到verified狀態之前,必須填寫“缺陷引入階段”字段(解決途徑是:invaild(無效)、duplicate(重複)、worksforme(無法重現)的除外);
3) 客戶現場存在問題,而內部無法重現的反饋Bug,如果能判斷較大的可能是由產品缺陷引起的問題,測試經理和產品經理溝通確認後,可以先將Bug狀態設置爲NEW。後續如果最終確認不是產品缺陷的,將Bug的解決途徑設置成INVAILD(無效);如果最終確認是產品缺陷的,按照缺陷的情況進行處理。(注:與此相關的績效“產品維護階段反饋缺陷的平均解決週期”的統計方法是從第一個unconfirmed(未確定 針對反饋bug/需求)到VERIFIED,不包括無效Bug。)
4) 客戶現場重現週期長或重現困難,而內部無法重現的反饋Bug,在能保證其他客戶處不重複出現,且相關方面可接受規避方案的情況下,可以先規避解決,將解決途徑設置成WALKAROUND,狀態爲RESOLVED,技術支持經理在此之後,等待一個月客戶現場不再繼續出現問題,也沒有再收到同樣的缺陷反饋,可將該反饋Bug關閉。如果在等待過程中,再出現問題或收到相同缺陷反饋,將該反饋Bug重新打開REOPENED。在該反饋Bug關閉之後再出現同樣問題的話,建立新的反饋Bug進行跟蹤,不再重新打開已關閉的反饋Bug。
5) 反饋缺陷的問題確認及復現,由產品質量部負責(特殊或緊急情況開發人員可以進行緊急處理)。UNCONFIRMED狀態變更爲NEW狀態的操作,一般由測試經理或測試人員在問題確認後完成。
七 反饋的需求處理說明
7.1 反饋的需求處理說明
1處於unconfirmed(未確定)狀態的反饋需求,必須先將狀態更改爲new,不能將狀態直接更變爲resolved(解決途徑爲invaild無效 duplicate重複的除外
2 處於new狀態的反饋需求,必須先將狀態變爲assigned(已分配),不能將狀態直接變爲resolved(解決途徑爲invaild duplicate的除外)。再變更到assigned之前,必須填寫完‘最後期限’(deadline)字段
3 處於confirming(確認中)狀態的反饋需求,必須先將狀態變更爲unconfirmed
7.2 反饋的需求狀態機
八 過程bug的處理說明
8.1 過程bug的狀態機
九 Deadline填寫說明
1 對於可行的,計劃在後續予以實現的產品反饋需求,產品經理和測試經理一同評估需求實現週期,提出需求實現計劃,計入需求處理系統,並通知系統工程師,產品市場經理
需求實現計劃至少包含城垛計劃完成的時間點(deadline,指到已驗證verified狀態的時間點)工作量預計(以 人*小時 爲單位),可以包括計劃實現的版本號,實現方式等;要求產品經理接到需求處理通知後在2個工作日內完成該任務,同時在bugzilla中將需求記錄狀態設置爲已分配assigned
2 對應確認需要進行修復的產品反饋缺陷,產品經理和測試經理一同評估缺陷修復及完成驗證週期。完成討論之後,產品經理給出修復處理方案,包括承諾計劃完成的時間點(deadline,指到已驗證verified狀態的時間點),記錄到bugzilla系統中,分配責任人,並將缺陷記錄狀態設置爲已分配(assigned)
3如果系統工程師,產品市場經理或產品支持經理等認爲時間承諾等無法滿足市場要求的,可以考慮召集評審會議重新審覈,或升級事件到更高一層的領導協調
十 bug引入階段字段的使用說明
10.1 目的
問題回溯——產品發佈後的缺陷分析,用於產品系統質量改進
流程相關問題發掘和流程改進
10.2 範圍
在buggilla中新增一個字段,用來定位和回溯發佈後反饋bug在生命週期中的引入階段
用於buggilla中反饋的bug,內部測試暫不執行
10.3 使用說明
10.3.1 引入階段的定義
對於引入階段,初步定義爲6項:“市場需求”階段,“測頻需求”階段,“設計”階段,“編碼”階段,“版本管理”和“歷史遺留”,在查詢bug 更新bug時可以看到,如下圖所示:
10,3,2 填寫說明
此階段定位由開發人員填寫,當反饋bug的責任人指向某開發人員時,開發人員響應,處理此bug期間,同時定位bug的引入階段,如上圖所示,在“缺陷引入階段”右側的下拉框中選定引入階段即可
當開發人員不能定位時,須告知產品經理,由產品經理進行定位
爲保證問題定位的準確性,以降低後續系統改進趨勢分析的偏差,對問題定位需由相關人員進行確認,確保問題定位在組內達成一致,不存在分歧,確任人員如下:
ü 定位爲“設計”階段的反饋bug需架構師或產品經理確認;
ü 定位爲“產品需求”階段的反饋bug需SE或產品經理確認;
ü 定位爲“市場需求”階段的反饋bug需產品市場經理確認;
ü 定位爲“版本管理”的反饋bug需項目級配置管理員或產品經理確認;
ü 定位爲“歷史遺留”的反饋bug需產品經理確認等。
通常建議在反饋bug關閉時,bug引入階段的定位也需要確定完畢,例外爲定位出現分歧的情況,允許直到達成一致時填寫完畢;
因流程改進和系統改進需要,開發中心項目管理組會定期抽取相關數據,週期爲2周(每月中旬)或4周(每月最後一週)左右,請各產品組儘量在相關週期內提交完畢。
此字段填寫於2009年5月開始試行。
十一 測試bug提交內容規範
測試人員在提交BUG時,應該按照以下的格式要求,提交BUG相關的信息。
ENV等處的內容,各個產品可以根據產品自身的特點,增加或裁減相關內容項,例如,RCM組的可能還需要包括插件數、漏洞數、被掃描系統的版本等信息。
十二 開發bug回覆內容規範
開發人員在完成BUG定位、BUG修復工作之後,更新BUG狀態的同時,應該按照以下的格式要求,對BUG進行回覆。儘量將以下內容填寫清楚,對的確不涉及的內容,可以省略。
十三 bug驗證規範
十四 bugzilla管理規範
十五 主要字段說明