本書匯總了293條來自軟體測試界頂尖專家的經驗與建議，闡述了如何做好測試工作、如何管理測試，以及如何澄清有關軟體測試的常見誤解，讀者可直接將這些建議用於自己的測試項目工作中。
基本介紹
- 書名：軟體測試經驗與教訓
- 作者：凱納
- 譯者：韓柯
- ISBN：9787111129752
- 出版社：機械工業出版社
基本信息,內容簡介,作者簡介,目錄,
基本信息
作 者：（美）凱納 等 著 韓柯 等 譯 叢 書 名：軟體工程技術叢書·測試系列 出 版 社：機械工業出版社ISBN：9787111129752 出版時間：2004-01-01 版 次：1 頁 數：234 裝 幀：平裝 開 本：16開 所屬分類：圖書 > 計算機與網際網路 > 軟體工程及軟體方法學
內容簡介
本書匯總了293條來自軟體測試界頂尖專家的經驗與建議，闡述了如何做好測試工作、如何管理測試，以及如何澄清有關軟體測試的常見誤解，讀者可直接將這些建議用於自己的測試項目工作中。這些經驗中的每一條都是與軟體測試有關的一個觀點，觀點後面是針對運用該測試經驗的方法、時機和原因的解釋或例子。
本書還提供了有關如何將本書提供的經驗有選擇性地運用到讀者實際項目環境中的建議，在所有關鍵問題上所積累的經驗，以及基於多年的測試經驗總結出的有用實踐和問題評估方法。
優秀的軟體測試團隊不是天生的，而是造就的，是通過大量艱苦工作和有效溝通造就的。在這個過程中，有很多陷阱，這些陷阱會使精心制訂的計畫出現偏差，使項目不能按進度完成。
本書的三位作者具有多年的測試經驗，知道成功的測試都需要什麼。在這本革命性的新書中，他們匯總了293條測試經驗建議，闡述了如何做好測試工作，如何管理測試，以及如何澄清有關軟體測試的常見誤解。讀者可直接將這些經驗用於自己的測試工作中。這些經驗中的每一條都是與軟體測試有關的一個觀點，後面是對運用這條經驗的方法、時機和原因的解釋或例子。
為了滿足不同層次的軟體測試員、開發人員和管理人員的需要，本書還提供以下內容：
◆ 根據世界頂級軟體測試專家多年的測試經驗總結出的有用實踐和問題評估方法。
◆ 在所有關鍵問題上積累的經驗，包括測試設計、測試自動化、測試管理、測試策略和錯誤報告。
◆ 如何將本書提供的經驗有選擇性地運用到實際項目環境中的建議。
作者簡介
CemcKaner是美國佛羅里達技術學院的教授，同時為軟體開發界提供技術和管理等方面的諮詢工作。他是世界級的測試技術權威，《TestingcComputercSoftware》(中文版即將由機械工業出版社出版)和《Bad Software》這兩本書的第一作者。
James Bach是Satisfice公司創始人和首席顧問，這是一家軟體測試和質量保證公司。他具有在頂級矽谷公司(例如蘋果和Borland公司)從事軟體開發的經驗，這使他在“足夠好的”質量、基於風險的測試、探索測試和其他對技能和判斷能力要求很高的技術等方面擁有豐富經驗。他還是軟體測試實驗室的首席科學家。
目錄
譯者序
序
前言
致謝
第1章 測試員的角色 1
經驗1：測試員是項目的前燈 1
經驗2：測試員的使命決定要做
的一切 2
經驗3：測試員為很多客戶服務 3
經驗4：測試員發現的信息會
“打擾”客戶 4
經驗5：迅速找出重要程式問題 4
經驗6：跟著程式設計師走 5
經驗7：詢問一切，但不一定外露 5
經驗8：測試員關註失效，客戶才能
關注成功 5
經驗9：不會發現所有程式問題 6
經驗10：當心“完備的”測試 6
經驗11：通過測試不能保證質量 7
經驗12：永遠別做看門人 7
.經驗13：當心測試中的不關我事理論 8
經驗14：當心成為過程改進小組 8
經驗15：別指望任何人會理解測試，
或理解測試員需要什麼條件
才能搞好測試 9
第2章 按測試員的方式思考 11
經驗16：測試運用的是認識論 11
經驗17：研究認識論有助於更好測試 12
經驗18：認知心理學是測試的基礎 12
經驗19：測試在測試員的頭腦中 13
經驗20：測試需要推斷，並不只是
做輸出與預期結果的比較 14
經驗21：優秀測試員會進行技術性、創造
性、批判性和實用性地思考 14
經驗22：黑盒測試並不是基於
無知的測試 15
經驗23：測試員不只是遊客 15
經驗24：所有測試都試圖回答某些問題 16
經驗25：所有測試都基於模型 16
經驗26：直覺是不錯的開始，但又是
糟糕的結束 16
經驗27：為了測試，必須探索 17
經驗28：探索要求大量思索 17
經驗29：使用誘導推斷邏輯發現推測 18
經驗30：使用猜想與反駁邏輯評估產品 19
經驗31：需求是重要人物所關心的質量
或條件 19
經驗32：通過會議、推導和參照發現
需求 20
經驗33：既要使用顯式規格說明，也要
使用隱式規格說明 20
經驗34：“它沒有問題”真正的含義是，
它看起來在一定程度上滿足
部分需求 21
經驗35：最後，測試員所能得到的只是
對產品的印象 22
經驗36：不要將試驗與測試混淆起來 22
經驗37：當測試複雜產品時：陷入
與退出 22
經驗38：運用試探法快速產生測試思路 23
經驗39：測試員不能避免偏向，但是可以
管理偏向 23
經驗40：如果自己知道自己不聰明，就更
難被愚弄 24
經驗41：如果遺漏一個問題，檢查這種遺漏
是意外還是策略的必然結果 25
經驗42：困惑是一種測試工具 25
經驗43：清新的眼光會發現失效 26
經驗44：測試員要避免遵循過程，
除非過程先跟隨自己 26
經驗45：在創建測試過程時，避免
“1287” 26
經驗46：測試過程的一個重要成果，
是更好、更聰明的測試員 27
經驗47：除非重新發明測試，否則
不能精通測試 27
第3章 測試手段 29
經驗48：關注測試員、覆蓋率、潛在問題、
活動和評估的組合測試手段 30
經驗49：關注測試員的基於人員的
測試手段 31
經驗50：關注測試內容的基於覆蓋率的
測試手段 32
經驗51：關注測試原因（針對風險測試）
的基於問題的測試手段 36
經驗52：關注測試方法的基於活動的
測試手段 37
經驗53：關注測試是否通過的基於評估
的測試手段 38
經驗54：根據自己的看法對測試
手段分類 39
第4章 程式錯誤分析 57
經驗55：文如其人 57
經驗56：測試員的程式錯誤分析會推動
改正所報告的錯誤 57
經驗57：使自己的錯誤報告成為一種
有效的銷售工具 58
經驗58：錯誤報告代表的是測試員 59
經驗59：努力使錯誤報告有更高的
價值 59
經驗60：產品的任何項目相關人員都
應該能夠報告程式錯誤 60
經驗61：引用別人的錯誤報告時要小心 60
經驗62：將質量問題作為錯誤報告 60
經驗63：有些產品的項目相關人員不能
報告程式錯誤，測試員就是
他們的代理 61
經驗64：將受到影響的項目相關人員的
注意力轉移到有爭議的
程式錯誤上 61
經驗65：決不要利用程式錯誤跟蹤系統
監視程式設計師的表現 61
經驗66：決不要利用程式錯誤跟蹤系統
監視測試員的表現 62
經驗67：及時報告缺陷 62
經驗68：永遠不要假設明顯的程式錯誤
已經寫入報告 62
經驗69：報告設計錯誤 63
經驗70：看似極端的缺陷是潛在的
安全漏洞 64
經驗71：使冷僻用例不冷僻 64
經驗72：小缺陷也值得報告和修改 65
經驗73：時刻明確嚴重等級和優先等級
之間的差別 66
經驗74：失效是錯誤徵兆，不是錯誤本身 66
經驗75：針對看起來很小的代碼錯誤
執行後續測試 67
經驗76：永遠都要報告不可重現的錯誤，
這樣的錯誤可能是時間炸彈 68
經驗77：不可重現程式錯誤是可重現的 68
經驗78：注意錯誤報告的處理成本 69
經驗79：特別處理與工具或環境有關的
程式錯誤 70
經驗80：在報告原型或早期個人版本的
程式錯誤之前，要先徵得同意 71
經驗81：重複錯誤報告是能夠自我解決
的問題 71
經驗82：每個程式錯誤都需要單獨
的報告 72
經驗83：歸納行是錯誤報告中最重要
的部分 72
經驗84：不要誇大程式錯誤 73
經驗85：清楚地報告問題，但不要試圖
解決問題 73
經驗86：注意自己的語氣。所批評的每個人
都會看到報告 74
經驗87：使自己的報告具有可讀性，即使
對象是勞累和暴躁的人 75
經驗88：提高報告撰寫技能 75
經驗89：如果合適，使用市場開發或技術
支持數據 76
經驗90：相互評審錯誤報告 76
經驗91：與將閱讀錯誤報告的
程式設計師見面 76
經驗92：最好的方法可能是向程式設計師演示
所發現的程式錯誤 77
經驗93：當程式設計師說問題已經解決時，
要檢查是否真的沒有問題了 77
經驗94：儘快檢驗程式錯誤修改 77
經驗95：如果修改出現問題，應與
程式設計師溝通 78
經驗96：錯誤報告應該由測試員封存 78
經驗97：不要堅持要求修改所有程式
錯誤，要量力而行 78
經驗98：不要讓延遲修改的程式
錯誤消失 79
經驗99：測試惰性不能成為程式錯誤
修改推遲的原因 79
經驗100：立即對程式錯誤延遲
決定抗訴 80
經驗101：如果決定據理力爭，就一定
要贏！ 80
第5章 測試自動化 81
經驗102：加快開發過程，而不是試圖在
測試上省錢 82
經驗103：拓展測試領域，不要不斷重複
相同的測試 83
經驗104：根據自己的背景選擇自動化
測試策略 84
經驗105：不要強求100%的自動化 84
經驗106：測試工具並不是策略 85
經驗107：不要通過自動化使無序情況
更嚴重 85
經驗108：不要把手工測試與自動化測試
等同起來 86
經驗109：不要根據測試運行的頻率來估
計測試的價值 87
經驗110：自動化的回歸測試發現少部分
程式錯誤 87
經驗111：在自動化測試時考慮什麼樣的
程式錯誤沒有發現 88
經驗112：差的自動化測試的問題是沒有
人注意 88
經驗113：捕獲回放失敗 90
經驗114：測試工具也有程式錯誤 91
經驗115：用戶界面變更 92
經驗116：根據兼容性、熟悉程度和服務
選擇gui測試工具 92
經驗117：自動回歸測試消亡 93
經驗118：測試自動化是一種軟體
開發過程 94
經驗119：測試自動化是一種重要投資 95
經驗120：測試自動化項目需要程式設計、
測試和項目管理方面的技能 95
經驗121：通過試點驗證可行性 96
經驗122：請測試員和程式設計師參與測試
自動化項目 96
經驗123：設計自動化測試以推動評審 97
經驗124：在自動化測試設計上不要
吝嗇 97
經驗125：避免在測試腳本中使用
複雜邏輯 98
經驗126：不要只是為了避免重複編碼而
構建代碼庫 98
經驗127：數據驅動的自動化測試更便於
運行大量測試變種 98
經驗128：關鍵字驅動的自動化測試更便於
非程式設計師創建測試 99
經驗129：利用自動化手段生成測試輸入 100
經驗130：將測試生成與測試執行分開 101
經驗131：使用標準腳本語言 101
經驗132：利用編程接口自動化測試 102
經驗133：鼓勵開發單元測試包 104
經驗134：小心使用不理解測試的測試
自動化設計人員 104
經驗135：避免使用不尊重測試的測試
自動化設計人員 105
經驗136：可測試性往往是比測試自動化
更好的投資 106
經驗137：可測試性是可視性和控制 106
經驗138：儘早啟動測試自動化 107
經驗139：為集中式測試自動化小組
明確章程 108
經驗140：測試自動化要立即見效 108
經驗141：測試員擁有的測試工具會比所
意識到的多 109
第6章 測試文檔 111
經驗142：為了有效地套用解決方案，
需要清楚地理解問題 112
經驗143：不要使用測試文檔模板：除非
可以脫離模板，否則模板
就沒有用 112
經驗144：使用測試文檔模板：模板能夠
促進一致的溝通 113
經驗145：使用ieee標準829作為測試
文檔 113
經驗146：不要使用ieee標準829 114
經驗147：在決定要構建的產品之前先分析
需求，這一點既適用於軟體也同
樣適用於文檔 116
經驗148：為了分析測試文檔需求，可采
用類似以下給出的問題清單
進行調查 117
經驗149：用簡短的語句歸納出核心
文檔需求 120
第7章 與程式設計師互動 121
經驗150：理解程式設計師怎樣思考 121
經驗151：獲得程式設計師的信任 122
經驗152：提供服務 123
經驗153：測試員的正直和能力需要尊重 123
經驗154：將關注點放在產品上，
而不是人上 124
經驗155：程式設計師喜歡談論自己的工作。
應該問他們問題 125
經驗156：程式設計師樂於通過可測試性
提供幫助 126
第8章 管理測試項目 129
經驗157：建設一種服務文化 129
經驗158：不要嘗試建立一種控制文化 130
經驗159：要發揮耳目作用 130
經驗160：測試經理管理的是提供測試服務
的子項目，不是開發項目 131
經驗161：所有項目都會演變。管理良好的
項目能夠很好地演變 131
經驗162：總會有很晚的變更 132
經驗163：項目涉及功能、可靠性、時間和
資金之間的折衷 132
經驗164：讓項目經理選擇項目生命周期 133
經驗165：瀑布生命周期把可靠性與時間
對立起來 134
經驗166：進化生命周期把功能與時間
對立起來 135
經驗167：願意在開發初期將資源分配
給項目團隊 135
經驗168：契約驅動的開發不同於尋求
市場的開發 136
經驗169：要求可測試性功能 137
經驗170：協商版本開發進度計畫 137
經驗171：了解程式設計師在交付版本之前會
做什麼（以及不會做什麼） 138
經驗172：為被測版本做好準備 138
經驗173：有時測試員應該拒絕測試
某個版本 138
經驗174：使用冒煙測試檢驗版本 139
經驗175：有時正確的決策是停止測試，
暫停改錯，並重新設計軟體 139
經驗176：根據實際使用的開發實踐調整
自己的測試過程 140
經驗177：“項目文檔是一種有趣的幻想：
有用，但永遠不足” 141
經驗178：測試員除非要用，否則
不要索要 141
經驗179：充分利用其他信息源 141
經驗180：向項目經理指出配置管理問題 142
經驗181：程式設計師就像龍捲風 143
經驗182：好的測試計畫便於後期變更 144
經驗183：只要交付工作製品，就會
出現測試機會 145
經驗184：做多少測試才算夠？這方面還
沒有通用的計算公式 145
經驗185：“足夠測試”意味著“有足夠的
信息可供客戶做出好決策” 145
經驗186：不要只為兩輪測試做出預算 146
經驗187：為一組任務確定進度計畫，估計
每個任務所需的時間 146
經驗188：承擔工作的人應該告訴測試經理
完成該任務需要多長時間 147
經驗189：在測試員與開發人員之間沒有
正確的比例 148
經驗190：調整任務和不能勝任的人員 148
經驗191：輪換測試員的測試對象 149
經驗192：儘量成對測試 149
經驗193：為項目指派一位問題查找高手 150
經驗194：確定測試的階段計畫，特別是
探索式測試的階段計畫 150
經驗195：分階段測試 151
經驗196：通過活動日誌來反映對測試員
工作的干擾 151
經驗197：定期狀態報告是一種強
有力的工具 152
經驗198：再也沒有比副總裁掌握統計
數據更危險的了 153
經驗199：要小心通過程式錯誤數度量
項目進展 154
經驗200：使用的覆蓋率度量越獨立，
了解的信息越多 154
經驗201：利用綜合計分牌產生考慮
多個因素的狀態報告 155
經驗202：以下是周狀態報告的推薦
結構 156
經驗203：項目進展表是另一種展示
狀態的有用方法 157
經驗204：如果里程碑定義得很好，
里程碑報告很有用 158
經驗205：不要簽署批准產品的發布 159
經驗206：不要簽字承認產品經過測試
達到測試經理的滿意程度 159
經驗207：如果測試經理要編寫產品發布
報告，應描述測試工作和結果，
而不是自己對該產品的看法 159
經驗208：在產品最終發布報告中列出
沒有排除的程式錯誤 159
經驗209：有用的發布報告應列出批評者
可能指出的10個最糟糕的問題 160
第9章 測試小組的管理 161
經驗210：平庸是一種保守期望 161
經驗211：要把自己的員工當作執行經理 162
經驗212：閱讀自己員工完成的錯誤報告 163
經驗213：像評估執行經理那樣評估
測試員 163
經驗214：如果測試經理確實想知道實際
情況，可與員工一起測試 164
經驗215：不要指望別人能夠高效處理
多個項目 165
經驗216：積累自己員工的專業領域知識 165
經驗217：積累自己員工相關技術方面的
專門知識 166
經驗218：積極提高技能 166
經驗219：瀏覽技術支持日誌 166
經驗220：幫助新測試員獲得成功 167
經驗221：讓新測試員對照軟體核對文檔 167
經驗222：通過正面測試使新測試員
熟悉產品 167
經驗223：讓測試新手在編寫新錯誤報告
之前，先改寫老的錯誤報告 168
經驗224：讓新測試員在測試新程式錯誤
之前，先重新測試老程式錯誤 168
經驗225：不要派測試新手參加幾乎完成
的項目 169
經驗226：員工的士氣是一種重要資產 169
經驗227：測試經理不要讓自己被濫用 170
經驗228：不要隨意讓員工加班 171
經驗229：不要讓員工被濫用 172
經驗230：創造培訓機會 172
經驗231：錄用決策是最重要的決策 173
經驗232：在招募期間利用承包人爭
取迴旋餘地 173
經驗233：謹慎把其他小組拒絕的人
吸收到測試小組中 173
經驗234：對測試小組需要承擔的任務，
以及完成這些任務所需的技能
做出規劃 174
經驗235：測試團隊成員要有不同背景 174
經驗236：錄用其他渠道的應聘者 175
經驗237：根據大家意見決定錄用 175
經驗238：錄用熱愛自己工作的人 175
經驗239：錄用正直的人 176
經驗240：在面談時，讓應聘者展示期望
有的技能 176
經驗241：在面談時，請應聘者通過非正
式能力測驗展示其在工作中
能夠運用的技能 176
經驗242：在錄用時，要求應聘者提供
工作樣本 177
經驗243：一旦拿定主意就迅速錄用 177
經驗244：要將錄用承諾形成文字，
並遵守諾言 177
第10章 軟體測試職業發展 179
經驗245：確定職業發展方向並不懈努力 179
經驗246：測試員的收入可以超過程式設計師
的收入 181
經驗247：可大膽改變職業發展方向
並追求其他目標 181
經驗248：不管選擇走哪條路，都要
積極追求 182
經驗249：超出軟體測試拓展自己的
職業發展方向 182
經驗250：超出公司拓展自己的
職業發展方向 183
經驗251：參加會議是為了討論 183
經驗252：很多公司的問題並不比本公司
的問題少 184
經驗253：如果不喜歡自己的公司，就再
找一份不同的工作 184
經驗254：為尋找新工作做好準備 184
經驗255：積累並維護希望加入的公司
的名單 185
經驗256：積累材料 185
經驗257：把簡歷當作推銷工具 186
經驗258：找一位內部推薦人 187
經驗259：蒐集薪金數據 187
經驗260：如果是根據招聘廣告應聘，
應根據廣告要求調整自己
的申請 187
經驗261：充分利用面談機會 187
經驗262：了解準備應聘的招聘公司 188
經驗263：在應聘時詢問問題 188
經驗264：就自己的工作崗位進行談判 190
經驗265：留意人力資源部 191
經驗266：學習perl語言 191
經驗267：學習java或c++ 192
經驗268：下載測試工具的演示版
並試運行 192
經驗269：提高自己的寫作技巧 192
經驗270：提高自己的公眾講話技巧 193
經驗271：考慮通過認證 193
經驗272：不要幻想只需兩個星期就能夠
得到黑帶柔道段位 194
經驗273：有關軟體工程師認可制度的
警告 194
第11章 計畫測試策略 199
經驗274：有關測試策略要問的三個基本問題
是“為什麼擔心？”、“誰關心？”、
“測試多少？” 199
經驗275：有很多種可能的測試策略 199
經驗276：實際測試計畫是指導測試過程
的一套想法 200
經驗277：所設計的測試計畫要符合
自己的具體情況 201
經驗278：利用測試計畫描述在測試策略、
保障條件和工作產品上所做的
選擇 202
經驗279：不要讓保障條件和工作產品
影響實現測試策略 202
經驗280：如何利用測試用例 202
經驗281：測試策略要比測試用例重要 203
經驗282：測試策略要解釋測試 203
經驗283：運用多樣化的折衷手段 204
經驗284：充分利用強有力測試策略的
原始材料 204
經驗285：項目的初始測試策略總是錯的 205
經驗286：在項目的每個階段，可自問
“我現在可以測試什麼，能夠
怎樣測試”？ 205
經驗287：根據產品的成熟度確定
測試策略 206
經驗288：利用測試分級簡化測試
複雜性的討論 207
經驗289：測試灰盒 208
經驗290：在重新利用測試材料時，
不要迷信以前的東西 208
經驗291：兩個測試員測試同樣的內容
也許並不是重複勞動 209
經驗292：設計測試策略時既要考慮產品
風險，也要考慮產品要素 209
經驗293：把測試周期看作是測試
過程的韻律 210
附錄：軟體測試的語境驅動方法 221
參考文獻 225
序
前言
致謝
第1章 測試員的角色 1
經驗1：測試員是項目的前燈 1
經驗2：測試員的使命決定要做
的一切 2
經驗3：測試員為很多客戶服務 3
經驗4：測試員發現的信息會
“打擾”客戶 4
經驗5：迅速找出重要程式問題 4
經驗6：跟著程式設計師走 5
經驗7：詢問一切，但不一定外露 5
經驗8：測試員關註失效，客戶才能
關注成功 5
經驗9：不會發現所有程式問題 6
經驗10：當心“完備的”測試 6
經驗11：通過測試不能保證質量 7
經驗12：永遠別做看門人 7
.經驗13：當心測試中的不關我事理論 8
經驗14：當心成為過程改進小組 8
經驗15：別指望任何人會理解測試，
或理解測試員需要什麼條件
才能搞好測試 9
第2章 按測試員的方式思考 11
經驗16：測試運用的是認識論 11
經驗17：研究認識論有助於更好測試 12
經驗18：認知心理學是測試的基礎 12
經驗19：測試在測試員的頭腦中 13
經驗20：測試需要推斷，並不只是
做輸出與預期結果的比較 14
經驗21：優秀測試員會進行技術性、創造
性、批判性和實用性地思考 14
經驗22：黑盒測試並不是基於
無知的測試 15
經驗23：測試員不只是遊客 15
經驗24：所有測試都試圖回答某些問題 16
經驗25：所有測試都基於模型 16
經驗26：直覺是不錯的開始，但又是
糟糕的結束 16
經驗27：為了測試，必須探索 17
經驗28：探索要求大量思索 17
經驗29：使用誘導推斷邏輯發現推測 18
經驗30：使用猜想與反駁邏輯評估產品 19
經驗31：需求是重要人物所關心的質量
或條件 19
經驗32：通過會議、推導和參照發現
需求 20
經驗33：既要使用顯式規格說明，也要
使用隱式規格說明 20
經驗34：“它沒有問題”真正的含義是，
它看起來在一定程度上滿足
部分需求 21
經驗35：最後，測試員所能得到的只是
對產品的印象 22
經驗36：不要將試驗與測試混淆起來 22
經驗37：當測試複雜產品時：陷入
與退出 22
經驗38：運用試探法快速產生測試思路 23
經驗39：測試員不能避免偏向，但是可以
管理偏向 23
經驗40：如果自己知道自己不聰明，就更
難被愚弄 24
經驗41：如果遺漏一個問題，檢查這種遺漏
是意外還是策略的必然結果 25
經驗42：困惑是一種測試工具 25
經驗43：清新的眼光會發現失效 26
經驗44：測試員要避免遵循過程，
除非過程先跟隨自己 26
經驗45：在創建測試過程時，避免
“1287” 26
經驗46：測試過程的一個重要成果，
是更好、更聰明的測試員 27
經驗47：除非重新發明測試，否則
不能精通測試 27
第3章 測試手段 29
經驗48：關注測試員、覆蓋率、潛在問題、
活動和評估的組合測試手段 30
經驗49：關注測試員的基於人員的
測試手段 31
經驗50：關注測試內容的基於覆蓋率的
測試手段 32
經驗51：關注測試原因（針對風險測試）
的基於問題的測試手段 36
經驗52：關注測試方法的基於活動的
測試手段 37
經驗53：關注測試是否通過的基於評估
的測試手段 38
經驗54：根據自己的看法對測試
手段分類 39
第4章 程式錯誤分析 57
經驗55：文如其人 57
經驗56：測試員的程式錯誤分析會推動
改正所報告的錯誤 57
經驗57：使自己的錯誤報告成為一種
有效的銷售工具 58
經驗58：錯誤報告代表的是測試員 59
經驗59：努力使錯誤報告有更高的
價值 59
經驗60：產品的任何項目相關人員都
應該能夠報告程式錯誤 60
經驗61：引用別人的錯誤報告時要小心 60
經驗62：將質量問題作為錯誤報告 60
經驗63：有些產品的項目相關人員不能
報告程式錯誤，測試員就是
他們的代理 61
經驗64：將受到影響的項目相關人員的
注意力轉移到有爭議的
程式錯誤上 61
經驗65：決不要利用程式錯誤跟蹤系統
監視程式設計師的表現 61
經驗66：決不要利用程式錯誤跟蹤系統
監視測試員的表現 62
經驗67：及時報告缺陷 62
經驗68：永遠不要假設明顯的程式錯誤
已經寫入報告 62
經驗69：報告設計錯誤 63
經驗70：看似極端的缺陷是潛在的
安全漏洞 64
經驗71：使冷僻用例不冷僻 64
經驗72：小缺陷也值得報告和修改 65
經驗73：時刻明確嚴重等級和優先等級
之間的差別 66
經驗74：失效是錯誤徵兆，不是錯誤本身 66
經驗75：針對看起來很小的代碼錯誤
執行後續測試 67
經驗76：永遠都要報告不可重現的錯誤，
這樣的錯誤可能是時間炸彈 68
經驗77：不可重現程式錯誤是可重現的 68
經驗78：注意錯誤報告的處理成本 69
經驗79：特別處理與工具或環境有關的
程式錯誤 70
經驗80：在報告原型或早期個人版本的
程式錯誤之前，要先徵得同意 71
經驗81：重複錯誤報告是能夠自我解決
的問題 71
經驗82：每個程式錯誤都需要單獨
的報告 72
經驗83：歸納行是錯誤報告中最重要
的部分 72
經驗84：不要誇大程式錯誤 73
經驗85：清楚地報告問題，但不要試圖
解決問題 73
經驗86：注意自己的語氣。所批評的每個人
都會看到報告 74
經驗87：使自己的報告具有可讀性，即使
對象是勞累和暴躁的人 75
經驗88：提高報告撰寫技能 75
經驗89：如果合適，使用市場開發或技術
支持數據 76
經驗90：相互評審錯誤報告 76
經驗91：與將閱讀錯誤報告的
程式設計師見面 76
經驗92：最好的方法可能是向程式設計師演示
所發現的程式錯誤 77
經驗93：當程式設計師說問題已經解決時，
要檢查是否真的沒有問題了 77
經驗94：儘快檢驗程式錯誤修改 77
經驗95：如果修改出現問題，應與
程式設計師溝通 78
經驗96：錯誤報告應該由測試員封存 78
經驗97：不要堅持要求修改所有程式
錯誤，要量力而行 78
經驗98：不要讓延遲修改的程式
錯誤消失 79
經驗99：測試惰性不能成為程式錯誤
修改推遲的原因 79
經驗100：立即對程式錯誤延遲
決定抗訴 80
經驗101：如果決定據理力爭，就一定
要贏！ 80
第5章 測試自動化 81
經驗102：加快開發過程，而不是試圖在
測試上省錢 82
經驗103：拓展測試領域，不要不斷重複
相同的測試 83
經驗104：根據自己的背景選擇自動化
測試策略 84
經驗105：不要強求100%的自動化 84
經驗106：測試工具並不是策略 85
經驗107：不要通過自動化使無序情況
更嚴重 85
經驗108：不要把手工測試與自動化測試
等同起來 86
經驗109：不要根據測試運行的頻率來估
計測試的價值 87
經驗110：自動化的回歸測試發現少部分
程式錯誤 87
經驗111：在自動化測試時考慮什麼樣的
程式錯誤沒有發現 88
經驗112：差的自動化測試的問題是沒有
人注意 88
經驗113：捕獲回放失敗 90
經驗114：測試工具也有程式錯誤 91
經驗115：用戶界面變更 92
經驗116：根據兼容性、熟悉程度和服務
選擇gui測試工具 92
經驗117：自動回歸測試消亡 93
經驗118：測試自動化是一種軟體
開發過程 94
經驗119：測試自動化是一種重要投資 95
經驗120：測試自動化項目需要程式設計、
測試和項目管理方面的技能 95
經驗121：通過試點驗證可行性 96
經驗122：請測試員和程式設計師參與測試
自動化項目 96
經驗123：設計自動化測試以推動評審 97
經驗124：在自動化測試設計上不要
吝嗇 97
經驗125：避免在測試腳本中使用
複雜邏輯 98
經驗126：不要只是為了避免重複編碼而
構建代碼庫 98
經驗127：數據驅動的自動化測試更便於
運行大量測試變種 98
經驗128：關鍵字驅動的自動化測試更便於
非程式設計師創建測試 99
經驗129：利用自動化手段生成測試輸入 100
經驗130：將測試生成與測試執行分開 101
經驗131：使用標準腳本語言 101
經驗132：利用編程接口自動化測試 102
經驗133：鼓勵開發單元測試包 104
經驗134：小心使用不理解測試的測試
自動化設計人員 104
經驗135：避免使用不尊重測試的測試
自動化設計人員 105
經驗136：可測試性往往是比測試自動化
更好的投資 106
經驗137：可測試性是可視性和控制 106
經驗138：儘早啟動測試自動化 107
經驗139：為集中式測試自動化小組
明確章程 108
經驗140：測試自動化要立即見效 108
經驗141：測試員擁有的測試工具會比所
意識到的多 109
第6章 測試文檔 111
經驗142：為了有效地套用解決方案，
需要清楚地理解問題 112
經驗143：不要使用測試文檔模板：除非
可以脫離模板，否則模板
就沒有用 112
經驗144：使用測試文檔模板：模板能夠
促進一致的溝通 113
經驗145：使用ieee標準829作為測試
文檔 113
經驗146：不要使用ieee標準829 114
經驗147：在決定要構建的產品之前先分析
需求，這一點既適用於軟體也同
樣適用於文檔 116
經驗148：為了分析測試文檔需求，可采
用類似以下給出的問題清單
進行調查 117
經驗149：用簡短的語句歸納出核心
文檔需求 120
第7章 與程式設計師互動 121
經驗150：理解程式設計師怎樣思考 121
經驗151：獲得程式設計師的信任 122
經驗152：提供服務 123
經驗153：測試員的正直和能力需要尊重 123
經驗154：將關注點放在產品上，
而不是人上 124
經驗155：程式設計師喜歡談論自己的工作。
應該問他們問題 125
經驗156：程式設計師樂於通過可測試性
提供幫助 126
第8章 管理測試項目 129
經驗157：建設一種服務文化 129
經驗158：不要嘗試建立一種控制文化 130
經驗159：要發揮耳目作用 130
經驗160：測試經理管理的是提供測試服務
的子項目，不是開發項目 131
經驗161：所有項目都會演變。管理良好的
項目能夠很好地演變 131
經驗162：總會有很晚的變更 132
經驗163：項目涉及功能、可靠性、時間和
資金之間的折衷 132
經驗164：讓項目經理選擇項目生命周期 133
經驗165：瀑布生命周期把可靠性與時間
對立起來 134
經驗166：進化生命周期把功能與時間
對立起來 135
經驗167：願意在開發初期將資源分配
給項目團隊 135
經驗168：契約驅動的開發不同於尋求
市場的開發 136
經驗169：要求可測試性功能 137
經驗170：協商版本開發進度計畫 137
經驗171：了解程式設計師在交付版本之前會
做什麼（以及不會做什麼） 138
經驗172：為被測版本做好準備 138
經驗173：有時測試員應該拒絕測試
某個版本 138
經驗174：使用冒煙測試檢驗版本 139
經驗175：有時正確的決策是停止測試，
暫停改錯，並重新設計軟體 139
經驗176：根據實際使用的開發實踐調整
自己的測試過程 140
經驗177：“項目文檔是一種有趣的幻想：
有用，但永遠不足” 141
經驗178：測試員除非要用，否則
不要索要 141
經驗179：充分利用其他信息源 141
經驗180：向項目經理指出配置管理問題 142
經驗181：程式設計師就像龍捲風 143
經驗182：好的測試計畫便於後期變更 144
經驗183：只要交付工作製品，就會
出現測試機會 145
經驗184：做多少測試才算夠？這方面還
沒有通用的計算公式 145
經驗185：“足夠測試”意味著“有足夠的
信息可供客戶做出好決策” 145
經驗186：不要只為兩輪測試做出預算 146
經驗187：為一組任務確定進度計畫，估計
每個任務所需的時間 146
經驗188：承擔工作的人應該告訴測試經理
完成該任務需要多長時間 147
經驗189：在測試員與開發人員之間沒有
正確的比例 148
經驗190：調整任務和不能勝任的人員 148
經驗191：輪換測試員的測試對象 149
經驗192：儘量成對測試 149
經驗193：為項目指派一位問題查找高手 150
經驗194：確定測試的階段計畫，特別是
探索式測試的階段計畫 150
經驗195：分階段測試 151
經驗196：通過活動日誌來反映對測試員
工作的干擾 151
經驗197：定期狀態報告是一種強
有力的工具 152
經驗198：再也沒有比副總裁掌握統計
數據更危險的了 153
經驗199：要小心通過程式錯誤數度量
項目進展 154
經驗200：使用的覆蓋率度量越獨立，
了解的信息越多 154
經驗201：利用綜合計分牌產生考慮
多個因素的狀態報告 155
經驗202：以下是周狀態報告的推薦
結構 156
經驗203：項目進展表是另一種展示
狀態的有用方法 157
經驗204：如果里程碑定義得很好，
里程碑報告很有用 158
經驗205：不要簽署批准產品的發布 159
經驗206：不要簽字承認產品經過測試
達到測試經理的滿意程度 159
經驗207：如果測試經理要編寫產品發布
報告，應描述測試工作和結果，
而不是自己對該產品的看法 159
經驗208：在產品最終發布報告中列出
沒有排除的程式錯誤 159
經驗209：有用的發布報告應列出批評者
可能指出的10個最糟糕的問題 160
第9章 測試小組的管理 161
經驗210：平庸是一種保守期望 161
經驗211：要把自己的員工當作執行經理 162
經驗212：閱讀自己員工完成的錯誤報告 163
經驗213：像評估執行經理那樣評估
測試員 163
經驗214：如果測試經理確實想知道實際
情況，可與員工一起測試 164
經驗215：不要指望別人能夠高效處理
多個項目 165
經驗216：積累自己員工的專業領域知識 165
經驗217：積累自己員工相關技術方面的
專門知識 166
經驗218：積極提高技能 166
經驗219：瀏覽技術支持日誌 166
經驗220：幫助新測試員獲得成功 167
經驗221：讓新測試員對照軟體核對文檔 167
經驗222：通過正面測試使新測試員
熟悉產品 167
經驗223：讓測試新手在編寫新錯誤報告
之前，先改寫老的錯誤報告 168
經驗224：讓新測試員在測試新程式錯誤
之前，先重新測試老程式錯誤 168
經驗225：不要派測試新手參加幾乎完成
的項目 169
經驗226：員工的士氣是一種重要資產 169
經驗227：測試經理不要讓自己被濫用 170
經驗228：不要隨意讓員工加班 171
經驗229：不要讓員工被濫用 172
經驗230：創造培訓機會 172
經驗231：錄用決策是最重要的決策 173
經驗232：在招募期間利用承包人爭
取迴旋餘地 173
經驗233：謹慎把其他小組拒絕的人
吸收到測試小組中 173
經驗234：對測試小組需要承擔的任務，
以及完成這些任務所需的技能
做出規劃 174
經驗235：測試團隊成員要有不同背景 174
經驗236：錄用其他渠道的應聘者 175
經驗237：根據大家意見決定錄用 175
經驗238：錄用熱愛自己工作的人 175
經驗239：錄用正直的人 176
經驗240：在面談時，讓應聘者展示期望
有的技能 176
經驗241：在面談時，請應聘者通過非正
式能力測驗展示其在工作中
能夠運用的技能 176
經驗242：在錄用時，要求應聘者提供
工作樣本 177
經驗243：一旦拿定主意就迅速錄用 177
經驗244：要將錄用承諾形成文字，
並遵守諾言 177
第10章 軟體測試職業發展 179
經驗245：確定職業發展方向並不懈努力 179
經驗246：測試員的收入可以超過程式設計師
的收入 181
經驗247：可大膽改變職業發展方向
並追求其他目標 181
經驗248：不管選擇走哪條路，都要
積極追求 182
經驗249：超出軟體測試拓展自己的
職業發展方向 182
經驗250：超出公司拓展自己的
職業發展方向 183
經驗251：參加會議是為了討論 183
經驗252：很多公司的問題並不比本公司
的問題少 184
經驗253：如果不喜歡自己的公司，就再
找一份不同的工作 184
經驗254：為尋找新工作做好準備 184
經驗255：積累並維護希望加入的公司
的名單 185
經驗256：積累材料 185
經驗257：把簡歷當作推銷工具 186
經驗258：找一位內部推薦人 187
經驗259：蒐集薪金數據 187
經驗260：如果是根據招聘廣告應聘，
應根據廣告要求調整自己
的申請 187
經驗261：充分利用面談機會 187
經驗262：了解準備應聘的招聘公司 188
經驗263：在應聘時詢問問題 188
經驗264：就自己的工作崗位進行談判 190
經驗265：留意人力資源部 191
經驗266：學習perl語言 191
經驗267：學習java或c++ 192
經驗268：下載測試工具的演示版
並試運行 192
經驗269：提高自己的寫作技巧 192
經驗270：提高自己的公眾講話技巧 193
經驗271：考慮通過認證 193
經驗272：不要幻想只需兩個星期就能夠
得到黑帶柔道段位 194
經驗273：有關軟體工程師認可制度的
警告 194
第11章 計畫測試策略 199
經驗274：有關測試策略要問的三個基本問題
是“為什麼擔心？”、“誰關心？”、
“測試多少？” 199
經驗275：有很多種可能的測試策略 199
經驗276：實際測試計畫是指導測試過程
的一套想法 200
經驗277：所設計的測試計畫要符合
自己的具體情況 201
經驗278：利用測試計畫描述在測試策略、
保障條件和工作產品上所做的
選擇 202
經驗279：不要讓保障條件和工作產品
影響實現測試策略 202
經驗280：如何利用測試用例 202
經驗281：測試策略要比測試用例重要 203
經驗282：測試策略要解釋測試 203
經驗283：運用多樣化的折衷手段 204
經驗284：充分利用強有力測試策略的
原始材料 204
經驗285：項目的初始測試策略總是錯的 205
經驗286：在項目的每個階段，可自問
“我現在可以測試什麼，能夠
怎樣測試”？ 205
經驗287：根據產品的成熟度確定
測試策略 206
經驗288：利用測試分級簡化測試
複雜性的討論 207
經驗289：測試灰盒 208
經驗290：在重新利用測試材料時，
不要迷信以前的東西 208
經驗291：兩個測試員測試同樣的內容
也許並不是重複勞動 209
經驗292：設計測試策略時既要考慮產品
風險，也要考慮產品要素 209
經驗293：把測試周期看作是測試
過程的韻律 210
附錄：軟體測試的語境驅動方法 221
參考文獻 225
