基于新信息技術(shù)的軟件測試技術(shù) 課件 蘇秀芝 第1-5章 軟件測試概述-軟件測試過程

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

1.1軟件測試技術(shù)

1.1.1行業(yè)背景

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

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

1.1.2軟件測試的由來

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

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

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

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

1.1.3軟件測試的定義

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

1)測試

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

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

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

2)測試環(huán)境

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

3)缺陷

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

4)測試用例

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

2．軟件測試定義

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

與上述觀點(diǎn)相反，GlenfordJ.Myers認(rèn)為應(yīng)該首先認(rèn)定軟件是有錯(cuò)誤的，然后用測試去發(fā)現(xiàn)盡可能多的錯(cuò)。除此之外，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ò)誤的測試。

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

1.1.4軟件測試的分類

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

1)白盒測試

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

圖1.1白盒測試示例圖

2)黑盒測試

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

圖1.2黑盒測試示例圖

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

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

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

3．按階段劃分

1)單元測試

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

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

2)集成測試

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

3)系統(tǒng)測試

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

4)驗(yàn)收測試

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

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

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

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

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

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

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

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

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

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

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í)，輕者影響用戶使用，重者會構(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)軟件很難理解，很難去使用，速度超慢，測試人員站在最終用戶的角度看到的問題是平常的但不是正確的。

1.2.3軟件Bug的級別

軟件Bug的級別由高到低依次為：

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

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

(3)一般：不會影響整個(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中可以看出，在測試階段修復(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空間探測器事件：MarinerI航空軟件的Bug導(dǎo)致火箭在發(fā)射時(shí)偏離了其預(yù)期軌道，最終導(dǎo)致在大西洋上空將整個(gè)火箭摧毀。

(2)?1995/1996年，致命的ping命令：由于缺乏對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)后，就會死鎖并進(jìn)入所謂的“藍(lán)屏死機(jī)”。這類攻擊也會影響很多使用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è)公眾的噩夢。估計(jì)流通中的300萬到500萬的芯片存在著這樣的缺陷。起初Intel僅僅為那些能夠證明他們確實(shí)有高精度計(jì)算需求的用戶提供了取代奔騰的芯片，最后Intel公司妥協(xié)為任何投訴的人提供替代芯片。該Bug給Intel最終造成了4.75億美元損失。

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

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

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

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

軟件測試具體工作：

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

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

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

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

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

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

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

(8)測試水平提高。

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

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

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

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

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

(2)軟件編程技能。

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

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

2)行業(yè)知識

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

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

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

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

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

(3)耐心：很多測試工作有時(shí)候顯得非常枯燥，需要很大的耐心才可以做好。

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

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

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

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年，國際標(biāo)準(zhǔn)化組織公布的國際標(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)心的，對最終用戶而言，這些質(zhì)量屬性只是間接地促進(jìn)用戶需求的滿足；而運(yùn)行期質(zhì)量屬性是軟件系統(tǒng)在運(yùn)行期間，最終用戶可以直接感受到的一類屬性，這些質(zhì)量屬性直接影響著用戶對軟件產(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ì)量的度量主要針對作為軟件開發(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章軟件測試基礎(chǔ)2.1軟件開發(fā)模型2.2軟件測試的目的和原則2.3軟件測試的模型2.4軟件測試過程2.5黑盒測試和白盒測試2.6靜態(tài)測試與動(dòng)態(tài)測試2.7驗(yàn)證測試與確認(rèn)測試

2.1軟件開發(fā)模型

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

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

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

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

在需求分析階段應(yīng)對開發(fā)的軟件進(jìn)行詳細(xì)的定義，由軟件開發(fā)人員和用戶共同討論決定哪些需求是可以滿足的并且給出確切的描述，寫出軟件需求說明(或稱軟件規(guī)格說明)以及初步的用戶手冊，提交管理機(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ì)，即對每個(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．測試(第五階段)

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

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

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

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

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

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

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

以上6個(gè)階段表明了軟件從開發(fā)直至使用相當(dā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í)施方案，指出如何識別并降低風(fēng)險(xiǎn)。

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

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

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

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

2.2軟件測試的目的和原則

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

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

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

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

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

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

2.2.2軟件測試的原則

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

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

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

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

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

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

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

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

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

2.3軟件測試的模型

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

圖2.3軟件測試中V模型

2．W模型

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

圖2.4軟件測試中W模型

3．H模型

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

2.4軟件測試過程

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

2.4.1單元測試

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

單元測試又稱為模塊測試。模塊并沒有嚴(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é)同工作。

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

2.4.2集成測試

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

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

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

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

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

組織集成測試的方法有兩種：

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

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

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

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

2.4.3系統(tǒng)測試

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

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

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

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

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

2.4.4驗(yàn)收測試

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

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

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

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

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

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

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

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

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

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

2.5黑盒測試和白盒測試

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

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

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

2.5.1黑盒測試

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

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

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

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

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

2.5.2白盒測試

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

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

2.5.3黑盒測試與白盒測試比較

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

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

圖2.8黑盒測試與白盒測試的比較

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

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

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

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

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

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

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

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

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

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

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

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

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

(10)檢查代碼是否可以優(yōu)化，算法效率是否最高。

(11)檢查代碼是否清晰、簡潔和容易理解(注意：冗長的程序并不一定是不清晰的)。

(12)檢查模塊內(nèi)部注釋是否完整，是否正確地反映了代碼的功能。錯(cuò)誤的注釋比沒有注釋更糟。

靜態(tài)測試并不是編譯程序所能代替的。靜態(tài)測試可以完成以下工作：

(1)可以發(fā)現(xiàn)程序缺陷。程序缺陷包括：

①錯(cuò)用了局部變量和全程變量；

②不匹配的參數(shù)；

③不適當(dāng)?shù)难h(huán)嵌套和分支嵌套，不適當(dāng)?shù)奶幚眄樞颍?/p>

④無終止的死循環(huán)；

⑤未定義的變量；

⑥不允許的遞歸；

⑦調(diào)用不存在的子程序；

⑧遺漏了標(biāo)號或代碼；

⑨不適當(dāng)?shù)倪B接。

(2)找到問題的根源。其問題的根源包括：

①未使用過的變量；

②不會執(zhí)行到的代碼；

③未引用過的標(biāo)號；

④可疑的計(jì)算；

⑤潛在的死循環(huán)。

(3)提供程序缺陷的間接信息。其間接信息包括：

①所用變量和常量的交叉引用表；

②標(biāo)識符的使用方式；

③過程的調(diào)用層次；

④是否違背編碼規(guī)則。

2.7驗(yàn)證測試與確認(rèn)測試

軟件包括程序以及開發(fā)、使用和維護(hù)程序所需的所有文檔。程序只是軟件產(chǎn)品的一個(gè)組成部分，表現(xiàn)在程序中的故障，并不一定是由編碼所引起的。實(shí)際上，軟件需求分析、設(shè)計(jì)和實(shí)施階段都是軟件故障的主要來源。因此，軟件測試不僅包含對代碼的測試，而且包含對軟件文檔和其他非執(zhí)行形式的測試。

所謂驗(yàn)證，是指確定軟件開發(fā)的每個(gè)階段、每個(gè)步驟的產(chǎn)品是否正確無誤，是否與其前面開發(fā)階段和開發(fā)步驟的產(chǎn)品相一致。驗(yàn)證工作意味著在軟件開發(fā)過程中開展一系列活動(dòng)，旨在確保軟件能夠正確無誤地實(shí)現(xiàn)軟件的需求。驗(yàn)證就是對諸如軟件需求規(guī)格說明、設(shè)計(jì)規(guī)格說明和代碼之類的產(chǎn)品進(jìn)行評估、審查和檢查的過程，屬于靜態(tài)測試。如果是針對代碼，就是代碼的靜態(tài)測試——代碼評審，而不是動(dòng)態(tài)執(zhí)行代碼。驗(yàn)證測試可應(yīng)用到開發(fā)早期一切可以被評審的事物上，以確保該階段的產(chǎn)品是所期望的。

確認(rèn)測試則只能通過運(yùn)行代碼來完成。按照IEEE/ANSI的定義，確認(rèn)測試是在開發(fā)過程中或結(jié)束時(shí)，對系統(tǒng)或部分系統(tǒng)進(jìn)行評估以確定其是否滿足需求規(guī)格說明的過程。

所謂確認(rèn)，是指確定最后的軟件產(chǎn)品是否正確無誤。比如，編寫出的程序與軟件需求和用戶提出的要求是否符合，或者說程序輸出的信息是否用戶所要求的信息，這個(gè)程序在整個(gè)系統(tǒng)環(huán)境中能否正確穩(wěn)定地運(yùn)行。正式的確認(rèn)包括實(shí)際軟件或仿真模型的運(yùn)行，確認(rèn)是“基于計(jì)算機(jī)的測試”過程，屬于動(dòng)態(tài)測試。

實(shí)際上，測試?=?驗(yàn)證?+?確認(rèn)。將測試分為驗(yàn)證與確認(rèn)的這種分類方法的確認(rèn)測試包括前述的單元測試、集成測試、確認(rèn)測試和系統(tǒng)測試。

1)在驗(yàn)證測試計(jì)劃中要考慮的問題

在驗(yàn)證測試計(jì)劃中要考慮：

(1)將進(jìn)行的驗(yàn)證活動(dòng)的種類(需求驗(yàn)證、功能設(shè)計(jì)驗(yàn)證、詳細(xì)設(shè)計(jì)驗(yàn)證還是代碼驗(yàn)證)；

(2)使用的方法(審查、走查等)；

(3)產(chǎn)品中要驗(yàn)證的和不要驗(yàn)證的范圍；

(4)沒有驗(yàn)證的部分所承擔(dān)的風(fēng)險(xiǎn)；

(5)產(chǎn)品需優(yōu)先驗(yàn)證的范圍；

(6)與驗(yàn)證相關(guān)的資源、進(jìn)度、設(shè)備、工具和責(zé)任。

2)在確認(rèn)測試計(jì)劃中要考慮的問題

在確認(rèn)測試計(jì)劃中要考慮：

(1)測試方法；

(2)測試工具；

(3)支撐軟件(開發(fā)和測試共享)；

(4)配置管理；

(5)風(fēng)險(xiǎn)(預(yù)算、資源、進(jìn)度和培訓(xùn))。

總之，驗(yàn)證和確認(rèn)是互相補(bǔ)充的，它們保證了最終軟件產(chǎn)品的正確性、完全性和一致性。第3章黑盒測試3.1等價(jià)類測試3.2邊界值測試3.3基于判定表的測試3.4基于因果圖的測試3.5基于場景的測試3.6其他黑盒測試3.7測試用例的編寫

3.1等?價(jià)?類?測?試

等價(jià)類測試是一種典型的黑盒測試方法，也是一種非常實(shí)用的測試方法，如圖3.1所示。使用這一方法時(shí)，完全不考慮程序的內(nèi)部結(jié)構(gòu)，只依據(jù)程序的規(guī)格說明來設(shè)計(jì)測試用例。

圖3.1等價(jià)類測試方法

3.1.1等價(jià)類的概念

由于窮舉測試工作量太大，以至于無法實(shí)際完成，促使我們在大量的可能數(shù)據(jù)中選取其中一部分作為測試用例。

等價(jià)劃分的方法是把程序的域劃分為若干部分，然后從每個(gè)部分中選取少數(shù)代表性數(shù)據(jù)作為測試用例。每一類的代表性數(shù)據(jù)在測試中的用途等價(jià)于這一類中的其他值，也就是說，如果在某一類中的一個(gè)例子中發(fā)現(xiàn)了錯(cuò)誤，則在這一等價(jià)類中的其他例子中也能發(fā)現(xiàn)同樣的錯(cuò)誤；反之，如果在某一類中的一個(gè)例子中沒有發(fā)現(xiàn)錯(cuò)誤，則這一類中的其他例子也不會被查出錯(cuò)誤(除非等價(jià)類中的某些例子屬于另一個(gè)等價(jià)類，因?yàn)閹讉€(gè)等價(jià)類是可能相交的)。

類是指某個(gè)輸入域的子集合。在該子集合中，各個(gè)輸入數(shù)據(jù)對于揭露程序中的錯(cuò)誤是等效的，并合理假定：測試某等價(jià)類的代表值就等于測試這一類其他值。

因此，可以把全部輸入數(shù)據(jù)合理地劃分為若干等價(jià)類，在每一個(gè)等價(jià)類中取一個(gè)數(shù)據(jù)作為測試的輸入條件，就可以用少量代表性的測試數(shù)據(jù)取得較少的測試結(jié)果。等價(jià)劃分有兩種不同的情況：有效等價(jià)類和無效等價(jià)類。

(1)有效等價(jià)類：指對于程序的規(guī)格說明來說是合理的、有意義的輸入數(shù)據(jù)構(gòu)成的集合。利用有效等價(jià)類可檢查程序是否實(shí)現(xiàn)了規(guī)格說明中所規(guī)定的功能和性能。

(2)無效等價(jià)類：與有效等價(jià)類的定義相反。

3.1.2等價(jià)類測試的類型

為了便于理解，以下討論涉及兩個(gè)變量X1和X2的函數(shù)F。如果函數(shù)F實(shí)現(xiàn)為一個(gè)程序，則輸入變量X1和X2將擁有以下邊界，以及邊界內(nèi)的區(qū)間：

a≤X1≤d，區(qū)間為[a，b)，[b，c)，[c，d]

e≤X2≤g，區(qū)間為[e，f)，[f，g]

其中方括號和圓括號分別表示閉區(qū)間和開區(qū)間的端點(diǎn)。X1，X2的無效值是X1＜a，X1＞d，X2＜e，X2＞g。以此作為例子，我們將進(jìn)一步討論等價(jià)類測試的類型。

1．弱一般等價(jià)類測試

弱一般等價(jià)類測試是指測試用例的設(shè)計(jì)是通過從每個(gè)等價(jià)類(區(qū)間)選擇一個(gè)值來實(shí)現(xiàn)。所謂弱，是指從各個(gè)等價(jià)類中選取值時(shí)只考慮等價(jià)類自身，查出的缺陷屬于“單缺陷”，即單一因素造成的缺陷。其用例如圖3.2所示。

圖3.2弱一般等價(jià)類測試用例

2．強(qiáng)一般等價(jià)類測試

強(qiáng)一般等價(jià)類測試是指設(shè)計(jì)測試用例時(shí)需要考慮等價(jià)類之間的相互作用，選取等價(jià)類的笛卡爾積的元素值來實(shí)現(xiàn)。笛卡爾積可保證兩種意義上的“完備性”：一是覆蓋所有的等價(jià)類；二是有可能輸入組合中的一個(gè)。所謂強(qiáng)，是指考慮了等價(jià)類之間的相互影響，查出的缺陷屬于多種因素造成的“多缺陷”。其用例如圖3.3所示。

圖3.3強(qiáng)一般等價(jià)類測試用例

3．弱健壯等價(jià)類測試

弱健壯等價(jià)類測試是一種考慮了無效值又有單缺陷假設(shè)的測試。

(1)對于有效輸入，使用每個(gè)有效類的一個(gè)值。(就像我們在所謂弱一般等價(jià)類測試中所做的一樣。請注意，這些測試用例中的所有輸入都是有效的。)

(2)對于無效輸入，測試用例將擁有一個(gè)無效值，并保持其余的值都是等效的。(因此，“單缺陷”會造成測試用例失敗。)

按照這種策略產(chǎn)生的測試用例如圖3.4所示。

圖3.4弱健壯等價(jià)類測試用例

4．強(qiáng)健壯等價(jià)類測試

強(qiáng)健壯等價(jià)類測試是指要考慮無效值又要考慮多缺陷假設(shè)的測試。它從所有的等價(jià)類笛卡爾積的每個(gè)元素中獲得測試用例，如圖3.5所示。圖3.5強(qiáng)健壯等價(jià)類測試用例

3.1.3等價(jià)類測試的原則

等價(jià)類測試的原則如下：

(1)在輸入條件規(guī)定了取值范圍的情況下，可以確立一個(gè)有效等價(jià)類(在取值范圍之內(nèi))和兩個(gè)無效等價(jià)類(小于取值范圍和大于取值范圍)。

(2)在輸入條件規(guī)定了取值的個(gè)數(shù)的情況下，可以確立一個(gè)有效等價(jià)類(在取值個(gè)數(shù)范圍之內(nèi))和兩個(gè)無效等價(jià)類(小于取值個(gè)數(shù)和大于取值個(gè)數(shù))。

(3)在輸入條件規(guī)定了輸入值的集合的情況下，可以確立一個(gè)有效等價(jià)類和一個(gè)無效等價(jià)類。

(4)在輸入條件規(guī)定了“必須如何”的條件的情況下，可以確立一個(gè)有效等價(jià)類和一個(gè)無效等價(jià)類。

(5)在輸入條件是一個(gè)布爾量的情況下，可以確立一個(gè)有效等價(jià)類和一個(gè)無效等價(jià)類。

(6)在規(guī)定了輸入數(shù)據(jù)的一組值(假定n個(gè))，并且程序要對每一個(gè)輸入值分別處理的情況下，可以確立n個(gè)有效等價(jià)類和一個(gè)無效等價(jià)類。

(7)在規(guī)定了輸入數(shù)據(jù)必須遵守規(guī)則的情況下，可以確立一個(gè)有效等價(jià)類(符合規(guī)則)和若干個(gè)無效等價(jià)類(從不同角度違反規(guī)則)。

(8)在確知已劃分的等價(jià)類中各元素在程序處理中的方式不同的情況下，則應(yīng)再將該等價(jià)類進(jìn)一步劃分為更小的等價(jià)類。

3.1.4等價(jià)類方法設(shè)計(jì)舉例

例程序規(guī)定，輸入三個(gè)整數(shù)作為三邊的邊長，構(gòu)成三角形。當(dāng)此三角形為一般三角形、等腰三角形、等邊三角形時(shí)，分別作計(jì)算。用等價(jià)類劃分方法為該程序進(jìn)行測試用例設(shè)計(jì)。

解設(shè)a、b、c代表三角形的三條邊。

(1)分析題目中給出的和隱含的對輸入條件的要求：①整數(shù)；②3個(gè)數(shù)；③非零數(shù)；④正數(shù)；⑤兩邊之和大于第三邊；⑥等腰；⑦等邊。

(2)列出等價(jià)類表并編號。仔細(xì)分析三角形問題，可得出其等價(jià)類表，見表3-1。根據(jù)等價(jià)類表，可設(shè)計(jì)覆蓋上述等價(jià)類的測試用例。

(3)列出覆蓋上述等價(jià)類的測試用例，如表3-2所示。

3.2邊?界?值?測?試

3.2.1邊界值分析的概念邊界值分析是通過選擇等價(jià)類邊界的測試。使用邊界值分析設(shè)計(jì)測試用例，應(yīng)先確定邊界情況，通常輸入和輸出等價(jià)類的邊界，應(yīng)當(dāng)選取正好等于、剛剛大于或剛剛小于邊界值作為測試數(shù)據(jù)，而不是選取等價(jià)類中的典型值或任意值作為測試數(shù)據(jù)。

3.2.2選擇測試用例的原則

選擇測試用例的原則如下：

(1)如果輸入條件規(guī)定了值的范圍，則應(yīng)取剛達(dá)到這個(gè)范圍的邊界值，以及剛剛超越這個(gè)范圍的邊界值作為測試輸入數(shù)據(jù)。

(2)如果輸入條件規(guī)定了值的個(gè)數(shù)，則用最大個(gè)數(shù)、最小個(gè)數(shù)、比最小個(gè)數(shù)少一、比最大個(gè)數(shù)多一的數(shù)作為測試數(shù)據(jù)。

(3)根據(jù)規(guī)格說明書的每個(gè)輸出條件，使用前面的原則。

(4)如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合，則應(yīng)選取集合的第一個(gè)元素和最后一個(gè)元素作為測試用例。

(5)如果程序中使用了一個(gè)內(nèi)部數(shù)據(jù)結(jié)構(gòu)，則應(yīng)當(dāng)選擇這個(gè)內(nèi)部數(shù)據(jù)結(jié)構(gòu)的邊界上的值作為測試用例。

(6)分析規(guī)格說明，找出其他可能的邊界條件。

3.2.3邊界值分析設(shè)計(jì)舉例

例三角形問題的邊界值分析測試用例設(shè)計(jì)。

在三角形問題描述中，除了要求邊長是整數(shù)外，沒有給出其他的限制條件。顯然，邊長下界為1，邊長上界可取為100。表3-3給出了其邊界值分析測試用例。

3.3基于判定表的測試

判定表(DecisionTable)，是指用于顯示條件和條件導(dǎo)致動(dòng)作的集合。判定表是分析和表達(dá)多邏輯條件下執(zhí)行不同操作的工具。判定表能夠?qū)?fù)雜的問題按照各種可能的情況全部列舉出來，簡明并避免遺漏。因此，利用判定表能夠設(shè)計(jì)出完整的測試用例。

3.3.1判定表的概念

判定表通常由四個(gè)部分組成，如圖3.6所示。

(1)條件樁(ConditionStub)：列出了問題的所有條件，通常認(rèn)為列出的條件的次序無關(guān)緊要。

(2)動(dòng)作樁(ActionStub)：列出了問題規(guī)定可能采取的操作，這些操作的排列順序沒有約束。

(3)條件項(xiàng)(ConditionEntry)：列出針對它左列條件取值在所有可能情況下的真假值。

(4)動(dòng)作項(xiàng)(ActionEntry)：列出在條件項(xiàng)的各種取值情況下應(yīng)該采取的動(dòng)作。圖3.6判定表結(jié)構(gòu)

根據(jù)規(guī)則說明得到的判定表如表3-4所示。

3.3.2基于判定表的設(shè)計(jì)舉例

書籍閱讀指南中有以下建議：

(1)如果覺得疲倦并且對書的內(nèi)容感興趣，不糊涂的話，回到本章重讀。

(2)如果覺得疲倦并且對書的內(nèi)容感興趣，但糊涂的話，繼續(xù)讀下去。

(3)如果不覺得疲倦并且對書的內(nèi)容感興趣，但糊涂的話，回到本章重讀。

(4)如果覺得疲倦并且對書的內(nèi)容不感興趣，但不糊涂，跳到下一章去閱讀。

(5)如果覺得疲倦并且對書的內(nèi)容不感興趣，但糊涂的話，請停止閱讀，休息。

(6)不疲倦，對書的內(nèi)容感興趣，書中的內(nèi)容不糊涂，繼續(xù)讀下去。

(7)不疲倦，不感興趣，書中內(nèi)容糊涂，跳到下一章去讀。

(8)不疲倦，不感興趣，書中內(nèi)容不糊涂，跳到下一章去讀。

根據(jù)需求將條件樁、條件項(xiàng)、動(dòng)作樁、動(dòng)作項(xiàng)分別列出來，如表3-5所示。

根據(jù)化簡規(guī)則對判定表進(jìn)行化簡：

只要覺得疲憊，那么其他兩項(xiàng)就不再考慮，直接休息，所以表3-5中1～4可以簡化合并成一條“不疲憊且感興趣時(shí)，無論是否糊涂，都直接休息”，簡化以后的測試用例如表3-6所示。

3.4基于因果圖的測試3.4.1因果圖的適用范圍前面介紹的等價(jià)類劃分方法和邊界值分析方法，都是著重考慮輸入條件，但未考慮輸入條件之間的聯(lián)系、相互組合等?？紤]輸入條件之間的相互組合，可能會產(chǎn)生一些新的情況。要檢查輸入條件的組合不是一件容易的事情，即使把所有輸入條件劃分成等價(jià)類，它們之間的組合情況也相當(dāng)多。因此必須考慮采用一種適合于描述對于多種條件的組合，相應(yīng)產(chǎn)生多個(gè)動(dòng)作的形式來考慮設(shè)計(jì)測試用例，這就需要利用因果圖(邏輯模型)。

3.4.2因果圖圖形符號介紹

1．因果圖基本符號

因果圖基本符號如圖3.7所示。圖3.7因果圖基本符號

2．因果圖約束符號

因果圖約束符號如圖3.8所示。圖3.8因果圖約束符號

互斥E：表示不同時(shí)為1，即a、b中至多只有一個(gè)1。

包含I：表示至少有一個(gè)1，即a、b、c中不同時(shí)為零。

唯一O：表示a、b中有且僅有一個(gè)1。

要求R：表示若a=1，則b必須為1，即不可能a=1且b=0。

屏蔽M：表示若a=1，則b必須為0。

3.4.3因果圖法測試用例設(shè)計(jì)舉例

某軟件需求說明書：某段文本中，第一列字符必須是A或B，第二列字符必須是一個(gè)數(shù)字，在此情況下進(jìn)行文件的修改。如果第一列字符不正確，則給出信息L；如果第二列字符不是數(shù)字，則給出信息M。

(1)確定原因和結(jié)果：從大的方面看，第一列和第二列不同的字符會引起不同的結(jié)果，所以初步分析原因結(jié)果如表3-7所示。

(2)確定因果邏輯關(guān)系：如果第一列和第二列都正確，則修改文件；如果第一列不正確，給出信息L；如果第二列不正確，給出信息M。可以得出圖3.9的因果圖。

圖3.9初步因果圖之一

根據(jù)需求描述，原因c1還可以細(xì)分為兩個(gè)原因：第一列字符是A(c11)，第一列字符是B(c12)。因此原因c1其實(shí)也可以看作結(jié)果。把它用因果圖表示出來如圖3.10所示。圖3.10初步因果圖之二

(3)確定約束關(guān)系：從需求描述中可知，原因c11和c12不可能同時(shí)為真，但可以同時(shí)為假，因此滿足排他性約束。這三個(gè)結(jié)果之間沒有掩碼標(biāo)記的約束。完整的因果圖如圖3.11所示。圖3.11完整因果圖

(4)根據(jù)因果圖畫決策表：列出三個(gè)原因所有的狀態(tài)組合，如表3-8所示。

(5)根據(jù)原因分析結(jié)果：分析每一種狀態(tài)對應(yīng)的結(jié)果，并根據(jù)約束關(guān)系，去掉不可能出現(xiàn)的狀態(tài)。本例的c11和c12滿足排他性約束，所以同時(shí)都為1的狀態(tài)不會出現(xiàn)，如表3-9所示。

(6)設(shè)計(jì)測試用例：根據(jù)決策表，列出有效的狀態(tài)組合和結(jié)果，給出對應(yīng)的測試用例，可以單獨(dú)畫一個(gè)表，也可以直接加到?jīng)Q策表中，如表3-10所示。

3.5基于場景的測試

場景測試方法是基于IBM公司提出的RUP(統(tǒng)一建模語言)的測試用例生成方法。該方法從系統(tǒng)分析的結(jié)果——用例出發(fā)，通過對每個(gè)用例的場景進(jìn)行分析，逐步實(shí)現(xiàn)測試用例的構(gòu)造。

根據(jù)圖3.12所示，可以確定以下不同的用例場景。

場景1：基本流；

場景2：基本流、備選流1；

場景3：基本流、備選流1、備選流2；

場景4：基本流、備選流3；

場景5：基本流、備選流3、備選流1；

場景6：基本流、備選流3、備選流1、備選流2；

場景7：基本流、備選流4；

場景8：基本流、備選流3、備選流4。

圖3.12場景測試法流程

3.6其他黑盒測試

3.6.1錯(cuò)誤推測法錯(cuò)誤推測法就是基于經(jīng)驗(yàn)和直覺推測程序中所有可能存在的各種錯(cuò)誤，有針對性地設(shè)計(jì)測試用例的方法。錯(cuò)誤推測法的基本思想是列舉出程序中所有可能存在的錯(cuò)誤和容易發(fā)生錯(cuò)誤的特殊情況，根據(jù)它們選擇測試用例。

例現(xiàn)有一個(gè)學(xué)生標(biāo)準(zhǔn)化考試批閱試卷、產(chǎn)生成績報(bào)告的程序。其規(guī)格說明如下：程序的輸入文件由一些有80個(gè)字符的記錄組成，所有記錄分為3組，如圖3.13所示。

圖3.13程序結(jié)構(gòu)說明

程序的輸出有4個(gè)報(bào)告：

(1)按學(xué)號排列的成績單，列出每個(gè)學(xué)生的成績、名次。

(2)按學(xué)生成績排序的成績單。

(3)平均分?jǐn)?shù)及標(biāo)準(zhǔn)偏差的報(bào)告。

(4)試題分析報(bào)告。按試題號排序，列出各題學(xué)生答對的百分比。

解答一采用邊界值分析方法，分析和設(shè)計(jì)測試用例。分別考慮輸入條件和輸出條件，以及邊界條件。表3-11列出了輸入條件及相應(yīng)的測試用例。

表3-12為輸出條件及測試用例表。

解答二：采用錯(cuò)誤推測法還可補(bǔ)充設(shè)計(jì)一些測試用例。

(1)程序是否把空格作為回答。

(2)在回答記錄中混有標(biāo)準(zhǔn)答案記錄。

(3)除了標(biāo)題記錄外，還有一些記錄的最后一個(gè)字符既不是2也不是3。

(4)有兩個(gè)學(xué)生的學(xué)號相同。

3.6.2基于接口的測試

基于接口的測試根據(jù)模塊和它們相互關(guān)系的特性選擇測試數(shù)據(jù)。

(1)輸入域測試。

(2)特殊值測試。

(3)輸出域測試。

3.6.3基于故障的測試

基于故障的測試目標(biāo)就是要證明某個(gè)規(guī)定的故障不存在于代碼中。

基于故障的測試策略是假設(shè)一組可能會出現(xiàn)的故障，然后設(shè)計(jì)測試用例去證明每個(gè)假設(shè)。

3.6.4基于風(fēng)險(xiǎn)的測試

基于風(fēng)險(xiǎn)的測試是指評估測試的優(yōu)先級，先做高優(yōu)先級的測試，如果時(shí)間或精力不夠，低優(yōu)先級的測試可以暫時(shí)不做。如圖3.14所示圖3.14基于風(fēng)險(xiǎn)測試法結(jié)構(gòu)示意圖

3.6.5比較測試

比較測試是指通過與競爭伙伴產(chǎn)品的比較(如軟件的弱點(diǎn)、優(yōu)點(diǎn)或?qū)嵙?來取長補(bǔ)短，以增強(qiáng)產(chǎn)品的競爭力。

3.7測試用例的編寫

測試用例的編寫遵照ANSI/IEEE892標(biāo)準(zhǔn)，包括：1)用例標(biāo)識用例標(biāo)識是用于引用和定位測試說明的唯一標(biāo)識符，俗稱用例標(biāo)號。2)用例名稱用例名稱是描述被測試系統(tǒng)或模板的名稱。3)用例狀態(tài)用例狀態(tài)用于標(biāo)記此狀態(tài)是通過、失敗等信息。

4)用例描述

用例描述用于詳細(xì)描述測試的步驟及預(yù)期結(jié)果。

以上是一個(gè)測試用例應(yīng)該包括的基本內(nèi)容，為了方便跟蹤和管理用例的執(zhí)行過程、狀態(tài)，還應(yīng)包括設(shè)計(jì)日期、設(shè)計(jì)人員、評審員、是否覆蓋需求等內(nèi)容。

測試用例因每個(gè)公司的標(biāo)準(zhǔn)習(xí)慣及軟件的特性不同，其編寫式樣也會不同。其樣板如表3-13所示。

第4章白盒測試4.1白盒測試簡介4.2白盒測試過程4.3白盒測試任務(wù)4.4邏輯覆蓋4.5邏輯覆蓋測試用例設(shè)計(jì)舉例4.6基本路徑測試法則

4.1白盒測試簡介

白盒測試又稱結(jié)構(gòu)測試、透明盒測試、邏輯驅(qū)動(dòng)測試、基于代碼的測試。其中，盒子指被測試的軟件，白盒指盒子是可視的。白盒測試是一種測試用例設(shè)計(jì)方法，測試人員依據(jù)程序內(nèi)部邏輯結(jié)構(gòu)相關(guān)信息，設(shè)計(jì)或選擇測試用例。白盒測試主要針對被測程序的源代碼，主要用于軟件驗(yàn)證，不考慮軟件的功能實(shí)現(xiàn)，只驗(yàn)證內(nèi)部動(dòng)作是否按照設(shè)計(jì)說明書的規(guī)定進(jìn)行。

1．白盒測試的目的

其測試目的如下：

(1)保證一個(gè)模塊中的所有獨(dú)立路徑至少被使用一次。

(2)對所有邏輯值均需測試TRUE和FALSE。

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

(4)檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性。

2．白盒測試的特點(diǎn)

白盒測試的優(yōu)點(diǎn)如下：

(1)迫使測試人員去仔細(xì)思考軟件的實(shí)現(xiàn)。

(2)可檢測代碼中的每條分支和路徑。

(3)可揭示隱藏在代碼中的錯(cuò)誤。

(4)對代碼的測試比較徹底。

(5)最優(yōu)化。

白盒測試的缺點(diǎn)如下：

(1)昂貴。

(2)無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯(cuò)誤。

(3)不驗(yàn)證規(guī)格的正確性。

3．白盒測試的實(shí)施步驟

(1)測試計(jì)劃階段：根據(jù)需求說明書，制定測試進(jìn)度。

(2)測試設(shè)計(jì)階段：依據(jù)程序設(shè)計(jì)說明書，按照一定規(guī)范化的方法進(jìn)行軟件結(jié)構(gòu)劃分和設(shè)計(jì)測試用例。

(3)測試執(zhí)行階段：輸入測試用例，得到測試結(jié)果。

(4)測試總結(jié)階段：對比測試的結(jié)果和代碼的預(yù)期結(jié)果，分析錯(cuò)誤原因，找到并解決錯(cuò)誤。

4．白盒測試的方法

白盒測試的方法總體上分為靜態(tài)分析和動(dòng)態(tài)分析兩大類。

靜態(tài)分析是一種不通過執(zhí)行程序而進(jìn)行測試的技術(shù)。靜態(tài)分析的關(guān)鍵功能是檢查軟件的表示和描述是否一致，沒有沖突或者沒有歧義。

動(dòng)態(tài)分析的主要特點(diǎn)是當(dāng)軟件系統(tǒng)在模擬的或真實(shí)的環(huán)境中執(zhí)行之前、之中和之后，對軟件系統(tǒng)行為進(jìn)行分析。動(dòng)態(tài)分析包含了程序在受控的環(huán)境下使用特定的期望結(jié)果進(jìn)行正式的運(yùn)行。它顯示了一個(gè)系統(tǒng)在檢查狀態(tài)下是正確還是不正確。在動(dòng)態(tài)分析技術(shù)中，最重要的技術(shù)是路徑和分支測試。后面要介紹的六種覆蓋測試方法屬于動(dòng)態(tài)分析方法。

4.2白盒測試過程

應(yīng)為測試模塊開發(fā)一個(gè)驅(qū)動(dòng)模塊(Driver)和若干個(gè)樁模塊(Stub)，圖4.1給出了一般白盒測試的環(huán)境。驅(qū)動(dòng)模塊在大多數(shù)場合稱為“主程序”，它接收測試數(shù)據(jù)并將這些數(shù)據(jù)傳遞到被測試模塊，被測試模塊被調(diào)用后，“主程序”打印“進(jìn)入/退出”消息。

圖4.1白盒測試環(huán)境

驅(qū)動(dòng)模塊和樁模塊是測試使用的軟件，而不是軟件產(chǎn)品的組成部分，但它需要一定的開發(fā)費(fèi)用。若驅(qū)動(dòng)模塊和樁模塊比較簡單，實(shí)際開銷相對低些。遺憾的是，僅用簡單的驅(qū)動(dòng)模塊和樁模塊不能完成某些模塊的測試任務(wù)，這些模塊的白盒測試只能采用下面討論的綜合測試方法。

提高模塊的內(nèi)聚度可簡化單元測試，如果每個(gè)模塊只能完成一個(gè)，則所需測試用例數(shù)目將顯著減少，模塊中的錯(cuò)誤也更容易被發(fā)現(xiàn)。

4.3白盒測試任務(wù)

白盒測試的任務(wù)主要包括以下幾個(gè)方面。

1．模塊接口測試模塊接口測試是白盒測試的基礎(chǔ)。只有在數(shù)據(jù)能正確流入、流出模塊的前提下，其他測試才有意義。測試接口正確與否應(yīng)該考慮下列因素：(1)輸入的實(shí)際參數(shù)與形式參數(shù)的個(gè)數(shù)是否相同；(2)輸入的實(shí)際參數(shù)與形式參數(shù)的屬性是否匹配；(3)輸入的實(shí)際參數(shù)與形式參數(shù)的量綱是否一致；

(4)調(diào)用其他模塊時(shí)所給實(shí)際參數(shù)的個(gè)數(shù)是否與被調(diào)模塊的形參個(gè)數(shù)相同；

(5)調(diào)用其他模塊時(shí)所給實(shí)際參數(shù)的屬性是否與被調(diào)模塊的形參屬性匹配；

(6)調(diào)用其他模塊時(shí)所給實(shí)際參數(shù)的量綱是否與被調(diào)模塊的形參量綱一致；

(7)調(diào)用預(yù)定義函數(shù)時(shí)所用參數(shù)的個(gè)數(shù)、屬性和次序是否正確；

(8)是否存在與當(dāng)前入口點(diǎn)無關(guān)的參數(shù)引用；

(9)是否修改了只讀型參數(shù)；

(10)對全程變量的定義各模塊是否一致；

(11)是否把某些約束作為參數(shù)傳遞。

如果模塊內(nèi)包括外部輸入/輸出，還應(yīng)該考慮下列因素：

(1)文件屬性是否正確；

(2)?OPEN/CLOSE語句是否正確；

(3)格式說明與輸入/輸出語句是否匹配；

(4)緩沖區(qū)大小與記錄長度是否匹配；

(5)文件使用前是否已經(jīng)打開；

(6)是否處理了文件尾；

(7)是否處理了輸入/輸出錯(cuò)誤；

(8)輸出信息中是否有文字性錯(cuò)誤。

2．模塊局部數(shù)據(jù)結(jié)構(gòu)測試

檢查局部數(shù)據(jù)結(jié)構(gòu)是為了保證臨時(shí)存儲在模塊內(nèi)的數(shù)據(jù)在程序執(zhí)行過程中完整、正確。局部數(shù)據(jù)結(jié)構(gòu)往往是錯(cuò)誤的根源，應(yīng)仔細(xì)設(shè)計(jì)測試用例，力求發(fā)現(xiàn)下面幾類錯(cuò)誤：

(1)不合適或不相容的類型說明；

(2)變量無初值；

(3)變量初始化或缺省值有錯(cuò)；

(4)不正確的變量名(拼錯(cuò)或不正確的截?cái)?；

(5)出現(xiàn)上溢、下溢和地址異常。

3．模塊邊界條件測試

除了局部數(shù)據(jù)結(jié)構(gòu)外，如果可能，單元測試時(shí)還應(yīng)該查清全局?jǐn)?shù)據(jù)(例如FORTRAN的公用區(qū))對模塊的影響。

4．模塊中所有獨(dú)立執(zhí)行通路測試

在模塊中應(yīng)對每一條獨(dú)立執(zhí)行路徑進(jìn)行測試，白盒測試的基本任務(wù)是保證模塊中每條語句至少執(zhí)行一次。設(shè)計(jì)測試用例是為了發(fā)現(xiàn)因錯(cuò)誤計(jì)算、不正確的比較和不適當(dāng)?shù)目刂屏髟斐傻腻e(cuò)誤?；韭窂綔y試和循環(huán)測試是最常用且最有效的測試技術(shù)。

計(jì)算中常見的錯(cuò)誤包括：

(1)誤解或用錯(cuò)了運(yùn)算符優(yōu)先級；

(2)混合類型運(yùn)算；

(3)變量初值錯(cuò)；

(4)精度不夠；

(5)表達(dá)式符號錯(cuò)。

比較判斷與控制流常常緊密相關(guān)，測試用例還應(yīng)致力于發(fā)現(xiàn)下列錯(cuò)誤：

(1)不同數(shù)據(jù)類型的對象之間進(jìn)行比較；

(2)錯(cuò)誤地使用邏輯運(yùn)算符或優(yōu)先級；

(3)因計(jì)算機(jī)表示的局限性，期望理論上相等而實(shí)際上不相等的兩個(gè)量相等；

(4)比較運(yùn)算或變量出錯(cuò)；

(5)循環(huán)終止條件或不可能出現(xiàn)；

(6)迭代發(fā)散時(shí)不能退出；

(7)錯(cuò)誤地修改了循環(huán)變量。

5．模塊的各條錯(cuò)誤處理通路測試

一個(gè)好的設(shè)計(jì)應(yīng)能預(yù)見各種出錯(cuò)條件，并預(yù)設(shè)各種出錯(cuò)處理通路。出錯(cuò)處理通路同樣需要認(rèn)真測試，測試應(yīng)著重檢查下列問題：

(1)輸出的出錯(cuò)信息難以理解；

(2)記錄的錯(cuò)誤與實(shí)際遇到的錯(cuò)誤不相符；

(3)在程序自定義的出錯(cuò)處理段運(yùn)行之前，系統(tǒng)已介入；

(4)異常處理不當(dāng)；

(5)錯(cuò)誤陳述中未能提供足夠的定位出錯(cuò)信息。

4.4邏輯覆蓋

4.4.1覆蓋率的概念覆蓋率是用于度量測試完整性的一個(gè)手段。覆蓋率的種類有很多，經(jīng)常接觸到的覆蓋率是邏輯覆蓋?，F(xiàn)在有越來越多的測試工具能夠支持測試的覆蓋率度量。但是，這些度量本身并不包含測試技術(shù)，它們只是測試技術(shù)有效性的一個(gè)度量。

覆蓋率可以通過一個(gè)比率公式來表示：

公式中的“項(xiàng)”視不同情況而定，對于具體準(zhǔn)則可定義它的語義。

4.4.2邏輯覆蓋測試法

為了下文的舉例描述方便，這里先給出一張程序流程圖，如圖4.2所示。圖4.2程序流程圖

1．語句覆蓋

1)主要特點(diǎn)

語句覆蓋是最起碼的結(jié)構(gòu)覆蓋要求，語句覆蓋要求設(shè)計(jì)足夠多的測試用例，使得程序中每條語句至少被執(zhí)行一次。

(1)優(yōu)點(diǎn)：可以很直觀地從源代碼得到測試用例，無需細(xì)分每條判定表達(dá)式。

(2)缺點(diǎn)：這種測試方法僅僅針對程序邏輯中顯式存在的語句，對于隱藏的條件和可能到達(dá)的隱式邏輯分支，是無法測試的。

2)用例設(shè)計(jì)

如果此時(shí)將A路徑上的語句1→T去掉，那么用例如表4-1所示。

2．判定覆蓋

1)主要特點(diǎn)

判定覆蓋又稱為分支覆蓋，它要求設(shè)計(jì)足夠多的測試用例，使得程序中每個(gè)判定至少有一次為真值，有一次為假值，即程序中的每個(gè)分支至少執(zhí)行一次。每個(gè)判斷的取真、取假至少執(zhí)行一次。

(1)優(yōu)點(diǎn)：判定覆蓋比語句覆蓋要多幾乎一倍的測試路徑，當(dāng)然也就具有比語句覆蓋更強(qiáng)的測試能力。同樣，判定覆蓋也和語句覆蓋一樣簡捷，無需細(xì)分每個(gè)判定就可以得到測試用例。

(2)缺點(diǎn)：往往大部分的判定語句是由多個(gè)邏輯條件組合而成的(如判定語句中包含AND、OR、CASE)，若僅僅判斷其整個(gè)最終結(jié)果，而忽略每個(gè)條件的取值情況，必然會遺漏部分測試路徑。

2)用例設(shè)計(jì)

判定覆蓋測試用例如表4-2所示。

3．條件覆蓋

1)主要特點(diǎn)

條件覆蓋要求設(shè)計(jì)足夠多的測試用例，使得判定中的每個(gè)條件獲得各種可能的結(jié)果，即每個(gè)條件至少有一次為真值，有一次為假值。

(1)優(yōu)點(diǎn)：條件覆蓋比判定覆蓋增加了對符合判定情況的測試及測試路徑。

(2)缺點(diǎn)：要達(dá)到條件覆蓋，需要足夠多的測試用例，但條件覆蓋并不能保證判定覆蓋。條件覆蓋只能保證每個(gè)條件至少有一次為真，而不考慮所有的判定結(jié)果。

2)用例設(shè)計(jì)

條件覆蓋測試用例如表4-3所示。

4．判定/條件覆蓋

1)主要特點(diǎn)

判定/條件覆蓋要求設(shè)計(jì)足夠多的測試用例，使得判定中每個(gè)條件的所有可能結(jié)果至少出現(xiàn)一次，每個(gè)判定本身所有可能結(jié)果也至少出現(xiàn)一次。

(1)優(yōu)點(diǎn)：判定/條件覆蓋滿足判定覆蓋準(zhǔn)則和條件覆蓋準(zhǔn)則，彌補(bǔ)了二者的不足。

(2)缺點(diǎn)：判定/條件覆蓋準(zhǔn)則未考慮條件的組合情況。

2)用例設(shè)計(jì)

判定/條件覆蓋測試用例如表4-4所示。

5．組合覆蓋

1)主要特點(diǎn)

組合覆蓋也叫做條件組合覆蓋，要求設(shè)計(jì)足夠多的測試用例，使得每個(gè)判定中條件結(jié)果的所有可能組合至少出現(xiàn)一次。

(1)優(yōu)點(diǎn)：條件組合覆蓋能夠同時(shí)滿足判定、條件和判定/條件覆蓋，覆蓋率較高。

(2)缺點(diǎn)：線性地增加了測試用例的數(shù)量。

2)用例設(shè)計(jì)

組合覆蓋測試用例如表4-5所示。

6．路徑覆蓋

1)主要特點(diǎn)

路徑覆蓋要求設(shè)計(jì)足夠多的測試用例，以覆蓋程序中所有可能的路徑。

(1)優(yōu)點(diǎn)：這種測試方法可以對程序進(jìn)行徹底的測試，比前面5種的覆蓋面都廣。

(2)缺點(diǎn)：由于路徑覆蓋需要對所有可能的路徑進(jìn)行測試(包括循環(huán)、條件組合、分支選擇等)，那么需要設(shè)計(jì)大量、復(fù)雜的測試用例，使得工作量呈指數(shù)級增長。而在有些情況下，一些執(zhí)行路徑是不可能被執(zhí)行的，如：

2)用例設(shè)計(jì)

路徑覆蓋測試用例如表4-6所示。

4.5邏輯覆蓋測試用例設(shè)計(jì)舉例

在覆蓋率測試中我們將使用一個(gè)計(jì)算器的程序示例，該程序用C++語言編寫，實(shí)現(xiàn)整數(shù)與浮點(diǎn)數(shù)的四則運(yùn)算功能，其界面如圖4.3所示。圖4.3計(jì)算器的程序示例界面

1．測試環(huán)境

1)硬件

普通PC；

CPU：酷睿i3；

內(nèi)存：2GB；

硬盤：1TB。

2)軟件

操作系統(tǒng)：Windows2003Professional中文版；

編譯系統(tǒng)：VisualStudio7.0。

2．測試工具

我們使用AppliedMicrosystemsCorporation公司的CodeTest3.5作為測試工具，但由于篇幅所限，將針對其中的一個(gè)主要函數(shù)“CCacl2Dlg::OnGo()”設(shè)計(jì)測試用例，該函數(shù)響應(yīng)用戶點(diǎn)擊按鈕“=”的操作，完成計(jì)算功能。

4.5.1測試用例設(shè)計(jì)

測試用例的步驟如下：

1．以源代碼為基礎(chǔ)，導(dǎo)出程序的控制流圖

根據(jù)源代碼，導(dǎo)出如圖4.4所示的控制流圖。

圖4.4控制流圖1

2．計(jì)算得到的控制流圖G的環(huán)路復(fù)雜性V(G)

利用在前面給出的計(jì)算控制流圖環(huán)路復(fù)雜性的方法，可以算出

V(G)?=?22(區(qū)域數(shù))?=?21(判斷節(jié)點(diǎn)數(shù))?+?1?=?22

3．確定線性無關(guān)的路徑的基本集

將圖4.4中所示的各節(jié)點(diǎn)加入對應(yīng)編號，得到如圖4.5所示的控制流圖。

圖4.5控制流圖2

其中