《Google軟體測試之道》—第2章2.2節測試認證

本節書摘來自異步社群《google軟體測試之道》一書中的第2章2.2節測試認證，作者【美】james whittaker , jason arbon , jeff carollo，更多章節

内容可以通路雲栖社群“異步社群”公衆号檢視。

2.2　測試認證

patrick copeland在本書的序中強調了讓開發人員參與測試的難度。招聘到技術能力強的測試人員隻是剛剛開始的第一步，我們依然需要開發人員參與進來一起做測試。其中我們使用的一個

關鍵方法就是被稱為“測試認證”（譯注：test certified）的計劃。現在回過頭來再看，這個計劃對開發人員做測試這個根深蒂固文化的形成有着巨大的幫助。

測試認證最初以競賽的方式進行。如果我們把測試認證做成一個富有聲望的事情，這會讓開發對測試重視起來嗎？如果開發人員遵循一些特定的測試實踐，并拿到期望的結果，我們能說他們通過了認證嗎？然後再給他們授予一個象征性的徽章（見圖2.12），使得他們擁有炫耀的資本嗎？

好吧，測試認證是：如果一個團隊完成了一系列的測試任務，這個團隊會得到一個通過“認證”的辨別。所有團隊最初的級别都是0。如果掌握了基本的優秀代碼習慣，就達到級别1，然後繼

測試認證級别摘要

級别1

使用測試覆寫率工具。

使用持續內建。

測試分級為小型、中型、大型。

明确标記哪些測試是非确定性的測試（譯注：非确定性測試指測試結果不确定的用例）。

建立冒煙測試集合。

級别2

如果有測試運作結果為紅色（譯注：表示運作失敗的用例）就不會做釋出。

在每次代碼送出之前都要求通過冒煙測試。

各種類型測試的整體增量覆寫率要大于50%。

小型測試的增量覆寫率要大于10%。

每一個功能特性至少有一個與之對應的內建測試用例。

級别3

所有重要的代碼變更都要經過測試。

小型測試的增量覆寫率要大于50%。

新增的重要功能都要經過內建測試的驗證。

級别4

在送出任何新代碼之前都會自動運作冒煙測試。

冒煙測試必須在30分鐘内運作完畢。

沒有不确定性的測試。

總體測試覆寫率應該不小于40%。

小型測試的代碼覆寫率應該不小于25%。

所有重要的功能都應該被內建測試驗證到。

級别5

對每一個重要的缺陷修複都要增加一個測試用例與之對應。

積極使用可用的代碼分析工具。

總體測試覆寫率不低于60%。

小型測試的代碼覆寫率應該不小于40%。

最初這個計劃在一些測試意識較高的團隊中緩慢試水，這些團隊成員熱衷于改進他們的測試實踐。經過在這幾個團隊的成功試驗之後，一個規模更大的、公司級别的認證競賽開始推行起來了

，然後在新加入的團隊中再推行這個計劃就變得容易的多。

這并不像一些人想象的那麼難以被接受，開發團隊也從中收益頗豐。

開發團隊得到許多優秀測試人員的關注，這些測試人員一般都報名成為測試認證教練。在一個測試資源稀缺的文化氛圍裡，注冊參加這個項目會吸引到比一般團隊更多的測試人員的加入。

他們獲得專家的指導，并學習到如何更好地編寫小型測試。

他們知道哪個團隊在測試上做的比較好，并向這個團隊學習。

他們能夠向其他的認證級别較低的團隊進行炫耀。

經過公司級别的推進，絕大多數團隊都在不斷向前進步，并意識到這個計劃的重要性。一些在這個計劃中表現不錯的開發總監會得到工程生産力團隊的優秀回報，而嘲笑這個計劃的團隊也會

置自身于危險之中。換句話說，在一個測試資源相對稀缺的公司裡，哪個團隊會舍得與工程生産力團隊疏遠呢？但并非哪裡都是鮮花與掌聲，讓運作這個計劃的負責人來給我們講述完整的故

事吧。

2.2.1 與測試認證計劃創始人的訪談

本訪談的作者和四名google工程師坐在一起，他們曾為測試認證計劃的開展起到了關鍵性的作用。mark striebeck是gmail的開發經理；neal norwitz是關注開發速度工具的swe；tracy

bialik和russ rufer是非管理角色的set，他倆是公司級别最高的set，也都是資深級的工程師。

hgts：測試認證計劃的起源是什麼？最初測試認證團隊試圖去解決什麼樣的問題？現在這個計劃嘗試去解決的問題相比還是同樣的問題嗎？

tracy：我們企圖去改變google的開發文化，想把測試工作也變成每個功能開發人員的職責。大家共享許多在測試方面有積極意義的經驗，并鼓勵整個團隊都去做測試。有些團隊比較感興趣，

但不知道具體怎樣去操作。另外的一些團隊會把“提高測試”作為團隊目标或績效（譯注：objectives and key results，簡寫okrs，是個人、團隊，甚至公司每個季度都要訂制的目标。基

本上這些事情都需要個人或團隊完成），這通常并沒有什麼實際的可操作性，有點像把“減肥”作為新的年度目标一樣。那樣其實也沒什麼不好，至少有崇高的目标。但是，如果這就是你要

說的一切，未來有朝一日發現并沒有變成現實，你也千萬不要感覺奇怪。

測試認證計劃提供了小而清晰且可操作的步驟給團隊去執行。級别1是做基本準備：建立測試運作的自動化機制、收集測試覆寫率、去除所有非确定性的測試、挑選冒煙測試集合（如果全部自

動化測試運作比較耗時的話）。級别越高就會變得越難，也需要越成熟的測試度。級别2開始着重提高增量覆寫率。級别3重點是測試新增代碼。級别4的重點是測試曆史遺留代碼，通常情況下

需要針對可測試性做一些重構。級别5要求更好的整體覆寫率，針對每個缺陷都增加測試用例，并要求使用已有可用的靜态與動态分析檢查工具。

現在，所有google的人都已經知道測試是功能開發人員的責任。雖然最早的問題已經得到了解決，但是我們依然需要為團隊提供更高的測試成熟能力度而做一些事情。測試認證持續不斷地在

為這個目标服務。

hgts：測試認證團隊最初從swe那裡收集到的回報是怎樣的？

neal：測試認證計劃太難了。他們認為我們把目标設定的過高，結果導緻許多團隊還在初級層裡掙紮。我們需要重新設定認證級别，設定為使他們隻要在空閑時間裡努力就可以達到的級别。

當時google的工具也有一些問題，而且我們當時要求的一些想法太過超前。對于參與的同僚們來說的确難以去開展進行，是以我們不得不考慮提供一些容易達成的目标，使他們相信自己在不

斷地進步中。

mark：是的，我們不得不把目标向下做了幾輪調整。我們設定了一些更加實際的目标，試圖在半路上與他們相遇。當然最終還是要達成我們的終極目标，隻是需要的時間更長。雖然我們并不

在意時間變長，但還是希望在某些地方可以加速。我們把第一個級别修改為“搭建持續內建環境，保證建成，并清楚自己的測試覆寫率”。這些是很容易達到的，但它建立起一些制度并使大

家的狀态從無變到有，并産生積極向上的動力。

hgts：有誰迫不及待地想參與進來？

neal：最早參與的人通常是測試圈子裡的人。這一小群人定期舉行會議，多數是對測試非常熱衷的人。我們慢慢地把其他認識的人也拉進來。當時有許多熱心的積極參與者，這對我們來說是

上經常出現）和其他的一些活動把測試搞得充滿熱情，更有趣味和吸引力，包括fixits（注：fixits是另外一個google的文化活動，促使人們一起“修複”一些注定要損壞的東西。團隊可能

會舉行一個fixit來降低bug，另外一些團隊或許會搞一個針對安全測試方面的fixit，也可以用來在c代碼中增加 #include的使用或者用以重構。fixit可以跨越技術領域，可以用來增加咖啡

館的食物或怎樣讓會議進行地更加平滑。任何一個活動，隻要一起參與能夠解決通用問題，都是一個fixit）、vp的郵件、海報、tgif上的分享等活動。

mark：一旦有的新的團隊參與進來時（當時已經有許多團隊對我們這個計劃感興趣），他們會意識到：① 需要提前做一些功課；② 不必有專業知識。那些專業知識會讓初學者産生挫敗感。

hgts：有誰不願意參與這個計劃嗎？

neal：多數項目都不願意參加。正如我上面提到的，這個計劃難度非常大。給我們最初的勃勃野心迎面澆了一盆涼水。大概有兩種類型的項目：壓根兒沒有測試的項目和測試非常糟糕的項目

。我們需要把計劃調整的更容易一些，使他們能夠利用一個下午的時間就把需要的測試任務完成（在我們的幫助下他們的确也做到了）。

mark：還有，當時還處于另外一種狀況，測試的價值和自動化測試在google還沒有被真正認可。與今日不同，甚至情況完全相反。那個時候，多數團隊也認可這是一個非常酷的想法，但他們

還有更重要的事情要去完成（例如寫産品的功能代碼）。

hgts：最初，一些參與團隊必須要去克服的困難是什麼？

neal：慣性，糟糕的測試，沒有測試時間。測試被當做其他開發人員的問題，或者測試是測試團隊的問題，跟我沒有關系。在寫功能代碼的時候，誰有時間去寫測試代碼啊？

mark：嘗試尋找下面的團隊：① 足夠感興趣；② 沒有太多的備援代碼；③ 在團隊中有一個測試戰神（對測試足夠的了解的人）。這是我們測試認證計劃在團隊裡的三大障礙，我們會一個一

個團隊地去解決。

hgts：是什麼把測試認證計劃推向了主流？是病毒性的爆發還是線性的增長？

russ：首先是一批試點團隊，他們對測試特别友好。早期的測試認證計劃鼓吹者也和我們保持比較親密的聯系。初期很好地選擇了參與者，基本上都是一些很容易成功的團隊。

在2007年中期，我們宣布測試認證計劃“正式啟動”的時候，有15個試點團隊在這個計劃的不同級别上運作着。在正式宣布之前，我們在山景城、紐約和其他地點的所有辦公大樓上張貼“神

秘的測試認證”的大海報，每個海報上用圖檔印着各個試點團隊名字，使用的是内部項目名稱，如rubix、bounty、mondrian和red tape。海報上唯一的文字是“未來就是現在”和“至關重要

，莫被遺棄”，還有一個連結。從喜愛猜謎的google同僚那裡，我們得到了大量點選通路，多數人想去一探究竟，還有一些人想去驗證自己的猜測是否正确。同時我們也使用tott來宣傳這個

新計劃，并把讀者指引到他們能夠得到資訊的地方。這是一個資訊閃電戰。

宣傳網站上有一些資訊，包括為什麼測試認證對于團隊很重要，以及使用者可以得到怎樣的幫助。裡面強調指出，參與團隊會從一個很大的測試專家社群裡得到一個測試認證教練，同時還會得

到兩個禮物——一個表示建構狀态的發光魔法球，可以告訴團隊他們的（一般是新的）持續內建是通過（綠色）還是失敗（紅色）；另外一個是一個漂亮的星球大戰洋芋頭工具包。這個被稱

為達斯洋芋工具包裡有三個逐漸變大的格子，每當團隊達到新的測試認證級别時我們都會給予獎勵。各個團隊展示他們的魔法球和洋芋頭，為這個計劃吸引來更多好奇的團隊和帶來更好的口

碑。

測試圈子裡的成員是這個項目的第一批教練和發言人。随着越來越多團隊的加入，有許多熱情的工程師幫助造勢，自己也成為其他團隊的教練。

每次我們嘗試說服更多的團隊加入這個計劃的時候，都會與他們逐一讨論理由和原因。一些團隊是由于你能使他們信服每一個級别和教練都會幫助團隊在這個領域有所提高而加入的。一些團

隊認為他們會有所改善，并堅信這種“官方”級别評定會使他們因為目前正在做的工作得到好評。另外的一些團隊，他們本身的測試成熟度已經很高了，但加入這個計劃，會給其他的團隊發

出一種信号，表示他們已經很重視測試了。

幾個月之後，大約有50個團隊參與進來，許多有魄力的測試工程師簽約成為測試認證計劃的教練。這是一個在團隊工程師和工程生産力團隊之間強大的合作關系的開始。

這是一個病毒爆發式的增長，通過許多一對一草根之間的對話發展起來。雖然我們有明确地要求一些團隊參與進來，但也有另外的團隊自己找上門來。

大概一年後，有一百多個團隊通過測試認證，加入測試認證計劃的速度開始慢慢地放慢。時任志願者主管bella kazwell策劃了一個活動——測試認證挑戰。該挑戰活動開發了一個積分系統，

新增測試、引入新團隊參與計劃、提高團隊測試實踐或提升測試認證級别等活動會被計算進來。同時，有一些個人獎項、全球的項目都參與進來，比拼誰是最高分獲得者。志願者被激勵，随

之又激勵了公司裡更多的團隊，使測試認證計劃再次加速，并吸引了更多的志願者教練。

參與測試認證的團隊一般都使用每個級别的标準作為可度量的團隊目标。到2008年後期，一些團隊的經理開始使用這個作為他們的團隊目标，而工程生産力團隊使用一個團隊在測試認證計劃

裡的級别，來評測這個團隊在提高測試方面的重視程度，并在決定是否向一個團隊投入有限測試資源時作為一個重要的參考名額。在某些限定的領域，一個團隊是否達到特定的測試認證級别

已經成為管理上的期望或啟動的标準。

在2011年，不斷有新的志願教練加入，也不斷有新團隊簽約加入，測試認證已經在整個公司中運作起來。

hgts：在最初的兩年測試認證計劃做了哪些變化？每個級别的要求有什麼變化麼？教練系統有變化麼？對于參與者在體驗方面有哪些改進？

tracy：對認證級别的數量和一些級别要求做了調整，這是最大的變化。最初我們有四個級别。從級别0到級别1，有意地設計成比較容易就可以達到。許多團隊，特别是一些可測試性比較差且

有遺留代碼的團隊，發現從級别1到級别2非常困難。這些團隊會比較受挫，并有意向退出測試認證計劃。我們在級别1和級别2之間增加了一個稍微簡單的新級别。我們把這個新級别定義成為

“1.5”，但實際上還是決定把新增的級别設定為2，并把後面所有的級别+1。

我們同時發現有一些要求并不合适，例如小型測試、中型測試、大型測試的比例要求并不适用于所有團隊。在我們增加了新級别之後，同時也更新了級别标準。我們在新增了“增量覆寫率”

的具體比例要求的同時，把各級别測試的比例也給去掉了。

輔導教練始終都在，但許多團隊已經進入“自我調教”的模式。由于測試文化已經無處不在，許多團隊已經不需要我們再提供建議了。他們希望跟蹤自己的進度。對于這些團隊，我們不再指

派教練，而是提供一個郵件清單用來回答他們的問題，這也是通過另一雙眼睛來觀察他們級别的轉換。

russ：值得注意的是，從一開始，我們就意識到測試認證标準必須要合理地制定。測試并像制作餅幹，都是一個模子裡出來的。在我們選擇标準的時候會發現有一些團隊的測試狀況跟我們心

中的所想迥然不同，無論是用以記錄測試覆寫率的工具還是用其他的度量方式，各有千秋。但每一個标準都有其背後的合理性。在這裡我們比較開明的沒有一刀切，而是定制化了一些多數團

隊可以滿足的标準。

hgts：目前如果一個團隊堅持參與測試認證計劃會有什麼收獲？還需要投入什麼？

tracy：可以把這個作為炫耀吹牛的資本。清晰明确的步驟、外部的幫助、一個看起來很酷的發光球，但對于團隊來說，真正的收獲是品質方面的提升。

實際投入非常小，但團隊需要專注于改善他們的測試成熟度。我們有一個定制化的工具，教練可以用此跟蹤團隊進度，檢查每一步目标是否達成。在一個頁面展現所有按照級别排列的團隊數

據，可以通過滑鼠點選檢視指定團隊的細節資料。

hgts：在所有的認證級别裡，哪個級别會給團隊帶來更多的麻煩？

tracy：最困難的一步是“對于所有的重要代碼變更，都需要經過測試”。這個要求在一個可測試性很好的項目中比較容易做到，但對于一個有遺留代碼的項目，特别是之前寫代碼的時候并沒

有測試意識，這就很困難。這可能需要寫一個大的端到端測試并嘗試通過測試驗證系統的特殊代碼路徑，然後再自動化。從長遠角度看，更好的辦法是代碼重構，進而獲得良好的可測試性。

有一些團隊，在寫代碼的時候沒有考慮到可測試性，一樣會發現很難去達到足夠的測試覆寫率，不管是單元測試，還是端到端的測試。

hgts：在google一般的活動隻會持續數周或一個季度，但是測試認證計劃已經運作了近五年而且沒有迹象表明會停止。是什麼導緻測試認證計劃經過了時間的考驗？測試認證之後會面臨什麼

挑戰？

russ：能夠保持活力的原因，不是因為這是個體參與活動，而是因為這是一次公司文化的變遷。随着一系列活動，測試小團隊、tott、支援郵件清單、技術交流、晉升貢獻、代碼風格文檔，

正常的測試已經演變成為公司所有工程師必須要做的事情。不管一個團隊是否參與了測試認證計劃，這個團隊總是希望有一個經過深思熟慮的自動化測試政策，這些政策來自于一部分測試專

家，不管是團隊内部還是外部的專家。

能夠持續至今也證明這個計劃是可行的。隻有很少一部分領域在使用手動測試。在這樣的情況下，測試認證計劃已經完成了它的使命。它會被作為偉大的曆史遺産，即使這個官方的草根計劃

某天真的結束了。

hgts：有什麼建議要給其他公司的同行？如果他也想在自己的組織裡考慮類似的計劃？

tracy：從一些對測試比較認可且友好的團隊開始，培養一批可以從你的計劃中受益的核心團隊。在激勵和贊美方面不要害羞，甚至要求其他人也來說好話。良好的教練是測試認證計劃成功的

一個重要原因。如果你想要求一個團隊去嘗試新的事物或者做某些改進，給他們提供一個聯系人會更好一些，這個聯系人來源于更大的社群，并可以從他那裡得到幫助。一個工程師或團隊如

果在一個郵件清單中問了一個很傻的問題，會感覺比較尴尬，但詢問對象如果是一個可以信任的測試認證教練的話，這将會好很多。

同時，尋找一些讓你的計劃變得有趣的方法。為你的計劃取一個好的名字，最好不要包含“認證”字樣，這可能會引起見識短淺的官僚主義。或者像我們一樣，就使用一個目光短淺的名字“

測試認證”，但要不斷地提醒大家注意我們知道這是一個不好的名字，這隻是一個反語，用以襯托你的計劃其實并不是這樣的。每一個步驟包含的内容要盡可能的少，這樣大家可以看見自己

的進步。不要陷入嘗試去建立一個包含獨立名額的完美系統的陷阱中。對所有人都完美的事情是不存在的。在沒有可替代的方案時，在合理的地方達成一緻并勇往直前是很重要的。需要靈活

的時候就靈活一些，但一定要堅持你的原則底線。

到此本章已結束。後面是可選閱讀部分，關于google如何面試set、與google工程師ted mao的訪談，以