測試工程師的職責重點在於評估對使用者的影響以及軟體產品整體目標上的風險。
1.為了成為一等公民，te必須首先是工程師的一部分。google的te綜合了開發者仰慕的技術能力和以使用者為中心檢查軟體質量而對開發者產生一定制約的能力。
1.在研發的早期階段，功能還在不斷變化，最終功能列表和範疇還沒有確定，te通常沒有太多的工作可做。
3.te的根本使命是保護使用者和業務的利益，使之不受到糟糕的設計、令人困惑的使用者體驗、功能bug、安全和隱私等問題的困擾。
4.理想情況下，測試計畫應當在專案執行中發揮核心作用，應當在軟體的整個生命週期中持續有效：隨著**庫的更新而更新，時刻代表最新的產品功能，而不是停留在專案開始階段時的樣子。
5.關於風險：
6.測試用例的生命週期
7.bug的生命週期
8.測試用例進入維護模式前需要考慮：
1.你如何參與乙個新專案呢？你首先會提出哪些問題、做哪些事情？
對於乙個新專案，我首先要站在使用者的角度了解這個產品。有可能的話，我會作為乙個使用者，以自己的賬戶和個人資料去使用產品。我努力使自己經歷完整的使用者體驗。一旦有自己的真實資料在裡面，你對乙個產品的期待會徹底改變。在具備了使用者心態之後，我會做下面的一些事情。
2.身為te，在你的工作中如何代表使用者呢？
我把自己變成使用者，就這麼簡。我認為，除非能以某種方式將自己置於使用者的視角，否則就不可能真正有效地對乙個應用進行測試。這就是為什麼測試遠比檢查乙個版本是否可用要複雜得多的原因；它包括應用的直觀性、行業標準等各方面的反饋。換句話說，測試要清楚地指出當做之事。
3.對於你的工作，開發是怎麼看待的？如果他們不認可測試的價值，那你又該怎麼辦？
開發經常會低估我的工作，知道我們在一起工作了幾個月之後，他們才會改變想法。我在完成了上述工作之後，將被邀請整個團隊開會，介紹一下我設定的測試流程。這種面對面的交流真的很重要，我可以利用這個機會讓他們看到我是多麼認真嚴肅地看待他們的應用。結果是一大堆的問題和意見交換。我得到了好的反饋，而他們確信自己有了得力幫手。在我介紹了整個流程，以及我所做的變化、更新和改進之後，所有對測試價值的懷疑通常就會煙消雲散了。
4.你的工作如何影響乙個產品的發布決定呢？
我會從對使用者產生影響的角度來說明為什麼乙個功能不能上線或整個發布都不能上線。
5.關於te這個角色，你最喜歡的是什麼？
1.關於web、flash以及資料驅動的web伺服器，你對其他測試人員有哪些建議？
不管是測試框架還是測試用例都以簡單為要，隨著專案的開展再迭代的涉及。不要試圖事先解決所有問題。要敢於扔掉過時的東西。如果測試或者自動化過於難以維護，不如放棄它並試著去實現更有韌性、更好的東西。密切關注一段時間維護和排錯的成本。遵守70-20-10法則：小型的用來驗證單個類或功能的單元測試佔70%，中型的用來驗證乙個或多個應用模組之間整合的測試佔20%，大型的高階別的用來驗證完整應用的測試（一般稱為系統測試和端到端測試）佔10%。
《Google軟體測試之道》有感
如他們的招聘要求，有很多想法，並且有能力去實現。印象深刻的是，有一位為了實現自己的想法，週末的時間在咖啡館也在努力，並且最終取得了成功。以前的我覺得有些不可思議，為什麼要占用自己的休息時間來完成工作。這大概就是熱愛吧。我們好像總是淹沒在版本不停的交付中，沒有停下來思考，如何提高效率，並去實踐。創新，...
轉《Google軟體測試之道》
google軟體測試之道 一直聽朋友講起這本書，出於瑣事太多，一直沒機會拜讀，最近部門架構覺得我們it部門的技術太low，就給我們挑選了一些書籍，讓我們多看看。個人的一種學習習慣吧，就做了筆記，將自己的學習理解感觸寫下來。預計會分為五部分寫這些學習筆記，分別是google軟體測試基礎介紹 軟體測試開...
google測試之道讀書筆記一
測試之道中，講到測試計畫，提出了acc概念 attribute,component,capacity 看完這部分講解，受益良多。之前工作中寫的測試計畫基本上是走形式的產物，簡單羅列了測試模組 測試各階段時間安排，雖有明確的時間規劃，但其實形同廢紙，寫完基本丟到一邊。attribute 特性，待測產品...