軟件測試基礎教材

軟

件

測

試

基

礎

教

材

目錄

第一章軟件測試的概述1

1.1軟件的相關知識概述1

1.1.1軟件的含義1

1.1.2軟件的生存周期1

1.1.3軟件測試的生命周期3

1.2軟件質(zhì)量保證4

1.2.1軟件質(zhì)量保證(SQA)的定義4

122SQA的目標4

1.2.3SQA的任務4

1.2.4SQA與軟件測試的關系5

1.3為什么需要測試6

1.3.1軟件系統(tǒng)的重要性6

1.3.2測試和質(zhì)量6

13.3測試是否充分7

1.3.4測試在軟件生命周期中所擔當?shù)慕巧?

1.4軟件缺陷與軟件故障7

1.4.1軟件缺陷的定義和類型7

1.4.2軟件缺陷產(chǎn)生的原因8

1.4.3軟件缺陷的構成9

1.5軟件測試的定義9

1.5.1軟件測試的概念9

1.5.2軟件測試的目的9

1.5.3軟件測試的原則10

1.5.4軟件測試的任務10

1.5.5軟件測試的職責10

1.6軟件測試用例設計11

1.6.1軟件測試用例的基本概念和用途11

1.6.2編制測試用例的規(guī)范12

1.63測試用例的設計技術及原則13

1.7軟件測試工程師的職業(yè)素養(yǎng)15

1.7.1軟件測試工程師的工作15

1.7.2軟件測試工程師的職業(yè)素質(zhì)16

第二章組織和管理測試團隊18

2.1測試團隊的任務和比例18

2.1.1測試團隊的任務18

2.1.2測試人員與開發(fā)人員的比例18

2.2測試團隊的構成和職責19

2.2.1測試團建的基本構成19

2.2.2測試人員的職責19

2.3測試團隊的管理和發(fā)展21

23.1樹立良好的測試團隊意識21

2.3.2激勵測試團隊的方法22

II

2.3.3從PSP到TSP再到CMM23

2.3.4知識共享和崗位培訓25

笫三章黑盒常用測試方法26

3.1等價類劃分法26

3.1.1等價類的數(shù)學定義26

3.1.2劃分等價類26

3.1.3等價類劃分的原則26

3.1.4等價類劃分法設計測試用例的步驟27

3.1.5等價類劃分的類型27

3.1.6用等價類劃分法解決一個實例29

3.1.7等價類劃分法小結30

3.2邊界值分析法30

321邊界值分析法概要30

3.2.2邊界值分析法的原則31

3.2.3確定邊界值分析法取值原則的幾種方法31

3.2.4邊界值分析法的目標33

3.2.5邊界值分析法設計測試用例的步驟33

3.2.6用邊界值分析法解決一個實例33

3.2.7邊界值分析法小結34

3.3因果圖法34

3.3.1因果圖法的來源34

332因果圖法的特點34

3.3.3原因之間的約束關系35

3.3.4結果之間的約束關系35

3.3.5原因和結果之間的關系35

3.3.6如何根據(jù)因果圖轉(zhuǎn)換為判定表36

3.3.7因果圖法設計測試用例的步驟36

3.3.8用因果圖法解決一個實例36

3.3.9因果圖法小結39

3.4錯誤推測法39

3.4.1借識推測法的概念39

3.4.2錯誤推測方法的基本思想39

3.43錯誤推測法設計測試用例的步驟40

3.4.4用錯誤推測法解決一個實例40

3.4.5錯誤推測法小結40

3.5場景法40

3.5.1場景法介紹40

3.5.2用例場景的定義41

3.5.3為什么引入用例場景41

3.5.4場景法設計測試用例的步驟41

3.5.5用場景法解決一個實例42

3.5.6場景法小結46

第四章使用黑盒測試方法編寫測試用例46

4.1規(guī)貝I]46

III

4.2階段劃分46

4.3階段目標47

4.4課后作業(yè)47

第五章功能性測試的測試方法一47

5.1軟件故障模型48

5.1.1故障模型簡介48

5.1.2故障模型框架48

5.2輸入非法數(shù)據(jù)48

5.2.1示例48

522缺陷產(chǎn)生的原因49

5.2.3發(fā)現(xiàn)這類問題的方法49

5.2.4小結49

5.3輸入默認值50

5.3.1示例50

5.3.2缺陷產(chǎn)生的原因51

5.3.3發(fā)現(xiàn)這類問題的方法52

5.3.4小結52

5.4輸入特殊字符52

5.4.1示例52

5.4.2缺陷產(chǎn)生的原因52

5.4.3發(fā)現(xiàn)這類問題的方法53

5.4.4小結53

5.5輸入使緩沖區(qū)溢出的數(shù)據(jù)54

5.5.1示例54

552缺陷產(chǎn)生的原因54

5.53發(fā)現(xiàn)這類問題的方法54

5.5.4小結55

5.6輸入產(chǎn)生錯誤的合法數(shù)據(jù)組合55

5.6.1示例55

5.6.2缺陷產(chǎn)生的原因56

S.6.3發(fā)現(xiàn)這類問題的方法56

5.6.4小結57

5.7產(chǎn)生同一個輸入的各種可能輸出57

5.7.1示例57

5.7.2缺陷產(chǎn)生的原因57

5.73發(fā)現(xiàn)這類問題的方法57

5.7.4小結57

5.8產(chǎn)生不符合業(yè)務規(guī)則的無效輸出57

5.8.1示例57

5.8.2缺陷產(chǎn)生的原因58

5.8.3發(fā)現(xiàn)這類問題的方法58

5.8.4小結58

第六章功能性測試的測試方法編寫測試用例一59

6.1規(guī)則59

6.2階段劃分59

6.3階段目標59

6.4課后作業(yè)60

第七章功能性測試的測試方法二60

7.1輸出屬性修改后的結果60

7.1.1示例60

7.1.2缺陷產(chǎn)生的原因60

7.1.3發(fā)現(xiàn)這類問題的方法61

7.1.4小結61

7.2頁面刷新61

7.2.1示例61

7.2.2缺陷產(chǎn)生的原因61

7.23發(fā)現(xiàn)這類問題的方法61

7.2.4小結62

7.3數(shù)據(jù)溢出62

7.3.1示例62

7.3.2缺陷產(chǎn)生的原因62

7.3.3發(fā)現(xiàn)這類問題的方法62

7.3.4小結63

7.4數(shù)據(jù)不符合約束條件63

7.4.1示例63

7.4.2缺陷產(chǎn)生的原因63

7.4.3發(fā)現(xiàn)這類問題的方法63

7.4.4小結64

7.5操作符導致的問題64

7.5.1示例64

7.5.2缺陷產(chǎn)生的原因64

7.53發(fā)現(xiàn)這類問題的方法64

7.5.4小結64

7.6遞歸調(diào)用自身65

7.6.1示例65

7.6.2缺陷產(chǎn)生的原因65

7.63發(fā)現(xiàn)這類問題的方法65

7.6.4小結65

7.7計算結果溢出65

7.7.1示例65

7.7.2缺陷產(chǎn)生的原因66

7.73發(fā)現(xiàn)這類問題的方法66

7.7.4小結66

7.8數(shù)據(jù)共享或關聯(lián)功能計算出錯66

7.8.1示例66

7.8.2缺陷產(chǎn)生的原因67

7.8.3發(fā)現(xiàn)這類問題的方法67

7.8.4小結68

V

第八章功能性測試的測試方法編寫測試用例二68

8.1規(guī)貝I」68

8.2階段劃分68

8.3階段目標68

8.4課后作業(yè)69

第九章功能性測試的測試方法三69

9.1文件系統(tǒng)超載69

9.1.1示例69

9.1.2缺陷產(chǎn)生的原因69

9.1.3發(fā)現(xiàn)這類問題的方法70

9.1.4小結70

9.2介質(zhì)忙或不可用70

9.2.1示例70

9.2.2缺陷產(chǎn)生的原因71

9.2.3發(fā)現(xiàn)這類問題的方法71

9.2.4小結71

9.3介質(zhì)損壞72

9.3.1示例72

9.3.2缺陷產(chǎn)生的原因72

9.33發(fā)現(xiàn)這類問題的方法72

9.3.4小結72

9.4介質(zhì)名不合法72

9.4.1示例72

9.4.2缺陷產(chǎn)生的原因72

9.4.3發(fā)現(xiàn)這類問題的方法73

9.4.4小結73

9.5設置介質(zhì)訪問權限73

9.5.1示例73

9.5.2缺陷產(chǎn)生的原因74

9.5.3發(fā)現(xiàn)這類問題的方法74

9.5.4小結74

9.6文件內(nèi)容損壞74

9.6.1示例74

962缺陷產(chǎn)生的原因75

9.63發(fā)現(xiàn)這類問題的方法75

9.6.4小結75

第十章功能性測試的測試方法編寫測試用例三75

10.1規(guī)則75

10.2階段劃分76

10.3階段目標76

10.4課后作業(yè)77

第十一章功能和界面的測試方法一77

11.1控件測試77

11.1.1文本框的測試77

11.1.2按鈕的測試79

11.1.3單選按鈕的測試80

11.1.4復選框的測試81

11.1.5列表框的測試82

11.1.6組和列表框的測試83

11.1.7up-down控件文本框的測試84

11.1.8滾動條的測試86

11.1.9控件混合使用的測試87

第十二章功能和界面的測試方法編寫測試用例一89

12.1規(guī)則89

12.2階段劃分90

12.3階段目標90

12.4課后作業(yè)91

第十三章功能和界面的測試方法二91

13.1功能測試用例91

13.1.1編輯操作91

13.1.2插入操作92

13.1.3鼠標操作94

13.2界面測試用例95

13.2.1窗體95

13.2.2控件98

13.2.3菜單99

13.2.4特殊屬性100

13.2.5界面設計的總體原則101

第十四章功能和界面的測試方法編寫測試用例二101

14.1規(guī)則101

14.2階段劃分102

14.3階段目標102

14.4課后作業(yè)102

第十五章安裝卸載測試方法103

15.1安裝卸載測試用例103

15.1.1安裝測試103

15.1.2運行測試106

15.1.3卸載測試107

15.1.4加密測試108

第十六章兼容性和易用性測試方法110

16.1設計兼容性測試用例110

16.1.1示例110

16.1.2產(chǎn)生的原因110

16.1.3解決方法111

16.2設計易用性測試用例116

16.2.1易用性測試的內(nèi)容116

16.2.2界面的標準119

第十七章缺陷管理121

VII

17.1軟件缺陷的描述121

17.2軟件缺陷的基本組成121

17.3軟件缺陷的屬性122

17.3.1軟件bug的標識123

17.3.2軟件bug的類型123

17.3.3軟件bug嚴重程度123

17.3.4軟件bug優(yōu)先級123

17.3.5軟件bug狀態(tài)124

17.3.6軟件bug管理常用的工具Bugzilla124

第十八章使用缺陷管理系統(tǒng)136

18.1規(guī)則136

18.2階段劃分136

18.3階段目標136

18.4課后作業(yè)138

第十九章軟件測試計劃與測試策略138

19.1軟件測試計劃138

19.1.1測試計劃規(guī)格說明138

19.1.2制定測試計劃的目的139

19.1.3制定測試計劃的作用139

19.1.4制定測試計劃139

19.2軟件測試策略142

19.2.1測試策略的概念142

19.2.2影響測試策略的因素142

19.2.3確定測試策略142

19.3風險分析147

19.3.1軟件風險分析148

19.3.2如何進行風險分析148

19.3.3計劃風險與應急措施154

第二十章制定軟件測試計劃154

20.1規(guī)則154

20.2階段劃分154

20.3階段目標154

20,4課后作業(yè)154

第二十一章軟件測試的流程155

21.1軟件測試流程155

21.1.1產(chǎn)品調(diào)研155

21.1.2測試需求說明156

21.1.3測試的策略和記錄156

21.1.4測試資源配置156

21.1.5時間計劃表156

21.1.6搭建測試環(huán)境156

21.1.7設計測試用例157

21.1.8跟蹤缺陷157

21.1.9測試計劃評審158

VIII

第二十二章編寫缺陷報告161

22.1規(guī)則161

22.2階段劃分161

22.3階段目標162

22.4上機提示162

22.5課后作業(yè)162

第二十三章軟件評審技術162

23.1軟件評審的目的162

23.2評審的度量及應用163

23.2.1軟件評審的角色和職能163

23.2.2軟件評審流程163

23.2.3評審類型163

2文檔評審164

3過程評審164

23.2.4評審方法和技術165

23.3小結166

第二十四章軟件測試經(jīng)驗166

24.1測試人員的服務對象166

24.2測試人員關注失效，客戶才能關注成功167

24.3什么是“完備的”測試167

24.4能事不關己高高掛起嗎168

24.5怎樣看待直覺168

24.6關于規(guī)格說明書168

24.7”它沒有問題”的真正含義169

24.8怎樣快速產(chǎn)生測試思路169

24.9是自己的報告成為一種有效的銷售工具170

24.10缺陷報告代表的是測試人員170

24.11努力使缺陷報告更有價值171

24.12永遠不要假設明顯的程序缺陷已經(jīng)寫入報告171

24.13隱藏在缺陷背后的安全隱患171

24.14明確嚴重登記和優(yōu)先級的差別172

24.15通過現(xiàn)象看本質(zhì)172

24.16編寫缺陷報告的幾條經(jīng)驗性原則172

24.17使用冒煙測試檢驗版本173

24.18設計測試計劃要結合實際情況173

24.19正確認識測試文檔模板173

IX

第一章軟件測試的概述

1.1軟件的相關知識概述

1.1.1軟件的含義

軟件（英語：Software）是一系列按照特定順序組織的電腦數(shù)據(jù)和指令的集合。

一般來說軟件被劃分為編程語言、系統(tǒng)軟件、應用軟件和介于這兩者之間的中間件。其

中系統(tǒng)軟件為計算機使用提供最基本的功能，但是并不針對某一特定應用領域。而應用軟件

則恰好相反，不同的應用軟件根據(jù)用戶和所服務的領域提供不同的功能。

軟件并不只是包括可以在計算機上運行的電腦程序，與這些電腦程序相關的文檔，一般

也被認為是軟件的一部分。簡單的說，軟件就是程序加文檔的集合體。軟件被應用于世界的

各個領域，對人們的生活和工作都產(chǎn)生了深遠的影響。

其中：

?程序是按事先設計的功能和性能要求執(zhí)行的指令序列。

?文檔是與程序開發(fā)、維護和使用有關的圖文材料。

1.1.2軟件的生存周期

軟件生命周期（SDLC,SystemsDevelopmentLifeCycle,SDLC）是軟件的產(chǎn)生直到報廢或停止使

用的生命周期。

周期內(nèi)有問題定義、可行性分析、總體描述、系統(tǒng)設計、編碼、調(diào)試和測試、驗收與運

行、維護升級到廢棄等階段，這種按時間分層的思想方法是軟件工程中的一種思想原則，即

按部就班、逐步推進，每個階段都要有定義、工作、審查、形成文檔以供交流或備查，以提

高軟件的質(zhì)量。但隨著新的面向?qū)ο蟮脑O計方法和技術的成熟，軟件生命周期設計方法的指

導意義正在逐步減少。

?瀑布模型

瀑布模型是將軟件生命周期的各項活動規(guī)定為依照固定順序連接的若干階段工作，形如瀑布

流水（如下圖所示），最終得到軟件產(chǎn)品。在每一個階段結束時，項目小組進行審查，并決

定是否進入下一步。

1

?螺旋模型

1988年，BarryBoehm正式發(fā)表了軟件系統(tǒng)開發(fā)的“螺旋模型”，它將瀑布模型和快速原型

模蟄結合起來，強調(diào)了其他模型所忽視的風險分析，特別適合于大型復雜的系統(tǒng)。

?迭代模型

迭代式模型是RUP（RationalUn而edProcess,統(tǒng)一軟件開發(fā)過程，統(tǒng)一軟件過程）推薦的周

期模型。在RUP中，迭代被定義為：迭代包括產(chǎn)生產(chǎn)品發(fā)布（穩(wěn)定、可執(zhí)行的產(chǎn)品版本）

的全部開發(fā)活動和使用該發(fā)布必需的所有其他外圍元素。

所以，在某種程度上，開發(fā)迭代是一次完整地經(jīng)過所有工作流程的過程：（至少包括）

需求工作流程、分析設計工作流程、實施工作流程和測試工作流程。實質(zhì)上，它類似小型的

瀑布式項目。RUP認為，所有的階段（需求及其它）都可以細分為迭代。每一次的迭代都會

產(chǎn)生一個可以發(fā)布的產(chǎn)品，這個產(chǎn)品是最終產(chǎn)品的一個子集。

2

迭代

第一次送代第二次迭代??????第N次迭代

強

信求分析中

弱//\,，0

強_____?、上

7

項目計劃中—

1

弱/9丁

強:

播要設計中一:-7

弱T—

/

強1

詳細設計中1

-/1N

弱-"廣*-,

9P

強—

編同及單元4試中1-H

11

弱B1

強11

/f

集成測試中■一

j1

弱Y■-11

1

強一；r1

系統(tǒng)溯試中

X7

弱7\}'

1.1.3軟件測試的生命周期

通過學習軟件生命周期的瀑布模型、螺旋模型以及迭代模型，可以了解軟件產(chǎn)品開發(fā)的

基本過程。那么，軟件測試的生命周期又是什么樣子？如下圖所示，展示了軟件測試的生命

周期。

0始一）

需求調(diào)研

/^\通

過

＜性評＞-T準備:段

制定測試一

不通過

＜評審J＞—T

不通過過

執(zhí)行測試

調(diào)優(yōu)階段”

WJuLi/

（結束）-報告階段y［達標）＞~

3

實踐證明，盡管人們在開發(fā)軟件的過程中使用了許多保證軟件質(zhì)量的方法和技術，但開

發(fā)出的軟件中還會隱藏許多錯誤和缺陷。規(guī)模大、復雜性高的軟件更是如此。所以。嚴格的

軟件測試對于保證軟件質(zhì)量具有重要作用。

1.2軟件質(zhì)量保證

1.2.1軟件質(zhì)量保證(SQA)的定義

軟件質(zhì)量保證(SQA-So代wareQualityAssurance)是建立一套有計劃，有系統(tǒng)的方法，來向

管理層保證擬定出的標準、步驟、實踐和方法能夠正確地被所有項目所采用。

軟件質(zhì)量保證的目的是使軟件過程對于管理人員來說是可見的。它通過對軟件產(chǎn)品和活

動進行評審和審計來驗證軟件是合乎標準的。軟件質(zhì)量保證組在項目開始時就一起參與建立

計劃、標準和過程。這些將使軟件項目滿足機構方針的要求。

1.2.2SQA的目標

?遵循《軟件質(zhì)量保證計劃》進行軟件質(zhì)量保證活動；

?客觀地驗證軟件開發(fā)過程和軟件產(chǎn)品是否遵守可用的標準、規(guī)程和要求：

?確保將軟件質(zhì)量保證的活動和結果通知受影響的項目組和人員；

?高層管理者關注在軟件項目中不能解決的偏差事件和不合格項。

1.2.3SQA的任務

?SQA參與制定計劃

SQA參與制定計劃包括SDP和階段計劃，在SDP活動中，SQA主要是參與到軟件過程

的剪裁、復審估算、參與評估風險等。然后，SQA參與復審SDP,其目的，除了熟悉項目的

計劃外，還需要復審查看是否SDP與納入項目的客戶的需求一致，計劃能否滿足客戶的需

求的，在SDP修正中，涉及到上述內(nèi)容的，也需要SQA參與。然后，SQA也會參與階段計

劃的制定，主要是復審階段計劃是否滿足階段的目標。

?SQA參與復審納入項目的需求

此時SQA主要是作為嵬審者的角色,第審納入的需求描述是否清晰、一致、需求的可

行性等。

?SQA制定SQA審計計劃

在制定計劃的同時，SQA也需要制定SQA審計計劃，在制定SDP的時候，SQA制高層

的審計計劃，主要是計劃有那些內(nèi)容需要SQA審計的。然后，在制定階段計劃的時候，SQA

需要制定具體的審計計劃，包括每次審計的時間，審計的對象等。

?SQA參與進度復審或里程碑復審活動

SQA在參與進度復審或里程碑復審活動中，主要是一方面了解項目的進度，另一方面,

復審項目在進度復審中采取的一些修正行動的時候，是否滿足客戶的需求，是否可行等，而

在里程碑復審中，則復審項目當前的狀態(tài)是否滿足里程碑的標準(CriteriaofMilestone),是否

達到里程碑的目標。

?SQA審計

另外，SQA的主要活動是按照制定的SQA審計計劃對項目進行審計，審計的內(nèi)容包括

過程審計和工作產(chǎn)品審計。過程審計主要是審計項目開展的軟件活動是否和計劃、與OSSP

4

一致，工作產(chǎn)品審計主要是審計工作產(chǎn)品是否滿足標準和約束條件。

?SQA階段總結

由于公司很多項目都是采用迭代模式的開發(fā)，項目開發(fā)周期較長，所以有必要在項目某

個階段結束的時候，對SQA在這個階段的活動進行一個總結，主要是對一些經(jīng)驗教訓進行

分析，找出這些問題背后的原因，提出一些可行性的解決方案，目的是為了提高質(zhì)量保證的

水平。

?跟蹤問題處理

SQA應跟蹤問題處理過程，直到問題解決。跟蹤的問題包括日常發(fā)現(xiàn)的產(chǎn)品問題、過程

問題、項目風險、評審發(fā)現(xiàn)的問題、測試發(fā)現(xiàn)的問題等。如果不能和項目組就解決方案達成

一致，可向公司高層反映。

?度量和報告

SQA應善于根據(jù)過程規(guī)范和經(jīng)驗發(fā)現(xiàn)項目運行中的問題，并做到緊急問題、重要問題隨

時匯報，其它問題周期性匯報.SQA需要隨時收集數(shù)據(jù)并保障數(shù)據(jù)的有效性、真實性。定期

匯總數(shù)據(jù)、統(tǒng)計分析并產(chǎn)生度量報告。SQA應協(xié)助項目組和SEPG針對不良趨勢和問題采取

糾正或預防措施。

?質(zhì)量推進

質(zhì)量推進主要包括提高全員的質(zhì)量意識和推進、解釋過程的執(zhí)行兩個方面。這項工作需

要在日常工作中循序漸進地、堅持不懈地實施，這樣做的目的是為了營造公司的一種質(zhì)量文

化氛圍，理解和支持SQA的工作。

?過程制定

如果項目或組織需要制定過程規(guī)范，SQA應組織相關人員來完成過程制定工作。一般情

況下，過程制定應由遵守和執(zhí)行該過程的人員負責。所有制定的過程都必須經(jīng)過評審，并由

SQA檢查執(zhí)行情況。

?過程改進

過程改進是一項長期的任務。SQA應注意隨時發(fā)現(xiàn)、聽取過程執(zhí)行中問題和改進工作的

方法，并進行階段性的總結（比如質(zhì)量報告等），以不斷改進過程，提高過程能力。

?學習和研究

SQA要不斷學習和研究，盡量保持與領域最新的知識、方法同步，找出提高產(chǎn)品質(zhì)量和

工作效率的方法與過程。學習的內(nèi)容主要包括管理領域和開發(fā)領域。管理領域包括質(zhì)量管理

（TQM、IS09000、CMM、RUP、MSF、XP等）、軟件度量（PSM、GQM、SPC、SixSigma）、

項目管理、配置管理等。開發(fā)領域包括需求工程、設計、編碼、測試等各階段的開發(fā)和管理

方法。

?質(zhì)量培訓

項目或組織需要時，SQA需要向相關人員進行質(zhì)量管理方面的培訓或咨詢。

1.2.4SQA與軟件測試的關系

軟件測試和軟件質(zhì)量保證是軟件質(zhì)量工程的兩個不同層面的工作。軟件測試只是軟件質(zhì)

量保證工作的一個重要環(huán)節(jié)。

軟件測試（SQC）是為使產(chǎn)品滿足質(zhì)量要求所采取的作業(yè)技術和活動，它包括檢驗、糾

正和反饋。比如SQC進行檢驗發(fā)現(xiàn)不良品后將其剔除，然后將不良信息反饋給相關部門采

取改善措施。因此SQC的控制范圍主要是在工廠內(nèi)部，其目的是防止不合格品投入、轉(zhuǎn)序、

出廠。確保產(chǎn)品滿足質(zhì)量要求及只有合格品才能交付給客戶。

軟件質(zhì)量保證（SQA）是為滿足顧客要求提供信任，即使顧客確信你提供的產(chǎn)品能滿足

他的要求。因此需從市場調(diào)查開始及以后的評審客戶要求、產(chǎn)品開發(fā)、接單及物料采購、進

5

料檢驗、生產(chǎn)過程控制及出貨、售后服務等各階段留下證據(jù)，證實工廠每一步活動都是按客

戶要求進行的。

1.3為什么需要測試

131軟件系統(tǒng)的重要性

計算機是由硬件和軟件組成，而操作系統(tǒng)就是基礎的軟件，它控制和管理計算機的軟硬

件資源，如果沒有它，硬件將是一堆廢鐵，除非你會用01代碼。其他的應用軟件就是所有

工作與生活中的主要或輔助工具，那么，計算機軟件的重要性包括哪些呢？

操作系統(tǒng)的作用主要體現(xiàn)在以下兩仝方面：管理系統(tǒng)中的各種資源，包括硬件資源和軟

件資源。

在計算機系統(tǒng)中，所有硬件部件（如CPU、存儲器、輸入/輸出設備等）稱為硬件資源；

而程序和數(shù)據(jù)等信息稱為軟件資源。

操作系統(tǒng)對每一種資源的管理都必須進行以下幾項工作：

?決定分配資源策略

包括選擇某種資源分配策略，決定誰有權限可以獲得這種資源，何時可以獲得，可以獲

得多少，如何退回資源等等。

?監(jiān)視資源

監(jiān)視資源包括需要知道該資源有多少，資源的狀態(tài)如何，它們都在哪里，誰在使用，可

供分配的又有多少，資源的使用歷史等等。

?回收資源

回收資源是指在使用者放棄某種資源之后，對該種資源進行善后處理，如果是可重復使

用的資源，則進行回收、整理，以備再次使用。

?分配資源

分配資源是指按照已決定的資源分配策略，對符合條件的申請者分配某種資源，并進行

相應的管理事務處理。

13.2測試和質(zhì)量

軟件測試和軟件質(zhì)量保證是軟件質(zhì)量工程的兩個不同層面的工作。軟件測試只是軟件質(zhì)

量保證工作的一個重要環(huán)節(jié)。

軟件測試是為使產(chǎn)品滿足質(zhì)量要求所采取的作業(yè)技術和活動，它包括檢驗、糾正和反饋。

比如軟件測試進行檢驗發(fā)現(xiàn)不良品后將其剔除，然后將不良信息反饋給相關部門采取改善措

施。因此軟件測試的控制范圍主要是在工廠內(nèi)部，其目的是防止不合格品投入、轉(zhuǎn)序、出廠。

確保產(chǎn)品滿足質(zhì)量要求及只有合格品才能交付給客戶。

軟件質(zhì)量保證是為滿足顧客要求提供信任，即使顧客確信你提供的產(chǎn)品能滿足他的要求。

軟件質(zhì)量保證的目的不是為了保證產(chǎn)品質(zhì)量，保證產(chǎn)品質(zhì)量是軟件測試的任務。

軟件質(zhì)量保證主要是提供確信。因此需對了解客戶要求開始至售后服務的全過程進行管

理。這就要求企業(yè)建立品管體系，制訂相應的文件規(guī)范各過程的活動并留下活動實施的證據(jù)，

以便提供信任。軟件測試和軟件質(zhì)量保證的主要區(qū)別前者是保證產(chǎn)品質(zhì)量符合規(guī)定，后者是

建立體系并確保體系按要求運作，以提供內(nèi)外部的信任。同時軟件測試和軟件質(zhì)量保證又有

相同點：即軟件測試和軟件質(zhì)量保證都要進行驗證，如軟件測試按標準檢測產(chǎn)品就是驗證產(chǎn)

品是否符合規(guī)定要求，軟件質(zhì)量保證的內(nèi)審，就是驗證體系運作是否符合標準要求。

6

測試并非像大家平時認知的那樣，不動腦,天天對著屏幕點鼠標，雖然做測試門檻不高，

但真正能做好做精，更需要正確的方法和勤奮的學習。

1.3.3測試是否充分

一個成功的測試包括兩個主要方面：一是軟件在所有的（或足夠多的）測試用例上是正

確的;二是測試用例是充分的，即軟件在測試用例上的表現(xiàn)能夠充分地反應軟件的總體表現(xiàn)。

軟件測試的充分性是從軟件在有限多個測試用例上的行為判斷軟件在所有輸入數(shù)據(jù)上

的行為的邏輯基礎。良好的軟件測試充分性準則應該具有如下基本性質(zhì)：

?空測試對任何軟件都是不充分的?？諟y試用例集意味著軟件未被測試。

?對任何軟件都存在有限的充分測試集合。因為測試必須在有限的時間內(nèi)完成，所以充分

的測試集合必須是有限的。這一性質(zhì)成為有限性。

?如果一個軟件系統(tǒng)在一個測試用例集合上的測試是充分的，那么再多測一些數(shù)據(jù)也應該

是充分的。這一性質(zhì)成為單調(diào)性。

?及時對軟件所有成分都進行了充分的測試，也并不意味著整個軟件的測試已經(jīng)充分了。

這一性質(zhì)稱為反復合性。

?即使對一個軟件系統(tǒng)整體的測試是充分的，也并不意味著軟件系統(tǒng)中各個成分都已經(jīng)充

分地得到了測試。這一性質(zhì)稱為反分解性。

?軟件測試的充分性應該與軟件的需求和軟件的實現(xiàn)都相關。

?軟件越復雜，需要測試的數(shù)據(jù)也越多。這一性質(zhì)成為復雜性。

?測試得越多，進一步測試所能得到的充分性增長就越少。

13.4測試在軟件生命周期中所擔當?shù)慕巧?/p>

在任何生命周期模型中，一個好的測試都應該具有下面幾個特點：

?每個開發(fā)活動都有相對應的測試活動；（開發(fā)需要測試來驗證）

?每個測試級別都有其特有的測試目標；

?對于每個測試級別，需要在相應的開發(fā)活動過程中進行相應的測試分析和設計；

?在開發(fā)生命周期中，測試員在文檔初稿階段就應該參與文檔的評審。

1.4軟件缺陷與軟件故障

1.4.1軟件缺陷的定義和類型

軟件缺陷（Defect）,常常又被叫做Bug。所謂軟件缺陷，即為計算機軟件或程序中存在

的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷。缺陷的存在會導致軟件產(chǎn)品

在某種程度上不能滿足用戶的需要。IEEE729-1983對缺陷有一個標準的定義：從產(chǎn)品內(nèi)部看,

缺陷是軟件產(chǎn)品開發(fā)或維護過程中存在的錯誤、毛病等各種問題：從產(chǎn)品外部看，缺陷是系

統(tǒng)所需要實現(xiàn)的某種功能的失效或違背。

軟件缺陷的表現(xiàn)形式不僅體現(xiàn)在功能的失效方面，還體現(xiàn)在其他方面。主要類型：

?軟件沒有實現(xiàn)產(chǎn)品規(guī)格說明所要求的功能模塊；

?軟件中出現(xiàn)了產(chǎn)品規(guī)格說明指明不應該出現(xiàn)的錯誤；

?軟件實現(xiàn)了產(chǎn)品規(guī)格說明沒有提到的功能模塊；

?軟件沒有實現(xiàn)雖然產(chǎn)品規(guī)格說明沒有明確提及但應該實現(xiàn)的目；

7

?軟件難以理解，不容易使用，運行緩慢，或從測試員的角度看，最終用戶會認為不好。

1.4.2軟件缺陷產(chǎn)生的原因

在軟件開發(fā)的過程中，軟件缺陷的產(chǎn)生是不可避免的。那么造成軟件缺陷的主要原因有

哪些？從軟件本身、團隊工作和技術問題等角度分析，就可以了解造成軟件缺陷的主要因素。

軟件缺陷的產(chǎn)生主要是由軟件產(chǎn)品的特點和開發(fā)過程決定的。主要有以下幾個方面：

從軟件本身角度考慮：

?需求不清晰，導致設計目標偏離客戶的需求，從而引起功能或產(chǎn)品特征上的缺陷。

?系統(tǒng)結構非常復雜，而又無法設計成一個很好的層次結構或組件結構，結果導致意想不

到的問題或系統(tǒng)維護、擴充上的困難；即使設計成良好的面向?qū)ο蟮南到y(tǒng)，由于對象、

類太多，很難完成對各種對象、類相互作用的組合測試，而隱藏著一些參數(shù)傳遞、方法

調(diào)用、對象狀態(tài)變化等方面問題。

?對程序邏輯路徑數(shù)據(jù)范圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯

誤。

?對一些實時應用，要進行精心設計和技術處理，保證精確的時間同步，否則容易引起時

間上不協(xié)調(diào)，不一致性帶來的問題。

?沒有考慮系統(tǒng)崩潰后的自我恢復或數(shù)據(jù)的異地備份、災難性恢復等問題，從而存在系統(tǒng)

安全性、可靠性的隱患。

?系統(tǒng)運行環(huán)境的復雜，不僅用戶使用的計算機環(huán)境千變?nèi)f化，包括用戶的各種操作方式

或各種不同的輸入數(shù)據(jù)，容易引起一些特定用戶環(huán)境下的問題；在系統(tǒng)實際應用中，數(shù)

據(jù)量很大。從而會引起強度或負載問題。

?由于通信端口多、存取和加密手段的矛盾性等，會造成系統(tǒng)的安全性或適用性等問題。

?新技術的采用，可能涉及技術或系統(tǒng)兼容的問題，事先沒有考慮到。

從團隊工作角度考慮：

?系統(tǒng)需求分析時對客戶的需求理解不清楚，或者和用戶的溝通存在一些困難。

?不同階段的開發(fā)人員相互理解不一致。例如，軟件設計人員對需求分析的理解有偏差,

編程人員對系統(tǒng)設計規(guī)格說明書某些內(nèi)容重視不夠，或存在誤解。

?對于設計或編程上的一些假定或依賴性，相關人員沒有充分溝通。

?項目組成員技術水平參差不齊，新員工較多，或培訓不夠等原因也容易引起問題。

從技術方面考慮：

?算法錯誤：在給定條件下沒能給出正確或準確的結果。

?語法錯誤：對于編譯性語言程序，編譯器可以發(fā)現(xiàn)這類問題；但對于解釋性語言程序，

只能在測試運行時發(fā)現(xiàn)。

?計算和精度問題：計算的結果沒有滿足所需要的精度。

?系統(tǒng)結構不合理、算法選擇不科學，造成系統(tǒng)性能低下。

?接口參數(shù)傳遞不匹配，導致模塊集成出現(xiàn)問題。

?從項目管理問題角度考慮：

?缺乏質(zhì)量文化，不重視質(zhì)量計劃，對質(zhì)量、資源、任務、成本等的平衡性把握不好，容

易擠掉需求分析、評審、測試等時間，遺留的缺陷會比較多。

?由于技術欠佳，系統(tǒng)分析時，對客戶的需求了解不透徹，或者和用戶的溝通存在一些困

難。

?開發(fā)周期短，需求分析、設計、編程、測試等各項工作不能完全按照定義好的流程來進

行，工作不夠充分，結果也就不完整。不準確，錯誤較多；周期短，還給各類開發(fā)人員

造成太大的壓力，引起一些人為的錯誤。

8

?開發(fā)流程不夠完善，存在太多的隨機性和缺乏嚴謹?shù)膬?nèi)審或評審機制，容易產(chǎn)生問題。

?文檔不完善，風險評估不足等。

1.4.3軟件缺陷的構成

軟件缺陷是由：屬性名稱、措述、缺陷標識(Identifier)構成的。缺陷標識是標記某個

缺陷的一組符號。每個缺陷必須有一個唯一的標識缺陷類型(Type),缺陷類型是根據(jù)缺陷

的自然屬性劃分的缺陷種類。缺陷嚴重程度(Severity)缺陷嚴重程度是指因缺陷引起的故

障對軟件產(chǎn)品的影響程度。缺陷優(yōu)先級(Priority)缺陷的優(yōu)先級指缺陷必須被修夏的緊急程

度。缺陷狀態(tài)(Status)缺陷狀態(tài)指缺陷通過一個跟蹤修復過程的進展情況。缺陷起源(Origin)

缺陷來源指缺陷引起的故障或事件第一次被檢測到的階段。缺陷來源(Source)缺陷來源指

引起缺陷的起因。缺陷根源(RootCause)缺陷根源指發(fā)生錯誤的根本因素。

1.5軟件測試的定義

1.5.1軟件測試的概念

在1979年出版的一本經(jīng)典著作《軟件測試藝術》中，對軟件測試進行了這樣的定義：

軟件測試就是“為了發(fā)現(xiàn)錯誤而執(zhí)行程序或者系統(tǒng)的過程”。這一定義明確了軟件測試的根

本目的是為了發(fā)現(xiàn)程序中的錯誤。Myers撰寫該著作的時期，軟件測試通常在軟件產(chǎn)品開發(fā)

的后期開始，主要目的就是尋找產(chǎn)品運行過程中的缺陷。因此，他對軟件測試所下的這一定

義被人們廣泛接受，反映了人們在當時對軟件測試所持的觀點。隨著這一定義被廣泛使用，

人們發(fā)現(xiàn)了定義中存在的不足。于是，1983年在IEEE提出的軟件工程標準術語中，調(diào)整了

對軟件測試的定義，即“使用人工或自動手段來運行或測試某個系統(tǒng)的過程，其目的在于檢

驗它是否滿足規(guī)定的需求或弄清預期結果與實際結果之間的差別二更新后的定義除吸收了

從前人們對軟件測試定義中的精華外，還明確指出，軟件測試作為保證軟件質(zhì)量的一個重要

手段，其主要任務是在已設計測試用例的基礎上檢驗軟件各個部分，以及整個系統(tǒng)是否正確、

完整地實現(xiàn)了預定的功能，以確保軟件質(zhì)量。今天，人們對軟件測試有了更進一步的認識,

從廣義上講，測試是指軟件產(chǎn)品生存周期內(nèi)所有的檢查、評審和確認活動。例如。設計評審、

單元測試、系統(tǒng)測試。從狹義上講，測試是對軟件產(chǎn)品質(zhì)量的檢驗和評價。它一方面檢查軟

件產(chǎn)品質(zhì)量中存在的質(zhì)量問題，同時對產(chǎn)品質(zhì)量進行客觀的評價。現(xiàn)代軟件開發(fā)領域的人多

數(shù)工作者都對測試有直觀的認識，最常見的看法如下：

?保證程序和相應的規(guī)范說明一致。

?發(fā)現(xiàn)軟件中的缺陷。

?確保軟件不做不必要的事情。

?確保系統(tǒng)合理地執(zhí)行。

?明確在系統(tǒng)失敗之前可以讓系統(tǒng)正常運行到何種程度。

?明確發(fā)布給用戶的系統(tǒng)中有哪些風險。

1.5.2軟件測試的目的

基于不同的立場，存在著兩種完全不同的測試目的。從用戶的角度出發(fā)，普遍希望通過

軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可接受該產(chǎn)品。從軟件開發(fā)者的角度出

發(fā)，則希望測試成為表明軟件產(chǎn)品中不存在錯誤的過程，驗證該軟件已正確地實現(xiàn)了用戶的

9

要求，確立人們對軟件質(zhì)量的信心。GrenfordJ.Myers曾對軟件測試的目的提出過以下觀點：

?測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程；

?好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案；

?成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。

換言之，測試的目的是想以最少的時間和人力，系統(tǒng)地找出軟件中潛在的各種錯誤和缺

陷。如果我們成功地實施了測試，我們就能夠發(fā)現(xiàn)軟件中的錯誤。測試的附帶收獲是，它能

夠證明軟件的功能和性能與需求說明相符合。實施測試收集到的測試結果數(shù)據(jù)為可靠性分析

提供了依據(jù)。測試不能表明軟件中不存在錯誤，它只能說明軟件中存在錯誤。

然而，這種觀點指出測試是以查找錯誤為中心，而不是為了演示軟件的正確功能。但是

只從字面意思理解，可能會產(chǎn)生誤導，認為發(fā)現(xiàn)錯誤是軟件測試的唯一目的，查找不出錯誤

的測試就是沒有價值的測試，實際上并非如此！

?測試并不僅僅是為了找出錯誤。通過分析錯誤產(chǎn)生的原因和錯誤的發(fā)生趨勢，可以幫助

項目管理者發(fā)現(xiàn)當前軟件開發(fā)過程中的缺陷，以便及時改進；

?這種分析也能幫助測試人員設計出有針對性的測試方法，改善測試的效率和有效性；

?沒有發(fā)現(xiàn)錯誤的測試也是有價值的，完整的測試是評定軟件質(zhì)量的一種方法。

1.5.3軟件測試的原則

?應當把“盡早地和不斷地進行軟件測試”作為軟件開發(fā)者的座右銘；

?測試用例應由測試輸入數(shù)據(jù)和對應的預期輸出結果這兩部分組成；

?程序員應避免檢查自己的程序；

?在設計測試用例時，應包括合理的輸入條件和不合理的輸入條件；

?充分注意測試中的群集現(xiàn)象。經(jīng)驗表明測試后程序中殘存錯誤數(shù)目與該程序中己發(fā)現(xiàn)的

錯誤數(shù)目成正比；

?嚴格執(zhí)行測試計劃，排除測試的隨意性；

?應當對每一個測試結果做全面檢查；

?妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護提供方便。

1.5.4軟件測試的任務

?根據(jù)軟件測試各個階段會有如下幾方面的任務：

?制定測試大綱；

?制作測試數(shù)據(jù)；

?單元測試（程序測試）；

?功能測試；

?性能測試；

?集成測試（子系統(tǒng)測試）；

?系統(tǒng)測試；

?驗收測試；

?寫出測試報告書；

?提交下一階段工作所需的系統(tǒng)運行、維護手冊的草案。

1.5.5軟件測試的職責

?根據(jù)軟件設計需求制定測試計劃，設計測試數(shù)據(jù)和測試用例；

10

?有效地執(zhí)行測試用例，提交測試報告；

?準確地定位并跟蹤問題，推動問題及時合理地解決；

?完成對產(chǎn)品的集成測試與系統(tǒng)測試，對產(chǎn)品的軟件功能、性能及其它方面的測試。

1.6軟件測試用例設計

1.6.1軟件測試用例的基本概念和用途

學員在學習過程中會遇到以下類似問題：不知道是否較全面地測試了所有內(nèi)容，測試的

覆蓋率無法衡量，對新版本的重復測試很難實施，存在大量冗余測試影響測試效率等。接下

來將采用編寫測試用例的方法解決以上提及的問題。

測試用例是指為實施測試而向被測試系統(tǒng)提供的輸入數(shù)據(jù)、操作或各種環(huán)境設置以及期

望結果的一個特定的集合。測試壓例控制軟件測試的執(zhí)行過程，它是對每個測試項目的進一

步實例化。換句話說，測試用例就是記下要進行什么測試，進行測試的具體步驟，以及測試

執(zhí)行是否正確的標準。測試用例來自于測試需求，它是對測試需求的一個細化，它是整個測

試的基礎，測試用例覆蓋系統(tǒng)的程度決定了測試的覆蓋程度。如果沒有測試用例，就只能按

照測試人員的心情進行測試了。

測試用例的編寫是個費時費力的事情,通常編寫測試用例的時間比實際執(zhí)行測試的時間

還要長。許多人對編寫測試用例的原因很不理解，他們認為功能測試只要對應著的需求或者

程序的菜單一項項地去測試就可以了，這樣寫來寫去很浪費時間，而且有沒有什么實際意義，

不如多花時間去執(zhí)行測試。其實編寫測試用例的好處主要表現(xiàn)在以下幾個方面：

?組織性：

編寫測試用例有利于測試的組織。在開始實施測試之前設計好測試用例?？梢员苊饷つ?/p>

測試，并可以提高測試效率。

?功能覆蓋：

測試用例可以確保功能不被遺漏。要確保所開發(fā)的軟件能讓最終用戶滿意，最好的辦法

就是明確闡述最終用戶的期望，對這些期望進行核實并確認其有效性，測試用例直接反

應了這些要核實的需求，令測試的實施重點突出、目的明確，以確保用戶需要的功能不

被遺漏。

?重復性：

在項目進行期間對不同軟件版本必須要多次重復執(zhí)行同樣的測試，以尋找新的軟件缺陷,

保證老的軟件缺陷已被修復。沒有測試用例光憑腦子不可能記住執(zhí)行了哪些測試用例及

執(zhí)行情況，這樣就很難重復原有的測試。

?跟蹤：

通過對測試用例的統(tǒng)計，例如統(tǒng)計執(zhí)行了多少測試用例？多少通過？多少失??？以確定

下一步測試的重點，缺陷多的模塊可以在后續(xù)的測試中重點進行測試。

?測試確認：

在少數(shù)高風險的測試中，例如醫(yī)療、航天等行業(yè)。不允許出現(xiàn)任何問題，必須證明卻是

按照計劃執(zhí)行了所有的測試用例。發(fā)布忽略了某些測試用例的軟件是十分危險的。通過

測試用例可以對測試過程進行有效的監(jiān)督，可以準確、有效地評估測試，并對測試是否

完成有個量化的結果。

11

1.6.2編制測試用例的規(guī)范

?對于每個功能，從類型1至類型N依次撰寫相應用例；

?對于不滿足要求的非常規(guī)類型，可以不寫相應的用例；

?對于邊界、空值、格式錯誤、溢出這幾個類型，一個功能如有多個數(shù)據(jù)項測試類型相同，

則可以放在一個用例里；

?測試用例均為最小的用例覆蓋要求：對于沒有提及的用例類型，根據(jù)業(yè)務需求情況，撰

寫相應用例；

?在測試過程中，輸入數(shù)據(jù)可在測試用例規(guī)定的范圍內(nèi)做一定變化。

常規(guī)的測試用例：

?對于一個功能一個模塊（頁面），每個數(shù)據(jù)項輸入或選中典型的取值，生成一個用例；

?對于一個功能多個模塊（頁面），多個模塊（頁面）一起生成一個用例；

?對于多個功能一個模塊（頁面），每個功能生成一個用例；

?每個功能操作需覆蓋，如刪除對話框點擊確定、取消分別生成2個用例步驟；

?輸入框測試，在允許范圍內(nèi)盡可能覆蓋多的字符類別，如中文、英文、數(shù)字等；

?對于每個功能點，必須通過一組（一個或多個）用例滿足其業(yè)務覆蓋：對于某條記錄的

每個狀態(tài)，對于能進行的每個操作，都生成一個用例（即對業(yè)務功能流程中的每個角色，

每個功能操作，生成一個用例）。

初始化的測試用例：

進入功能模塊（頁面）后，某些控件會初始化填入數(shù)據(jù)，生成一個用例確保所有的初始

數(shù)據(jù)正確。

邊界的測試用例：

?每個數(shù)據(jù)項，生成一個邊界用例（含最大、最小兩個邊界值）；

?字符串數(shù)據(jù)以字符串長度為計量單位；

?布爾值數(shù)據(jù)的所有取值都需測試；

?