?
前言：經(jīng)過前兩篇的介紹之后，評(píng)論里留下許多問題。并沒有逐一回復(fù)，當(dāng)然不是想把這些評(píng)論置之不理，而是希望在這里和后面的文章中做詳細(xì)介紹和解釋這些問題。從這一篇開始，我將開始講谷歌是如何測試軟件的了。
在谷歌，質(zhì)量不等于測試，是的，我確定在其他所有的公司也都是這樣。“質(zhì)量不是被測出來的”，這句陳詞濫調(diào)是再正確不過的了。不管汽車制造還是 軟件開發(fā)，如果在最初的設(shè)計(jì)建造的時(shí)候就有問題，那它永遠(yuǎn)都會(huì)有問題。試問任何一家曾經(jīng)被迫大量召回汽車的公司，逃避質(zhì)量問題的代價(jià)是多么的昂貴。
但是，“質(zhì)量不是被測出來的”這句話本身并不像它聽起來的那么簡單和準(zhǔn)確。雖然質(zhì)量并不是被測出來的，但同樣也有證據(jù)表明，未經(jīng)過測試，也不可能開發(fā)出有質(zhì)量的產(chǎn)品。你連測試都沒有做過，又是怎么知道產(chǎn)品功能是否正確，并有高質(zhì)量呢？
對(duì)于這種難題，最簡單的辦法是不要區(qū)分開發(fā)和測試，不要把他們當(dāng)成對(duì)立的活動(dòng)。測試和開發(fā)【譯注：兩種行為，不是人】最好能手牽手的并行，寫一點(diǎn) 代碼就立刻進(jìn)行測試，寫的越多，測的就要越多。最好是，在編碼的同時(shí)，甚至在編碼之前，就考慮清楚這些代碼將如何被測試。測試不是一個(gè)單獨(dú)的工作，測試就 是開發(fā)的一部分。所以，質(zhì)量并不等同于測試，當(dāng)把開發(fā)和測試混在一起，攪拌直到分不清他們彼此的時(shí)候，就得到了質(zhì)量。
這就是谷歌的想法，把開發(fā)和測試工作混在一起，不分彼此。寫點(diǎn)代碼，就必須測試，多寫一些就多測一些。關(guān)鍵的問題就是誰來做測試工作？ 由于谷歌的專職測試人員非常的少，唯一的答案就只能是開發(fā)人員。還有比實(shí)際寫代碼的開發(fā)人員更適合來測試這些代碼的人嗎？還有比程序的作者更懂得怎樣去發(fā) 現(xiàn)程序 bug 的嗎？是誰更想知道程序在第一次運(yùn)行時(shí)是否有沒有問題呢？谷歌之所以用這么少的專職測試人員的原因就是開發(fā)對(duì)質(zhì)量負(fù)全責(zé)。實(shí)際上，如果一個(gè)團(tuán)隊(duì)在過于依賴 測試的時(shí)候，通常情況下這個(gè)團(tuán)隊(duì)在開發(fā)上一定也會(huì)有問題。如果在這個(gè)團(tuán)隊(duì)里，測試人員比較多，這也是一個(gè)強(qiáng)烈的信號(hào)，這表明開發(fā)和測試融入到一起的程度還 不夠，失衡了，缺乏測試，單純地增加測試人員并不能解決任何問題。
這意味著，對(duì)于質(zhì)量來說，預(yù)防問題比發(fā)現(xiàn)問題本身更重要。質(zhì)量是開發(fā)人員的問題，而不是測試人員的問題。通過把測試工作融入到開發(fā)過程中，我們 能降低那些富產(chǎn) Bug 的人的出錯(cuò)機(jī)會(huì)，不僅可以避免了大量最終用戶的使用問題，而且還可以極大地降低測試人員報(bào)無效 Bug 的數(shù)量。在谷歌軟件測試工程師的工作目標(biāo)就是檢查這種預(yù)防措施是否有效，軟件測試工程師不停地尋找一些證據(jù)來證明作為 bug 的作者和預(yù)防者的“軟件開發(fā)工程師-軟件測試開發(fā)工程師”組合是否存在問題，一旦發(fā)現(xiàn)任何不正常，就會(huì)拉響警笛。
這種開發(fā)和測試一體的場景隨處可見，不管是在代碼審核的時(shí)候問“你的測試呢？”，還是在廁所蹲坑里張貼著的最佳測試實(shí)踐–臭名昭著的馬桶測試指南【譯者注，參見 google test blog，有關(guān)于”Testing On The Toilet“的更多介紹】。測試是開發(fā)過程中必不可少的一環(huán)，質(zhì)量是開發(fā)和測試合體的產(chǎn)物。軟件開發(fā)工程師，軟件測試開發(fā)工程師，軟件測試工程師，所有 的人都是測試人員。
如果你所在的公司也想要做這種開發(fā)和測試的統(tǒng)一，請(qǐng)也給大家分享一下其中經(jīng)驗(yàn)和教訓(xùn)。如果沒有，這將是一個(gè)幫助你公司的機(jī)會(huì)：讓開發(fā)和質(zhì)量劃等 號(hào)。你大概知道諺語里說的，雞和豬為了一頓有培根和雞蛋的早餐都樂于奉獻(xiàn)自己，但是豬卻犧牲了。好吧，這就是事實(shí)，嘗試跑到開發(fā)工程師那里，對(duì)他們”哼哼 “（豬叫聲）兩聲，看他們是否也用”哼哼“來回應(yīng)，如果他們”咯咯噠“（雞叫聲）來回應(yīng)，那就說明有問題了。
【譯者注，崩潰了，這里比較難懂。James 這里引用了一個(gè)豬和雞的英語諺語，（參見，http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig?），諺語的意思大概是，豬和雞都參與制作培根雞蛋早餐，豬變成了豬肉（培根），雞只下了一個(gè)蛋，說明對(duì)于早餐，豬和雞的奉獻(xiàn)程度是不同的。并在這里把測試 工程師比喻成雞，開發(fā)工程師比喻成豬，早餐就是質(zhì)量，豬的奉獻(xiàn)大。測試人員跑到開發(fā)人員那里，如果發(fā)現(xiàn)他們沒有做豬的事情，早餐將做不成，那說明質(zhì)量也將 會(huì)有問題。】
【四】
爬，走，跑。
在比其他公司少很多測試人員的情況下，谷歌做的還不錯(cuò)的一個(gè)關(guān)鍵原因是，很少嘗試在一次發(fā)布中包含很多的功能。實(shí)際上，谷歌經(jīng)常反其道而行之， 在一個(gè)產(chǎn)品的核心模塊被開發(fā)后，如果有一定數(shù)量的受益人群就立刻發(fā)布，然后不斷的得到用戶反饋再迭代開發(fā)新功能。這也是我們?cè)?Gmail 上的做法，Gmail 被貼上 Beta 版本的標(biāo)簽在線上運(yùn)營了四年。通過這個(gè) Beta 標(biāo)簽也可以來警示用戶，Gmail 還并非完美的產(chǎn)品，有出錯(cuò)的可能。只有當(dāng)郵件數(shù)據(jù)達(dá)到 99.99% 的時(shí)間都是可用的時(shí)候，我們目標(biāo)就算達(dá)到了，這個(gè) Beta 標(biāo)簽才會(huì)被去除。很明顯，質(zhì)量是一個(gè)不斷改進(jìn)的過程。
這里的這個(gè)改進(jìn)過程，并不像西部牛仔那樣，一下子什么都能搞出來。實(shí)際上，一個(gè)產(chǎn)品為了達(dá)到我們稱之為 Beta 的版本，也要經(jīng)歷一系列的過程，并在過程中證明其價(jià)值。Chrome 是我加入谷歌前兩年一直所工作的團(tuán)隊(duì)，它同樣經(jīng)歷了多個(gè)版本。在每個(gè)版本里，基于對(duì)產(chǎn)品質(zhì)量的信心和不斷尋求的客戶反饋才讓我們進(jìn)入到下一個(gè)版本。這些版 本歷程大致如下：
金絲雀版本（Canary Channel），不太可靠的版本，并不適用于發(fā)布。就像一只金絲雀在煤堆里一樣，如果不幸身亡，那說明還有工作要去做。只有超強(qiáng)容忍能力的用戶才有可能使用金絲雀版本來試驗(yàn)運(yùn)行，你不能依賴這樣的應(yīng)用能把實(shí)際工作完成。
開發(fā)版本（Dev Channel)，是開發(fā)工程師們?nèi)粘９ぷ髦惺褂玫陌姹尽Ｋ械耐划a(chǎn)品組的工程師都需要去安裝這個(gè)版本，并在真正的工作中使用他們。
測試版本（Test Channel），是給內(nèi)部的狗食，如果能夠有持續(xù)不錯(cuò)的性能表現(xiàn)的話，也可能會(huì)是 beta 版本的候選。【譯者注，dog food，一般指自己團(tuán)隊(duì)的產(chǎn)品，給自己或者公司內(nèi)部的人嘗試使用的中間產(chǎn)品】
Beta 版本或發(fā)布版本(The Beta Channel or Release Channel)，是給外部用戶使用的第一個(gè)版本。只有在之前的各種版本歷程中通過了測試和真實(shí)用戶的槍林彈雨般的驗(yàn)證后，才會(huì)成為 beta 版。
上述的這種從爬到走、走到跑的模式，讓我們?cè)谶\(yùn)行一些測試同時(shí)又可以對(duì)我們的應(yīng)用系統(tǒng)做一些試驗(yàn)調(diào)整，并從真實(shí)用戶和每個(gè)版本的每日自動(dòng)化測試那里得到及時(shí)的反饋。
對(duì)于這樣的過程，還有一些分析角度的益處。例如，發(fā)現(xiàn)了一個(gè) bug，測試人員可以根據(jù)這個(gè) bug 創(chuàng)建一個(gè)測試用例，并針對(duì)所有的每一個(gè)版本都運(yùn)行這個(gè)測試用例，從而可以驗(yàn)證這個(gè) bug fix 是否在所有的版本中都真正得到了修復(fù)。
【譯者注：關(guān)于 Chrome 與 Chrome OS 各版本的稱呼，可以參見http://www.chromi.org/chromedownload?，其中也涉及到本文中各個(gè)版本的稱呼，但并不是與 James 文中完全一致，實(shí)際上像金絲雀版本，一些喜歡嘗鮮的外部用戶也在使用】
?
By James Whittaker
●How Google Tests Software – Part Three
●How Google Tests Software – Part Four
?
?
轉(zhuǎn)載自伯樂在線http://blog.jobbole.com/15791/
已有 0 人發(fā)表留言，猛擊->>這里<<-參與討論