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

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

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

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

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

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

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

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

1 開(kāi)發(fā)和測(cè)試流程

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

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

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

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

公共代碼必須盡可能地被復(fù)用而且相對(duì)獨(dú)立。因?yàn)榕c功能的復(fù)雜性和設(shè)計(jì)的巧妙性相比，可復(fù)用性帶來(lái)的價(jià)值更大。

所有依賴必須明確指出。

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

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

在共享代碼庫(kù)中的代碼，對(duì)測(cè)試有更高的要求。

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

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

使用統(tǒng)一的運(yùn)行平臺(tái)和相同的代碼庫(kù)，進(jìn)行持續(xù)集成測(cè)試、打包。

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

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

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

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

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

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

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

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

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

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

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

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

經(jīng)過(guò)良好測(cè)試的獨(dú)立庫(kù)。

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

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

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

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

在以上的活動(dòng)中，SET 始終是核心參與者。SET 還會(huì)同時(shí)編寫(xiě)許多的 mock 工具。

2 SET 角色

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

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

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

3 項(xiàng)目的早期階段

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

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

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

4 團(tuán)隊(duì)結(jié)構(gòu)

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

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

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

5 設(shè)計(jì)文檔

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

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

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

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

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

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

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

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

正確性：是否有語(yǔ)法、錯(cuò)字、標(biāo)點(diǎn)符號(hào)等方面的錯(cuò)誤。

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

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

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

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

6 接口和協(xié)議

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

7 自動(dòng)化計(jì)劃

SET 要盡早提供一個(gè)可供實(shí)施的自動(dòng)化測(cè)試計(jì)劃。計(jì)劃必須合情合理而且有影響力。因?yàn)橥度氲脑蕉啵S護(hù)的成本也會(huì)越大，所以需要保證計(jì)劃規(guī)模小而且目的性要強(qiáng)。

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

SET 會(huì)構(gòu)建一個(gè)輕量級(jí)的自動(dòng)化框架，并使用報(bào)表和儀表盤(pán)來(lái)展示收集到的測(cè)試結(jié)果以及測(cè)試進(jìn)度，整個(gè)過(guò)程公開(kāi)透明，這樣獲得的代碼的質(zhì)量會(huì)大大提高。

8 可測(cè)試性

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

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

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

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

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

9 測(cè)試大小的定義

9.1 小型測(cè)試

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

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

9.2 中型測(cè)試

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

9.3 大型測(cè)試

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

10 測(cè)試平臺(tái)

Google 的測(cè)試平臺(tái)的需要滿足的功能是：

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

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

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

看到一個(gè)項(xiàng)目的測(cè)試覆蓋率并查看結(jié)果。

對(duì)項(xiàng)目的每次代碼變更，都能夠運(yùn)行這個(gè)項(xiàng)目的小型測(cè)試，并將運(yùn)行結(jié)果發(fā)送給團(tuán)隊(duì)成員以輔助進(jìn)行代碼審查。

在代碼變更提高到版本控制系統(tǒng)后，自動(dòng)運(yùn)行項(xiàng)目的所有測(cè)試。

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

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

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

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

11.1 小型測(cè)試的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

因?yàn)榭梢院芸爝\(yùn)行完畢，所以在有代碼變更時(shí)就可以立即運(yùn)行，這樣可以較早地發(fā)現(xiàn)缺陷并及時(shí)反饋。

可以很容易做邊界場(chǎng)景與錯(cuò)誤條件的測(cè)試。

可以很容易地隔離錯(cuò)誤。

缺點(diǎn)：

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

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

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

11.2 中型測(cè)試的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

是小型測(cè)試到大型測(cè)試的過(guò)渡。

因?yàn)檫\(yùn)行速度較快，所以也可以頻繁地運(yùn)行它們。

缺點(diǎn)：

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

運(yùn)行速度沒(méi)有小型測(cè)試來(lái)得快。

11.3 大型測(cè)試的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

是最根本，也是最重要的，因?yàn)樗鼈兎磻?yīng)了系統(tǒng)是如何工作的。

缺點(diǎn)：

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

因?yàn)闇y(cè)試范疇很寬，所以如果測(cè)試運(yùn)行失敗，要精確定位到失敗的根源比較困難。

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

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

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

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

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

12 測(cè)試運(yùn)行的要求

每個(gè)測(cè)試與其他測(cè)試都是獨(dú)立的，它們能夠以任意順序運(yùn)行。

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