在谷歌，質量不等於測試，是的，我確定在其他所有的公司也都是這樣。「質量不是被測出來的」，這句陳詞濫調是再正確不過的了。不管汽車製造還是 軟體開發，如果在最初的設計建造的時候就有問題，那它永遠都會有問題。試問任何一家曾經被迫大量召回汽車的公司，逃避質量問題的代價是多麼的昂貴。
但是，「質量不是被測出來的」這句話本身並不像它聽起來的那麼簡單和準確。雖然質量並不是被測出來的，但同樣也有證據表明，未經過測試，也不可能開發出有質量的產品。你連測試都沒有做過，又是怎麼知道產品功能是否正確，並有高質量呢？
對於這種難題，最簡單的辦法是不要區分開發和測試，不要把他們當成對立的活動。測試和開發
【譯註：兩種行為，不是人】
最好能手牽手的並行，寫一點 **就立刻進行測試，寫的越多，測的就要越多。最好是，在編碼的同時，甚至在編碼之前，就考慮清楚這些**將如何被測試。測試不是乙個單獨的工作，測試就 是開發的一部分。所以，質量並不等同於測試，當把開發和測試混在一起，攪拌直到分不清他們彼此的時候，就得到了質量。
這就是谷歌的想法，把開發和測試工作混在一起，不分彼此。寫點**，就必須測試，多寫一些就多測一些。關鍵的問題就是誰來做測試工作？ 由於谷歌的專職測試人員非常的少，唯一的答案就只能是開發人員。還有比實際寫**的開發人員更適合來測試這些**的人嗎？還有比程式的作者更懂得怎樣去發 現程式 bug 的嗎？是誰更想知道程式在第一次執行時是否有沒有問題呢？谷歌之所以用這麼少的專職測試人員的原因就是開發對質量負全責。實際上，如果乙個團隊在過於依賴 測試的時候，通常情況下這個團隊在開發上一定也會有問題。如果在這個團隊裡，測試人員比較多，這也是乙個強烈的訊號，這表明開發和測試融入到一起的程度還 不夠，失衡了，缺乏測試，單純地增加測試人員並不能解決任何問題。
這意味著，對於質量來說，預防問題比發現問題本身更重要。質量是開發人員的問題，而不是測試人員的問題。通過把測試工作融入到開發過程中，我們 能降低那些富產 bug 的人的出錯機會，不僅可以避免了大量終端使用者的使用問題，而且還可以極大地降低測試人員報無效 bug 的數量。在谷歌軟體測試工程師的工作目標就是檢查這種預防措施是否有效，軟體測試工程師不停地尋找一些證據來證明作為 bug 的作者和預防者的「軟體開發工程師-軟體測試開發工程師」組合是否存在問題，一旦發現任何不正常，就會拉響警笛。
這種開發和測試一體的場景隨處可見，不管是在**審核的時候問「你的測試呢？」，還是在廁所蹲坑裡張貼著的最佳測試實踐–臭名昭著的馬桶測試指南
【譯者注，參見 google test blog，有關於」testing on the toilet「的更多介紹】
。測試是開發過程中必不可少的一環，質量是開發和測試合體的產物。軟體開發工程師，軟體測試開發工程師，軟體測試工程師，所有 的人都是測試人員。
如果你所在的公司也想要做這種開發和測試的統一，請也給大家分享一下其中經驗和教訓。如果沒有，這將是乙個幫助你公司的機會：讓開發和質量划等 號。你大概知道諺語裡說的，雞和豬為了一頓有培根和雞蛋的早餐都樂於奉獻自己，但是豬卻犧牲了。好吧，這就是事實，嘗試跑到開發工程師那裡，對他們」哼哼 「（豬叫聲）兩聲，看他們是否也用」哼哼「來回應，如果他們」咯咯噠「（雞叫聲）來回應，那就說明有問題了。
【譯者注，崩潰了，這裡比較難懂。james 這裡引用了乙個豬和雞的英語諺語，（參見，
），諺語的意思大概是，豬和雞都參與製作培根雞蛋早餐，豬變成了豬肉（培根），雞只下了乙個蛋，說明對於早餐，豬和雞的奉獻程度是不同的。並在這裡把測試 工程師比喻成雞，開發工程師比喻成豬，早餐就是質量，豬的奉獻大。測試人員跑到開發人員那裡，如果發現他們沒有做豬的事情，早餐將做不成，那說明質量也將 會有問題。】
【四】
爬，走，跑。
這裡的這個改進過程，並不像西部牛仔那樣，一下子什麼都能搞出來。實際上，乙個產品為了達到我們稱之為 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 各版本的稱呼，可以參見
，其中也涉及到本文中各個版本的稱呼，但並不是與 james 文中完全一致，實際上像金絲雀版本，一些喜歡嘗鮮的外部使用者也在使用】
Google 是如何做負載均衡的？
google 使用的技術一般都自帶光環，吸引程式設計師的注意，基礎設施方面的東西就更是如此，年初 google 發布了篇 介紹內部的負載均衡器的實現，讓我們有機會一睹可能是全球最好的負載均衡器。通常情況下的負載均衡要在靈活性和效能之間做權衡，使用者態軟體層面有 haproxy 和 nginx 這樣的...
如何做效能測試？
一提到效能測試，大家首先想到的就是測試工具，很多人認為效能測試就是使用測試工具，會使用測試工具就是會效能測試，我認為這種思想是不對的。什麼叫效能測試呢？效能測試是通過自動化的測試工具模擬多種正常 峰值以及異常負載條件來對系統的各項效能指標進行測試。測試工具只是用於模擬某些特定的情況的，模擬出某些情況...
如何做報表測試
報表測試根據專案的定義有大有小,有時只是作為軟體的乙個部分進行測試,有時整個專案都是測試各種報表.但不論如何,報表的作用始終都是將系統中已經存在的資料根據使用者的設定計算加工 整理彙總 最終以清晰的格式展示給使用者,以便使用者進一步做資料分析或統計.軟體中的報表實現一般分為定義報表的所需資料 一般可...