bug管理的流程和幾個重點
初到現場發現原有的bug跟蹤很不方便,則在空閒之餘搭建了乙個bug跟蹤工具。在談論bug管理的問題中,大家列舉了很多bug跟蹤軟體。但我覺得工具只是乙個部分,主要的還是在bug管理的流程上。
在這些bug管理工具中,bug的極重要屬性就是「狀態」。一般可分為「新增(new&active)」,「處理中(in progress)」,「已修正(fixed)」,「重新開啟(reopened)」,「關閉(close)」等。
就這幾個狀態而言,明眼人一看就清楚乙個bug從發現到排除要走哪些流程:
1、測試人員發現bug,提交。bug狀態為new&acitve
2、開發人員接收bug。bug狀態為in progress
3、開發人員修改完畢並提交。bug狀態為fixed
4、測試人員針對開發人員的解決方案再次對bug進行驗證測試。如果bug依然存在,則把bug狀態設定為reopened,流程返回至第二步。如果問題已經解決,就直接設定為close。
經過以上四個步驟,整個bug的流程就基本走完了。
看似流程非常簡,可是在實際使用中還是會發現一些問題:
1、bug資訊不全。
有的資訊如專案,模組,指定處理人等。依據這些資訊會用來作統計分析,哪個專案,哪個模組,誰的bug多,誰發現的bug多,誰改的bug多等等,則可以大致看出乙個人的工作量和工作質量。所以測試人員在填寫bug問題單時,不要嫌麻煩。應該把涉及bug相關的資訊完全寫出來。
2、提供的資訊不準確。
有的bug描述一帶而過,表述含糊不清。只是說出了錯誤並沒有清楚的描述錯誤的現象是什麼,提示資訊是什麼,怎麼操作才可以出現等。這樣的bug交給開發人員,只會給開發人員增加負擔。因為當開發人員拿到bug後,發現不明之處還需要再做測試才可發現更多的資訊去解決bug。或者與相關測試人員討論並詢問詳情,有時要多次在反饋資訊當中才能明確bug的目的。這無疑造成了研發週期的無限延長。
3、開發人員關閉bug
只有bug的提交人(也就是發現人)才能關閉bug,開發人員只能使用兩種狀態,即「處理中」和「已修正」。
4、bug的重要性
這個重要性是在bug管理軟體中無法體現和度量的,這個任務主要體現在測試這邊。如果當測試人員發現了乙個bug,及時與開發人員溝通時無法重現bug,此時連測試人員都不知道這個bug是怎樣操作才出現的。對於這樣不能重現的bug幾乎就不能算是bug,也是最讓人頭疼的問題。那麼作為測試人員,其任務就是要盡可能的找出bug出現的規律。嘗試各種可能,即使不能重現也起碼要讓開發人員知道測試人員是怎麼做的,而減少開發人員的再操作的時間。
Bug管理的流程和幾個重點
2007年06月13日 廣州 24 30 暴雨 無風向 微風初到現場發現原有的bug跟蹤很不方便,則在空閒之餘搭建了乙個bug跟蹤工具。在談論bug管理的問題中,大家列舉了很多bug跟蹤軟體。但我覺得工具只是乙個部分,主要的還是在bug管理的流程上。在這些bug管理工具中,bug的極重要屬性就是 狀...
bug的級別及管理流程
什麼是bug 簡單來說就是測試的結果和測試用例的預期結果或者是使用者的需求不符。bug一般分四類,從嚴重程度由小到大分別是次要 minor 一般 major 嚴重 critical 和崩潰 blocker 接下來我通過乙個例子來說一下對bug分類的說明 從網上剛買回來一件衣服,開啟看的時候發現 衣服...
敏捷開發bug管理流程
概述 編寫目的 對由本組負責處理的bug進行管理,通過對bug的提交 跟蹤解釋 驗證流程進行規範,提高bug處理效率。適用範圍 測試團隊以及其他團隊進行的bug提交 跟進與解釋 驗證工作。bug管理流程 bug提交要求 要求提交bug要求分類準確 描述簡潔 步驟清晰 有例項 複雜問題有據可查 日誌或...