軟件測試與維護(hù)基礎(chǔ)

“十三五”高等職業(yè)教育規(guī)劃教材

軟件測試與維護(hù)基礎(chǔ)

周之昊劉熱主編

陳忱張海越辛振國孫振亞副主編

內(nèi)容簡介

本書吸取了課程建設(shè)成果，總結(jié)多位教師教學(xué)經(jīng)驗(yàn)，全面系統(tǒng)地介紹了軟件測試的概念、過程、

方法及相關(guān)工具。全書共9章，前4章以理論介紹為主，從理論角度討論軟件測試的概念和技術(shù)；后

5章以實(shí)踐練習(xí)為主，從實(shí)踐角度介紹軟件測試的應(yīng)用和工具的使用。前一部分內(nèi)容主要包含軟件測

試基礎(chǔ)概念、軟件測試流程、軟件測試崗位能力要求、黑盒測試技術(shù)、白盒測試技術(shù)、測試的組織與

管理、軟件維護(hù)等。后一部分內(nèi)容主要包括黑盒測試方法的綜合應(yīng)用，單元測試工具JUnit在Android

開發(fā)中的應(yīng)用，自動(dòng)化測試工具UTF在Web系統(tǒng)測試中的使用，負(fù)載測試工具LoadRunner在性能

測試中的使用，應(yīng)用程序生命周期管理工具QC在軟件測試管理中的使用。

本書內(nèi)容全面、層次清晰、難易可控，可根據(jù)不同的教學(xué)要求及教學(xué)方向，有選擇地實(shí)施教學(xué)。

本書適合作為高等職業(yè)院校相關(guān)專業(yè)軟件測試課程的教材或參考用書，同時(shí)也可以供從事軟件開

發(fā)及測試工作的人員，以及對軟件測試有興趣的初學(xué)者參考學(xué)習(xí)。

圖書在版編目（CIP）數(shù)據(jù)

軟件測試與維護(hù)基礎(chǔ)/周之昊，劉熱主編.—北京：中國

鐵道出版社有限公司，2019.8

“十三五”高等職業(yè)教育規(guī)劃教材

ISBN978-7-113-26089-7

Ⅰ.①軟…Ⅱ.①周…②劉…Ⅲ.①軟件-測試-高等職業(yè)

教育-教材②軟件維護(hù)-高等職業(yè)教育-教材Ⅳ.①TP311.5

中國版本圖書館CIP數(shù)據(jù)核字(2019)第164164號

書名：軟件測試與維護(hù)基礎(chǔ)

作者：周之昊劉熱

策劃：包寧編輯部電話2067

責(zé)任編輯：包寧翟玉峰

封面設(shè)計(jì)：劉穎

責(zé)任校對：張玉華

責(zé)任印制：郭向偉

出版發(fā)行：中國鐵道出版社有限公司（100054，北京市西城區(qū)右安門西街8號）

網(wǎng)址：/51eds/

印刷：北京銘成印刷有限公司

版次：2019年8月第1版2019年8月第1次印刷

開本：850mm×1168mm1/16印張：19字?jǐn)?shù)：484千

書號：ISBN978-7-113-26089-7

定價(jià)：49.90元

版權(quán)所有侵權(quán)必究

凡購買鐵道版圖書，如有印制質(zhì)量問題，請與本社教材圖書營銷部聯(lián)系調(diào)換。電話：（010）63550836

打擊盜版舉報(bào)電話：（010）51873659

PREFACE前言

根據(jù)中國調(diào)研報(bào)告網(wǎng)發(fā)布的《2019年中國軟件測試行業(yè)現(xiàn)狀研究分析與市場前景預(yù)測報(bào)告》顯

示，軟件測試企業(yè)以非外包公司為主，其中傳統(tǒng)IT企業(yè)、互聯(lián)網(wǎng)企業(yè)數(shù)量占比超過50%，軟件測試

企業(yè)對軟件測試的重視度越來越高。

隨著對軟件測試的重視，企業(yè)測試人員與開發(fā)人員比由早些年的1∶7升至1∶3左右，這說明

軟件行業(yè)的測試?yán)砟钜寻l(fā)生轉(zhuǎn)變，對專業(yè)測試的重視程度逐步加強(qiáng)。而且比例近年還在持續(xù)緩慢上

升，也體現(xiàn)出在未來幾年國內(nèi)企業(yè)對這種人員配比傾向度較高。同時(shí)隨著軟件業(yè)的發(fā)展，測試的需

求也越來越大，軟件測試也由原來的人工測試向自動(dòng)化測試方向發(fā)展，這不僅可以大大地提高測試

效率，還能使測試人員從反復(fù)枯燥的測試工作中解放出來，使得測試人員可以把精力放在系統(tǒng)測試

的整體大局上。

軟件測試崗位到2018年之后，其發(fā)展相對較為穩(wěn)定，但是人才缺口依然很大。產(chǎn)生這種現(xiàn)象的

原因主要有兩方面：

1．軟件在未來一段時(shí)間內(nèi)仍會(huì)較快發(fā)展。由于軟件企業(yè)要靠產(chǎn)品及產(chǎn)品服務(wù)去占領(lǐng)市場，開發(fā)

出來的軟件需要軟件開發(fā)部門和軟件測試部門的合作才能保證產(chǎn)品質(zhì)量，產(chǎn)品符不符合客戶的需求，

能不能實(shí)現(xiàn)所需訴求，需不需要長期維護(hù)，都需要測試人員去驗(yàn)證。測試人員可謂是一個(gè)軟件企業(yè)

生存的守護(hù)神，測試這關(guān)過不了，做出來的產(chǎn)品也是廢品。

2．軟件測試發(fā)展越來越快，人才缺口也越來越大，同時(shí)對測試人員的能力要求也越來越高。以

前很多測試人員由于知識儲(chǔ)備不成體系，技術(shù)掌握也不穩(wěn)固，只能應(yīng)對一些簡單的測試工作，但是

隨著軟件行業(yè)的發(fā)展，企業(yè)更多需要的是技術(shù)層級相對以往更高的人才。

本書編者均在一線從事教學(xué)工作近十年，深感找一本適合的教材頗為不易。目前市場上關(guān)于軟

件測試技術(shù)及測試用例設(shè)計(jì)方面的書籍雖然較多，但主要以基礎(chǔ)理論講解為主，與實(shí)踐結(jié)合的內(nèi)容

偏少，未能對初學(xué)者實(shí)踐能力的提高有太多幫助。而另一些書籍主要受眾面偏向于在軟件測試領(lǐng)域

有一定實(shí)踐經(jīng)驗(yàn)，在軟件測試崗位有一定工作年限的專業(yè)人員，對于學(xué)生或有興趣的初學(xué)者來說，

雖然有大量實(shí)踐內(nèi)容的教學(xué)，但又感覺很陌生、太深?yuàn)W、沒有著力感，很多知識點(diǎn)介紹得又過于簡

略。為解決這一問題，并將編者教學(xué)工作中積累的些許經(jīng)驗(yàn)回饋更多的學(xué)習(xí)者，于是就產(chǎn)生了編

寫本書的想法。

本書從學(xué)生和教師的角度出發(fā)，將理論和實(shí)踐結(jié)合起來，選材適當(dāng)，重點(diǎn)突出，并注重體系結(jié)構(gòu)

I

的完整性。本書從最基本的知識點(diǎn)開始，配以經(jīng)典實(shí)用的案例，比較全面系統(tǒng)地介紹了軟件測試的

概念、過程、方法及相關(guān)工具。通過相關(guān)測試?yán)碚撝R與實(shí)踐技能的學(xué)習(xí)，層層深入地培養(yǎng)學(xué)生的

軟件測試能力。

經(jīng)過兩年多的醞釀和準(zhǔn)備，歷時(shí)近一年的時(shí)間，本書初稿基本成形。本書由周之昊、劉熱任主

編，陳忱、張海越、辛振國、孫振亞任副主編。其中，周之昊負(fù)責(zé)第1章、第2章2.1節(jié)和2.3節(jié)、

第5章的編寫，并負(fù)責(zé)全書的統(tǒng)稿；劉熱負(fù)責(zé)第7章、第8章和第9章的編寫，并負(fù)責(zé)全書的總體

設(shè)計(jì)；陳忱負(fù)責(zé)第2章2.2節(jié)和第6章的編寫；張海越負(fù)責(zé)第3章的編寫；辛振國負(fù)責(zé)第4章的編

寫；孫振亞負(fù)責(zé)全書材料的整理和修訂。

無錫科技職業(yè)學(xué)院物聯(lián)網(wǎng)與軟件技術(shù)學(xué)院領(lǐng)導(dǎo)趙航濤、閭立新、陳曉男等對本書編寫給予了關(guān)

心和指導(dǎo)；物軟學(xué)院相關(guān)專業(yè)的全體師生試用了本書的校本教材，并提出了不少寶貴建議和修改意

見，在此向他們表示感謝。同時(shí)，還要感謝書后參考文獻(xiàn)的作者，感謝他們的文獻(xiàn)給予本書的指導(dǎo)。

最后感謝所有編者的家人，沒有他們的支持，也很難在這段時(shí)間內(nèi)完成本書。

讀者在學(xué)習(xí)的過程中，可以在軟件測試網(wǎng)（/）、CSDN程序員網(wǎng)

（/）、百度百科（/）和百度文庫（http://

/）等網(wǎng)站檢索相關(guān)資料。

書中所涉及的微課視頻是相關(guān)內(nèi)容的補(bǔ)充，以方便讀者理解和掌握知識點(diǎn)或操作，僅供參考使

用。

由于編者水平有限，時(shí)間倉促，書中不妥之處在所難免，敬請各位讀者批評指正。如有反饋意

見和建議，請發(fā)送至編者電子郵箱86164585@，謝謝！

編者

2019年6月

II

CONTENTS目錄

2.1.7功能圖法····································75

第1章軟件測試基礎(chǔ)····························12.1.8其他黑盒測試方法·····················77

2.1.9黑盒測試方法的比較與選擇·······83

1.1軟件測試基本概念·······························1

2.2白盒測試技術(shù)····································83

1.1.1軟件測試的定義···························1

2.2.1覆蓋方式····································84

1.1.2軟件測試的重要性·······················3

2.2.2覆蓋深度····································84

1.1.3軟件測試的原則···························4

2.2.3測試方法····································85

1.1.4軟件測試的分類···························6

2.2.4實(shí)施方法····································85

1.1.5軟件測試的過程模型·················13

2.2.5基本路徑測試·····························86

1.1.6軟件測試的過程改進(jìn)模型··········17

2.2.6循環(huán)測試····································86

1.1.7軟件測試與軟件質(zhì)量保證··········23

2.2.7白盒測試綜合案例·····················87

1.2軟件測試的流程································27

2.3白盒與黑盒測試的比較·····················90

1.2.1測試流程概述·····························27

2.3.1策略及方法對比·························90

1.2.2測試用例·····································28

2.3.2黑盒測試與白盒測試之爭··········91

1.2.3測試環(huán)境·····································33

小結(jié)····························································92

1.2.4測試缺陷·····································35

習(xí)題與思考·················································92

1.2.5測試報(bào)告·····································39

1.3測試崗位能力要求·····························43第3章測試的跟蹤與管理···················94

1.3.1測試崗位需求·····························44

1.3.2職位描述·····································453.1缺陷的生命周期································94

1.3.3職業(yè)技能要求·····························473.2管理測試內(nèi)容····································96

1.3.4職業(yè)素養(yǎng)要求·····························483.2.1測試計(jì)劃····································96

小結(jié)·····························································493.2.2測試組織····································99

習(xí)題與思考·················································503.2.3缺陷管理··································101

3.3測試管理工具簡介··························108

第2章軟件測試技術(shù)··························513.3.1軟件缺陷報(bào)告和跟蹤···············108

3.3.2Bugzilla的安裝和使用·············109

2.1黑盒測試技術(shù)····································51

3.3.3建設(shè)高效測試團(tuán)隊(duì)···················123

2.1.1等價(jià)類劃分法·····························53

小結(jié)··························································125

2.1.2邊界值分析法·····························59

習(xí)題與思考···············································125

2.1.3決策表分析法·····························65

2.1.4因果圖法·····································68第4章軟件維護(hù)·······························127

2.1.5正交試驗(yàn)法·································72

2.1.6場景法·········································734.1軟件維護(hù)概述··································127

I

軟件測試與維護(hù)基礎(chǔ)

4.1.1軟件維護(hù)定義···························1275.7.4基于因果圖法的用例設(shè)計(jì)········162

4.1.2軟件維護(hù)類型···························1275.7.5基于錯(cuò)誤推測法的用例

4.2軟件維護(hù)的特點(diǎn)······························129設(shè)計(jì)··········································167

4.2.1結(jié)構(gòu)化維護(hù)與非結(jié)構(gòu)化5.7.6基于正交試驗(yàn)法的用例

維護(hù)差別巨大···························129設(shè)計(jì)··········································170

4.2.2維護(hù)的代價(jià)高昂·······················1305.7.7基于場景法的用例設(shè)計(jì)···········173

4.2.3維護(hù)的問題很多·······················130小結(jié)··························································179

4.3軟件維護(hù)過程··································131習(xí)題與思考···············································179

4.3.1維護(hù)組織···································131JUnit單元測試與Android

第章

4.3.2維護(hù)報(bào)告···································1316

測試·······································180

4.3.3維護(hù)的工作流程·······················132

6.1JUnit概述········································180

4.3.4保存軟件維護(hù)文檔···················133

6.1.1JUnit3與JUnit4的

4.3.5評價(jià)維護(hù)活動(dòng)···························133

主要區(qū)別··································180

4.4······························134

軟件的可維護(hù)性6.1.2JUnit4常用Annotation

4.4.1決定軟件可維護(hù)性的因素········134

介紹···········································183

4.4.2文檔··········································135

6.2使用JUnit進(jìn)行項(xiàng)目測試················185

4.4.3可維護(hù)性復(fù)審···························136

6.2.1自動(dòng)售賣機(jī)項(xiàng)目概述···············185

4.4.4提高軟件的可維護(hù)性···············136

6.2.2項(xiàng)目代碼··································185

4.5······································138

預(yù)防性維護(hù)6.2.3測試類創(chuàng)建向?qū)Р僮鞑襟E········188

4.6······························138

軟件再工程過程6.2.4自動(dòng)售賣機(jī)項(xiàng)目測試···············190

小結(jié)···························································140

6.3AndroidJUnit測試··························194

···············································141

習(xí)題與思考6.3.1AndroidJUnit概述···················194

6.3.2創(chuàng)建虛擬機(jī)·······························195

第5章管理系統(tǒng)的功能測試··············143

6.3.3封裝類測試·······························197

5.1測試準(zhǔn)備··········································1436.3.4輸入操作測試···························208

5.2測試計(jì)劃··········································1456.3.5位置測試··································213

5.3功能測試用例的設(shè)計(jì)·······················1466.4單元測試框架··································218

5.4用例執(zhí)行的竅門······························147小結(jié)··························································218

5.5功能測試的三步曲···························148習(xí)題與思考···············································218

5.6查找遺漏問題的七大招···················149

第章基于的功能測試

5.7測試用例設(shè)計(jì)··································1507UFT············220

5.7.1基于等價(jià)類劃分法的

7.1自動(dòng)化功能測試工具UFT的

用例設(shè)計(jì)···································150

介紹·················································220

5.7.2基于邊界值分析法的

7.2訂票系統(tǒng)的介紹······························221

用例設(shè)計(jì)···································157

7.3基于訂票系統(tǒng)的測試設(shè)計(jì)···············222

5.7.3基于決策表法的用例設(shè)計(jì)········160

7.3.1開發(fā)測試腳本···························222

II

目錄

7.3.2創(chuàng)建共享對象存儲(chǔ)庫···············2258.6運(yùn)行負(fù)載測試··································260

7.3.3創(chuàng)建函數(shù)和函數(shù)庫···················2328.7分析測試結(jié)果··································264

7.3.4增加步驟···································234小結(jié)··························································271

7.4運(yùn)行及分析基于訂票系統(tǒng)的習(xí)題與思考···············································271

測試··················································241

第章基于的測試用例管理

7.4.1運(yùn)行測試腳本···························2419QC·······272

7.4.2查看及分析測試結(jié)果···············242

9.1測試管理工具QC的介紹···············272

···························································243

小結(jié)9.2創(chuàng)建版本和周期······························276

···············································243

習(xí)題與思考9.3定義需求··········································277

基于LoadRunner的9.4定義測試計(jì)劃··································282

第8章

負(fù)載測試································2459.5運(yùn)行測試··········································286

8.1性能測試工具LoadRunner9.6跟蹤缺陷··········································291

簡介··················································2459.7分析數(shù)據(jù)··········································293

8.2旅游網(wǎng)站系統(tǒng)的介紹·······················249小結(jié)··························································294

8.3創(chuàng)建腳本··········································251習(xí)題與思考···············································295

8.4回放腳本··········································254

參考文獻(xiàn)···············································296

8.5創(chuàng)建負(fù)載測試場景···························258

III

第1章軟件測試基礎(chǔ)

第1章

軟件測試基礎(chǔ)

視頻

學(xué)習(xí)目標(biāo)：

1．了解軟件測試的概念。

2．理解軟件測試在軟件開發(fā)過程中的作用。

3．理解軟件測試的流程。

4．理解軟件測試的分類、原則、策略。課程導(dǎo)言

5．了解軟件測試行業(yè)的發(fā)展?fàn)顩r。

1.1軟件測試基本概念

為什么要測試？最主要的目的有兩個(gè)：一是對質(zhì)量或可接受性作出評判，二是發(fā)現(xiàn)存在的問題。

之所以要測試，是因?yàn)槿私?jīng)常會(huì)出錯(cuò)，特別是在軟件領(lǐng)域和采用軟件控制的系統(tǒng)中，這個(gè)問題尤為

突出。本章的目標(biāo)是給出軟件測試的基本全貌，而本書的其他各章都將圍繞這個(gè)目標(biāo)展開。

1.1.1軟件測試的定義

IEEE1983給出的“軟件測試”定義是：使用人工或自動(dòng)手段來運(yùn)行或測試某個(gè)系統(tǒng)的過程，

其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。它是幫助識別開

發(fā)完成（中間或最終的版本）的計(jì)算機(jī)軟件（整體或部分）的正確度（Correctness）、完全度

（Completeness）和質(zhì)量（Quality）的軟件過程；是軟件質(zhì)量保證（SoftwareQualityAssurance，SQA）

的重要子域。

該定義基本反映了軟件測試的重點(diǎn)與難點(diǎn)，表明軟件測試需要進(jìn)行過程管理，包含靜態(tài)測試和

動(dòng)態(tài)測試，分為人工測試和自動(dòng)化測試。軟件測試的主要工作是設(shè)計(jì)測試用例，執(zhí)行測試用例和分

析測試用例結(jié)果，也就是發(fā)現(xiàn)缺陷、記錄缺陷和報(bào)告缺陷的過程。

在IEEE計(jì)算機(jī)學(xué)會(huì)（IEEEComputerSociety）職業(yè)實(shí)踐委員會(huì)（ProfessionalPracticesCommittee）

《軟件工程知識體系指南2004版》中給出的定義對上述定義進(jìn)行了補(bǔ)充。其定義和解釋如下：

測試是為評價(jià)與改進(jìn)產(chǎn)品質(zhì)量、標(biāo)識產(chǎn)品的缺陷和問題而進(jìn)行的活動(dòng)。

軟件測試是由一個(gè)程序的行為在有限測試集合上，針對期望的行為的動(dòng)態(tài)驗(yàn)證組成，測試用例

是從通常的無限執(zhí)行域中適當(dāng)選取的。

在以上定義中，有幾個(gè)與軟件測試知識相關(guān)的關(guān)鍵問題，具體說明如下。

1

軟件測試與維護(hù)基礎(chǔ)

1．動(dòng)態(tài)

動(dòng)態(tài)意味著測試總是隱含在經(jīng)過評價(jià)的輸入中執(zhí)行程序，更確切地講，輸入值本身并不能充分

地確定一個(gè)測試，因?yàn)橐粋€(gè)復(fù)雜的、非確定性的系統(tǒng)可能對相同的輸入作出不同的反應(yīng)行為，這取

決于系統(tǒng)的狀態(tài)。盡管在這個(gè)知識域中，“輸入”這個(gè)術(shù)語在需要它的情況下繼續(xù)使用，并有隱含的

約定：其含義也包括一個(gè)特定的輸入狀態(tài)。靜態(tài)技術(shù)與動(dòng)態(tài)不同，并作為動(dòng)態(tài)技術(shù)的補(bǔ)充。

2．有限

即使是簡單的程序，理論上也有很多的測試用例，需要若干年或若干月才能完成窮舉測試。因

此，在實(shí)踐中，一般認(rèn)為整個(gè)測試集合是有限的。測試總是隱含了有限的資源和進(jìn)度與無限的測試

需求之間的權(quán)衡。

3．選取

人們提出的許多測試技術(shù)，本質(zhì)上的區(qū)別在于如何選取測試集合，軟件工程師必須意識到，不

同的選擇標(biāo)準(zhǔn)可能產(chǎn)生差別很大的效果。在給定條件下，如何標(biāo)識最適當(dāng)?shù)倪x擇準(zhǔn)則是一個(gè)復(fù)雜的

問題。在實(shí)踐中，需要使用風(fēng)險(xiǎn)分析技術(shù)和測試技能。

4．期望

確定觀察的程序所執(zhí)行的輸出是否可被接受，這盡管不容易但也必須是可能的，否則測試工作

就無用了。觀察到的結(jié)果可以與用戶的期望對比（確認(rèn)測試），與規(guī)格說明對比（驗(yàn)證測試），與隱

含的需求的期望行為或合理的期望對比。

在許多測試方面的文獻(xiàn)中，名詞術(shù)語的使用都比較混亂，究其原因，可能是因?yàn)闇y試技術(shù)在近

幾十年中不斷地演化進(jìn)步，而且文獻(xiàn)作者所處領(lǐng)域存在差異。首先來研究幾個(gè)有用的術(shù)語。

錯(cuò)誤（error）：人會(huì)做錯(cuò)事。錯(cuò)誤的同義詞是過失（mistake）。編程時(shí)出的錯(cuò)稱為“Bug”。錯(cuò)

誤很容易傳遞和放大，比如需求分析方面的錯(cuò)誤在系統(tǒng)設(shè)計(jì)時(shí)有可能會(huì)被放大，而且在編碼

時(shí)還會(huì)被進(jìn)一步放大。

故障（fault）：故障是錯(cuò)誤的后果。更確切地說，故障是錯(cuò)誤的具體表現(xiàn)形式，比如文字?jǐn)⑹觥?/p>

數(shù)據(jù)流圖、層次結(jié)構(gòu)圖、源代碼等。與把編程錯(cuò)誤稱為Bug類似，故障的同義詞是缺陷（defect）。

故障可能難以捕獲。比如，設(shè)計(jì)人員犯下一個(gè)遺漏錯(cuò)誤，所導(dǎo)致的故障可能只是在表現(xiàn)上丟

掉了一些應(yīng)有的內(nèi)容。這里也可以把故障進(jìn)一步細(xì)分為過失故障和遺漏故障。如果在表象中

添加了不正確的信息，這是過失故障，而未輸入正確的信息，則是遺漏故障。在這兩類故障

中，遺漏故障更難檢測和糾正。

失效（failure）：發(fā)生故障會(huì)導(dǎo)致失效。失效具有兩個(gè)很微妙的特征：①失效只出現(xiàn)在程序的

可執(zhí)行表現(xiàn)形式中，通常是源代碼，確切地說是加載后的目標(biāo)代碼；②這樣定義的失效只和

過失故障有關(guān)。那么如何處理遺漏故障所對應(yīng)的失效呢？進(jìn)一步說，對于不輕易發(fā)生的故障，

或者長期不發(fā)生的故障，情況又會(huì)怎樣呢？米開朗基羅（Michelangelo）病毒就是這種故障的

一個(gè)例子，它只有在3月6日（米開朗基羅生日）才執(zhí)行。采用代碼評審能夠通過查找故障

來避免失效。實(shí)際上，好的代碼評審?fù)瑯幽軝z查出遺漏故障來。

事故（incident）：失效發(fā)生時(shí)，用戶（或客戶和測試人員）可能察覺得到，也可能察覺不到。

事故是與失效相關(guān)聯(lián)的癥狀，它警示用戶有失效發(fā)生。

測試（test）：測試顯然要考慮到錯(cuò)誤、故障、失效和事故等諸多問題。測試是利用測試用例

2

第1章軟件測試基礎(chǔ)

來操作軟件的活動(dòng)。測試有兩個(gè)明確目標(biāo)：找出失效問題和證實(shí)軟件執(zhí)行的正確性。

測試用例（testcase）：每個(gè)測試用例都有一個(gè)用例標(biāo)識，并與程序的行為密切相關(guān)。每個(gè)測

試用例還包括若干輸入和期望輸出。

1.1.2軟件測試的重要性

從開發(fā)角度，軟件測試可以盡早發(fā)現(xiàn)和改正軟件中潛在的錯(cuò)誤，不僅避免給用戶造成可能的損

失，更重要的是避免給開發(fā)方的信譽(yù)造成不良影響，即避免最終給開發(fā)方自己造成直接或間接的

損失。

對于用戶來說，適當(dāng)?shù)臏y試是用戶對是否接受軟件系統(tǒng)的依據(jù)，用戶通過親自的測試或者委托

第三方測試的結(jié)果來對軟件的質(zhì)量作出判斷，并最后作出選擇。

近年來，軟件缺陷給人們造成重大損失的例子數(shù)不勝數(shù)，表1-1簡要地列出了一些影響比較大

的事件，關(guān)于事件的完整故事，感興趣的讀者可以查閱相關(guān)資料。

表1-1典型的因?yàn)檐浖毕菰斐蓳p失的案例

事件時(shí)間原因后果

1金星探測器的飛行失敗1963程序語句中少了一個(gè)逗號損失1000多萬美元

2新西蘭客機(jī)撞山1979飛行軟件故障257名乘客全部罹難

3愛國者導(dǎo)彈事故1991計(jì)時(shí)器誤差誤殺28名美國士兵

4英特爾奔騰芯片缺陷1994浮點(diǎn)數(shù)除法算法缺陷支付4億美元更換芯片

5阿麗亞娜火箭爆炸1996慣性導(dǎo)航系統(tǒng)軟件故障9年的航天技術(shù)受重挫

6NASA火星登錄器1999集成測試不充分登錄器丟失損失3.27億美元

7千年蟲問題2000節(jié)省內(nèi)存年份縮為2位全球損失幾千億美元

8巴拿馬放射性設(shè)備醫(yī)療事故2000軟件設(shè)計(jì)存在缺陷因超劑量輻射死亡或致癌

9美國及加拿大停電2003電力管理系統(tǒng)故障大規(guī)模停電

10金山詞霸出現(xiàn)錯(cuò)誤2003系統(tǒng)安裝問題無法取詞，無法解釋

11“沖擊波”計(jì)算機(jī)病毒2003微軟MSN缺陷被攻破數(shù)萬Windows計(jì)算機(jī)崩潰

12Norton“誤殺門”2007將系統(tǒng)文件定義為病毒超百萬臺(tái)計(jì)算機(jī)癱瘓

13北京奧運(yùn)會(huì)售票事件2007大量訪問造成網(wǎng)絡(luò)擁堵無法售票

14F-16戰(zhàn)機(jī)失事2007導(dǎo)航軟件失靈飛機(jī)失事

15F-22機(jī)群系統(tǒng)癱瘓2008全球定位系統(tǒng)都失靈飛機(jī)群險(xiǎn)些失事

16Google的Gmail故障2009負(fù)載均衡軟件的BugGmail用戶不能訪問郵箱

17春運(yùn)黃牛倒票2014對身份證信息缺乏審核漏洞黃牛利用該漏洞倒票

軟件測試可以保證對需求和設(shè)計(jì)的理解與表達(dá)的正確性，實(shí)現(xiàn)的正確性以及運(yùn)行的正確性，因

為任何一個(gè)環(huán)節(jié)發(fā)生了問題都將在軟件測試中表現(xiàn)出來。同時(shí)測試還可防止由于無意識的行為而引

入的一些可能出現(xiàn)的錯(cuò)誤。例如，對一些功能進(jìn)行更改、分解或者擴(kuò)展時(shí)不小心引入的，也許就會(huì)

對整個(gè)程序功能造成不可預(yù)料的破壞。所以一旦發(fā)生了上面的情況，就需要對更新后的工作結(jié)果進(jìn)

3

軟件測試與維護(hù)基礎(chǔ)

行重新測試。如果測試沒有通過，則說明某個(gè)環(huán)節(jié)出現(xiàn)了問題。

軟件測試是軟件質(zhì)量保證的重要手段。在軟件開發(fā)總成本中，測試上的開銷要占30%～50%。如

果把維護(hù)階段也考慮在內(nèi)，整個(gè)軟件生命周期，開發(fā)測試的成本所占比例會(huì)有所降低，但維護(hù)工作

相當(dāng)于二次開發(fā)，乃至多次開發(fā)，其中也包含許多測試工作。因此，估計(jì)軟件工作有50%的時(shí)間和

50%以上的成本花費(fèi)在測試工作上。由此可見，要成功開發(fā)出高質(zhì)量的軟件產(chǎn)品，必須重視并加強(qiáng)軟

件測試工作。歸納起來，軟件測試的重要性表現(xiàn)如下幾方面：

（1）一個(gè)不好的測試程序可能導(dǎo)致任務(wù)的失敗，更重要的是可能影響操作的性能和可靠性，并

且可能導(dǎo)致在維護(hù)階段花費(fèi)巨大的成本。

（2）一個(gè)好的測試程序是項(xiàng)目成功的重要保證。復(fù)雜的項(xiàng)目在軟件測試和驗(yàn)證上需要花費(fèi)項(xiàng)目

一半以上的成本，為了使測試有效，必須事先在計(jì)劃和組織測試方面花費(fèi)適當(dāng)?shù)臅r(shí)間。

（3）一個(gè)好的測試程序可以極大地幫助定義需求和設(shè)計(jì)，這有助于項(xiàng)目在一開始就步入正軌，

測試程序的好壞對整個(gè)項(xiàng)目的成功有著重要的影響。

（4）一個(gè)好的測試可以使修改錯(cuò)誤的成本變得很低。

（5）一個(gè)好的測試可以彌補(bǔ)一個(gè)不好的軟件項(xiàng)目，有助于發(fā)現(xiàn)項(xiàng)目存在的許多問題。

1.1.3軟件測試的原則

（1）軟件測試應(yīng)追溯到用戶需求。軟件開發(fā)的最終目的是要滿足最終用戶的需求，軟件缺陷從

原始需求開始，經(jīng)歷需求分析、設(shè)計(jì)和編程階段逐步形成的過程，要完成對待測試軟件有效的測試，

測試人員要緊緊圍繞用戶需求，站在用戶角度看問題，系統(tǒng)中最嚴(yán)重的錯(cuò)誤是那些導(dǎo)致無法滿足用

戶需求的缺陷。用戶是軟件的使用者和投資者，不滿足用戶需求的軟件是無法順利交付和收回成

本的。

（2）軟件測試應(yīng)該盡早開始，不斷進(jìn)行。由于軟件的復(fù)雜性和抽象性，以及涉及項(xiàng)目人員之間

溝通不暢等原因，導(dǎo)致在軟件生命周期的各個(gè)階段都可能產(chǎn)生缺陷。軟件錯(cuò)誤發(fā)現(xiàn)得越早，修改錯(cuò)

誤的成本就越低，所以測試要從需求分析和設(shè)計(jì)就開始，在軟件開發(fā)的每個(gè)環(huán)節(jié)都要不斷地進(jìn)行測

試，才有可能使錯(cuò)誤不被遺漏。極限編程和測試驅(qū)動(dòng)的開發(fā)將“盡早開始，不斷進(jìn)行”用到極致，

它們強(qiáng)調(diào)測試先行，在編程開始之前就開始設(shè)計(jì)測試用例，用測試用例指導(dǎo)代碼的撰寫。

（3）窮盡測試是不可能的，測試要有停止準(zhǔn)則，適可而止。完美的情況下，通過在有限的時(shí)間

和資源下，窮盡運(yùn)行軟件，發(fā)現(xiàn)所有問題。但實(shí)際上是不可能的，這可以從軟件的基本要素——輸

入、輸出、數(shù)據(jù)處理和計(jì)算等方面來分析。因?yàn)槌绦蜉斎胍话愣挤浅４?，無法計(jì)數(shù)，輸出也很復(fù)雜，

有時(shí)甚至超過輸入的復(fù)雜度。數(shù)據(jù)處理和計(jì)算的復(fù)雜程度也越來越高，導(dǎo)致路徑組合近似天文數(shù)字。

因此，只能通過多種測試方式，在有限資源下，盡可能多地發(fā)現(xiàn)缺陷。測試停止準(zhǔn)則大致可以分為

5類：

①測試超過了預(yù)定時(shí)間。

②執(zhí)行了所有的測試用例，但并沒有發(fā)現(xiàn)故障。

③使用特定的測試用例設(shè)計(jì)方案作為判斷測試停止的基礎(chǔ)。

④正面指出停止測試具體要求，即查出某一預(yù)定數(shù)目的故障。

⑤根據(jù)單位時(shí)間內(nèi)查出故障的數(shù)量決定是否停止。

4

第1章軟件測試基礎(chǔ)

GoodEnough原則指出：測試的投入與產(chǎn)出要適當(dāng)權(quán)衡，測試進(jìn)行的不充分是對質(zhì)量不負(fù)責(zé)任的

表現(xiàn)，但是投入過多的測試，則是資源浪費(fèi)的表現(xiàn)。

（4）一個(gè)測試用例除了要對軟件的輸入數(shù)據(jù)進(jìn)行詳細(xì)描述，還要給出預(yù)期輸出結(jié)果。否則，在

測試過程中，極有可能因?yàn)闊o法與預(yù)期輸出進(jìn)行比對，而使應(yīng)該發(fā)現(xiàn)的錯(cuò)誤從眼皮底下溜走，降低

測試效果。

（5）程序員應(yīng)該避免測試自己的程序，軟件測試應(yīng)該具有一定的獨(dú)立性。待測試程序就好像程

序員自己生的孩子，怎么看怎么順眼，客觀上，程序員很難跳出自己的思維習(xí)慣，對自己編寫的程

序做出科學(xué)的測試。軟件測試應(yīng)該是“破壞性的”，以“找茬”為目的的，獨(dú)立的軟件測試才有可能

發(fā)現(xiàn)意外的錯(cuò)誤。而且軟件測試中存在一種“同化效應(yīng)”，即一名測試人員重復(fù)使用一個(gè)軟件而產(chǎn)生

熟悉感，因此可能會(huì)忽視一些易用性問題和用戶體驗(yàn)問題。同時(shí)測試人員與開發(fā)人員在一起工作時(shí)

間較久之后，容易被同化。同化效應(yīng)會(huì)使Bug具有免疫效果，因此，測試過程中還需要通過輪換或

補(bǔ)充新測試人員來避免此問題。

（6）應(yīng)該徹底檢查每個(gè)測試的結(jié)果。每個(gè)測試用例一般都是經(jīng)過精心設(shè)計(jì)產(chǎn)生的，承擔(dān)一定的

檢測任務(wù)。由于測試執(zhí)行結(jié)果可以形式多樣，如界面的顯示、數(shù)據(jù)文件以及性能測試中關(guān)注的軟件

執(zhí)行時(shí)間等，不同形式的結(jié)果對于判斷測試是否通過具有不同程度的影響。而且軟件測試的預(yù)期輸

出描述可能不是很準(zhǔn)確，這就更需要認(rèn)真檢查每個(gè)測試結(jié)果。

（7）測試用例的編寫不僅應(yīng)該包括有效合法和預(yù)料到的輸入情況，還要考慮無效非法和未預(yù)料

的輸入情況。程序員往往基于預(yù)料之中的合法輸入編寫程序進(jìn)行處理，可能忽視對一些非法輸入或

意料之外的輸入的處理，從而使程序留下隱患。

（8）不僅要檢查程序是否“做了它應(yīng)該做的”，而且要檢查程序是否“做了它不應(yīng)該做的”。程

序只能做被規(guī)定的那些工作，任何多余的功能都應(yīng)被視為安全隱患。全面的測試包括：驗(yàn)證程序是

否做了應(yīng)該做的事情，以確保軟件的可靠性；驗(yàn)證程序是否沒有做不應(yīng)該做的事情，以確保軟件的

安全性。

（9）測試用例要進(jìn)行管理和保存，切忌用后即棄，要重視測試過程的記錄并保存相關(guān)文檔。除

了一次性軟件，幾乎所有的軟件測試都不可能一次性完成，在軟件生命周期中一般都要經(jīng)過測試、

修改、再測試、再修改等多次反復(fù)。原先的測試用例可以為再測試的選擇性復(fù)生、生成新測試用例

和測試分析等提供非常好的依據(jù)和基礎(chǔ)，避免重復(fù)勞動(dòng)，特別是在回歸測試中，要使用原有的測試

用例檢查修改是否引入新的錯(cuò)誤。

（10）程序中的錯(cuò)誤存在“集群現(xiàn)象”。程序中如果某處發(fā)現(xiàn)錯(cuò)誤，在該處和周圍還可能存在錯(cuò)

誤，有人甚至認(rèn)為：“程序中某部分存在錯(cuò)誤的可能性，與該處已發(fā)現(xiàn)錯(cuò)誤的數(shù)量成正比”。人們也

用“冰山原理”和“二八原理”來定性程序中錯(cuò)誤的分布。所謂“冰山原理”就是兩座冰山，露出

水面部分大的那一座，其水下部分也較大?！岸嗽怼眮碜陨鐣?huì)學(xué)觀點(diǎn)“20%的富人掌握了80%的

社會(huì)財(cái)富，其他80%的人只占有20%的社會(huì)財(cái)富”，在軟件工程中有“20%的代碼包含了軟件中80%

的缺陷”，“20%的缺陷消耗了80%的軟件修改維護(hù)費(fèi)”。

（11）選擇一組合適的測試方法。軟件系統(tǒng)的不同部分具有不同的特點(diǎn)和不同的重要程度，

需要不同的測試方法才能充分、有針對性地測試。因此，在測試過程中選擇合適的測試方法也非

常重要。

（12）測試應(yīng)該認(rèn)真做好測試計(jì)劃，使用測試清單。測試計(jì)劃和清單列出所有需要測試的對象、

5

軟件測試與維護(hù)基礎(chǔ)

場景和條件列表，提供了一種確定測試覆蓋率的方法，并可以作為軟件測試質(zhì)量和軟件質(zhì)量的依據(jù)。

測試過程中，切忌測試的隨意性。

（13）恰當(dāng)使用測試工具。工具可以延伸認(rèn)知能力，很多測試工作，如測試數(shù)據(jù)的生成，測試結(jié)

果的比對，如果手工完成，既累人又容易出錯(cuò)。測試工具的正確使用不僅能夠有效地提高測試效率，

而且也可以提高正確率，使測試人員有更多精力從事創(chuàng)造性測試工作。

（14）不斷進(jìn)行培訓(xùn)。測試作為一門科學(xué)，和其他學(xué)科一樣，有著一套知識體系和特定的技能要

求。另外，根據(jù)一些測試人員執(zhí)行的測試類型，甚至還需要特殊的或先進(jìn)的知識和技能。測試人員

只有不斷地進(jìn)行培訓(xùn)或自我學(xué)習(xí)，才能適應(yīng)測試工作中遇到的新挑戰(zhàn)。

（15）進(jìn)行軟件風(fēng)險(xiǎn)分析，做有重點(diǎn)的測試。由于不可能進(jìn)行窮盡測試，某種意義上，測試了什

么比測試了多少更重要。軟件風(fēng)險(xiǎn)分析可以對測試對象進(jìn)行優(yōu)先級排序，這樣合理分配測試資源，

集中精力對軟件系統(tǒng)中的關(guān)鍵部分進(jìn)行充分測試。

（16）度量測試有效性，對出錯(cuò)結(jié)果進(jìn)行統(tǒng)計(jì)和分析。使用科學(xué)的度量可以使測試工作更加科

學(xué)。對于各種測試方法有效性的度量，可以幫助人們選擇有效的測試方法；對于測試人員測試效果

的度量，可以幫助人們判斷哪些測試人員更有工作潛力。

（17）分析缺陷趨勢和模式。缺陷之間往往存在一些相互關(guān)聯(lián)和依賴關(guān)系，通過分析測試缺陷的趨

勢、模式、類型、來源、嚴(yán)重程度和潛伏期等，可以進(jìn)一步發(fā)覺一些新的問題，從中找到需要改進(jìn)的

地方。同時(shí)對測試過程中找到的所有缺陷進(jìn)行定性分析和預(yù)測，已決定是否進(jìn)入下一個(gè)測試階段。

（18）增量和分階段測試。測試范圍應(yīng)從小規(guī)模開始，逐步轉(zhuǎn)向大規(guī)模的增量和分級的測試。所

謂小規(guī)模是指測試的顆粒度，如某種程度的單元測試，進(jìn)一步的測試從單元測試逐步過渡到多個(gè)單

元的組合測試，即集成測試，最終過渡到系統(tǒng)測試。

（19）軟件測試是一項(xiàng)極富能力創(chuàng)造性、極具智力挑戰(zhàn)性的工作。不僅測試一個(gè)大型軟件所需要

的創(chuàng)造性很可能超過了開發(fā)該軟件所需的創(chuàng)造性，而且要充分測試一個(gè)軟件以確保所有錯(cuò)誤都不存

在是不可能的。因此，這就給軟件測試的從業(yè)人員留下了開闊的創(chuàng)造性空間，并使軟件測試成為一

門職業(yè)。

（20）軟件測試是一種服務(wù)。軟件測試人員通過對軟件產(chǎn)品進(jìn)行研究和探索，獲取有關(guān)軟件的信

息，供項(xiàng)目決策者作出正確的決定。特別是敏捷開發(fā)中，軟件測試指引著團(tuán)隊(duì)的工作。把軟件測試

理解成一種服務(wù)可以化解測試人員和開發(fā)人員之間的矛盾，從而有利于客觀公正地進(jìn)行測試工作。

1.1.4軟件測試的分類

1．按測試階段劃分

按照測試的階段可以將軟件測試分為單元測試、集成測試、確認(rèn)測試、系統(tǒng)測試和驗(yàn)收測試。

測試過程流程如圖1-1所示。

1）單元測試

單元測試是對軟件測試設(shè)計(jì)中最小的單位——程序模塊進(jìn)行的測試，它著重檢查程序單元是否

符合軟件詳細(xì)設(shè)計(jì)規(guī)約中對于模塊功能、性能、接口和設(shè)計(jì)約束等方面的要求，發(fā)現(xiàn)各模塊內(nèi)部可

能存在的各種錯(cuò)誤。由于程序模塊間應(yīng)該具有低耦合、高內(nèi)聚的特性，所以單元測試一般是可以并

行進(jìn)行的。

6

第1章軟件測試基礎(chǔ)

圖1-1測試過程流程

2）集成測試

集成測試是在單元測試的基礎(chǔ)上，將已通過單元測試的各個(gè)模塊有序地、遞增地進(jìn)行測試，它

著重發(fā)現(xiàn)各模塊接口之間的關(guān)系和相互協(xié)作中是否存在錯(cuò)誤。在很多情況下，已通過單元測試的模

塊集成到系統(tǒng)中往往還存在問題，就是由于它沒能正確地與其他模塊協(xié)作，或者出現(xiàn)了接口錯(cuò)誤。

集成測試依據(jù)的標(biāo)準(zhǔn)是軟件概要設(shè)計(jì)規(guī)約。

3）確認(rèn)測試

確認(rèn)測試是通過檢驗(yàn)和提供客觀證據(jù)，驗(yàn)證軟件是否滿足特定預(yù)期用途的需求。它依據(jù)軟件需

求規(guī)格說明書，包括用戶對軟件的功能、性能和某種特定特性的要求。如果說前兩種測試主要是驗(yàn)

證軟件是否在“正確地做事”，那么確認(rèn)測試主要是驗(yàn)證軟件是否在“做正確的事”。

4）系統(tǒng)測試

系統(tǒng)測試是將通過已確認(rèn)的軟件，作為整個(gè)基于計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外圍

設(shè)備、網(wǎng)絡(luò)和系統(tǒng)軟件、某些主應(yīng)用軟件、插件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實(shí)際

運(yùn)行環(huán)境下，檢測其是否能夠進(jìn)行正確的配置、連接，以滿足用戶需求。系統(tǒng)測試一般依據(jù)系統(tǒng)需

求規(guī)格說明書。

5）驗(yàn)收測試

驗(yàn)收測試是指按照項(xiàng)目說明書、合同、軟件供需雙方約定的驗(yàn)收依據(jù)文檔等進(jìn)行的對整個(gè)系統(tǒng)

的測試和評審，決定是否接受或拒絕接受系統(tǒng)。該階段測試也是被傳統(tǒng)軟件測試過程所采用，有時(shí)

也把確認(rèn)測試和系統(tǒng)測試歸為一個(gè)過程，統(tǒng)稱為系統(tǒng)測試。

2．按是否需要執(zhí)行被測試軟件劃分

按照是否需要執(zhí)行被測試軟件，可將軟件測試分為靜態(tài)測試和動(dòng)態(tài)測試。

1）靜態(tài)測試

靜態(tài)測試又稱靜態(tài)分析，是指不實(shí)際運(yùn)行被測試軟件，而是直接分析軟件的形式和結(jié)構(gòu)來查找

缺陷。主要包括對源代碼、程序界面和各類文檔及之間產(chǎn)品（如產(chǎn)品說明書、技術(shù)設(shè)計(jì)文檔等）所

做的測試。

（1）對于源代碼：

查看源代碼是否符合相應(yīng)的標(biāo)準(zhǔn)和規(guī)范，如可讀性、可維護(hù)性等，其工作過程類似于一個(gè)編譯

器，隨著語法分析的進(jìn)行做特定工作，如分析模塊調(diào)用圖、程序的控制流圖等圖表以及度量軟件的

7

軟件測試與維護(hù)基礎(chǔ)

代碼質(zhì)量等。一般各公司內(nèi)部都有自己相應(yīng)的編碼規(guī)范，如C/C++/Java編碼規(guī)范等，應(yīng)按照規(guī)范中

所列出的條目逐條測試。

源代碼中含有大量原設(shè)計(jì)信息，以及程序員異常的信息。利用靜態(tài)測試，不僅可以發(fā)現(xiàn)程序中

明顯的缺陷，還可以幫助程序員重點(diǎn)關(guān)注那些可能存在缺陷的高風(fēng)險(xiǎn)模塊，如多出口、程序較復(fù)雜、

接口過多等情況。

當(dāng)然，對源代碼進(jìn)行靜態(tài)測試并非易事，可以使用一些自動(dòng)化的靜態(tài)分析工具來降低測試人員

的勞動(dòng)強(qiáng)度。目前市面上有很多靜態(tài)分析工具，如Parasoft公司的dotTest、C/C++Test、JTest，JetBrains

公司的IntelliJIDEA、PyCharm等。這些靜態(tài)分析工具一般由4部分組成：語言程序預(yù)處理器、數(shù)據(jù)

庫、錯(cuò)誤分析器和報(bào)告生成器。

其具有如下優(yōu)點(diǎn)：①測試人員直接面對的是問題