軟件測試過程中的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
【編輯推薦】
