Google軟件測試開發(fā)工程師的工作內(nèi)容有哪些

一個完美的開發(fā)過程是這樣的：測試先行，開發(fā)人員會些設(shè)計一些邊界場景的測試用例，比如數(shù)據(jù)的取值范圍從極大到極小、循環(huán)語句超出限制范圍等等許多極端情況。這些測試代碼會作為產(chǎn)品代碼的一部分，以自檢代碼或者單元測試代碼的形式與功能代碼放在一起。這種類型的測試，開發(fā)人員是最適合、也是最有資格去做的人。

對于功能代碼而言，思維模式是建設(shè)，重點在考慮用戶、使用場景和數(shù)據(jù)流程上；對于測試代碼而言，思維模式是破壞，借用代碼擾亂用戶以及數(shù)據(jù)。在理想的開發(fā)過程里，我們可以把開發(fā)人員分為功能開發(fā)人員與測試開發(fā)人員。

我們還需要一個用戶開發(fā)人員，他們主要關(guān)心的問題是面向用戶的任務(wù)，包括用例、用戶故事、用戶場景、探索式測試等等。

上面的這種烏托邦式的理想開發(fā)過程，三種角色分工合作，真是完美啊 O（∩_∩）O~

可惜，這種公司在現(xiàn)階段好像還不存在過，Google 也只是接近這種模式。當(dāng)前的軟件業(yè)的發(fā)布周期需要以年為單位的客戶端模式向每周、每天、甚至每小時都會發(fā)布的云端模式轉(zhuǎn)變。Google 的客戶端也按照 “云端模式” 來發(fā)布，他們的客戶端都有一個“自動更新”功能。

Google 的軟件測試開發(fā)工程師（SET）的職責(zé)如下：

在單元測試方面給予開發(fā)人員支持。

為開發(fā)人員提供測試框架，這樣會方便開發(fā)人員編寫一些中小型測試，以利于后期進行更多的與質(zhì)量相關(guān)的測試。

1 開發(fā)和測試流程

公開的代碼庫（搜索非常便利）、和諧的工程工具、公司范圍內(nèi)的資源共享，這些共享服務(wù)依賴于 Google 的基礎(chǔ)設(shè)施產(chǎn)品，它們會加速項目完成，并且減少了項目失敗的風(fēng)險。

開發(fā)人員在維護這些代碼時，需要遵守這些規(guī)則：

所有的開發(fā)人員必須復(fù)用已經(jīng)存在的公共庫，除非在需求方面有很好的說服理由。

對于公共的共享代碼，必須能夠很容易被找到，并且具有良好的可讀性，這些代碼必須存儲在代碼庫的共享區(qū)域，以便查找。

公共代碼必須盡可能地被復(fù)用而且相對獨立。因為與功能的復(fù)雜性和設(shè)計的巧妙性相比，可復(fù)用性帶來的價值更大。

所有依賴必須明確指出。

如果一個開發(fā)人員對共享代碼庫中的某段代碼有更好的方案，他可以去重構(gòu)已有的代碼，并協(xié)助依賴在這個公共代碼庫之上的應(yīng)用項目遷移到新的代碼庫上。Google 設(shè)立了一個“同事獎金”，任何人如果受到其他開發(fā)人員的正面影響，就可以送出獎金作為感謝。除此之外，經(jīng)理們還有權(quán)使用其他獎勵手段。這么做的目的就是為了這種正向團隊合作形成一種良性的循環(huán)，并持續(xù)發(fā)展下去。

Google 非常重視代碼審核，特別是公共通用模塊的代碼必須經(jīng)過審核。開發(fā)人員必須通過相關(guān)語言（C++、Java、Python、JavaScript）的可讀性審核，當(dāng)開發(fā)人員按照約定的代碼風(fēng)格寫出干凈、簡潔的代碼之后，委員會會授予這名開發(fā)人員一個“良好可讀性”的證書。

在共享代碼庫中的代碼，對測試有更高的要求。

最小化對平臺的依賴。所有開發(fā)人員的操作系統(tǒng)都盡可能地與 Google 生產(chǎn)環(huán)境的操作系統(tǒng)保持一致。對 Linux 發(fā)行版本也進行了管理。這樣如果一個 bug 在測試機器上出現(xiàn)時，那么在開發(fā)機器和生產(chǎn)機器上應(yīng)該也能復(fù)現(xiàn)。

所有對平臺依賴的代碼，都強制要求使用公共的底層庫。Google 使用的每種編程語言，都要求使用統(tǒng)一的編譯器，這個編譯器針對不同的 Linux 發(fā)行版本都會進行持續(xù)的測試。限制運行環(huán)境可以避免許多與環(huán)境相關(guān)的那些難以調(diào)試的問題。保持簡單，也就相對安全。

使用統(tǒng)一的運行平臺和相同的代碼庫，進行持續(xù)集成測試、打包。

整體構(gòu)建流程如下：

針對某個服務(wù)，保證所有相關(guān)代碼編譯通過。

設(shè)置這個服務(wù)的構(gòu)建目標(biāo)（Google 中是公共庫、二進制文件或者測試套件，我們假設(shè)是公共庫）

編寫一套單元測試用例，所有外部重要的依賴通過 mock 模擬實現(xiàn)。

為單元測試創(chuàng)建一個測試目標(biāo)。

構(gòu)建并運行測試目標(biāo)，有問題就修改代碼，直到所有的測試都運行成功。

運行靜態(tài)代碼分析工具，確保遵守統(tǒng)一的代碼風(fēng)格，且通過一系列常見問題的靜態(tài)掃描檢測。

提交代碼，申請代碼審核，根據(jù)反饋再做修改，然后運行所有的單元測試并保證順利通過。

這里面包含兩個目標(biāo)：

庫構(gòu)建目標(biāo)：需要新發(fā)布的公共庫。

測試構(gòu)建目標(biāo)：驗證新發(fā)布的公共庫是否滿足需求。

一個 Google 產(chǎn)品由三部分組成：

經(jīng)過良好測試的獨立庫。

可讀性和可復(fù)用性好的公共服務(wù)庫。

覆蓋所有重要構(gòu)建目標(biāo)的單元測試套件。

為了保證單獨的服務(wù)可以并行地開發(fā)，服務(wù)之間的接口需要在項目的早期確定下來，這樣開發(fā)人員就可以依賴于協(xié)商好的接口上。為了保證服務(wù)級別之間的早期測試，這些接口一般只做了虛假實現(xiàn)。

在構(gòu)建目標(biāo)增長到一定規(guī)模時，針對功能集成的小型測試會成為回歸測試的一部分。

在以上的活動中，SET 始終是核心參與者。SET 還會同時編寫許多的 mock 工具。

2 SET 角色

SET 也是軟件工程師，是一個 100% 的編碼角色，他會作為測試人員盡可能早地參與到設(shè)計和代碼開發(fā)流程中去。

SET 是和功能開發(fā)人員坐在一起的，這樣更容易融入進去。

在面試 SET 的時候，在代碼要求上與軟件開發(fā)工程師（SWE）是一樣的，同時還要求 SET 明白如何去測試 SWE 編寫的代碼。也就是 SET 的要求更高，需要同時了解代碼以及測試的問題。

3 項目的早期階段

許多創(chuàng)新產(chǎn)品（比如 Gmail 和 Chrome OS）都來源于團隊 20% 的業(yè)余時間。只有在軟件產(chǎn)品變得重要的時候，質(zhì)量才顯得重要。

如果一個產(chǎn)品在概念上還沒有完全成型就去關(guān)心質(zhì)量，這是優(yōu)先級混亂的表現(xiàn)。因此在項目早期就強調(diào)測試，是一件非常愚蠢的事情。

Chrome OS 剛開始只有幾個開發(fā)人員做了原型，且多數(shù)都是腳本和虛假實現(xiàn)，他們拿著只是原型的瀏覽器應(yīng)用模型做演示，并通過了正式的立項批準(zhǔn)。一旦得到正式批準(zhǔn)立項，項目的開發(fā)總監(jiān)就會找測試團隊，尋求測試資源。

4 團隊結(jié)構(gòu)

SWE 一般僅在自己的模塊領(lǐng)域內(nèi)提供最優(yōu)的解決方案，但從整個產(chǎn)品的角度來看，視野略窄，而一個 SET 不僅要具有更廣的產(chǎn)品視野，而且在產(chǎn)品的整個生命周期中對產(chǎn)品和功能特性都要做充分的理解。

早期的計劃做多少和怎樣做比較合適，由創(chuàng)建項目的負(fù)責(zé)人來做最終的決定。

Google 的技術(shù)負(fù)責(zé)人一般由工程師擔(dān)任，負(fù)責(zé)設(shè)定技術(shù)方向、開展合作、充當(dāng)與其他團隊溝通的項目接口人。

5 設(shè)計文檔

在初期，團隊成員一起協(xié)同完成設(shè)計文檔的不同部分，這些文檔需要技術(shù)負(fù)責(zé)人的審核。SET 在團隊中的優(yōu)勢就是他們擁有產(chǎn)品方面最廣闊的視野。

為什么要讓 SET 參與審核設(shè)計文檔：

SET 熟悉系統(tǒng)設(shè)計（通過閱讀所有設(shè)計文檔）。

SET 早期提出的建議會反饋在文檔和代碼里。

作為第一個審閱所有設(shè)計文檔的人，SET 對整個項目的了解程度超過了技術(shù)負(fù)責(zé)人。

SET 在項目初期就與開飯人員建立了良好的工作關(guān)系。

審核設(shè)計文檔時，需要帶著一定的目的性：

完整性：找出一些特殊背景知識的地方，鼓勵作者在這方面添加更多的細(xì)節(jié)，或者增加一些外部文檔的鏈接，作為補充。

正確性：是否有語法、錯字、標(biāo)點符號等方面的錯誤。

一致性：確保配圖和文字描述保持一致，確保文檔沒有出現(xiàn)與其他文檔在觀點上截然相反。

設(shè)計：設(shè)計經(jīng)過深思熟慮。

接口和協(xié)議：清晰的定義，完整地描述。

測試：保證系統(tǒng)的可測試性，而且易于測試。

6 接口和協(xié)議

Google 采用的是 protocol buffer 語言，它與編程語言和平臺無關(guān)，對結(jié)構(gòu)化數(shù)據(jù)具有可擴展性，但相比 XML 更小、更快、也更簡單。開發(fā)人員使用 protocol buffer 的描述語言定義數(shù)據(jù)結(jié)構(gòu)，然后自動生成源代碼。

7 自動化計劃

SET 要盡早提供一個可供實施的自動化測試計劃。計劃必須合情合理而且有影響力。因為投入的越多，維護的成本也會越大，所以需要保證計劃規(guī)模小而且目的性要強。

SET 會先把容易出錯的接口進行隔離，并針對它們創(chuàng)建 mock，這樣就可以控制它們之間的交互，從而確保良好的測試覆蓋率。

SET 會構(gòu)建一個輕量級的自動化框架，并使用報表和儀表盤來展示收集到的測試結(jié)果以及測試進度，整個過程公開透明，這樣獲得的代碼的質(zhì)量會大大提高。

8 可測試性

SET 要保證系統(tǒng)的可測試性。他是一個質(zhì)量顧問的角色，為開發(fā)人員提供程序結(jié)構(gòu)和代碼風(fēng)格方面的建議，這樣開發(fā)人員才能更好地做單元測試。SET 還提供測試框架方面的建議，使開發(fā)人員能夠在測試框架的基礎(chǔ)上寫測試。

開發(fā)人員必須有能力進行代碼審查，代碼審查有來自工具和公司文化方面的支持。只有被證明是值的信賴的開發(fā)者，才能往代碼庫中提交代碼。

Google 把代碼審查作為開發(fā)流程的中心，因此相對于編寫代碼而言，代碼審查更值的炫耀。

代碼已一個“變更列表”（change list，下文會簡稱為 CL）的單元被編寫和封裝起來。CL 會被提交審查，Google 使用代碼審查工具 Mondrian 發(fā)送給具有審核資格的 SWE 或 SET進行審查。

如果 CL 很大，那么審查者會要求把數(shù)量較大的 CL 分解為數(shù)量較小的幾個 CL。有經(jīng)驗和值的信賴的開發(fā)人員會得到“可讀性”的資格，大家同心協(xié)力確保整個代碼庫看起來像是由一個人編寫的一樣。

9 測試大小的定義

9.1 小型測試

小型測試就是單元測試。它一般集中精力在函數(shù)級別的獨立操作與調(diào)用上，這樣的限定可以提供更加全面的底層代碼的覆蓋率：

范圍的隔離而且沒有外部依賴，所以小型測試可以在很短的時間內(nèi)運行結(jié)束。這樣它們就可以執(zhí)行的比較頻繁，也可以很快發(fā)現(xiàn)問題。

9.2 中型測試

中型測試的主要目標(biāo)是驗證指定模塊之間的交互，也就是集成測試。鼓勵使用模擬技術(shù)（mock）來解決外部服務(wù)的依賴問題。有的情況下 mock 不能用，那就用輕量級的虛假實現(xiàn)（fake），比如使用常駐內(nèi)存的數(shù)據(jù)庫。

9.3 大型測試

大型測試就是系統(tǒng)測試，或者端到端測試。它會依賴外部資源，比如數(shù)據(jù)庫、文件系統(tǒng)、網(wǎng)絡(luò)服務(wù)等等。

10 測試平臺

Google 的測試平臺的需要滿足的功能是：

開發(fā)人員編譯和運行小型測試，希望立即能夠知道運行結(jié)果。

開發(fā)人員系統(tǒng)運行一個項目中的所有小型測試，并能夠快速知道運行結(jié)果。

只有在代碼變更后，才希望去編譯運行所有相關(guān)的測試，并能夠立即知道運行結(jié)果。

看到一個項目的測試覆蓋率并查看結(jié)果。

對項目的每次代碼變更，都能夠運行這個項目的小型測試，并將運行結(jié)果發(fā)送給團隊成員以輔助進行代碼審查。

在代碼變更提高到版本控制系統(tǒng)后，自動運行項目的所有測試。

每周都能得到代碼覆蓋率，并實時跟蹤覆蓋率的變化。

當(dāng)每一個測試都被標(biāo)注為相應(yīng)的規(guī)模后，調(diào)度器可以優(yōu)化任務(wù)隊列，達到合理利用的目的。

Google 的測試系統(tǒng)會監(jiān)測某個測試任務(wù)是否超時，或者消耗的資源超過了這個測試規(guī)模所應(yīng)使用的資源時，會取消它并報告錯誤。

11 測試規(guī)模的益處

11.1 小型測試的優(yōu)缺點

優(yōu)點：

因為可以很快運行完畢，所以在有代碼變更時就可以立即運行，這樣可以較早地發(fā)現(xiàn)缺陷并及時反饋。

可以很容易做邊界場景與錯誤條件的測試。

可以很容易地隔離錯誤。

缺點：

代碼應(yīng)清晰干凈、規(guī)模較小且重點集中。

為了便于模擬，系統(tǒng)之間的接口要有良好的定義。

有時候?qū)σ蕾囐Y源的模擬是有難度的。

11.2 中型測試的優(yōu)缺點

優(yōu)點：

是小型測試到大型測試的過渡。

因為運行速度較快，所以也可以頻繁地運行它們。

缺點：

依賴外部資源，所以本身就具有不確定性。

運行速度沒有小型測試來得快。

11.3 大型測試的優(yōu)缺點

優(yōu)點：

是最根本，也是最重要的，因為它們反應(yīng)了系統(tǒng)是如何工作的。

缺點：

依賴外部資源，所以本身就具有不確定性。

因為測試范疇很寬，所以如果測試運行失敗，要精確定位到失敗的根源比較困難。

準(zhǔn)備測試數(shù)據(jù)很耗時。

大型測試不能像小型測試那樣可以走特定的代碼路徑，所以只能進行功能的常規(guī)測試。

小型測試帶來優(yōu)秀的代碼質(zhì)量、良好的異常處理以及優(yōu)雅的錯誤報告。中大型測試帶來整體產(chǎn)品質(zhì)量和數(shù)據(jù)驗證。

代碼覆蓋率的結(jié)果會存儲在云端，任何開發(fā)人員都可以通過內(nèi)網(wǎng)的網(wǎng)絡(luò)，使用瀏覽器來查看這些報告。

總體上的經(jīng)驗法則是：70% 是小型測試，20% 是中型測試，10% 是大型測試。如果項目是面向用戶的，擁有較高的集成度，或者用戶接口比較復(fù)雜，就應(yīng)該使用更多的中大型測試；如果是基礎(chǔ)平臺或者面向數(shù)據(jù)的項目，最好有大量的小型測試。

12 測試運行的要求

每個測試與其他測試都是獨立的，它們能夠以任意順序運行。

不做持久化方面的工作。當(dāng)測試用例測試后，要保證測試環(huán)境的狀態(tài)與測試用例開始執(zhí)行之前的狀態(tài)是一致的。