這幾天又翻了幾頁這本書，覺得妙語連珠，關鍵語錄摘抄如下，並補充自己的一些思考：

“如果你想要求一個團隊去嘗試新的事物或者做某些改進，給他們提供一個聯系人會更好一些，這個聯系人來源於更大的社區，並可以從他那裏得到幫助”；

“不要陷入嘗試去創建一個包含獨立指標的完美系統的陷阱中。對所有人都完美的事情是不存在的。在沒有可替代的方案時，在合理的地方達成一致並勇往直前是很重要的。需要靈活的時候就靈活一些，但一定要堅持你的原則底線”。

當考慮團隊建設方面時，在以前總是收獲理想很豐滿，現實很骨感的局面，最後總是不了了之的結局。這比沒開展還壞，因為會打擊團隊的積極性，忙亂一頓，卻看不到明顯的產出，而且有很強的受挫感。這裏提到要有一個指導者，而且最好有一個這樣的聯盟，大家一起來做這件事情，形成一種社區的氛圍，那事情的成功性會較大。而且，做事情，不要太過死板，既然是嘗試，就沒有板上釘釘的事情，一直強調考核和目標，這樣的行政指標會讓人反感和排斥。適當的轉彎，可以讓團隊走的更遠。

“專註於你的用戶，理解他們的需求並解決他們的問題。”

“缺陷驅動開發，一旦用戶發現了一個bug，我就立刻去修復它，然後再宣布它沒有問題了，更加完美無瑕”。

產品的最終目標，是滿足用戶的需求，無論是真實功能上的需求，還是用戶無法提出來的隱形需求。要做到缺陷驅動開發，當然不能把缺陷都放到市場上等待用戶發現，而是在實驗室內多次叠代，多次從用戶角度去試用，通過快速的叠代，持續的集成來實現。這是敏捷的思想，我想到了今天，世界上測試技術那樣多，但有一點是不變的，那就是要快。只有測試足夠的快，能快速執行，快速出結果，快速評估，才能提高生產力和效率。

“試驗性工作、尚無明確目標或用戶故事的早期產品，TE很少參與，甚至不參與。”

“過度早期地投入測試意味著資源上的浪費，尤其是在SET已經深度介入的時候”

“以策略上將，給一個項目配備多少測試人員，取決於項目風險和投資回報率”

”TE擅長發現需求中的模糊之處，分析溝通不明確的問題“

”一旦找到薄弱點，TE就會通過測試使軟件出錯，然後與開發、產品、SET一起推動解決這些bug“

”如果做測試計劃已經來不及了，那就幹脆不做了。如果一個項目最需要的是測試，那就做一個簡單夠用的指導性計劃，一些測試教條所倡導的從頭就介入的模式，在google並不適用。“

google一直在強調，傳統的測試模式在快速叠代的今天已經有些跟不上了，至少從我工作的經驗來看，確實是這樣。測試跟不上研發的進度，研發抱怨測試拖了項目的後腿。測試什麽時候介入，也無需一味按照傳統的開發模型來生搬硬套。但是這裏提到的測試指的是系統測試，而其他的測試，例如單元測試、集成測試，以及測試腳本的開發和維護，則是在項目之初就開始了。測試的角色是更加全方位的，測試是真正意義上的測試開發工程師，產生的測試代碼和產品功能代碼一樣屬於產品功能完整性的一部分。這其實給測試提出了更大的要求和期待，既要熟悉測試方法，兼具用戶視角，又要有很強的編程能力，是真正意義上的開發工程師。google內部對測試工程師的角色劃分也非常細致，可以看出是真正重視人員培養的。越發覺得，別人是真正講求效率和實效性的，和自己當下的處境相比，現實差距太大啦。。。

”測試人員不應該對測試文檔過於珍愛。糟糕的測試用例不會受到足夠的關註和改善，他們只會被拋棄，而最後留下來的是更好的測試用例。“

”作為一種測試文檔，測試計劃的生命周期是所有測試產物中最短的“

”測試計劃是最早出現，最先被遺忘的測試產物“

”伴隨著計劃內或計劃外的變更，維護一份測試計劃是要花費大量精力的，除非多數項目的成員會定期查看，否則測試計劃並沒有什麽價值“

這裏道出了現實中測試計劃的尷尬局面。有時候甚至會產生要測試計劃何用的嘆息，測試計劃執行完後，我們對於測試的程度和產品質量的好壞仍然不能評估，不知道還有哪些沒測，哪些是風險點，哪些對於產品來說是至關重要的。每次的測試計劃不能相互關聯，一次測試計劃完成後，就永久性的擱置。而且最大的尷尬是，測試計劃似乎無人在乎，開發不在乎，連測試人員也不太在乎，測試中隨時可能會更改測試用例（有些步驟被證明是失效的，維護測試用例需要花費很大的精力），測試主管又不能根據測試計劃做出合理評估！google提出的ACC方法確實有見地，在測試中一直在追問產品的核心價值，一切活動溯源都是產品的定位與價值。這其實給我們現在的測試管理敲了個警鐘，要不忘初心！作為測試管理人員，是否能在10分鐘內準確說出產品的特質？如果不能，說明對產品不夠熟悉，還不能有效地測試它。一切都是為了提高效率，那就要時刻牢記最終的目標，這是測試的願景，否則，在浩瀚的測試海洋中，是會迷失方向的。

願在工作中，能盡快實踐書中的一些理念，對於測試，實在要有長遠的信心和行動才行！

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