讀『Google軟件測試之道』

在IT領域，Google是一面旗幟，是一家非常善于思考善于嘗試的公司。隨著面臨挑戰的不斷增大，傳統的測試開展方式也越來越力不從心，這本書講述的就是一次完整的轉型過程，非常的有價值。這是本老書了，一年多前就拜讀過，當時更多看到的是差距和困難，隨著一年的努力和嘗試，突然覺得有點開竅，和大家做一些分享。

基本理念

Google在質量方面的基本共識是:

質量不是被測試出來的

具體的工作目標是：

讓每個工程師都注重質量

從業多年，這個口號其實經常能聽到，但是大多數時候只是一個口號而已，很長一段時間，我甚至覺得開發人員缺乏質量意識已成為了一種天性，如何破開這塊堅冰，Google也許能帶來點啟示。

組織變革

Google的變革是從組織開始，面臨的是幾個比較大的問題。

測試部門是否需要保留?
從思維角度說，開發是一種創建思維，而測試是一種破壞思維，兩者是無法同時兼容的。
一個部門是比較難兼容兩種思維方式的，所以Google保留了獨立的測試部門。

測試部門的定位如何？
新部門的名稱叫做 Engineering Productivity工程生產力部門。
從部門的名稱就可以看到，主要關注生產力提升方面。

工程生產力部門如何工作?
關鍵在于人員的分工，主要有兩類角色SET和TE。
TE(測試工程師)和常規測試角色類似，主要負責功能層面的驗證。
SET(測試開發工程師)這是一個全新的職責，其目標是幫助開發人員進行測試。

Google變革的核心是新增了一個全新的角色SET，這個角色主要起到了開發和測試的融合劑，也是把質量意識進行普及的關鍵。

測試分類

SET這個角色是如何協同工作的，關鍵是Google的測試分類。

測試分類是這樣的：

小型測試：單元測試。
中型測試：兩個或兩個以上模塊，關注功能交互。
大型測試：三個或以上，使用真實用戶場景和數據。

初看到這個分類，我是感覺有點凌亂的，命名上也太不嚴謹了。
從技術角度，對三類測試有個更詳細的區分，明確了很多。

小型測試的特點是運行時間短，而且沒有外部依賴。
并不是符合所有條件就算小型測試，如下代碼雖然符合，但仍然不算小型測試，因為其輸出結果不穩定。

    public String getString(){
        return new SimpleDateFormat("yyyy-MM-dd hh:mm:ss.SSS")
                        .format(new Date());
    }

三類測試的分工如下：

小型測試運行時間短、無依賴、輸出穩定，這些特性無疑都非常有利于測試，大多數開發人員完全能夠勝任，所有小型測試是由開發人員SWE來負責。同時，小型測試是所有模塊的基石，構成了這個質量體系的穩固基礎。并不是所有代碼都能符合小型測試的要求，所以SET的第一個職責是幫助開發人員將代碼重構符合小型測試。

中型測試會涉及到外部依賴和模塊間接口，相對難度較高，所以主要由SET來負責，同時，SET會負責接口相關的開發。

大型測試主要面向用戶，會由TE來負責。

在Google，SWE、SET和TE共同協作來完成質量工作，但三者之間有著嚴格的邊界區分，小型測試數量龐大易于測試，需要的是細節邏輯的掌握，SWE負責最為合適；在此基礎上，中型測試需要實現接口和外部依賴，專業性較強，由SET負責；大型測試主要面向用戶和價值，由TE來負責。三者共同構成了質量的金字塔。

ACC測試法

TE角色由于小型測試和中型測試的支持，主要關注用戶體驗和業務價值。工作方法叫做ACC測試法。

A特性、C組件、C能力是一個矩陣表達法。每一項能力(系統功能)需要同時考慮功能和特性(業務價值)兩方面。

ACC是一種測試計劃的安排法，和傳統的樹形結構相比，增加了特性的維度，突顯了業務價值。但是這種方法主觀性比較大，對測試人員有一定的要求。

小結

書中對于SET和TE的工作有著較為具體的描述，限于篇幅就不再贅述。整本書讀下來，讓我印象最為深刻的Google解決問題的思路。面對質量這個業界的巨大難題，Google的做法不是口號，也是不是革命，而是面對每個具體問題，進行了非常人性化的解決，將一個非常大的問題進行了分解。雖然其解決方法有著濃重的Google特色，我們不可以完全照搬，但是解決問題的思路和衍生的眾多技術成果卻是非常值得我們學習的。