小課堂week14 Google軟件測試之道

讀《Google軟件測試之道》

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

基本理念

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

質量不是被測試出來的

具體的工做目標是：

讓每一個工程師都注重質量

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

組織變革

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

測試部門是否須要保留?
從思惟角度說，開發是一種建立思惟，而測試是一種破壞思惟，二者是沒法同時兼容的。
一個部門是比較難兼容兩種思惟方式的，因此Google保留了獨立的測試部門。

測試部門的定位如何？
新部門的名稱叫作 Engineering Productivity工程生產力部門
從部門的名稱就能夠看到，主要關注生產力提高方面

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

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

測試分類

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

測試分類是這樣的：

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

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

	小型測試	中型測試	大型測試
時間	10ms內	1s內	儘量快
強制結束	1min	5min	15min
網絡服務	模擬	僅本地	是
數據庫	模擬	是	是
文件系統	模擬	是	是
用戶界面	模擬	不鼓勵	是
系統調用	否	不鼓勵	是
多線程	不鼓勵	是	是

小型測試的特色是運行時間短，並且沒有外部依賴。
並非符合全部條件就算小型測試，以下代碼雖然符合，但仍然不算小型測試，由於其輸出結果不穩定。

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能力是一個矩陣表達法。每一項能力(系統功能)須要同時考慮功能和特性(業務價值)兩方面。

	特性1	特性2	特性3
組件1	能力
組件2		能力
組件3			能力

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

小結

書中對於SET和TE的工做有着較爲具體的描述，限於篇幅就再也不贅述。整本書讀下來，讓我印象最爲深入的Google解決問題的思路。面對質量這個業界的巨大難題，Google的作法不是口號，也是否是革命，而是面對每一個具體問題，進行了很是人性化的解決，將一個很是大的問題進行了分解。雖然其解決方法有着濃重的Google特點，咱們不能夠徹底照搬，可是解決問題的思路和衍生的衆多技術成果倒是很是值得咱們學習的。