軟件測試是一門新興的學科，同時，又是一門越來越重要的學科。本書首先從軟件測試的產生和定義出發，描述了一個完整的軟件測試知識體系輪廓，讓讀者從全局來把握軟件測試；然后，針對軟件測試不同的知識點展開討論。
本書在內容組織上力求創新，盡量使軟件測試知識具有很好的銜接性和系統性，使需求和設計評審、軟件測試用例設計、自動化測試和各個階段的實際測試活動有機地結合起來，使讀者更容易領會如何將測試的方法和技術應用到單元測試、功能測試、系統測試和本地化測試中去。本書提供了豐富的實例和實踐要點，更好地體現軟件測試學科的特點，使讀者掌握測試方法的應用之道和品味測試的極佳實踐。
本書條理清晰、語言流暢、通俗易懂，內容豐富、實用，理論和實踐能有效地結合。本書可作為高等學校的軟件工程專業、計算機軟件專業和相關專業的教材，也可作為軟件測試工程師以及其他各類軟件工程技術人員的參考書。
《軟件測試》條理清晰、語言流暢、通俗易懂，內容豐富、實用，理論和實踐能有效地結合。《軟件測試》可作為高等學校的軟件工程專業、計算機軟件專業和相關專業的教材，也可作為軟件測試工程師以及其他各類軟件工程技術人員的參考書。
內容與軟件測試行業實際需求相吻合
理論和實踐有機結合
簡單易懂、循序漸進、案例豐富
《軟件測試》從軟件測試的基本概念出發，對單元測試、集成測試到功能測試、性能測試進行全面介紹，深入講解其中涉及到的測試方法。《軟件測試》將軟件測試自動化作為重點內容進行介紹．包括測試工具的介紹、使用以及腳本的開發和維護。軟件測試是一門實踐性很強的課程，這對其教材的編寫有更高的要求，《軟件測試》充分吸收軟件業界的經驗和最佳實踐，并力求簡單易懂、循序漸進，配以豐富的案例。
在過去半個世紀，軟件獲得了空前的發展，逐漸滲透到各個領域，從最早的科學計算、文字處理、數據庫管理、銀行業務處理，到工業自動控制和生產、辦公自動化、新聞媒體、通信、汽車、消費電子、娛樂等，軟件無處不在，改變了人類的生活與生產方式。隨著計算機軟件在各行各業的普及應用，人們對軟件質量的要求也越來越高，軟件的專業化和多樣化特點越來越顯著。但同時，我們看到軟件產業目前還不夠成熟，軟件質量的現狀不容樂觀，軟件在運行和使用過程中出現的問題還比較多。例如，2008年互聯網Web發展十大失敗事件中，90％都是由質量問題造成的，與"宕機"、"停機"、"崩潰"等一系列嚴重的質量問題聯系在一起。
軟件質量一直是軟件工程中的一個焦點，成為人們幾十年來不斷研究、探索的領域。為了改善軟件質量，人們不僅從企業文化、軟件過程模型、需求工程、設計模式等不同方面來獲取有效的方法和實踐，而且開始重視軟件測試，在軟件測試上有更多的考慮和投入。雖然質量是內建的，但軟件測試依舊承擔著非常重要的作用。軟件測試自身也在發生變化，已經不再只充當門衛——僅在軟件發布之前進行檢驗，而是正在形成一個持續的反饋機制，貫穿軟件開發的整個過程，以便盡早地發現問題，降低開發成本，提高軟件開發生產力。軟件測試人員不再是軟件開發的輔助人員，而是軟件開發團隊的主體之一、積極的參與者。從項目開始的第一天，測試人員就參與項目需求和設計的討論、評審等各種活動，盡早發現軟件需求定義和設計實現上的問題，及時發現軟件項目中存在的質量風險。軟件開發團隊必須盡可能地在交付產品之前控制未來的質量風險，這就必然需要依賴于卓有成效的軟件測試。將傳統的程序測試的狹義概念擴展到今日業界逐漸認可的、廣義的軟件測試概念，測試涵蓋了需求驗證（評審）、設計驗證（評審）等活動。軟f牛測試貫穿整個軟件生命周期，從需求評審、設計評審開始，就介入到軟件產品的開發活動或軟件項目的實施中，和其他開發團隊相互協作、相互補充，共同構成軟件生命周期中的有機整體。
軟件測試不是一項簡單的工作，它遠比人們所直觀想象的要復雜。高效、高質量地完成一個軟件系統的測試，涉及的因素很多，也會碰到各種各樣的問題，并且要在測試效率和測試風險之間找到最佳平衡點和有效的測試策略，這些都需要測試人員一一克服。要做好軟件測試，測試人員不僅需要站在客戶的角度思考問題，真正理解客戶的需求，具備良好的分析能力和創造性的思維能力，完成功能測試和用戶界面的測試，而且要能理解軟件系統的實現機理和各種使用場景，具備扎實的技術功底，能通過測試工具完成相應的性能測試、安全性測試、兼容性測試和可靠性測試等更具挑戰性的任務。軟件測試的主要目的是發現軟件中的缺陷；堅持"質量第一"的原則，就會在實際操作中遇到一些阻力，這都需要測試人員去克服。從這些角度看，相對設計、編程人員，對一個優秀的測試工程師的要求要高得多，不僅要體現高超的技術能力，如系統平臺設置、架構設計分析、編程等方面的能力，而且要展示自己的業務分析能力、對客戶需求的理解能力和團隊溝通協作的能力。
第1章 軟件測試概述 1
1.1 一個真實的故事 1
1.2 為什么要進行軟件測試 2
1.3 軟件缺陷的由來 4
1.4 軟件測試學科的發展歷程 5
1.5 軟件測試的定義 6
1.5.1 基本定義的正反兩面性 6
1.5.2 服從于用戶需求——V&V 7
1.6 軟件測試和軟件開發 8
1.6.1 軟件測試過程 9
1.6.2 軟件測試和開發的關系 11
小結 12
思考題 12
第2章 需求和設計評審 13
2.1 軟件評審的方法與技術 13
2.1.1 什么是評審 13
2.1.2 評審的方法 15
2.1.3 評審會議 16
2.1.4 評審的技術 18
2.2 產品需求評審 19
2.2.1 需求評審的重要性 19
2.2.2 如何理解需求 21
2.2.3 需求評審的標準 22
2.2.4 如何對需求進行評審 24
2.3 設計評審 25
2.3.1 軟件設計評審標準 25
2.3.2 系統架構設計的評審 27
2.3.3 組件設計的評審 28
2.3.4 界面設計的評審 28
小結 29
思考題 30
第3章 測試用例設計 31
3.1 什么是測試用例 31
3.1.1 一個簡單的測試用例 31
3.1.2 測試用例的元素 32
3.2 為什么需要測試用例 33
3.3 測試用例的質量 34
3.3.1 測試用例的質量要求 34
3.3.2 測試用例書寫標準 35
3.3.3 如何設計出高質量的測試用例 36
3.3.4 測試用例的評審 39
3.4 測試用例的組織和使用 40
3.4.1 測試用例的創建 40
3.4.2 測試用例套件 41
3.4.3 測試用例的維護 43
小結 43
思考題 44
第4章 軟件測試自動化 45
4.1 測試自動化的內涵 45
4.1.1 簡單的實驗 46
4.1.2 自動化測試的例子 47
4.1.3 什么是自動化測試 48
4.1.4 自動化測試的特點和優勢 49
4.2 自動化測試的原理 51
4.2.1 代碼分析 51
4.2.2 GUI對象識別 52
4.2.3 DOM對象識別 54
4.2.4 自動比較技術 55
4.2.5 腳本技術 56
4.3 測試工具的分類和選擇 59
4.3.1 測試工具的分類 59
4.3.2 測試工具的選擇 61
4.4 自動化測試的引入 62
4.4.1 普遍存在的問題 62
4.4.2 對策 63
小結 65
思考題 66
第5章 單元測試和集成測試 67
5.1 什么是單元測試 68
5.2 單元測試的方法 68
5.2.1 黑盒方法和白盒方法 69
5.2.2 驅動程序和樁程序 70
5.3 白盒測試方法的用例設計 70
5.3.1 分支覆蓋 71
5.3.2 條件覆蓋 71
5.3.3 基本路徑測試法 72
5.4 代碼審查 74
5.4.1 代碼審查的范圍和方法 74
5.4.2 代碼規范性的審查 75
5.4.3 代碼缺陷檢查表 76
5.5 集成測試 79
5.5.1 集成測試的模式 79
5.5.2 自頂向下集成測試 79
5.5.3 自底向上集成測試 80
5.5.4 混合策略 80
5.6 單元測試工具 81
5.6.1 JUnit介紹 82
5.6.2 用JUnit進行單元測試 83
5.6.3 微軟VSTS的單元測試 87
5.6.4 開源工具 88
5.6.5 商業工具 91
小結 92
思考題 93
第6章 功能測試 94
6.1 功能測試 94
6.2 功能測試用例的設計 95
6.2.1 等價類劃分法 96
6.2.2 邊界值分析法 99
6.2.3 循環結構測試的綜合方法 101
6.2.4 因果圖法 102
6.2.5 決策表方法 105
6.2.6 功能圖法 107
6.2.7 正交試驗設計方法 108
6.3 可用性測試 111
6.3.1 可用性的內部測試 111
6.3.2 可用性的外部測試 114
6.4 功能測試執行 115
6.4.1 功能測試套件的創建 115
6.4.2 回歸測試 116
6.5 功能測試工具 118
6.5.1 如何使用功能測試工具 118
6.5.2 開源工具 119
6.5.3 商業工具 121
小結 123
思考題 124
第7章 國際化和本地化測試 125
7.1 國際化和本地化的概念 125
7.2 國際化測試 126
7.2.1 軟件國際化的基本要求 126
7.2.2 全球通用的字符集 128
7.2.3 國際化及其標準 129
7.2.4 國際化測試方法 132
7.2.5 國際化測試點 133
7.3 本地化測試 135
7.3.1 軟件本地化的實現 135
7.3.2 功能測試 136
7.3.3 數據格式驗證 138
7.3.4 UI驗證 141
7.3.5 配置和兼容性驗證 142
7.3.6 翻譯驗證 143
7.4 I18N和L10N測試工具 144
小結 146
思考題 146
第8章 系統測試 147
8.1 什么是系統測試 147
8.2 概念：負載測試、壓力測試和性能測試 149
8.2.1 背景及其分析 149
8.2.2 定義 150
8.3 負載測試技術 151
8.3.1 負載測試過程 151
8.3.2 輸入參數 152
8.3.3 輸出參數 154
8.3.4 場景設置 155
8.3.5 負載測試的執行 157
8.3.6 負載測試的結果分析 157
8.4 性能測試 158
8.4.1 如何確定性能需求 159
8.4.2 性能測試類型 160
8.4.3 性能測試的步驟 160
8.4.4 一些常見的性能問題 163
8.4.5 容量測試 163
8.5 壓力測試 164
8.6 性能測試工具 165
8.6.1 特性及其使用 165
8.6.2 開源工具 167
8.6.3 商業工具 169
8.7 兼容性測試 171
8.7.1 兼容性測試的內容 171
8.7.2 系統兼容性測試 172
8.7.3 數據兼容性測試 173
8.8 安全性測試 174
8.8.1 安全性測試的范圍 174
8.8.2 Web安全性的測試 175
8.8.3 安全性測試工具 177
8.9 容錯性測試 178
8.9.1 負面測試 178
8.9.2 故障轉移測試 179
8.10 可靠性測試 181
小結 181
思考題 182
第9章 缺陷報告 183
9.1 一個簡單的缺陷報告 183
9.2 缺陷報告的描述 184
9.2.1 缺陷的嚴重性和優先級 185
9.2.2 缺陷的類型和來源 186
9.2.3 缺陷附件 186
9.2.4 完整的缺陷信息列表 187
9.3 如何有效地報告缺陷 188
9.4 軟件缺陷的處理和跟蹤 189
9.4.1 軟件缺陷生命周期 189
9.4.2 缺陷的跟蹤處理 190
9.4.3 缺陷狀態報告 191
9.5 缺陷分析 192
9.5.1 實時趨勢分析 192
9.5.2 累計趨勢分析 194
9.5.3 缺陷分布分析 195
9.6 缺陷跟蹤系統 197
小結 199
思考題 199
第10章 測試計劃和管理 200
10.1 測試的原則 200
10.2 測試計劃 202
10.2.1 概述 203
10.2.2 測試計劃過程 203
10.2.3 測試目標 204
10.2.4 測試策略 205
10.2.5 制定有效的測試計劃 208
10.3 測試范圍分析和工作量估計 209
10.3.1 測試范圍的分析 209
10.3.2 工作量的估計 210
10.4 資源安排和進度管理 212
10.4.1 測試資源需求 212
10.4.2 團隊組建與培訓 213
10.4.3 測試進度管理 214
10.5 測試風險的控制 215
10.5.1 主要存在的風險 215
10.5.2 控制風險的對策 217
10.5.3 測試策略的執行 218
10.6 測試報告 219
10.6.1 評估測試覆蓋率 220
10.6.2 基于軟件缺陷的質量評估 221
10.6.3 測試報告的書寫 223
10.7 測試管理工具 223
10.7.1 測試管理系統的構成 223
10.7.2 主要工具介紹 225
小結 226
思考題 227
附錄A 軟件測試術語中英文對照 228
附錄B 測試計劃簡化模板 233
附錄C 測試用例設計模板 235
附錄D 軟件缺陷模板 237
附錄E 軟件測試報告模板 239
參考文獻 242
2．缺乏相應的人才有些軟件公司舍得花幾十萬元去買測試工具軟件，但缺乏具有良好素質、經驗的測試人才。軟件測試自動化并不是簡簡單單地使用測試工具，需要建立良好的自動化測試框架、開發測試腳本，這就要求測試人員不僅要熟悉產品的特性和領域知識，而且要掌握開發平臺構建技術和具備較高的編程能力。
3．測試腳本的質量低劣有些軟件組織對待測試腳本，不像對待軟件產品自身的源代碼，既沒有將腳本進行有效的配置管理，也沒有遵守設計原則和編碼規范，測試腳本存在很多問題，例如結構混亂、變量命名不規范、缺少注釋等，從而導致測試腳本的質量低劣。測試腳本的質量將直接影響到測試執行過程，腳本執行不穩定，并導致測試結果不準確、不可靠。
4．缺乏培訓
在引入測試工具前后，有些組織缺乏對測試人員的培訓，其結果，測試人員對測試工具了解的深度和廣度都不夠，從而導致測試工具的使用效率低下，不能達到管理者的期望。測試自動化的培訓是一個長期的實踐過程，不是通過一兩次講課的形式就能達到效果，而應該提供具有實際項目背景的系列培訓，從頭開始，逐步深入，直至掌握主要的方法和技巧等。
5．沒有考慮到公司的實際情況。盲目引入測試工具
有一點很明確，不同的測試工具面向不同的測試目的、具有各自的特點和適用范圍，所以不是任何一個優秀的測試工具都能適應不同公司的需求。某個公司懷著美好的愿望花了不小的代價引入測試工具，半年一年以后，測試工具卻成了擺設。究其原因，就是沒有能夠考慮公司的現實情況，不切實際地期望測試工具能夠改變公司的現狀，從而導致了失敗。
例如，許多軟件公司是針對最終用戶進行一次性的項目開發，而不是產品開發。項目開發周期短，不同的用戶需求不一樣，而且在整個開發過程中需求和用戶界面變動較大，這種情況下就不適合引入功能測試工具，因為需求、界面變化比較大，測試腳本的開發和維護工作量很大，而腳本的復用頻率不高，從而導致投入產出率很低，不但不能減輕工作量，反而加重了測試人員的負擔。
新書資訊