作為乙個測試人員，這本書我讀的中文版，看了一部分，感覺有些受益，特此記錄！
本書中把軟體的測試角色分為三種：軟體開發工程師（swe）、軟體測試開發工程師（set）、測試工程師（te）。swe和set都是必須要編寫**的，差別是wet是開發工程師，側重點是開發功能、提高系統效能；set是測試開發工程師，側重點是測試**的質量。te與set歸屬於測試團隊，不同的是te把使用者放在第一位來思考問題，代表使用者利益，需要花費大量時間模擬大量使用者場景和編寫自動化指令碼，推動產品發布；而set的關注物件數開發人員，負責測試支援，能夠很熟悉的應用測試框架，非常近距離的觀察**的質量與風險。理想狀態是sew和wet兩個角色可以互相轉換需要開發功能的時候一起開發，需要測試的時候一起測試，但是現實中是既懂開發又懂測試的開發人員很少，既懂測試又懂開發的測試人員也很少，這就充分說明了wet的稀缺性。所以作為測試人員，無論處於哪個階段編寫指令碼、提高**編寫能力都是很必要的。
書中把產品發布版本也分為4個階段：金絲雀版本、開發版本、測試版本、beta或發布版本。
金絲雀版本：每日更新一版，安裝在自己的裝置上，內部測試，過濾掉不合適宜的版本，可能導致自己的裝置無法正常工作，需要極強的容忍度（成員涉及：開發人員、測試人員、管理人員）；
開發版本：開發人員日常使用的版本，每週發布乙個，滿足真實工作需求，如果不能夠能滿足日常真實工作需求，將會被打回金絲雀版本（成員涉及：開發人員）；
測試版本：通過了持續測試的版本，近乙個月的最穩定最信任的最佳版本，內部嘗鮮（dog food），若該版本有比較持續的優良表現，會作為beta測試的候選版本；
beta或發布版本：由非常穩定的測試版本演變而來，經過內部使用和通過所有質量考核的乙個版本，也是對外發布的第乙個版本。
書中還涉及測試人員在軟體執行週期的作用和參與測試的程度與時機。很多測試人員都以為測試越早進行越好，實則不然，在測試**設計初期強調測試是一件非常愚蠢的事情，乙個產品如果在概念上還沒有成型時就去關心質量，這是優先順序混亂的表現。當然，也不能太晚，不然質量「債」會拖慢產品發布。所以在軟體開發的各個階段，測試人員的測試重點都是不一樣的，這一點我們必須要明確。軟體測試的必要性在於產品的重要性，只有在軟體產品變得重要的時候，質量測試才會顯得重要，否則測試就會顯得徒勞。
完整性：文件是否有軟體背景知識？讀者是否能完整了解整個產品？文件結構是否完整？
正確性：語法、拼寫、標點符號等。
設計：設計流程、設計框架。
介面與協議：清晰定義、與期望一致。
測試：是否具有易測試性？預估需要做哪些工作？
在現在的軟體行業，其實軟體測試並不是只是測試人員的事情，在開發初期swe也會進行自測，set要比te更早的接觸測試，只有軟體在形成乙個產品雛形的時候te才會接觸產品測試，te更相當於乙個產品專家。管理、開發、測試，這些都是測試的主體，大家都有發現bug的權利和義務，只有相互學習、共同致力於產品質量才能增強軟體產品的健壯性，促使軟體的可持續發展。
《Google軟體測試之道》有感
如他們的招聘要求，有很多想法，並且有能力去實現。印象深刻的是，有一位為了實現自己的想法，週末的時間在咖啡館也在努力，並且最終取得了成功。以前的我覺得有些不可思議，為什麼要占用自己的休息時間來完成工作。這大概就是熱愛吧。我們好像總是淹沒在版本不停的交付中，沒有停下來思考，如何提高效率，並去實踐。創新，...
google測試之道讀書筆記一
測試之道中，講到測試計畫，提出了acc概念 attribute,component,capacity 看完這部分講解，受益良多。之前工作中寫的測試計畫基本上是走形式的產物，簡單羅列了測試模組 測試各階段時間安排，雖有明確的時間規劃，但其實形同廢紙，寫完基本丟到一邊。attribute 特性，待測產品...
單元測試之道有感
單元測試之道有感 這幾天，去看了一下老師發的 單元測之道 這本書，說實話，感觸很大，作者也舉了很多例子，告訴我們單元測試的重要性，單元測試它是服務於人的，它可以使你的工作更輕鬆，減少你在測試上花的時間和精力，那麼問題來了，什麼是單元測試，單元測試是開發者編寫的一小段 用於檢驗被測 的乙個很小的 很明...