軟件測試經驗與教訓

譯者序
序
前言
致謝
第1章 測試員的角色 1
經驗1：測試員是項目的前燈 1
經驗2：測試員的使命決定要做
的一切 2
經驗3：測試員為很多客戶服務 3
經驗4：測試員發(fā)現的信息會
“打擾”客戶 4
經驗5：迅速找出重要程序問題 4
經驗6：跟著程序員走 5
經驗7：詢問一切，但不一定外露 5
經驗8：測試員關注失效，客戶才能
關注成功 5
經驗9：不會發(fā)現所有程序問題 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：優(yōu)秀測試員會進行技術性、創(chuàng)造
性、批判性和實用性地思考 14
經驗22：黑盒測試并不是基于
無知的測試 15
經驗23：測試員不只是游客 15
經驗24：所有測試都試圖回答某些問題 16
經驗25：所有測試都基于模型 16
經驗26：直覺是不錯的開始，但又是
糟糕的結束 16
經驗27：為了測試，必須探索 17
經驗28：探索要求大量思索 17
經驗29：使用誘導推斷邏輯發(fā)現推測 18
經驗30：使用猜想與反駁邏輯評估產品 19
經驗31：需求是重要人物所關心的質量
或條件 19
經驗32：通過會議、推導和參照發(fā)現
需求 20
經驗33：既要使用顯式規(guī)格說明，也要
使用隱式規(guī)格說明 20
經驗34：“它沒有問題”真正的含義是，
它看起來在一定程度上滿足
部分需求 21
經驗35：最后，測試員所能得到的只是
對產品的印象 22
經驗36：不要將試驗與測試混淆起來 22
經驗37：當測試復雜產品時：陷入
與退出 22
經驗38：運用試探法快速產生測試思路 23
經驗39：測試員不能避免偏向，但是可以
管理偏向 23
經驗40：如果自己知道自己不聰明，就更
難被愚弄 24
經驗41：如果遺漏一個問題，檢查這種遺漏
是意外還是策略的必然結果 25
經驗42：困惑是一種測試工具 25
經驗43：清新的眼光會發(fā)現失效 26
經驗44：測試員要避免遵循過程，
除非過程先跟隨自己 26
經驗45：在創(chuàng)建測試過程時，避免
“1287” 26
經驗46：測試過程的一個重要成果，
是更好、更聰明的測試員 27
經驗47：除非重新發(fā)明測試，否則
不能精通測試 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：決不要利用程序錯誤跟蹤系統(tǒng)
監(jiān)視程序員的表現 61
經驗66：決不要利用程序錯誤跟蹤系統(tǒng)
監(jiān)視測試員的表現 62
經驗67：及時報告缺陷 62
經驗68：永遠不要假設明顯的程序錯誤
已經寫入報告 62
經驗69：報告設計錯誤 63
經驗70：看似極端的缺陷是潛在的
安全漏洞 64
經驗71：使冷僻用例不冷僻 64
經驗72：小缺陷也值得報告和修改 65
經驗73：時刻明確嚴重等級和優(yōu)先等級
之間的差別 66
經驗74：失效是錯誤征兆，不是錯誤本身 66
經驗75：針對看起來很小的代碼錯誤
執(zhí)行后續(xù)測試 67
經驗76：永遠都要報告不可重現的錯誤，
這樣的錯誤可能是時間炸彈 68
經驗77：不可重現程序錯誤是可重現的 68
經驗78：注意錯誤報告的處理成本 69
經驗79：特別處理與工具或環(huán)境有關的
程序錯誤 70
經驗80：在報告原型或早期個人版本的
程序錯誤之前，要先征得同意 71
經驗81：重復錯誤報告是能夠自我解決
的問題 71
經驗82：每個程序錯誤都需要單獨
的報告 72
經驗83：歸納行是錯誤報告中最重要
的部分 72
經驗84：不要夸大程序錯誤 73
經驗85：清楚地報告問題，但不要試圖
解決問題 73
經驗86：注意自己的語氣。所批評的每個人
都會看到報告 74
經驗87：使自己的報告具有可讀性，即使
對象是勞累和暴躁的人 75
經驗88：提高報告撰寫技能 75
經驗89：如果合適，使用市場開發(fā)或技術
支持數據 76
經驗90：相互評審錯誤報告 76
經驗91：與將閱讀錯誤報告的
程序員見面 76
經驗92：最好的方法可能是向程序員演示
所發(fā)現的程序錯誤 77
經驗93：當程序員說問題已經解決時，
要檢查是否真的沒有問題了 77
經驗94：盡快檢驗程序錯誤修改 77
經驗95：如果修改出現問題，應與
程序員溝通 78
經驗96：錯誤報告應該由測試員封存 78
經驗97：不要堅持要求修改所有程序
錯誤，要量力而行 78
經驗98：不要讓延遲修改的程序
錯誤消失 79
經驗99：測試惰性不能成為程序錯誤
修改推遲的原因 79
經驗100：立即對程序錯誤延遲
決定上訴 80
經驗101：如果決定據理力爭，就一定
要贏！ 80
第5章 測試自動化 81
經驗102：加快開發(fā)過程，而不是試圖在
測試上省錢 82
經驗103：拓展測試領域，不要不斷重復
相同的測試 83
經驗104：根據自己的背景選擇自動化
測試策略 84
經驗105：不要強求100%的自動化 84
經驗106：測試工具并不是策略 85
經驗107：不要通過自動化使無序情況
更嚴重 85
經驗108：不要把手工測試與自動化測試
等同起來 86
經驗109：不要根據測試運行的頻率來估
計測試的價值 87
經驗110：自動化的回歸測試發(fā)現少部分
程序錯誤 87
經驗111：在自動化測試時考慮什么樣的
程序錯誤沒有發(fā)現 88
經驗112：差的自動化測試的問題是沒有
人注意 88
經驗113：捕獲回放失敗 90
經驗114：測試工具也有程序錯誤 91
經驗115：用戶界面變更 92
經驗116：根據兼容性、熟悉程度和服務
選擇GUI測試工具 92
經驗117：自動回歸測試消亡 93
經驗118：測試自動化是一種軟件
開發(fā)過程 94
經驗119：測試自動化是一種重要投資 95
經驗120：測試自動化項目需要程序設計、
測試和項目管理方面的技能 95
經驗121：通過試點驗證可行性 96
經驗122：請測試員和程序員參與測試
自動化項目 96
經驗123：設計自動化測試以推動評審 97
經驗124：在自動化測試設計上不要
吝嗇 97
經驗125：避免在測試腳本中使用
復雜邏輯 98
經驗126：不要只是為了避免重復編碼而
構建代碼庫 98
經驗127：數據驅動的自動化測試更便于
運行大量測試變種 98
經驗128：關鍵詞驅動的自動化測試更便于
非程序員創(chuàng)建測試 99
經驗129：利用自動化手段生成測試輸入 100
經驗130：將測試生成與測試執(zhí)行分開 101
經驗131：使用標準腳本語言 101
經驗132：利用編程接口自動化測試 102
經驗133：鼓勵開發(fā)單元測試包 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：要發(fā)揮耳目作用 130
經驗160：測試經理管理的是提供測試服務
的子項目，不是開發(fā)項目 131
經驗161：所有項目都會演變。管理良好的
項目能夠很好地演變 131
經驗162：總會有很晚的變更 132
經驗163：項目涉及功能、可靠性、時間和
資金之間的折衷 132
經驗164：讓項目經理選擇項目生命周期 133
經驗165：瀑布生命周期把可靠性與時間
對立起來 134
經驗166：進化生命周期把功能與時間
對立起來 135
經驗167：愿意在開發(fā)初期將資源分配
給項目團隊 135
經驗168：合同驅動的開發(fā)不同于尋求
市場的開發(fā) 136
經驗169：要求可測試性功能 137
經驗170：協(xié)商版本開發(fā)進度計劃 137
經驗171：了解程序員在交付版本之前會
做什么（以及不會做什么） 138
經驗172：為被測版本做好準備 138
經驗173：有時測試員應該拒絕測試
某個版本 138
經驗174：使用冒煙測試檢驗版本 139
經驗175：有時正確的決策是停止測試，
暫停改錯，并重新設計軟件 139
經驗176：根據實際使用的開發(fā)實踐調整
自己的測試過程 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：在測試員與開發(fā)人員之間沒有
正確的比例 148
經驗190：調整任務和不能勝任的人員 148
經驗191：輪換測試員的測試對象 149
經驗192：盡量成對測試 149
經驗193：為項目指派一位問題查找高手 150
經驗194：確定測試的階段計劃，特別是
探索式測試的階段計劃 150
經驗195：分階段測試 151
經驗196：通過活動日志來反映對測試員
工作的干擾 151
經驗197：定期狀態(tài)報告是一種強
有力的工具 152
經驗198：再也沒有比副總裁掌握統(tǒng)計
數據更危險的了 153
經驗199：要小心通過程序錯誤數度量
項目進展 154
經驗200：使用的覆蓋率度量越獨立，
了解的信息越多 154
經驗201：利用綜合計分牌產生考慮
多個因素的狀態(tài)報告 155
經驗202：以下是周狀態(tài)報告的推薦
結構 156
經驗203：項目進展表是另一種展示
狀態(tài)的有用方法 157
經驗204：如果里程碑定義得很好，
里程碑報告很有用 158
經驗205：不要簽署批準產品的發(fā)布 159
經驗206：不要簽字承認產品經過測試
達到測試經理的滿意程度 159
經驗207：如果測試經理要編寫產品發(fā)布
報告，應描述測試工作和結果，
而不是自己對該產品的看法 159
經驗208：在產品最終發(fā)布報告中列出
沒有排除的程序錯誤 159
經驗209：有用的發(fā)布報告應列出批評者
可能指出的10個最糟糕的問題 160
第9章 測試小組的管理 161
經驗210：平庸是一種保守期望 161
經驗211：要把自己的員工當作執(zhí)行經理 162
經驗212：閱讀自己員工完成的錯誤報告 163
經驗213：像評估執(zhí)行經理那樣評估
測試員 163
經驗214：如果測試經理確實想知道實際
情況，可與員工一起測試 164
經驗215：不要指望別人能夠高效處理
多個項目 165
經驗216：積累自己員工的專業(yè)領域知識 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：創(chuàng)造培訓機會 172
經驗231：錄用決策是最重要的決策 173
經驗232：在招募期間利用承包人爭
取回旋余地 173
經驗233：謹慎把其他小組拒絕的人
吸收到測試小組中 173
經驗234：對測試小組需要承擔的任務，
以及完成這些任務所需的技能
做出規(guī)劃 174
經驗235：測試團隊成員要有不同背景 174
經驗236：錄用其他渠道的應聘者 175
經驗237：根據大家意見決定錄用 175
經驗238：錄用熱愛自己工作的人 175
經驗239：錄用正直的人 176
經驗240：在面談時，讓應聘者展示期望
有的技能 176
經驗241：在面談時，請應聘者通過非正
式能力測驗展示其在工作中
能夠運用的技能 176
經驗242：在錄用時，要求應聘者提供
工作樣本 177
經驗243：一旦拿定主意就迅速錄用 177
經驗244：要將錄用承諾形成文字，
并遵守諾言 177
第10章 軟件測試職業(yè)發(fā)展 179
經驗245：確定職業(yè)發(fā)展方向并不懈努力 179
經驗246：測試員的收入可以超過程序員
的收入 181
經驗247：可大膽改變職業(yè)發(fā)展方向
并追求其他目標 181
經驗248：不管選擇走哪條路，都要
積極追求 182
經驗249：超出軟件測試拓展自己的
職業(yè)發(fā)展方向 182
經驗250：超出公司拓展自己的
職業(yè)發(fā)展方向 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：測試策略要解釋測