我讀完了一本非常有趣的書，《How Google Tests Software》。我是從一個對這本書的作者之一， James Whittaker，的IT訪談中聽到這本書的。訪談的內容實際上對這本書里的很多關鍵點做了很好的概述，但我仍然從讀這本書的過程中發(fā)現(xiàn)了很多很有價值的內容。

這并不是一本講“如何做”的書，并不是在說關于如何測試軟件的具體步驟。相反，它站在一個更高層面上，大部分的篇幅都在致力于描述谷歌公司里各種不同的測試角色。從這個訪談以及這本書里，我感覺有三個獨特的主題呈現(xiàn)在我面前。

測試工具的規(guī)模

谷歌對測試/軟件質量投入了大量的精力，給人非常深刻的印象。他們?yōu)樽詣踊幾g，自動化回歸測試，延遲測試，代碼審查和用戶反饋所制作的各種基礎工具讓人眼花繚亂。當這些復雜的工具和各種復雜的谷歌產(chǎn)品混合在一起時，你很難想象這樣一個相互交織的軟件世界里各部分是如何發(fā)揮作用的。同時，你也很容易看出谷歌的產(chǎn)品有多么的復雜，如果沒有這些他們自己開發(fā)出的測試工具，這些產(chǎn)品是不可能完成的。

測試行為實用主義

對于測試，谷歌給人的感覺似乎是非常實用主義。如果某個自動化測試很難維護，他們就會丟掉它們。如果某個軟件功能不是高風險的或高影響力的，他們甚至不在意是否有測試(或者更好的做法是砍掉這個功能)。相較于在軟件完成后寫測試計劃，谷歌卻是專注于ACC(屬性，組件，能力)模型。按照這三個概念，一個軟件應用會按下面的方式描述。

• 屬性：系統(tǒng)中的形容詞，通常是銷售、市場關注的(例如，速度，安全，穩(wěn)定等)。
• 組件：系統(tǒng)中的名詞(例如 購物籃，打印/格式化功能)。
• 能力：系統(tǒng)中的動詞(例如往購物籃添加商品，計算購物金額).

測試用例必須涵蓋每個概念里的至少一項，以此保證應用的主要功能被測試到，并且不做無用功。

另外有趣的一點是，谷歌刻意保持測試人員的最少化，以此保障測試力量的最優(yōu)化。最少化測試人員還能迫使開發(fā)人員在軟件的整個生命期間都參與到測試中，尤其是在項目的早期階段，測試基礎架構容易建立的時候。

軟件測試的未來

最后，作者對軟件測試給我們展示了一個非常壯麗的未來(至少是針對商業(yè)應用軟件)。傳統(tǒng)的測試角色將會消失，取而代之的是開發(fā)人員測試和自動化測試。相較于依賴于手工測試人員，未來的軟件團隊將依賴內部全體員工測試，beta版大眾測試和早期用戶測試。傳統(tǒng)的測試角色將轉變職能，變成“測試人員”開發(fā)測試工具，開發(fā)用戶反饋工具，處理用戶bug報告提交。這是一個壯麗的愿景，我認為只有像谷歌這樣具有相當規(guī)模的公司才能夠實現(xiàn)。對于小公司來說，我很難想象它們能實施這樣的測試流程。畢竟，并不是每個公司都有2萬個內部職員來一起試用測試谷歌瀏覽器。但由于測試工具的改進，以及這個領域的OSS逐漸建立，大的趨勢看起來正像這個方向發(fā)展。

因為我正是一個苦惱于如何將TDD集成到日常的開發(fā)流程中的人，這本書給我來相當大的啟發(fā)。它在鼓勵我們在測試中適當?shù)牟捎靡环N適用主義的態(tài)度，不要讓完美主義成為好愿望的敵人。隔絕部分代碼，讓測試易于維護，減少應用中的高風險區(qū)域，這給了我們從擔心100% 測試覆蓋率的思路上找到了第二個值得考慮的方向。