軟件測試-課程筆記

軟件測試-課程筆記

.第1章軟件測試概述

?軟件測試的背景

?軟件的缺陷及其影響

?什么是軟件缺陷

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

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

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

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

?軟件缺陷的類型:

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

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

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

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

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

認(rèn)為不好。

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

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

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

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

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

?(5)諾基亞手機(jī)平臺(tái)缺陷(2008年)

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

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

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

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

?(2)用戶定義錯(cuò)誤；

?(3)需求記錄錯(cuò)誤；

?(4)設(shè)計(jì)說明錯(cuò)誤；

?(5)編碼說明有誤；

?(6)程序代碼有誤；

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

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

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

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

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

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

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

陷。

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

功能缺失，立即補(bǔ)上就可了，可以說付出的代價(jià)小得幾乎忽略不計(jì).

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

的修補(bǔ)費(fèi)用可以說高許多。

?因此要盡早進(jìn)行測試。

?軟件測試的基本概念

?軟件測試的定義

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

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

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

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

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

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

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

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

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

?軟件測試用例

?軟件測試用例定義

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

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

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

?測試用例的元素

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

?Why

?為什么測試？對功能、性能、可用性、容錯(cuò)性、安全性等測試，檢驗(yàn)是否符合

相關(guān)要求。

?What

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

?Where

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

?When

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

?Which

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

?How

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

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

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

?從兩個(gè)層次考慮測試用例

?（1）低層次

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

?（2）高層次

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

蓋率等；

?測試用例的基本原則

?（1）代表性

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

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

?（2）可判定性

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

果。

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

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

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

?測試用例模板

表1-1測試用例模板

項(xiàng)目名稱程序版本

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

軟件:

編制人編制時(shí)間

功能模塊名

功能特性

測試目的

預(yù)置條件

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

明

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

1

2

表1-2XX測試安裝用例

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

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

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

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

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

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

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

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

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)境就是軟件測試運(yùn)行的平臺(tái)。包括系統(tǒng)的硬件、軟件和網(wǎng)絡(luò)等。

?可以用一公式來表示

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

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

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

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

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

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

?(5)安全措施的實(shí)施

?軟件測試人員的要求

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

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

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

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

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

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

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

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

?(3)測試文檔審核師

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

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

?(4)測試工程師

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

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

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

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

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

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

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

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

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

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

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

?軟件工程的階段

?軟件工程的三個(gè)階段：

?定義階段

?可行性研究初步項(xiàng)目計(jì)劃、需求分析

?圖示

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

?開發(fā)階段

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

?圖示

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

?檢驗(yàn)交付與維護(hù)階段

?運(yùn)行、維護(hù)、廢棄

?圖示

圖2-3軟件工程的檢驗(yàn)交付與維護(hù)階段

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

?通常包括四種基本過程活動(dòng)：

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

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

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

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

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

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

?(4)軟件演進(jìn)

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

期。

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

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

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

?(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è)計(jì)人員

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

?(5)程序員

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

?(6)測試人員

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

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

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

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

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

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

?線性III頁序模型

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

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

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

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

?圖示

圖2-4線性順序模型

?原型模型

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

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

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

?圖示

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

用戶測試運(yùn)行

原型

圖2-5原型模型

?快速開發(fā)模型

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

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

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

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

?圖示

第三業(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é)合起來，隨著日程/時(shí)間的進(jìn)展而交錯(cuò)析線性序列集合

?圖示

開發(fā)日程

增

量

序

列

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

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

圖2-7增量模型

?螺旋模型

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

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

用戶評估等。

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

方法。

?圖示

圖2-8螺旋模型

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

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

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

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

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

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

30%-50%o

占有的時(shí)間和費(fèi)用可能更多更高。

?軟件測試的基本原則

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

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

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

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

?5、第三方測試會(huì)更客觀、更有效；

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

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

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

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

?軟件測試方法的分類

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

?靜態(tài)測試

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

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

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

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

?圖示

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

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

?(1)走查

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

?(2)審查

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

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

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

?動(dòng)態(tài)測試

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

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

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

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

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

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

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

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

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

?黑盒測試與白盒測試

?黑盒測試

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

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

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

?常用的測試方法

?等價(jià)類劃分、邊界值法、決策表法、因果圖法、錯(cuò)誤推測試法等。

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

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

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

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

?黑盒測試的局限性

?不可能做到窮舉測試

?可能存在漏洞。

?白盒測試

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

試用例的方法。

?常用的測試方法

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

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

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

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

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

?白盒測試的局限性

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

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

?灰盒測試

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

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

軟件的設(shè)計(jì)。

?人工測試與自動(dòng)化測試

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

?人工測試

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

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

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

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

分析的測試行為。

?自動(dòng)測試

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

分析。

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

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

?自動(dòng)化測試的優(yōu)點(diǎn)

?提高測試效率

?降低測試成本

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

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

?自動(dòng)化測試的局限性

?自動(dòng)化測試軟件本身的問題

?測試人員期望過高

?有些人工測試是不能用自動(dòng)化測試替代等。

?其他測試分類

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

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

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

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

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

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

?圖示

原始材料:模型——

需求

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

源程序特性一

特性滿足嗎？

修改模型或原

始材料

圖2-10模型檢測的要素

?冒煙測試

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

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

對這個(gè)問題進(jìn)行專門的測試，這個(gè)測試過程稱為冒煙測試。

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

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

?隨機(jī)測試

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

的有效閱和過程。

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

?還對軟件更新和新增的功能要進(jìn)行重點(diǎn)測試。常與回歸測試一起進(jìn)行。

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

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

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

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

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

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

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

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

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

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

進(jìn)行評審。

?3、在編碼工作階段，

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

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

各種覆蓋方法進(jìn)行測試，此時(shí)主要由程序員進(jìn)行測試。

?4、在測試階段中

?此時(shí)進(jìn)行的集成與系統(tǒng)測試。

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

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

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

試。

?5、在檢驗(yàn)交付與維護(hù)階段

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

?大多采用自動(dòng)化測試工具進(jìn)行測試驗(yàn)收。

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

?軟件測試的過程模型

?V-model

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

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

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

?圖示

圖2-11v-model

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

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

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

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

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

?V-model的缺陷

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

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

?W-model

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

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

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

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

?圖示

圖2-12W-model

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

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

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

驗(yàn)收測試。

?W-model的局限性

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

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

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

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

?H-model

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

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

?圖示

圖2-13H-model

?H-model揭示了：

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

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

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

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

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

?X-model

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

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

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

?圖示

圖2-14X-model

?pretest-model

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

的項(xiàng)目加快速度。如圖2-15所示。

?圖示

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

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

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

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

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

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

?測試模型的使用

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

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

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

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

和V-model一樣也沒有專門對軟件測試流程予以說明，因?yàn)槭聦?shí)上，隨著軟件質(zhì)量要求越

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

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

測試計(jì)劃和測試案例編寫，到測試實(shí)施以及測試報(bào)告編寫的全過程，

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

?X-model和Pretest-model又在此基礎(chǔ)上增加了許多不確定因素的處理情況，因?yàn)樵谡?/p>

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

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

.第3章白盒測試

?白盒測試基本概念

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

而找出軟件缺陷的過程。

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

?正式審查

?正式審查有四個(gè)要素

?（1）確定問題

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

?（3）準(zhǔn)備

?（4）編寫報(bào)告

?正式審查的效果

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

果。

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

高正確率等。正式審查是把大家聚在一起討論同一個(gè)項(xiàng)目問題的良機(jī)。

?正式審查幾種類型

?（1）同事審杳

?（2）走杳

?（3）檢驗(yàn)

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

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

?三個(gè)重要的原因

?（1）可靠性

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

?（2）可讀性/維護(hù)性

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

?（3）移植性

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

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

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

?①標(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所示，是一個(gè)針對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é)會(huì)（IEEE）:

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

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

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

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

?通用代碼審查清單

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

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

致的軟件缺陷。

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

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

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

?3、計(jì)算錯(cuò)誤

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

?4、比較錯(cuò)誤

?在使用比較和判斷運(yùn)算時(shí)產(chǎn)生的比較和判斷錯(cuò)誤，這種錯(cuò)誤很可能是因?yàn)檫吔鐥l件問題。

?5、控制流程錯(cuò)誤

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

?通常由計(jì)算或者比較錯(cuò)誤直接或間接造成。

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

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

?7、輸入/輸出錯(cuò)誤

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

入錯(cuò)誤。

?8、其他檢查

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

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

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

?流圖的概念

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

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

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

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

?結(jié)構(gòu)化程序設(shè)計(jì)中的幾種基本結(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é)點(diǎn)和控制流線。

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

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

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

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

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

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

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

?圖示

(a)(b)

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

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

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

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

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

試法。

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

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

結(jié)點(diǎn)的有向圖。

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

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

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

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

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

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

?流圖雖為連通圖，但不是強(qiáng)連通圖，可以在流圖中增加一條出口點(diǎn)到入口點(diǎn)的虛弧線，此

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

連通圖。

?圖示

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

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

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

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

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

?4條融獨(dú)立路徑：

?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

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

形復(fù)雜度。

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

?V(G)=判定結(jié)點(diǎn)數(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),因此公式②計(jì)算得到的流圖環(huán)形復(fù)雜度為4。

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

?圖矩陣

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

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

不填。

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

?圖示

結(jié)點(diǎn)1234

11

21

31

41

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

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

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

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

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

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

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

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

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

同時(shí)強(qiáng)制軟件以正常測試難以實(shí)現(xiàn)的方式運(yùn)行。

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

補(bǔ)充遺漏的測試用例.

?邏輯覆蓋法

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

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

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

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

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

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

?語句覆蓋和塊覆蓋

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

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

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

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

口點(diǎn)進(jìn)入，從出口點(diǎn)退出。除了其出口點(diǎn)，程序不可能在基本塊的其他任意點(diǎn)退出或中

止。

?例子

?圖

例3-1下面以一個(gè)簡單的小程

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

例。

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è)計(jì)見表3-1：

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

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

ID

XyZZ

TE1-00120461-4-5-6-7

對于testexamplel函

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

為五個(gè)塊，第一塊為

第一個(gè)if語句；第二塊

為賦值語句z=z+x；

第三塊為第二個(gè)if語

句；第四塊是賦值語

句2=2+丫；第五塊是

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

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

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

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

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

基本塊。

?判定覆蓋

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

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