《軟件測試經驗與教訓》作者：凱納 （美），翻譯 韓柯 2004年出版的。
倘若你沒有跳過很多坑，可能無法體會他寫的有多好，而當你跳過坑后，你就會想如果我早點知道這些就好了，本人就是處于這種情況，于是一直想本來收藏，隨時翻閱，可一直買不到。
共享地址：https://pan.baidu.com/s/1skSQGjF
貼下它的293條經驗，如有可能想對每條經驗說說自己的看法/或是自己跳過的坑。

第1章 測試員的角色

經驗1：測試員是項目的前燈
經驗2：測試員的使命決定要做的一切
經驗3：測試員為很多客戶服務
經驗4：測試員發(fā)現(xiàn)的信息會“打擾”客戶
經驗5：迅速找出重要程序問題
經驗6：跟著程序員走
經驗7：詢問一切，但不一定外露
經驗8：測試員關注失效，客戶才能關注成功
經驗9：不會發(fā)現(xiàn)所有程序問題
經驗10：當心“完備的”測試
經驗11：通過測試不能保證質量
經驗12：永遠別做看門人
經驗13：當心測試中的不關我事理論
經驗14：當心成為過程改進小組
經驗15：別指望任何人會理解測試，或理解測試員需要什么條件才能搞好測試

第2章 按測試員的方式思考

經驗16：測試運用的是認識論
經驗17：研究認識論有助于更好測試
經驗18：認知心理學是測試的基礎
經驗19：測試在測試員的頭腦中
經驗20：測試需要推斷，并不只是做輸出與預期結果的比較
經驗21：優(yōu)秀測試員會進行技術性、創(chuàng)造性、批判性和實用性地思考
經驗22：黑盒測試并不是基于無知的測試
經驗23：測試員不只是游客
經驗24：所有測試都試圖回答某些問題
經驗25：所有測試都基于模型
經驗26：直覺是不錯的開始，但又是糟糕的結束
經驗27：為了測試，必須探索
經驗28：探索要求大量思索
經驗29：使用誘導推斷邏輯發(fā)現(xiàn)推測
經驗30：使用猜想與反駁邏輯評估產品
經驗31：需求是重要人物所關心的質量或條件
經驗32：通過會議、推導和參照發(fā)現(xiàn)需求
經驗33：既要使用顯式規(guī)格說明，也要使用隱式規(guī)格說明
經驗34：“它沒有問題”真正的含義是，它看起來在一定程度上滿足部分需求
經驗35：最后，測試員所能得到的只是對產品的印象
經驗36：不要將試驗與測試混淆起來
經驗37：當測試復雜產品時：陷入與退出
經驗38：運用試探法快速產生測試思路
經驗39：測試員不能避免偏向，但是可以管理偏向
經驗40：如果自己知道自己不聰明，就更難被愚弄
經驗41：如果遺漏一個問題，檢查這種遺漏是意外還是策略的必然結果
經驗42：困惑是一種測試工具
經驗43：清新的眼光會發(fā)現(xiàn)失效
經驗44：測試員要避免遵循過程，除非過程先跟隨自己
經驗45：在創(chuàng)建測試過程時，避免“1287”
經驗46：測試過程的一個重要成果，是更好、更聰明的測試員
經驗47：除非重新發(fā)明測試，否則不能精通測試

第3章 測試手段

經驗48：關注測試員、覆蓋率、潛在問題、活動和評估的組合測試手段
經驗49：關注測試員的基于人員的測試手段
經驗50：關注測試內容的基于覆蓋率的測試手段
經驗51：關注測試原因（針對風險測試）的基于問題的測試手段
經驗52：關注測試方法的基于活動的測試手段
經驗53：關注測試是否通過的基于評估的測試手段
經驗54：根據(jù)自己的看法對測試手段分類

第4章 程序錯誤分析

經驗55：文如其人
經驗56：測試員的程序錯誤分析會推動改正所報告的錯誤
經驗57：使自己的錯誤報告成為一種有效的銷售工具
經驗58：錯誤報告代表的是測試員
經驗59：努力使錯誤報告有更高的價值
經驗60：產品的任何項目相關人員都應該能夠報告程序錯誤
經驗61：引用別人的錯誤報告時要小心
經驗62：將質量問題作為錯誤報告
經驗63：有些產品的項目相關人員不能報告程序錯誤，測試員就是他們的代理
經驗64：將受到影響的項目相關人員的注意力轉移到有爭議的程序錯誤上
經驗65：決不要利用程序錯誤跟蹤系統(tǒng)監(jiān)視程序員的表現(xiàn)
經驗66：決不要利用程序錯誤跟蹤系統(tǒng)監(jiān)視測試員的表現(xiàn)
經驗67：及時報告缺陷
經驗68：永遠不要假設明顯的程序錯誤已經寫入報告
經驗69：報告設計錯誤
經驗70：看似極端的缺陷是潛在的安全漏洞
經驗71：使冷僻用例不冷僻
經驗72：小缺陷也值得報告和修改
經驗73：時刻明確嚴重等級和優(yōu)先等級之間的差別
經驗74：失效是錯誤征兆，不是錯誤本身
經驗75：針對看起來很小的代碼錯誤執(zhí)行后續(xù)測試
經驗76：永遠都要報告不可重現(xiàn)的錯誤，這樣的錯誤可能是時間炸彈
經驗77：不可重現(xiàn)程序錯誤是可重現(xiàn)的
經驗78：注意錯誤報告的處理成本
經驗79：特別處理與工具或環(huán)境有關的程序錯誤
經驗80：在報告原型或早期個人版本的程序錯誤之前，要先征得同意
經驗81：重復錯誤報告是能夠自我解決的問題
經驗82：每個程序錯誤都需要單獨報告
經驗83：歸納行是錯誤報告中最重要的部分
經驗84：不要夸大程序錯誤
經驗85：清楚地報告問題，但不要試圖解決問題
經驗86：注意自己的語氣。所批評的每個人都會看到報告
經驗87：使自己的報告具有可讀性，即使像是勞累和暴躁的人
經驗88：提高報告撰寫技能
經驗89：如果合適，使用市場開發(fā)或技術支持數(shù)據(jù)
經驗90：相互評審錯誤報告
經驗91：與將閱讀錯誤報告的程序員見面
經驗92：最好的方法可能是向程序員演示所發(fā)現(xiàn)的程序錯誤
經驗93：當程序員說問題已經解決時，要檢查是否真的沒有問題了
經驗94：盡快檢驗程序錯誤修改
經驗95：如果修改出現(xiàn)問題，應與程序員溝通
經驗96：錯誤報告應該由測試員封存
經驗97：不要堅持要求修改所有程序錯誤，要量力而行
經驗98：不要讓延遲修改的程序錯誤消失
經驗99：測試惰性不能成為程序錯誤修改推遲的原因
經驗100：立即對程序錯誤延遲決定上訴
經驗101：如果決定據(jù)理力爭，就一定要贏！

第5章 測試自動化

經驗102：加快開發(fā)過程，而不是試圖在測試上省錢
經驗103：拓展測試領域，不要不斷重復相同的測試
經驗104：根據(jù)自己的背景選擇自動化測試策略
經驗105：不要強求100%的自動化
經驗106：測試工具并不是策略
經驗107：不要通過自動化使無序情況更嚴重
經驗108：不要把手工測試與自動化測試等同起來
經驗109：不要根據(jù)測試運行的頻率來估計測試的價值
經驗110：自動化的回歸測試發(fā)現(xiàn)少部分程序錯誤
經驗111：在自動化測試時考慮什么樣的程序錯誤沒有發(fā)現(xiàn)
經驗112：差的自動化測試的問題是沒有人注意
經驗113：捕獲回放失敗
經驗114：測試工具也有程序錯誤
經驗115：用戶界面變更
經驗116：根據(jù)兼容性、熟悉程度和服務選擇gui測試工具
經驗117：自動回歸測試消亡
經驗118：測試自動化是一種軟件開發(fā)過程
經驗119：測試自動化是一種重要投資
經驗120：測試自動化項目需要程序設計、測試和項目管理方面的技能
經驗121：通過試點驗證可行性
經驗122：請測試員和程序員參與測試自動化項目
經驗123：設計自動化測試以推動評審
經驗124：在自動化測試設計上不要吝嗇
經驗125：避免在測試腳本中使用復雜邏輯
經驗126：不要只是為了避免重復編碼而構建代碼庫
經驗127：數(shù)據(jù)驅動的自動化測試更便于運行大量測試變種
經驗128：關鍵詞驅動的自動化測試更便于非程序員創(chuàng)建測試
經驗129：利用自動化手段生成測試輸入
經驗130：將測試生成與測試執(zhí)行分開
經驗131：使用標準腳本語言
經驗132：利用編程接口自動化測試
經驗133：鼓勵開發(fā)單元測試包
經驗134：小心使用不理解測試的測試自動化設計人員
經驗135：避免使用不尊重測試的測試自動化設計人員
經驗136：可測試性往往是比測試自動化更好的投資
經驗137：可測試性是可視性和控制
經驗138：盡早啟動測試自動化
經驗139：為集中式測試自動化小組明確章程
經驗140：測試自動化要立即見效
經驗141：測試員擁有的測試工具會比所意識到的多

第6章 測試文檔

經驗142：為了有效地應用解決方案，需要清楚地理解問題
經驗143：不要使用測試文檔模板：除非可以脫離模板，否則模板就沒有用
經驗144：使用測試文檔模板：模板能夠促進一致的溝通
經驗145：使用ieee標準829作為測試文檔
經驗146：不要使用ieee標準829
經驗147：在決定要構建的產品之前先分析需求，這一點既適用于軟件也同樣適用于文檔
經驗148：為了分析測試文檔需求，可采用類似以下給出的問題清單進行調查
經驗149：用簡短的語句歸納出核心文檔需求

第7章 與程序員交互

經驗150：理解程序員怎樣思考
經驗151：獲得程序員的信任
經驗152：提供服務
經驗153：測試員的正直和能力需要尊重
經驗154：將關注點放在產品上，而不是人上
經驗155：程序員喜歡談論自己的工作。應該問他們問題
經驗156：程序員樂于通過可測試性提供幫助

第8章 管理測試項目

經驗157：建設一種服務文化
經驗158：不要嘗試建立一種控制文化
經驗159：要發(fā)揮耳目作用
經驗160：測試經理管理的是提供測試服務的子項目，不是開發(fā)項目
經驗161：所有項目都會演變。管理良好的項目能夠很好地演變
經驗162：總會有很晚的變更
經驗163：項目涉及功能、可靠性、時間和資金之間的折衷
經驗164：讓項目經理選擇項目生命周期
經驗165：瀑布生命周期把可靠性與時間對立起來
經驗166：進化生命周期把功能與時間對立起來
經驗167：愿意在開發(fā)初期將資源分配給項目團隊
經驗168：合同驅動的開發(fā)不同于尋求市場的開發(fā)
經驗169：要求可測試性功能
經驗170：協(xié)商版本開發(fā)進度計劃
經驗171：了解程序員在交付版本之前會做什么（以及不會做什么）
經驗172：為被測版本做好準備
經驗173：有時測試員應該拒絕測試某個版本
經驗174：使用冒煙測試檢驗版本
經驗175：有時正確的決策是停止測試，暫停改錯，并重新設計軟件
經驗176：根據(jù)實際使用的開發(fā)實踐調整自己的測試過程
經驗177：“項目文檔是一種有趣的幻想：有用，但永遠不足”
經驗178：測試員除非要用，否則不要索要
經驗179：充分利用其他信息源
經驗180：向項目經理指出配置管理問題
經驗181：程序員就像龍卷風
經驗182：好的測試計劃便于后期變更
經驗183：只要交付工作制品，就會出現(xiàn)測試機會
經驗184：做多少測試才算夠？這方面還沒有通用的計算公式
經驗185：“足夠測試”意味著“有足夠的信息可供客戶做出好決策”
經驗186：不要只為兩輪測試做出預算
經驗187：為一組任務確定進度計劃，估計每個任務所需的時間
經驗188：承擔工作的人應該告訴測試經理 完成該任務需要多長時間
經驗189：在測試員與開發(fā)人員之間沒有 正確的比例
經驗190：調整任務和不能勝任的人員
經驗191：輪換測試員的測試對象
經驗192：盡量成對測試
經驗193：為項目指派一位問題查找高手
經驗194：確定測試的階段計劃，特別是探索式測試的階段計劃
經驗195：分階段測試
經驗196：通過活動日志來反映對測試員工作的干擾
經驗197：定期狀態(tài)報告是一種強有力的工具
經驗198：再也沒有比副總裁掌握統(tǒng)計數(shù)據(jù)更危險的了
經驗199：要小心通過程序錯誤數(shù)度量項目進展
經驗200：使用的覆蓋率度量越獨立，了解的信息越多
經驗201：利用綜合計分牌產生考慮多個因素的狀態(tài)報告
經驗202：以下是周狀態(tài)報告的推薦結構
經驗203：項目進展表是另一種展示狀態(tài)的有用方法
經驗204：如果里程碑定義得很好，里程碑報告很有用
經驗205：不要簽署批準產品的發(fā)布
經驗206：不要簽字承認產品經過測試達到測試經理的滿意程度
經驗207：如果測試經理要編寫產品發(fā)布報告，應描述測試工作和結果，而不是自己對該產品的看法
經驗208：在產品最終發(fā)布報告中列出沒有排除的程序錯誤
經驗209：有用的發(fā)布報告應列出批評者可能指出的10個最糟糕的問題

第9章 測試小組的管理

經驗210：平庸是一種保守期望
經驗211：要把自己的員工當作執(zhí)行經理
經驗212：閱讀自己員工完成的錯誤報告
經驗213：像評估執(zhí)行經理那樣評估測試員
經驗214：如果測試經理確實想知道實際情況，可與員工一起測試
經驗215：不要指望別人能夠高效處理多個項目
經驗216：積累自己員工的專業(yè)領域知識
經驗217：積累自己員工相關技術方面的專門知識
經驗218：積極提高技能
經驗219：瀏覽技術支持日志
經驗220：幫助新測試員獲得成功
經驗221：讓新測試員對照軟件核對文檔
經驗222：通過正面測試使新測試員熟悉產品
經驗223：讓測試新手在編寫新錯誤報告之前，先改寫老的錯誤報告
經驗224：讓新測試員在測試新程序錯誤之前，先重新測試老程序錯誤
經驗225：不要派測試新手參加幾乎完成的項目
經驗226：員工的士氣是一種重要資產
經驗227：測試經理不要讓自己被濫用
經驗228：不要隨意讓員工加班
經驗229：不要讓員工被濫用
經驗230：創(chuàng)造培訓機會
經驗231：錄用決策是最重要的決策
經驗232：在招募期間利用承包人爭取回旋余地
經驗233：謹慎把其他小組拒絕的人吸收到測試小組中
經驗234：對測試小組需要承擔的任務，以及完成這些任務所需的技能做出規(guī)劃
經驗235：測試團隊成員要有不同背景
經驗236：錄用其他渠道的應聘者
經驗237：根據(jù)大家意見決定錄用
經驗238：錄用熱愛自己工作的人
經驗239：錄用正直的人
經驗240：在面談時，讓應聘者展示期望有的技能
經驗241：在面談時，請應聘者通過非正式能力測驗展示其在工作中能夠運用的技能
經驗242：在錄用時，要求應聘者提供工作樣本
經驗243：一旦拿定主意就迅速錄用
經驗244：要將錄用承諾形成文字，并遵守諾言

第10章 軟件測試職業(yè)發(fā)展

經驗245：確定職業(yè)發(fā)展方向并不懈努力
經驗246：測試員的收入可以超過程序員的收入
經驗247：可大膽改變職業(yè)發(fā)展方向并追求其他目標
經驗248：不管選擇走哪條路，都要積極追求
經驗249：超出軟件測試拓展自己的職業(yè)發(fā)展方向
經驗250：超出公司拓展自己的職業(yè)發(fā)展方向
經驗251：參加會議是為了討論
經驗252：很多公司的問題并不比本公司的問題少
經驗253：如果不喜歡自己的公司，就再找一份不同的工作
經驗254：為尋找新工作做好準備
經驗255：積累并維護希望加入的公司的名單
經驗256：積累材料
經驗257：把簡歷當作推銷工具
經驗258：找一位內部推薦人
經驗259：搜集薪金數(shù)據(jù)
經驗260：如果是根據(jù)招聘廣告應聘，應根據(jù)廣告要求調整自己的申請
經驗261：充分利用面談機會
經驗262：了解準備應聘的招聘公司
經驗263：在應聘時詢問問題
經驗264：就自己的工作崗位進行談判
經驗265：留意人力資源部
經驗266：學習perl語言
經驗267：學習java或c++
經驗268：下載測試工具的演示版并試運行
經驗269：提高自己的寫作技巧
經驗270：提高自己的公眾講話技巧
經驗271：考慮通過認證
經驗272：不要幻想只需兩個星期就能夠得到黑帶柔道段位
經驗273：有關軟件工程師認可制度的警告

第11章 計劃測試策略

經驗274：有關測試策略要問的三個基本問題是“為什么擔心？”、“誰關心？”、“測試多少？”
經驗275：有很多種可能的測試策略
經驗276：實際測試計劃是指導測試過程的一套想法
經驗277：所設計的測試計劃要符合自己的具體情況
經驗278：利用測試計劃描述在測試策略、保障條件和工作產品上所做的選擇
經驗279：不要讓保障條件和工作產品影響實現(xiàn)測試策略
經驗280：如何利用測試用例
經驗281：測試策略要比測試用例重要
經驗282：測試策略要解釋測試
經驗283：運用多樣化的折衷手段
經驗284：充分利用強有力測試策略的原始材料
經驗285：項目的初始測試策略總是錯的
經驗286：在項目的每個階段，可自問“我現(xiàn)在可以測試什么，能夠怎樣測試”？
經驗287：根據(jù)產品的成熟度確定測試策略
經驗288：利用測試分級簡化測試復雜性的討論
經驗289：測試灰盒
經驗290：在重新利用測試材料時，不要迷信以前的東西
經驗291：兩個測試員測試同樣的內容也許并不是重復勞動
經驗292：設計測試策略時既要考慮產品風險，也要考慮產品要素
經驗293：把測試周期看作是測試過程的韻律