前兩天談論的bug管理的問題，大家列舉了很多bug跟蹤軟體，我覺得工具是一部分，但是主要還在bug管理的流程上。
在這些bug管理工具裡，bug的一個最重要的屬性就是“狀态”，一般又有“新增（New或Active）”，“進行中（in progress）”，“已修正（Fixed）”，“重新打開（reopened）”，“關閉（Close）”等幾個，這幾個狀态一看就很明白一個bug從發現到排除要走哪些流程：
1.測試人員發現bug，送出。bug狀态為New
2.開發人員接收bug，bug狀态為in Progress
3.開發人員修改完畢，送出，bug狀态改為Fixed
4.測試人員針對開發人員作的修改，再次對bug進行測試，如果bug依然存在，就把bug狀态置為reopened，流程到第二步重新開始，如果問題已經解決，就直接改為close，該bug的流程就走完了。
流程雖然簡單，但是在實際使用中還是發現一些問題：
1.bug資訊不全：
有的資訊，比如項目，子產品，指定處理人（也就是指派給誰處理）等，這些資訊會用來作統計分析，哪個項目，哪個子產品，誰的bug多，誰發現的bug多，誰改的bug多等，根據這些資訊可以大緻看出一個人的工作量和工作品質。是以不要嫌麻煩，把bug的資訊寫全些。
2.所提供的資訊不準确：
有的bug描述一帶而過，表述含糊不清，隻是說出現了錯誤，但是錯誤的現象是什麼，提示資訊是什麼，怎麼操作才出現的，都不清楚，這樣的bug交給開發人員，隻會給開發人員增加負擔，因為他自己還要再作測試，以發現更多的資訊，去排除bug，或者他會到測試那邊其讨論，詢問詳情，有時要多次回報才能确定到底是什麼問題。
3.開發人員關閉bug：
隻有bug的送出人（也就是發現人）才能去關閉該bug，開發人員隻能使用兩個狀态：“進行中”和“已修正”
4.bug的可重制性：
這個重要的屬性是在bug管理軟體中無法展現和度量的， 這個任務主要都在測試這邊，如果你發現了一個bug，趕緊把開發人員叫過來，人家來了，你要給他看看這個bug，可是卻怎麼也不出現了，連自己都不知道這個bug是怎樣操作後才出現的。這樣不能重制的bug幾乎就不能算作bug，也是最讓人頭疼的問題。那麼作為測試人員，你的任務就是要盡可能的找到bug出現的規律，嘗試各種可能，即使不能重制，起碼也要讓開發人員知道你已經作了哪些嘗試，而他不必再去走彎路。
