Bugfree是一款優秀的
bug管理和追蹤工具，因此受到不少公司的青睞。但實際的
工作中，我發現不少開發或是
測試的同事有一些不好的使用習慣，使得我們對Bugfree的利用不夠高效。我下面列出使用Bugfree的一些壞習慣，以此與各位測試同仁切磋使用這個工具的高效的方法。
對開發的同事而言，可能會有下面幾條壞習慣。
壞習慣一：只采用默認的解決方案。
周圍不少開發的同事，在解決掉一個bug的時候，往往只采用默認的解決方案：fixed。事實上，Bugfree提供了7種解決bug的方案供程序員選擇。它們分別是：By Design、Duplicate、External、Fixed、Not Repro 、Postponed、Won't Fix 。這7種解決方案反應了程序員解決bug的理由。By Design的意思是，設計上就是這么定的，bug無效；Duplicate的意思是，這個bug已經有人提過，重復了；External的意思是，軟件本身沒有問題，是外部因素（比如
操作系統）造成的問題；Fixed的意思是：bug被解決掉了；Not Repro的意思是，這個bug無法重現；Postponed的意思是，這個bug推遲到以后解決；Won't Fix的意思是，是個問題，但是不值得解決。為什么會有這種習慣呢？我詢問過一位開發的同事，他說看不懂英文，又懶得去查。另一位開發同事說，一開始沒注意到這一項是可選的，時間久了，自然而然就視而不見了。
改掉這個習慣不是更好嗎？我的理由：給bug設置正確的解決方案，一方面可以減少開發和測試的溝通障礙，讓測試員知道程序員為什么要關掉這個bug；另一方面可以給bug歸類，便于查找bug和開發后期集中解決bug。
壞習慣二：只在詳細信息里寫上：已解決。
由Bugfree提供的7種解決方案，不難看出詳細信息這一欄多數情況下是為第四種解決方案Fixed提供補充的。很多bug在被fixed掉以后，如果只在這一欄注明已解決字樣會有不好的影響。因為時間久了，或許程序員自己都不清楚這個bug是怎么被fixed掉的，如果再碰到類似的問題又要花很長時間去想辦法解決，影響工作的效率。
改掉這個習慣不是更好嗎？我的理由：在詳細信息欄里注明bug被fixed掉的理由，一方面像上面所說的可以給開發人員提個醒，便于解決類似的bug；另一方面對測試員也有好處。測試員在碰到類似的bug以后，能夠知道哪兒出了問題，這樣就可以準確及時地提醒開發人員，便于bug的修改。
對測試的同事而言，可能會有下面的幾條壞習慣。
壞習慣一：創建bug時，選錯了項目。
周圍有測試同事，在發現了bug后，就急急忙忙去bugfree里描述bug和指派bug，往往會忽略其他的選項。就拿這個項目來說，登錄bugfree后里面就有默認的內容，但未必是和bug相對應的。如果測試人員因為發現了bug，有點興奮，再加上一點粗心就會忽略這一項。
改掉這個習慣不是更好嗎？我的理由：設置正確的項目可以給bug歸類，便于bug的查找。若選錯了項目，難免會抱怨找不到自己創建的bug，還得通過其他方式查找這個沉入“大海”的bug，影響了工作的
心情和效率。
壞習慣二：創建bug時，沒有選/選錯了模塊。
創建bug時，模塊這個選填項，不僅看起來不起眼，而且會讓人誤以為它沒有用，所以測試人員往往會忽略它。 改掉這個習慣不是更好嗎？我的理由：設置正確的模塊，可以給bug分門別類。這樣，開發人員就能很方便知道A模塊有哪些bug，B模塊有哪些bug，讓開發人員對自己負責的項目模塊心里有底。所以，還請測試人員辛苦下，把模塊這一項設置好。
壞習慣三：設置錯誤的嚴重等級。
周圍有同事，往往只注重對bug地描述，不去關注對bug等級的設置，不利于開發人員優先解決嚴重的bug。其實Bugfree提供可選的4種嚴重等級：1、2、3、4。1是最高等級，意思是這個bug導致系統死機，數據丟失或者與需求不符合；2是嚴重等級，意思是這個bug導致計算出現錯誤，功能實現出現錯誤；3是一般等級，意思是這個bug是個合法性問題，界面問題或是文檔問題等；4是最低等級，意思是這個bug影響易用性。不少情況下是測試人員不清楚各種級別的含義，導致的分類錯誤。
改掉這個習慣不是更好嗎？
我的理由：設置正確的嚴重等級，可以讓開發人員優先解決1、2bug，在項目時間允許的情況下，再著手解決3、4類bug，以保證產品的質量。啰嗦一句，首先要保證產品能用，再去保證產品好用。
其實最好的習慣是按照bugfree的格式，把每一項該填的內容填好！！