軟件測(cè)試過程中的BUG管理
測(cè)試是軟件開發(fā)過程中必不可少的一個(gè)階段，大家的著重點(diǎn)可能都在測(cè)試人員如何發(fā)現(xiàn)BUG以及開發(fā)人員如何解決BUG，而很少去關(guān)注BUG自身的管理。在這里，想介紹一下我們?cè)陂_發(fā)中如何進(jìn)行BUG的流程管理，更重要的是想了解一下大家都是如何進(jìn)行相關(guān)的工作，希望能與大家深入的交流。
首先，需要介紹一下BUG的管理工具，這個(gè)應(yīng)該做開發(fā)和測(cè)試的朋友都接觸過，如Bugzilla,BugFree等，我們沒有單獨(dú)使用BUG的管理工具，而是使用TRAC，利用其中的TICKET來做BUG的管理與控制。TRAC中的TICKET自身有狀態(tài)的工作流定義，我們使用的0.11版本，TICKET狀態(tài)如下所示：
然后，我介紹一下我們?nèi)绾螌?duì)BUG的流程進(jìn)行控制：
開發(fā)人員編碼結(jié)束后，發(fā)布一個(gè)0.1的軟件版本提供測(cè)試。測(cè)試人員對(duì)該版本進(jìn)行測(cè)試，一但測(cè)出BUG，就在TRAC中新建一個(gè)TICKET，對(duì)BUG的情況進(jìn)行描述，并指定哪位開發(fā)人員接收這個(gè)TICKET。同時(shí)，也指明該BUG是針對(duì)哪一個(gè)版本的軟件。
開發(fā)人員在接收到TRAC的郵件通知后，登錄上TRAC，查看屬于自己的TICKET列表。如果這個(gè)TICKET屬于自己的修改范圍，就accept下來，如果不是，就reassign給別的開發(fā)者。接下來的工作就是修復(fù)BUG，修復(fù)完成以后，將TICKET的狀態(tài)更改為resolve as “fixed”。如果BUG不需要修改，或者根本不是BUG，可以選擇resolve as “wontfix”和resolve as “invalid”。開發(fā)人員在將所有BUG都處理完一遍之后，可以BUILD出一個(gè)新的軟件版本0.2。
測(cè)試人員進(jìn)行第二輪的測(cè)試，首先，他們需要把第一輪報(bào)的TICKET全部檢查一遍，如果開發(fā)人員把BUG修復(fù)了，那么可以把TICKET的狀態(tài)改為”verifed”，如果發(fā)現(xiàn)根本沒有改完，而開發(fā)人員就把TICKET標(biāo)成了已修復(fù)，那么測(cè)試人員可以把TICKET做一個(gè)reopen的操作。同時(shí)，把該TICKET的指定軟件版本改為0.2。然后，繼續(xù)測(cè)試，報(bào)出新的BUG。
如此循環(huán)下去，直到測(cè)試人員測(cè)不出BUG，或者剩下暫進(jìn)不改的BUG，開發(fā)人員的修復(fù)工作停止。測(cè)試人員提交測(cè)試報(bào)告。報(bào)告包括每一輪測(cè)試中測(cè)出的總BUG數(shù)，已修復(fù)的BUG數(shù)等。
以上，就是我們現(xiàn)在應(yīng)用的測(cè)試以及BUG的管理流程。目前還是有一些問題在困擾著我們：
1、測(cè)試人員在發(fā)現(xiàn)BUG后，填寫TICKET，首先發(fā)送給誰？（直接發(fā)送給測(cè)試人員，會(huì)帶來很多溝通上的成本，如測(cè)試人員覺得這不是BUG等；還是發(fā)給一個(gè)能決定這是不是一個(gè)BUG，以及如果是BUG需不需要修改的人，如項(xiàng)目經(jīng)理）
2、BUG本身存不存在版本這么一說？（BUG是只針對(duì)某一版本的測(cè)試軟件，還是跟著軟件版本一起走，比如說reopen的BUG）
3、有沒有更好的測(cè)試管理流程，包括BUG的管理方式？（希望能與大家深入的交流這個(gè)問題，把這個(gè)東西徹底地搞清楚）
原文鏈接：http://www.cnblogs.com/brucenan/archive/2010/11/10/1874450.html
【編輯推薦】
