對 Google軟體測試之道的讚揚

“James Whittaker早就掌握了能型塑測試實作的議題之脈動。在轉換到雲端服務

的這十個年頭裡，這本書不僅已成為 Google員工必須要讀的書，也是所有想讓

自己的實作更精準、更具競爭力且更有意義的軟體測試工作者們必讀的書。＂

― Sam Guckenheimer

微軟 Visual Studio策略部產品經理

“在軟體測試領域中，不論是在混合自動化測試與手動測試、結合內部或外包

的資源，還是最近率先採用實地測試以強化在實驗室所產生的結果等方面，

Google一直勇於創新。這種追求創新的態度，讓 Google有能力可以解決新型

態的問題，進而推出更好的應用軟體。

在本書中，James Whittaker提出了 Google之所以能在軟體測試領域瞬息萬

變的環境中，立於不敗之地的藍圖。＂

― Doron Reuveni uTest公司執行長與共同創辦人

“從每天發行到那些顯示在螢幕上的，都受到這本書的影響。James Whittaker

以電腦科學的角度切入測試，這些方法未來將成為軟體公司所遵循的標準。我

們在 Google裡頭所採用的程序與創新技術都會真實而有趣地呈現在您的眼前。

這是所有與軟體開發有關的人士都必須閱讀的一本書。＂

― Michael Bachman

Google AdSense/Display資深工程經理

“透過記錄許多 Google測試工程實踐的神妙之處，作者完成了相當於現代軟體

測試慾經的經典之作。＂

― Alberto Savoia

Google工程部主任

“如果您需要將程式碼往雲端上送，而且想要建立一套策略以確保產品的品質並

讓客戶滿意，那您一定要研讀本書，深究其中所提到的各種方法。＂

― Phil Waligora

Salesforce.com

“在軟體測試領域中，James Whittaker啟發了許多人的靈感，是導師級人物。

少了他的貢獻，這個領域裡頭就等於沒有了大師與技術。我一直很祟拜這位充

滿幹勁、熱情又幽默的人士。他是這個領域的巨擘，IT產業中的每一個人都應

該閱讀他的作品。＂

― Stewart Noakes

英國 TCL集團主席

“我曾與 James Whittaker在微軟共事過，雖然我很想可以一直在微軟裡頭與他

共事，但我知道他在 Google將作出一番豐功偉業。James、Jason Arbon與 Jeff

Carollo把許多嶄新的測試理念、實際的範例與對 Google測試機的剖析都裝進

了這本書。只要對 Google的軟體測試方法與品質有一點點好奇或者只是想找一

些軟體測試新想法的人，都可以在這些書頁中獲益。＂

― Alan Page

微軟 Xbox團隊‧微軟軟體測試之道作者

xi前言 ─ Alberto Savoia

前言 ― Alberto Savoia

為一本你希望那是自己所寫的書來寫序，你會有一種怪怪的榮譽感；它就

有點像為一個下輩子都會與你要娶的女人糾纏不清的朋友賣命那樣。James

Whittaker是一個狡猾的傢伙，在問我是不是願意為這本書寫序之前，他利用

我無法抗拒墨西哥美食的弱點，先請我吃頓很棒的晚餐，然後在“提出那個問

題＂之前，讓我灌了許多 Dos Equis啤酒。當他提出要求的時候，我也只能像

眼前裝著我剛吃完的鱷梨沙拉的碗那樣，乖乖地順從人意。我大概也只能說

“好吧，先生。＂他的計謀很成功，他帶著就像是他的新娘的這本書到我跟前

來，我也就只好上台致詞祝福這對新人了。

就跟我之前說的那樣，他是一個狡猾的傢伙。

所以我們就來看看這篇…為希望是我自己寫的書所寫的序文。把那浪漫的婚

禮樂曲給奏上來吧！

這個世上是否真的需要另一本軟體測試的書，特別是這本由我常在公開場合

稱呼他為“出版測試書籍的八產媽（Octomon，註 1）＂的多產 James Whittaker

所寫的軟體測試書？外頭那些描述著類似的舊式並令人厭煩的測試方法論以及

強調一些含糊的、過時的建議的書籍，難道還不夠多嗎？嗯，這類的書的確已

經夠多了，不過我認為這本書應該不屬於這一類的書。這就是為什麼我多麼希

望這本書是我自己所寫出來的原因。世上確實需要這本獨特的談軟體測試的書。

網際網路已戲劇性地改變了大多數軟體的設計、開發與發佈的方法。在許多

過去曾經受到歡迎的書籍裡頭所體現的測試最佳實踐法，在現今的環境中，已

經變得不再那麼有效率、沒有效率，或者在某些情況下，根本就會產生不良的

影響。在我們的產業之中，事物是變化得如此快速，以致於許多在最近幾年所

寫的軟體測試書籍，變得像是給我們關於寄生蟲與頭顱訓練建議的外科手術書

那樣，企圖讓我們的身體免除於惡靈的侵擾；最好把它們跟成人紙尿褲一起回

收了，免得被它們給弄糊塗了。

1 不瞭解八產媽是什麼嗎？請 Google一下。

xii Google軟體測試之道

因為軟體產業裡頭，事物演化的速度相當快，我一點都不會為十年後這本書

將會過時而感到訝異。不過在下一次的典範轉移（paradigm shifts）來臨之前，

Google 的軟體測試之道會讓您看到一位內行人，以及時且實用角度來剖析一家

全世界最成功且成長最快速的網際網路公司，如何在 21世紀處理軟體測試獨特

挑戰的方法。James Whittaker與他的共同作者們已經掌握了 Google在測試一

些我們這個時代中最複雜也最受歡迎的軟體時，所運用的一些基本要素。我身

處在這個轉變當中，所以我知道這些。

我在 2001年以工程主管的身份加入 Google。當時，我們大概有二百位開發

者與高達…三個測試者！我的開發者們負責測試他們自己所寫的程式碼，但測

試導向（test-driven）的開發方法與像 JUnit這樣的自動測試工具也才剛加入戰

場，所以我們的測試工作大部份是隨意（ad-hoc）而且要靠個別勤勞的工作人

員來編寫這些程式碼。但這樣還好；我們是家新創公司，不但要動作快也得用

一些險招，否則我們無法與那些威名顯赫的大咖們競爭。

不過當公司的規模擴大，我們的產品變得愈來愈像是使用者與客戶成功與否

的關鍵（像我負責的其中一個產品 AdWords，已經迅速地成為商機的來源網

站）時，我們必須增加更多的關注與投資到測試上。在只有三位測試人員情況

下，我們別無選擇，只能找來更多的開發人員投入到測試當中。對幾位 Google

人，我介紹、教，並推廣單元測試（unit testing）。我們鼓勵開發人員將測試

視為一個優先項目，並使用像 JUnit這樣的工具來實現測試自動化。不過為人

所接受的過程很緩慢，而且並不是每位開發者都覺得應該自行測試自己所寫的

程式碼。為了能讓這個動能持續，每個禮拜在公司的週五午後啤酒檢討會（叫

TGIF比較恰當）裡頭，我會提供測試獎賞給那些編寫測試碼的開發者。這聽來

就像是一位動物訓練師在小狗表演雜耍後餵零食吃那樣，不過至少它讓大家注

意到測試了。難道我就這麼幸運，這麼簡單就能讓開發者開始搞測試？

很不幸地，這個小把戲沒有發揮作用。開發者瞭解到，為了要能對程式進行

足夠的測試，他們得要為每一行需測試的程式碼編寫二到三行的單元測試碼，

而且也要像功能程式碼本身那樣維護這些測試程式碼，當然也會有相當的機會

讓整個程式包含了一些臭蟲。另外，就如大家可以想見的，只有開發者 -單元

測試（developer-unit testing）是不夠的。我們還是需要整合測試（integration

tests）、系統測試（system tests）以及 UI測試等等。面臨測試時，我們還有許

多成長空間（和大量的學習），而且我們動作要快，要很快！

xiii前言 ─ Alberto Savoia

何以如此緊急？嗯，我不相信做這些測試就能把差勁的想法或思慮不週的產

品變好。但我確實相信不對的測試方法會讓一項好產品或公司錯失良機，或者

至少讓自身的成長趨緩，讓對手有機可乘。當時 Google就處於那個時間點上。

測試變成了延續成功的一個最大障礙。要能跟得上使用者、產品以及員工數量

的超快速成長而不讓公司慢下來，這需要許多創新的方法、新型態的解決方案

與獨特的工具。當然，並不是所有事都行得通，不過在過程中，我們學到了許

多寶貴的教訓與經驗，而這些是所有像 Google這樣快速成長與前進的公司可借

鏡的。我們瞭解如何不需盯著開發過程看就可以注意品質，也知道我們能夠多

快把事情做好。帶著對背後隱藏想法的洞察力與讓它們之所以可行的因素，本

書所談的就是這整個過程的結果。如果您想瞭解 Google如何面對 21世紀在現

代網際網路、行動運算與客戶端程式方面所遇上的測試挑戰，那真是找對地方

了。我真希望我也能來談談其他的一些故事，不過 James與他的協同作者們比

我更合適，他們掌握了在 Google裡頭實行測試的本質。

最後值得注意的是：James Whittaker是創造出這本書的人。他加入 Google，

融入到其文化之中、進行重大的開發專案，而且推出了像 Chrome、Chrome

OS，以及不少小一點的優質產品。有些時候，他甚至成為了 Google測試領域

方面的代表人物。不過，不同於他所著的其他書籍，本書中的許多素材都不是

他自己的。他是 Google如何測試軟體革新的貢獻者之一，但也是一位報導者。

在您閱讀本書時，請您記得這件事，因為 James可能會試著把所有的功勞都攬

在他身上！

就在 Google的規模從 200名員工擴展到 20,000名員工的同時，有許多人在

開發工作上扮演著很重要的角色，而且也對我們的測試策略作出許多貢獻。

James記錄了許多事蹟，有些同仁直接參與編寫側欄內容，而且其受訪過程也

記錄在本書當中。不過，沒有任何一個在本書中被提及的人物，不是我，也不

是 James，能像我們目前組織結構的架構師與 Google生產力工程團隊的領導者

Patrick Copeland這樣，對這些有這麼重大的影響。公司裡頭每一位測試者的報

告都要經過 Patrick，他就是那個執行長，其遠見造就了 James在本書所紀錄的

與所作出的貢獻。如果有人可以讓我們把現今 Google如何測試軟體的功勞記在

他頭上的話，那，那個人非 Patrick莫屬。我不只是因為他是我的頂頭上司才這

樣說；我會這樣說是因為他是我的上司，而且他也交待我要這樣說！

xiv Google軟體測試之道

Alberto Savoia 是 Google 的一位工程主管，也是創新的推動者。他在 2001

年時加入 Google，主要負責推出 Google AdWords服務，是公司裡推動開發

者 /單元測試文化的關鍵人物。他也是測試大師之道（The Way of Testivus）與O’Reilly出版的美麗程式（Beautiful Code）中“美麗測試＂的作者。

James Whittaker的註記：我非常贊同！作為這整個過程的一位描述者或記

者，我要將大部份的這些內容歸功於 Patrick創建的這個組織。而且我不只是因

為他授權給我寫這本書才這樣說的，他是我老闆，這本書是他讓我寫的！

xv前言 ─ Patrick Copeland

前言 ― Patrick Copeland

我與 Google一起經歷的冒險於 2005年的三月展開。如您已經看了 Alberto

為本書所寫的序，就知道一些當時 Google的情況。雖然它是家小公司，但已經

出現嚴重的成長問題。當時也是網際網路世界中動態內容開始大量出現，雲端

服務開始成為客戶 -伺服架構（client-server）可行的替代方案且於後凌駕於其

上的時刻。

第一個禮拜，我與一些頭頂著三色螺旋帽剛加入 Google的菜鳥們（Nooglers）

一起聆聽創辦人在討論關於公司管理策略中，被稱為 TGIF，於每週定期舉行的

例行聚會。我不太清楚為何自己會一頭栽進去。我天真地感到興奮而且也確信

自己對該領域有足夠的瞭解。Google成長的速度與規模，讓我之前十年的那種

每五年推出產品的經驗，看來毫無招架之力。更慘的是，我覺得我是那些戴著

三色螺旋帽的人當中唯一的測試人員。

我加入 Google時，工程部僅有 1,000人。測試團隊有大約 50位全職與一些

我沒見過的臨時工作人員。這個團隊被稱為“測試服務（Testing Services）＂，

專注在 UI的驗證工作，以及在需要時參與一些專案。如您所想像的，當時它完

全不會是 Google最看重的團隊。

在當時，這個團隊足敷需求。Google主要的業務為 Search與 Ads。規模比現

在的 Google要小許多，把偵測性質的測試工作做好，就可以滿足大部份對品

質的要求。不過世界正在慢慢地轉變。連上網際網路的使用者人數達到了空前

未有的數量，文件型的網頁也正漸漸為應用程式型的網頁所掩蓋。您可以感受

到成長和改變的必然性，有能力去調控並讓產品儘快問市的能力，會成為成功

與…一個您最不想要的東西之間最大的差異。

在 Google內部，具相當規模而且又複雜的問題，一直阻礙著測試服務的發

展。當測試人員忙著為接續而來的專案救火時，即使一份運作正常且單純的專

案，也會讓他們焦頭爛額。快速地將產品推出向來是 Google的堅持。有些事

需要改變，而我可以在繼續推動這種土法鍊鋼的程序或改變遊戲規則間作出選

擇。測試服務需要進行徹底的改革，以應付發生在產業界或 Google其他地方的

重大轉變。

xvi Google軟體測試之道

我非常想說，我運用了我非常豐富的經驗並變出了一個完美的測試組織，但

事實上，我的經驗只教了我一些比錯誤的做事方法好一點點的東西。在我帶

領過或任職過的每一個測試組織，都有某種程度上的缺陷。東西總是壞的。程

式碼壞了、測試壞了，包括團隊也壞了！我知道這表示為了品質與避免技術失

誤，每一個創新的想法都會被壓縮，免得它危及了脆弱的產品。如果我的經驗

有讓我學到東西，那一定是如何才能別做測試。

從我到那時為止的所有與人互動的經驗中，我明確地看到一件關於 Google的

事。那就是它尊重電腦科學與程式設計技巧。這後來演變成，如果有測試者要

加入這個俱樂部，則他們得要有好的電腦科學基礎並具備一些程式設計實力。

要進入第一流的國度，這是基本條件。

如果那時我要改變 Google對測試工作的看法，我得要改變它對測試者而言

所代表的意義。我常常會試著想像有個完美的團隊，以及這個團隊會如何來擔

負起品質的重任，然後我就可以證實同樣的前提：只有在整個團隊需要為品質

負責時，一個團隊才能寫出高品質的軟體。不管是產品經理、開發者還是測試

者…所有人都要負責。就我的角度而言，達成這個目標最好的方法就是讓測試

者能夠把測試當成程式碼中的一項實際的功能。測試功能應該等同於所有客

戶實際上可能看到的功能。建置功能所需的技能就是一個開發者所應具備的技

能。要找到能寫功能的測試者不容易；要找到能夠進行測試的功能開發者更加

困難。不過現況可能比上述情況更糟，所以我就提前開始鍛鍊了。我要求測試

者為自己負責的產品多做些事，同時，我要去推展測試工作的本質與主權，這

表示要向開發團隊要求巨量的投入。這是一個我在這個產業生涯裡頭從未見到

有人實踐過的組織架構，我確信它正是 Google該走的路，而且我認為，我們這

家公司已經準備好了。

不幸的是，公司裡頭的其他人分散了我對這種深奧且基本的變化的熱情。當

我開始以這種同中求異的軟體測試角色，進行社交活動的過程中，我竟然連要

找到一位願意共進午餐的伙伴都沒有！工程師似乎受到他們將要在測試工作中

扮演更重大角色的這種說法的威脅，存著“這就是測試之所以存在的原因。＂的

看法。在測試者當中，即使已經習於測試工作的，也同樣有這種令人感到不舒

服的態度，現實中存在著這種能量，讓改變這件事變成是一項難以解決的問題。

xvii前言 ─ Patrick Copeland

我持續推動這件事大多是因為擔心 Google的工程流程會陷入技術的泥淖之

中，造成品質的下降，而如此一來，我可能又會回到之前高興地將之丟棄在傳

統客戶端 -伺服端世界中的那些五年推出產品的週期中。Google是由專注在創

新上的天才們所建造出的公司，而這種企業形象就是與漫長的產品推行週期不

相容。這是場值得奮戰的仗，我說服自己一旦這些天才們瞭解“技術工廠＂裡

頭這些有效率且可重複的開發與測試實作之後，他們就會參與。他們就會瞭解

我們已不再是一家新創公司，而且隨著使用者人數的快速增長，由臭蟲所造成

的技術問題以及結構不佳的程式碼，將會終結這個程式設計師的樂園。

我觀察以我的方式來進行開發的工作團隊，試著找出我論據中有說服力的

甜蜜區（sweet spot）。就開發者而言，我描繪出一個持續建置（continuous

builds）、快速佈署（rapid deployment）以及一個快速的開發流程，可節省更多

時間激發創新思考。就測試者來說，我讓他們渴望成為具同等技術能力、有同

樣大的貢獻且能獲得相同回饋的工程夥伴的希望得以實現。

如果我們想找有足夠技術的人來進行功能的開發，那就應該要讓他們去進行

功能的開發工作。通常開發者們是這麼想的。有些人非常反對，他們就會用如

何對付我這種瘋狂想法的方法，將我老闆的電郵信箱灌爆。好險，我的老闆忽

略了這些建議。

讓我驚訝的是，測試者也有相同的反應。他們還停留在過去，並為現在的處

境嘆息，進展很慢。

我老闆對這些抱怨的回應是：“這就是 Google，如果你要把事情做好，那就

得這樣做。＂

我是這樣處理的。我將有相同想法的人聚集過來，組成了一個足夠大的結

構，並弄出幾個面試的流程，然後我們就開始面試一些侯選人。這個過程並不

輕鬆。我們要找那些有開發技術並具有測試者特質的人。我們要找的是那些有

能力寫程式、願意將自身的技術投入到工具、基礎結構與測試自動化開發工作

上頭的人。因此我們得要重新思考招募與面試的過程，然後向自我意識比較強

且比較習於以往的聘任委員會解釋。

在前幾季裡頭吃足了苦頭。或許是因為在解決一些困難問題時顯得有些遲

頓，又或者是因為在處理某些人認為重要但卻與測試技術無關的事務上意興闌

珊，好的候選者往往在審查過程中被打掉（orpedoed）。我瞭解到聘任工作將會

變得困難，而且每週都要花時間寫一份又一份的聘任說明書。情況一直持續到

xviii Google軟體測試之道

那時是 Google共同創辦人的 Larry Page（現在還是）在面試過程中，批准了聘

任案後才有所改善。他批准了足夠的人，讓我的團隊能開始成長。我常常會有

種感覺，Larry每次聽到我名字時，是不是都會聯想到“聘用測試人員！＂

當然，在此時我發出夠大的聲音，說服大家除了這樣做之外，我們沒有其他

的路可走。整個公司都在觀望，而隨時都可能發生災難性的錯誤。外頭對一個

由常常生變的供應商或臨時人員所維繫的小型測試團隊，有著許多的期待。但

在我們盡最大努力去聘人，以及在我回撥電話給我們聘用的臨時人員時，我發

現許多情況已經變了。測試資源愈來愈不足，而開發人員要做的測試工作則愈

來愈多。許多團隊都面臨這方面的挑戰。我想如果技術還是在原地踏步的話，

很快地就會發現我們離該達成的目標愈來愈遠。

科技並不會停滯不動，開發與測試的準則迅速地在改變。靜態網頁內容的時

代已經成為過去，而瀏覽器才正試著去因應這種變化。與瀏覽器有關的自動化

技術，也已經落後過時的瀏覽器有一年的時間。當開發者面臨這麼巨大的技術

轉變的同時，把測試導入到開發流程中似乎是一項愚蠢的舉動。我們連能手動

完善測試這些應用程式的能力都沒有，更不用說要自動化了。

開發團隊面臨同樣糟糕的壓力。Google 開始併購有豐富（rich）與動態

（dynamic）網頁應用程式的公司。YouTube、Google Docs等等都陸續要整合到

我們內部的基礎架構當中。我在測試工作中所面臨到的問題，與開發團隊要寫

程式給我測試時所面臨的問題，同樣令人擔憂！我要解決的測試問題，就是無

法分開來處理。把測試與開發看成是個別的教條，或甚至只是不同的問題，這

都是一種偏見，如果一直這樣下去，我們將永遠無法解決兩者所存在的問題。

調整測試的團隊是讓我們可以向前邁進的唯一道路。

情況有些進展了。聘用一些聰明的傢伙是一件有趣的事：他們會試著讓事情

有進展！2007年時，測試準則的採行步上軌道，我們都能把發佈週期的最後階

段處理得很好。開發團隊瞭解到他們可以像伙伴般地信任我們而提高生產力。

不過如果我們以後期支援團隊的身份存在，那又會與傳統的 QA模式混淆。先

不管我們能把事情處理好的能力，我們還未到達我預期的位置。我有權處理人

員聘任問題，測試工作也往對的方向發展，不過在整個流程中，我們太晚參與了。

我們開始推動稱為“測試認證（Test Certified）＂（稍後本書作者會對此作說

明）的概念，透過這個概念，我們與開發者討論並協助他們能寫出比較合宜

（hygiene）的程式碼，且在早期就建立單元測試的實作。我們製作工具並且輔

xix前言 ─ Patrick Copeland

導團隊持續進行整合工作，讓產品一直維持在一種可測試的狀態之下。本書會

提到雖然有無數次細微的改良與校調，消弭了初期的許多懷疑，但我們還是缺

乏對全貌的瞭解。開發仍舊是開發；而測試仍舊是測試。許多足可改變文化的

因素已然存在，但我們還是需要一些催化劑將它們融合在一起。

在我環視這個因為我所提出的建議而聘用開發者進行測試工作的組織時，我

發現測試只是我們所努力的一部份。我們還有工具小組負責建置從原始碼儲存

槽（source repositories）、建置基礎架構（building infrastructure）到臭蟲資料庫

（bug databases）等的所有工具。我們扮演著測試工程師、發行工程師（release

engineers）、工具開發者（tool developers）以及顧問等角色。令我印象深刻的

是在我們的工作當中，有多少非測試取向的工作正影響著我們的生產力。我們

的招牌是測試服務（Testing Services），但我們要做的事卻這麼的雜。

因此，我決定要將它變成是官方的，我也將團隊的名稱改為工程生產力

（Engineering Productivity）。名稱改了文化也會跟著變。人們開始用生產力來替

代測試與品質。生產力是我們的工作；測試與品質則是所有開發相關人員的工

作。這代表開發者不但要負責測試也要負責品質。生產力團隊則需負責讓整個

開發過程都能夠處理這兩方面的問題。

一開始，這個理念大部份是啟發性質，而“加速 Google＂這個口號剛開始也

可能流於空泛，但經過時間的推移與我們的推動之後，我們實現了承諾。我們

的工具讓開發者的工作速度加快，隨著瓶頸一個接著一個被克服，開發者所面

臨的問題可以被順利地解決。我們的工具也讓開發者可以編寫測試，然後在後

續的建置（build）工作中，看到這些測試的結果。測試案例不再只於某些測試

者的機器中被獨立執行。這些測試結果被貼在儀表板上，並且持續將後續的版

本累積起來，因此它們變成了判斷應用軟體是否符合發行標準的公開紀錄。我

們不只要求開發者的參與；我們讓它變得簡單，讓開發者很容易去參與。生產

力與測試之間的不同終於顯現了出來：Google能以阻力更小且不會被累積的技

術問題拖累的方式來進行創新。

然後結果呢？嗯，這就是這本書存在的原因，我不會壞了本書其他的部份。

作者煞費苦心將他們自身的經驗淬鍊了出來，其他的 Google人也運用我們的祕

密醬汁把核心的實作集烹調了出來。從數量級、減少建置時間、執行即忘（run-

it-and-forget-it）的測試自動化到把某些真正創新的測試工具變為開源碼（open

sourcing），使我們在這許多面向上獲得成功。在寫這篇序言的時候，生產力團

xx Google軟體測試之道

隊已經有 1,200位工程師，這比我在 2005年加入 Google當時的所有工程師人

數還稍多了一些。這塊生產力的招牌很強大，而且我們加速 Google的口號也成

了工程文化的一部份。我們從我開始坐在 TGIF裡頭面臨困惑與不確定性的時

候到現在，已經走了一段很長的路。唯一不變的就是我的那頂三色螺旋帽，它

靜靜地坐在辦公桌上提醒著我，我們已經走了多遠的路程。

Patrick Copeland是工程生產力的資深主任，Google測試食物鏈的層峰。

這家公司所有測試者的報告會向上匯報到 Patrick（順帶一提，他的直屬上司就

是 Google的共同創辦人 Larry Page）這裡。Patrick到 Google任職之前，曾在

Microsoft擔任測試部主任近十年的時間。最近他則為活躍的公開演講者，是

Google裡廣為人知的 Google快速開發、測試與軟體佈署技術的架構師。

xxi序

序

軟體開發難，軟體的測試也難。當您以整個網際網路的規模來討論開發與測

試時，您就等於是在討論 Google。如果您對網際網路上這個大傢伙如何處理這

麼大尺度的測試（large-scale testing）有興趣的話，您就找對書了。

Google每天都會在幾百萬個原始檔裡頭測試並釋出幾億行的原始程式碼。每

天，數十億次的建置動作推動在數十萬個瀏覽器實體上所執行的幾百萬次自動

測試。建置、測試並釋出作業系統的時間不超過一年。瀏覽器則每天都有新的

建置。網頁應用程式以幾近不中斷的步調在釋出。2011年，Google+有 100項

功能在 100天的週期內推出。

這是 Google的規模與速度 ― 其實就是網際網路本身的規模，這也是本書所

描述的測試的解決方案。我們會揭露這個基礎架構的構想、實作以及如何維護

的方法。我們向讀者介紹在概念與實作的發展上造成影響的人物，也會介紹用

以解決問題的基礎架構。

但事情並不會總是如此發展。Google能發展至此所走的路程與我們用來進行

測試的技術同樣有趣。將時間往前調六年，那時 Google與我們曾工作過的其

他公司並無不同：測試並不是顯學。它的門徒不但過勞，工作也沒有受到應有

的尊重。它是繁重的手動操作過程，擅長自動化的人都很快地被吸收進開發部

門，因為在那兒，他們能更“具影響力＂。推動 Google稱為“生產力工程＂的

創始團隊除了必須克服抗拒測試的偏見，還要鼓勵在工程嚴謹度上作出英雄式

奉獻的企業文化。目前，Google的測試者就紅利與升遷的速度而言，與開發者

有同樣的待遇水準。事實上，測試者成功了，這種文化隨著公司的成長（從產

品、多樣性與營收方面而言）而鞏固，跟隨 Google腳步發展的公司應該有信心

進行組織結構的重整。測試工作可以正確地被執行，產品團隊與公司管理階層

應該要接納它。

當愈來愈多的公司發現他們的財富與未來都繫於網際網路之上時，本書所描

述的測試技術與組織架構可能會愈來愈普遍。如果真是這樣，那不妨將本書當

作如何達成目標的手冊。

xxii Google軟體測試之道

這本 Google測試手冊是以相關角色的角度來編寫的。在第一個部份裡，我們

討論所有的角色，並介紹 Google品質程序中所有的相關概念、程序與錯綜複雜

的狀況。這個部份一定要讀。

您可以透過任何順序來閱讀這些章節。我們會先提到 SET測試軟體工程師

（software engineer in test）這個角色，因為這是現代 Google測試發展的起點。

SET是一種技術測試者，那一章裡適當地提到一些技術，但等級也夠高，讓每

個人都能掌握其主要的概念。接續這個 SET章節的是涵蓋其他主要測試角色的

一個章節，討論的是 TE或稱測試工程師（test engineer）。這是一個大章節，因

為 TE的工作很廣泛，Google裡的 TE們在產品週期中需負責許多任務。這是

許多傳統測試者會感到熟悉的角色，我們相信這個部份應該是本書最會被詳讀

的部份，因為它適用於大部份從事相關行業的讀者。

本書會在測試管理與訪談之間取得平衡。我們會對那些在 Google測試的發展

歷史中佔有一席之地，或在 Google主要產品中扮演重要角色的人士進行訪談。

嘗試發展像 Google的測試程序或團隊的讀者，應該會對這些訪談很感興趣才是。

對這方面有興趣的讀者更不要錯過本書的最後一章。James Whittaker提出了

對 Google測試如何持續演化的深入剖析，他也對 Google以及其他大規模的工

業體將如何更有智慧地運用測試作出預測。我們相信許多讀者會覺得這發人深

省，有些讀者甚至會感到震驚。

關於圖表

受討論主題的複雜度與網際網路繪圖特性的影響，本書第三章中的部份圖表內容太細了，這只是為了

要呈現出概念的高階樣貌。這些圖表只是為了呈現，並不需要去細究。如果您想要在電腦上細閱這些

圖表，可以到 www.informit.com/title/9780321803023去下載。

xxiii關於本書

關於本書

當 Patrick Copeland當初建議我寫這本書的時候，我是遲疑的，而且我顧慮

的都有道理。有人會質疑我是不是那位最適合寫它的 Google人（確實有人質

疑）。有許多人都想要參與（這也是真的）。不過最主要的原因是，我之前所

寫的書都是為初學者寫的。不論是 How to Break…系列亦或是我的 Exploratory Testing都是完整且前後連貫的故事。不過本書不是如此。讀者也許會坐下來好好地讀它一遍，但它更像是記錄 Google如何執行這些大大小小的，組成我們測

試實作的那些工作的參考書。我希望有在企業環境中測試軟體經驗的讀者，能

比初學者從中得到更多，因為他們會習慣拿我們的 Google程序與他們習慣的程

序來比較。我想像著有經驗的測試者、經理人與主管們會將它拿起來，找到感

興趣的議題，然後閱讀相關的章節，以瞭解 Google是如何處理某些特定工作

的。但這並不是我慣用的寫作風格！

兩位之前沒有出版經驗的共同作者加入了編寫本書的行列。這兩位都是優

秀的工程師，在 Google的工作資歷都比我長。Jason Arbon的職銜為測試工程

師，不過他擁有企業家的思維，許多在本書關於測試工程師的章節中出現的想

法與工具，都深受他的影響。我們在事業上的交會，讓我們彼此獲益良多。Jeff

Carollo則是一位具有測試者思維的開發者，他是我所見過的最佳測試開發者，

也是少數能做到“寫好就放手（walk away automation）＂的人 ― 這是指測試程

式寫得夠好、夠完善，讓編寫者在完成它之後就直接送交到團隊裡頭，不需任

何修改就能運作得很好。這兩位共同作者相當傑出，我們很努力地讓這本書讀

起來一致且流暢。

有不少 Google人提供了許多素材。只要這些文字或內容是由單一作者所產生

的，他的名字就會標示在他所提供的內容之前。還有不少對我們進行測試時產

生重大影響的關鍵 Google 人，我們也收錄對他們所進行的訪談。這是我們所能

想到的，盡可能網羅與 Google測試的形成有關的人士，而不讓一本書的作者數

量超過 30位的方法！並不是所有的讀者都會對所有訪談感到興趣，因此我們將

這些訪談清楚地標示出來，要跳過或選讀都很方便。

xxiv Google軟體測試之道

我們誠摰地感謝這些對本書作出貢獻的人士，如果因為我們的才疏學淺，讓

這些努力沒辦法得到應有的彰顯，我們也接受任何形式的責難。用言語實難描

述這些耀眼的光芒。

祝各位讀者，閱讀愉快，測試愉快，希望您都能找到（與修復）您在抓的那

隻臭蟲。

James WhittakerJason ArbonJeff Carollo

於華盛頓州，科克蘭市

xxvii關於作者

關於作者

James Whittaker是 Google的一位工程主任，負責測試 Chrome、maps與 Google

的網頁型應用程式。他過去在 Microsoft工作而且在那之前還是一位大學教授。

James在測試界中是廣為人知的人物之一。

Jason Arbon是 Google的一位測試工程師，負責測試 Google Desktop、Chrome

與 Chrome OS。他也是一系列開源測試工具開發與個人化實驗工作的主導人

物。在加入 Google之前，他在 Microsoft任職。

Jeff Carollo是在 Google中參與測試工作的軟體工程師。負責測試 Google Voice、

Toolbar、Chrome與 Chrome OS。他是許多 Google內部開發團隊的顧問，協

助這些團隊提昇程式碼的起始品質。他在 2010年時轉任為軟體工程師並領導

Google+ API的開發工作。在加入 Google之前，他也是在 Microsoft任職。