軟件測試-課程筆記

軟件測試-課程筆記

.第1章軟件測試概述

?軟件測試的背景

?軟件的缺陷及其影響

?什么是軟件缺陷

?軟件缺陷就是軟件產(chǎn)品中所存在的問題，最終表現(xiàn)為用戶所需要的功能沒有完全實現(xiàn)，

不能滿足或不能全部滿足用戶的需求。

?從產(chǎn)品內(nèi)部看，軟件缺陷是軟件產(chǎn)品開發(fā)或維護過程中所存在的錯誤、誤差等各種問題。

?從外部看，軟件缺陷是系統(tǒng)所需要實現(xiàn)的某種功能的失效或違背。

?軟件缺陷的類型:

?(1)軟件未實現(xiàn)產(chǎn)品說明書要求的功能。

?(2)軟件出現(xiàn)了產(chǎn)品說明書不應(yīng)該出現(xiàn)的錯誤。

?(3)軟件實現(xiàn)了產(chǎn)品說明書未提到的功能。

?(4)軟件未實現(xiàn)產(chǎn)品說明書雖未明確提及但應(yīng)該實現(xiàn)的功能。

?(5)軟件難以理解、不易使用、運行緩慢—從測試員的角度看—最終用戶會

認(rèn)為不好。

?存在軟件缺陷的案例及影響

?(1)千年蟲問題(產(chǎn)生約1974年)

?(2)愛國者導(dǎo)彈防御系統(tǒng)(1991年)

?(3)英特爾奔騰浮點除法缺陷(1994年)

?(4)"沖擊波"病毒(2003年)

?(5)諾基亞手機平臺缺陷(2008年)

?軟件測試的產(chǎn)生與發(fā)展

?軟件測試的產(chǎn)生

?軟件缺陷產(chǎn)生的主要原因：

?(1)需求解釋有錯誤；

?(2)用戶定義錯誤；

?(3)需求記錄錯誤；

?(4)設(shè)計說明錯誤；

?(5)編碼說明有誤；

?(6)程序代碼有誤；

?(7)其他有誤，如：數(shù)據(jù)輸入等。

?軟件測試的發(fā)展

?(1)初級階段(1957-1971年)

?(2)發(fā)展階段(1972-1982年)

?(3)成熟階段(1983年至今)

?修復(fù)軟件缺陷的成本

?軟件開發(fā)過程是使用軟件工程的方法，在整個過程中，都有可能出現(xiàn)各種各樣的軟件缺

陷。

?隨著開發(fā)時間的推移，軟件缺陷修復(fù)成本呈倍數(shù)的增長。假如早在進行分析時發(fā)現(xiàn)相關(guān)

功能缺失，立即補上就可了，可以說付出的代價小得幾乎忽略不計.

?如果在發(fā)布時發(fā)現(xiàn)缺失某個功能，那么此時加上一個功能，相當(dāng)于重新開發(fā)一樣，這時

的修補費用可以說高許多。

?因此要盡早進行測試。

?軟件測試的基本概念

?軟件測試的定義

?軟件測試專家GJ.Myers早在1979年給軟件測試下定義

?軟件測試是為了發(fā)現(xiàn)錯誤而針對某個程序或系統(tǒng)的執(zhí)行過程。

?GJ.Myers給出與測試相關(guān)的三個要點

?(1)測試是為了證明程序有錯，而不是證明程序無錯誤；

?(2)一個好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；

?(3)一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。

?1990年，IEEE再次給出軟件測試的定義

?(1)在特定的條件下運行系統(tǒng)或構(gòu)件，觀察或記錄結(jié)果，對系統(tǒng)的某個方面做出評價；

?(2)分析某個軟件項以發(fā)現(xiàn)現(xiàn)存的和要求的條件之差別并評價此軟件項的特性。

?軟件測試用例

?軟件測試用例定義

?IEEE標(biāo)準(zhǔn)610(1990)給出的定義：

?測試用例是一組測試輸入、執(zhí)行條件和預(yù)期結(jié)果的集合,目的是要滿足一個特定的目標(biāo)，

比如執(zhí)行一條特定的程序路徑或檢驗是否符合一個特定的需求。

?測試用例的元素

?軟件測試設(shè)計的關(guān)鍵問題可以概括為5W1H

?Why

?為什么測試？對功能、性能、可用性、容錯性、安全性等測試，檢驗是否符合

相關(guān)要求。

?What

?測什么？測試的對象可以是文檔，代碼，圖表等。

?Where

?在哪里測？測試用例的環(huán)境，包括系統(tǒng)的硬件、軟件和網(wǎng)絡(luò)環(huán)境等。

?When

?什么時候測？測試用例所需的前提條件，盡早開始。

?Which

?什么數(shù)據(jù)？測試用例設(shè)計的各種數(shù)據(jù)。

?How

?如何執(zhí)行？結(jié)果怎樣？要據(jù)測試用例設(shè)計的步驟來執(zhí)行，最后進行結(jié)果比較，

確定是否一致。若一致才能通過測試。

?測試用例設(shè)計的基本原則

?從兩個層次考慮測試用例

?（1）低層次

?從單個測試用例看，衡量其描述的規(guī)范性、可理解性及可維護性條等

?（2）高層次

?以滿足某一個測試目標(biāo)或測試任務(wù)來衡量一組測試用例的結(jié)構(gòu)、設(shè)計思路和覆

蓋率等；

?測試用例的基本原則

?（1）代表性

?測試用例能代表并覆蓋各種合法的或不合法、邊界內(nèi)的或越界的以及極限的輸

入數(shù)據(jù)、操作和環(huán)境的設(shè)置。

?（2）可判定性

?測試執(zhí)行的結(jié)果的正確性是可以判定的。每一個測試用例都應(yīng)有相應(yīng)的預(yù)期結(jié)

果。

?（3）可再現(xiàn)性

?對于同樣的測試用例，系統(tǒng)執(zhí)行的結(jié)果應(yīng)當(dāng)相同的，并且相同的測試的執(zhí)行過

程可以反復(fù)操作。

?測試用例模板

表1-1測試用例模板

項目名稱程序版本

測試環(huán)境硬件：

軟件:

編制人編制時間

功能模塊名

功能特性

測試目的

預(yù)置條件

參考信息特殊規(guī)程說

明

用例編號輸入數(shù)據(jù)執(zhí)行步驟預(yù)期結(jié)果測試結(jié)果

1

2

表1-2XX測試安裝用例

編號測試內(nèi)容安裝測試是否通過

1執(zhí)行典型安裝：執(zhí)行安裝步驟，按功能測試方法確認(rèn)功能正

確，包括各種控件、回車鍵、Tab鍵、快捷鍵、錯誤提示信息等

2執(zhí)行自定義安裝：執(zhí)行安裝步驟，按功能測試方法確認(rèn)功能正

確，包括各種控件、回車鍵、Tab鍵、快捷鍵、錯誤提示信息

等。選擇與典型安裝不同的安裝路徑和功能組件

3執(zhí)行網(wǎng)絡(luò)安裝：執(zhí)行安裝步驟，按功能測試方法確認(rèn)功能正

確，包括各種控件、回車鍵、Tab鍵、快捷鍵、錯誤提示信息等

4取消或關(guān)閉安裝過程，程序沒有安裝，檢查注冊表、安裝路徑

中是否存在程序的任何信息

5按界面和易用性測試規(guī)則，檢查安裝中的所有界面

6按文檔測試規(guī)則，檢查安裝中的所有文檔（幫助、許可協(xié)議

等）

7突然中斷安裝過程（網(wǎng)絡(luò)安裝還要考慮網(wǎng)絡(luò)中斷）

8安裝過程中介質(zhì)處于忙碌狀態(tài)

?軟件測試環(huán)境

?什么是測試環(huán)境

?軟件測試環(huán)境就是軟件測試運行的平臺。包括系統(tǒng)的硬件、軟件和網(wǎng)絡(luò)等。

?可以用一公式來表示

?測試環(huán)境=硬件+軟件+網(wǎng)絡(luò)+數(shù)據(jù)

?測試環(huán)境的搭建和維護

?（1）機房環(huán)境的建立

?（2）硬件環(huán)境的建立

?（3）軟件環(huán)境的建立

?（4）網(wǎng)絡(luò)環(huán)境的建立

?(5)安全措施的實施

?軟件測試人員的要求

?軟件測試人員的角色與職責(zé)

?測試人員的角色主要有四類

?(1)測試經(jīng)理

?主要負(fù)責(zé)測試隊伍的內(nèi)部管理以及與外部人員、客戶的交流工作，包括進度管理、

風(fēng)險管理、資金管理、人力資源管理、交流管理等。

?還有測試計劃書的編寫、測試總結(jié)報告的歸納等。必須具有項目經(jīng)理的知識和技能。

?(2)測試設(shè)計師

?主要根據(jù)軟件開發(fā)各階段產(chǎn)生的設(shè)計文檔來設(shè)計各階段的測試用例。

?(3)測試文檔審核師

?主要負(fù)責(zé)前置測試，包括對各個階段的分析與設(shè)計文檔進行審核，如：需求說明書、

概要與詳細(xì)設(shè)計說明書等。

?(4)測試工程師

?對測試設(shè)計師設(shè)計的測試用例分階段完成測試工作。

?軟件測試人員的基本素質(zhì)要求

?基本素質(zhì)要求如下：

?(1)具備計算機軟件測試的基本理論知識

?(2)熟悉開發(fā)工野口平臺

?(3)掌握測試工具的使用

?(4)善于學(xué)習(xí)，理解與歸納

?(5)耐心、細(xì)致、工作態(tài)度好

.第2章軟件開發(fā)過程與軟件測試

?軟件開發(fā)過程概述

?軟件開發(fā)的階段、活動及角色

?軟件工程的階段

?軟件工程的三個階段：

?定義階段

?可行性研究初步項目計劃、需求分析

?圖示

圖2-1軟件工程的定義階段

?開發(fā)階段

?概要設(shè)計、詳細(xì)設(shè)計、實現(xiàn)、測試

?圖示

圖2-2軟件工程的開發(fā)階段

?檢驗交付與維護階段

?運行、維護、廢棄

?圖示

圖2-3軟件工程的檢驗交付與維護階段

?軟件開發(fā)過程的活動

?通常包括四種基本過程活動：

?(1)軟件規(guī)格說明

?規(guī)定軟件的功能、性能及其運行限制。

?(2)軟件開發(fā)

?產(chǎn)生滿足規(guī)格說明的軟件,包括設(shè)計與編碼等工作。

?(3)軟件確認(rèn)

?確認(rèn)軟件能夠滿足客戶提出的要求，對應(yīng)于軟件測試。

?(4)軟件演進

?為滿足客戶的變更要求，軟件必須在使用過程中演進，以求盡量延長軟件的生命周

期。

?開發(fā)過程中的角色

?(1)項目經(jīng)理

?負(fù)責(zé)管理業(yè)務(wù)應(yīng)用開發(fā)和系統(tǒng)開發(fā)項目。

?(2)業(yè)務(wù)分析人員

?理螭口描繪客戶的要求,引導(dǎo)用］協(xié)調(diào)用戶和業(yè)務(wù)需求的收集和確認(rèn)，并使文檔化。

?(3)架構(gòu)師

?負(fù)責(zé)理解系統(tǒng)的業(yè)務(wù)需求，并創(chuàng)建合理、完善的系統(tǒng)體系架構(gòu)。

?并決定相關(guān)技術(shù)的選擇。

?(4)數(shù)據(jù)設(shè)計人員

?負(fù)責(zé)定義詳細(xì)的數(shù)據(jù)庫設(shè)計。

?(5)程序員

?設(shè)計、編寫程序代碼及內(nèi)部設(shè)計規(guī)格說明。

?(6)測試人員

?負(fù)責(zé)制定測試計劃，并根據(jù)計劃進行相關(guān)測試，找出產(chǎn)品中的問題。

?(7)產(chǎn)品經(jīng)理

?負(fù)責(zé)產(chǎn)品的交付和發(fā)布，以及銷售產(chǎn)品。

?(8)技術(shù)支持代表

?負(fù)責(zé)處理客戶的投訴，以及售后服務(wù)問題。

?軟件開發(fā)的過程模型

?線性III頁序模型

?(1)各個階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量；

?(2)由于開發(fā)模型是線性的，用戶只有等到整個過程的末期才能見到開發(fā)成果，從而

增加了開發(fā)的風(fēng)險；

?(3)早期的錯誤可能要等到開發(fā)后期的測試階段才能發(fā)現(xiàn)，進而帶來嚴(yán)重的后果。

?圖示

圖2-4線性順序模型

?原型模型

?原型模型從需求收集開始，開發(fā)者與用戶在一起定義軟件的總體目標(biāo)，標(biāo)識出已知的需

求，并規(guī)劃出進一步定義的區(qū)域，然后快速地設(shè)計并進行編碼實現(xiàn)，建立好原型。在原

型模型的基礎(chǔ)上，運行、評估、修改，多次迭代進行，直到滿足用戶的需求為止。

?圖示

聽取用戶意見建造/修改原型

用戶測試運行

原型

圖2-5原型模型

?快速開發(fā)模型

?采用RAD模型時，系統(tǒng)的每一個主要功能部件都可由一個單獨的RAD工作組完成，

最后將所有的部件集成起來構(gòu)成完整的軟件。

?RAD模型強調(diào)可復(fù)用程序構(gòu)件的開發(fā)，并支持多小組并行工作。但若一個系統(tǒng)很難模

塊時，構(gòu)件的復(fù)用和建造會出現(xiàn)許多問題，不適用于技術(shù)風(fēng)險高、采用新技術(shù)的項目。

?圖示

第三業(yè)務(wù)

小組建模n

數(shù)據(jù)

第二

業(yè)務(wù)_,建模

小組建模F

處理

數(shù)據(jù)建模

第一業(yè)務(wù)建模

小蛆建模應(yīng)用

口處理_.生成

數(shù)據(jù)建模J

測試

建模

口應(yīng)用反復(fù)

處理—?生成

建模I

測試

應(yīng)用_.反復(fù)

生成

測試

反復(fù)

今

60—90天

圖2-6快速開發(fā)模型

?演化軟件過程模型

?增量模型

?將線性模型與原型模型結(jié)合起來，隨著日程/時間的進展而交錯析線性序列集合

?圖示

開發(fā)日程

增

量

序

列

增量_I分析I—l設(shè)計I—>1編碼I_>I測試IJ發(fā)布I

增量三|分析|―乂設(shè)計?編碼|"-3測試|~T發(fā)布

圖2-7增量模型

?螺旋模型

?也是將線性模型與原型模型結(jié)合起來，并加入風(fēng)險分析

?螺旋模型被劃分為若干框架活動：用戶通信、計劃、風(fēng)險分析、工程、建造及發(fā)布、

用戶評估等。

?螺旋模型適應(yīng)于計算機軟件產(chǎn)品的整個生命周期。對于大型系統(tǒng)的開發(fā)是一種模型

方法。

?圖示

圖2-8螺旋模型

?軟件測試與軟件開發(fā)的關(guān)系

.軟件測試在軟件開發(fā)過程中占有重要的地位，在傳統(tǒng)的瀑布模型中，軟件測試只成為其階

段性的一段工作一進行代碼的測試.而現(xiàn)代軟件工程思想將軟件測試認(rèn)為是貫穿整個軟

件生命周期，并且是保證軟件質(zhì)量的重要手段之一。

?有些研究數(shù)據(jù)顯示，在國外軟件開發(fā)的工作量中，軟件測試的工作量占有總工作量的40%

左右；軟件開發(fā)的總費用中軟件測試占有對于一些高科技開發(fā)系統(tǒng)，軟件測試

30%-50%o

占有的時間和費用可能更多更高。

?軟件測試的基本原則

?1、測試不是為了證明系統(tǒng)的正確性，而是為了證明系統(tǒng)存在缺陷；

?2、所有的測試都應(yīng)該追溯到用戶的需求；

?3、測試應(yīng)當(dāng)盡早開始和不斷進行；

?4、窮舉測試是不可能的；

?5、第三方測試會更客觀、更有效；

?6、Pareto原則應(yīng)用于軟件測試；

?7、軟件測試是有風(fēng)險的行為；但并非所有的測試都要修復(fù)；

?8、測試應(yīng)從小規(guī)模開始，逐步轉(zhuǎn)向大規(guī)模；

?9、軟件測試是一項講究條理的技術(shù)專業(yè)。

?軟件測試方法的分類

?靜態(tài)測試與動態(tài)測試

?靜態(tài)測試

?靜態(tài)測試，是不需要執(zhí)行被測軟件，而是采用分析和查看的方式，來發(fā)現(xiàn)軟件當(dāng)中的缺

陷，包括需求文檔、源代碼、設(shè)計文檔、以及其他與軟件相關(guān)文檔中的二義性和錯誤。

最好由未參加代碼編寫的個人或小組來完成。測試小組還能夠使用一個或多個靜態(tài)測試

工具，以源程序代碼作為輸入，產(chǎn)生大量的在測試過程有用的數(shù)據(jù)。

?圖示

圖2-9靜態(tài)測試的要素

?靜態(tài)測試常用的方法

?(1)走查

?走查是個非正式的過程，檢查所有與源程序代碼相關(guān)的文檔。

?(2)審查

?審查比走查要求更加正規(guī)。

?(3)靜態(tài)代碼分析工具

?靜態(tài)結(jié)構(gòu)分析主要是以圖形的方式表現(xiàn)程序的內(nèi)部結(jié)構(gòu)

?動態(tài)測試

?動態(tài)測試是指通過運行實際被測試軟件，通過觀察程序運行時所表現(xiàn)的狀態(tài)、行為等來

發(fā)現(xiàn)軟件的缺陷。并對被測程序的運行情況進行分析對比，以便發(fā)嵋序表現(xiàn)的行為與

設(shè)計規(guī)格或客戶需求不一致的地方。

?動態(tài)測試一般包括功能確認(rèn)與接口測試，覆蓋率分析、性能分析、內(nèi)存分析等。

?動態(tài)測試是一種經(jīng)常運行的測試技術(shù)。但也有它的局限性：必須要借助測試用例完成；

需要搭建特定的測試環(huán)境；不能發(fā)現(xiàn)文檔中的問題。

?由于動態(tài)測試與靜態(tài)測試之間存在一定的協(xié)同性，又具有相對的獨立性。所以在程序執(zhí)

行前進行靜態(tài)測試，盡可能多地發(fā)現(xiàn)代碼中隱含的缺陷；執(zhí)行動態(tài)測試檢查程序?qū)崟r的

行為，發(fā)現(xiàn)程序在運行時存在的缺陷。

?黑盒測試與白盒測試

?黑盒測試

?黑盒測試又稱功能測試或數(shù)據(jù)驅(qū)動測試；是將被測試軟件看做一個黑盒子，完全不考慮

程序的內(nèi)部結(jié)構(gòu)和處理過程，只考慮系統(tǒng)的輸入和輸出，在程序的接口進行測試，檢查

系統(tǒng)功能是否符合需求規(guī)格說明書的要求。

?常用的測試方法

?等價類劃分、邊界值法、決策表法、因果圖法、錯誤推測試法等。

?黑盒測試的優(yōu)點

?黑盒測試用例與程序如何實現(xiàn)無關(guān)；

?測試用例的設(shè)計與程序開發(fā)可并行設(shè)計；

?沒有編程經(jīng)驗的人也可以設(shè)計測試用例。

?黑盒測試的局限性

?不可能做到窮舉測試

?可能存在漏洞。

?白盒測試

?白盒測試又稱結(jié)構(gòu)測試或邏輯驅(qū)動測試；是根據(jù)被測試程序源代碼的內(nèi)部結(jié)構(gòu)來設(shè)計測

試用例的方法。

?常用的測試方法

?邏輯覆蓋、基本路徑和數(shù)據(jù)流測試等。

?白盒測試的優(yōu)點

?可以利用不同的覆蓋準(zhǔn)則測試程序代碼的各個分支，發(fā)現(xiàn)程序內(nèi)部的編碼錯誤；

?可以直接發(fā)現(xiàn)內(nèi)存泄露問題；

?可以充當(dāng)黑盒測試的檢查手段等。

?白盒測試的局限性

?因程序路徑組合太多，同樣不能做到窮舉測試；

?由于設(shè)計測試用例不是根據(jù)客戶需求說明進行的測試，可能存需求方面的漏洞。

?灰盒測試

?灰盒測試結(jié)合了白盒測試和黑盒測試的要素，關(guān)注輸入的正確性，同時了關(guān)注內(nèi)部的表

現(xiàn)；考慮了用戶端、特定的系統(tǒng)知識和操作環(huán)境。它在系統(tǒng)組件的協(xié)同環(huán)境中評價應(yīng)用

軟件的設(shè)計。

?人工測試與自動化測試

?按照測試執(zhí)行時是否需要人工干預(yù)進行分類，可分為人工測試與自動測試。

?人工測試

?人工測試是人為測試和手工測試的統(tǒng)稱。

?人為測試的主要方法有桌前檢查、代碼審查和走直。

?用于軟件開發(fā)各階段的審查或評審都是人為測試。

?手工測試主要指在測試過程中，按照測試計劃一步一步執(zhí)行程序，得出測試結(jié)果并進行

分析的測試行為。

?自動測試

?自動化測試指的是利用測試工具對各種測試活動的管理與執(zhí)行，并對測試結(jié)果自動進行

分析。

?在測試的執(zhí)行過程中，一般不需要人工干預(yù)。

?常用在功能測試、回歸測試和性能測試等。

?自動化測試的優(yōu)點

?提高測試效率

?降低測試成本

?具有一致性和可重復(fù)性

?降低風(fēng)險，增加軟件的質(zhì)量等

?自動化測試的局限性

?自動化測試軟件本身的問題

?測試人員期望過高

?有些人工測試是不能用自動化測試替代等。

?其他測試分類

?基于模型的測試與模型檢測

?基于模型的測試，是指對軟件行為進行建模以及根據(jù)軟件的形式化模型設(shè)計測試的活動。

?模型檢測是指，用來驗證軟件特定模型中的一個或多個特性的一類技術(shù)。

?模型通常是有限狀態(tài)的，是從一些原始材料中提取出來的，這些原始材料可能是需求文

檔，也可能是系統(tǒng)源代碼本身。有窮狀態(tài)模型中的每一個狀態(tài)前都有一個或多個前置條

件，當(dāng)軟件處于該狀態(tài)時，這些特性必須滿足。見圖2-10所示說明模型檢測過程。

?圖示

原始材料:模型——

需求

以往經(jīng)驗）模型檢測器

源程序特性一

特性滿足嗎？

修改模型或原

始材料

圖2-10模型檢測的要素

?冒煙測試

?冒煙測試是指在測試中發(fā)現(xiàn)問題，也就是說找到了一個缺陷，由開發(fā)人員來修復(fù)這個缺

陷，當(dāng)修復(fù)完成后，是否真的解決了這個缺陷，或?qū)ζ渌K是否存在影響，因此要針

對這個問題進行專門的測試，這個測試過程稱為冒煙測試。

?在許多情況下，經(jīng)過測試后，發(fā)現(xiàn)修復(fù)某個問題會引起其他功能模塊一系列的反應(yīng)，導(dǎo)

致產(chǎn)生新的缺陷。冒煙測試的優(yōu)點是節(jié)省測試時間，防止創(chuàng)建失敗。缺點是覆蓋率較低。

?隨機測試

?隨機測試是根據(jù)測試說明書執(zhí)行樣例測試的一種重要補充手段，是保證測試覆蓋完整性

的有效閱和過程。

?隨機測試主要針對系統(tǒng)的一些重要功能進行復(fù)測。

?還對軟件更新和新增的功能要進行重點測試。常與回歸測試一起進行。

?軟件測試方法在軟件開發(fā)過程的運用

?L在軟件需求分析與建模階段中

?主要進行軟件目標(biāo)的定義，可行性研究和軟件需求分析工作。

?這時測試的對象是相關(guān)文檔資料，

?如：需求規(guī)格說明書等。從需求的完備、可實現(xiàn)、是否合理、是否可測試等方面進行評審，

采用的靜態(tài)測試方法。

?2、在概要設(shè)計與詳細(xì)設(shè)計階段

?概要設(shè)計描述總體系統(tǒng)架構(gòu)中各個模塊的劃分及相互之間的關(guān)系；詳細(xì)設(shè)計則描述各個模

塊具體的算法和數(shù)據(jù)結(jié)構(gòu)。

?這些都是用文字、圖表的形式進行描述的，測試時也是用靜態(tài)測試的方法，對文字、圖表

進行評審。

?3、在編碼工作階段，

?主要是采用高級語言對已詳細(xì)設(shè)計的模塊進行編程。

?這時的測試工作主要是對已有的程序代碼進行白盒測試，可以是靜態(tài)與動態(tài)相結(jié)合，采用

各種覆蓋方法進行測試，此時主要由程序員進行測試。

?4、在測試階段中

?此時進行的集成與系統(tǒng)測試。

?集成測試采用灰盒測試方法（白盒測試與黑盒測試相結(jié)合），主要測試產(chǎn)品的接口以及各

模塊之間的關(guān)系。

?而系統(tǒng)測試一般采用黑盒測試方法，主要測試系統(tǒng)的功能、性能等；由測試人員來完成測

試。

?5、在檢驗交付與維護階段

?模擬或?qū)嶋H客戶環(huán)境，對系統(tǒng)進行驗收測試。

?大多采用自動化測試工具進行測試驗收。

?包括功能測試、性能測試、回歸測試、發(fā)布測試等。

?軟件測試的過程模型

?V-model

?v-model模型是最早的軟件生存期模型，在20世紀(jì)80年代由PaulRook提出的。

?v-model包含了三個等級，分別是生存期模型，分配模型，功能性工具需求模型，闡述了

應(yīng)當(dāng)實施哪些活動，應(yīng)當(dāng)產(chǎn)生哪些結(jié)果，諸如此類。

?圖示

圖2-11v-model

?V-model指出，單元測試所檢測代碼的開發(fā)是否符合詳細(xì)設(shè)計的要求。集成測試所檢測此

前測試過的各組成部分是否能完好地結(jié)合到一起。系統(tǒng)測試所檢測已集成在一起的產(chǎn)品是

否符合系統(tǒng)規(guī)格說明書的要求。而驗收測試則檢測產(chǎn)品是否符合最終用戶的需求。所以V-

model模型軟件測試的策略既包括低層測試又包括高層測試，底層測試是為了驗證系統(tǒng)源

代碼的正確性，高層是為了測試整個系統(tǒng)是否滿足用戶的需求。

?V-model的缺陷

?僅僅把測試過程作為在需求分析、系統(tǒng)設(shè)計及編碼之后的一個階段忽視了測試對需求分

析，系統(tǒng)設(shè)計的驗證，一直到后期的驗收測試才被發(fā)現(xiàn)。

?W-model

?W模型由Evolutif公司提出，相對于V-model,W-model更科學(xué),W-model是V-

model的發(fā)展。由于V-model的局限性，沒有明確地說明早期的測試，無法體現(xiàn)"盡早地

和不斷地進行軟件測試”的原則。在V-model中增加軟件各開發(fā)階段應(yīng)同步進行的測試，

演化為W-modeL如圖2-12所示。

?圖示

圖2-12W-model

?W-model,強調(diào)的是測試伴隨著整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、

功能和設(shè)計同樣要測試。測試與開發(fā)是同步進行的，從而有利于盡早地發(fā)現(xiàn)問題。以需求

為例，需求分析一完成，我們就可以對需求進行測試，而不是等到最后才進行針對需求的

驗收測試。

?W-model的局限性

?W模型和V模型都把軟件的開發(fā)視為需求、設(shè)計、編碼等一系列串行的活動，軟件開

發(fā)和測試保持一種線性的前后關(guān)系，需要有嚴(yán)格的指令表示上一階段完全結(jié)束，才可以

正式開始下一個階段。這樣就無法支持迭代、自發(fā)性以及變更調(diào)整。對于當(dāng)前很多文檔

需要事后補充，或者根本沒有文檔的做法下，開發(fā)人員和測試人員都面臨同樣的困惑。

?H-model

?H-model,它將測試活動完全獨立出來，形成一個完全獨立的流程，將測試準(zhǔn)備活動和測

試執(zhí)行活動清晰地體現(xiàn)出來。如圖2-13所示:

?圖示

圖2-13H-model

?H-model揭示了：

?(1)軟件測試不僅僅指測試的執(zhí)行，還包括很多其他的活動；

?(2)軟件測試是f獨立的流程，貫穿產(chǎn)品整個生命周期，與其他流程并發(fā)地進行；

?(3)軟件測試要盡早準(zhǔn)備，盡早執(zhí)行；

?(4)軟件測試是根據(jù)被測物的不同而分層次進行的。不同層次的測試活動可以是按照

某個次序先后進行的，但也可能是反復(fù)的。

?X-model

?X-model的基本思想是由Marick提出的，他認(rèn)為一個模型必須能處理開發(fā)的所有方面,

包括交接，頻繁重復(fù)的集成，以及需求文檔的缺乏等等。而X-model填補了V-model的

缺陷，并可為測試人員和開發(fā)人員帶來明顯的幫助。如圖2-14所示。

?圖示

圖2-14X-model

?pretest-model

?pretest-model,它是將測鹿口開發(fā)緊密結(jié)合的模型，該模型提供了輕松的方式，可以使你

的項目加快速度。如圖2-15所示。

?圖示

?Pretest-model體現(xiàn)了以下的要點

?(1)開發(fā)和測試相結(jié)合

?(2)對每T交付內(nèi)容進行測試

?(3)在設(shè)計階段進行測試計劃和測試設(shè)計

?(4)測試和開發(fā)結(jié)合在一起

?(5)讓驗收測試和技術(shù)測試保持相對獨立

?測試模型的使用

?V-model強調(diào)了在整個軟件項目開發(fā)中需要經(jīng)歷的若干個測試級別，而且每一個級別都與

一個開發(fā)級別相對應(yīng)，但它忽略了測試的對象不應(yīng)該僅僅包括程序，或者說它沒有明確地

之處應(yīng)該對軟件的需求、設(shè)計進行測試。

?W-model強調(diào)了測試計劃等工作的先行核對系統(tǒng)需求和系統(tǒng)設(shè)計的測試，但W-model

和V-model一樣也沒有專門對軟件測試流程予以說明，因為事實上，隨著軟件質(zhì)量要求越

來越為大家所重視，軟件測試也逐步發(fā)展成為一個獨立于軟件開發(fā)部的組織，就每一個軟

件測試的細(xì)節(jié)而言，它都有一個獨立的操作流程。比如，現(xiàn)在的第三方測試，就包含了從

測試計劃和測試案例編寫，到測試實施以及測試報告編寫的全過程，

?H-model強調(diào)測試是獨立的，只要測試準(zhǔn)備完成，就可以執(zhí)行測試了。

?X-model和Pretest-model又在此基礎(chǔ)上增加了許多不確定因素的處理情況，因為在真

實項目中，經(jīng)常會有變更的發(fā)生，例如需要重新訪問前一階段的內(nèi)容，或者跟蹤并糾正以

前提交的內(nèi)容，修復(fù)錯誤，排除多余的成分，以及增加新發(fā)現(xiàn)的功能等。

.第3章白盒測試

?白盒測試基本概念

?白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試，是針對被測試程序單元內(nèi)部如何工作的測試，特點

是基于被測試程序的源代碼，而不是軟件的需求規(guī)格說明。

?使用白盒測試方法時，測試者必須全面了解程序內(nèi)部邏輯結(jié)構(gòu)，檢查程序的內(nèi)部結(jié)構(gòu)，從檢查

程序的邏輯著手，對相關(guān)的邏輯路徑進行測試，最后得出測試結(jié)果。

?采用白盒測試方法必須遵循原則

?（1）保證一個模塊中的所有獨立路徑至少被測試一次。

?（2）所有邏輯值均需測試真值和假值兩種情況。

?（3）檢查程序的內(nèi)部數(shù)據(jù)結(jié)構(gòu)，保證其結(jié)構(gòu)的有效性。

?（4）在上下邊界及可操作范圍內(nèi)運行所有循環(huán)。

?靜態(tài)白盒測試方法

?靜態(tài)白盒測試主要通過審杳、走查、檢驗等方法，來查找代碼中的問題和缺陷。

?主要原因是為了盡早發(fā)現(xiàn)軟件缺陷，以找出黑盒測試難以發(fā)現(xiàn)或隔離的軟件缺陷。其次，為黑

盒測試員在接受軟件進行測試設(shè)計時，設(shè)計和應(yīng)用測試用例提供思路。通過審查評論，可以確

定有問題或者容易產(chǎn)生軟件缺陷的特性范圍。

?檢查設(shè)計和代碼

?靜態(tài)白盒測試是在不執(zhí)行軟件的條件下有條理地仔細(xì)審查軟件設(shè)計、體系結(jié)構(gòu)和代碼，從

而找出軟件缺陷的過程。

?有時又稱為結(jié)構(gòu)化分析。

?正式審查

?正式審查有四個要素

?（1）確定問題

?（2）遵守規(guī)則

?（3）準(zhǔn)備

?（4）編寫報告

?正式審查的效果

?正式審查的主要的目的是找出軟件中存在的缺陷，除此之外，還可以形成一些間接的效

果。

?如：程序員與程序、測試人員之間的交流，增強相互了解；程序員會更仔細(xì)的編程，提

高正確率等。正式審查是把大家聚在一起討論同一個項目問題的良機。

?正式審查幾種類型

?（1）同事審杳

?（2）走杳

?（3）檢驗

?編碼標(biāo)準(zhǔn)和規(guī)范

?在編程和審查程序代碼時，建立相關(guān)的規(guī)范和標(biāo)準(zhǔn)，并堅持標(biāo)準(zhǔn)或規(guī)范。

?三個重要的原因

?（1）可靠性

?堅持按照某種標(biāo)準(zhǔn)和規(guī)范編寫的代碼更加可靠和安全。

?（2）可讀性/維護性

?符合設(shè)備標(biāo)準(zhǔn)和規(guī)范的代碼易于閱讀、理瞬口維護。

?（3）移植性

?代碼符合設(shè)備標(biāo)準(zhǔn)，遷移到另一個平臺就會輕而易舉，甚至完全沒有障礙。

?編程標(biāo)準(zhǔn)和規(guī)范示例

?（1）編程標(biāo)準(zhǔn)的4個組成部分

?①標(biāo)題

?描述標(biāo)準(zhǔn)包含的主題。

?②標(biāo)準(zhǔn)（或規(guī)范）

?描述標(biāo)準(zhǔn)或規(guī)范的內(nèi)容。

?③解釋說明

?給出標(biāo)準(zhǔn)背后的原因，以使程序員理解為什么這樣是好的編程習(xí)慣。

?④示例

?給出如何使用標(biāo)準(zhǔn)的簡單程序示例。

?（2）示例

?如圖3-1所示，是一個針對C++中所用的（:語言特性的規(guī)范示例。說明在C++中

如何使用某些C語言特性的編程。

?圖示

TOPIC:7.02C_problems-ProblemareasfromC

GUIDELINE

TrytoavoidClanguagefeaturesifaconflictwithprogramminginC++

DonotuseandJpngjniAifthereareanyobjectswithdestructorswhich

could忱createdbetweentheexecutionofthe5的mpandthe

Donotusetheoffsetofmacroexceptwhenappliedtomembersofjust-a-struct.

DonotmixC-styleFILEl/O(usingstdio.h)withC++styleI/O(usingjostream.hor

stream.h)onthesamefile.

AvoidusingCfunctionslikememcpyormemcapforcopyingorcomparingobjects

ofatypeotherthanarray-of-charorjust-a-struct.

AvoidtheCmacroNULL;use0instead.

JUSTIFICATION

EachofthesefeaturesconcernsanareaoftraditionalCusagewhichcreatesome

probleminC++.

圖3-1C++中所用C語言特性的程序示例

?獲取標(biāo)準(zhǔn)

?國際標(biāo)準(zhǔn)化組織（ISO）:www.iso.ch

?電子電氣工程學(xué)會（IEEE）:

?美國國家標(biāo)準(zhǔn)學(xué)會（ANSI）:

?國際工程協(xié)會（正C）:

?信息技術(shù)標(biāo)準(zhǔn)國家委員會（NCITS）:

?美國計算機協(xié)會（ACM）:

?通用代碼審查清單

?1、數(shù)據(jù)引用錯誤

?數(shù)據(jù)引用錯誤是指使用未經(jīng)正確聲明和初始化的變量、常量、數(shù)組、字符串或記錄而導(dǎo)

致的軟件缺陷。

?數(shù)據(jù)引用錯誤是緩沖區(qū)溢出的主要原因。

?2、數(shù)據(jù)聲明錯誤

?數(shù)據(jù)聲明缺陷產(chǎn)生的原因是不正確地聲明或使用變量和常量。

?3、計算錯誤

?計算或運算錯誤就是計算無法得到預(yù)期的結(jié)果。

?4、比較錯誤

?在使用比較和判斷運算時產(chǎn)生的比較和判斷錯誤，這種錯誤很可能是因為邊界條件問題。

?5、控制流程錯誤

?控制流程錯誤產(chǎn)生的原因是編程語言中循環(huán)等控制結(jié)構(gòu)未按預(yù)期的方式工作。

?通常由計算或者比較錯誤直接或間接造成。

?6、子程序參數(shù)錯誤

?子程序參數(shù)錯誤的來源是軟件子程序不正確地傳遞數(shù)據(jù)。

?7、輸入/輸出錯誤

?輸入輸出錯誤包括文件讀取、接受鍵盤或鼠標(biāo)輸入，以及向打印機或屏幕等輸出設(shè)備寫

入錯誤。

?8、其他檢查

?程序復(fù)雜度及度量方法

?在實際的軟件開發(fā)過程中，人們發(fā)現(xiàn)程序的復(fù)雜度不僅影響軟件的可維護性、可測試性及可靠

性等，而且與軟件中故障的數(shù)量、軟件的開發(fā)成本及軟件的效率有關(guān)。

?流圖的概念

?流圖又稱程序圖，實際上可以看作是一種簡化了的程序流程圖。在流圖中，只關(guān)注程序的

流程，不關(guān)心各個處理框的細(xì)節(jié)，因此，原來程序流程圖中的各個處理框（包括語句框、

判斷框、輸入/輸出框等）都被簡化為結(jié)點，一般用圓圈表示，而原來程序流程圖中的帶有

箭頭的控制流變成了程序圖中的有向邊。

?結(jié)構(gòu)化程序設(shè)計中的幾種基本結(jié)構(gòu)的流圖。如圖3-2所示。

?圖示

圖3-2流圖的幾種基本結(jié)構(gòu)

（a）順序結(jié)構(gòu)：（b）分支結(jié)構(gòu)；（c）循環(huán)結(jié)構(gòu);

?簡化后的流圖只有兩種圖形符號：結(jié)點和控制流線。

?結(jié)點用帶標(biāo)號的圓圈表示，可以代表一個或多個語句、一個處理框或一個判斷框。

?控制流線用帶箭頭的弧線表示，代表程序中控制流。

?從圖論的觀點來看，流圖是一個可表示為G=<N,E>的有向圖。

?其中，N表示圖中的結(jié)點，而E表示圖中的有向邊。

?流圖可以通過簡化程序流程圖得到，也可以由PAD圖或其他詳細(xì)設(shè)計表達工具變換得到。

?圖3-3是典型的程序流程圖轉(zhuǎn)換為相對應(yīng)的流圖。對圖3-3中的(a)所示的程序流程圖進

行簡化，得到圖3-3(b)所示的流圖。

?圖示

(a)(b)

圖3-3程序流程圖及對應(yīng)的流圖

(a)程序流程圖；(b)流圖

?環(huán)形復(fù)雜度

?環(huán)形復(fù)雜度又稱為圈復(fù)雜度，是一種為程序邏輯復(fù)雜度提供定量尺度的軟件度量。它可以

提供程序基本集的獨立路徑數(shù)量和確保所有語句至少執(zhí)行一次的過程。常用于基本路徑測

試法。

?環(huán)形復(fù)雜度的度量方法又稱為McCabe方法。一個強連通流圖中線性無關(guān)的有向環(huán)的個數(shù)

就是該程序的環(huán)形復(fù)雜度。而強連通圖，是指從圖中任意一個結(jié)點出發(fā)都能到達圖中其他

結(jié)點的有向圖。

?在圖論中可以通過以下公式來計算有向圖中線性無關(guān)的有向環(huán)的個數(shù)。

?V(G)=m-n+p①

.其中：V(G)表示有向圖G中的線性無關(guān)的環(huán)數(shù)；

?m表示有向圖G中有向邊的個數(shù)；

?n表示有向圖中的結(jié)點數(shù)；

?p表示有向圖G中可分離出的獨立連通區(qū)域數(shù)，為常數(shù)L

?流圖雖為連通圖，但不是強連通圖，可以在流圖中增加一條出口點到入口點的虛弧線，此

時，流圖就變成了一個強連通圖。如圖3-4所示，在圖3-3(b)流圖添加虛弧后得到的強

連通圖。

?圖示

圖3-4將圖3-3(b)變換后的強連通圖

?采用上面的公式①計算它的環(huán)形復(fù)雜度為：

?V(G)=13-10+1=4

?圖3-4強連通圖的復(fù)雜度是4,因此圖3-4中有4個線性獨立環(huán)路。此時刪除從結(jié)點E

到結(jié)點S的虛弧，則這4個環(huán)路就是結(jié)點S到結(jié)點E的線性獨立路徑。

?4條融獨立路徑：

?Pathl:S—a—>b-g-E

?Path2:S—a—b—g-h一E

?Path3:S—a—b—c—dTf—b—g—E

?Path4:S—*aTb—c一e一f—?b一g一E

?除了采用上面的公式①可以計算環(huán)形復(fù)雜度外，還可以用其他的公式計算出流圖中的環(huán)

形復(fù)雜度。

?V(G)=強連通的流圖在平面上圍成的區(qū)域數(shù)②

?V(G)=判定結(jié)點數(shù)+1③

?圖3-4中，流圖中圍成的區(qū)域有(b,c,d,f,b),(c,d,f,e,c),(g,h,E,g)和

(S,a,b,g,E,S),因此公式②計算得到的流圖環(huán)形復(fù)雜度為4。

.在圖3-4中，判定結(jié)點分別為b,c和g,根據(jù)公式③可得環(huán)形復(fù)雜度為：3+1=4。

?圖矩陣

?圖矩陣是流圖的鄰接矩陣的表示形式，其階數(shù)等于流圖的結(jié)點數(shù)，矩陣的每列與每行都對

應(yīng)于標(biāo)識的某一結(jié)點，矩陣元素對應(yīng)于結(jié)點之間的存在的邊；有邊取值為1,否則為0或

不填。

?如圖3-5和圖3-6所示，一個簡單流圖及對應(yīng)的鄰接矩陣：

?圖示

結(jié)點1234

11

21

31

41

圖3-5一個流圖圖3-6對應(yīng)的鄰接矩陣圖

?動態(tài)白盒測試方法

?動態(tài)白盒測試主要是按一定步驟和方法生成測試用例，并驅(qū)動相關(guān)模塊去執(zhí)行程序并發(fā)現(xiàn)軟件

中的錯誤和缺陷。測試人員要求對被測系統(tǒng)內(nèi)的程序結(jié)構(gòu)有深入的認(rèn)識，清楚程序的結(jié)構(gòu)、各

個組成部分及其之間的關(guān)聯(lián)，以及其內(nèi)部的運行原理、邏輯等。

?內(nèi)容包括的4部分

?（1）直接測試底層函數(shù)、過程、子程序和庫。

?（2）以完整程序的方式從頂層測試軟件，有時根據(jù)對軟件運行的了解調(diào)整測試用例。

?（3）從軟件獲得讀取變量和狀態(tài)信息的訪問權(quán)，以便確定測試結(jié)果與預(yù)期結(jié)果是否相符，

同時強制軟件以正常測試難以實現(xiàn)的方式運行。

?（4）估算執(zhí)行測試時"命中"的代碼量和具體代碼，然后調(diào)整測試，去掉多余的測試用例，

補充遺漏的測試用例.

?邏輯覆蓋法

?邏輯覆蓋法是動態(tài)白盒測試中常用的測試技術(shù)，是一系列測試過程的總稱。有選擇地執(zhí)行

程序中的某些最具有代表性的通路來對盡窮測試的唯一可行的替代方法。

?邏輯覆蓋法的覆蓋率是程序中一組被測試用例執(zhí)行到的百分比。

?覆蓋率=（至少被執(zhí)行一次的被測試項數(shù)）/被測試項總數(shù)

?根據(jù)測試覆蓋的目標(biāo)不同，以及覆蓋的程度不同，可由弱到強分為：語句覆蓋、判定覆蓋、

條件覆蓋、判定/條件覆蓋、修正的判定/條件覆蓋、條件組合覆蓋、路徑覆蓋

?語句覆蓋和塊覆蓋

?語句覆蓋又稱為代碼行覆蓋，指選擇足夠多的測試用例，使得程序中的每一條可執(zhí)行語

句至少被執(zhí)行一次。

?程序的基本塊就是一個連續(xù)的語句序列，只有一個入口點和一個出口點。這些唯一的入

口點和出口點就是基本塊的第一條語句和最后一條語句。程序的控制總是從基本塊的入

口點進入，從出口點退出。除了其出口點，程序不可能在基本塊的其他任意點退出或中

止。

?例子

?圖

例3-1下面以一個簡單的小程

序段來說明怎樣設(shè)計測試用

例。

VoidtestexampleKintx,int

y,intz)

(

if(x>l)&&(y==0)

z=z+x;

if(x==2)||(z>l)

z=z+y;

圖3?7例3?1的模塊的流程圖

returnz;

圖中數(shù)字L2.3.4.5.6.7為邊。

)

對于這段testexamplel函數(shù)

相對應(yīng)的程序控制流程圖見圖

3?7所示。

對于testexamplel函數(shù)，完全語句覆蓋是從第1行執(zhí)行到

最后一行。因此它的測試用例的設(shè)計見表3-1：

表3-1testexamplel語句沒盅測試川例

輸入數(shù)據(jù)返回值通過的路徑

ID

XyZZ

TE1-00120461-4-5-6-7

對于testexamplel函

數(shù)，其函數(shù)體可以分

為五個塊，第一塊為

第一個if語句；第二塊

為賦值語句z=z+x；

第三塊為第二個if語

句；第四塊是賦值語

句2=2+丫；第五塊是

returnz語句。將圖圖3-8testexamplel函數(shù)體的控制流圖

3-7換為圖3-8所示。

?塊覆蓋的測試用例的設(shè)計是要將這五塊都要遍歷，表3-1語句覆蓋的測試用例也就

是這個函數(shù)的塊覆蓋的測試用例。

?注意，語句覆蓋是覆蓋所測試程序段中的所有語句，塊覆蓋是測試程序段中的所有

基本塊。

?判定覆蓋

?判定覆蓋又叫分支覆蓋，即設(shè)計若干測試用例，使得程序中的每個判定表達式的每種可

能的結(jié)果值都應(yīng)該至少執(zhí)行一次，也就是說每個判定的"真"值分