編輯推薦
時隔6年，作者傾心打造的《全程軟體測試（第2版）》全新亮相！內容提要
《全程軟體測試（第2版）》全力主張“軟體測試貫穿軟體開發整個生命周期”的思想及其實踐，無論在傳統測試中還是在敏捷測試中都具有很好的指導作用。《全程軟體測試（第2版）》的素材來源於十幾年的測試工作，進行了很好的組織和提煉，力求做到易於理解、所學即所用、行之有效，並融入了敏捷測試、探索式測試等新的實踐經驗，能更好地滿足測試人員的當前實際工作需求。《全程軟體測試（第2版）》共分12章，以案例為背景，以項目實際運行的全過程為路線圖，全面展開軟體測試的思維方式、流程、方法和優秀實踐，涉及測試計畫、測試需求分析與設計、軟體評審、自動化測試、測試執行、缺陷跟蹤、結果評估等關鍵內容，最後輔以深刻的剖析與總結。目錄
第0章引子 10.1究竟什麼是軟體測試？ 2
0.2究竟什麼是敏捷測試？ 3
0.3軟體測試的作用6
0.4軟體測試在SDLC中的位置 7
0.5傳統的軟體測試過程9
0.6敏捷測試過程 12
第1章測試項目啟動 14
1.1了解軟體的質量需求15
1.1.1軟體產品的質量需求 15
1.1.2軟體質量的對立面——軟體缺陷18
1.1.3軟體缺陷產生的原因 20
1.1.4軟體測試的目標 22
1.2項目測試團隊 24
1.2.1測試過程和開發過程的關係24
1.2.2團隊組建27
1.2.3培訓29
1.2.4測試團隊在項目中的位置 30
1.3掌控項目背景 32
1.3.1軟體測試的項目要素 32
1.3.2兩個典型項目的介紹 34
1.4確定測試規範 36
1.5小結 44
第2章測試需求分析與計畫45
2.1軟體測試的目標和基本需求 46
2.1.1質量要求46
2.1.2測試目標49
2.1.3基本的測試需求 50
2.2項目的測試需求53
2.2.1測試需求分析的基本方法 54
2.2.2測試需求的分析技術 55
2.2.3功能測試範圍分析56
2.2.4非功能性的系統測試需求 60
2.3測試工作量估算66
2.3.1工作量的估計66
2.3.2工作分解結構表方法 68
2.3.3工作量估計的實例70
2.4測試資源需求 73
2.5測試里程碑和進度安排 74
2.5.1傳統測試74
2.5.2敏捷測試75
2.6測試風險分析 76
2.7制定有效的測試策略81
2.8完整生成測試計畫書85
2.9小結 86
第3章需求與設計的評審 88
3.1產品需求評審 89
3.1.1需求評審的重要性89
3.1.2測試人員在需求評審中的角色 92
3.1.3需求評審的標準 94
3.1.4需求的可測試性 96
3.2系統架構的審查97
3.2.1系統架構選型的確認 97
3.2.2軟體設計評審標準99
3.2.3設計的可測試性 102
3.2.4系統組件設計的審查 105
3.3產品設計規格說明書的複審 107
3.3.1重視設計規格說明書的審查107
3.3.2設計規格說明書的多層次審查 108
3.3.3界面設計的評審 109
3.3.4驗證過程與確認過程 110
3.4系統部署設計的審查112
3.4.1系統部署邏輯設計的審查 113
3.4.2軟體部署物理設計的審查 114
3.4.3可用性設計的審查115
3.4.4可伸縮性設計的驗證 119
3.4.5安全性設計的驗證121
3.5小結 121
第4章測試設計 123
4.1測試用例框架的設計124
4.1.1為什麼需要測試用例 124
4.1.2測試用例設計考慮因素125
4.1.3測試用例框架的構成 127
4.1.4測試用例的元素 129
4.2探索式測試之設計 130
4.3功能測試用例的設計133
4.3.1功能測試用例的內容 135
4.3.2功能測試用例的設計方法 136
4.3.3等價類劃分法與邊界值分析法 136
4.3.4決策表與因果圖法141
4.3.5功能圖法144
4.3.6Pair-wise方法和正交實驗設計方法145
4.4非功能性測試設計 148
4.4.1故障轉移測試設計148
4.4.2系統安全性測試設計 150
4.5測試用例的審查153
4.5.1測試用例書寫標準153
4.5.2測試用例評審要點154
4.6測試套件的創建157
4.7小結 160
第5章測試工具選擇和腳本開發161
5.1測試工具的需求分析162
5.1.1測試工具的優勢 162
5.1.2測試工具的實現原理 163
5.2測試工具的選擇167
5.2.1測試工具選擇的標準 167
5.2.2測試工具選擇的誤區 170
5.3商業測試工具解決方案 171
5.4開源測試工具解決方案 172
5.5測試腳本的開發174
5.5.1測試自動化策略 175
5.5.2適應測試腳本開發的測試用例 176
5.5.3測試腳本的重構和最佳化178
5.6小結 179
第6章單元測試 180
6.1程式代碼的審查181
6.1.1代碼審查的方法和範圍181
6.1.2代碼風格的審查 183
6.1.3編程規則的審查 186
6.2單元測試內容 189
6.2.1什麼是單元測試 189
6.2.2單元測試的現狀和作用191
6.2.3單元測試的方法 192
6.3單元測試用例的設計194
6.3.1語句覆蓋法 194
6.3.2判定和條件覆蓋法196
6.3.3基本路徑測試法 198
6.3.4多種白盒測試方法的比較和總結199
6.3.5循環結構的測試用例 201
6.3.6單元測試的典型實例 203
6.4單元測試工具 205
6.4.1靜態代碼分析206
6.4.2測試覆蓋率工具EMMA 207
6.5小結 210
第7章功能測試的執行211
7.1測試執行概述 212
7.2測試執行的準備214
7.2.1測試任務安排215
7.2.2測試環境的建立 216
7.2.3測試環境的設定 217
7.2.4測試自動化運行平台 219
7.3如何有效地創建測試套件221
7.3.1功能測試套件的創建 221
7.3.2測試環境的爆炸性組合及其最佳化223
7.4功能測試自動化的執行 226
7.5敏捷測試的執行229
7.5.1策略與實踐 229
7.5.2探索式測試的執行231
7.6用戶界面和適用性測試 233
7.7回歸測試 237
7.8軟體缺陷的報告240
7.8.1缺陷的屬性 240
7.8.2缺陷的詳細描述 243
7.8.3如何報告缺陷245
7.9小結 246
第8章國際化和本地化測試247
8.1國際化測試248
8.1.1軟體國際化的基本要求249
8.1.2國際化測試 253
8.1.3I18N測試實例255
8.2本地化測試257
8.2.1軟體本地化的質量需求258
8.2.2本地化測試的基本內容260
8.2.3L10N的功能測試 262
8.2.4L10N的數據格式驗證 264
8.2.5L10N的UI驗證 268
8.2.6L10N的配置和兼容性驗證 268
8.2.7L10N的翻譯驗證 270
8.3I18N和L10N測試工具 271
8.4小結 273
第9章系統非功能性測試 275
9.1實施要求和策略276
9.2 WEB套用伺服器的負載測試 278
9.2.1負載測試的載入方式 278
9.2.2負載測試的準備工作 279
9.2.3負載測試的執行 282
9.2.4負載測試的結果分析 284
9.3WEB套用伺服器的性能測試 285
9.4WEB安全性測試287
9.5容錯性測試289
9.6資料庫的性能測試 290
9.7兼容性測試294
9.8小結 297
第10章後續測試 299
10.1驗收測試299
10.2部署測試303
10.2.1客戶端軟體安裝測試303
10.2.2後台系統的部署測試305
10.3線上測試306
10.4後繼版本的測試 308
10.5小結310
第11章測試的跟蹤和管理 311
11.1測試管理312
11.1.1測試管理的全局性 312
11.1.2測試管理思想和策略313
11.1.3測試管理系統的套用315
11.1.4測試管理工具 317
11.2測試用例的管理 320
11.2.1測試用例管理架構 320
11.2.2管理與維護要點321
11.3測試自動化的管理323
11.3.1測試自動化的管理準則 323
11.3.2測試自動化的框架 327
11.3.3測試自動化的流程 328
11.4缺陷跟蹤和分析 330
11.4.1缺陷生命周期 330
11.4.2缺陷狀態的跟蹤332
11.4.3缺陷的分析333
11.4.4累計缺陷趨勢分析 336
11.5測試進度和風險的控制337
11.5.1測試進度管理 337
11.5.2測試風險的控制341
11.6測試覆蓋度和結果分析343
11.6.1測試覆蓋評估 344
11.6.2基於軟體缺陷的質量評估346
11.6.3軟體缺陷清除率348
11.6.4測試報告的模板、實例 350
11.7小結354
第12章總結與思考355
12.1軟體測試的現實和原則356
12.1.1測試的現實356
12.1.2測試的原則357
12.2軟體測試的多維空間 363
12.3軟體測試之辯證統一 364
12.3.1白盒測試方法和黑盒測試方法365
12.3.2靜態測試和動態測試366
12.3.3主動測試和被動測試366
12.3.4基於腳本測試和探索式測試 367
12.3.5手工測試和自動化測試 369
12.3.6測試方法綜合套用的總結370
12.4軟體測試的優秀實踐 371
12.4.1測試有效性和風險性的平衡 372
12.4.2測試計畫的優秀實踐373
12.4.3測試設計的優秀實踐374
12.4.4測試執行的優秀實踐375
12.4.5測試團隊建設中的優秀實踐 377
12.5持續改進379
12.5.1TMMi和TPI Next分析380
12.5.2構建更實用的持續改進模型 382
附錄A軟體測試全景圖 388
附錄B測試計畫（GB8567-2006）391
附錄C測試用例設計模板398
附錄D軟體缺陷模板401
附錄E代碼審查的示範性列表403
附錄F軟體測試相關的國家標準 407
附錄G軟體測試術語中英文對照 409
附錄H參考書目和資源 414
精彩節摘
翻閱少民的這部新作時，不禁讓我想起一位好朋友前幾天提到的《敘事謠曲》中“只彎一次腰”的故事：有一次，耶穌帶著他的門徒彼得出門遠行，在路上發現了一塊破爛的馬蹄鐵，耶穌就讓彼得揀起來，不料彼得懶得彎腰，假裝沒有聽見。耶穌沒說什麼，自己彎腰揀起馬蹄鐵，用它在鐵匠那裡換了幾文錢，並用這些錢買了十幾顆櫻桃。出了城，兩人繼續向前走，沿途都是茫茫的荒野，看不到人煙，也找不到水源。耶穌猜到彼得渴得厲害，就讓藏在袖子裡的櫻桃悄悄掉出一顆。彼得一見，趕緊撿起來吃掉。耶穌邊走邊掉，彼得也就狼狽地彎了十七八次腰。於是耶穌對他說：“要是你剛才彎一次腰，就不會在後來沒完沒了地彎腰了。小事不乾，就將在更多的小事上操勞。”這個故事，不同的人有不同的感悟。作為一個軟體行業的多年從業者，我很自然就聯想到了軟體開發過程。軟體測試（具體到每一個測試用例的實施）正是在龐大複雜的軟體產品開發過程中確保軟體產品質量的“小事”。軟體測試工作繁雜、瑣碎又耗時，甚至有時吃力不討好，這使得許多軟體從業者對其不夠重視；好多技術人員熱衷於編碼而不願從事測試工作這樣的“小事”；有些公司認為開發能出成果而測試可有可無，因而非常重視開發但不重視測試；許多國內軟體企業存在著漠視測試過程、測試時間不充分、測試計畫不細緻、測試軟硬體資源不足等問題，從而在軟體質量控制上存在相當大的問題，以致項目延遲甚至失敗。
在軟體產業發展的幾十年中，軟體測試已逐步滲透到各個領域，成為越來越不可或缺的技術成分。例如，以前被認為距離軟體技術比較遠的汽車工業，現在已把高級車製造費用的20%～25%投入到電子設備與軟體系統上。由此看來，軟體的品質已成為人們日益關注的重中之重。如何找到一種全面的分析方法，來檢測軟體開發過程中不同階段的結果，以便儘可能早地系統地保證或提高軟體產品的質量和可靠性，從而減少後期“彎腰”的必要性與次數，已成為影響軟體企業生產力與生產效率的關鍵問題。
可喜的是，越來越多的軟體公司和管理技術人員在工作中將更多的時間和資源投向了測試方面。很多優秀企業中開發與測試的人員比例達到了3:1或2:1，許多頂尖的技術人員在從事質量控制和軟體測試工作。而國內這幾年軟體測試人員的短缺和招聘難度的提高從反面證明了軟體測試正越來越得到重視。
近年來，軟體產業發展正從產品模式向服務模式（Software as a Service，SaaS）轉變。 在過去的多年中，WebEx公司一直處於這一浪潮的領導地位。WebEx提供的網路會議服務（Web Conference）被稱為改變人們工作方式的技術革命。朱少民先生與他帶領的團隊非常自豪而榮幸地參與了WebEx產品開發的整個過程，在這個過程中他們夯實了軟體測試的理論基礎，並積累了豐富的實戰經驗。
少民從事高校教育及軟體開發測試工作多年，並且在美國矽谷工作兩年，其經歷是很好的理論與實踐相結合的典範。與少民共事多年，了解他在軟體測試領域的積累，從開始時採用簡單、初級的測試方法，一步步發展到今天系統、科學的軟體質量管理體系；從手工測試向自動化測試過渡；從幾個人的測試小組到幾百名測試工程師的大規模團隊。現在，是到了將過去的經驗教訓作一番總結，以其親身經歷為業界同仁指點軟體測試的規律與介紹成功實踐經驗的時候了。
這部《全程軟體測試》是少民與其工作團隊多年來的經驗積累，其中一些觀點與見解已經成為WebEx公司的基本工作準則，對軟體研發領域有著重要的實質性貢獻。本書通過實例全面描述了軟體測試的整個過程，覆蓋了測試管理的各個重要方面。對測試管理的各個層次和環節做了系統的介紹，包括測試策略制定、風險控制、缺陷跟蹤和分析、測試管理系統的套用等，並且更進一步對如何執行本地化測試和國際化測試進行了闡述。作者重點聚焦在實踐性上，從軟體測試項目啟動、測試計畫開始，深入到測試用例設計、測試工具選擇、腳本開發，以及功能測試和系統測試等各個步驟，並對它們都做了詳細闡述。
讓人印象深刻的是本書對軟體測試工作中幾個看似簡單，實際上非常關鍵的問題做了詳細的說明。例如就開發團隊模式，作者介紹了以開發為核心、以項目經理為核心，以及“三國鼎立”（以項目經理、開發組長、測試組長為核心）的模式。而“三國鼎立”的測試團隊具有獨立、權威性地位的概念也是工作經驗的總結。相信讀者會從實戰中體會到作者的深刻用意。
在探索高效軟體測試與軟體開發的過程中，本書覆蓋了全面的理論分析和詳細的實戰闡述，對任何從事軟體測試的人員和軟體開發人員，以及軟體工程相關專業的高校師生，都具有重要的參考價值。希望書中的一些真知灼見對廣大讀者有所裨益。
李欽敏（Jim Li）
WebEx總部工程技術及中國研發高級總監
2007年6月於美國矽谷
2007年春節後，我從美國返回國內，曾在美麗的西子湖畔與作者一敘，其間我們談到了《全程軟體測試》這本書。我高興地接受了作者的邀請——為本書寫推薦序。我和作者共事近7年，結下了深厚的友誼。我們從2000年開始，就合作開發美國網迅公司（WebEx Communications, Inc，納斯達克上市公司，2007年5月被CISCO以32億美元收購）網際網路通信平台產品第一個基於PHP的網頁。那時，我在美國領導著整個Web開發部門，他則在國內負責軟體測試。再到後來，我們在產品研發、部署和服務運營等多個領域的合作不斷深入。在我管理整個網迅（中國）公司的這段時間裡，他作為公司的質量管理總監直接向我匯報工作。當然，這也是我們合作最親密的一段時間。
話說回來，作者在加盟網迅之前，雖然已是一所重點大學的副研究員、碩士生導師，而且擁有良好的軟體開發和項目管理經驗，但那時國內軟體測試還剛剛起步，他對軟體測試也了解甚少，可以說是一個門外漢。
時光如梭，7年的時間一晃而過。同樣擁有7年的時光，如果缺乏思考，收穫就屈指可數；如果勤於鑽研，就會碩果纍纍。而他不僅勤于思考、善於思考，而且憑著智慧、毅力和堅實的計算機基礎，很快就從一個門外漢成為軟體測試領域的資深專家，他先後主編了3本有關軟體工程領域的高等學校教材。在這7年裡，他不斷通過自學、努力和追求，幫助網迅（中國）公司從零開始建立和發展軟體測試團隊，圓滿地完成了全線產品的軟體測試任務，並向全球的客戶提供了高質量的軟體產品和服務。目前，他領導著這支近300人的國內一流測試團隊，正向下一個目標前進。
軟體質量管理在軟體研發團隊中的作用是顯而易見的。其中軟體測試人員在保障和改進軟體質量工作中發揮著越來越大的作用。但是從整個軟體工程周期來看，軟體質量其實是在整個開發過程中形成的，或者說軟體質量是構造出來的，而不是測出來的。程式代碼完成之後，其質量水平就基本確定了，雖然可以通過測試發現大部分缺陷，但是，程式代碼中存在的缺陷越多，遺漏的缺陷就會越多，質量很難得到改善。如果缺陷發生在需求階段或設計階段，則將帶來更大的成本和風險。如果將軟體測試貫穿於整個軟體開發過程，從項目啟動的第一天開始就將軟體測試引入進來，情況就完全不一樣了。貫穿於軟體開發全過程的測試，不僅可以在第一時間內發現缺陷，而且能有效地預防缺陷的產生。缺陷預防，可以大大減少軟體缺陷的數量、提高軟體質量，更有價值的是，它可以極大地縮短開發周期、降低軟體開發的成本。
全過程的軟體測試，賦予了軟體測試更多的責任和內容，軟體測試不再是事後檢查，而是缺陷預防和檢查的統一。在需求分析時，通過測試團隊和開發團隊的共同努力，儘可能把用戶的需求全部挖掘出來，清除一切模糊的需求描述；在設計階段，測試人員可以對不合理的設計提出質疑，督促開發人員在設計時充分考慮性能、可靠性和安全性等各個方面的要求，以確定每一個設計項的可測試性；在編程階段，測試人員參與代碼評審、單元測試等。所有這些都是為了告訴人們，測試過程可以看作質量保證的過程，測試不再是產品質量的一個檢驗環節。這也就是《全程軟體測試》書名的由來，將軟體測試擴展到軟體質量保證的全過程中，作者賦予了軟體測試新的含義和新的生命！
全程軟體測試的另一層含義就是手把手地教會讀者如何做測試，從頭到尾，覆蓋每一個環節。從項目啟動——如何把握項目的背景和需求、如何選定測試組長等開始，逐漸深入測試計畫、設計評審、用例設計、測試執行等過程，直至缺陷報告、測試結果分析和測試報告，每一過程都能得到細緻的輔導。作者還用了不少筆墨來介紹如何選擇測試工具、如何更有效地開展測試自動化的工作。因為測試自動化非常重要，它可以解放測試人員，使測試工作變得非常有趣，又獲得很高的技術挑戰。測試自動化能夠提高測試效率，使測試人員有更多的時間思考，從而可以更好地分析測試範圍和設計好測試用例，形成一個良性的循環。
本書不僅闡述了先進的、獨特且成熟的軟體測試思想和方法，而且呈現了豐富多彩而又實實在在的測試技術和實踐。測試的知識、概念是比較容易獲得的，但要獲得多年通過實踐積累下來的體會和經驗，卻是非常難得的。現在，這些內容就在您的眼前，唾手可得。《全程軟體測試》能幫助您獲得您所需要的東西、幫您解開心中的疑惑。本書給出的最佳實踐，不僅代表著國內的最高水平，而且與美國矽谷的軟體測試水平同步。它一定會幫助讀者高效地、高質量地完成測試和軟體質量保證任務。
最後，希望大家喜歡這本書，進而從中受益。
沈劍（Joss Shen）
Founder and CEO
Dreamcast Systems, Inc.
作者簡介
朱少民，國內軟體測試界的領軍人物和資深專家，二十多年來一直從事軟體測試、質量管理和過程改進等工作，先後出版了十多部著作，包括測試方面的暢銷書《完美測試》、《輕輕鬆鬆自動化測試》、《軟體測試方法和技術》、《軟體測試》和譯作《自動化測試最佳實踐》等，經常在國內外會議上發表演講。之前曾任思科-網迅（中國）軟體有限公司QA高級總監，目前是同濟大學軟體學院教授、中國科技大學軟體學院教指委委員。媒體評論
這是一本為軟體測試團隊創作的融實踐性、專業性、思想性和實用性為一體的軟體測試書籍。全書以完整測試項目的規劃和執行過程為主線，以典型測試項目案例為分析和套用實例，把作者豐富的測試實踐經驗與具體測試方法和技術總結出來與讀者分享。本書適合於指導軟體公司測試經理和測試工程師閱讀和實踐，對準備從事軟體測試的從業人員也是不可多得的學習和培訓教材。——崔啟亮昱達軟體科技有限公司 技術與培訓總裁
非常欣喜地得知又一本國內原創的軟體測試專著問世了，目前國內的軟體測試書籍理論偏多，介紹最佳實踐的偏少，希望本書能成為軟體測試工程師的案頭手冊，為國內軟體測試行業的蓬勃發展添磚加瓦。
——賀炘慧靈科技
首席測試專家、北京軟體行業協會測試工作委員會副秘書長
如果你想通過一本切合實際而不僅僅是紙上談兵的書來學習軟體測試，《全程軟體測試》會是一個很好的選擇！
——周澤睿百度高級測試工程師
興趣：模組級測試、性能壓力測試、網路編程、算法等
很難得，久未看到如此讓人暢快的文章。能將軟體工程實踐系統地貫穿在一起，並不失理論佐證，這本身就是個勝利。
——高磊百度高級測試工程師
致力於軟體測試前沿理論的探索及其與工程實踐的結合
優秀的測試思想，體現著對人生反思的哲學。從某種意義上說，生活和軟體開發一樣，要在試錯的磨鍊中成長。
——李曉傑百度測試與項目管理工程師
本書最吸引我的地方在於其真實的項目背景，這對於缺乏豐富實踐經驗的從業人員來說無疑是最寶貴的材料。
——周可杉對外經濟貿易大學信息學院在讀碩士研究生
研究方向：管理信息系統與電子商務
作者對於測試項目從啟動、計畫、驗證、設計、工具和腳本開發等多個角度由淺入深地介紹，非常有利於初學者對於測試流程的理解。
——曹輝某公司軟體測試工程師
計算機信息管理專業
前言
“人生天地間，若白駒之過隙，忽然而已”，這樣開頭雖然比較俗，但也的確反映真實感受。2007年《全程軟體測試》第1版和讀者見面了，一晃六年了。欣慰的是，本書深受讀者喜歡，在噹噹網有2百多人評論，總評是五顆星，在京東網也得到五星級的好評，甚至有些公司把這本書作為新員工的培訓教材，有些公司的測試工程師人手一本。但隨著時間推移，越來越感覺這本書需要修改，但似乎“筆頭懶”，遲遲沒有動手修改本書，出版社編輯常常催促，我似乎不為所動，但終究拗不過編輯，趁著節日終於完成其修改，使本書第2版能夠與讀者見面。六年來，筆者經常參加一些軟體技術大會，和測試同仁有很多交流，閱讀了不少測試類圖書，也經常上網瀏覽國外測試大師的部落格，自己對軟體測試有著更深的理解，每當瀏覽《全程軟體測試》第1版，總覺得其中許多內容都需要修改，本書可能會被改得面目全非，但那需要很多時間，甚至不如重新寫一本書，這也就是為什麼遲遲沒有修改本書的潛在原因之一吧。後來想，也不能翻天覆地地大改，應該保持其基本面貌，否則就不是原書的第2版。
幸好，當初本書寫作時就認定“軟體測試是貫穿整個軟體生命周期的活動”，這個主題在今天依舊有效，即使在敏捷開發模式下，“全過程的軟體測試”也是大家全力提倡的，可以說本書主題和敏捷測試是不謀而合，雖然在局部或某些具體的實踐有衝突。本書所介紹的許多實踐來自美國矽谷，具有很好的先進性和普適性，即使若干年後，這些實踐中大部分內容在今天依舊有很好的借鑑作用。
在本次修改中，為了保持本書的風格和一致性，全書結構沒有進行大的改動，還保持原來的12章，從引子、項目啟動到最後的思考與總結，但有幾個小節還是做了較大調整，使全書結構更合理，同時融入了一些敏捷測試實踐，包括持續測試、驗收測試驅動開發、探索式測試等內容，以適應目前業界的環境。第2版的主要修改如下。
（1）引子：增加兩部分內容，即“究竟什麼是敏捷測試？”、“敏捷測試過程”，以達到更好的鋪墊效果。
（2）把第2章“團隊組建”、“培訓”兩小節移到第1章，刪除“測試組長的人選”這一小節，在1.2節比較徹底地討論測試團隊相關的問題。
（3）將“需求評審”移到第3章，第2章加強了測試需求分析，包括質量要求和測試目標、測試需求的分析方法和技術。測試需求分析不僅是測試設計的基礎，也是制定測試計畫的基礎，第2章定義為“測試需求分析與計畫”，就更加自然，先進行測試需求分析，再逐步完成測試計畫所要進行的工作，包括測試風險分析、工作量估算。
（4）第3章的重點放在需求和設計的評審上，構成了完整的“靜態測試”篇章。而且，在這一章增加了“需求可測試性”和“設計可測試性”兩小節，使需求評審和設計評審更具價值，也為將來的測試設計和執行打下更堅實的基礎。
（5）第4章不僅增加了“探索式測試設計”，順帶介紹了基於會話的測試管理（SBTM），而且對黑盒測試的具體方法重新組織，讓讀者更有效地運用測試方法，如將等價類劃分方法和邊界值分析法結合在一起來套用。Pair-wise方法使用起來方便，所以也添加進來了。
（6）第5章進行了簡化，把具體工具的介紹和對比刪去了，工具變化很快，儘量避免工具的一般介紹性內容。同時，增加了自動化測試策略，包括整體策略和功能測試自動化策略。
（7）第7章增加了“敏捷測試的執行”一節，這節包含兩個小節：“敏捷測試策略與實踐、探索式測試的執行”。第1章已討論了“培訓”，本章刪除了原來的“培訓和知識傳遞”，並簡化了測試環境爆炸性組合的最佳化方法。
（8）第9章改為“系統非功能性測試”，所以原來“安裝測試”一節的內容，整改為“部署測試”，移到第10章。刪除原9.1節討論的非功能性測試內容，部分內容和第2、第3章進行了合併。
（9）第10章刪除“10.2文檔測試”，少量有價值內容併入“驗收測試”，而且將敏捷流程的“驗收測試”考慮進來，和傳統“驗收測試”加以區分。最後，把“α測試和β測試”整合為線上測試。
（10）將第12章中的一節移到第11章，整合為“測試自動化的管理準則”，對測試自動化的框架做了較大修改，更準確地定義了自動化測試框架的概念。對“軟體缺陷清除率”、“測試管理思想和策略”兩小節也做了較多修改，測試用例的管理也從原來三小節整合為兩小節。
（11）第12章改動也比較大，測試原則由原來的10條增加到12條，而更大的改動在“12.3軟體測試之辯證統一”、“12.5持續改進”這兩節，增加了“基於腳本測試和探索式測試”、“TMMi和TPI Next分析”，而且對相應的內容做了刪減。另外兩節“12.2軟體測試的多維空間”、“12.4軟體測試的優秀實踐”也有一些修改。
（12）附錄刪除了“完整的項目檢查表”和“完整的測試工具列表”，因為前者和測試關係不是十分密切，而刪除後者則是因為在第5章已將主要的測試工具做了介紹，有那么多工具對讀者使用已足夠了。如果還需要其他工具，可以藉助網路搜尋引擎來查找。而增加了“用例設計模板”、“缺陷報告模板”、“測試相關的國家標準”三個附錄，“軟體測試計畫模板”也換了最新的國家標準定義的模板。
（13）第6、第8章沒有大的改動，只進行了細節上的文字修改。
看起來，第2版做了比較大的改動，但自己也不是十分滿意，可能是第1版的基礎還不夠紮實，總覺得有些內容還可以不斷改下去，但時間又不允許。而且，在敏捷時代追求完美也是不合情理的，雖然不能做到持續交付、快速交付，但縮短疊代時間還是可以的，如1～2年本書出一個版本還是可以的，也是比較好的。
希望經過修改後，本書更能滿足當今軟體測試的知識傳遞和技能培養的需求，可以給讀者帶來更多的收益，更希望讀者不吝賜教，我將繼續努力修改本書，繼續更好、更多地為測試人服務。
朱少民
2013年國慶節於上海
2000年剛建立測試團隊時，測試人員和開發人員是一種對立的關係，開發人員覺得軟體測試是挑他們的毛病，和他們過不去，有一個簡單的故事可以說明這一點。當時，條件有限，測試人員和開發人員共享一台小型機伺服器，測試人員發現了一個缺陷，告訴了某個開發人員，而他趁測試人員不注意，回到自己的座位上偷偷地修改了代碼，處理了那個缺陷，然後跑到測試人員身邊說：“你把那個Bug再現給我看看？”結果，可想而知，這個測試人員無論如何也不能復現那個Bug（缺陷）了。
幾年以後，這種情況不再出現了，不是因為條件好了，可以買很多伺服器，將測試環境和開發環境分離開來，而是觀念改變了。雖然的確是購買了幾百台伺服器（不用小型機，越來越多的伺服器採用Linux系統），將測試環境和開發環境分離開了，在客觀上可以避免那類“悲劇”的發生，但是觀念遠比機器重要。擁有正確的觀念，就比較容易創建良好的質量文化，開發人員的態度也隨之發生變化，他們已經深深認識到：
軟體測試是幫助自己，測試人員是在找產品定義、設計和實現的缺陷，不是找自己的缺陷，是對事，不是對人；
測試人員越快地發現缺陷，項目越能儘早結束；
測試人員儘可能多地發現Bug，遺留在產品中的Bug就會越少，產品的質量就會越高；
測試人員和自己（開發人員）的工作都是為了相同的目標——按時、高質量地發布產品；
開發人員的水平越高，所寫的程式中的Bug越少，而不在於使用了別人不知道的技巧。
現在，有的開發人員向我抱怨，是不是換了一個新人測試他寫的模組？因為這次發現的缺陷比前次發現的少多了。開發人員希望更多的缺陷被測試人員發現出來，絕不希望缺陷被留給客戶去發現。
今天，我們高興地看到開發人員和測試人員心往一處想。從項目啟動的第一天起到需求和設計的評審階段，從後期的缺陷修正到產品維護——在整個軟體生命周期中，開發人員和測試人員愉快地合作、共同努力，將軟體產品的開發效率和質量推到一個新的高度。一方面，開發人員主動介紹自己對產品特性是如何理解的，又是如何實現這些特性的，他們主動邀請測試人員參與代碼的走查並對新發現的Bug快速回響。另一方面，測試人員提前將設計好的一些測試用例交給開發人員，讓開發人員先根據這些測試用例驗證正在開發的功能特性，測試人員還愉快地幫助開發人員再現某個缺陷。
所有這些，都可以看出軟體測試在國內越來越受重視，軟體測試領域正迎來朝氣蓬勃的新氣象。當更多的人投入到測試行業時，需要一本實踐性強、富有啟發性的專業書，指導大家如何進行測試，出色地完成測試任務。這本《全程軟體測試》就承擔了這樣一個任務，它會從項目啟動開始，一步一步地教會大家如何做好測試工作，包括建立測試組、計畫測試、設計測試用例、選擇測試工具、開發測試腳本、執行測試和編寫測試報告等。這也是我與大家分享多年來積累的軟體測試經驗與技術實踐，以及不斷思考所升華的體會。
為了寫這本書，我事先也做了一些嘗試，儘量收集大家對軟體測試需求的反饋，並在CSDN的個人部落格上演義了30回的軟體測試，受到了大家的好評。也許就因為這個，在CSDN建立部落格不到8個月，我的部落格就成為當年（2006年）十大最具價值的部落格之一。
此前，我曾寫過一本《軟體測試方法和技術》的教材，這本教材在比較短的時間內印刷了好幾次，也頗受歡迎。但那本書在很大程度上是從理論、概念上講解軟體測試的方法和技術的，適合在校學生使用。而這本書重實踐、重套用，適合軟體公司的測試經理、工程師和想進入軟體測試行業的人員學習。
全書共12章，以兩個案例為背景，以項目向前發展的實際過程為路線圖，全面展開軟體測試的思想、流程、方法、技術和最佳實踐。全書力求做到方法有效、技術實用，集中講解實際測試工作，沒有單純地介紹概念，而是將概念準確地穿插在測試進程活動之中。
第1章介紹測試項目啟動後要做好哪些準備，如何掌控項目背景和要素，為制定測試計畫打下堅實的基礎。
第2章本章的焦點是測試計畫，主要討論測試人員在需求評審中的作用。
第3章本章從系統架構的審查開始，深入到系統組件設計、設計規格說明書、界面設計和系統部署設計等一系列的審查。
第4章本章圍繞測試設計展開討論，先從測試用例框架的設計入手，然後逐步涉及測試用例的構成、設計方法、評審、功能測試用例和系統測試用例的設計。
第5章本章著重介紹測試工具的選擇和腳本的開發。
第6章本章展示測試和編程的互動過程。
第7章本章開始進入功能測試的執行階段，並著重介紹了自動化功能測試的執行。
第8章本章介紹如何進行國際化測試和本地化測試。
第9章本章的重點內容是如何執行系統測試。
第10章本章介紹驗收測試、文檔測試、α測試和β測試、產品後繼版本的測試。
第11章本章介紹測試管理的思想和系統、測試用例的管理、測試自動化的管理、缺陷跟蹤和分析、測試進度和風險的控制、測試覆蓋度和結果分析等。
第12章最後一章是對測試的總結和思考。
本書最後附有軟體測試全景圖、完整的項目檢查表、軟體測試計畫通用模板、完整的測試工具列表和代碼審查的示範性列表等資料。
由於水平和時間的限制，書中難免會出現錯誤，歡迎讀者及業界同仁不吝指正。
筆者
