谷歌（google）是如何做軟件測試的

　　這是這個主題系列的第一篇文章。

　　我聽到的最多的一個問題是“Google如何做測試?”這個問題已經在本博客上零零散散的回答過，但這次的回答將會做一個完整的更新。Google的測試策略從來沒有變過，我們執行測試的策略隨著公司的演化而演化。我們現在是一個集搜索、應用、廣告、移動、操作系統等業務于一體的公司。每一個我們關注的領域都是在該領域有意義的問題。隨著我們不斷的增加新的“關注領域”(Focus Areas)，延伸已經存在的領域，我們的測試也在不斷的擴展和改善。而我們當下在做的以及我們預計未來將會發展的方向，就是我將要在這系列文章中將要闡述的問題。

　　讓我們先從組織結構的介紹開始，這個或許會讓你感到驚奇。在Google并不存在一個真正意義上的測試部門。測試實際存在于一個關注領域，我們稱它為“生產率工程”(EngineeringProductivity)。“生產率工程”是一個擁有一定數量的橫向和縱向的工程學科，測試是最大的一個。而在這個組織中，“生產率工程”是由以下三部分組成：

　　1. 產品團隊(productteam)。他們設計的內部的和開源的工具由公司里的所有工程師完成。他們負責構建和維護代碼分析器、開發環境、測試用例管理系統、自動化測試工具、構建系統、源代碼控制系統、代碼回顧計劃、缺陷數據庫。他們的目標就是設計一種能讓工程師更有效率的工具。工具是在檢測預防的戰略目標中占非常大的一部分。

　　2. 服務團隊(servicesteam)。他們在一個非常寬泛的領域內向產品團隊提供諸如包含工具(includingtools)、文檔、測試、發布管理、培訓等方面的專業技能。他們的專業技能涵蓋可靠性、安全性、國際化等方面，也會處理產品團隊可能遇到的關于功能細節方面的問題。任何一個其他“關注領域”的服務團隊也可以為產品團隊提供專業技能服務。

　　3. 嵌入式工程師(embeddedengineer)。他們有效的擔負起了Google產品團隊在有需要時的需求。有些工程師會跟著同一個的產品團隊數年，另一些則只會在一個較短的周期內為產品團隊的需要提供服務。Google鼓勵所有的工程師經常更換自己服務的產品團隊，以保持飽滿的精神狀態，并保證有效和客觀的工作。測試工程師也一樣，更換團隊的節奏也是因人而異的。有些測試工程師在Chrome項目下數年，而有一些則在加入團隊18個月后去了別的團隊。在產品知識與新穎的視角間保持一個良好的平衡，是一個測試管理者需要關注的。

　　據上，也就是說測試工程師需要向產品經理的主管報告，但是也需要與產品團隊一樣自己對產品有所識別，比如搜索、Gmail、Chrome這樣的產品團隊。從組織架構上來說，他們是共屬于兩個團隊的。他們與產品團隊在一起辦公，共同參與產品計劃，與他們一起共進午餐，擁有相同的獎金，獲得和團隊所有成員一樣的待遇。獨立報告這樣的組織結構的好處在于提供給了測試工程師一個論壇，去分享他們的看法。好的測試想法不會被產品束縛，可以很容易的由產品工程師傳你給所有的測試工程師，獲得公司內最好的技術。

　　這種項目與報告結構相分離是有其自身的挑戰性的。到目前為止，最大的挑戰在于測試工程師是外部資源，產品團隊不能在他們身上壓太大的賭注，他們必須確保產品的質量合乎預期。是的，在Google，產品團隊為他們質量負責，而不是測試工程師。每一個開發工程師需要自己做測試，而測試工程師的工作是確保他們的自動化測試結構的可移植性，以確保其是可信賴的。測試工程師是為了讓開發工程師可測試。

　　我喜歡的策略是讓開發工程師和測試工程師處于相同的地位。這樣做一方面可以確保我們伙伴間對質量有相同的責任，并且把對質量負責的重任交給應該確保其正確性的開發工程師。另一方面，這樣會確保我們存在一個“多對一”的開發工程師對測試工程師的比例。開發工程師多于測試工程師。這樣的話，他們測試上做得越好，他們在數量上就比我們越多。產品團隊也會以這樣的高比例而驕傲。

　　現在，我們都到齊了嗎?你們都看到了這個我十分確定的策略的漏洞了。有一個非常大的問題，開發工程師不能去做測試。我該去拒絕誰呢?沒有多少人讓我去拒絕，尤其是在我去年做的一次關于開發工程師與測試工程師對比的游戲之后(告訴你：測試工程師贏得了較量)。

　　Google的回答是分解角色。我們在Google用兩種不同類型的測試角色解決了兩種不同問題。下一章我將談一談這些角色，以及我們是如何將問題分解為兩個部分的。
 

　　為了踐行 “誰構建，誰破壞”的座右銘，一些超出常規意義上的開發工程師的角色是有必要的。也就是說，有必要存在一種讓開發工程師更快更有效的做測試的工程作用。在Google，我們設置了一些以提高他人更有成效為工作內容的角色。這些工程師把自身當作一名測試工程師看待，但是他們真正的任務是讓測試更有效率。他們的工作是為了讓開發工程師更有效率，而提高質量是更有效率的一個很大的組成部分。下面是這些角色的一個簡要介紹：

　　軟件工程師(Software Engineer，SWE)就是傳統的開發工程師的角色。他們為用戶編寫各個功能的代碼。他們創建設計文檔，設計數據結構，進行架構總體的設計，并且花費大量的時間編寫和檢查代碼。他們編寫大量的測試代碼，包括測試驅動設計(test driven design)、單元測試以及其它我們將要在后文中提到的內容，他們參與各種規模的測試構建。他們為他們所接觸的一切由他們編寫的、維護的、修改的代碼負責。

　　測試開發工程師(Software Engineer in Test，SET)同樣也是一個開發工程師的角色，只不過他們更多的關注于軟件的可測試性。他們檢查設計，特別關注代碼質量和可能存在的風險。他們不斷的檢查代碼，以確保其可測試性。測試開發工程師編寫單元測試框架和自動化腳本，他們在代碼層面是軟件工程師的伙伴，但是他們更關注不斷增長的代碼的質量和測試覆蓋率，而不是增加幾個新的功能特性或者不斷優化的性能。

　　測試工程師(Test Engineer，TE)和測試開發工程師恰好完全相反。這個角色的主要職責是將測試放在第一位，開發放在第二位。測試工程師花費大量時間在寫自動化測試腳本的形式，編寫那些驅動使用的場景以及模仿用戶使用的代碼。他們也會組織軟件工程師和測試開發工程師的測試工作，解釋特使結果，驅動執行測試，尤其是在項目后期驅動項目向發布的方向發展。測試工程師是產品方面的磚家，質量的建議者，以及風險的分析師。

　　從質量的角度上講，軟件工程師只對產品的特性和這些特性的質量負責。他們負責容錯設計，故障恢復，測試驅動開發，單元測試，以及和軟件測試開發工程師一起為產品特性編寫測試腳本。

　　測試開發工程師是提供測試特性的開發工程師。一個框架，可以通過模擬新開發的代碼與樁(stub)、虛擬對象(mocks)、仿冒(fake)的依賴關系將新開發的代碼進行隔離，并且確定提交順序以管理代碼的合入。換句話說，測試開發工程師編寫可供讓軟件開發工程師進行特性測試的代碼。實際上大多數測試是由軟件開發工程師執行的。測試開發工程師是確保特性的可測試項，而軟件工程師則更多參與測試用例的編寫。

　　測試開發工程師主要關注在開發工程師(developer)。獨立特性的質量是目標，而促使開發工程師容易測試他們編寫的代碼是開發測試工程師主要關注的目標。我可以十分肯定的說各位讀者一定清楚的看到了，這里提到的開發的關注點留下了一個很大的漏洞：用戶角度的測試呢?

　　在Google用戶集中測試是測試工程師的主要工作。假設軟件工程師和測試開發工程師已經將執行模塊和特性級別的測試進行得非常充分了，下一步的工作就是了解這個可執行的代碼和數據聚合的產品是如何在一起工作以滿足用戶的需要的。測試工程師扮演著二次檢查這些經過勤奮的開發工程師開發出的作品的角色。任何明顯的缺陷都是早期開發工程師測試不充分或粗心大意的表現。當這種缺陷非常罕見時，測試工程師就可以把主要工作轉為確保軟件可以在用戶的場景下正常運行，確保軟件是高性能的和安全的，是符合國際化標準的等等。測試工程師執行很多測試，協調眾多測試工程師測試工作，聯系測試工程師、外包測試工程師、代碼聚合測試工程師、內部測試人員(dog fooders)、beta版用戶和早期用戶(early adopters)。他們會不斷溝通包括包括基本設計、特性的復雜性以及失敗的避免方法在內的可能產生的風險。一旦測試工程師介入，他們的任務會變得無休止。

　　好了，關于各個角色你應該會有一定的了解了。下次，我將更深入的講解我們是如何通過這些角色進行工作的。感謝你們的關注。

原文轉自：http://www.kjueaiud.com