《Google軟體測試之道》—第1章1.4節爬、走、跑

本節書摘來自異步社群《google軟體測試之道》一書中的第1章1.4節爬、走、跑，作者【美】james whittaker , jason arbon , jeff carollo，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

1.4　爬、走、跑

在擁有如此少量測試人員的情況下，google還可以取得不錯的成果，核心原因在于google從來不會在一次産品釋出中包含大量的功能。實際上，我們的做法恰恰相反，在一個産品的基本核心功能實作之後，就立刻對外釋出使用，然後從使用者那裡得到真實回報，再進行疊代開發。這也是我們在gmail産品上的經驗，gmail帶着beta标簽線上上營運了四年，這個标簽用以警示我們的使用者，gmail仍處于改良之中。對于最終使用者，隻有該産品達到99.99%的可用性時，我們才會把beta标簽去掉。在android g1這個産品上，我們再次使用了這個方法，讓這個非常有用且經過良好設計的産品變得更棒了，功能也更加豐富全面，之後的nexus手機也采用了相同的政策。有一點需要引起注意，對于初期版本的使用者，并不是因為這個産品還處于早期版本就不為之提供足夠的功能，早期版本并不意味着是一個不可用的爛版本。

注意

google經常在最初的版本裡隻包含最基本的可用功能，然後在後繼的快速疊代的過程中得到内部和外部使用者的回報，而且在每次疊代的過程中都非常注重品質。一個産品在釋出給使用者使用之前，一般都要經曆金絲雀版本、開發版本、測試版本、beta或正式釋出版本。

google釋出的過程雖然快，但也并不像想象中如牛仔一般的魯莽與倉促。實際上，為了釋出我們稱為beta的版本，一個産品要經曆一系列的内部版本驗證，用以證明它已經具備了一定的品質。例如chrome，這是我加入google之後的兩年都為之工作的一個産品，根據我們對産品的信心以及來自使用者的回報，我們在整個過程中使用了不同的版本，大緻順序如下。

金絲雀版本：這是每日都要建構的版本，用來排除過濾一些明顯不适宜的版本。就像煤礦井裡的金絲雀（譯注：17世紀，英國人将金絲雀放到煤礦井裡檢測井中空氣品質。如果金絲雀死了，則表示礦井中的空氣已達到令人中毒的水準。此處意為對一件事情的預警），如果建構失敗了的話，意味着我們的流程可能在哪裡出了嚴重問題，需要去複查一遍我們的工作。使用金絲雀版本需要極強的容忍度，而且在這個版本下可能無法使用應有的基本功能。一般來說，隻有這個産品的工程師（開發或測試人員）和管理人員才會安裝使用金絲雀版本。

android團隊在這方面有更勇敢的嘗試，所有核心開發團隊成員的手機上都安裝有每日建構的版本。這樣做是為了減少往代碼庫中送出有問題的代碼，一旦安裝了錯誤代碼，手機甚至都無法使用其基本功能，例如和家人通話。

開發版本：這是開發人員日常使用的版本，一般是每周釋出一個。該版本具有一定的功能并通過了一系列的測試（我們将會在随後的章節裡讨論這點）。所有這個産品下的工程師都會被要求去安裝這個版本，并在日常工作中真正使用它，這樣可以持續對這個版本進行測試。如果一個開發版本不能夠滿足日常真實工作的需求，那麼它将會被打回為金絲雀版本。發生這種情況不但令人郁悶，工程團隊也需要再花費大量的時間去重新評估。

測試版本：這是一個通過了持續測試的版本。這個版本基本上是最近一個月裡的最佳版本了，也是工程師在日常工作中使用的最穩定最信任的一個版本。測試版本可以被挑選作為内部嘗鮮（譯注：dog food）版本，如果該版本有比較持續的優良表現，也是作為beta測試的候選版本。一些情況下，如果測試版本在公司内部使用得足夠穩定，一些想更早嘗試這個産品的外部合作夥伴也會使用這個版本。

beta 或釋出版本：這個版本是由非常穩定的測試版本演變而來，并經曆了内部使用和通過所有品質考核的一個版本，也是對外釋出的第一個版本。

這種爬、走、跑的模式，給我們的應用程式盡早地提供了一個測試驗證的良好機會。與從自動化測試那裡得到的回報一樣，我們每天都能從内部使用者那裡得到關于這些版本的品質回報。