我很喜歡看各個産品的Bug追蹤系統，比如jQuery的Bug Tracker，因為在Bug系統中總能發現一些非常細節的問題，補充自己的知識，慢慢地自己的代碼的相容性會有很大的提高。
但是，在各個Bug系統之中，包括現在公司使用的Trace系統，無一例外地存在一些讓我不滿意之處，其中最大的原因就是很多Bug系統僅僅是作為Bug的記錄系統存在，而沒有試圖去讓一個Bug成為一個知識的積累，讓整個Bug系統變成一個豐富充實的知識庫。這樣的Bug系統，永遠都隻是提供一個簡單的業務流程，不會變成幹完人員、産品、甚至是整個團隊的進步的天梯。
在我看來，一個Bug系統應該更加全面，管理Bug的生命周期的同時，也用于管理一個産品、團隊的知識，更可以與周邊系統合作，形成一個真正的內建式管理平台。
Bug的分類
現在的Bug系統，對Bug系統的分類通常有這麼幾種：
● 根據性質：Bug、Feature、Enhancement等。
● 根據危險程度：Trival、Minor、Normal、Major、Critical等。
● 根據子產品、系統、可重制性等與項目緊密相關的分類。
但是這些Bug系統往往忽略了一個很重要的分類方式，那就是“按Bug影響面分類”，在這種分類模式下，一個Bug可以根據其影響的範圍來進行區分：
項目型Bug
與目前項目的業務流程、邏輯等有緊密關系的Bug，此類Bug隻可能在目前項目中出現，離開了項目的大環境就沒有任何存在的意義。
針對此類的Bug，隻需要在目前的環境下修複即可，不需要考慮太多的問題。
複發型Bug
此類Bug通常也與項目有緊密的關系，但是此類Bug在項目的整個演化過程中一而再再而三的出現，也許每一次出現的原因有些許差異，但表現上極其相似。比如某系統每天下午17：00左右會出現無法提供服務的情況，在第一輪修複的情況下，幾周後繼續出現此類情況。
同時，在問題被定位并修複後，可以進行一次case study，以杜絕此類問題的再次發生。
通用型Bug
此類Bug是我認為目前的Bug系統最沒有關注到的一個問題，而且相比前面兩類Bug往往可以在項目層面通過制度和流程來進行規範，通用型Bug是一個最需要自動化處理的問題。這往往涉及到不同團隊之間的合作，也是Bug平台成為一個知識庫的最為基礎的條件。
顧名思義，通用型Bug即與項目本身的業務沒有任何關系的，僅僅是技術上存在的問題。比如我最近發現的一個Bug，其可以用以下的代碼來表現：
<!DOCTYPE html>
<head>
<base target="_blank"/>
<body>
<script>
variframe=document.createElement('iframe');
document.body.appendChild(iframe);
iframe.contentWindow.location='javascript:;';
//以上代碼會在IE9下彈出一個視窗
</script>
這個Bug很明顯，是不屬于任何項目的，即所有項目在特定的情況下都可能使用類似的代碼，産生相同的Bug。
在這樣的情況下，如果将這個Bug繼續劃定在某個項目之下，那麼他最多隻能為一個項目提供幫助，防止該項目再次出現類似的問題。是以我們各項目組間可能經常能看到這樣的對話：
A：Hi，我們這邊發現一個問題，具體是…………這樣的，你們有相關經驗嗎？
B：哈哈，這個我們前段時間才遇上過，解決方法是…………那樣的。
A：謝謝，謝謝！！
确實，這樣的場景很多，甚至能貫以“項目之間善于交流”的美名，但是如果認真地去思考，這樣的場景真的有必要嗎？如果有一個自動化的平台，會将這些通用的Bug都公布出來，每個人各取所需進行關注、記錄，又怎麼會出現這樣的對話呢？
交流，哪怕是使用最好的方式進行最有效的溝通，始終是有一定的成本的。同時，交流通常是1v1的關系，即便頻繁的接觸、溝通，一個知識也很難以廣播的形式讓盡可能多地需要他的人接收到。
正因如此，我才認為一個Bug系統的職責遠不止記錄、處理、關閉Bug，而應該作為一個知識的集散地，在團隊的發展中起更大的作用。
通用性Bug處理平台
前面也提到，對于通用型Bug，平台應該有能力對其進行分發、通告，在這裡再詳細地總結一下，一個較為完善的Bug平台，在處理通用型Bug方面應該至少有以下的特色：
Bug的tag
無論系統内置使用怎麼樣的方式來對Bug進行分類，其分類的次元總會有照顧不周之處。是以在Bug平台中應該引入tag的概念，讓每一個Bug都能夠有一個或多個tag，使用tag這種通用的方式來辨別一個Bug的屬性，也進一步友善了靈活的分類。
Bug的訂閱
在Bug有了tag之後，所有擁有相應權限的人都可以訂閱其指定的tag的通用型Bug。當一個Bug被提升為通用型Bug時，Bug平台會找到所有訂閱了這個Bug擁有的tag的使用者，并通過郵件等形式向其發送該Bug報告。而随後Bug的每一個處理環節都會有郵件等形式的廣播。
Bug的共享
在Bug可以被訂閱和廣播的同時，通用型Bug應該允許每一個有權限（并且此類權限應該放得很寬松）的使用者來參與讨論、修補，每一個人都可以送出解決方案，再由相應的QA進行驗證後給予實行。這樣的效率遠大于一個項目的開發人員獨自苦苦掙紮，因為很可能有某個人曾經遇上過這個問題，對他來說提供解決方案僅僅是舉手之勞。
Bug的生命周期
目前多數的Bug平台将Bug的狀态分為幾個階段，一般是Open -> Resolved -> Closed這樣的過程，但這其實遠遠沒有涵蓋一個Bug處理過程中應該有的環節。
當然作為一個簡單、現實為上的Bug系統，其主要環節有以上三者足矣，但是如果需要将Bug平台擴充成一個知識庫，就不得不添加更多的環節，以期得到更多的資訊：
1、Open，Bug的發現階段，此時建立一個Bug，通常這個動作由QA進行。任何可重制、不可重制、小頻率重制的問題都可以進入到這個階段。
2、Reproduce Step Confirmed，Bug的重制步驟被确定，通常由QA送出。在這個階段的Bug通常是穩定的，至少通過QA提供的重制步驟能大機率地被重制出來。
3、Reproduce Environment Confirmed，Bug的重制環境被确定，通常由開發人員送出。在這個階段，在正常的重制步驟之外，開發人員已經可以提供一個最簡的環境來複現問題，可能是一段非常精簡的代碼，也可能是一個很簡單的步驟，其特點是這個重制的環境遠比QA的按步操作來得簡單，甚至可能得以自動化的重制。如果問題可以自動化重制和确定，則可以考慮将自動化腳本作為單元測試儲存。
4、Reason Found，問題的根本原因被确定，通常由開發人員送出。在這個階段，開發人員需要描述問題産生的原因，可能是某個業務邏輯的了解有分歧、或者某個第三方産品确實存在Bug、或者某段代碼存在着函數使用的錯誤等。
5、Resolution Submitted，解決方案已送出，通常由開發人員進行。在這個階段，開發人員送出一個完整的解決方案，根據開發人員的思路，這個解決方案确實得以修複該問題。随後同項目級的人員、QA可以對該解決方案進行評估，确定對其他子產品不會有影響等。
6、Resolution Applied，已經應用了解決方案，通常由開發人員送出。此時開發人員指定一個新的源碼版本号，該版本号中的相應代碼段應用了第5步中送出的解決方案，問題應當已經修複。
7、Resolution Confirmed，問題已經确定修複，由QA人員送出。此階段QA确定問題已經被修複，并且經過了一定範圍的回歸測試，確定問題不會對其他子產品産生嚴重影響。在這個階段，Bug依舊是開放狀态，各成員可以對Bug進行參與，作一些總結性的讨論。
8、Close，Bug關閉，此時Bug已經鎖定，可以作為一個固定的知識項來檢視，但不再有修改和讨論的可能性。
以上為一個非常周全的Bug生命周期管理，但确實不需要對其進行一個強制的要求。一個Bug平台可以提供這些生命周期，也許隻是簡單地在“Bug狀态”中添加相應的項，而進一步如何引導使用者對這些環節進行充分的利用，則可以通過團隊的規章、Bug平台本身的界面等方面來進行，強硬地規定隻會讓Bug追蹤過程事倍功半。
其他方面的增強
上文提的是個人認為Bug平台向知識庫整合過程中最重要的一環，即通用型Bug的分類、分享、訂閱工作，以此為其他來散布衆多點狀知識，以期通過所有人員共同參與交流、溝通，再将點狀的知識整合成線狀甚至是面狀的知識體系，補充團隊的經驗和能力。
但是在此之外，其實Bug平台還可以做很多事情，來提高這個“僞知識平台”的使用體驗，證知識更加有條理、有結構：
● 與源碼平台關聯
一個Bug平台應該與源碼平台有着非常緊密的關系，包括一個Bug在哪個版本（A）發現，在哪個版本（B）修複，并可以通過平台找到源碼平台中兩個版本的diff，比如scm.xxx.com/diff？file=abc&rev=A：B。這要求Bug平台與源碼平台都提供相應的接口，可以在兩個第三方系統間進行互動合作，現時也要求Bug平台有一個嚴格的規範，在Bug的open和close操作中提供相關的版本号。
● 與知識平台關聯
Bug是知識的來源，那麼Bug提供的知識自然要進入到知識管理平台。這一點需要系統的智能化識别，當一個Bug其資訊足夠完善，包括了前面提到的Bug生命周期的各個環節應有的資訊的時候，Bug平台應該主動與知識平台連接配接，将這個Bug整理成一份真正的知識文檔進入到知識管理平台。
本文轉自 小強測試幫 51CTO部落格，原文連結：http://blog.51cto.com/xqtesting/906118，如需轉載請自行聯系原作者
![主流浏覽器四大綜合性能測試[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)