基于新信息技術(shù)的軟件測試技術(shù) 課件 第5章 軟件測試過程

第5章軟件測試過程5.1軟件測試過程概述5.2單元測試5.3集成測試5.4系統(tǒng)測試5.5驗(yàn)收測試

5.1軟件測試過程概述

軟件測試過程與軟件開發(fā)過程應(yīng)該是相對應(yīng)的，V模型(圖5.1)表示了軟件開發(fā)與軟件測試的這種對應(yīng)關(guān)系。它反映了測試活動與分析和設(shè)計(jì)的關(guān)系，從左到右描述了基本的開發(fā)過程和測試行為，標(biāo)明了測試工程中存在的不同級別，清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系。

圖5.1軟件開發(fā)的V模型

最初的軟件需求分析定義出軟件的作用范圍、信息域、功能、行為、性能、約束和驗(yàn)收標(biāo)準(zhǔn)，再進(jìn)一步是概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)，然后是編程。在V模型中，單元測試是基于代碼的測試，最初由開發(fā)人員執(zhí)行，以驗(yàn)證其可執(zhí)行程序代碼的各個(gè)部分是否已達(dá)到了預(yù)期的功能要求；集成測試驗(yàn)證了多個(gè)單元之間的集成是否正確，并有針對性地對詳細(xì)設(shè)計(jì)中所定義的各單元之間的接口進(jìn)行檢查；在所有單元測試和集成測試完成后，系統(tǒng)測試開始以客戶環(huán)境模擬系統(tǒng)的運(yùn)行，以驗(yàn)證系統(tǒng)是否達(dá)到了在概要設(shè)計(jì)中所定義的功能和性能，系統(tǒng)測試應(yīng)檢測系統(tǒng)功能、性能的質(zhì)量特性是否達(dá)到了系統(tǒng)要求的指標(biāo)；驗(yàn)收測試確定軟件的實(shí)現(xiàn)是否滿足用戶需要或合同的要求。

5.2單元測試

5.2.1單元測試定義

單元測試(UnitTesting)是指對軟件中的最小可測試單元進(jìn)行檢查和驗(yàn)證。對于單元測試中單元的含義，一般來說，要根據(jù)實(shí)際情況判定其具體含義，如C語言中單元指一個(gè)函數(shù)；Java里單元指一個(gè)類，也可指一個(gè)函數(shù)；圖形化的軟件中可以指一個(gè)窗口或一個(gè)菜單等。總的來說，單元就是人為規(guī)定的最小的被測功能模塊。

在單元測試活動中，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(jìn)行測試，主要工作分為兩個(gè)步驟：人工靜態(tài)檢查和動態(tài)執(zhí)行跟蹤。

單元測試的目標(biāo)是檢查每個(gè)模塊是否正確地實(shí)現(xiàn)了設(shè)計(jì)說明書中的功能、性能、接口和其他設(shè)計(jì)約束要求，以確保每個(gè)單元都被正確地編碼。單元測試的目標(biāo)不僅是測試代碼的功能性，還需確保代碼在結(jié)構(gòu)上的可靠性及健全性，并且能夠在所有條件下正確響應(yīng)。

單元測試需要達(dá)到以下一些具體目標(biāo)：

(1)信息能正確地流入和流出單元；

(2)在單元工作過程中，其內(nèi)部數(shù)據(jù)能否保持完整性，包括內(nèi)部數(shù)據(jù)的形式、內(nèi)容及相互關(guān)系不發(fā)生錯(cuò)誤，也包括全局變量在單元中的處理和影響；

(3)控制數(shù)據(jù)處理的邊界能正確工作；

(4)單元的運(yùn)行能滿足特定的邏輯覆蓋；

(5)對于單元中發(fā)生的錯(cuò)誤，其出錯(cuò)處理措施是有效的。

5.2.2單元測試內(nèi)容

單元測試的主要任務(wù)是解決5個(gè)方面的測試問題，包括模塊接口測試、局部數(shù)據(jù)結(jié)構(gòu)測試、路徑測試、錯(cuò)誤處理測試、邊界測試，如圖5.2所示。

圖5.2單元測試解決5個(gè)方面的問題

1．模塊接口測試

(1)針對模塊接口測試進(jìn)行的檢查，主要涉及以下幾方面的內(nèi)容：

①調(diào)用本模塊的輸入?yún)?shù)是否正確。

②本模塊調(diào)用子模塊時(shí)輸入給子模塊的參數(shù)是否正確。

③輸入的實(shí)際參數(shù)與形式參數(shù)的個(gè)數(shù)是否相同。

④調(diào)用標(biāo)準(zhǔn)函數(shù)的參數(shù)在個(gè)數(shù)、屬性、順序上是否匹配。

⑤全局變量的定義在各個(gè)模塊中是否一致。

⑥是否修改了只讀型參數(shù)。

(2)如果模塊內(nèi)包括外部輸入、輸出，還應(yīng)考慮以下問題：

①文件屬性是否正確。

②是否處理了文件尾。

③是否所有的文件使用前已經(jīng)打開。

④輸出信息有沒有文字性錯(cuò)誤。

⑤對文件結(jié)束條件的判斷和處理是否正確。

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

在模塊工作中，必須測試模塊內(nèi)部的數(shù)據(jù)能否保持完整性，包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式及相互關(guān)系不發(fā)生錯(cuò)誤。對于局部數(shù)據(jù)結(jié)構(gòu)，應(yīng)該在單元測試中注意發(fā)現(xiàn)以下幾類錯(cuò)誤：

(1)不正確的或不一致的類型說明。

(2)錯(cuò)誤的初始化或默認(rèn)值。

(3)錯(cuò)誤的變量名，如拼寫錯(cuò)誤或書寫錯(cuò)誤。

(4)下溢、上溢或者地址錯(cuò)誤。

(5)不相容的數(shù)據(jù)類型。

3．路徑測試

在單元測試中最主要的測試是針對路徑的測試。測試用例必須能夠發(fā)現(xiàn)由于計(jì)算錯(cuò)誤、不正確的判定或不正常的控制而產(chǎn)生的錯(cuò)誤。

應(yīng)選擇適當(dāng)?shù)臏y試用例，對模塊中重要的執(zhí)行路徑進(jìn)行測試。

應(yīng)當(dāng)設(shè)計(jì)測試用例查找由于錯(cuò)誤的計(jì)算、不正確的比較或不正常的控制流而導(dǎo)致的錯(cuò)誤。

對基本執(zhí)行路徑和循環(huán)進(jìn)行測試，可以發(fā)現(xiàn)大量的路徑錯(cuò)誤。

4．錯(cuò)誤處理測試

測試出錯(cuò)處理的重點(diǎn)是模塊在工作中發(fā)生了錯(cuò)誤，其中的出錯(cuò)處理是否有效。檢驗(yàn)程序中的出錯(cuò)處理可能面對的情況有：

(1)對運(yùn)行發(fā)生的錯(cuò)誤簡述得難以理解。

(2)所報(bào)告的錯(cuò)誤與實(shí)際遇到的錯(cuò)誤不一致。

(3)出錯(cuò)后，在錯(cuò)誤處理之前就引起系統(tǒng)的干預(yù)。

(4)例外條件的處理不正確。

(5)提供的錯(cuò)誤信息不足，以至于無法找到錯(cuò)誤的原因。

5．邊界測試

邊界測試是單元測試的最后一步，必須采用邊界值分析方法來設(shè)計(jì)測試用例，認(rèn)真仔細(xì)地測試為限制數(shù)據(jù)處理而設(shè)置的邊界處，檢查模塊是否能夠正常工作。邊界測試主要考慮以下問題：

(1)處理m維數(shù)組的第m個(gè)元素時(shí)是否出錯(cuò)。

(2)運(yùn)算或判斷時(shí)取最大值、最小值時(shí)是否出錯(cuò)。

(3)在m次循環(huán)的第0次、第1次、第n次是否有錯(cuò)誤。

5.2.3單元測試方法

在單元測試階段，應(yīng)使用白盒測試方法和黑盒測試方法對被測單元進(jìn)行測試，其中以白盒測試方法為主。

在單元測試階段以白盒測試方法為主，是指在單元測試階段，白盒測試消耗的時(shí)間、人力、物力等成本一般會大于黑盒測試的成本。白盒測試進(jìn)入的前提條件是測試人員已經(jīng)對被測試對象有了一定的了解，基本上明確了被測試軟件的邏輯結(jié)構(gòu)。黑盒測試要首先了解軟件產(chǎn)品具備的功能和性能等需求，再根據(jù)需求設(shè)計(jì)一批測試用例以驗(yàn)證程序內(nèi)部活動是否符合設(shè)計(jì)要求。

一般說來，由于黑盒測試是從被測單元外部進(jìn)行的測試，成本較低，因此可先對被測單元進(jìn)行黑盒測試，之后再進(jìn)行白盒測試，以彌補(bǔ)黑盒測試的不徹底。

白盒測試和黑盒測試的測試用例設(shè)計(jì)方法如圖5.3所示。圖5.3測試用例設(shè)計(jì)方法

在單元測試中，設(shè)計(jì)測試用例應(yīng)注意以下問題：

(1)測試人員在實(shí)際工作中至少應(yīng)該設(shè)計(jì)能夠覆蓋如下需求的基于功能的單元測試用例：

①測試程序單元的功能是否實(shí)現(xiàn)；

②測試程序單元性能是否滿足要求；

③是否有可選的其他測試特性，如邊界、余量、安全性、可靠性、強(qiáng)度、人機(jī)交互界面等。

(2)無論是白盒測試還是黑盒測試，每個(gè)測試用例都應(yīng)該包含下面4個(gè)關(guān)鍵元素：

①被測單元模塊初始狀態(tài)聲明，即測試用例的開始狀態(tài)(僅適用于被測單元維持了調(diào)用中間狀態(tài)的情況)；

②被測單元的輸入，包含由被測單元讀入的任何外部數(shù)據(jù)值；

③該測試用例實(shí)際測試的代碼，用被測單元的功能和測試用例設(shè)計(jì)中使用的分析來說明，如：單元中哪一個(gè)決策條件被測試；

④測試用例的期望輸出結(jié)果(在測試進(jìn)行之前的測試說明中定義)。

5.2.4單元測試環(huán)境

一般情況下，單元測試常常緊接在代碼編寫之后。完成了程序編寫、復(fù)查、語法正確性驗(yàn)證之后，就應(yīng)進(jìn)行單元測試。

對每個(gè)模塊進(jìn)行單元測試時(shí)，不能完全忽視它們和周圍模塊的相互關(guān)系。為模擬這一聯(lián)系，在進(jìn)行單元測試時(shí)，需要設(shè)置若干輔助測試模塊。輔助測試模塊有兩種，一種是驅(qū)動模塊(Driver)，另一種是被調(diào)用模擬子模塊(Sub)。

被調(diào)用模擬子模塊又稱為樁模塊，是模擬被測試的模塊所調(diào)用的模塊。被調(diào)用模擬子模塊由被測模塊調(diào)用，它們一般只進(jìn)行很少的數(shù)據(jù)處理，如圖5.4所示。圖5.4驅(qū)動模塊與樁模塊示例圖

單元測試通常被認(rèn)為是附屬于編碼步驟的。其測試環(huán)境如圖5.5所示：一個(gè)驅(qū)動程序只是一個(gè)接收測試數(shù)據(jù)并把數(shù)據(jù)傳送給要測試模塊的構(gòu)件；樁模塊是替代那些隸屬于被測試構(gòu)件的從屬模塊。這就是一般的單元測試環(huán)境。

圖5.5一般單元測試環(huán)境

所測模塊和與其相關(guān)的驅(qū)動模塊及被調(diào)用模擬子模塊構(gòu)成了一個(gè)“測試環(huán)境”。人們在進(jìn)行單元測試時(shí)盡量避免開發(fā)驅(qū)動模塊和樁模塊，尤其應(yīng)避免開發(fā)樁模塊，因?yàn)轵?qū)動模塊開發(fā)的工作量一般少于樁模塊。

5.2.5單元測試過程

1．計(jì)劃階段

測試分析人員應(yīng)根據(jù)軟件測試任務(wù)書(合同或項(xiàng)目計(jì)劃)和被測試軟件的設(shè)計(jì)文檔對被測試軟件單元進(jìn)行分析，并確定以下內(nèi)容：

(1)確定測試充分性的要求，根據(jù)軟件單元的重要性、單元測試的目標(biāo)和約束條件，確定測試用例應(yīng)覆蓋的范圍及每個(gè)范圍所要求的覆蓋程度(如語句覆蓋率、功能覆蓋率以及分支覆蓋率，單元的每一個(gè)軟件特性都至少被一個(gè)正常的測試用例和一個(gè)異常的測試用例分別覆蓋一次)。

(2)確定測試終止的要求，設(shè)定測試過程正常終止的條件(如測試充分性是否達(dá)到要求)，確定導(dǎo)致測試過程異常終止的可能情況(如代碼邏輯錯(cuò)誤)。

(3)確定用于測試的資源要求，包括軟件(如所需要的操作系統(tǒng)、數(shù)據(jù)庫、網(wǎng)絡(luò)服務(wù)、編譯環(huán)境、靜態(tài)分析軟件、測試數(shù)據(jù)產(chǎn)生軟件、測試結(jié)果獲取和處理軟件及測試驅(qū)動軟件等)、硬件(如計(jì)算機(jī)、服務(wù)器、設(shè)備接口、網(wǎng)絡(luò)連接設(shè)備等)、人員配備以及技能素質(zhì)要

求等。

(4)確定需要測試的軟件特性，根據(jù)軟件設(shè)計(jì)文檔的描述確定軟件單元的功能、性能、接口、狀態(tài)、設(shè)計(jì)約束以及數(shù)據(jù)結(jié)構(gòu)等內(nèi)容和要求，進(jìn)行標(biāo)識、分類，從中確定需要進(jìn)行測試的軟件特性。

(5)確定測試需要的技術(shù)和方法，包括測試數(shù)據(jù)輸入/輸出技術(shù)，測試數(shù)據(jù)生成與驗(yàn)證技術(shù)，測試結(jié)果獲取技術(shù)等。

(6)根據(jù)測試任務(wù)書(合同或項(xiàng)目計(jì)劃)的要求和被測試軟件的特性，確定測試結(jié)束的條件。

(7)確定由資源和被測試軟件單元所決定的單元測試活動的進(jìn)度。

2．設(shè)計(jì)實(shí)現(xiàn)階段

軟件單元測試的設(shè)計(jì)和實(shí)現(xiàn)工作由測試設(shè)計(jì)人員和測試程序員共同完成，一般根據(jù)軟件單元測試計(jì)劃完成以下工作：

(1)測試用例的設(shè)計(jì)，將需測試的軟件特性分解，針對分解后的每種情況設(shè)計(jì)測試用例。

(2)獲取測試數(shù)據(jù)，有兩種方式可得到測試數(shù)據(jù)，一種是獲得現(xiàn)有的測試數(shù)據(jù)；另一種是生成新的測試數(shù)據(jù)，并按要求對所獲得的數(shù)據(jù)進(jìn)行驗(yàn)證。

(3)確定測試順序，考慮資源約束、風(fēng)險(xiǎn)管理以及測試用例失效造成的影響或后果等幾個(gè)方面的因素。

(4)獲取測試資源，對于測試所需用到的軟件和硬件，有的可從現(xiàn)有工具中選擇，有的則需要另外研制。

(5)編寫測試程序，包括開發(fā)測試支持工具、單元測試的驅(qū)動模塊與樁模塊。

(6)建立和校準(zhǔn)測試環(huán)境。

(7)編寫軟件單元測試說明文檔。

3．執(zhí)行評估階段

測試人員和測試分析人員要共同執(zhí)行測試。其中測試人員的主要工作是按照軟件單元測試計(jì)劃和軟件單元測試說明的內(nèi)容以及要求執(zhí)行測試。在執(zhí)行過程中，測試人員應(yīng)仔細(xì)觀察和如實(shí)記錄測試過程、測試結(jié)果并努力發(fā)現(xiàn)其中的錯(cuò)誤，認(rèn)真填寫測試記錄。

如果測試用例不通過，測試分析人員應(yīng)認(rèn)真分析其原因，并根據(jù)以下原因采取相應(yīng)的措施：

(1)由于軟件單元測試說明和測試數(shù)據(jù)的錯(cuò)誤導(dǎo)致測試用例不通過時(shí)，需要改正錯(cuò)誤，將被改正的錯(cuò)誤信息詳細(xì)記錄，并重新運(yùn)行該測試。

(2)由于執(zhí)行測試步驟的錯(cuò)誤導(dǎo)致測試用例不通過時(shí)，需要重新運(yùn)行未正確執(zhí)行的測試步驟。

(3)由于測試環(huán)境(包括軟件環(huán)境與硬件環(huán)境)的錯(cuò)誤導(dǎo)致測試用例不通過時(shí)，需要修改測試環(huán)境，將環(huán)境更正信息詳細(xì)記錄下來，重新運(yùn)行該測試。如果不能修正環(huán)境，要記錄相關(guān)原因，并核對終止測試。

(4)由于軟件單元的實(shí)現(xiàn)錯(cuò)誤導(dǎo)致測試用例不能通過時(shí)，要填寫軟件問題報(bào)告單，提出軟件修改建議，然后繼續(xù)進(jìn)行測試；或是比較錯(cuò)誤與異常終止情況，核對終止測試，待軟件更新完畢后，視情況進(jìn)行回歸測試。

(5)由于軟件單元的設(shè)計(jì)錯(cuò)誤導(dǎo)致測試用例不能通過時(shí)，同樣要填寫軟件問題報(bào)告單，提出軟件修改建議，然后繼續(xù)進(jìn)行測試；或是比較錯(cuò)誤與異常終止情況，核對終止測試，待軟件更新完畢后，視情況進(jìn)行回歸測試，并修改相應(yīng)的測試設(shè)計(jì)與測試數(shù)據(jù)。

在對單元測試的結(jié)果進(jìn)行評估時(shí)，測試分析人員應(yīng)根據(jù)被測試設(shè)計(jì)文檔、軟件單元測試說明、測試記錄和軟件問題報(bào)告單等，對測試工作進(jìn)行總結(jié)，主要包括以下內(nèi)容：

(1)總結(jié)軟件單元測試計(jì)劃和軟件單元測試說明變化情況以及原因，記錄在軟件單元測試報(bào)告中。

(2)根據(jù)測試異常終止的情況，確定測試用例未覆蓋到的范圍，并將其理由記錄在測試報(bào)告中。

(3)確定不能解決的測試事件以及不能解決的理由，并將理由記錄在測試報(bào)告中。

(4)總結(jié)測試所反映的軟件單元與軟件設(shè)計(jì)文檔，對軟件單元的設(shè)計(jì)與實(shí)現(xiàn)進(jìn)行評估，并提出改進(jìn)意見，將其記錄在測試報(bào)告中。

(5)編寫軟件單元測試報(bào)告，內(nèi)容包括測試結(jié)果分析、軟件單元的評估以及對軟件單元的改進(jìn)意見。

(6)根據(jù)測試記錄和軟件問題報(bào)告單編寫測試問題報(bào)告。

5.2.6單元測試人員

通常開發(fā)組在組長的監(jiān)督下進(jìn)行，由編寫該單元的開發(fā)設(shè)計(jì)者設(shè)計(jì)所需的測試用例和測試數(shù)據(jù)，來測試該單元并修改缺陷。開發(fā)組組長負(fù)責(zé)保證使用合適的測試技術(shù)，在合理的質(zhì)量控制和監(jiān)督下執(zhí)行充分的測試。實(shí)驗(yàn)表明，單元測試，尤其是對代碼的評審和檢查，能夠充分發(fā)揮開發(fā)組的團(tuán)隊(duì)作用，可以十分有效地找出單元的缺陷。

5.2.7測試工具簡介

目前市場上有很多可以用的單元測試工具。單元測試使用自動化測試工具，可以避免大量的重復(fù)勞動，降低工作強(qiáng)度，并有效地提高測試效率，使測試人員能夠把精力花在更有創(chuàng)造性的工作上。

目前的單元測試工具類型很多，按照測試的范圍和功能，可以分為：靜態(tài)分析工具、代碼規(guī)范審核工具、內(nèi)存和資源檢查工具、測試數(shù)據(jù)生成工具、測試框架工具、測試結(jié)果比較工具、測試度量工具、測試文檔生成和管理工具。

下面分別按編程語言介紹單元測試工具。

1)?C/C++

CppUnit是C++單元測試工具的鼻祖，具有免費(fèi)的開源的單元測試框架。由于已有高人寫了不少關(guān)于CppUnit的很好的文章，想了解CppUnit的朋友，建議讀一下Cpluser所作的《CppUnit測試框架入門》，該文也提供了CppUnit的下載地址。

2)?C++Test

C++Test是Parasoft公司的產(chǎn)品。“C++Test是一個(gè)功能強(qiáng)大的自動化C/C++單元級測試工具，可以自動測試任何C/C++函數(shù)、類，自動生成測試用例、測試驅(qū)動函數(shù)或樁函

數(shù)，在自動化的環(huán)境下極其容易快速地將單元級的測試覆蓋率達(dá)到100%”(引自華唐公司的網(wǎng)頁)。

3)?VisualUnit

VisualUnit簡稱VU，這是國產(chǎn)的單元測試工具，據(jù)說申請了多項(xiàng)專利，擁有一批創(chuàng)新的技術(shù)?！白詣由蓽y試代碼；快速建立功能測試用例程序行為一目了然；極高的測試完整性；高效完成白盒覆蓋；快速排錯(cuò)；高效調(diào)試；詳盡的測試報(bào)告”。(摘自VU開發(fā)商的網(wǎng)頁)。前面所述的測試要求：完成功能測試，完成語句覆蓋、條件覆蓋、分支覆蓋、路徑覆蓋，用VU可以輕松實(shí)現(xiàn)。使用VU還能提高編碼的效率，總體來說，在完成單元測試的同時(shí)，編碼調(diào)試的時(shí)間還能大幅度縮短。

4)?gtest

gtest測試框架是在不同平臺上(Linux，MacOSX，Windows，Cygwin，WindowsCE和Symbian)為編寫C++測試而生成的。它是基于xUnit架構(gòu)的測試框架，支持自動發(fā)現(xiàn)測試，豐富的斷言集，用戶定義的斷言，death測試，致命與非致命的失敗，類型參數(shù)化測試，各類運(yùn)行測試的選項(xiàng)和XML的測試報(bào)告。需要詳細(xì)了解的朋友可以參閱《玩轉(zhuǎn)Google單元測試框架gtest系列》文章。

5)?C#

NUnit是一個(gè)單元測試框架，專門針對于?.NET來寫的。其實(shí)JUnit(Java)、CppUnit(C++)都是xUnit的一員。NUnit是xUnit家族中的第4個(gè)主打產(chǎn)品，完全由C#語言來編寫，并且編寫時(shí)充分利用了許多?.NET的特性，比如反射、客戶屬性等。

6)?Java

JUnit是Java社區(qū)中知名度最高的單元測試工具。它誕生于1997年，由ErichGamma和KentBeck共同開發(fā)完成。其中ErichGamma是經(jīng)典著作《設(shè)計(jì)模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)》一書的作者之一，并在Eclipse中有很大的貢獻(xiàn)；KentBeck則是一位極限編程(XP)方面的專家和先驅(qū)。JUnit設(shè)計(jì)得非常小巧，但是功能卻非常強(qiáng)大，是一個(gè)開發(fā)源代碼的Java測試框架，用于編寫和運(yùn)行可重復(fù)的測試，是用于單元測試框架體系xUnit的一個(gè)實(shí)例(用于java語言)，主要用于白盒測試和回歸測試。

5.3集成測試

5.3.1集成測試的定義把經(jīng)過單元測試的模塊按設(shè)計(jì)要求連接起來，組成所規(guī)定的軟件系統(tǒng)的過程稱為“集成”。集成是多個(gè)單元的聚合，許多單元組合成模塊，而這些模塊又聚合成更大的部分，如子系統(tǒng)或系統(tǒng)。

集成測試(IntegrationTesting)，也叫組裝測試或聯(lián)合測試。在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求(如根據(jù)結(jié)構(gòu)圖)組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測試。實(shí)踐表明，一些模塊雖然能夠單獨(dú)工作，但并不能保證連接起來也能正常工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實(shí)現(xiàn)。

5.3.2測試目標(biāo)

集成測試的目標(biāo)是確保在把各個(gè)子模塊連接起來的時(shí)候，能達(dá)到預(yù)期功能要求，一個(gè)模塊的功能不會對另一個(gè)模塊的功能產(chǎn)生不利影響。

5.3.3集成測試的原則

集成測試的原則如下：

(1)所有公共接口必須被測試到；

(2)關(guān)鍵模塊必須進(jìn)行充分測試；

(3)集成測試應(yīng)當(dāng)按一定層次進(jìn)行；

(4)集成測試策略選擇應(yīng)當(dāng)綜合考慮質(zhì)量、成本和進(jìn)度三者之間的關(guān)系；

(5)集成測試應(yīng)當(dāng)盡早開始，并以概要設(shè)計(jì)為基礎(chǔ)；

(6)在模塊和接口的劃分上，測試人員應(yīng)該和開發(fā)人員進(jìn)行充分溝通。

5.3.4集成測試的策略

1．一次性集成方式(bigbang)

這是一種非增量式組裝方式。也叫做整體拼裝。

使用這種方式，首先對每個(gè)模塊分別進(jìn)行模塊測試，然后再把所有模塊組裝在一起進(jìn)行測試，最終得到要求的軟件系統(tǒng)，如圖5.6所示。

圖5.6一次性集成方式

1)優(yōu)點(diǎn)

(1)可迅速完成集成測試；

(2)需要的樁和樁模塊非常少；

(3)需要的用例是最少的，多個(gè)測試人員可以并行測試；

(4)操作簡單；

(5)資源利用率高。

2)缺點(diǎn)

(1)一次試運(yùn)行成功的可能性不大；

(2)問題定位和修改比較困難；

(3)接口間的交互關(guān)系只被測試到很少的一部分，大量的實(shí)際中會運(yùn)行到的程序執(zhí)行路徑?jīng)]有被測試到；

(4)風(fēng)險(xiǎn)高。

2．增量式集成方式

這種集成方式又稱漸增式集成。增量式集成測試可按不同的次序?qū)嵤?，因而可以有兩種方法，即自頂向下的增量方式和自底向上的增量方式。

1)自頂向下的增量方式

這種集成方式將模塊按系統(tǒng)程序結(jié)構(gòu)，從最頂層程序開始，所有被主程序調(diào)用的下層單元全部使用樁來代替，然后一層一層向下進(jìn)行測試，每層程序調(diào)用的下一層程序單元都要打樁。整個(gè)集成可以按深度優(yōu)先的策略進(jìn)行，也可以按照廣度優(yōu)先的策略進(jìn)行。

自頂向下的集成方式有兩種：深度優(yōu)先集成方式、廣度優(yōu)先集成方式。

(1)深度優(yōu)先集成方式。從最頂層單元開始，持續(xù)向下到下一層，選擇一個(gè)分支，自頂而下一個(gè)一個(gè)地集成這條分支上的所有單元，直到最底層，然后轉(zhuǎn)向另一個(gè)分支，重復(fù)這樣的集成操作直到所有的單元都集成進(jìn)來。

以圖5.7為例，深度優(yōu)先集成方式集成的步驟如下：

①從U1開始，被U1調(diào)用的U2、U3、U4被3個(gè)樁模塊S1、S2、S3代替，基于功能樹，選擇一個(gè)U1的分支，集成自頂而下。在本例中選擇最左面的一個(gè)分支。

②將U1和U2集成，被U2調(diào)用的U5用樁模塊S4代替，U3、U4被S2、S3代替。

③將U1、U2和U5集成，U3、U4用樁模塊S2、S3代替。

④轉(zhuǎn)回到第二級，將U1、U2、U5和U3集成，用S3代替U4。

⑤轉(zhuǎn)回到第二級，將U1、U2、U3、U5和U4集成，用S5代替U6。

⑥將U6與其他模塊集成。圖5.7深度優(yōu)先集成方式

(2)廣度優(yōu)先集成方式。從最頂層單元開始，持續(xù)向下到下一層，一個(gè)個(gè)完成下一層上所有單元集成后，再轉(zhuǎn)向下面一層，重復(fù)這樣的集成操作直到所有的單元都集成進(jìn)來。

以圖5.8為例，廣度優(yōu)先集成方式集成的步驟如下：

①從U1開始測試，被U1調(diào)用的U2、U3、U4被S1、S2、S3這3個(gè)樁模塊代替，集成從左向右進(jìn)行。

②移到下一層，將U1和U2集成，被U2調(diào)用的U5被樁模塊S4代替，U3，U4被S2、S3代替。

③集成U1、U2、U3，U5被S4代替，U4被S3代替。

④集成U1、U2、U3和U4，被U4調(diào)用的U6被S5代替，U5用S4代替。

⑤移到下一層，集成U2、U1、U3、U4和U5，用S5代替U6。

⑥將U6與其他單元集成。圖5.8廣度優(yōu)先集成方式

自頂向下的增量方式集成的優(yōu)點(diǎn)包括：

①較早地驗(yàn)證了主要控制和判斷點(diǎn)；

②按深度優(yōu)先可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能；

③功能較早證實(shí)，帶來信心；

④只需一個(gè)驅(qū)動，減少驅(qū)動器開發(fā)的費(fèi)用；

⑤支持故障隔離。

自頂向下的增量方式集成的缺點(diǎn)包括：

①樁的開發(fā)量大；

②底層驗(yàn)證被推遲；

③底層組件測試不充分。

自頂向下的增量方式集成的適用范圍包括：

①產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定；

②高層接口變化較??；

③底層接口未定義或經(jīng)?？赡鼙恍薷?；

④產(chǎn)品控制組件具有較大的技術(shù)風(fēng)險(xiǎn)，需要盡早被驗(yàn)證；

⑤希望盡早能看到產(chǎn)品的系統(tǒng)功能行為。

2)自底向上的增量方式

這種集成的方式是從程序模塊結(jié)構(gòu)的最底層的模塊開始集成和測試。

因?yàn)槟K是自底向上進(jìn)行組裝，對于一個(gè)給定層次的模塊，它的子模塊(包括子模塊的所有下屬模塊)已經(jīng)組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運(yùn)行子模塊得到。

以圖5.9為例，自底向上的增量方式集成的步驟如下：

①從最底層U5、U3、U6開始，開發(fā)3個(gè)驅(qū)動模塊d1、d2、d3調(diào)用它們；

②用U5集成U2，U6、U4被d4、d5代替；

③將所有單元集成在一起。

圖5.9自底向上的增殖方式

自底向上的增量方式集成的優(yōu)點(diǎn)包括：

①對底層組件行為較早驗(yàn)證；

②工作最初可以并行集成，比自頂向下效率高；

③減少了樁的工作量；

④支持故障隔離。

自底向上的增量方式集成的缺點(diǎn)包括：

①驅(qū)動的開發(fā)工作量大；

②對高層的驗(yàn)證被推遲，設(shè)計(jì)上的錯(cuò)誤不能被及時(shí)發(fā)現(xiàn)。

自底向上的增量方式集成的適用范圍包括：

①底層接口比較穩(wěn)定；

②高層接口變化比較頻繁；

③底層組件較早被完成。

3．三明治集成方式

結(jié)合自底向上和自頂向下兩種集成方法，對于底層模塊采用自底向上的集成方法，對于頂層模塊采用自頂向下的集成方法進(jìn)行測試。

以圖5.10為例，三明治集成方式的步驟如下：

(1)基于功能樹，選擇完全分支/子分支作為集成單元，在本例中，選擇了3個(gè)子樹：

①為了測試U2和U5的集成，開發(fā)一個(gè)驅(qū)動模塊d1。

②開發(fā)兩個(gè)樁S1和S2，測試U1和U3的集成。

③為了測試U4和U6，開發(fā)一個(gè)驅(qū)動模塊d2。圖5.10三明治集成方式

(2)將所有的測試子樹集成在一起。

三明治集成方式集成的優(yōu)點(diǎn)：集合了自頂向下的增量方式和自底向上的增量方式的優(yōu)點(diǎn)。

三明治集成方式集成的缺點(diǎn)：中間層測試不充分。

三明治集成方式集成的適用范圍：適應(yīng)于大部分軟件開發(fā)項(xiàng)目。

5.3.5集成測試過程

一個(gè)測試從開發(fā)到執(zhí)行遵循一個(gè)過程，不同的組織對這個(gè)過程的定義會有所不同。根據(jù)集成測試不同階段的任務(wù)，可以把集成測試劃分為5個(gè)階段：計(jì)劃階段、設(shè)計(jì)階段、實(shí)施階段、執(zhí)行階段、評估階段。其具體流程圖如圖5.11所示。

圖5.11集成測試過程流程圖

集成測試各階段的工作內(nèi)容及流程如表5-1所示。

5.3.6集成測試人員

由于集成測試不是在真實(shí)環(huán)境下進(jìn)行，而是在開發(fā)環(huán)境或是一個(gè)獨(dú)立的測試環(huán)境下進(jìn)行的，所以集成測試所需人員一般從開發(fā)組中選出，在開發(fā)組長的監(jiān)督下進(jìn)行，開發(fā)組長負(fù)責(zé)保證在合理的質(zhì)量控制和監(jiān)督下使用合適的測試技術(shù)執(zhí)行充分的集成測試。

集成測試過程中應(yīng)考慮邀請一個(gè)用戶代表非正式地觀看集成測試。

5.4系統(tǒng)測試

5.4.1系統(tǒng)測試定義系統(tǒng)測試(SystemTesting)是將已經(jīng)確認(rèn)的軟件、計(jì)算機(jī)硬件、外設(shè)、網(wǎng)絡(luò)等其他元素結(jié)合在一起，進(jìn)行信息系統(tǒng)的各種組裝測試和確認(rèn)測試。系統(tǒng)測試是針對整個(gè)產(chǎn)品系統(tǒng)進(jìn)行的測試，目的是驗(yàn)證系統(tǒng)是否滿足了需求規(guī)格的定義，找出與需求規(guī)格不符或與之矛盾的地方，從而提出更加完善的方案。

5.4.2系統(tǒng)測試目標(biāo)

系統(tǒng)測試的主要目標(biāo)是驗(yàn)證系統(tǒng)功能的完整性，保證系統(tǒng)各模塊的功能滿足基本業(yè)務(wù)需求，確保系統(tǒng)測試的活動是按計(jì)劃進(jìn)行的，模塊能正確取得數(shù)據(jù)并處理，各功能流程處理正確。

5.4.3系統(tǒng)測試的主要測試技術(shù)

系統(tǒng)測試一般要完成以下幾種測試。

1．功能測試

功能測試也叫黑盒子測試或數(shù)據(jù)驅(qū)動測試，只需考慮各個(gè)功能，不需要考慮整個(gè)軟件的內(nèi)部結(jié)構(gòu)及代碼，一般從軟件產(chǎn)品的界面、架構(gòu)出發(fā)，按照需求編寫出來的測試

用例，輸入數(shù)據(jù)在預(yù)期結(jié)果和實(shí)際結(jié)果之間進(jìn)行評測，檢查產(chǎn)品是否達(dá)到用戶要求的功能。

需求規(guī)格說明是功能測試的基本輸入。因此應(yīng)先對需求規(guī)格進(jìn)行分析，明確功能測試的重點(diǎn)，可按照如下步驟進(jìn)行：

(1)標(biāo)識所有的功能需求(其中包括隱含的功能需求)。

(2)對所有可能出現(xiàn)的功能異常進(jìn)行分類并分析，再加以標(biāo)識。

(3)對前面表示的功能需求確定優(yōu)先級。

(4)對每個(gè)功能進(jìn)行測試分析，分析其是否可測、采用何種測試方法、測試的入口條件、可能的輸入、預(yù)期輸出等。

(5)確定是否需要開發(fā)腳本或借助工具錄制腳本。

(6)確定要對哪些測試使用自動化測試，對哪些測試使用手工測試。

經(jīng)常進(jìn)行的功能測試項(xiàng)目如下：

(1)頁面鏈接；(2)相關(guān)性；

(3)按鈕的功能是否正確；(4)字符串長度；

(5)字符類型；(6)標(biāo)點(diǎn)符號；

(7)中文字符處理；(8)帶出信息的完整性；

(9)信息重復(fù)情況；(10)刪除功能；

(11)添加和修改是否一致；(12)修改重名；

(13)重復(fù)提交表單；(14)多次使用back鍵的情況；

(15)?search檢查；(16)輸入信息位置；

(17)上傳下載文件；(18)必填項(xiàng)；

(19)快捷鍵；(20)回車鍵。

2．性能測試

性能測試檢驗(yàn)安裝在系統(tǒng)內(nèi)的軟件的運(yùn)行性能。性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負(fù)載條件來對系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測試。負(fù)載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進(jìn)行。通過負(fù)載測試，可確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測試負(fù)載逐漸增加時(shí)系統(tǒng)各項(xiàng)性能指標(biāo)的變化情況。壓力測試是通過確定一個(gè)系統(tǒng)的瓶頸或者不能接受的性能點(diǎn)，來獲得系統(tǒng)能提供的最大服務(wù)級別的測試?？蓮娜齻€(gè)方面進(jìn)行性能測試：應(yīng)用在客戶端的性能測試、應(yīng)用在網(wǎng)絡(luò)上的性能測試和應(yīng)用在服務(wù)器端的性能測試。

1)應(yīng)用在客戶端的性能測試

應(yīng)用在客戶端的性能測試目的是考察客戶端應(yīng)用的性能，測試的入口是客戶端。它主要包括并發(fā)性能測試、疲勞強(qiáng)度測試、大數(shù)據(jù)量測試和速度測試等，其中并發(fā)性能測試是重點(diǎn)。

并發(fā)性能測試的過程是一個(gè)負(fù)載測試和壓力測試的過程，即逐漸增加負(fù)載，直到系統(tǒng)的瓶頸或者不能接受的性能點(diǎn)，通過綜合分析交易執(zhí)行指標(biāo)和資源監(jiān)控指標(biāo)來確定系統(tǒng)并發(fā)性能的過程。

2)應(yīng)用在網(wǎng)絡(luò)上的性能測試

該測試重點(diǎn)是利用成熟先進(jìn)的自動化技術(shù)進(jìn)行網(wǎng)絡(luò)應(yīng)用性能監(jiān)控、網(wǎng)絡(luò)應(yīng)用性能分析和網(wǎng)絡(luò)預(yù)測。下面分別從三個(gè)方面來闡述。

(1)網(wǎng)絡(luò)應(yīng)用性能分析，目的就是準(zhǔn)確展示網(wǎng)絡(luò)帶寬、延遲、負(fù)載和TCP端口的變化是如何影響用戶的響應(yīng)時(shí)間的。

(2)網(wǎng)絡(luò)應(yīng)用性能監(jiān)控，主要用來分析關(guān)鍵應(yīng)用程序的性能，定位問題的根源是在客戶端、服務(wù)器、應(yīng)用程序還是網(wǎng)絡(luò)。

(3)網(wǎng)絡(luò)預(yù)測，主要是從網(wǎng)絡(luò)管理軟件獲取網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)、從現(xiàn)有的流量監(jiān)控軟件獲取流量信息，這樣可以得到現(xiàn)有網(wǎng)絡(luò)的基本結(jié)構(gòu)，并進(jìn)行流量分析和沖突檢測。

3)應(yīng)用在服務(wù)器端的性能測試

該測試主要是采用工具監(jiān)控資源使用情況。實(shí)施測試的目的是實(shí)現(xiàn)服務(wù)器設(shè)備、服務(wù)器操作系統(tǒng)、數(shù)據(jù)庫系統(tǒng)、應(yīng)用在服務(wù)器上的性能的全面監(jiān)控。

3．系統(tǒng)可靠性測試

可靠性測試是指連續(xù)運(yùn)行被測系統(tǒng)，檢查系統(tǒng)運(yùn)行時(shí)的穩(wěn)定程度。

4．系統(tǒng)兼容性測試

兼容性測試是指待測試項(xiàng)目在特定的硬件平臺上、不同的應(yīng)用軟件之間、不同的操作系統(tǒng)平臺上、不同的網(wǎng)絡(luò)等環(huán)境中能正常地運(yùn)行的測試。

在做兼容性測試時(shí)，應(yīng)主要關(guān)注如下幾個(gè)問題：

(1)當(dāng)前系統(tǒng)可能運(yùn)行在哪些不同的操作系統(tǒng)環(huán)境下？

(2)當(dāng)前系統(tǒng)可能與哪些不同類型的數(shù)據(jù)庫進(jìn)行數(shù)據(jù)交換？

(3)當(dāng)前系統(tǒng)可能運(yùn)行在哪些不同的硬件配置的環(huán)境下？

(4)當(dāng)前系統(tǒng)可能需要與哪些軟件系統(tǒng)協(xié)同工作？這些軟件系統(tǒng)可能的版本有哪些？

(5)是否需要綜合測試？

5．恢復(fù)測試

恢復(fù)測試作為一種系統(tǒng)測試，主要關(guān)注導(dǎo)致軟件運(yùn)行失敗的各種條件，并驗(yàn)證其恢復(fù)過程能否正確執(zhí)行。在特定情況下，系統(tǒng)需具備容錯(cuò)能力。另外，系統(tǒng)失效必須在規(guī)定時(shí)間段內(nèi)被更正，否則將會導(dǎo)致嚴(yán)重的經(jīng)濟(jì)損失。

在進(jìn)行恢復(fù)性測試時(shí)，同樣先要進(jìn)行恢復(fù)性測試分析，需考慮如下的主要問題：

(1)恢復(fù)期間的安全性過程；

(2)恢復(fù)處理日志方面的能力；

(3)當(dāng)出現(xiàn)供電問題時(shí)的恢復(fù)能力；

(4)恢復(fù)操作后系統(tǒng)性能是否下降。

6．安全測試

安全測試用來驗(yàn)證系統(tǒng)內(nèi)部的保護(hù)機(jī)制，以防止非法侵入。在安全測試中，測試人員扮演試圖侵入系統(tǒng)的角色，采用各種辦法突破防線。因此系統(tǒng)安全設(shè)計(jì)的準(zhǔn)則是要想方設(shè)法使侵入系統(tǒng)所需的代價(jià)盡可能地昂貴。

7．強(qiáng)度測試

強(qiáng)度測試檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力，檢查系統(tǒng)在極限狀態(tài)下運(yùn)行的時(shí)候性能下降的幅度是否在允許的范圍內(nèi)。

5.4.4系統(tǒng)測試的過程

系統(tǒng)測試的過程如圖5.12所示。圖5.12系統(tǒng)測試的過程

系統(tǒng)測試的幾個(gè)階段：

(1)計(jì)劃階段：制訂測試計(jì)劃。

(2)設(shè)計(jì)階段：對系統(tǒng)進(jìn)行詳細(xì)的測試分析，然后設(shè)計(jì)一些典型的、滿足測試需求的測試用例，同時(shí)給出系統(tǒng)測試的大致過程。

3)實(shí)施階段：使用當(dāng)前的軟件版本進(jìn)行測試腳本的錄制工作，確定軟件的基線。

(4)執(zhí)行階段：根據(jù)系統(tǒng)測試計(jì)劃和事先設(shè)計(jì)好的系統(tǒng)測試用例，以及一定的測試