《軟體測試經驗與教訓》評注
經驗11： 測試不能保證質量，非常贊同這個說話，考慮兩個因素：（1）你給的時間和成本是多少？如果是0，提什麼保證質量？（2）質量形成與構建者，也受其他人制約，例如三聚氰胺奶粉生產商不知道自己加了嘛？
經驗13 ：測試確實應該盡其所能，橫向上覆蓋產品的設計，開發，發布，售後等過程，縱向覆蓋與其他模組的互動；但是需要分析下為什麼測試者往往有「不關我事」理論，無非涉及到管理的層面，例如：（1）薪資等不平等；（2）承接模組過多，失去興趣和信心；
經驗14 ：過程改進很傷感情，測試人員在測試前期不應該成為吹毛求疵的挑剔者，如果如此很可能出現兩種情況：（1）開發的**還沒有完成階段，但明知有很多bug之地，這個時候qa不斷提出bug,勢必影響開發心情。尊重開發的開發過程很重要；（2）開發的設計或許有其他思路，qa不斷強調並說服開發者上司採用其他思路，如果不是非常有把握，就不要自作聰明強烈地說服開發者上司，這樣最後往往被證明不定合理；
經驗15：不要指望別人理解測試，需要不斷向別人解釋，這點在其他領域也適用，很多時候事實並不是就是事實，而是觀察者眼中的「事實」，因此推銷是門學問，「指鹿為馬」未嘗不可做到。
經驗30：任何量的測試都不能「確定」乙個產品的質量，證明失效比證明正確容易的多。
經驗31：客戶需求多變，或許自己也不明白真正要什麼，需求分析即是輔助、辨別需求。
經驗32： 隱式規格說明很重要，很多測試依據都是這些「潛規則」，顯式說明文件不可能也沒有必要面面俱到。
經驗33：測試員中的「它沒有問題」，與他人眼中不同。
經驗34：對質量印象只能限定在已知侷限的前提下；
經驗35：配置、執行、觀察、評估是行為層面的用例；
經驗39：防止思維定勢，提倡多人思考互補，不用去偏執的帶有目的去證明缺陷，而是平常心的客觀測試。
經驗43：應該提倡結對測試，互補思考，同時要攻破「難」點，越複雜之地越容易出問題，且多次出現頻率更高。
經驗45: 測試用例過於細節話，有可能限制測試者的想象力和創造性，之所以同乙個case跑出不同的結果往往也和測試用例不過於細節化有關，但我認為不細節化一定程度上是好事情。
經驗46：現在很多人還是以bug數量、測試效果來衡量測試人員的水平，這條經驗告訴人們要看測試人員如何思考；同時我們應該加強測試人才的培養與重視，不要僅僅為的是表面化的一些工作；
經驗90：同行評審是個培訓、提高的好方式；
經驗103： 重試不同、多樣測試比反反覆覆執行自動化指令碼有效的多；
經驗108： 專業培訓的測試員的頭腦是最好的測試工具；
經驗114： 如果不是非常優秀的開發人員，且具有良好的測試思維，就不要開發測試工具，否則一旦推廣害人害己，因為測試工具問題往往比普通產品更容易出現；
經驗117：自動回歸測試有時候不能將改進和錯誤區分，特別是介面和輸出格式變動；
經驗122：評審自動化測試**比用**測試自動化測試**好；因為後者容易陷入乙個無限的邏輯；
經驗130： 建議測試資料與測試執行分離；
經驗132： 自動化是否繞過介面直接操作api取決於到底是介面穩定還是api穩定；盡量依賴穩定的東西；
經驗133： 單元整合測試值得執行；
經驗143： 流程、模板都是用來規範人的行為的，只有不斷了解、改善才有意義，如果乙個流程、模板不允許任何應需改變則無意義；
經驗146： 形式化工作越多，往往本質工作預留的時間越少，思維也限制的更固定；
經驗148： 自己的測試文件是產品還是工具？這個問題很好；過於頻繁的細節不要寫到文件裡，否則以後更新繁瑣；
經驗154： 不要利用程式設計師的弱點或透露的缺陷直接上報，類似於打小報告，以後的合作會減弱很多；
經驗157： 測試是一種服務，不是控制，無法控制最終產品的質量；
經驗168： 任務完成時間評估，應由掌握最佳知識的人進行，或者由估計錯誤需要負責的人執行，而不是根據測試經理的主觀期望。
經驗173： 可以拒絕某個版本的測試：1）新的版本很快就有，這個版本的測試結果會被忽略；2）重要的功能點沒有新增；3）基本功能點不工作，導致大部分測試無法進行；
經驗182： 提前應對可能風險，將潛在的風險預處理劃分到專案的各個階段而不是後期應急處理；
經驗183：測試思考中總體認為產品不是一天做出的，而是慢慢堆積出的，只要有東西提交，就有可測之地，同時越早越好，只是需要抱著同情、謹慎心態等不同心態而已；
經驗186：考慮二輪以上測試；
經驗189： 測試：開發人員比例這種問題如果不結合具體專案及要求就不要提！
經驗197：測試小組的真正力量是溝通，而非監管；
經驗199： bug數隨進度推進而不斷降低不能完全說明質量已經符合要求，因為後期可能從事非發現缺陷的活動：如展示產品、回歸測試等；簡單說：當看到bug數連續幾天較少時，不要完全覺得是產品質量變好，而可能是最近沒有從事太多新的測試；
經驗211： 要給予員工自己的思考、執行時空自由，尊重他們的測試思路，而不是模板化；
經驗213： 非常贊同：指明了如何評價一名測試人員的工作，但是很多公司做不到，因為很辛苦。或許他們更傾向於用bug數來衡量，這樣簡單明瞭，雖然不正確。
經驗215： 贊同，所以假設必須分配多個任務給同乙個員工，不要糾錯式的責備某個時刻某個任務沒有做好;
經驗216： 測試經理在測試產品領域的視角要開闊；
經驗220： 多了解員工的期待與現實感覺，不僅僅對於新員工需要這麼做，留住老員工也是必須的，否則會出現離職都不知道真實原因的情況。關心員工、與員工做朋友非常重要。
經驗225： 不要在專案末尾新增新手，有可能起到相反作用，這點在專案管理上也提到；同時不要為了以後可能有的培訓或者職位更換理由，浪費太多時間在文件活動；在開發程式時也一樣，不要為了以後可能還用不到的需求做無限擴大需求活動，否則永無盡頭且不實際。
經驗226：經理應該 客觀評價事物，不要不懂裝懂，否則容易誤導員工，有失公正；
經驗227： 不要使自己陷入導致工作失敗（如工作量過大）或者沒有希望的工作上，最終只會使自己的情緒受到傷害。管理者總是覺得應該給能者更多的工作，而員工則希望更多的休息，如果給予信任的員工更多的工作，最終可能導致其失敗並有損情緒，實際上就是摧殘而已。
經驗228： 測試經理不應該是傳話筒，否則有可能是成為不同決策者的執行機器，而應該是中間溝通協調層，保護其員工不受不同決策者的不同觀點的影響，但是這種保護應該是正確的觀點指導下。
經驗235：多樣化是專案團隊建議的良藥；
經驗238：跳槽時不要顯示對原來公司的不滿或洩露原公司的資訊；
經驗239：速度測驗高分只能反映是腦力兔子，或者有可能是訓練、練習所致；而低分者可能是腦力烏龜，慢工出細活。
經驗245： 從職業發展角度來說，掌握測試技術本身比掌握專業業務邏輯更好，當然這裡的專業業務是銀行系統等的話，另當別論。
經驗250： 面試貫徹2個逐條：逐條解釋簡歷中的每條：逐條解釋招聘要求的每個條目為什麼自己符合，不符合，但是可以很快學習的地方；
經驗252： 和其他公司測試員建立聯絡，有助於以後的職業發展。
經驗253： 如有可能，多休息也是一種緩和跳槽的想法；
經驗278： 測試計畫經常漏掉如何保障測試策略的執行與工作產品；
經驗280： 討論風險和覆蓋率，研究用例內容比單純統計測試用例數量更有意義；
經驗284： 策略決策可利用資源可簡單歸納為：人、事、物；
經驗285： v字軟體測試模型強調軟體測試策略早先制定，實際上隨著測試的深入，策略會因風險識別的準確度提高等因素而做出調整，因為v不是非常好的專案組織方法。
經驗286： 不要將測試侷限在某個階段，抓住一切機會測試可以測試並值得測試的事物；
經驗297：專案初期：同情的測試；開發只想知道已經完成的功能的測試結果，不是想知道自己還沒有做的功能的測試結果；整個測試按專案發展分為：同情地測試-》積極地測試-》多樣地測試=》謹慎地測試；
經驗292： 當遇到測試問題過多的模組（可能需要其他設計替換），應提醒開發，不要再痛打落水狗；要測試模糊不清的地方（介面之地、新的技術方案、需求模糊之地）；測試員負責任務之間的縫隙處（交叉部分）容易出問題；
總結：（1） 關注如何思考；
（2） 關注本質，少看數量；
（3） 關注多樣化；
（4） 強調結對測試；
（5） 測所有可測之地，越早介入越好；
（6） 不同階段，擁有不同心態；
軟體測試 經驗與教訓
1，明確測試員的使命！找出錯誤？為產品達到某標準？幫助程式設計師改進？幫助使產品與需求吻合？對產品總體質量的評估？盡快完成測試的工作？2，我們測試面對的主要客戶是哪幾類？面向程式設計師？面向客戶？專案經理？看門人 明確責任，避免 不關我事 3，盡早迅速測試。4，當心 完備的 測試，明確給定時間內，做...
軟體測試經驗與教訓
1.人工測試的重要性仍是第一位的，儘管現在自動化測試如火如荼的發展著，但很多重大缺陷依然需要通過人工測試的方式才能發現，因為測試策略才是根本，人工測試在這裡充分體現出了其靈活多樣的特性，尤其是有意識的進行探索式測試 2.乙個經驗豐富，能力較強的只會人工測試的測試工程師的價值肯定大於乙個一般的自動化測...
《軟體測試經驗與教訓》之一 測試員的角色
1.測試需要找到專案或產品的資訊。後期有關軟體或產品的關鍵關鍵決策都是根據這些資訊進行的。2.測試員的使命 經常重新考慮自己的使命，保證自己的計畫或使命不會偏重某一方面而忽略另一方面。3.測試是一種服務角色。服務意味著有客戶。測試員的工作是否成功，主要看其是否很好的滿足了客戶的要求和最佳利益。4.測...