要做好這樣的活動，首先我們必須明白這項活動的意義。
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總量。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
