基于新信息技術(shù)的軟件測(cè)試技術(shù) 課件 第1、2章 軟件測(cè)試概述、軟件測(cè)試基礎(chǔ)

第1章軟件測(cè)試概述1.1軟件測(cè)試技術(shù)1.2軟件中的Bug1.3軟件測(cè)試的職業(yè)素質(zhì)與要求1.4軟件質(zhì)量管理與評(píng)估

1.1軟件測(cè)試技術(shù)

1.1.1行業(yè)背景

計(jì)算機(jī)是由硬件與軟件組成的。硬件，就像我們的基礎(chǔ)設(shè)置，是由專門的廠商去設(shè)計(jì)制造的，而軟件也是由專業(yè)的人員去開發(fā)測(cè)試的。

就軟件行業(yè)而言，如何提高軟件的質(zhì)量，一直是軟件生產(chǎn)活動(dòng)中的熱門話題。軟件測(cè)試工作對(duì)于尋找軟件系統(tǒng)中存在的缺陷、保證軟件產(chǎn)品的質(zhì)量以及降低企業(yè)的生產(chǎn)成本、提高經(jīng)濟(jì)效益具有不可替代的作用。

1.1.2軟件測(cè)試的由來

1950年左右，軟件伴隨著第一臺(tái)電子計(jì)算機(jī)的問世而誕生。

過去，軟件僅是由程序員編寫的，程序員不僅擔(dān)負(fù)著編寫代碼的工作，還肩負(fù)著程序代碼測(cè)試、保證代碼質(zhì)量的職責(zé)。實(shí)際上，程序員此時(shí)所做的測(cè)試工作并非真正意義上的軟件測(cè)試，他們所做的工作從本質(zhì)上來說應(yīng)該稱作“調(diào)試”。

通常軟件調(diào)試是在已知錯(cuò)誤的情況下，對(duì)軟件程序代碼做出的一系列檢查、校正的過程，而軟件測(cè)試則是在未知錯(cuò)誤的情況下，檢查程序代碼是否有問題的過程。測(cè)試與調(diào)試的區(qū)別在于，軟件測(cè)試是從軟件質(zhì)量保證的角度來檢查程序代碼是否有錯(cuò)誤，而調(diào)試則是為了解決當(dāng)前已知的錯(cuò)誤，調(diào)試活動(dòng)無法替代測(cè)試活動(dòng)。

軟件測(cè)試活動(dòng)的出現(xiàn)，解放了程序員，使程序員能夠?qū)Ｐ牡亻_發(fā)代碼、優(yōu)化算法，并能及時(shí)地修復(fù)測(cè)試人員所發(fā)現(xiàn)的代碼缺陷，提高其工作效率。同時(shí)，各司其職的分工方式，也更適合于當(dāng)今社會(huì)的發(fā)展模式。

1.1.3軟件測(cè)試的定義

1．軟件測(cè)試常用術(shù)語

1)測(cè)試

測(cè)試是一項(xiàng)活動(dòng)，在這項(xiàng)活動(dòng)中某個(gè)系統(tǒng)或者其組成的部分將在特定的條件下運(yùn)行，結(jié)果將被觀察和記錄，并對(duì)系統(tǒng)或者組成部分進(jìn)行評(píng)價(jià)。

測(cè)試是一個(gè)或者多個(gè)測(cè)試用例的集合。

我們說的測(cè)試，若無特別說明，一般是指系統(tǒng)測(cè)試。

2)測(cè)試環(huán)境

測(cè)試環(huán)境是指為了完成軟件測(cè)試工作所必需的計(jì)算機(jī)硬件、軟件、網(wǎng)絡(luò)設(shè)備、歷史數(shù)據(jù)的總稱。

3)缺陷

軟件的缺陷(即Bug)指的是軟件中(包括程序和文檔)不符合用戶需求的問題。

4)測(cè)試用例

測(cè)試用例是為特定的目的而設(shè)計(jì)的一組測(cè)試輸入、執(zhí)行條件和預(yù)期的結(jié)果，用于測(cè)試某個(gè)程序路徑或核實(shí)是否滿足某個(gè)特定需求。

2．軟件測(cè)試定義

1972年，軟件測(cè)試領(lǐng)域先驅(qū)BillHetzel博士在美國(guó)的北卡羅萊納大學(xué)組織了歷史上第一次正式的關(guān)于軟件測(cè)試的會(huì)議。1973年他首先給出軟件測(cè)試的定義：“軟件測(cè)試就是建立一種信心，確信程序能夠按預(yù)期的設(shè)想運(yùn)行?！?983年他又將軟件測(cè)試的定義修改為：“評(píng)價(jià)一個(gè)程序和系統(tǒng)的特性或能力，并確定它是否達(dá)到預(yù)期的結(jié)果。軟件測(cè)試就是以此為目的的任何行為。”定義中的“設(shè)想”和“預(yù)期結(jié)果”其實(shí)就是我們現(xiàn)在所說的“用戶需求”。BillHetzel把軟件的質(zhì)量定義為“符合要求”。他認(rèn)為：測(cè)試方法是試圖驗(yàn)證軟件是“工作的”。所謂“工作的”就是指軟件的功能是按照預(yù)先的設(shè)想執(zhí)行的。

與上述觀點(diǎn)相反，GlenfordJ.Myers認(rèn)為應(yīng)該首先認(rèn)定軟件是有錯(cuò)誤的，然后用測(cè)試去發(fā)現(xiàn)盡可能多的錯(cuò)。除此之外，Myers還給出了與測(cè)試相關(guān)的三個(gè)重要觀點(diǎn)：

(1)測(cè)試是為了證明程序有錯(cuò)，而不是證明程序無錯(cuò)。

(2)一個(gè)好的測(cè)試用例是在于它發(fā)現(xiàn)了以前未能發(fā)現(xiàn)的錯(cuò)誤。

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

簡(jiǎn)單地說，軟件測(cè)試就是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程。軟件測(cè)試是一個(gè)找錯(cuò)的過程，測(cè)試只能找出程序中的錯(cuò)誤，而不能證明程序無錯(cuò)。

1.1.4軟件測(cè)試的分類

1．按是否關(guān)心系統(tǒng)內(nèi)部結(jié)構(gòu)劃分

1)白盒測(cè)試

白盒測(cè)試也稱結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試，是指基于一個(gè)應(yīng)用代碼的內(nèi)部邏輯，即基于覆蓋全部代碼、分支、路徑、條件的測(cè)試，測(cè)試者知道產(chǎn)品內(nèi)部工作過程，可通過測(cè)試來檢測(cè)產(chǎn)品內(nèi)部操作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測(cè)試程序，檢驗(yàn)程序中的每條通路是否都能按預(yù)定要求正確工作。白盒測(cè)試的主要方法有邏輯驅(qū)動(dòng)、基路測(cè)試等，主要用于軟件驗(yàn)證。圖1.1是白盒測(cè)試的示例圖。

圖1.1白盒測(cè)試示例圖

2)黑盒測(cè)試

黑盒測(cè)試是指不依據(jù)程序內(nèi)部設(shè)計(jì)和代碼的任何知識(shí)，而僅基于需求和功能性所進(jìn)行的測(cè)試。黑盒測(cè)試也稱功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試，它是在已知產(chǎn)品所應(yīng)具有的功能的前提下，通過測(cè)試來檢測(cè)每個(gè)功能是否都能正常使用。在測(cè)試時(shí)，把程序看作一個(gè)不能打開的黑盒子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測(cè)試者在程序接口進(jìn)行測(cè)試，且只檢查程序功能是否可按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息，并且保持外部信息(如數(shù)據(jù)庫(kù)或文件)的完整性。黑盒測(cè)試方法主要有等價(jià)類劃分、邊值分析、因果圖、錯(cuò)誤推測(cè)等。圖1.2是黑盒測(cè)試的示例圖。

圖1.2黑盒測(cè)試示例圖

“黑盒”法著眼于程序外部結(jié)構(gòu)，不考慮內(nèi)部邏輯結(jié)構(gòu)，針對(duì)軟件界面和軟件功能進(jìn)行測(cè)試?！昂诤小狈ㄊ歉F舉輸入測(cè)試，只有把所有可能的輸入都加以測(cè)試，才能以這種方法查出程序中所有的錯(cuò)誤。實(shí)際上其測(cè)試情況可能有無窮多個(gè)，不僅要測(cè)試所有合法的輸入，而且還要對(duì)那些不合法但是可能的輸入進(jìn)行測(cè)試。

2．按是否需要執(zhí)行被測(cè)軟件的角度劃分

按是否需要執(zhí)行被測(cè)軟件的角度，軟件測(cè)試可分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試。靜態(tài)測(cè)試不運(yùn)行待測(cè)程序而應(yīng)用其他手段實(shí)現(xiàn)測(cè)試目的，如代碼審核；而動(dòng)態(tài)測(cè)試通過運(yùn)行被測(cè)試軟件來達(dá)到目的。

3．按階段劃分

1)單元測(cè)試

單元測(cè)試是對(duì)軟件中的基本組成單位進(jìn)行的測(cè)試，如一個(gè)模塊、一個(gè)過程等。單元測(cè)試是軟件動(dòng)態(tài)測(cè)試的最基本的部分，也是最重要的部分之一，其目的是檢驗(yàn)軟件基本組成單位的正確性。

一個(gè)軟件單元的正確性是相對(duì)于該單元的規(guī)約而言的。因此，單元測(cè)試以被測(cè)試單位的規(guī)約為基準(zhǔn)。

2)集成測(cè)試

集成測(cè)試是在軟件系統(tǒng)集成過程中所進(jìn)行的測(cè)試，其主要目的是檢查軟件單元之間的接口是否正確。通常是根據(jù)集成測(cè)試計(jì)劃，一邊將模塊或其他軟件單元組合成越來越大的系統(tǒng)，一邊運(yùn)行該系統(tǒng)，以分析測(cè)試所組成的系統(tǒng)是否正確，各組成部分是否合拍。集成測(cè)試的策略主要有自頂向下和自底向上兩種。

3)系統(tǒng)測(cè)試

系統(tǒng)測(cè)試是對(duì)已經(jīng)集成好的軟件系統(tǒng)進(jìn)行徹底的測(cè)試，以驗(yàn)證軟件系統(tǒng)的正確性和性能等是否滿足其規(guī)約所指定的要求。檢查軟件的行為和輸出是否正確并非一項(xiàng)簡(jiǎn)單的任務(wù)，因此系統(tǒng)測(cè)試應(yīng)該按照測(cè)試計(jì)劃進(jìn)行，其輸入、輸出和其他動(dòng)態(tài)運(yùn)行行為應(yīng)該與軟件規(guī)約進(jìn)行對(duì)比。軟件系統(tǒng)測(cè)試方法很多，主要有功能測(cè)試、性能測(cè)試、隨機(jī)測(cè)試等。

4)驗(yàn)收測(cè)試

驗(yàn)收測(cè)試旨在向軟件的購(gòu)買者展示該軟件系統(tǒng)滿足預(yù)期設(shè)計(jì)目標(biāo)的需求。它的測(cè)試數(shù)據(jù)通常是系統(tǒng)測(cè)試的測(cè)試數(shù)據(jù)的子集。所不同的是，驗(yàn)收測(cè)試常常有軟件系統(tǒng)的購(gòu)買者代表在現(xiàn)場(chǎng)，甚至是在軟件安裝使用的現(xiàn)場(chǎng)。驗(yàn)收測(cè)試是軟件在投入使用之前的最后測(cè)試。

1.1.5軟件測(cè)試技術(shù)的發(fā)展

1．軟件驗(yàn)證技術(shù)

軟件驗(yàn)證的目的用于證明軟件生命周期的各個(gè)階段以及各階段間的邏輯協(xié)調(diào)性和正確性。目前，軟件驗(yàn)證技術(shù)還只是適用于特殊用途的小型程序。

2．軟件靜態(tài)測(cè)試

目前，軟件測(cè)試正在逐漸地由對(duì)程序代碼的靜態(tài)測(cè)試向高層開發(fā)產(chǎn)品的靜態(tài)測(cè)試方向發(fā)展，如靜態(tài)分析工具的產(chǎn)生。靜態(tài)分析工具可以在不執(zhí)行程序的情況下，進(jìn)行類型分析、接口分析、輸入輸出規(guī)格說明分析等。

3．測(cè)試數(shù)據(jù)的選擇

在測(cè)試數(shù)據(jù)選擇方面，主要是對(duì)測(cè)試用例進(jìn)行選擇，這對(duì)測(cè)試的成功與否有著重要的影響。

4．自動(dòng)化測(cè)試技術(shù)

自動(dòng)化測(cè)試是軟件測(cè)試技術(shù)的最新發(fā)展方向，其主要的目標(biāo)是研究如何實(shí)現(xiàn)軟件測(cè)試的自動(dòng)化過程以及相關(guān)的一系列內(nèi)容，具體表現(xiàn)是集成化測(cè)試系統(tǒng)。它將多種測(cè)試工具融為一體，合成為功能強(qiáng)大的測(cè)試工具。

1.2軟件中的Bug

1.2.1軟件Bug的定義軟件Bug實(shí)際是軟件產(chǎn)品沒有達(dá)到預(yù)期設(shè)計(jì)目標(biāo)，在軟件內(nèi)部存在的一種缺陷。通常情況下Bug不影響用戶和系統(tǒng)的正常運(yùn)行，處于隱蔽狀態(tài)。當(dāng)Bug發(fā)生運(yùn)行錯(cuò)誤時(shí)，輕者影響用戶使用，重者會(huì)構(gòu)成事故，造成損失或傷害。

1.2.2軟件Bug的類型

軟件Bug的類型可分為以下幾種：

(1)產(chǎn)品說明書中規(guī)定要做的事情，而軟件沒有實(shí)現(xiàn)。

(2)產(chǎn)品說明書中規(guī)定不要做的事情，而軟件卻實(shí)現(xiàn)了。

(3)產(chǎn)品說明書沒有提到的事情，而軟件卻實(shí)現(xiàn)了。

(4)產(chǎn)品說明書中沒有提到但是必須要做的事情，軟件卻沒有實(shí)現(xiàn)。

(5)軟件很難理解，很難去使用，速度超慢，測(cè)試人員站在最終用戶的角度看到的問題是平常的但不是正確的。

1.2.3軟件Bug的級(jí)別

軟件Bug的級(jí)別由高到低依次為：

(1)致命：數(shù)據(jù)被破壞、數(shù)據(jù)丟失、系統(tǒng)崩潰、系統(tǒng)無法運(yùn)行。

(2)嚴(yán)重：處理結(jié)果不正確、流程不對(duì)、性能不能滿足要求。

(3)一般：不會(huì)影響整個(gè)系統(tǒng)的運(yùn)行性能。

(4)微小：一些小問題如有個(gè)別的錯(cuò)誤字、文字排版不整齊等。

(5)建議：功能正常，有改進(jìn)的空間。

1.2.4軟件Bug的產(chǎn)生

軟件Bug的產(chǎn)生原因如圖1.3所示。圖1.3軟件Bug產(chǎn)生原因示意圖

1.2.5軟件Bug的構(gòu)成

軟件Bug的構(gòu)成示意圖如圖1.4所示，具體構(gòu)成見表1-1。圖1.4軟件Bug構(gòu)成示意圖

1.2.6修復(fù)Bug的代價(jià)

在軟件開發(fā)周期的不同階段，修復(fù)一個(gè)Bug所需的成本差別非常之大。越是到了后期，修復(fù)Bug越困難，成本也就越高。從圖1.5中可以看出，在測(cè)試階段修復(fù)Bug的代價(jià)是設(shè)計(jì)開發(fā)階段的幾倍，而一旦產(chǎn)品上線，進(jìn)入維護(hù)期后，所需的代價(jià)更是設(shè)計(jì)開發(fā)階段的幾十倍。

圖1.5Bug修復(fù)成本示意圖

1.2.7Bug的影響

下面是歷史上發(fā)生的幾次Bug大事件：

(1)?1962年7月28日MarinerI空間探測(cè)器事件：MarinerI航空軟件的Bug導(dǎo)致火箭在發(fā)射時(shí)偏離了其預(yù)期軌道，最終導(dǎo)致在大西洋上空將整個(gè)火箭摧毀。

(2)?1995/1996年，致命的ping命令：由于缺乏對(duì)IP段組裝代碼的完整性檢查和錯(cuò)誤的執(zhí)行使得有可能通過從互聯(lián)網(wǎng)的任意位置發(fā)送惡意的“ping”數(shù)據(jù)報(bào)而攻擊多個(gè)操作系統(tǒng)，受明顯影響的大部分是運(yùn)行Windows的計(jì)算機(jī)，當(dāng)它們接收到數(shù)據(jù)報(bào)后，就會(huì)死鎖并進(jìn)入所謂的“藍(lán)屏死機(jī)”。這類攻擊也會(huì)影響很多使用Macintosh和Unix操作系統(tǒng)的計(jì)算機(jī)。

(3)?1993年Intel奔騰浮點(diǎn)指數(shù)除法事件：一個(gè)硅片上的錯(cuò)誤導(dǎo)致Intel高性能奔騰芯片在一段范圍內(nèi)計(jì)算浮點(diǎn)指數(shù)除法時(shí)發(fā)生錯(cuò)誤。例如4195835.0/3145727.0產(chǎn)生的是1.33374而不是1.33382，產(chǎn)生了0.00008的偏差。盡管該Bug僅僅影響了少數(shù)用戶，然而它卻成了整個(gè)公眾的噩夢(mèng)。估計(jì)流通中的300萬到500萬的芯片存在著這樣的缺陷。起初Intel僅僅為那些能夠證明他們確實(shí)有高精度計(jì)算需求的用戶提供了取代奔騰的芯片，最后Intel公司妥協(xié)為任何投訴的人提供替代芯片。該Bug給Intel最終造成了4.75億美元損失。

1.3軟件測(cè)試的職業(yè)素質(zhì)與要求

1.3.1軟件測(cè)試職業(yè)發(fā)展軟件測(cè)試職業(yè)規(guī)劃表如表1-2所示。

1.3.2軟件測(cè)試人員工作目標(biāo)與必備素質(zhì)

1．軟件測(cè)試人員工作目標(biāo)

軟件測(cè)試具體工作：

(1)測(cè)試和發(fā)現(xiàn)軟件中存在的軟件缺陷。軟件測(cè)試人員要使用各種測(cè)試技術(shù)和方法來測(cè)試及發(fā)現(xiàn)軟件中存在的軟件缺陷。測(cè)試技術(shù)主要分為黑盒測(cè)試和白盒測(cè)試兩大類。

(2)測(cè)試工作需要貫穿整個(gè)軟件開發(fā)生命周期。完整的軟件測(cè)試工作包括單元測(cè)試、集成測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試。

(3)缺陷報(bào)告編寫及提交。測(cè)試人員將發(fā)現(xiàn)的缺陷編寫成正式的缺陷報(bào)告，提交給開發(fā)人員進(jìn)行缺陷的確認(rèn)和修復(fù)。

(4)軟件質(zhì)量分析。測(cè)試人員需要分析軟件質(zhì)量。

(5)測(cè)試計(jì)劃制訂。測(cè)試過程中，為了更好地組織與實(shí)施測(cè)試工作，測(cè)試負(fù)責(zé)人需要制訂測(cè)試計(jì)劃，包括測(cè)試資源、測(cè)試進(jìn)度、測(cè)試策略、測(cè)試方法、測(cè)試工具、測(cè)試風(fēng)險(xiǎn)等。

(6)測(cè)試用例報(bào)告形成。

(7)自動(dòng)化測(cè)試工具引進(jìn)。

(8)測(cè)試水平提高。

2．軟件測(cè)試人員必備素質(zhì)

測(cè)試人員通常要具備以下一些素質(zhì)及技能。

1)計(jì)算機(jī)專業(yè)技能

計(jì)算機(jī)領(lǐng)域的專業(yè)技能是測(cè)試工程師應(yīng)該必備的一項(xiàng)素質(zhì)，這是做好測(cè)試工作的前提條件。

(1)測(cè)試專業(yè)技能。

(2)軟件編程技能。

(3)網(wǎng)絡(luò)、操作系統(tǒng)、數(shù)據(jù)庫(kù)、中間件等知識(shí)。

作為一名測(cè)試人員，盡管不能精通所有的知識(shí)，但要想做好測(cè)試工作，應(yīng)該盡可能地學(xué)習(xí)更多的與測(cè)試工作相關(guān)的專業(yè)知識(shí)。

2)行業(yè)知識(shí)

所謂行業(yè)，主要是指測(cè)試人員所在企業(yè)涉及的領(lǐng)域。例如，很多IT企業(yè)從事石油、電信、銀行、電子政務(wù)、電子商務(wù)等行業(yè)領(lǐng)域的產(chǎn)品開發(fā)。行業(yè)知識(shí)即專業(yè)業(yè)務(wù)知識(shí)，是測(cè)試人員做好測(cè)試工作的又一個(gè)前提條件。只有深入了解了產(chǎn)品的業(yè)務(wù)流程，才可以判斷開發(fā)人員實(shí)現(xiàn)的功能是否正確。

3)個(gè)人素養(yǎng)

作為一名優(yōu)秀的測(cè)試工程師，首先要對(duì)測(cè)試工作有興趣，因?yàn)闇y(cè)試工作多數(shù)比較枯燥。

(1)專心：主要指測(cè)試人員在執(zhí)行測(cè)試任務(wù)的時(shí)候不可一心二用。

(2)細(xì)心：主要指進(jìn)行測(cè)試工作時(shí)要認(rèn)真，不可以忽略細(xì)節(jié)。

(3)耐心：很多測(cè)試工作有時(shí)候顯得非?？菰?，需要很大的耐心才可以做好。

(4)責(zé)任心：責(zé)任心是做好工作必備的素質(zhì)之一，測(cè)試工程師更應(yīng)該高度負(fù)責(zé)。

(5)自信心：自信心是目前多數(shù)測(cè)試工程師都缺少的一項(xiàng)素質(zhì)，尤其在面對(duì)測(cè)試開發(fā)等工作時(shí)，往往認(rèn)為自己做不到。

1.4軟件質(zhì)量管理與評(píng)估

1.4.1軟件質(zhì)量的定義1979年，F(xiàn)isher和Light將軟件質(zhì)量定義為：表征計(jì)算機(jī)系統(tǒng)卓越程度的所有屬性的集合。1982年，F(xiàn)isher和Baker將軟件質(zhì)量定義為：軟件產(chǎn)品滿足明確需求一組屬性的集合。20世紀(jì)90年代，Norman、Robin等將軟件質(zhì)量定義為：表征軟件產(chǎn)品滿足明確的和隱含的需求的能力的特性或特征的集合。

994年，國(guó)際標(biāo)準(zhǔn)化組織公布的國(guó)際標(biāo)準(zhǔn)ISO8042將軟件質(zhì)量定義為：反映實(shí)體滿足明確的和隱含的需求的能力的特性的總和。

綜上所述，軟件質(zhì)量是產(chǎn)品、組織和體系或過程的一組固有特性，反映它們滿足顧客和其他相關(guān)方面要求的程度。

GB/T11457—2006《軟件工程術(shù)語》中定義軟件質(zhì)量為：

(1)軟件產(chǎn)品中能滿足給定需要的性質(zhì)和特性的總體。

(2)軟件具有所期望的各種屬性的組合程度。

(3)顧客和用戶覺得軟件滿足其綜合期望的程度。

(4)確定軟件在使用中將滿足顧客預(yù)期要求的程度。

1.4.2軟件質(zhì)量的屬性

軟件質(zhì)量屬性劃分為開發(fā)期質(zhì)量屬性和運(yùn)行期質(zhì)量屬性兩大類，如圖1.6所示。開發(fā)期質(zhì)量屬性其實(shí)包含了與軟件開發(fā)、維護(hù)和移植這三類活動(dòng)相關(guān)的所有質(zhì)量屬性，這些是開發(fā)人員、開發(fā)管理人員和維護(hù)人員都非常關(guān)心的，對(duì)最終用戶而言，這些質(zhì)量屬性只是間接地促進(jìn)用戶需求的滿足；而運(yùn)行期質(zhì)量屬性是軟件系統(tǒng)在運(yùn)行期間，最終用戶可以直接感受到的一類屬性，這些質(zhì)量屬性直接影響著用戶對(duì)軟件產(chǎn)品的滿意度。圖1.6軟件質(zhì)量結(jié)構(gòu)示意圖

1.4.3軟件質(zhì)量的模型

1．Boehm質(zhì)量模型

Boehm質(zhì)量模型是1976年由Boehm等提出的分層方案，將軟件的質(zhì)量特性定義成分層模型，如圖1.7所示。

圖1.7Boehm質(zhì)量模型

2．McCall質(zhì)量模型

McCall質(zhì)量模型是1979年由McCall等人提出的軟件質(zhì)量模型。它將軟件質(zhì)量的概念建立在11個(gè)質(zhì)量特性之上，而這些質(zhì)量特性分別是面向軟件產(chǎn)品的運(yùn)行、修正和轉(zhuǎn)移的，如圖1.8所示。

圖1.8McCall質(zhì)量模型

1.4.4軟件質(zhì)量的度量

軟件質(zhì)量的度量主要針對(duì)作為軟件開發(fā)成果的軟件產(chǎn)品的質(zhì)量而言，獨(dú)立于其過程。軟件的質(zhì)量由一系列質(zhì)量要素組成，每一個(gè)質(zhì)量要素又由一些衡量標(biāo)準(zhǔn)組成，每個(gè)衡量標(biāo)準(zhǔn)又由一些度量標(biāo)準(zhǔn)加以定量刻畫。質(zhì)量度量貫穿于軟件工程的全過程以及軟件交付后，在軟件交付之前的度量主要包括程序復(fù)雜性、模塊的有效性和總的程序規(guī)模；在軟件交付之后的度量則主要包括殘存的缺陷數(shù)和系統(tǒng)的可維護(hù)性。第2章軟件測(cè)試基礎(chǔ)2.1軟件開發(fā)模型2.2軟件測(cè)試的目的和原則2.3軟件測(cè)試的模型2.4軟件測(cè)試過程2.5黑盒測(cè)試和白盒測(cè)試2.6靜態(tài)測(cè)試與動(dòng)態(tài)測(cè)試2.7驗(yàn)證測(cè)試與確認(rèn)測(cè)試

2.1軟件開發(fā)模型

軟件開發(fā)模型是軟件開發(fā)過程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架，它能夠清晰、直觀地表達(dá)軟件開發(fā)的全部過程，明確規(guī)定要完成的主要活動(dòng)和任務(wù)，是軟件項(xiàng)目開發(fā)的基礎(chǔ)。與任何事物一樣，軟件也有一個(gè)從孕育、誕生、成長(zhǎng)到衰亡的生存過程，通常稱為軟件生存周期，其中包括計(jì)劃、需求分析、軟件設(shè)計(jì)、編碼、測(cè)試及運(yùn)行和維護(hù)6個(gè)階段。

1．計(jì)劃(第一階段)

在計(jì)劃階段應(yīng)確定軟件開發(fā)的總目標(biāo)，設(shè)想軟件的功能、性能、可靠性以及接口等方面的要求，研究完成該項(xiàng)軟件任務(wù)的可行性，探討解決問題的方案，對(duì)可供開發(fā)使用的資源(如計(jì)算機(jī)軟硬件、人力等)、成本、可取得的效益和開發(fā)的進(jìn)度作出估計(jì)，制訂完成開發(fā)任務(wù)的實(shí)施計(jì)劃。

2．需求分析(第二階段)

在需求分析階段應(yīng)對(duì)開發(fā)的軟件進(jìn)行詳細(xì)的定義，由軟件開發(fā)人員和用戶共同討論決定哪些需求是可以滿足的并且給出確切的描述，寫出軟件需求說明(或稱軟件規(guī)格說明)以及初步的用戶手冊(cè)，提交管理機(jī)構(gòu)審查。

3．軟件設(shè)計(jì)(第三階段)

設(shè)計(jì)是軟件工程的技術(shù)核心，在設(shè)計(jì)階段首先應(yīng)把已確定的各項(xiàng)需求轉(zhuǎn)換成相應(yīng)的體系結(jié)構(gòu)，在結(jié)構(gòu)中每一組成部分都是功能明確的模塊，每個(gè)模塊體現(xiàn)相應(yīng)的需求，這一步稱為概要設(shè)計(jì)；在概要設(shè)計(jì)的基礎(chǔ)上進(jìn)行詳細(xì)設(shè)計(jì)，即對(duì)每個(gè)模塊要完成的工作進(jìn)行具體的描述，包括確定使用的數(shù)據(jù)結(jié)構(gòu)等，為程序編寫打下基礎(chǔ)。上述兩步設(shè)計(jì)工作均應(yīng)寫出設(shè)計(jì)說明，以供后繼工作使用并提交審查。

4．編碼(第四階段)

編碼是把軟件設(shè)計(jì)轉(zhuǎn)換成計(jì)算機(jī)可以接受的程序，即編寫出以某種程序設(shè)計(jì)語言表示的源程序。當(dāng)然，編寫出的程序應(yīng)該是結(jié)構(gòu)良好、清晰易讀并且與設(shè)計(jì)相一致的。

5．測(cè)試(第五階段)

測(cè)試是檢驗(yàn)開發(fā)的軟件是否符合規(guī)格說明的要求，它是保證軟件質(zhì)量的重要手段。通常測(cè)試工作分為以下4步：

(1)單元測(cè)試：檢驗(yàn)各單元模塊能否正常工作。

(2)集成測(cè)試：將已測(cè)試的單元模塊組裝起來進(jìn)行測(cè)試，檢驗(yàn)與軟件設(shè)計(jì)相關(guān)的程序結(jié)構(gòu)問題。

(3)確認(rèn)測(cè)試：對(duì)照軟件規(guī)格說明，檢驗(yàn)開發(fā)的軟件能否滿足所有功能和性能的要求，以決定開發(fā)的軟件是否合格，能否提交用戶使用等。

(4)系統(tǒng)測(cè)試：檢驗(yàn)開發(fā)的軟件能否與系統(tǒng)的其他部分(如硬件、數(shù)據(jù)庫(kù)、操作人員等)協(xié)調(diào)工作。

6．運(yùn)行和維護(hù)(第六階段)

已交付的軟件投入正式使用以后便進(jìn)入了運(yùn)行階段，這個(gè)階段可能持續(xù)若干年，甚至幾十年。在運(yùn)行過程中可能會(huì)有多種原因需要對(duì)軟件進(jìn)行修改，比如，運(yùn)行中發(fā)現(xiàn)了軟件故障，為適應(yīng)變化了的軟件工作環(huán)境，為進(jìn)一步增強(qiáng)軟件的功能以及提高它的性能等。

以上6個(gè)階段表明了軟件從開發(fā)直至使用相當(dāng)長(zhǎng)一段時(shí)間以后，被新的軟件所代替而退役的整個(gè)過程。按此順序逐步轉(zhuǎn)變的過程可用一個(gè)軟件生存期的瀑布模型加以形象地描述，如圖2.1所示。

圖2.1軟件開發(fā)的瀑布模型

另一種常用的軟件開發(fā)模型是1988年由TRW公司提出的螺旋模型，如圖2.2所示，該模型加入了風(fēng)險(xiǎn)分析。

圖2.2軟件開發(fā)的螺旋模型

由圖2.2可以看出，每一螺旋包括4個(gè)方面的活動(dòng)，即：

(1)制訂計(jì)劃：確定軟件項(xiàng)目開發(fā)的目標(biāo)，選定實(shí)施方案，弄清項(xiàng)目開發(fā)的限制條件。

(2)風(fēng)險(xiǎn)分析：分析所選的實(shí)施方案，指出如何識(shí)別并降低風(fēng)險(xiǎn)。

(3)實(shí)施方案：實(shí)施軟件開發(fā)方案。

(4)評(píng)估方案：評(píng)價(jià)開發(fā)工作，提出修正建議。

螺旋模型適合于大型軟件的開發(fā)，該模型的使用需要具有相當(dāng)豐富的風(fēng)險(xiǎn)評(píng)估經(jīng)驗(yàn)和專門知識(shí)。如果項(xiàng)目風(fēng)險(xiǎn)較大，又未能及時(shí)發(fā)現(xiàn)，勢(shì)必造成重大損失。軟件測(cè)試人員比較喜歡螺旋模式，通過參與最初的設(shè)計(jì)階段，項(xiàng)目的來龍去脈比較清楚，可以盡早地了解項(xiàng)目甚至影響項(xiàng)目。測(cè)試一直在進(jìn)行，直到最后宣布成功，不至于在項(xiàng)目末期匆匆忙忙地在短時(shí)間內(nèi)完成測(cè)試。

螺旋模型出現(xiàn)較晚，遠(yuǎn)不如瀑布模型普及，要讓開發(fā)人員和用戶廣泛接受，還有待于更多的實(shí)踐。

2.2軟件測(cè)試的目的和原則

2.2.1軟件測(cè)試的目的基于不同的立場(chǎng)，軟件測(cè)試存在著兩種完全不同的目的。從用戶的角度出發(fā)，普遍希望通過軟件測(cè)試暴露軟件中隱藏的錯(cuò)誤和缺陷，以考慮是否接受該產(chǎn)品。而從軟件開發(fā)者角度出發(fā)，則希望測(cè)試成為表明軟件產(chǎn)品不存在錯(cuò)誤的過程，驗(yàn)證該軟件已正確地實(shí)現(xiàn)了用戶需求，確立人們對(duì)軟件質(zhì)量的信心。

鑒于此，GrenfordJ.Myers就軟件測(cè)試的目的提出以下觀點(diǎn)：

(1)測(cè)試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯(cuò)誤；

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

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

測(cè)試的目的是想以最少的時(shí)間和人力找出軟件中潛在的各種錯(cuò)誤和缺陷。

2.2.2軟件測(cè)試的原則

軟件測(cè)試應(yīng)遵循以下原則：

(1)軟件開發(fā)人員應(yīng)當(dāng)避免測(cè)試自己開發(fā)的程序。

(2)應(yīng)盡早地和不斷地進(jìn)行軟件測(cè)試。

(3)對(duì)測(cè)試用例要有正確的態(tài)度：第一，測(cè)試用例應(yīng)當(dāng)由測(cè)試輸入數(shù)據(jù)和預(yù)期輸出結(jié)果兩部分組成；第二，在設(shè)計(jì)測(cè)試用例時(shí)，不僅要考慮合理的輸入條件，更要注意不合理的輸入條件。

(4)充分注意軟件測(cè)試中的群集現(xiàn)象，不要以為發(fā)現(xiàn)幾個(gè)錯(cuò)誤并且解決這些問題之后，就不需要測(cè)試了。

(5)嚴(yán)格執(zhí)行測(cè)試計(jì)劃，排除測(cè)試的隨意性，以避免發(fā)生疏漏或者重復(fù)無效的工作。

(6)應(yīng)當(dāng)對(duì)每一個(gè)測(cè)試結(jié)果進(jìn)行全面檢查。

(7)妥善保存測(cè)試用例、測(cè)試計(jì)劃、測(cè)試報(bào)告和最終分析報(bào)告，以備回歸測(cè)試及維護(hù)之用。

(8)這是最重要的一個(gè)原則，即所有測(cè)試的標(biāo)準(zhǔn)都是建立在用戶需求之上。

2.3軟件測(cè)試的模型

1．V模型V模型中從左到右描述了基本的開發(fā)過程和測(cè)試行為。V模型的價(jià)值在于它非常明確地標(biāo)明了測(cè)試過程存在的不同級(jí)別，并且清楚地描述了這些測(cè)試階段和開發(fā)過程期間各階段的對(duì)應(yīng)關(guān)系。由圖2.3可以直觀地觀察到測(cè)試過程的局限性，測(cè)試過程被放在了需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)與編碼之后，容易使人理解成測(cè)試是軟件開發(fā)的最后一個(gè)階段，主要針對(duì)程序進(jìn)行測(cè)試，尋找錯(cuò)誤。

圖2.3軟件測(cè)試中V模型

2．W模型

根據(jù)圖2.4很容易看出，W模型比V模型更科學(xué)，它伴隨著整個(gè)開發(fā)過程，而且測(cè)試對(duì)象不僅僅是程序，同時(shí)也測(cè)試需求與設(shè)計(jì)。

圖2.4軟件測(cè)試中W模型

3．H模型

測(cè)試條件只要成熟，測(cè)試準(zhǔn)備活動(dòng)完成了，就可以執(zhí)行測(cè)試活動(dòng)。測(cè)試模型是一個(gè)獨(dú)立的過程，貫穿于整個(gè)產(chǎn)品周期，與其他流程并發(fā)進(jìn)行，如圖2.5所示。圖2.5軟件測(cè)試中H模型

2.4軟件測(cè)試過程

軟件開發(fā)是一個(gè)自頂向下逐步細(xì)化的過程。軟件測(cè)試則是以相反順序自底向上逐步集成的過程。低一級(jí)的測(cè)試為上一級(jí)的測(cè)試準(zhǔn)備條件。圖2.6表示了軟件測(cè)試的4個(gè)步驟，即單元測(cè)試、集成測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試。圖2.6軟件測(cè)試過程

2.4.1單元測(cè)試

單元測(cè)試是在軟件開發(fā)過程中進(jìn)行的最低級(jí)別的測(cè)試活動(dòng)，其測(cè)試的對(duì)象是軟件設(shè)計(jì)的最小單位。在傳統(tǒng)的結(jié)構(gòu)化編程語言中(比如C語言)，單元測(cè)試的對(duì)象一般是函數(shù)或子過程。在像C++這樣的面向?qū)ο蟮恼Z言中，單元測(cè)試的對(duì)象可以是類，也可以是類的成員函數(shù)。單元測(cè)試的原則同樣也可以擴(kuò)展到第四代語言(4GL)中，這時(shí)單元被典型地定義為一個(gè)菜單或顯示界面。

單元測(cè)試又稱為模塊測(cè)試。模塊并沒有嚴(yán)格的定義，不過按照一般的理解，模塊應(yīng)該具有以下的一些基本屬性：

(1)名字；

(2)明確規(guī)定的功能；

(3)內(nèi)部使用的數(shù)據(jù)或稱局部數(shù)據(jù)；

(4)與其他模塊或外界的數(shù)據(jù)聯(lián)系；

(5)實(shí)現(xiàn)其特定功能的算法；

(6)可被其上層模塊調(diào)用，也可調(diào)用其下屬模塊進(jìn)行協(xié)同工作。

單元測(cè)試的目的是檢測(cè)程序模塊中有無故障存在，也就是說，一開始并不是把程序作為一個(gè)整體來測(cè)試，而是首先集中注意力來測(cè)試程序中較小的結(jié)構(gòu)塊，以便發(fā)現(xiàn)并糾正模塊內(nèi)部的故障。單元測(cè)試還提供了同時(shí)測(cè)試多個(gè)模塊的良機(jī)，從而在測(cè)試過程中引入了并行性。

2.4.2集成測(cè)試

程序在某些局部反映不出的問題，很可能在全局暴露出來，影響到功能的正常發(fā)揮，可能的原因有：

(1)模塊相互調(diào)用時(shí)引入了新的問題，例如數(shù)據(jù)可能丟失，一個(gè)模塊對(duì)另一模塊可能有不良的影響等。

(2)幾個(gè)子功能組合起來不能實(shí)現(xiàn)主功能。

(3)誤差不斷積累，以致達(dá)到不可接受的程度。

(4)全局?jǐn)?shù)據(jù)結(jié)構(gòu)出現(xiàn)錯(cuò)誤等。

組織集成測(cè)試的方法有兩種：

(1)獨(dú)立地測(cè)試程序的每個(gè)模塊，然后把它們組合成一個(gè)整體進(jìn)行測(cè)試，稱為非增式集成測(cè)試法。

(2)先把下一個(gè)待測(cè)模塊組合到已經(jīng)測(cè)試過的那些模塊上，再進(jìn)行測(cè)試，逐步完成集成測(cè)試，稱為增式集成測(cè)試法。

圖2.7是一個(gè)程序例子，圖中的7個(gè)矩形分別表示程序的7個(gè)模塊(子程序或者過程)，模塊之間的連線表示程序的控制層次，就是說模塊M1調(diào)用模塊M2、M3和M4，模塊M2調(diào)用模塊M5和M6等。

圖2.77個(gè)模塊的程序簡(jiǎn)圖

2.4.3系統(tǒng)測(cè)試

軟件只是計(jì)算機(jī)系統(tǒng)的一個(gè)重要組成部分，軟件開發(fā)完成以后，還應(yīng)與系統(tǒng)中其他部分聯(lián)合起來，進(jìn)行一系列系統(tǒng)集成和測(cè)試，以保證系統(tǒng)各組成部分能夠協(xié)調(diào)地工作。這里所說的系統(tǒng)組成部分除軟件外，還包括計(jì)算機(jī)硬件及相關(guān)的外圍設(shè)備、數(shù)據(jù)及采集和傳輸機(jī)構(gòu)、計(jì)算機(jī)系統(tǒng)操作人員等。系統(tǒng)測(cè)試實(shí)際上是針對(duì)系統(tǒng)中各個(gè)組成部分進(jìn)行的綜合性檢驗(yàn)，很接近日常測(cè)試實(shí)踐。系統(tǒng)測(cè)試的目標(biāo)不是要找出軟件故障，而是要證明系統(tǒng)的性能。

系統(tǒng)測(cè)試很困難，需要?jiǎng)?chuàng)造性。那么，系統(tǒng)測(cè)試應(yīng)該由誰來進(jìn)行呢？可以肯定以下人員、機(jī)構(gòu)不能進(jìn)行系統(tǒng)測(cè)試：

(1)系統(tǒng)開發(fā)人員不能進(jìn)行系統(tǒng)測(cè)試。

(2)系統(tǒng)開發(fā)組織不能負(fù)責(zé)系統(tǒng)測(cè)試。

之所以如此，第一個(gè)原因是，進(jìn)行系統(tǒng)測(cè)試的人必須善于從用戶的角度考慮問題，他最好能徹底了解用戶的看法和環(huán)境，了解軟件的使用。

2.4.4驗(yàn)收測(cè)試

驗(yàn)收測(cè)試的主要任務(wù)包括：

(1)明確規(guī)定驗(yàn)收測(cè)試通過的標(biāo)準(zhǔn)；

(2)確定驗(yàn)收測(cè)試方法；

(3)確定驗(yàn)收測(cè)試的組織和可利用的資源；

(4)確定測(cè)試結(jié)果的分析方法；

(5)制定驗(yàn)收測(cè)試計(jì)劃并進(jìn)行評(píng)審；

(6)設(shè)計(jì)驗(yàn)收測(cè)試的測(cè)試用例；

(7)審查驗(yàn)收測(cè)試的準(zhǔn)備工作；

(8)執(zhí)行驗(yàn)收測(cè)試；

(9)分析測(cè)試結(jié)果，決定是否通過驗(yàn)收。

2.5黑盒測(cè)試和白盒測(cè)試

黑盒測(cè)試和白盒測(cè)試是兩類廣泛使用的軟件測(cè)試方法。黑盒測(cè)試又稱功能測(cè)試或基于規(guī)格說明的測(cè)試。黑盒測(cè)試的基本觀點(diǎn)是：任何程序都可以看做從輸入定義域映射到輸出值域的函數(shù)。這種觀點(diǎn)將被測(cè)程序看做一個(gè)打不開的黑盒，黑盒的內(nèi)容(實(shí)現(xiàn))是完全不知道的，只知道軟件要做什么。因無法看到盒子中的內(nèi)容，所以不知道軟件是如何運(yùn)作的以及為什么會(huì)這樣。

在用黑盒測(cè)試方法設(shè)計(jì)測(cè)試用例時(shí)，測(cè)試人員所使用的唯一信息就是軟件的規(guī)格說明，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，只依靠被測(cè)程序輸入和輸出之間的關(guān)系或程序的功能來設(shè)計(jì)測(cè)試用例，推斷測(cè)試結(jié)果的正確性，即所依據(jù)的只是程序的外部特性。因此，黑盒測(cè)試是從用戶觀點(diǎn)出發(fā)的測(cè)試。

白盒測(cè)試又稱結(jié)構(gòu)測(cè)試或基于程序的測(cè)試。白盒測(cè)試將被測(cè)程序看做一個(gè)打開的盒子，測(cè)試人員可以看到被測(cè)的源程序，可以分析被測(cè)程序的內(nèi)部構(gòu)造，這時(shí)測(cè)試人員可以完全不考慮程序的功能，只根據(jù)其內(nèi)部構(gòu)造設(shè)計(jì)測(cè)試用例。

2.5.1黑盒測(cè)試

黑盒測(cè)試是一類重要的軟件測(cè)試方法，它根據(jù)規(guī)格說明設(shè)計(jì)測(cè)試用例，不涉及程序的內(nèi)部結(jié)構(gòu)。因此，黑盒測(cè)試有兩個(gè)顯著的優(yōu)點(diǎn)：

(1)黑盒測(cè)試與軟件具體實(shí)現(xiàn)無關(guān)，所以如果軟件實(shí)現(xiàn)發(fā)生了變化，測(cè)試用例仍然可以使用。

(2)設(shè)計(jì)黑盒測(cè)試用例可以和軟件實(shí)現(xiàn)同時(shí)進(jìn)行，因此可以壓縮項(xiàng)目總的開發(fā)時(shí)間。

黑盒測(cè)試的另一個(gè)問題是功能生成問題。軟件開發(fā)把原始問題變換成計(jì)算機(jī)能處理的形式，需要進(jìn)行一系列的變換，在這一系列變換過程中，每一步都可能得到不同形式的中間結(jié)果。

黑盒測(cè)試以軟件規(guī)格說明為依據(jù)選取測(cè)試數(shù)據(jù)，其正確性依賴于規(guī)格說明的正確性。事實(shí)上，人們不能保證規(guī)格說明完全正確。

2.5.2白盒測(cè)試

白盒測(cè)試(結(jié)構(gòu)測(cè)試)是根據(jù)被測(cè)程序的內(nèi)部結(jié)構(gòu)設(shè)計(jì)測(cè)試用例的一類測(cè)試，具有很強(qiáng)的理論基礎(chǔ)。結(jié)構(gòu)測(cè)試要求對(duì)被測(cè)程序的結(jié)構(gòu)特性做到一定程度的覆蓋，或者說是“基于覆蓋的測(cè)試”。測(cè)試人員可以嚴(yán)格定義要測(cè)試的確切內(nèi)容，明確提出要達(dá)到的測(cè)試覆蓋率，以減少測(cè)試的盲目性，引導(dǎo)測(cè)試人員朝著提高測(cè)試覆蓋率的方向努力，從而找出那些被忽視的程序故障。

語句覆蓋是一種最為常見也是最弱的邏輯覆蓋準(zhǔn)則，它要求設(shè)計(jì)若干個(gè)測(cè)試用例，使被測(cè)程序的每個(gè)語句都至少被執(zhí)行一次。判定覆蓋或分支覆蓋則要求設(shè)計(jì)若干個(gè)測(cè)試用例，使被測(cè)程序的每個(gè)判定的真分支和假分支都至少被執(zhí)行一次。當(dāng)判定含有多個(gè)條件時(shí)，可以要求設(shè)計(jì)若干個(gè)測(cè)試用例，使被測(cè)程序的每個(gè)條件的真、假分支都至少被執(zhí)行一次，這就是條件覆蓋。

2.5.3黑盒測(cè)試與白盒測(cè)試比較

黑盒測(cè)試和白盒測(cè)試是兩種完全不同的測(cè)試方法，可以說，它們的出發(fā)點(diǎn)不同，并且是兩個(gè)完全對(duì)立的出發(fā)點(diǎn)，反映了事物的兩個(gè)極端。它們各有側(cè)重，都有堅(jiān)定的擁護(hù)者。

表2-1給出了黑盒測(cè)試和白盒測(cè)試兩類方法的比較。圖2.8則說明了它們各自的能力范圍及不足。

圖2.8黑盒測(cè)試與白盒測(cè)試的比較

2.6靜態(tài)測(cè)試與動(dòng)態(tài)測(cè)試

原則上講，軟件測(cè)試方法可以分為兩大類：靜態(tài)測(cè)試方法和動(dòng)態(tài)測(cè)試方法。靜態(tài)測(cè)試是指不利用計(jì)算機(jī)運(yùn)行被測(cè)程序，而是通過其他手段達(dá)到檢測(cè)的目的。動(dòng)態(tài)測(cè)試則是指通常意義上的測(cè)試，通過運(yùn)行和使用被測(cè)程序，發(fā)現(xiàn)軟件故障，以達(dá)到檢測(cè)的目的。

這兩種測(cè)試方法可用汽車的檢查過程來打個(gè)比方，踩油門、看車漆、打開前蓋檢查都屬于靜態(tài)測(cè)試技術(shù)，而發(fā)動(dòng)汽車、聽發(fā)動(dòng)機(jī)的聲音、上路行駛則屬于動(dòng)態(tài)測(cè)試技術(shù)。檢查軟件規(guī)格說明屬于靜態(tài)黑盒測(cè)試。軟件規(guī)格說明是書面文檔，不是可以執(zhí)行的程序，軟件測(cè)試人員可以利用書面文檔資料進(jìn)行靜態(tài)黑盒測(cè)試，認(rèn)真查找軟件缺陷，而檢查代碼則屬于靜態(tài)白盒測(cè)試，它們是在不執(zhí)行程序的條件下有條理地仔細(xì)審查軟件設(shè)計(jì)、體系結(jié)構(gòu)和代碼，從而找出軟件故障的過程。

靜態(tài)測(cè)試是對(duì)被測(cè)程序進(jìn)行特性分析的一些方法的總稱。通常在靜態(tài)測(cè)試階段進(jìn)行以下檢測(cè)活動(dòng)：

(1)檢查算法的邏輯正確性，確定算法是否實(shí)現(xiàn)了所要求的功能。

(2)檢查模塊接口的正確性，確定形參的個(gè)數(shù)、數(shù)據(jù)類型，順序是否正確，確定返回值類型及返回值的正確性。

(3)檢查輸入?yún)?shù)是否有合法性檢查。(4)檢查調(diào)用其他模塊的接口是否正確、檢查實(shí)參類型是否正確、實(shí)參個(gè)數(shù)是否正確、返回值是否正確、是否會(huì)誤解返回值所表示的意思。

(4)檢查調(diào)用其他模塊的接口是否正確、檢查實(shí)參類型是否正確、實(shí)參個(gè)數(shù)是否正確、返回值是否正確、是否會(huì)誤解返回值所表示的意思。

(5)檢查是否設(shè)置了適當(dāng)?shù)某鲥e(cuò)處理，以便在程序出錯(cuò)時(shí)能對(duì)出錯(cuò)部分進(jìn)行重做安排，保證其邏輯的正確性。

(6)檢查表達(dá)式、語句是否正確，是否含有二義性。對(duì)于容易產(chǎn)生歧義的表達(dá)式或運(yùn)算符優(yōu)先級(jí)(如，<=、=、>=、&&、++、--?等)可以采用()運(yùn)算符以避免二義性。

(7)檢查常量或全局變量使用是否正確。

(8)檢查標(biāo)識(shí)符的定義是否規(guī)范、一致，變量命名是否能夠見名知意、簡(jiǎn)潔、規(guī)范和容易記憶。

(9)檢查程序風(fēng)格的一致性、規(guī)范性，代碼是否符合行業(yè)規(guī)范，是否所有模塊的代碼風(fēng)格一致、規(guī)范、工整。

(10)檢查代碼是否可以優(yōu)化，算法