15.11 向ZBB進軍

　　啥是ZBB？即：

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

　　Zero Bug Bounce：通常在一個Zero Bug Build之后，bug數(shù)目會以驚人的速度反彈，故稱Bounce。系統(tǒng)要經(jīng)歷幾次bounce，像阻尼震蕩一樣，bug的數(shù)目在彈了幾次之后，最后固定在（或者無限逼近于） 0。

　　要注意必須保證bug的數(shù)量要到0，以防止一些問題拖而未決。

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

圖15-8ZBB計劃圖

　　小飛：我注意到這一條預想變化線（到11/11為0）不是一條直線，好像中間斷斷續(xù)續(xù)有一些平的階段。

　　阿超：看起來是每星期的周末，理論上周末兩天沒有人上班，因此團隊也沒有期望在周末的時候bug 數(shù)量會自動下降。

　　小飛：還是比較人性化。

　　阿亨：我有一個問題，測試人員每天都有新的bug 要報告，開發(fā)人員修復一個缺陷需要走大約一天左右的流程，等到第二天的時候，又會有新的bug 產(chǎn)生，所以這個“零”只是一個一瞬間的狀態(tài)，或者根本不能實現(xiàn)？

　　阿超：這里有一個技術(shù)細節(jié)，大部分的團隊，都是這樣定義的：在這一時刻，我們系統(tǒng)內(nèi)沒有N天以前創(chuàng)建同時又是Active 的bug。N 一般是2天。用移山項目的例子來說，就是：

　　Stone項目ZBB =此次構(gòu)建中所有2天以前報告的缺陷都已經(jīng)處理。

　　移山公司的例子：

　　第一個ZBB，劃了線，達到了。同時產(chǎn)生了一個ZBB 的構(gòu)建，由于這個構(gòu)建質(zhì)量很好，因此測試團隊鉚足了勁把各個部分都測試了一遍。同時也測試了復雜的場景，進行了效能和壓力測試。結(jié)果報告出來不少新問題。因此ZBB 中的Bounce就跳得特別高。第二次ZBB 后，由于各個模塊質(zhì)量的提高，這一次的反彈就低很多，隨著每次ZBB過程中質(zhì)量的加強，bug 的數(shù)目會越來越少。同時也有幾個功能被砍掉，這些功能的bug 也就不計入總數(shù)。因此ZBB 的趨勢圖顯示了bug 經(jīng)過幾次反彈，逐漸到0的情況（如圖15-9所示）。

圖15-9bug ZBB趨勢圖，橫坐標是構(gòu)建的版本號

　　15.11.1最后回歸測試

　　在臨近項目結(jié)束的時候，所有人員（開發(fā)、管理、測試）都要回歸測試所有的bug。每個人都要幫助團隊確保這些bug 的確是被修復了。而且別的更改沒有導致功能的“回歸”。從便于管理考慮，我們可以再加入一個新的字段標記某bug已經(jīng)被回歸測試過。

　　15.11.2凍結(jié)

　　隨著程序功能的完善，我們要讓程序的各個方面有次序地“凍結(jié)”，這樣才能把穩(wěn)定的軟件交付給用戶。一般來說，程序的人機交互界面最先開始“凍結(jié)”，不能再隨意修改，因為很多項目的文字信息要被本地化成多種語言，當人機界面所用的文字和排版（layout） 固定后，我們才能把這些文字交給負責本地化的部門。隨著時間的推移，一些功能也可以“凍結(jié)”，這些功能都經(jīng)過全面測試，所有的bug 都解決了，功能進入穩(wěn)定狀態(tài)。在下一個版本前不要再碰和此功能相關(guān)的代碼。

　　15.11.3侵官之害甚于寒

　　昔者韓昭候醉而寢，典冠者見君之寒也，故加衣于君之上，覺寢而說，問左右曰：“誰加衣者？”左右對曰：“典冠。”君因兼罪典衣與典冠。其罪典衣，以為失其事也；其罪典冠，以為越其職也。非不惡寒也，以為侵官之害甚于寒。

　　——《韓非子·二柄第七》

　　九條：（來找阿超）我最近新建了不少bug，今天發(fā)現(xiàn)它們都變成了closed，本來要測試的bug 都變成了關(guān)閉狀態(tài)，我還用測試么？

　　阿超：是別的測試人員替你測試了么？

　　九條：沒有，從記錄上看是果凍修改了這些缺陷，然后把狀態(tài)變成resolved，過了兩天他又把狀態(tài)變成 closed，但是我還沒有運行驗證測試呢。

　　他們把果凍找來了。

　　果凍：我是看著我的bug 老是沒有關(guān)閉，心里很著急，然后昨天我就認真地把所有bug 驗證了一遍，確信沒有問題后，就把它們順手關(guān)閉了。

　　九條：是不是你的領(lǐng)導在統(tǒng)計你的bug 數(shù)目了？呵呵。

　　阿超：不同的角色在開發(fā)過程中有相互合作，相互制約的作用，不能替代。測試人員在做驗證測試時，需要做多方面、多平臺的測試，這些工作量，也許遠遠超過了開發(fā)人員的能力范圍。因此，必須要由測試人員來驗證并處理已經(jīng)修理好的bug。

　　侵官之害甚于寒——我們不是不鼓勵開發(fā)人員主動幫助測試，我們是要避免導致職責不清的越界行為。