第乙個融合開發角色和質量意識於一身的角色，即set。
1.工程師團隊的交付物就是即將要發布的**，**的組織形式、開發過程、維護是日常的工作重點。
2.google在平台方面有特定的目標，就是保持簡單且統一。開發工作機和生產環境的機器都保持統一的linux發行版本；一套集中控制的通用核心庫；一套統一的通用**、構建和測試基礎設施；每個核心語言只有乙個編譯器；與語言無關的通用打包規範；文化上對這些共享資源的維護表示尊重且有激勵。
3.如果乙個swe在某個產品的第三個版本研發時加入，這時這個產品已經有良好的文件、不錯的可測試性、執行著穩定的自動化測試、清晰的**提交流程，這些現象都在說明這個產品早期已有出色的set在為之工作。
4.專案的技術負責人和發起人要做的第一件事就是涉及文件。隨著文件的不斷完善，就需要不同專業型別的工程師角色投入到專案中去。許多技術負責人期望set在早期就能參與想，即便那時set資源還相對稀缺。
5.對於一些規模足夠大的專案來說，需要針對主要子系統也建立相應的設計文件，並在專案設計文件中增加子系統設計文件的鏈結。在初期版本完成後，裡面會囊括所有將來需要完成的工作清單，這也可以作為專案前進的路標。
6.作為工程師，set在團隊中有乙個巨大的優勢，就是擁有產品方面最廣闊的視野。乙個好的set會把非常專業的廣闊視野轉化為影響力，在開發人員所編寫的**上產生深遠的影響力。
7.set會對protocal buffer**做比較系統全面的審查，因為protocal buffer定義的介面與協議的**實現是要由set來完成的。沒錯，set是第乙個實現所有介面和協議的人。在系統真正搭建起來之前，整合測試的執行依賴這些介面實現。為了能夠盡早地開始做整合測試，set針對各個模組的依賴提供了mock或fake的實現。雖然功能模組**還沒有實現，整合測試的**就已經可以開始編寫了。在這個時候，如果整合測試**可以執行起來，那將會更有**。另外，在任何階段，整合測試總是依賴mock和fake.因為有了它們，一些依賴服務的期望錯誤場景和條件異常，會比較容易產生。
8.在google，set遵循以下方法：
（1）首先把容易出錯的介面做隔離，並針對它們建立mock和fake。
（2）接下來構建乙個輕量級的自動化框架，控制mock系統的建立和執行。
（3）set除了再這個計畫中涵蓋自動化（mock、fake和框架）之外，還要包括如何公開產品質量方面的資訊給所有關心的人。
9.檢驗乙個專案裡小型測試、中型測試和大型測試之間的比率是否健康，乙個好辦法是使用**覆蓋。測試**覆蓋率可以針對小型測試、中大型測試分別單獨產生報告。覆蓋率報告會針對不同的專案展示乙個可被接受的覆蓋率結果。如果中大型測試只有20%的**覆蓋率，而小型測試有近100%的覆蓋率，則說明這個專案缺乏端到端的功能驗證。如果結果數字反過來了，則說明這個專案很難去做公升級擴充套件和維護，由於小型測試較少，就需要大量的時間消耗在底層**除錯差錯上。
10.持續整合系統使用構建系統中的構建依賴規則。在這個規則中描述了**是如何編譯、資料檔案是怎樣整合在一起成為應用程式的，以及測試如何執行等資訊。這個構建規則中詳細定義了構建所需的輸入輸出。
良好的教練是測試認證計畫成功的乙個重要原因。如果你想要求乙個團隊去嘗試新的事物或者做默寫改進，給他們提供乙個聯絡人會更好一些，這個聯絡人**於更大的社群，並可以從他那裡得到幫助。
1.在你打造這些工具的時候，你面臨過的最難的技術挑戰是什麼？
對於我而言，我認為最艱難和最有趣的挑戰總是出現在設計階段。理解乙個問題領域，權衡不同的解決方案和他們的利弊，並從中選乙個最優的方案。實現階段一般按照選定的方案去做即可。這樣的選擇決定和功能實現一樣會貫穿專案的整個生命週期，決定專案的成敗。
2.對於世界上其他專注於測試工具方面的工程師，你有什麼一般性的建議嗎？
專注於你的使用者，理解他們的需求並解決他們的問題。不要忽視一些看不見的功能，如可用性和響應速度。工程師在解決他們問題方面有自己獨特的能力，要允許他們使用你無法預料的方式來使用你的工具。
《Google軟體測試之道》有感
如他們的招聘要求，有很多想法，並且有能力去實現。印象深刻的是，有一位為了實現自己的想法，週末的時間在咖啡館也在努力，並且最終取得了成功。以前的我覺得有些不可思議，為什麼要占用自己的休息時間來完成工作。這大概就是熱愛吧。我們好像總是淹沒在版本不停的交付中，沒有停下來思考，如何提高效率，並去實踐。創新，...
轉《Google軟體測試之道》
google軟體測試之道 一直聽朋友講起這本書，出於瑣事太多，一直沒機會拜讀，最近部門架構覺得我們it部門的技術太low，就給我們挑選了一些書籍，讓我們多看看。個人的一種學習習慣吧，就做了筆記，將自己的學習理解感觸寫下來。預計會分為五部分寫這些學習筆記，分別是google軟體測試基礎介紹 軟體測試開...
google測試之道讀書筆記一
測試之道中，講到測試計畫，提出了acc概念 attribute,component,capacity 看完這部分講解，受益良多。之前工作中寫的測試計畫基本上是走形式的產物，簡單羅列了測試模組 測試各階段時間安排，雖有明確的時間規劃，但其實形同廢紙，寫完基本丟到一邊。attribute 特性，待測產品...