google軟件測試之道讀後感（一）

這幾天在抽空讀一本新書，久負盛名的《google軟件測試之道》。以前在網絡上一點一點地看過它的英文版，很受觸動，還作了很長的讀書筆記，如今看到了中文版，才恍覺以前的好些理解存在不恰當的地方，英文讀寫能力真是個硬傷。。

這本書不少讓我驚奇的地方，能夠說刷新了從業這麼久的三觀。例如它說測試團隊真正的定位在於提升「工程生產力」，google內部只有很是少的專職測試人員，有的是具備測試視角的研發團隊，和兼具研發能力的測試工程師，還有具備用戶視角的產品經理。因爲人員的精簡，所以尤爲注重優先級的安排，充分運用各類技術手段，建立高影響力、低阻力的實踐活動。做者提到，讓測試員工保持昂揚的鬥志和充沛的精力是很是重要的。在現有工做中，本身一直糾結沒有充分的測試時間和充足的測試人員，認爲研發老是壓榨測試，爲作不到充足的測試而抱怨，本身鑽進了一條走不通的死衚衕。看到書裏的描述，頓時以爲本身把方向想反了，還沉浸在過去幾十年老舊的測試理念中沒法自拔。測試和開發，只是視角不一樣，能力上並不該該有差異。以爲測試時間不足，問問本身，本身的測試開發能力跟上了嗎？充分運用了各類測試技術和測試手段了嗎？測試用例優先級和設計合理嗎？測試熱情是否充沛？產品成熟後，是否引入了自動化測試？測試不該該成爲研發的阻礙，敏捷測試強調的是持續集成測試，測試和開發是密不可分的一個總體，「質量更多的是一種預防行爲，而不是檢測。質量是開發過程的問題，而不是測試問題。「這些話，給了我現實工做中莫大的指引。

從書中看出，google的各類框架已經很是成熟了，開發也有一整套的google準則，一切都已高效、優質爲目標。代碼從產生，就在不停的作測試，這個過程，不少是有完善的自動化機制觸發的，例如代碼提交後，自動編譯、自動測試，甚至能夠自動上報缺陷。從函數級別的小型測試，亦即單元測試，到側重接口交互的中性測試，而後是系統測試，最後進入灰度測試，經過後，才發佈beta版本。測試無處不在，測試團隊的工做就是編寫及維護各類測試功能代碼，重複且單調的工做都交給機器，人工只測新功能和探索性測試。感受google的測試就像一個高度工業化的流水線，前面通過大量的機器檢測，最後一道是人工的鑑別，最終出來的就是完善的成品，持續集成，快速迭代，如此纔有高效的生產力啊！

關於自動化，書裏提到，」在端到端的自動化測試上過分投入，經常會把你與產品的特定功能設計綁定在一塊兒，這部分測試在整個產品穩定以前都不會特別有用。「所以，引入自動化的時機比較重要，只有重要且穩定的產品，纔有自動化的必要，減小沒必要要的自動化代碼維護開銷。

目前看到這裏，一個比較深的感觸就是，要切實提升本身的代碼開發能力，不能在以測試爲藉口，看看這個圈子裏，有不少具有完美編程能力的測試員，測試的進階，要以代碼編程能力爲跳板，不然，就永遠只能成爲鼠標黨！！！