How Google Test Software讀書筆記(一)

許久都沒有寫部落格了，因為一直在讀那本“How Google Test Software”，每天下了班不管回家多晚，我都會看上那麼幾十頁，算是補充補充精神食糧吧。現在終於讀完了，想把一些感想摘記下來，記性這玩意始終是靠不住的。

第一章 Introduction of Google Software Testing

其中有個很重要的觀點：Quality 不等於Testing, 如果說硬要給Quality下一個定義的話：當把開發與測試混在一起分不清彼此的時候，Quality就產生了。所以文章中提倡的觀點是：Code a little and test what you built，這樣循序漸進的過程才能產生穩定的品質。補充一點：對於品質來說，預防問題比發現問題本身更重要。品質更多是開發人員的問題，而丌是測試人員的。通過把測試工作融入到開發過程中，我們能降低那些富產Bug的人的出錯機會，丌僅可以避免了大量終端使用者的使用問題，而丏還可以極大地降低測試人員報無效Bug的數量。

那麼Google是如何定義測試工程師的呢？Some engineers are responsible for making other engineers more productive and more quality-minded。除了測試工程師，Google還有一種叫SET的角色，也就是我們所說的測試開發工程師，他們專註代碼品質、代碼架構裡潛在的風險，他們會重構單元測試，負責搭建測試平台並開發出人性化的自動化工具。其實很重要的一點是這裡所謂的自動化工具，並不僅僅是自動化測試所用，而是講一切研發的流程都能提高效率的各個環節都能用上的自動化，哪怕是HR部門使用的、產品經理適用的，或者使用者也能用上的，只要是能夠提高效率並使得Google產品研發過程更加順暢的工具，他們都會去嘗試做，而且持續的去改進。

那麼，Google的工程師們是如何騰出自己自己的時間來製作和維護改進那麼多工具的呢？在Google內部有一個20%為了創新的文化，每個員工允許將20%的工作時間拿出來做自己想做的任何事情，相當於每周只有4個工作日是必須專註在自己的工作上的。恰恰是在那20%的時間裡，Google的工程師們常常按照各自的興趣愛好和擅長的領域聚在一起，發起各種工具項目，並最終幾乎無一例外的全部開源的放給全世界一起來用，因為他們相信人的思維是無限寬廣的，集思廣益最好的辦法就是開源歡迎所有人下載和改進。事實上，例如像Selenium
WebDriver這種優秀架構，就吸引了來自全世界各地的優秀工程師參與，發展迅速幾乎都要納入W3C的Web自動化標準中去了。

此外，這一章還講解了Google裡測試工作的分類，他們喜歡用簡潔的Small，Medium和Large來定義測試類型，Size類的單詞更加形象直觀的表明此種測試的規模也就是它能覆蓋多大範圍的代碼。對應到傳統意義上，Small就相當於單元測試，只覆蓋單一的程式碼片段，而Medium就會將一些有關聯的程式碼片段組合在一起測試，有點類似整合測試，真正類比使用者行為的就是端對端的Large測試，類似我們常說的系統測試。在針對程式碼片段為主的Small和Medium測試中Google大量的使用了Fake和Mock技術來類比環境因素和資料對象。

第二章 The Software Engineer in Test

這章介紹的是Google的SET，也就是測試開發工程師這種角色。許多Google的SET都是從開發轉過來的，他們對測試感興趣，有著品質保障方面的天賦，也通常樂於分享和製作工具來提高所有人的效率。既需要對測試有興趣有熱情，又要有很強的編碼技術，這樣的人才，在市面上是很難找到的，從開發工程師中尋找往往是個更靠譜的辦法。筆者一直覺得，電腦技術不管是用在開發還是測試還是別的什麼地方，終究目的是為了讓人們的生活更加美好，何必要糾結自己是在做開發還是測試這些角色呢！

在Google，SET和SWE（研發工程師）是緊密合作的關係，他們的工作甚至有許多重疊的部分。雖然傳統的觀念認為，工程項目分工精細能導致效率。但如今的互連網IT行業需求瞬息萬變，資訊爆棚，市場機遇出現得快消失得也快，軟體的品質恰恰通過這種分不開的重疊，才能真正讓整個團隊都來為此負責。分工太明確了，會無端的引入許多人為的因素，對一些出現的問題，誰也不願意出來承認是自己做得不夠好。這兩種角色裡，SWE會寫更多的Small
Test代碼，而SET會寫更多的Mock和Fake Environment的代碼，Google的工程一般會以約定好的介面開始，一邊白盒一邊Mock這樣子起步，並預先設定好足夠的挑戰和裡程碑，隨時對代碼做靜態分析跟蹤進度。這是一種快速原型的概念，項目長時間處於不明確不可見狀態是件很危險的事情，所以Google願意用最少的時間先讓它跑起來，然後在持續的迭代改進，跟Agile裡的迭代交付也是同樣的概念，隨著迭代改進的過程，項目和需求也會變得越發明確。

在Google，大部分項目都共用一份程式碼程式庫，任何員工都可以去裡面下載別的項目別的團隊的代碼，這給了所有人一個高效學習的機會。例如我們遇到任何程式上的經驗問題或者編譯錯誤會去網上Google Search一樣，Google的工程師們一般都能在這樣一個共用程式碼庫中找到自己想要的例子做參考。而且敢於把自己的代碼Share出來，本身就代表對代碼品質的一種負責的態度，歡迎大家來拍磚、指教，也能對自身的代碼起到一個監督促進的積極作用。一個題外話是Google基本用到四大程式設計語言：C++、Java、Python和Javascript，員工用的工作機器基本都是定製化的Linux系統，他們會維護這些Linux核心甚至維護裡麵包含的編譯器，以保障大家的代碼都是被同樣版本的編譯器編譯通過的，可以在任何人的機器上無障礙的運行。在項目發起約定介面的時候，Google還有一種自己的語言叫Interface
Protocols，通過這種Protocol檔案的描述，SET和SWE都清晰明了項目的需求和功能是什麼樣子於是可以開始並行的寫一點測試一點循序漸進。Google有解譯器可以把Protocol格式的檔案，翻譯成常用四大語言中的任何一種，這樣把重複人為敲代碼的勞動都給省了，也算是工具文化的一個例子吧。

在許多其他的公司，測試開發就是負責做自動化的，關於這一點Google的觀點是自動化的攤子鋪得越大，隨著系統變遷需求變更，自動化本身就會變得越發脆弱。所以Google的方式是：使用一些Mock技術來隔離複雜的系統，為更加明確不易變更的組件做輕量級的自動化。往往工程師在自己的代碼Check in之前，就已經利用Mock和自動化在整個系統中運行過一遍經過了驗收和檢測了，這樣可以有力的保障程式碼程式庫中的代碼品質。

關於Google對SET的定位，從他們招聘的一些案例中可以讀到許多有意思的故事。他們最期望看到的SET是能夠提出解決問題的思路，先不管這思路是否是最優的。例如給定一個簡單的方法，思考對它進行單元測試。Google覺得優秀的SET不是簡單的去遵循單元測試的原則去按部就班的做，而應該儘可能提出自己的疑點，比如方法的擴充性、可重用性、多線程訪問的安全性、是否可以最佳化，更甚者應該考慮到指標溢出、分布式調用、如何分析它的健壯性，寫出的單元測試是否淺顯易懂，除了單元測試還可以做什麼來分析代碼的邊界、死結、記憶體泄露之類的風險。（由此可見，SET也需要相當強的技術背景）

聲明：轉載請註明原文出處。