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