軟件測(cè)試技術(shù)第4章軟件生存周期中的測(cè)試

1、第4章 軟件生存周期中的測(cè)試 軟件測(cè)試技術(shù)及實(shí)踐詹慧靜 陳燕 段相勇 了解軟件生存周期中軟件測(cè)試的角色和作用 掌握單元測(cè)試的詳細(xì)內(nèi)容和流程 掌握集成測(cè)試的詳細(xì)內(nèi)容和流程 掌握系統(tǒng)測(cè)試的詳細(xì)內(nèi)容和流程 掌握驗(yàn)收測(cè)試的詳細(xì)內(nèi)容和流程 掌握性能測(cè)試的詳細(xì)內(nèi)容和流程 掌握回歸測(cè)試的詳細(xì)內(nèi)容和流程 本章學(xué)習(xí)目標(biāo)軟件測(cè)試V模型軟件測(cè)試W模型軟件生存周期中的各個(gè)測(cè)試階段4.1 軟件生存周期中的測(cè)試概述 回顧：軟件測(cè)試V模型編碼詳細(xì)設(shè)計(jì)概要設(shè)計(jì)需求分析用戶需求單元測(cè)試集成測(cè)試系統(tǒng)測(cè)試驗(yàn)收測(cè)試局限：V模型認(rèn)為測(cè)試是查找軟件運(yùn)行時(shí)出現(xiàn)的錯(cuò)誤，在編碼之后才開(kāi)始，忽視了測(cè)試活動(dòng)對(duì)軟件生存周期中其他階段 4.1 軟件生

2、存周期中的測(cè)試概述 回顧：軟件測(cè)試W模型 W模型強(qiáng)調(diào)測(cè)試貫穿整個(gè)軟件生存周期，測(cè)試的對(duì)象不僅僅是程序代碼，需求分析、系統(tǒng)設(shè)計(jì)等同樣需要測(cè)試，測(cè)試與開(kāi)發(fā)是同步進(jìn)行的。 編碼詳細(xì)設(shè)計(jì)概要設(shè)計(jì)需求分析用戶需求集成實(shí)施交付驗(yàn)收測(cè)試準(zhǔn)備集成測(cè)試系統(tǒng)測(cè)試驗(yàn)收測(cè)試單元測(cè)試系統(tǒng)測(cè)試準(zhǔn)備單元測(cè)試準(zhǔn)備集成測(cè)試準(zhǔn)備4.1 軟件生存周期中的測(cè)試概述 軟件生存周期中的各開(kāi)發(fā)階段對(duì)應(yīng)的不同測(cè)試階段（測(cè)試級(jí)別） 需求系統(tǒng)設(shè)計(jì)概要設(shè)計(jì)詳細(xì)設(shè)計(jì)編碼驗(yàn)收測(cè)試系統(tǒng)測(cè)試集成測(cè)試單元測(cè)試用戶設(shè)計(jì)人員編碼人員軟件開(kāi)發(fā)過(guò)程軟件測(cè)試過(guò)程4.1 軟件生存周期中的測(cè)試概述 在軟件開(kāi)發(fā)的編碼階段為單元測(cè)試做準(zhǔn)備工作，在開(kāi)發(fā)過(guò)程的詳細(xì)設(shè)計(jì)階段對(duì)應(yīng)的

3、測(cè)試活動(dòng)是制定單元測(cè)試方案、設(shè)計(jì)單元測(cè)試用例等。單元測(cè)試主要是對(duì)軟件中的最小可測(cè)試單元（模塊）進(jìn)行檢查和驗(yàn)證。開(kāi)發(fā)過(guò)程的概要設(shè)計(jì)階段對(duì)應(yīng)的是集成測(cè)試。集成測(cè)試主要測(cè)試模塊間的接口定義是否清楚、正確，模塊是否能一起正常工作，集成為一個(gè)完整的系統(tǒng)。開(kāi)發(fā)過(guò)程的系統(tǒng)設(shè)計(jì)階段對(duì)應(yīng)的是系統(tǒng)測(cè)試。系統(tǒng)測(cè)試主要測(cè)試集成后的系統(tǒng)是否達(dá)到系統(tǒng)需求定義的要求，是否存在與系統(tǒng)定義不符合或有矛盾的地方，驗(yàn)證軟件系統(tǒng)的功能和性能等是否滿足項(xiàng)目需求。需求分析階段對(duì)應(yīng)的是驗(yàn)收測(cè)試。驗(yàn)收測(cè)試主要根據(jù)需求規(guī)格說(shuō)明書(shū)測(cè)試軟件產(chǎn)品交付給用戶使用前是否符合產(chǎn)品分析和設(shè)計(jì)預(yù)期的各項(xiàng)要求，用戶是否能確認(rèn)并接受產(chǎn)品。4.1 軟件生存周期中的

4、測(cè)試概述 4.2 單元測(cè)試 單元測(cè)試的定義單元測(cè)試的內(nèi)容單元測(cè)試的目標(biāo)單元測(cè)試的環(huán)境單元測(cè)試所采用的測(cè)試策略和方法單元測(cè)試人員4.2.1 單元測(cè)試的定義單元測(cè)試：組件測(cè)試，是針對(duì)軟件設(shè)計(jì)基本組成部分單元，進(jìn)行檢查和驗(yàn)證的測(cè)試工作，主要檢查被測(cè)單元在語(yǔ)法和邏輯上的錯(cuò)誤。 單元是軟件設(shè)計(jì)中最小的但可獨(dú)立運(yùn)行的單位，通常具有以下特征：1）單元應(yīng)該是可測(cè)試的，可重復(fù)執(zhí)行的。2）有明確的功能定義。3）有明確的性能定義。4）有明確的接口定義，不會(huì)輕易地?cái)U(kuò)展到其他單元。 單元要根據(jù)實(shí)際情況去判定其具體含義：在結(jié)構(gòu)化程序設(shè)計(jì)，如C語(yǔ)言中，單元是一個(gè)過(guò)程或一個(gè)函數(shù)。在面向?qū)ο蟮某绦蛟O(shè)計(jì)，如Java、C+中，單元

5、指一個(gè)類。在第四代程序語(yǔ)言（4GL)中，單元是一個(gè)窗口或一個(gè)菜單等。 單元測(cè)試的重要意義在于：1）單元測(cè)試緊接在軟件編碼實(shí)現(xiàn)之后展開(kāi)，將可能最早發(fā)現(xiàn)軟件Bug，并且付出很低的成本進(jìn)行修改，而在軟件開(kāi)發(fā)的后期階段，Bug的發(fā)現(xiàn)和修改將會(huì)變得十分困難，并要消耗大量的時(shí)間和成本。2）經(jīng)過(guò)測(cè)試的單元會(huì)使得系統(tǒng)集成過(guò)程大大地簡(jiǎn)化，開(kāi)發(fā)人員可以將精力集中在單元之間的交互作用和全局的功能實(shí)現(xiàn)上，節(jié)約了軟件開(kāi)發(fā)時(shí)間，提高了開(kāi)發(fā)效率。在生命周期中盡早地對(duì)軟件產(chǎn)品進(jìn)行測(cè)試將盡可能地保證軟件設(shè)計(jì)效率和質(zhì)量。3）單元測(cè)試是其他測(cè)試的基礎(chǔ)，能發(fā)現(xiàn)后期測(cè)試很難發(fā)現(xiàn)的代碼中的深層次問(wèn)題，好的單元測(cè)試是后期測(cè)試順利進(jìn)行的保障

6、。4）單元測(cè)試大多由程序員來(lái)完成的，因此程序員會(huì)有意識(shí)地將單元軟件單元代碼寫(xiě)得便于測(cè)試和調(diào)用，有助于提高代碼質(zhì)量。4.2.1 單元測(cè)試的定義4.2.2 單元測(cè)試的內(nèi)容 單元測(cè)試一般包括以下五個(gè)方面的內(nèi)容： 1單元接口測(cè)試 軟件單元接口測(cè)試主要檢查軟件單元通過(guò)外部設(shè)備進(jìn)行輸入/輸出操作時(shí)數(shù)據(jù)流是否正確。1）調(diào)用軟件單元時(shí)輸入的實(shí)際參數(shù)與軟件單元的形式參數(shù)在個(gè)數(shù)、屬性、使用單位及順序上是否匹配。2）調(diào)用其他軟件單元時(shí)所給實(shí)際參數(shù)在個(gè)數(shù)、屬性、使用單位及順序上是否與被調(diào)軟件單元的形式參數(shù)匹配。3）調(diào)用內(nèi)部函數(shù)時(shí)所用參數(shù)的個(gè)數(shù)、屬性和順序是否正確。4）是否存在與當(dāng)前入口點(diǎn)無(wú)關(guān)的參數(shù)引用。5）是否修改了

7、只讀型參數(shù)。6）對(duì)全程變量的定義各軟件單元是否一致。7）是否把某些約束作為參數(shù)傳遞。 如果被測(cè)的軟件單元功能還包括外部輸入輸出，那么軟件單元接口測(cè)試還應(yīng)該考慮以下內(nèi)容：1）文件屬性是否正確。2）文件打開(kāi)和關(guān)閉語(yǔ)句是否正確。3）格式說(shuō)明與輸入輸出語(yǔ)句是否匹配。4）緩沖區(qū)大小與記錄長(zhǎng)度是否匹配。5）文件使用前是否已經(jīng)打開(kāi)。6）是否處理了文件尾。7）是否處理了輸入/輸出錯(cuò)誤。8）輸出信息中是否有文字性錯(cuò)誤。9）結(jié)束處理時(shí)是否關(guān)閉了文件。4.2.2 單元測(cè)試的內(nèi)容 2軟件單元局部數(shù)據(jù)結(jié)構(gòu)測(cè)試 測(cè)試軟件單元內(nèi)部局部數(shù)據(jù)結(jié)構(gòu)在程序執(zhí)行過(guò)程中是否完整、正確，內(nèi)部函數(shù)是否運(yùn)行正確。通過(guò)測(cè)試盡可能地發(fā)現(xiàn)以下幾類

8、錯(cuò)誤：1)不合適或不一致的類型說(shuō)明。 2)變量初始化或省缺值有錯(cuò)。 3)不正確的變量名，包括拼寫(xiě)或縮寫(xiě)錯(cuò)誤等。4)出現(xiàn)上溢、下溢和地址異常。4.2.2 單元測(cè)試的內(nèi)容 3軟件單元中執(zhí)行路徑測(cè)試 執(zhí)行路徑測(cè)試是單元測(cè)試的最主要內(nèi)容，目的是為了發(fā)現(xiàn)因錯(cuò)誤計(jì)算、不正確的比較和不適當(dāng)?shù)目刂屏髟斐傻腻e(cuò)誤。執(zhí)行路徑測(cè)試時(shí)常見(jiàn)的錯(cuò)誤如下：1)運(yùn)算符優(yōu)先級(jí)使用不正確。2)混合類型運(yùn)算。 3)算法錯(cuò)。4)變量初始化錯(cuò)誤。 5)運(yùn)算精度不夠。 6)表達(dá)式中不正確的變量或符號(hào)錯(cuò)誤。 4.2.2 單元測(cè)試的內(nèi)容 由于判斷與控制流聯(lián)系緊密，執(zhí)行路徑測(cè)試時(shí)還要注意下列錯(cuò)誤：1)不同數(shù)據(jù)類型的對(duì)象之間進(jìn)行比較。2)使用邏輯

9、運(yùn)算符或優(yōu)先級(jí)使用不正確。3)理論上應(yīng)該相等而實(shí)際上由于計(jì)算機(jī)局限（如精度限制）不能相等的兩個(gè)量。4)比較運(yùn)算或變量出錯(cuò)。5)循環(huán)終止條件不正確或不存在。6)不能退出分友循環(huán)。7)錯(cuò)誤地修改了循環(huán)變量。4.2.2 單元測(cè)試的內(nèi)容 4邊界條件測(cè)試 邊界條件測(cè)試是單元測(cè)試中最重要的一項(xiàng)內(nèi)容。如果邊界測(cè)試執(zhí)行得好，則將極大提高程序健壯性。邊界條件測(cè)試主要考慮以下內(nèi)容：1)軟件單元內(nèi)的一個(gè)n次循環(huán)，應(yīng)是1n，而不是0n。2)由各種比較運(yùn)算確定的比較值出錯(cuò)。3)上溢、下溢和地址異常問(wèn)題。4.2.2 單元測(cè)試的內(nèi)容 5軟件單元錯(cuò)誤處理測(cè)試 設(shè)計(jì)良好的程序應(yīng)該能預(yù)見(jiàn)程序運(yùn)行中各種可能出現(xiàn)的錯(cuò)誤，并預(yù)先設(shè)置相

10、應(yīng)的處理，以便在程序運(yùn)行出錯(cuò)時(shí)，能及時(shí)地重新安排，不至于手足無(wú)措。錯(cuò)誤處理測(cè)試主要檢查以下內(nèi)容： 1)輸出的出錯(cuò)信息難以理解。 2)顯示的錯(cuò)誤與實(shí)際發(fā)生的錯(cuò)誤不一致。 3)出錯(cuò)時(shí)，在程序的出錯(cuò)處理運(yùn)行之前，系統(tǒng)就開(kāi)始介入。 4)異常處理不當(dāng)。5)錯(cuò)誤描述不充分，無(wú)法定位錯(cuò)誤或找出出錯(cuò)的原因。4.2.2 單元測(cè)試的內(nèi)容 4.2.3 單元測(cè)試環(huán)境 單元測(cè)試的對(duì)象是程序的一個(gè)單元，要盡可能地在與軟件的其他部分相隔離的情況下進(jìn)行，但又必須考慮到被測(cè)單元和其他軟件單元的聯(lián)系。 需要引入輔助模塊去模擬與被測(cè)軟件單元關(guān)聯(lián)的其他軟件單元。1)驅(qū)動(dòng)模塊。模擬所測(cè)軟件單元的上級(jí)軟件單元，接收測(cè)試數(shù)據(jù)，并把測(cè)試數(shù)據(jù)

11、傳送給被測(cè)軟件單元，最后再輸出測(cè)試結(jié)果。2)樁模塊。模擬由被測(cè)軟件單元調(diào)用的下級(jí)子軟件單元，它代替由被測(cè)單元所調(diào)用的軟件單元的功能，使被測(cè)軟件單元能繼續(xù)運(yùn)行，同時(shí)樁軟件單元還要進(jìn)行少量的數(shù)據(jù)處理，如打印入口和返回等，以檢驗(yàn)被測(cè)軟件單元與其下級(jí)子軟件單元的接口。單元測(cè)試環(huán)境示意圖： 驅(qū)動(dòng)模塊和樁模塊是為了單元測(cè)試而開(kāi)發(fā)的，在軟件開(kāi)發(fā)結(jié)束后不再使用，不需要與最終產(chǎn)品一起交付給用戶，因此驅(qū)動(dòng)模塊和樁模塊的設(shè)計(jì)要盡量簡(jiǎn)單，避免增加新的錯(cuò)誤而干擾被測(cè)軟件單元的運(yùn)行及測(cè)試結(jié)果判斷。4.2.3 單元測(cè)試環(huán)境 4.2.4 單元測(cè)試的目標(biāo) 單元測(cè)試的主要目標(biāo)是確保被測(cè)軟件單元被正確地編碼，不存在任何差錯(cuò)，結(jié)構(gòu)上

12、可靠且健全，并且能夠在所有條件下正確響應(yīng)。單元測(cè)試的目標(biāo)可具體描述為：1)信息正確地流入和流出被測(cè)軟件單元。2)被測(cè)軟件單元運(yùn)行時(shí)，其內(nèi)部數(shù)據(jù)能保持完整性，即數(shù)據(jù)的形式、內(nèi)容及相互關(guān)系不發(fā)生錯(cuò)誤。3)被測(cè)軟件單元運(yùn)行時(shí)，全局變量在軟件單元中的處理和影響不發(fā)生錯(cuò)誤。4)在邊界地區(qū)，軟件單元運(yùn)行能得到正確的結(jié)果。5)被測(cè)軟件單元的運(yùn)行能覆蓋所有執(zhí)行路徑。6)被測(cè)軟件單元運(yùn)行出錯(cuò)時(shí)，錯(cuò)誤處理措施有效。4.2.5 單元測(cè)試策略 單元測(cè)試采取白盒測(cè)試技術(shù)為主，黑盒測(cè)試技術(shù)為輔的方法。首先對(duì)被測(cè)軟件單元進(jìn)行靜態(tài)分析和代碼審查，然后動(dòng)態(tài)跟蹤，即先進(jìn)行被測(cè)軟件單元代碼的語(yǔ)法檢查，再進(jìn)行邏輯檢查。1單元測(cè)試中的

13、靜態(tài)測(cè)試 靜態(tài)測(cè)試是在不運(yùn)行被測(cè)軟件單元的情況下，通過(guò)人工分析其靜態(tài)特性，即檢查和評(píng)審軟件單元代碼，并對(duì)外部接口和關(guān)鍵代碼進(jìn)行桌面檢查和代碼審查來(lái)發(fā)現(xiàn)錯(cuò)誤。靜態(tài)測(cè)試的項(xiàng)目主要如表所示：靜態(tài)測(cè)試項(xiàng)目備注檢查軟件單元的邏輯正確性所編寫(xiě)的代碼算法、數(shù)據(jù)結(jié)構(gòu)定義（如：隊(duì)列、堆棧等）是否實(shí)現(xiàn)了所要求的功能軟件單元接口的正確性檢查形式參數(shù)個(gè)數(shù)、數(shù)據(jù)類型、順序是否正確。返回值類型及返回值是否正確輸入?yún)?shù)正確性檢查如果沒(méi)有作正確性檢查，確定該參數(shù)是否的確無(wú)需做參數(shù)正確性檢查，否則請(qǐng)?zhí)砑由蠀?shù)的正確性檢查調(diào)用其他方法接口的正確性檢查檢查實(shí)參類型、傳入的參數(shù)值、個(gè)數(shù)是否正確。返回值是否正確，有沒(méi)有誤解返回值檢查出

14、錯(cuò)處理軟件單元代碼是否能預(yù)見(jiàn)出錯(cuò)的條件，并設(shè)置適當(dāng)?shù)某鲥e(cuò)處理檢查表達(dá)式、SQL語(yǔ)句的正確性檢查所編寫(xiě)的SQL語(yǔ)句的語(yǔ)法、邏輯的正確性。表達(dá)式不含二義性檢查常量或全局變量使用的正確性確定常量或全局變量的取值和數(shù)值、數(shù)據(jù)類型。保證常量引用時(shí)的取值、數(shù)值和類型的一致性檢查標(biāo)識(shí)符定義的規(guī)范一致性保證標(biāo)識(shí)符能夠見(jiàn)名知意、簡(jiǎn)潔規(guī)范、容易記憶。保證用相同的標(biāo)識(shí)符代表相同功能檢查程序風(fēng)格是否一致、規(guī)范程序風(fēng)格的一致性、規(guī)范性是否符合軟件編碼規(guī)范檢查代碼是否可以優(yōu)化、算法效率能否提高語(yǔ)句是否可以優(yōu)化，循環(huán)是否必要，循環(huán)中的語(yǔ)句是否可以抽到循環(huán)之外等函數(shù)內(nèi)部注釋檢查函數(shù)內(nèi)部注釋是否完整，是否清晰簡(jiǎn)潔。是否正確的反

15、映了代碼的功能。是否做了多余的注釋4.2.5 單元測(cè)試策略 2單元測(cè)試中的動(dòng)態(tài)測(cè)試動(dòng)態(tài)測(cè)試通常采用白盒測(cè)試技術(shù)，主要完成三項(xiàng)工作:設(shè)計(jì)測(cè)試用例：一般采用邏輯覆蓋法和基本路徑法進(jìn)行設(shè)計(jì)。設(shè)計(jì)測(cè)試類模塊。被測(cè)軟件單元并不是一個(gè)獨(dú)立的程序，測(cè)試時(shí)要考慮測(cè)試它與外界的聯(lián)系，設(shè)計(jì)輔助模塊去模擬與被測(cè)軟件單元相聯(lián)系的其他軟件單元，如前述驅(qū)動(dòng)模塊和樁模塊。3)跟蹤調(diào)試：測(cè)試類設(shè)計(jì)完成后，借助代碼排錯(cuò)工具來(lái)跟蹤調(diào)試待測(cè)代碼段以深入的檢查代碼的邏輯錯(cuò)誤。 對(duì)被測(cè)軟件單元進(jìn)行白盒測(cè)試，主要進(jìn)行如下檢查：1)對(duì)軟件單元內(nèi)所有獨(dú)立的執(zhí)行路徑至少測(cè)試一次。2)對(duì)所有的邏輯判定，取“真”與“假”的兩種情況都至少執(zhí)行一次。

16、3)在循環(huán)的邊界和運(yùn)行界限內(nèi)執(zhí)行循環(huán)體。4)測(cè)試內(nèi)部數(shù)據(jù)的有效性等。 此外，如果被測(cè)單元具有完整的功能，那么動(dòng)態(tài)跟蹤也需要使用黑盒測(cè)試對(duì)被測(cè)軟件單元的功能需求和性能進(jìn)行檢驗(yàn)，測(cè)試過(guò)程如下：1)分析規(guī)格說(shuō)明。2)選擇正常輸入檢查軟件單元是否正確實(shí)現(xiàn)功能設(shè)計(jì)，選擇非正常輸入檢查軟件單元能否正確處理。3)根據(jù)輸入數(shù)據(jù)確定被測(cè)軟件單元的預(yù)期輸出。4)設(shè)計(jì)并執(zhí)行測(cè)試用例，比較實(shí)際結(jié)果和預(yù)期結(jié)果。5)確定被測(cè)軟件單元是否符合規(guī)格說(shuō)明。6)單元測(cè)試的工具4.2.5 單元測(cè)試策略 3單元測(cè)試的工具 單元測(cè)試涉及內(nèi)容眾多，工作量大，有必要借助工具來(lái)減少重復(fù)勞動(dòng)，降低人工工作強(qiáng)度，提高測(cè)試效率。根據(jù)單元測(cè)試的內(nèi)容

17、，單元測(cè)試工具可分為以下幾類：1)靜態(tài)分析工具2)代碼規(guī)范審核工具3)內(nèi)存和資源檢查工具4)測(cè)試數(shù)據(jù)生成工具5)測(cè)試框架工具6)測(cè)試結(jié)果比較工具7)測(cè)試度量工具8)測(cè)試文檔生成和管理工具4.2.5 單元測(cè)試策略 根據(jù)編程語(yǔ)言不同，目前比較常用的自動(dòng)化單元測(cè)試工具有：1)自動(dòng)化C/C+單元測(cè)試工具C+Test C+Test是一個(gè)功能強(qiáng)大的自動(dòng)化C/C+單元級(jí)測(cè)試工具。可以自動(dòng)測(cè)試任何C/C+函數(shù)、類。自動(dòng)生成測(cè)試用例、測(cè)試驅(qū)動(dòng)函數(shù)或樁函數(shù)。在自動(dòng)化的環(huán)境下能快速地將單元級(jí)的測(cè)試覆蓋率達(dá)到100%。其主要特性有：(1)在不需要執(zhí)行程序的情況下識(shí)別運(yùn)行時(shí)缺陷。(2)自動(dòng)化代碼分析以增強(qiáng)兼容性。(3)

18、支持嵌入式和跨平臺(tái)開(kāi)發(fā)。(4)高度的可定制化。(5)提高團(tuán)隊(duì)代碼走查的效率和全面性。(6)為即時(shí)驗(yàn)證和回歸測(cè)試提供自動(dòng)化單元及組件測(cè)試。4.2.5 單元測(cè)試策略 2)XUnit測(cè)試框架 XUnit一個(gè)基于測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的測(cè)試框架，提供了一個(gè)方便在開(kāi)發(fā)過(guò)程中使用測(cè)試驅(qū)動(dòng)的工具，使單元測(cè)試得以快速進(jìn)行。(1)Java環(huán)境單元測(cè)試工具JUnit JUnit是一個(gè)Java語(yǔ)言的單元測(cè)試框架，幾乎所有的Java開(kāi)發(fā)環(huán)境都集成了JUnit作為單元測(cè)試的工具：可以使測(cè)試代碼與產(chǎn)品代碼分開(kāi)。針對(duì)某一個(gè)類的測(cè)試代碼通過(guò)較少的改動(dòng)便可以應(yīng)用于另一個(gè)類的測(cè)試。易于集成到測(cè)試人員的構(gòu)建過(guò)程中。JUnit是公開(kāi)源代碼的，

19、用戶可以進(jìn)行二次開(kāi)發(fā)?？梢苑奖愕貙?duì)JUnit進(jìn)行擴(kuò)展。4.2.5 單元測(cè)試策略 (2) .Net環(huán)境單元測(cè)試工具NUnit NUnit適合于所有.NET語(yǔ)言，可以方便地對(duì).NET組件進(jìn)行單元測(cè)試，可以不修改原代碼而直接編寫(xiě)專門的測(cè)試代碼對(duì)被測(cè)軟件單元進(jìn)行測(cè)試。使用NUnit框架，需要如下工作：使用using聲明引用必要的NUnit類。定義一個(gè)Public的測(cè)試類及一個(gè)public的沒(méi)有參數(shù)的構(gòu)造函數(shù)，在類定義時(shí)添加TestFixtureattribute標(biāo)記。在測(cè)試類中包含使用Testattribute標(biāo)記的方法。4.2.5 單元測(cè)試策略 4單元測(cè)試人員 單元測(cè)試應(yīng)該由開(kāi)發(fā)人員，特別是編程人員

20、或設(shè)計(jì)人員來(lái)完成。因?yàn)閱卧獪y(cè)試采用白盒測(cè)試技術(shù)為主，要深入被測(cè)軟件單元代碼，同時(shí)還要構(gòu)造驅(qū)動(dòng)模塊、樁模塊，具有較強(qiáng)的開(kāi)發(fā)能力和對(duì)代碼最為熟悉的編程人員或設(shè)計(jì)人員具有很大的優(yōu)勢(shì)。 考慮到單元測(cè)試的效果，單元測(cè)試還需要專門測(cè)試組成員參與，因?yàn)椋?1)從目前軟件開(kāi)發(fā)現(xiàn)狀來(lái)看，測(cè)試人員質(zhì)量意識(shí)要高于開(kāi)發(fā)人員，測(cè)試人員參與單元測(cè)試能夠提高測(cè)試質(zhì)量。2)測(cè)試人員參與單元測(cè)試，將使得測(cè)試人員能夠從代碼開(kāi)始熟悉被測(cè)系統(tǒng)，有利于對(duì)后期的集成測(cè)試和系統(tǒng)測(cè)試活動(dòng)。4.2.5 單元測(cè)試策略 4.3 集成測(cè)試 集成測(cè)試的定義 集成測(cè)試的目標(biāo) 集成測(cè)試的內(nèi)容 集成測(cè)試的環(huán)境 集成測(cè)試策略和方案 集成測(cè)試人員4.3.1 集

21、成測(cè)試的定義集成：是指將已經(jīng)通過(guò)單元測(cè)試的多個(gè)軟件單元聚合組成更大的模塊，進(jìn)而將這些模塊又聚合成程序的更大部分，如子系統(tǒng)或系統(tǒng)等。集成測(cè)試：又稱為組裝測(cè)試或聯(lián)合測(cè)試，指檢查軟件組成的各個(gè)單元聚合后其接口是否存在問(wèn)題。它可以看作是單元測(cè)試的邏輯擴(kuò)展，其最簡(jiǎn)單的形式是：把兩個(gè)通過(guò)單元測(cè)試的單元組合成一個(gè)模塊，測(cè)試它們之間的接口。 集成測(cè)試的前提是對(duì)軟件的各個(gè)構(gòu)成單元已經(jīng)開(kāi)展了單元測(cè)試，并根據(jù)單元測(cè)試的結(jié)果完成了對(duì)單元的相應(yīng)修改，即在集成測(cè)試之前，單元測(cè)試應(yīng)該已經(jīng)完成，集成測(cè)試中所使用的對(duì)象應(yīng)該是經(jīng)過(guò)單元測(cè)試的軟件單元。集成測(cè)試是軟件測(cè)試中不可或缺的階段，具有重要的意義：1)對(duì)于軟件單元間接口信息的

22、正確性、相互調(diào)用關(guān)系是否符合設(shè)計(jì)等問(wèn)題，單元測(cè)試無(wú)法完成，只能依靠集成測(cè)試來(lái)進(jìn)行。2)集成測(cè)試用例是從程序結(jié)構(gòu)出發(fā)的，目的性、針對(duì)性更強(qiáng)，定位問(wèn)題的效率更高。3)集成測(cè)試是可重復(fù)的且對(duì)測(cè)試人員而言是透明的，因此發(fā)現(xiàn)問(wèn)題后較容易定位，有利于加快測(cè)試的進(jìn)度。4.3.1 集成測(cè)試的定義4.3.2 集成測(cè)試的目標(biāo) 集成測(cè)試是將所有軟件單元按照設(shè)計(jì)要求組裝成系統(tǒng)的測(cè)試活動(dòng)，其主要目標(biāo)是發(fā)現(xiàn)以下問(wèn)題：1)把各個(gè)模塊連接起來(lái)，驗(yàn)證模塊相互調(diào)用時(shí)，數(shù)據(jù)經(jīng)過(guò)接口時(shí)是否會(huì)丟失。2)一個(gè)模塊的功能是否會(huì)對(duì)另一個(gè)模塊的功能產(chǎn)生影響。3)把各個(gè)子模塊的功能組合起來(lái)，驗(yàn)證是否能達(dá)到預(yù)期的總體功能。4)全局的數(shù)據(jù)結(jié)構(gòu)是否有

23、問(wèn)題。5)共享資源訪問(wèn)是否存在問(wèn)題。6)每個(gè)模塊的誤差累加起來(lái)后是否會(huì)放大到無(wú)法接受的程度。4.3.3 集成測(cè)試的內(nèi)容1.集成功能測(cè)試1）測(cè)試對(duì)象的各項(xiàng)功能是否實(shí)現(xiàn)。不僅要檢查集成單元功能是否實(shí)現(xiàn)和集成后的模塊、子系統(tǒng)或系統(tǒng)的總體功能是否實(shí)現(xiàn)，還要考察在實(shí)現(xiàn)集成后的復(fù)雜功能時(shí)是否衍生或增加了不需要的、錯(cuò)誤的功能。2）是否有針對(duì)異常情況的相關(guān)錯(cuò)誤處理措施3）模塊間的協(xié)作是否高效合理4.3.3 集成測(cè)試的內(nèi)容2接口測(cè)試 模塊間的接口問(wèn)題是集成測(cè)試的最主要內(nèi)容：1)針對(duì)函數(shù)接口，測(cè)試主要關(guān)注函數(shù)接口參數(shù)的類型和個(gè)數(shù)、輸入/輸出屬性和范圍的一致性。2)針對(duì)消息接口，測(cè)試主要關(guān)注消息的發(fā)送和接收雙方對(duì)消

24、息參數(shù)的定義是否一致、消息和消息隊(duì)列長(zhǎng)度是否滿足設(shè)計(jì)要求、消息的完整性如何、消息的內(nèi)存是否在發(fā)送過(guò)程中被非法釋放、有無(wú)對(duì)消息隊(duì)列阻塞進(jìn)行處理等。3全局?jǐn)?shù)據(jù)結(jié)構(gòu)測(cè)試 全局?jǐn)?shù)據(jù)結(jié)構(gòu)通常存在著被非法修改的風(fēng)險(xiǎn)，因此集成測(cè)試應(yīng)針對(duì)全局?jǐn)?shù)據(jù)結(jié)構(gòu)開(kāi)展如下檢查：1)全局?jǐn)?shù)據(jù)結(jié)構(gòu)的值在任意兩次被訪問(wèn)的間隔是否可預(yù)知。2)全局?jǐn)?shù)據(jù)結(jié)構(gòu)的各個(gè)數(shù)據(jù)段的內(nèi)存是否被錯(cuò)誤釋放。3)多個(gè)全局?jǐn)?shù)據(jù)結(jié)構(gòu)間是否存在緩存越界。4)多個(gè)軟件單元對(duì)全局?jǐn)?shù)據(jù)結(jié)構(gòu)的訪問(wèn)是否采用相關(guān)保護(hù)機(jī)制。4.3.3 集成測(cè)試的內(nèi)容4資源測(cè)試 對(duì)資源的測(cè)試分為兩個(gè)方面：共享資源測(cè)試和資源極限使用測(cè)試。主要關(guān)注：1)共享資源是否存在被死鎖的現(xiàn)象。2)共享資

25、源是否存在被過(guò)度利用的情況。3)是否存在對(duì)共享資源的破壞性操作。4)公共資源訪問(wèn)機(jī)制是否完善。 資源極限使用測(cè)試關(guān)注系統(tǒng)資源的極限使用情況、資源極限使用時(shí)的處理，目的是避免軟件系統(tǒng)在資源耗盡的情況下出現(xiàn)系統(tǒng)崩潰。4.3.3 集成測(cè)試的內(nèi)容5性能測(cè)試 根據(jù)測(cè)試對(duì)象的需求和軟件設(shè)計(jì)中的要求，對(duì)測(cè)試對(duì)象的性能指標(biāo)，包括時(shí)間特性、資源特性等進(jìn)行測(cè)試，以便及時(shí)發(fā)現(xiàn)性能瓶頸。6穩(wěn)定性測(cè)試 集成測(cè)試中的穩(wěn)定性測(cè)試主要檢查測(cè)試對(duì)象長(zhǎng)期運(yùn)行后的情況：1)測(cè)試對(duì)象長(zhǎng)期運(yùn)行是否導(dǎo)致資源耗竭。2)測(cè)試對(duì)象長(zhǎng)期運(yùn)行后是否出現(xiàn)性能的明顯下降。3)測(cè)試對(duì)象長(zhǎng)期運(yùn)行是否出現(xiàn)任務(wù)掛起。4.3.3 集成測(cè)試的內(nèi)容4.3.4 集成

26、測(cè)試環(huán)境 集成測(cè)試需要引入輔助模塊去模擬與測(cè)試集成模塊、子系統(tǒng)或系統(tǒng)關(guān)聯(lián)的具有驅(qū)動(dòng)能力的模塊，還需要設(shè)置負(fù)責(zé)監(jiān)控穿越測(cè)試模塊間接口數(shù)據(jù)流的程序模塊，即：1)驅(qū)動(dòng)模塊。模擬被測(cè)試集成模塊、子系統(tǒng)或系統(tǒng)的上級(jí)模塊，接收測(cè)試數(shù)據(jù)，并把測(cè)試數(shù)據(jù)傳送給被測(cè)軟件單元，最后再輸出測(cè)試結(jié)果。由于測(cè)試模塊、子系統(tǒng)或系統(tǒng)是由軟件單元集成而得，除了組成的各個(gè)單元外，沒(méi)有其他測(cè)試對(duì)象之外的接口，因此可以重用單元測(cè)試中的驅(qū)動(dòng)模塊。2)樁模塊：模擬由被測(cè)試集成模塊、子系統(tǒng)或系統(tǒng)調(diào)用的下級(jí)子模塊，同樣可以重用單元測(cè)試中的驅(qū)動(dòng)模塊。3)監(jiān)控模塊：用于讀取和記錄測(cè)試模塊、子系統(tǒng)或系統(tǒng)之間的數(shù)據(jù)流情況。4.3.4 集成測(cè)試環(huán)境4

27、.3.5 集成測(cè)試策略1集成測(cè)試策略 集成測(cè)試首先需要完成的是模塊分析，即如何合理地劃分測(cè)試模塊，這將直接影響到集成測(cè)試工作量、進(jìn)度和質(zhì)量。通常，測(cè)試模塊的劃分應(yīng)遵循以下原則：1)根據(jù)本次測(cè)試的目的確定測(cè)試模塊。 2)集成與該模塊最緊密的模塊。3)該模塊的外圍模塊與集成模塊之間的通信應(yīng)該是易于模擬和控制的。 根據(jù)劃分后模塊的業(yè)務(wù)復(fù)雜程度和功能的重要性，可以將測(cè)試模塊分為高危模塊、一般模塊和低危模塊，其中高危模塊應(yīng)該被優(yōu)先測(cè)試。4.3.5 集成測(cè)試策略2集成測(cè)試方案1)非增量式集成測(cè)試 非增量式集成測(cè)試方案的思路是先對(duì)所有要集成的模塊進(jìn)行個(gè)別的單元測(cè)試后，按程序結(jié)構(gòu)圖將各模塊聯(lián)接起來(lái)，把聯(lián)接后的

28、程序當(dāng)作一個(gè)整體進(jìn)行測(cè)試，即先分散測(cè)試，再集中起來(lái)一次完成集成測(cè)試。典型的測(cè)試方法是大爆炸集成測(cè)試。2)增量式集成測(cè)試 增量式集成測(cè)試方案的思路是逐步把下一個(gè)要被組裝的軟件單元，同已測(cè)試好的模塊結(jié)合起來(lái)測(cè)試，即逐步集成，逐步測(cè)試。 增量式集成測(cè)試有兩種方法：自頂向下集成測(cè)試和自底向上集成測(cè)試。(1)自頂向下集成測(cè)試 根據(jù)自頂向下的集成模式進(jìn)行的，即從最頂層模塊（主控模塊）開(kāi)始，按軟件結(jié)構(gòu)圖自上而下地逐漸加入下層模塊。具體步驟如下：以主控模塊作為測(cè)試驅(qū)動(dòng)模塊，把對(duì)主控模塊進(jìn)行單元測(cè)試時(shí)引入的所有樁模塊用實(shí)際模塊代替。依據(jù)所選擇的集成策略（深度優(yōu)先或廣度優(yōu)先），每次只替代一個(gè)樁模塊。每集成一個(gè)模塊

29、就測(cè)試一遍。在每組測(cè)試完成后，再開(kāi)始集成下一個(gè)樁模塊。不斷地進(jìn)行回歸測(cè)試，直到整個(gè)系統(tǒng)結(jié)構(gòu)被集成完成。4.3.5 集成測(cè)試策略 深度優(yōu)先是根據(jù)軟件結(jié)構(gòu)圖縱向考慮，層次多的分支優(yōu)先測(cè)試。自頂向下增量集成測(cè)試（深度優(yōu)先）案例：s2s24.3.5 集成測(cè)試策略廣度優(yōu)先是根據(jù)軟件結(jié)構(gòu)圖從橫向考慮，總是先測(cè)試下一級(jí)的模塊。自頂向下增量集成測(cè)試（廣度優(yōu)先）案例：4.3.5 集成測(cè)試策略(2)自底向上集成測(cè)試 根據(jù)自底向上的集成模式進(jìn)行的，即從最底層模塊開(kāi)始，按軟件結(jié)構(gòu)圖自下而上地逐漸加入上層模塊。因?yàn)闇y(cè)試到較高層模塊時(shí)，所需的下層模塊功能均已具備，所以不再需要樁模塊。具體步驟如下：把低層模塊組織成實(shí)現(xiàn)某個(gè)

30、子功能的模塊群。開(kāi)發(fā)一個(gè)測(cè)試驅(qū)動(dòng)模塊，控制測(cè)試數(shù)據(jù)的輸入和測(cè)試結(jié)果的輸出。對(duì)每個(gè)模塊群進(jìn)行測(cè)試。刪除驅(qū)動(dòng)模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群。重復(fù)上述各步驟，直至整個(gè)系統(tǒng)集成完成。4.3.5 集成測(cè)試策略 自底向上增量集成測(cè)試案例：4.3.5 集成測(cè)試策略3)其他集成測(cè)試方案(1)三明治集成測(cè)試 結(jié)合自頂向下集成測(cè)試和自底向上集成測(cè)試的一種混合式集成測(cè)試，它把系統(tǒng)劃分成三層，中間一層為目標(biāo)層，目標(biāo)層之上采用自頂向下集成，之下采用自底向上集成。4.3.5 集成測(cè)試策略(2)核心系統(tǒng)先行集成測(cè)試 先對(duì)核心軟件部件進(jìn)行集成測(cè)試，在測(cè)試通過(guò)的基礎(chǔ)上再根據(jù)重要程度將各外圍軟件部件逐一

31、集成到核心系統(tǒng)中。每次加入一個(gè)外圍軟件部件都產(chǎn)生一個(gè)產(chǎn)品基線，直至最后形成穩(wěn)定的軟件產(chǎn)品。核心系統(tǒng)先行集成測(cè)試的具體步驟如下。區(qū)分核心軟件部件和外圍軟件。核心系統(tǒng)中的每個(gè)模塊先進(jìn)行單獨(dú)的、充分的測(cè)試。將核心系統(tǒng)中的所有模塊一次性集成到被測(cè)系統(tǒng)中并著手解決集成時(shí)出現(xiàn)的各種問(wèn)題。特別地，當(dāng)核心系統(tǒng)規(guī)模較大時(shí)，可以根據(jù)自底向上集成的步驟進(jìn)行。外圍軟件部件完成內(nèi)部的模塊級(jí)集成測(cè)試。根據(jù)各外圍軟件部件的重要程度以及模塊間的相互制約關(guān)系，擬定外圍軟件部件集成到核心系統(tǒng)中的順序方案并進(jìn)行方案審核。按順序方案逐一加入外圍軟件部件，形成最終的用戶系統(tǒng)。4.3.5 集成測(cè)試策略(3)高頻集成測(cè)試 高頻集成測(cè)試同步

32、于軟件開(kāi)發(fā)過(guò)程，指頻繁地將新代碼和一個(gè)已經(jīng)穩(wěn)定化的基線集成在一起。使用高頻集成測(cè)試需要具備以下條件:能夠持續(xù)獲得一個(gè)穩(wěn)定的增量，并且該增量?jī)?nèi)部已經(jīng)過(guò)驗(yàn)證無(wú)誤。大部分有意義的功能增加可以在一個(gè)相對(duì)穩(wěn)定的時(shí)間間隔內(nèi)獲得。測(cè)試包和代碼的開(kāi)發(fā)工作必須是并行進(jìn)行的，并且需要版本控制工具來(lái)保證始終維護(hù)的是測(cè)試腳本和代碼的最新版本。必須借助于使用自動(dòng)化工具來(lái)完成。由于集成次數(shù)頻繁，人工的方法顯然不能勝任。4.3.5 集成測(cè)試策略高頻集成測(cè)試的具體步驟如下：選擇集成測(cè)試自動(dòng)化工具。如Java項(xiàng)目采用的Unit+Ant方案等。設(shè)置版本控制工具，以確保集成測(cè)試自動(dòng)化工具所獲得的版本是最新版本。編寫(xiě)對(duì)應(yīng)程序代碼的測(cè)

33、試腳本。設(shè)置自動(dòng)化集成測(cè)試工具，定時(shí)對(duì)新添加到配置管理庫(kù)的代碼進(jìn)行自動(dòng)化的集成測(cè)試，并提交測(cè)試報(bào)告。測(cè)試人員監(jiān)督代碼開(kāi)發(fā)人員及時(shí)關(guān)閉不合格項(xiàng)。重復(fù)第三步至第五步，直至形成最終軟件產(chǎn)品。4.3.5 集成測(cè)試策略4)幾種集成測(cè)試方案比較實(shí)施方案比較結(jié)果非增量式集成測(cè)試先分散測(cè)試，再一次性完成集成測(cè)試。需要設(shè)計(jì)驅(qū)動(dòng)模塊和樁模塊，工作量大。直到整個(gè)程序組裝之后，模塊之間接口相關(guān)的錯(cuò)誤才會(huì)浮現(xiàn)，因此錯(cuò)誤定位、糾下困難?？梢酝瑫r(shí)并行測(cè)試很多模塊。增量式集成測(cè)試逐步集成，逐步測(cè)試?？梢暂^早發(fā)現(xiàn)模塊中與不匹配接口、不正確假設(shè)等編程錯(cuò)誤。測(cè)試更徹底，每個(gè)模塊都經(jīng)過(guò)更多的檢驗(yàn)。使用前面測(cè)試過(guò)的模塊來(lái)代替所需要的驅(qū)

34、動(dòng)模塊或樁模塊，工作量小。并行性差。三明治集成測(cè)試集合了自頂向下集成測(cè)試和自底向上集成測(cè)試兩種策略的優(yōu)點(diǎn)?？沙掷m(xù)集成。能較早發(fā)現(xiàn)錯(cuò)誤，測(cè)試效率較高。但中間層測(cè)試不充分。核心系統(tǒng)先行集成測(cè)試需要區(qū)分核心軟件部件和外圍軟件部分。能確保核心功能的實(shí)現(xiàn)。適用于快速軟件開(kāi)發(fā)。高頻集成測(cè)試能在開(kāi)發(fā)過(guò)程中及時(shí)發(fā)現(xiàn)代碼錯(cuò)誤。集成次數(shù)頻繁。必須借助自動(dòng)化工具。4.3.5 集成測(cè)試策略3集成測(cè)試人員 集成測(cè)試人員通常由以下人員構(gòu)成：1)系統(tǒng)分析設(shè)計(jì)人員：對(duì)需求和設(shè)計(jì)進(jìn)行跟蹤、分析，以確定集成測(cè)試的對(duì)象、范圍和方法。2)開(kāi)發(fā)人員：參與集成測(cè)試計(jì)劃的制定、集成測(cè)試方案的評(píng)審及審核集成測(cè)試報(bào)告，即主要配合測(cè)試代碼設(shè)計(jì)和

35、實(shí)現(xiàn)，完成白盒測(cè)試的內(nèi)容。3)測(cè)試人員：制定集成測(cè)試計(jì)劃、集成測(cè)試方案并組織評(píng)審，執(zhí)行集成測(cè)試并完成集成測(cè)試報(bào)告及組織評(píng)審。4)質(zhì)量保證（QA）人員：負(fù)責(zé)集成測(cè)試過(guò)程質(zhì)量保證，參與相關(guān)評(píng)審工作。4.3.5 集成測(cè)試策略4.4 系統(tǒng)測(cè)試 系統(tǒng)測(cè)試的定義 系統(tǒng)測(cè)試的目標(biāo) 系統(tǒng)測(cè)試的內(nèi)容 系統(tǒng)測(cè)試的環(huán)境 系統(tǒng)測(cè)試策略和實(shí)施方案 系統(tǒng)測(cè)試人員4.4.1 系統(tǒng)測(cè)試的定義系統(tǒng)測(cè)試：是指將已經(jīng)集成好并通過(guò)集成測(cè)試的軟件系統(tǒng)，作為整個(gè)計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下，對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的整體測(cè)試和確認(rèn)測(cè)試。系統(tǒng)測(cè)試的測(cè)試對(duì)象不僅包

36、括需測(cè)試的軟件，還要包含軟件所依賴的硬件、外設(shè)甚至包括某些數(shù)據(jù)、某些支持軟件及其接口等。系統(tǒng)測(cè)試是軟件測(cè)試中資源消耗最多、持續(xù)時(shí)間較長(zhǎng)的一個(gè)環(huán)節(jié)，其中大部分測(cè)試工作量主要分配在測(cè)試被測(cè)軟件系統(tǒng)與計(jì)算機(jī)系統(tǒng)中其他組成部分的協(xié)同工作方面。4.4.2 系統(tǒng)測(cè)試的目標(biāo)系統(tǒng)測(cè)試的目標(biāo)如下：1)根據(jù)系統(tǒng)的功能和性能需求進(jìn)行的測(cè)試，發(fā)現(xiàn)系統(tǒng)的缺陷并度量產(chǎn)品質(zhì)量。2)檢驗(yàn)所開(kāi)發(fā)的軟件系統(tǒng)是否按軟件需求規(guī)格說(shuō)明中確定的軟件功能、性能、約束及限制等技術(shù)要求進(jìn)行工作。3)將系統(tǒng)中的軟件與各種依賴的相關(guān)資源結(jié)合起來(lái)，在系統(tǒng)實(shí)際運(yùn)行環(huán)境下驗(yàn)證其是否能協(xié)調(diào)工作。4)從用戶的角度出發(fā)，驗(yàn)證被測(cè)軟件系統(tǒng)是否能滿足用戶使用需求

37、。4.4.3 系統(tǒng)測(cè)試的內(nèi)容系統(tǒng)測(cè)試通常包括以下測(cè)試：1)功能測(cè)試。是系統(tǒng)測(cè)試中要進(jìn)行的最基本的測(cè)試。主要是根據(jù)產(chǎn)品的需求分析說(shuō)明書(shū)和測(cè)試需求列表，驗(yàn)證產(chǎn)品是否符合產(chǎn)品的需求規(guī)格。2)性能測(cè)試。通常從三個(gè)方面進(jìn)行性能測(cè)試：應(yīng)用在客戶端性能的測(cè)試、應(yīng)用在網(wǎng)絡(luò)上性能的測(cè)試和應(yīng)用在服務(wù)器端性能的測(cè)試。應(yīng)用在客戶端性能的測(cè)試目的是考察客戶端應(yīng)用的性能，包括并發(fā)性能測(cè)試、疲勞強(qiáng)度測(cè)試、大數(shù)據(jù)量測(cè)試和速度測(cè)試等。應(yīng)用在網(wǎng)絡(luò)上性能的測(cè)試包括進(jìn)行網(wǎng)絡(luò)應(yīng)用性能監(jiān)控、網(wǎng)絡(luò)應(yīng)用性能分析和網(wǎng)絡(luò)預(yù)測(cè)。應(yīng)用在服務(wù)器上性能的測(cè)試目的是發(fā)現(xiàn)系統(tǒng)的瓶頸，即實(shí)現(xiàn)服務(wù)器設(shè)備、服務(wù)器操作系統(tǒng)、數(shù)據(jù)庫(kù)系統(tǒng)、應(yīng)用在服務(wù)器上性能的全面監(jiān)控

38、。4.4.3 系統(tǒng)測(cè)試的內(nèi)容3)強(qiáng)度測(cè)試。又稱壓力測(cè)試，是在各種資源超負(fù)荷情況下觀察系統(tǒng)的運(yùn)行情況。4)安全性測(cè)試。主要驗(yàn)證系統(tǒng)內(nèi)的保護(hù)機(jī)制能否抵御入侵者的攻擊。通?？梢詮挠行?、生存性、精確性、出錯(cuò)反應(yīng)時(shí)間及吞吐量等方面來(lái)評(píng)價(jià)系統(tǒng)的安全。5)恢復(fù)性測(cè)試。驗(yàn)證系統(tǒng)從軟件或者硬件失敗中恢復(fù)的能力。在測(cè)試過(guò)程中采取各種人工干預(yù)方式使軟件出錯(cuò)而不能正常工作，進(jìn)而檢驗(yàn)系統(tǒng)的恢復(fù)能力。4.4.3 系統(tǒng)測(cè)試的內(nèi)容6)健壯性測(cè)試。又稱容錯(cuò)性測(cè)試。主要是測(cè)試系統(tǒng)在出現(xiàn)故障時(shí)，是否能夠自動(dòng)恢復(fù)或者忽略故障繼續(xù)運(yùn)行。7)兼容性測(cè)試。檢驗(yàn)被測(cè)軟件系統(tǒng)對(duì)其他應(yīng)用或者系統(tǒng)的兼容性。8)面向用戶應(yīng)用的測(cè)試。主要是從用戶的

39、角度檢查被測(cè)軟件系統(tǒng)對(duì)用戶支持的情況。9)其他系統(tǒng)測(cè)試。如分布式系統(tǒng)中協(xié)議一致性測(cè)試、容量測(cè)試、備份測(cè)試、可安裝性測(cè)試、文檔測(cè)試、在線幫助測(cè)試等。4.4.4 系統(tǒng)測(cè)試環(huán)境 相對(duì)于單元測(cè)試和集成測(cè)試而言，其測(cè)試環(huán)境涵蓋了硬件環(huán)境、軟件環(huán)境和網(wǎng)絡(luò)環(huán)境三個(gè)部分：4.4.5 系統(tǒng)測(cè)試策略 1系統(tǒng)測(cè)試實(shí)施方案系統(tǒng)測(cè)試過(guò)程包括以下幾個(gè)階段：1）系統(tǒng)測(cè)試計(jì)劃階段：進(jìn)行系統(tǒng)測(cè)試分析，制定測(cè)試計(jì)劃。2）系統(tǒng)測(cè)試設(shè)計(jì)階段：對(duì)系統(tǒng)進(jìn)行詳細(xì)的測(cè)試分析，需要設(shè)計(jì)一些典型的、滿足測(cè)試需求的測(cè)試用例并同時(shí)給出系統(tǒng)測(cè)試的大致過(guò)程。3）系統(tǒng)測(cè)試實(shí)施階段：使用當(dāng)前的軟件版本進(jìn)行測(cè)試腳本的錄制工作，確定軟件的基線。4）系統(tǒng)測(cè)試執(zhí)行

40、階段：根據(jù)系統(tǒng)測(cè)試計(jì)劃和事先設(shè)計(jì)好的系統(tǒng)測(cè)試用例，按一定測(cè)試規(guī)程實(shí)施測(cè)試。5）系統(tǒng)測(cè)試評(píng)估階段：對(duì)測(cè)試結(jié)果進(jìn)行評(píng)估，以確定系統(tǒng)是否通過(guò)測(cè)試。 4.4.5 系統(tǒng)測(cè)試策略 2系統(tǒng)測(cè)試人員 系統(tǒng)測(cè)試人員通常由以下人員構(gòu)成：1）系統(tǒng)分析設(shè)計(jì)人員：確定系統(tǒng)測(cè)試的對(duì)象、范圍和方法。2）軟件測(cè)試人員：制定系統(tǒng)測(cè)試計(jì)劃、系統(tǒng)測(cè)試方案、實(shí)現(xiàn)測(cè)試用例的設(shè)計(jì)等并組織評(píng)審，執(zhí)行系統(tǒng)測(cè)試并完成系統(tǒng)測(cè)試報(bào)告及組織評(píng)審。3）質(zhì)量保證（QA）人員：負(fù)責(zé)系統(tǒng)測(cè)試過(guò)程質(zhì)量保證，參與相關(guān)評(píng)審工作。4.5 驗(yàn)收測(cè)試 驗(yàn)收測(cè)試的定義 驗(yàn)收測(cè)試的內(nèi)容 驗(yàn)收測(cè)試的組織過(guò)程 驗(yàn)收測(cè)試策略 驗(yàn)收測(cè)試人員4.5.1 驗(yàn)收測(cè)試概述 驗(yàn)收測(cè)試：是部

41、署軟件之前的最后一項(xiàng)測(cè)試。是軟件產(chǎn)品完成系統(tǒng)測(cè)試之后，產(chǎn)品發(fā)布之前所進(jìn)行的軟件測(cè)試活動(dòng)，它主要檢驗(yàn)軟件產(chǎn)品和產(chǎn)品需求規(guī)格說(shuō)明書(shū)是否一致，因此也稱為交付測(cè)試。此外，驗(yàn)收測(cè)試通常需要用戶參與測(cè)試過(guò)程，在用戶實(shí)際使用的運(yùn)行環(huán)境下進(jìn)行測(cè)試，有時(shí)又被稱為現(xiàn)場(chǎng)測(cè)試。 驗(yàn)收測(cè)試應(yīng)滿足以下條件：1）軟件產(chǎn)品已經(jīng)通過(guò)單元測(cè)試、集成測(cè)試和系統(tǒng)測(cè)試各項(xiàng)內(nèi)部測(cè)試，發(fā)現(xiàn)了軟件錯(cuò)誤并完成修正。2）軟件產(chǎn)品已經(jīng)試運(yùn)行了預(yù)定的時(shí)間。3）測(cè)試應(yīng)站在用戶使用和業(yè)務(wù)場(chǎng)景的角度，而不是開(kāi)發(fā)者的角度。4）驗(yàn)收測(cè)試應(yīng)盡可能在用戶實(shí)際使用的真實(shí)環(huán)境下進(jìn)行。5）完成驗(yàn)收測(cè)試相關(guān)準(zhǔn)備工作。4.5.1 驗(yàn)收測(cè)試概述 驗(yàn)收測(cè)試的主要目的有：1）確

42、保軟件產(chǎn)品準(zhǔn)備就緒，最終用戶可以應(yīng)用執(zhí)行產(chǎn)品的既定功能和任務(wù)。2）確保軟件產(chǎn)品滿足合同規(guī)定的所有功能和性能。3）確保相關(guān)文檔資料完整。4）確保產(chǎn)品用戶使用界面符合標(biāo)準(zhǔn)和規(guī)范，具有直觀性、一致性、舒適性、靈活性和實(shí)用性等。5）確保軟件產(chǎn)品的可移植性、兼容性、可維護(hù)性及錯(cuò)誤恢復(fù)能力等讓用戶滿意。4.5.2 驗(yàn)收測(cè)試的內(nèi)容 驗(yàn)收測(cè)試的主要內(nèi)容包括制定驗(yàn)收測(cè)試標(biāo)準(zhǔn)、配置項(xiàng)復(fù)審及實(shí)施驗(yàn)收測(cè)試三個(gè)部分。 1制定驗(yàn)收測(cè)試標(biāo)準(zhǔn)1）軟件功能測(cè)試。（1）軟件安裝、卸載測(cè)試。即軟件產(chǎn)品是否能夠成功地安裝和卸載。（2）需求規(guī)格說(shuō)明書(shū)中的所有功能測(cè)試及邊界值測(cè)試。（3）軟件的運(yùn)行是否與需求規(guī)格說(shuō)明書(shū)中描述相互一致。（4

43、）軟件系統(tǒng)是否存在實(shí)際運(yùn)行中不可或缺但需求規(guī)格說(shuō)明書(shū)中卻沒(méi)有規(guī)定的功能。2）軟件性能測(cè)試。 根據(jù)軟件系統(tǒng)設(shè)計(jì)的性能指標(biāo)，測(cè)試包括計(jì)算精度、響應(yīng)時(shí)間、恢復(fù)時(shí)間及傳輸連接時(shí)限等軟件性能。4.5.2 驗(yàn)收測(cè)試的內(nèi)容 3）界面測(cè)試。 主要檢查軟件產(chǎn)品的界面是否能做到符合標(biāo)準(zhǔn)和規(guī)范、具有直觀性、一致性、靈活性、 舒適性及實(shí)用性等，具體包括軟件界面的組織和布局、文字等元素的格式、色彩的搭配等是否協(xié)調(diào)和便于操作。4）安全性測(cè)試。 包括用戶權(quán)限限制測(cè)試、留痕功能測(cè)試、屏蔽用戶操作錯(cuò)誤應(yīng)答測(cè)試、系統(tǒng)備份與恢復(fù)手段測(cè)試、多用戶操作輸入數(shù)據(jù)有效性測(cè)試、異常情況及網(wǎng)絡(luò)故障對(duì)系統(tǒng)的影響測(cè)試。5）易用性測(cè)試。 站在用戶的

44、角度，著重測(cè)試軟件產(chǎn)品的使用性能，目的主要是衡量軟件系統(tǒng)的普及推廣的難易度。4.5.2 驗(yàn)收測(cè)試的內(nèi)容 6）擴(kuò)充性測(cè)試。 擴(kuò)充性測(cè)試包括檢查軟件系統(tǒng)升級(jí)是否方便、是否留有非本系統(tǒng)的數(shù)據(jù)接口，以方便數(shù)據(jù)的傳輸、用戶是否可以通過(guò)修改配置文件或其它非編程方式修改或增減系統(tǒng)功能等。 7）穩(wěn)定性測(cè)試。主要檢查軟件產(chǎn)品在超負(fù)荷情況下其功能的實(shí)現(xiàn)情況。8）兼容性測(cè)試。 兼容性測(cè)試是驗(yàn)收測(cè)試中的重要內(nèi)容，主要檢查軟件產(chǎn)品在不同操作系統(tǒng)中運(yùn)行是否正常、在不同數(shù)據(jù)庫(kù)系統(tǒng)上運(yùn)行是否正常、在不同的硬件環(huán)境中運(yùn)行是否正常。9）效率測(cè)試。 效率測(cè)試主要檢查在網(wǎng)絡(luò)環(huán)境下，軟件運(yùn)行過(guò)程中數(shù)據(jù)的網(wǎng)絡(luò)傳輸時(shí)間和存取時(shí)間是否能達(dá)到

45、用戶的要求。進(jìn)行效率測(cè)試需要了解軟件系統(tǒng)采用的傳輸協(xié)議及傳輸方式，還需要相應(yīng)的測(cè)試環(huán)境及使用專用網(wǎng)絡(luò)測(cè)試工具。4.5.2 驗(yàn)收測(cè)試的內(nèi)容 10）軟件文檔資料檢查。 驗(yàn)收測(cè)試涉及的文檔主要有：項(xiàng)目實(shí)施計(jì)劃、詳細(xì)技術(shù)方案、軟件需求規(guī)格說(shuō)明書(shū)（STP）、概要設(shè)計(jì)說(shuō)明書(shū)（PDD）、詳細(xì)設(shè)計(jì)說(shuō)明書(shū)（DDD）、測(cè)試任務(wù)說(shuō)明書(shū)、測(cè)試計(jì)劃說(shuō)明書(shū)、測(cè)試報(bào)告說(shuō)明書(shū)、用戶手冊(cè)（SUM）、測(cè)試總結(jié)說(shuō)明書(shū)、測(cè)試驗(yàn)收說(shuō)明書(shū)、問(wèn)題跟蹤報(bào)告說(shuō)明書(shū)和階段評(píng)審報(bào)表。4.5.2 驗(yàn)收測(cè)試的內(nèi)容 2配置項(xiàng)復(fù)審 進(jìn)行驗(yàn)收測(cè)試的一個(gè)重要前提是所有的軟件配置項(xiàng)都已經(jīng)準(zhǔn)備充分，這樣才能確保交付給用戶的最終軟件產(chǎn)品是完整的和有效的。配置項(xiàng)復(fù)審

46、就是為了保證軟件配置齊全、分類有序及包括進(jìn)行軟件維護(hù)時(shí)所必需的細(xì)節(jié)。3實(shí)施驗(yàn)收測(cè)試 實(shí)施驗(yàn)收測(cè)試是整個(gè)驗(yàn)收測(cè)試的核心部分。在驗(yàn)收測(cè)試前期準(zhǔn)備工作完成的基礎(chǔ)上，采取某種測(cè)試策略實(shí)施驗(yàn)收測(cè)試。測(cè)試結(jié)束后還需要完成以下工作：（1）測(cè)試結(jié)果分析：根據(jù)驗(yàn)收通過(guò)準(zhǔn)則分析測(cè)試結(jié)果，作出驗(yàn)收是否通過(guò)及測(cè)試評(píng)價(jià)。 （2）測(cè)試報(bào)告：根據(jù)測(cè)試結(jié)果編制缺陷報(bào)告和驗(yàn)收測(cè)試報(bào)告，并提交給客戶。4.5.3 驗(yàn)收測(cè)試的組織過(guò)程 驗(yàn)收測(cè)試應(yīng)該采用黑盒測(cè)試技術(shù)進(jìn)行。 1驗(yàn)收測(cè)試的實(shí)施過(guò)程1）軟件需求分析：根據(jù)軟件需求分析說(shuō)明書(shū)對(duì)照測(cè)試以判斷軟件產(chǎn)品是 否滿足需求。2）根據(jù)軟件需求和驗(yàn)收要求編制測(cè)試計(jì)劃，確定測(cè)試種類，制定測(cè)試策

47、略及驗(yàn)收通過(guò)準(zhǔn)則，編制驗(yàn)收測(cè)試計(jì)劃和項(xiàng)目驗(yàn)收準(zhǔn)則，并 經(jīng)過(guò)用戶評(píng)審。3）根據(jù)驗(yàn)收測(cè)試計(jì)劃和項(xiàng)目驗(yàn)收準(zhǔn)則完成測(cè)試設(shè)計(jì)和測(cè)試用例 設(shè)計(jì)并經(jīng)過(guò)評(píng)審。4）測(cè)試環(huán)境建立：建立驗(yàn)收測(cè)試的硬件環(huán)境、軟件環(huán)境等。5）驗(yàn)收測(cè)試實(shí)施：根據(jù)測(cè)試計(jì)劃和測(cè)試策略進(jìn)行測(cè)試并記錄測(cè)試過(guò)程和 結(jié)果。6）測(cè)試結(jié)果分析：根據(jù)驗(yàn)收通過(guò)準(zhǔn)則分析測(cè)試結(jié)果，作出驗(yàn)收是否通過(guò) 及測(cè)試評(píng)價(jià)。7）測(cè)試報(bào)告：根據(jù)測(cè)試結(jié)果編制缺陷報(bào)告和驗(yàn)收測(cè)試報(bào)告，并提交給客 戶。開(kāi)始整改簽訂驗(yàn)收測(cè)試合同提交被測(cè)軟件產(chǎn)品及相關(guān)資料分析被測(cè)軟件產(chǎn)品及相關(guān)資料能否進(jìn)入測(cè)試驗(yàn)收測(cè)試項(xiàng)目洽談否是編制測(cè)試計(jì)劃并經(jīng)過(guò)評(píng)審參與測(cè)試人員培訓(xùn)測(cè)試設(shè)計(jì)，編制測(cè)試方案并經(jīng)過(guò)評(píng)審驗(yàn)收測(cè)

48、試實(shí)施測(cè)試結(jié)果分析，編制測(cè)試報(bào)告并組織評(píng)審提交測(cè)試報(bào)告結(jié)束4.5.3 驗(yàn)收測(cè)試的組織過(guò)程 4.5.3 驗(yàn)收測(cè)試的組織過(guò)程 2驗(yàn)收測(cè)試策略1）正式驗(yàn)收測(cè)試 正式驗(yàn)收測(cè)試可以看作是系統(tǒng)測(cè)試的延伸，其測(cè)試計(jì)劃和設(shè)計(jì)制定周密而詳細(xì)，不能偏離所選擇的測(cè)試用例方向，是一項(xiàng)管理嚴(yán)格的過(guò)程。正式驗(yàn)收測(cè)試有兩種組織方式：（1）開(kāi)發(fā)成員或獨(dú)立的測(cè)試成員與最終用戶代表一起執(zhí)行驗(yàn)收測(cè)試。（2）驗(yàn)收測(cè)試完全由最終用戶代表或最終用戶選擇的人員組織實(shí)施。 目前常用的驗(yàn)收測(cè)試策略有三種：正式驗(yàn)收測(cè)試、非正式驗(yàn)收測(cè)試、測(cè)試及測(cè)試。 4.5.3 驗(yàn)收測(cè)試的組織過(guò)程 2）非正式驗(yàn)收測(cè)試 非正式驗(yàn)收測(cè)試對(duì)測(cè)試實(shí)施的限制沒(méi)有正式驗(yàn)收測(cè)

49、試嚴(yán)格。驗(yàn)收測(cè)試過(guò)程中，主要需要確定的是功能和業(yè)務(wù)任務(wù)，測(cè)試內(nèi)容由測(cè)試人員，也就是最終用戶代表決定，而沒(méi)有設(shè)計(jì)必須遵循的特定測(cè)試用例，因而非正式驗(yàn)收測(cè)試不象正式驗(yàn)收測(cè)試那樣組織有序，更為主觀。 4.5.3 驗(yàn)收測(cè)試的組織過(guò)程 3）測(cè)試和測(cè)試 可以采用、測(cè)試策略，來(lái)發(fā)現(xiàn)只有最終用戶才能發(fā)現(xiàn)的問(wèn)題。（1）測(cè)試是指軟件開(kāi)發(fā)公司組織內(nèi)部人員模擬各類用戶行對(duì)即將面市軟件產(chǎn)品（稱為版本）進(jìn)行測(cè)試，試圖發(fā)現(xiàn)錯(cuò)誤并修正。其關(guān)鍵在于盡可能逼真地模擬實(shí)際運(yùn)行環(huán)境和用戶對(duì)軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的用戶操作方式。經(jīng)過(guò)測(cè)試調(diào)整的軟件產(chǎn)品稱為版本。（2）測(cè)試是指軟件開(kāi)發(fā)公司組織各方面的用戶代表在日常工作中實(shí)

50、際使用版本，并報(bào)告異常情況、提出批評(píng)意見(jiàn)，然后軟件開(kāi)發(fā)公司再對(duì)版本進(jìn)行改錯(cuò)和完善。 4.5.3 驗(yàn)收測(cè)試的組織過(guò)程 幾種驗(yàn)收測(cè)試策略比較：驗(yàn)收測(cè)試策略優(yōu)點(diǎn)缺點(diǎn)正式驗(yàn)收測(cè)試需要測(cè)試的功能、特性、測(cè)試的細(xì)節(jié)及用戶可接受的標(biāo)準(zhǔn)都是已知的?？梢宰詣?dòng)執(zhí)行，支持回歸測(cè)試?？梢詫?duì)測(cè)試過(guò)程進(jìn)行評(píng)測(cè)和監(jiān)測(cè)。需要大量的資源和詳細(xì)、周密的計(jì)劃。驗(yàn)收測(cè)試可能是演變?yōu)橄到y(tǒng)測(cè)試的再次實(shí)施。較難發(fā)現(xiàn)軟件中由于主觀原因造成的缺陷。非正式驗(yàn)收測(cè)試需要測(cè)試的功能、特性、測(cè)試的細(xì)節(jié)及用戶可接受的標(biāo)準(zhǔn)都是已知的。需要對(duì)測(cè)試過(guò)程進(jìn)行評(píng)測(cè)和監(jiān)測(cè)。與正式驗(yàn)收測(cè)試相比，可以發(fā)現(xiàn)更多由于主觀原因造成的缺陷。無(wú)法控制所使用的測(cè)試用例。最終用戶可

51、能沿用系統(tǒng)工作的方式，導(dǎo)致無(wú)法發(fā)現(xiàn)缺陷。最終用戶可能專注于比較系統(tǒng)，而不是查找缺陷。用于驗(yàn)收測(cè)試的資源可能受到壓縮。測(cè)試和測(cè)試測(cè)試由最終用戶實(shí)施。經(jīng)過(guò)測(cè)試，擁有大量的潛在測(cè)試資源。提高用戶對(duì)參與人員的滿意程度。能發(fā)現(xiàn)更多由于主觀原因造成的缺陷。不能對(duì)被測(cè)軟件產(chǎn)品的所有功能和性能進(jìn)行測(cè)試。測(cè)試過(guò)程難以評(píng)測(cè)。最終用戶可能沿用系統(tǒng)工作的方式，會(huì)導(dǎo)致沒(méi)有發(fā)現(xiàn)或沒(méi)有報(bào)告缺陷。最終用戶可能專注于比較系統(tǒng)，而不是查找缺陷。用于驗(yàn)收測(cè)試的資源可能受到壓縮。用戶可接受的標(biāo)準(zhǔn)未知。需要更多輔助資源來(lái)支持測(cè)試過(guò)程。4.5.3 驗(yàn)收測(cè)試的組織過(guò)程 3驗(yàn)收測(cè)試人員驗(yàn)收測(cè)試人員通常包括：1）用戶或用戶代表：確定軟件產(chǎn)品是

52、否滿足用戶的需求、行為和性能。2）軟件測(cè)試人員：適時(shí)配合用戶或用戶代表做好驗(yàn)收測(cè)試的各項(xiàng)準(zhǔn)備工作，根據(jù)測(cè)試計(jì)劃按步驟執(zhí)行驗(yàn)收測(cè)試，形成規(guī)范的測(cè)試文檔，客觀地分析和評(píng)估測(cè)試結(jié)果，包括向用戶解釋測(cè)試執(zhí)行過(guò)程、測(cè)試用例的結(jié)果等。3）質(zhì)量保證（QA）人員：充當(dāng)測(cè)試觀察員，負(fù)責(zé)驗(yàn)收測(cè)試過(guò)程質(zhì)量保證，參與相關(guān)評(píng)審工作。4.6 性能測(cè)試 什么是軟件性能 性能測(cè)試的定義 性能測(cè)試的指標(biāo) 性能測(cè)試的方法 性能測(cè)試人員4.6.1 性能測(cè)試概述 軟件性能涉及面廣，涵蓋了執(zhí)行效率、資源占用、安全性、穩(wěn)定性、兼容性、可擴(kuò)充性、可靠性等多個(gè)方面的內(nèi)容，軟件性能不僅是一種指標(biāo)，還是軟件產(chǎn)品的一種特性。 通常從三個(gè)層面關(guān)注軟

53、件性能： 1）用戶視角的軟件性能。從用戶的角度來(lái)說(shuō)，軟件性能就是軟件對(duì)用戶操作的響應(yīng)時(shí)間。2）管理員視角的軟件性能。從管理員的角度來(lái)看，軟件系統(tǒng)的性能首先表現(xiàn)在系統(tǒng)的響應(yīng)時(shí)間上，但還要關(guān)注和系統(tǒng)狀態(tài)相關(guān)的信息。3）產(chǎn)品開(kāi)發(fā)人員視角的軟件性能。從開(kāi)發(fā)人員的角度來(lái)說(shuō)，首先應(yīng)該關(guān)注的是響應(yīng)時(shí)間，其次關(guān)注系統(tǒng)的擴(kuò)展性等管理員關(guān)心的內(nèi)容。但開(kāi)發(fā)人員最關(guān)注的是軟件系統(tǒng)的“性能瓶頸”和系統(tǒng)存在大量用戶訪問(wèn)時(shí)表現(xiàn)出來(lái)的缺陷。 站在不同的層面上所關(guān)注的軟件性能測(cè)試內(nèi)容有著顯著的差異。因此，從技術(shù)上可以將軟件性能測(cè)試概述為通過(guò)自動(dòng)化的測(cè)試工具模擬多種正常、峰值以及異常負(fù)載條件來(lái)對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測(cè)試。 4.

54、6.2 性能測(cè)試指標(biāo) 通常，性能測(cè)試主要關(guān)注的指標(biāo)有：1響應(yīng)時(shí)間 響應(yīng)時(shí)間是對(duì)用戶請(qǐng)求作出響應(yīng)所需要的時(shí)間。實(shí)際上，用戶所感受到的響應(yīng)時(shí)間應(yīng)該包括 “呈現(xiàn)時(shí)間”和“系統(tǒng)響應(yīng)時(shí)間”兩個(gè)部分。1）呈現(xiàn)時(shí)間：指客戶端接收到結(jié)果數(shù)據(jù)后把它呈現(xiàn)出來(lái)的時(shí)間。2）系統(tǒng)響應(yīng)時(shí)間：指應(yīng)用系統(tǒng)從請(qǐng)求發(fā)出開(kāi)始到客戶端接收到結(jié)果數(shù)據(jù)所消耗的時(shí)間。 特別要注意的是，響應(yīng)時(shí)間對(duì)客戶來(lái)說(shuō)帶有一定的主觀色彩，即沒(méi)有絕對(duì)的響應(yīng)時(shí)間 “長(zhǎng)”和“短”的區(qū)別。因此，在進(jìn)行性能測(cè)試時(shí)，“響應(yīng)時(shí)間”是否合理取決于實(shí)際的用戶需求，而不是測(cè)試人員自己設(shè)定。4.6.2 性能測(cè)試指標(biāo) 2并發(fā)用戶數(shù) 并發(fā)用戶數(shù)是指在同一個(gè)時(shí)間段內(nèi)訪問(wèn)系統(tǒng)的用戶數(shù)

55、量，通常從用戶角度和服務(wù)器端兩個(gè)方面來(lái)考查：1）用戶角度的并發(fā)用戶數(shù)。在一個(gè)時(shí)間段內(nèi)，如果所有用戶都能順利開(kāi)展操作，則可以認(rèn)為系統(tǒng)能夠承受該數(shù)量的并發(fā)用戶訪問(wèn)，即將業(yè)務(wù)并發(fā)用戶數(shù)等同于并發(fā)用戶數(shù)。2）服務(wù)器端的并發(fā)用戶數(shù)。從服務(wù)器端承受的壓力來(lái)考慮，系統(tǒng)的性能表現(xiàn)則主要由服務(wù)器端決定。 在實(shí)際的性能測(cè)試中，測(cè)試人員大多關(guān)注的是用戶角度的并發(fā)用戶數(shù)，為了方便，直接將業(yè)務(wù)并發(fā)用戶數(shù)稱為并發(fā)用戶數(shù)。4.6.2 性能測(cè)試指標(biāo) 3吞吐量 吞吐量是指單位時(shí)間內(nèi)系統(tǒng)處理的用戶請(qǐng)求的數(shù)量，直接體現(xiàn)軟件系統(tǒng)的性能承載能力。一般可以從三個(gè)方面來(lái)衡量系統(tǒng)的吞吐量：1）用戶請(qǐng)求數(shù)/秒或頁(yè)面數(shù)/秒。2）從業(yè)務(wù)的角度，可

56、以用訪問(wèn)人數(shù)/天或處理的業(yè)務(wù)數(shù)/小時(shí)。3）從網(wǎng)絡(luò)的角度來(lái)，可以用字節(jié)數(shù)/天。4性能計(jì)數(shù)器 性能計(jì)數(shù)器是描述服務(wù)器或操作系統(tǒng)性能的一些數(shù)據(jù)指標(biāo)，它常與系統(tǒng)各種資源的使用狀況，即資源利用率相關(guān)，是性能測(cè)試分析的主要參考值。 性能計(jì)數(shù)器在性能測(cè)試中的主要作用是分析系統(tǒng)的可擴(kuò)展性及進(jìn)行性能瓶頸的定位。4.6.2 性能測(cè)試指標(biāo) 5思考時(shí)間 思考時(shí)間，有時(shí)也稱為系統(tǒng)的休眠時(shí)間，即是用戶在進(jìn)行操作時(shí)，每個(gè)請(qǐng)求之間的間隔時(shí)間。思考時(shí)間與迭代次數(shù)、并發(fā)用戶數(shù)和吞吐量等都有關(guān)系。 在實(shí)際的性能測(cè)試中，測(cè)試人員關(guān)注的是如何合理地設(shè)置思考時(shí)間。4.6.3 性能測(cè)試的目標(biāo) 性能測(cè)試的目標(biāo)包括以下幾個(gè)方面：1）評(píng)估系統(tǒng)的

57、性能。在系統(tǒng)試運(yùn)行階段，確定當(dāng)前系統(tǒng)是否滿足驗(yàn)收要求。系統(tǒng)實(shí)際運(yùn)行一段時(shí)間后，如何保證能夠一直具有良好的運(yùn)行性能。2）尋找系統(tǒng)性能瓶頸，優(yōu)化性能。當(dāng)用戶業(yè)務(wù)操作響應(yīng)時(shí)間長(zhǎng)，如何發(fā)現(xiàn)問(wèn)題并調(diào)整性能。當(dāng)系統(tǒng)運(yùn)行一段時(shí)間后，出現(xiàn)速度變慢等問(wèn)題時(shí)，如何尋找瓶頸，進(jìn)而優(yōu)化性能。3）預(yù)測(cè)系統(tǒng)可擴(kuò)展性。當(dāng)系統(tǒng)用戶數(shù)增加時(shí)，系統(tǒng)是否還能滿足用戶需求，如果不能，如何進(jìn)行調(diào)整。 4.6.4 性能測(cè)試的策略 1軟件性能測(cè)試的方法目前軟件性能測(cè)試中主要使用的方法有： 1）性能測(cè)試法。 性能測(cè)試的方法是通過(guò)模擬系統(tǒng)運(yùn)行的業(yè)務(wù)壓力和使用場(chǎng)景，測(cè)試系統(tǒng)的性能是否滿足用戶提出的系統(tǒng)性能要求。該方法的主要特點(diǎn)是：（1）需要事先

58、了解被測(cè)試系統(tǒng)典型場(chǎng)景，并具有確定的性能目標(biāo)。（2）在已確定的環(huán)境下運(yùn)行。（3）包括確定用戶場(chǎng)景、給出需要關(guān)注的性能指標(biāo)、測(cè)試執(zhí)行和測(cè)試分析幾個(gè)步驟。（4）主要目的是驗(yàn)證系統(tǒng)是否達(dá)到預(yù)期的性能。4.6.4 性能測(cè)試的策略 2）負(fù)載測(cè)試法 負(fù)載測(cè)試的方法，也稱為可量性測(cè)試方法，是指通過(guò)在被測(cè)系統(tǒng)上不斷增加壓力，直到性能指標(biāo)超過(guò)預(yù)定指標(biāo)或某種資源使用達(dá)到飽和狀態(tài)，從而發(fā)現(xiàn)系統(tǒng)處理的極限，為系統(tǒng)優(yōu)化提供依據(jù)。該方法的主要特點(diǎn)是：（1）負(fù)載測(cè)試方法以發(fā)現(xiàn)系統(tǒng)處理能力的極限為目的。（2）負(fù)載測(cè)試方法需要在給定的測(cè)試環(huán)境下進(jìn)行，即通常要考慮系統(tǒng)的典型場(chǎng)景，使得測(cè)試結(jié)果具有業(yè)務(wù)意義。（3）負(fù)載測(cè)試方法一般用

59、來(lái)發(fā)現(xiàn)系統(tǒng)的性能極限，或是配合系統(tǒng)性能調(diào)優(yōu)。4.6.4 性能測(cè)試的策略 3）壓力測(cè)試法 壓力測(cè)試的方法是指系統(tǒng)在一定負(fù)荷的狀態(tài)下，系統(tǒng)能夠處理的用戶操作能力或系統(tǒng)是否會(huì)出現(xiàn)錯(cuò)誤，從而定位系統(tǒng)失效以及如何失效。壓力測(cè)試方法的主要特點(diǎn)是：（1）使用壓力測(cè)試方法的目的是檢查系統(tǒng)處于一定壓力情況下的應(yīng)用的表現(xiàn)，特別是系統(tǒng)有無(wú)錯(cuò)誤產(chǎn)生及系統(tǒng)對(duì)應(yīng)用的響應(yīng)時(shí)間等。（2）壓力測(cè)試方法一般通過(guò)模擬負(fù)載等方法使得系統(tǒng)的資源使用達(dá)到較高的水平。（3）壓力測(cè)試方法一般用于測(cè)試系統(tǒng)的穩(wěn)定性。 4.6.4 性能測(cè)試的策略 4）配置測(cè)試法 配置測(cè)試的方法是指通過(guò)對(duì)被測(cè)系統(tǒng)進(jìn)行軟、硬件配置環(huán)境的調(diào)整，發(fā)現(xiàn)不同配置環(huán)境對(duì)系統(tǒng)性

60、能影響的程度，從而找到系統(tǒng)各項(xiàng)資源的最優(yōu)配置。配置測(cè)試的方法主要用于性能調(diào)優(yōu)。該方法的主要特點(diǎn)是：（1）配置測(cè)試的方法可分為兩個(gè)層面：功能測(cè)試層面主要驗(yàn)證系統(tǒng)在不同的軟、硬件環(huán)境中能否正常運(yùn)行，實(shí)現(xiàn)其功能。性能測(cè)試層面主要驗(yàn)證不同的軟、硬件配置對(duì)系統(tǒng)性能的影響，從而發(fā)現(xiàn)對(duì)系統(tǒng)性能影響最大的因素。（2）配置測(cè)試方法通常要在對(duì)系統(tǒng)性能狀況有一定了解后才能進(jìn)行。（3）配置測(cè)試的方法一般用于系統(tǒng)性能調(diào)優(yōu)和規(guī)劃配置。 4.6.4 性能測(cè)試的策略 5）并發(fā)測(cè)試法 并發(fā)測(cè)試的方法是指通過(guò)模擬用戶的并發(fā)訪問(wèn)，測(cè)試系統(tǒng)在多用戶并發(fā)訪問(wèn)同一個(gè)應(yīng)用、同一個(gè)模塊等時(shí)是否出現(xiàn)死鎖或者其它性能問(wèn)題。該方法的主要特點(diǎn)是：（