Bug bash、ZBB與軟體品質

Bug bash 的來源與意義

要做好這樣的活動，首先我們必須明白這項活動的意義。

Bug bash（Bug大掃除）來源於微軟，通常發生在項目開發各階段（微軟叫裡程碑）的末期，比如Beta版發布前，划出一個專門的時間段（通常1-3天），在這期間所有參與項目的人員，集中全部精力，運用各方面的知識，盡全部智慧來搜尋項目的Bug。

這是一個非常有意思的活動，但要組織好這樣的活動並非易事。一般有以下要點：

（1）儘管這是一個測試活動，但參與者並不僅限於測試人員。專案經理，開發人員甚至於高層管理員都應參加，如同全民動員。目的是要集思廣益；

（2）要鼓勵各部門，領域交叉搜尋，因為新的思路和視角通常有助於發現更多的Bug；

（3）為調動積極性，增強趣味性，可以適當引入競爭機制，比如當活動結束時，評出發現Bug最多，發現最嚴重Bug的個人，給以物質和精神獎勵。

（4）可以分專題展開，比如安全性、使用者介面可用性、國際化和本地化等等。

（5）as usual we'll have pizza and other fun food. Sometimes there's prizes for most bugs kept, most heinous bug, etc.

ZBB（零錯誤反彈）--軟體穩定的指標

為什麼要做Bug bash，其實與另一個測試方法有密切聯絡。在此之前，先說說錯誤收斂。

錯誤收斂

錯誤收斂是指項目組在減少活躍錯誤數量上取得了重大進步的一個轉折點。在錯誤收斂這一轉折點上，解決錯誤的速度超過了發現錯誤的速度；因此實際的活躍錯誤數量開始減少。給出了錯誤收斂的圖示。

即使錯誤數量從整體上開始減少，但具體數量還會出現升降變化，因此錯誤收斂通常來講只代表一種趨勢，而不是一個固定的時間點。在錯誤收斂之後，錯誤的數量將持續減少直到零錯誤反彈。

零錯誤反彈

Zero Bug Build：這一版本的構建把所有已知的bug都解決掉了。

Zero Bug Bounce：通常在一個Zero Bug Build之後，bug數目會以驚人的速度反彈，故稱Bounce。系統要經曆幾次bounce，像阻尼震蕩一樣，bug的數目在彈了幾次之後，最後固定在（或者無限逼近於） 0。要注意必須保證bug的數量要到0，以防止一些問題拖而未決。

是一個60人的團隊的“預想ZBB 進軍圖”。每個小組的bug數量累加起來，就是團隊的bug總量。圖中的黑線表明修複的bug總量。

零錯誤反彈是指在項目中的某一點上，開發活動最終趕上了測試的步伐，當前已經不存在活躍錯誤。在零錯誤反彈之後，錯誤數量的峰值將顯著減小，並且錯誤數量會持續減少直到產品足夠穩定，進而構建出第一個候選版版。取得零錯誤反彈是項目組逐漸接近穩定的候選版版的明確標誌。

注意，在到達這一裡程碑之後，必定還會發現新的錯誤。但是，它卻標誌著項目組能夠第一次誠實地報告已經不存在活躍錯誤了，雖然這隻是針對當前情況。而且它可以讓項目組集中力量保持在這一點上。

事實上，正是通過bug bash的方式，來達到ZBB的效果。

本次bug bash活動總結

本次bug bash總體效果不佳，真正參與人數不多，發現有效bug數量不算多，達不到bug bash的效果。總結原因如下：

1、大家並不真正理解以上所談的bug bash對於產品的意義，而僅僅將其當作一項臨時活動，積極性不高，這是首要原因。因此，大部分同事沒有全力投入進來，甚至是沒有參與，這就沒有達到bug bash活動的初衷；

2、活動召集人及部門經理在活動方式的理解不一致。在召集人發布了測試要求之後，部門經理並沒有及時向參加人員強調活動的必要性及強制性，而對於部門人員到底參加了bug bash沒有也不清楚，而召集人則認為部門經理會有良好的配合，事先做好這些事務安排工作；

3、活動缺乏良好的獎勵及競爭機制，無法調動大家參與的積極性；如果能有一些物質或精神獎勵，同時引入競爭機制，可以增加趣味性，調動積極性，真正做到真正寓工作於娛樂；

4、活動過程缺乏有效監督，對於沒有參加的同事，沒有進行有效監督；

5、產品穩定程度不高，影響測試的效率

希望在下次我們能有較大的改善！