軟件測試過程中的BUG管理
測試是軟件開發過程中必不可少的一個階段,大家的著重點可能都在測試人員如何發現BUG以及開發人員如何解決BUG,而很少去關注BUG自身的管理。在這里,想介紹一下我們在開發中如何進行BUG的流程管理,更重要的是想了解一下大家都是如何進行相關的工作,希望能與大家深入的交流。
首先,需要介紹一下BUG的管理工具,這個應該做開發和測試的朋友都接觸過,如Bugzilla,BugFree等,我們沒有單獨使用BUG的管理工具,而是使用TRAC,利用其中的TICKET來做BUG的管理與控制。TRAC中的TICKET自身有狀態的工作流定義,我們使用的0.11版本,TICKET狀態如下所示:

然后,我介紹一下我們如何對BUG的流程進行控制:
開發人員編碼結束后,發布一個0.1的軟件版本提供測試。測試人員對該版本進行測試,一但測出BUG,就在TRAC中新建一個TICKET,對BUG的情況進行描述,并指定哪位開發人員接收這個TICKET。同時,也指明該BUG是針對哪一個版本的軟件。
開發人員在接收到TRAC的郵件通知后,登錄上TRAC,查看屬于自己的TICKET列表。如果這個TICKET屬于自己的修改范圍,就accept下來,如果不是,就reassign給別的開發者。接下來的工作就是修復BUG,修復完成以后,將TICKET的狀態更改為resolve as “fixed”。如果BUG不需要修改,或者根本不是BUG,可以選擇resolve as “wontfix”和resolve as “invalid”。開發人員在將所有BUG都處理完一遍之后,可以BUILD出一個新的軟件版本0.2。
測試人員進行第二輪的測試,首先,他們需要把第一輪報的TICKET全部檢查一遍,如果開發人員把BUG修復了,那么可以把TICKET的狀態改為”verifed”,如果發現根本沒有改完,而開發人員就把TICKET標成了已修復,那么測試人員可以把TICKET做一個reopen的操作。同時,把該TICKET的指定軟件版本改為0.2。然后,繼續測試,報出新的BUG。
如此循環下去,直到測試人員測不出BUG,或者剩下暫進不改的BUG,開發人員的修復工作停止。測試人員提交測試報告。報告包括每一輪測試中測出的總BUG數,已修復的BUG數等。
以上,就是我們現在應用的測試以及BUG的管理流程。目前還是有一些問題在困擾著我們:
1、測試人員在發現BUG后,填寫TICKET,首先發送給誰?(直接發送給測試人員,會帶來很多溝通上的成本,如測試人員覺得這不是BUG等;還是發給一個能決定這是不是一個BUG,以及如果是BUG需不需要修改的人,如項目經理)
2、BUG本身存不存在版本這么一說?(BUG是只針對某一版本的測試軟件,還是跟著軟件版本一起走,比如說reopen的BUG)
3、有沒有更好的測試管理流程,包括BUG的管理方式?(希望能與大家深入的交流這個問題,把這個東西徹底地搞清楚)
原文鏈接:http://www.cnblogs.com/brucenan/archive/2010/11/10/1874450.html
【編輯推薦】