15.11 向ZBB進(jìn)軍
啥是ZBB？即：
Zero Bug Build：這一版本的構(gòu)建把所有已知的bug都解決掉了。
Zero Bug Bounce：通常在一個(gè)Zero Bug Build之后，bug數(shù)目會(huì)以驚人的速度反彈，故稱Bounce。系統(tǒng)要經(jīng)歷幾次bounce，像阻尼震蕩一樣，bug的數(shù)目在彈了幾次之后，最后固定在（或者無限逼近于） 0。
要注意必須保證bug的數(shù)量要到0，以防止一些問題拖而未決。
圖15-8是一個(gè)60人的團(tuán)隊(duì)的“預(yù)想ZBB 進(jìn)軍圖”。每個(gè)小組的bug數(shù)量累加起來，就是團(tuán)隊(duì)的bug總量。圖中的黑線表明修復(fù)的bug總量。
圖15-8ZBB計(jì)劃圖
小飛：我注意到這一條預(yù)想變化線（到11/11為0）不是一條直線，好像中間斷斷續(xù)續(xù)有一些平的階段。
阿超：看起來是每星期的周末，理論上周末兩天沒有人上班，因此團(tuán)隊(duì)也沒有期望在周末的時(shí)候bug 數(shù)量會(huì)自動(dòng)下降。
小飛：還是比較人性化。
阿亨：我有一個(gè)問題，測(cè)試人員每天都有新的bug 要報(bào)告，開發(fā)人員修復(fù)一個(gè)缺陷需要走大約一天左右的流程，等到第二天的時(shí)候，又會(huì)有新的bug 產(chǎn)生，所以這個(gè)“零”只是一個(gè)一瞬間的狀態(tài)，或者根本不能實(shí)現(xiàn)？
阿超：這里有一個(gè)技術(shù)細(xì)節(jié)，大部分的團(tuán)隊(duì)，都是這樣定義的：在這一時(shí)刻，我們系統(tǒng)內(nèi)沒有N天以前創(chuàng)建同時(shí)又是Active 的bug。N 一般是2天。用移山項(xiàng)目的例子來說，就是：
Stone項(xiàng)目ZBB =此次構(gòu)建中所有2天以前報(bào)告的缺陷都已經(jīng)處理。
移山公司的例子：
第一個(gè)ZBB，劃了線，達(dá)到了。同時(shí)產(chǎn)生了一個(gè)ZBB 的構(gòu)建，由于這個(gè)構(gòu)建質(zhì)量很好，因此測(cè)試團(tuán)隊(duì)鉚足了勁把各個(gè)部分都測(cè)試了一遍。同時(shí)也測(cè)試了復(fù)雜的場(chǎng)景，進(jìn)行了效能和壓力測(cè)試。結(jié)果報(bào)告出來不少新問題。因此ZBB 中的Bounce就跳得特別高。第二次ZBB 后，由于各個(gè)模塊質(zhì)量的提高，這一次的反彈就低很多，隨著每次ZBB過程中質(zhì)量的加強(qiáng)，bug 的數(shù)目會(huì)越來越少。同時(shí)也有幾個(gè)功能被砍掉，這些功能的bug 也就不計(jì)入總數(shù)。因此ZBB 的趨勢(shì)圖顯示了bug 經(jīng)過幾次反彈，逐漸到0的情況（如圖15-9所示）。
圖15-9bug ZBB趨勢(shì)圖，橫坐標(biāo)是構(gòu)建的版本號(hào)
15.11.1最后回歸測(cè)試
在臨近項(xiàng)目結(jié)束的時(shí)候，所有人員（開發(fā)、管理、測(cè)試）都要回歸測(cè)試所有的bug。每個(gè)人都要幫助團(tuán)隊(duì)確保這些bug 的確是被修復(fù)了。而且別的更改沒有導(dǎo)致功能的“回歸”。從便于管理考慮，我們可以再加入一個(gè)新的字段標(biāo)記某bug已經(jīng)被回歸測(cè)試過。
15.11.2凍結(jié)
隨著程序功能的完善，我們要讓程序的各個(gè)方面有次序地“凍結(jié)”，這樣才能把穩(wěn)定的軟件交付給用戶。一般來說，程序的人機(jī)交互界面最先開始“凍結(jié)”，不能再隨意修改，因?yàn)楹芏囗?xiàng)目的文字信息要被本地化成多種語(yǔ)言，當(dāng)人機(jī)界面所用的文字和排版（layout） 固定后，我們才能把這些文字交給負(fù)責(zé)本地化的部門。隨著時(shí)間的推移，一些功能也可以“凍結(jié)”，這些功能都經(jīng)過全面測(cè)試，所有的bug 都解決了，功能進(jìn)入穩(wěn)定狀態(tài)。在下一個(gè)版本前不要再碰和此功能相關(guān)的代碼。
15.11.3侵官之害甚于寒
昔者韓昭候醉而寢，典冠者見君之寒也，故加衣于君之上，覺寢而說，問左右曰：“誰(shuí)加衣者？”左右對(duì)曰：“典冠。”君因兼罪典衣與典冠。其罪典衣，以為失其事也；其罪典冠，以為越其職也。非不惡寒也，以為侵官之害甚于寒。
——《韓非子·二柄第七》
九條：（來找阿超）我最近新建了不少bug，今天發(fā)現(xiàn)它們都變成了closed，本來要測(cè)試的bug 都變成了關(guān)閉狀態(tài)，我還用測(cè)試么？
阿超：是別的測(cè)試人員替你測(cè)試了么？
九條：沒有，從記錄上看是果凍修改了這些缺陷，然后把狀態(tài)變成resolved，過了兩天他又把狀態(tài)變成 closed，但是我還沒有運(yùn)行驗(yàn)證測(cè)試呢。
他們把果凍找來了。
果凍：我是看著我的bug 老是沒有關(guān)閉，心里很著急，然后昨天我就認(rèn)真地把所有bug 驗(yàn)證了一遍，確信沒有問題后，就把它們順手關(guān)閉了。
九條：是不是你的領(lǐng)導(dǎo)在統(tǒng)計(jì)你的bug 數(shù)目了？呵呵。
阿超：不同的角色在開發(fā)過程中有相互合作，相互制約的作用，不能替代。測(cè)試人員在做驗(yàn)證測(cè)試時(shí)，需要做多方面、多平臺(tái)的測(cè)試，這些工作量，也許遠(yuǎn)遠(yuǎn)超過了開發(fā)人員的能力范圍。因此，必須要由測(cè)試人員來驗(yàn)證并處理已經(jīng)修理好的bug。
侵官之害甚于寒——我們不是不鼓勵(lì)開發(fā)人員主動(dòng)幫助測(cè)試，我們是要避免導(dǎo)致職責(zé)不清的越界行為。
鄂公網(wǎng)安備 42010302001612號(hào)