軟件質(zhì)量保證與測(cè)試5.1.1單元測(cè)試簡(jiǎn)介第5章軟件測(cè)試過程SoftwareQualityAssuranceandTesting5.1單元測(cè)試單元測(cè)試的成本效率

在軟件開發(fā)過程中，越早發(fā)現(xiàn)問題、解決問題，花費(fèi)的成本就越小，經(jīng)驗(yàn)表明一個(gè)盡責(zé)的單元測(cè)試將會(huì)在軟件開發(fā)的早期發(fā)現(xiàn)很多的問題和缺陷，并且修改它們的成本也較低，而如果拖到后期階段，缺陷的發(fā)現(xiàn)和修改將會(huì)變得更加困難，并要消耗更多的時(shí)間和費(fèi)用。對(duì)于程序代碼而言，開發(fā)出來之后，應(yīng)首先對(duì)其進(jìn)行單元測(cè)試，力爭(zhēng)盡早發(fā)現(xiàn)程序中缺陷和問題。

有統(tǒng)計(jì)數(shù)據(jù)表明，以軟件的一個(gè)功能點(diǎn)為基準(zhǔn)，單元測(cè)試的成本效率大約是集成測(cè)試的兩倍，系統(tǒng)測(cè)試的三倍。單元測(cè)試的成本效率單元測(cè)試的概念

單元測(cè)試是針對(duì)軟件設(shè)計(jì)的最小單位——程序模塊，進(jìn)行檢查和驗(yàn)證，其目的在于發(fā)現(xiàn)每個(gè)程序模塊內(nèi)部可能存在的問題和差錯(cuò)。單元測(cè)試通常應(yīng)用于實(shí)施模型中的構(gòu)件，核實(shí)是否已覆蓋控制流和數(shù)據(jù)流，以及構(gòu)件是否可以按照預(yù)期工作。執(zhí)行單元測(cè)試，就是為了驗(yàn)證單元模塊代碼的行為和我們期望的一致。單元的粒度

單元測(cè)試是對(duì)軟件基本組成單元的測(cè)試。單元的粒度具體劃分可以不同，在傳統(tǒng)的結(jié)構(gòu)化編程語言如C語言中，單元一般是模塊，也就是函數(shù)或子過程；在C++中，單元是類或類的方法；在Ada語言中，單元可為獨(dú)立的過程、函數(shù)或Ada包；在第四代語言(4GL)中，單元對(duì)應(yīng)為一個(gè)菜單或顯示界面。***打印模塊

......publicintfindMin(){......單元的粒度

單元測(cè)試中的一個(gè)可測(cè)“單元”應(yīng)符合以下要求：(1)是可測(cè)試的、最小的、不可再分的程序模塊。(2)有明確的功能、規(guī)格定義。(3)有明確的接口定義，清晰地與同一程序的其他單元?jiǎng)澐珠_來。單元測(cè)試的完成人

單元測(cè)試通常是由程序員自己來完成，有時(shí)測(cè)試人員也加入進(jìn)來，但編程人員仍會(huì)起到主要作用。單元測(cè)試是程序員的一項(xiàng)基本職責(zé)，程序員有責(zé)任對(duì)自己編寫的代碼進(jìn)行單元測(cè)試。程序員必須對(duì)自己所編寫的代碼保持認(rèn)真負(fù)責(zé)的態(tài)度，這是程序員的基本職業(yè)素質(zhì)之一。同時(shí)單元測(cè)試能力也是程序員的一項(xiàng)基本能力，這種能力的高低直接影響到程序員的工作效率與軟件的質(zhì)量。

在編碼的過程中進(jìn)行單元測(cè)試的話，由于程序員對(duì)設(shè)計(jì)和代碼都很熟悉，不需要額外花時(shí)間去閱讀、理解、分析程序的設(shè)計(jì)書和源代碼，所以測(cè)試成本是最小的，測(cè)試效率也是最高的。在編碼的過程中考慮測(cè)試問題，得到的將是更優(yōu)質(zhì)的代碼，因?yàn)榇藭r(shí)程序員對(duì)代碼應(yīng)該做些什么了解得最清楚。如果不這樣做，而是先匆匆忙忙完成模塊開發(fā)，等過了很久，甚至是一直等到模塊報(bào)錯(cuò)崩潰了，再來做單元測(cè)試，到那時(shí)程序員可能已經(jīng)忘記了這個(gè)模塊的代碼是怎樣工作的，需要花較多的時(shí)間來重新閱讀、理解、分析程序的設(shè)計(jì)書和源代碼。編程與單元測(cè)試

由于單元測(cè)試是在編碼過程中進(jìn)行的，若發(fā)現(xiàn)了一個(gè)錯(cuò)誤，修復(fù)錯(cuò)誤的成本會(huì)遠(yuǎn)小于集成測(cè)試階段，更是小于系統(tǒng)測(cè)試階段。在編碼的過程中考慮單元測(cè)試問題，有助于編程人員養(yǎng)成良好的編程習(xí)慣，提高源代碼質(zhì)量。編程與單元測(cè)試單元測(cè)試的目標(biāo)

單元測(cè)試是軟件測(cè)試的基礎(chǔ)。通過單元測(cè)試，應(yīng)分別完成對(duì)每個(gè)單元的測(cè)試任務(wù)，確保每個(gè)單元模塊能正常工作，程序代碼符合各種要求和規(guī)范。通常合格的代碼應(yīng)該具備以下性質(zhì)：正確性、清晰性、規(guī)范性、一致性、高效性等，要具備的這些性質(zhì)中，優(yōu)先級(jí)最高的的正確性，只有先滿足正確性，其它特性才具有實(shí)際意義，其次是清晰性、規(guī)范性和一致性，而對(duì)有些會(huì)反復(fù)執(zhí)行的代碼，還需要具有高效性，否則會(huì)影響整個(gè)系統(tǒng)的效率和性能。單元測(cè)試的目標(biāo)1.正確性是指代碼邏輯必須正確，能夠?qū)崿F(xiàn)預(yù)期的功能。2.清晰性是指代碼必須簡(jiǎn)明、易懂，注釋準(zhǔn)確沒有歧義。3.規(guī)范性是指代碼必須符合企業(yè)或部門所定義的共同規(guī)范包括命名規(guī)則，代碼風(fēng)格等4.一致性指代碼必須在名稱、風(fēng)格等方面保持統(tǒng)一5.高效性是指代碼不但要滿足以上性質(zhì)，而且需要盡可能降低代碼的執(zhí)行時(shí)間。單元測(cè)試的輔助模塊

一個(gè)單元模塊或一個(gè)方法（Method）等并不是一個(gè)獨(dú)立的程序，在測(cè)試它時(shí)要同時(shí)考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與被測(cè)模塊相聯(lián)系的其他模塊。這些輔助模塊分為驅(qū)動(dòng)模塊和樁模塊兩種。例如有如圖所示的程序模塊圖，如果要對(duì)中間的單元做測(cè)試，則需要輔助的一個(gè)驅(qū)動(dòng)模塊和兩個(gè)樁模塊。單元測(cè)試的輔助模塊驅(qū)動(dòng)模塊

驅(qū)動(dòng)模塊用來模擬被測(cè)單元的上層模塊的程序模塊，它能夠接收或者設(shè)置測(cè)試數(shù)據(jù)、參數(shù)、環(huán)境變量等，調(diào)用被測(cè)單元，將數(shù)據(jù)傳遞給被測(cè)單元，如果需要還可以顯示或者打印測(cè)試的執(zhí)行結(jié)果。可將驅(qū)動(dòng)模塊理解為被測(cè)單元的主程序。樁模塊

樁模塊又稱為存根模塊，它用來模擬被測(cè)單元的子模塊。設(shè)計(jì)樁模塊的目的是模擬被測(cè)單元所調(diào)用的子模塊，接受被測(cè)單元的調(diào)用，并返回調(diào)用結(jié)果給被測(cè)單元。樁模塊不一定需要包括子模塊的全部功能，但至少應(yīng)能模擬滿足被測(cè)單元的調(diào)用需求，而不至于讓被測(cè)單元在調(diào)用它時(shí)出現(xiàn)錯(cuò)誤。單元測(cè)試的測(cè)試環(huán)境

被測(cè)試的單元模塊與它的驅(qū)動(dòng)模塊及樁模塊一起，共同構(gòu)成了一個(gè)“測(cè)試環(huán)境”。建立單元測(cè)試的環(huán)境，需完成以下一些工作：①構(gòu)造最小運(yùn)行調(diào)度系統(tǒng)，即構(gòu)造被測(cè)單元的驅(qū)動(dòng)模塊。②模擬被測(cè)單元的下級(jí)調(diào)用接口，即構(gòu)造用于提供給被測(cè)單元調(diào)用的樁模塊。③模擬生成測(cè)試數(shù)據(jù)及狀態(tài)，為被測(cè)單元運(yùn)行準(zhǔn)備動(dòng)態(tài)環(huán)境。單元測(cè)試模型算法和邏輯模塊接口數(shù)據(jù)結(jié)構(gòu)邊界條件獨(dú)立路徑錯(cuò)誤處理......

驅(qū)動(dòng)模塊

被測(cè)模塊樁模塊樁模塊樁模塊測(cè)試結(jié)果測(cè)試用例單元測(cè)試的測(cè)試環(huán)境

驅(qū)動(dòng)模塊和樁模塊的編寫會(huì)產(chǎn)生一定的工作量，帶來額外的開銷。因?yàn)樗鼈冊(cè)谲浖桓稌r(shí)并不作為產(chǎn)品的一部分一同交付。特別是樁模塊，為了能夠正確、充分的測(cè)試軟件，樁模塊可能需要模擬實(shí)際子模塊的功能，這樣樁模塊的建立就并不是一件很輕松的事情了。

單元測(cè)試的測(cè)試環(huán)境

有時(shí)編寫樁模塊是非常困難和費(fèi)時(shí)的，但也可以采取一定的策略，來避免編寫樁模塊，只需在項(xiàng)目進(jìn)度管理時(shí)將實(shí)際樁模塊的代碼編寫工作安排在被測(cè)模塊前編寫即可。而且這樣可以提高測(cè)試工作的效果，因?yàn)椴粩嗾{(diào)用實(shí)際的樁模塊可以更好的對(duì)其進(jìn)行測(cè)試，保證產(chǎn)品的質(zhì)量。

單元測(cè)試的測(cè)試環(huán)境

對(duì)于每一個(gè)包或子系統(tǒng)我們可以根據(jù)所編寫的測(cè)試用例來編寫一個(gè)測(cè)試模塊類來做驅(qū)動(dòng)模塊，用于測(cè)試包中所有的待測(cè)試模塊。而最好不要在每個(gè)類中用一個(gè)測(cè)試函數(shù)的方法，來測(cè)試類中所有的方法。下面給出一個(gè)源代碼和測(cè)試代碼的結(jié)構(gòu)示例。importjava.util.Comparator;importjava.util.Random;publicfinalclassSorting{publicvoidinsertionSort(int[]a){

...... }publicbooleanisSorted(int[]a){

...... }

......

}程

序

源

代

碼importstaticorg.junit.Assert.*;importorg.junit.Test;publicclassTestSorting{ @Test publicvoidtestInsertionSort(){

...... } @Test publicvoidtestIsSorted(){

...... }......

}一個(gè)測(cè)試類和多個(gè)測(cè)試函數(shù)單元測(cè)試的測(cè)試環(huán)境這樣的好處在于：

能夠同時(shí)測(cè)試包中所有的方法或模塊，也可以方便的測(cè)試指定的模塊或方法。

能夠聯(lián)合使用所有測(cè)試用例對(duì)同一段代碼執(zhí)行測(cè)試，發(fā)現(xiàn)問題。便于回歸測(cè)試，當(dāng)某個(gè)模塊作了修改之后，只要執(zhí)行測(cè)試類就可以執(zhí)行所有被測(cè)的模塊或方法。單元測(cè)試的測(cè)試環(huán)境

不但能夠方便的檢查、測(cè)試所修改的代碼，而且能夠檢查出修改對(duì)包內(nèi)相關(guān)模塊或方法所造成的影響，使得因修改而可能引進(jìn)的錯(cuò)誤得以及時(shí)被發(fā)現(xiàn)；能夠復(fù)用測(cè)試方法，使測(cè)試單元保持持久性，并可以基于已有的測(cè)試來編寫相關(guān)的其它測(cè)試。

能夠?qū)y(cè)試代碼與產(chǎn)品代碼分開，使代碼更清晰、簡(jiǎn)潔；可以提高測(cè)試代碼與被測(cè)代碼的可維護(hù)性。

本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測(cè)試5.1.2單元測(cè)試的任務(wù)第5章軟件測(cè)試過程SoftwareQualityAssuranceandTesting5.1單元測(cè)試單元測(cè)試的步驟

代碼編寫完成后的單元測(cè)試工作，主要分為兩個(gè)步驟：靜態(tài)檢查和動(dòng)態(tài)測(cè)試。靜態(tài)檢查是單元測(cè)試的第一步，這個(gè)階段的工作主要是保證代碼算法的邏輯正確性，應(yīng)通過人工檢查發(fā)現(xiàn)代碼的邏輯錯(cuò)誤，其次還要檢查代碼的清晰性、規(guī)范性、一致性，反復(fù)執(zhí)行的代碼，還需要分析算法是否高效。第二步是通過設(shè)計(jì)測(cè)試用例，執(zhí)行被測(cè)程序，比較實(shí)際結(jié)果與預(yù)期結(jié)果的異同，以發(fā)現(xiàn)程序中的錯(cuò)誤。單元測(cè)試的步驟

經(jīng)驗(yàn)表明，使用靜態(tài)檢查法能夠有效的發(fā)現(xiàn)30%到70%的邏輯設(shè)計(jì)和編碼錯(cuò)誤。但是代碼中仍會(huì)有大量的隱性錯(cuò)誤無法通過靜態(tài)檢查發(fā)現(xiàn)，必須通過動(dòng)態(tài)測(cè)試才能夠捕捉和發(fā)現(xiàn)。動(dòng)態(tài)測(cè)試是單元測(cè)試的重點(diǎn)與難點(diǎn)。單元測(cè)試的任務(wù)

一般而言，應(yīng)當(dāng)對(duì)程序模塊進(jìn)行以下動(dòng)態(tài)單元測(cè)試：1、對(duì)模塊內(nèi)所有獨(dú)立的執(zhí)行路徑至少測(cè)試一次；2、對(duì)所有的邏輯判定，取“真”與“假”的兩種情況都至少執(zhí)行一次；3、在循環(huán)的邊界和運(yùn)行界限內(nèi)執(zhí)行循環(huán)體；4、測(cè)試內(nèi)部數(shù)據(jù)的有效性等。單元測(cè)試的任務(wù)

單元測(cè)試的依據(jù)是軟件的詳細(xì)設(shè)計(jì)和編碼標(biāo)準(zhǔn)等，檢查和測(cè)試對(duì)象主要就是源程序。單元測(cè)試的任務(wù)主要包括：①驗(yàn)證代碼能否達(dá)到詳細(xì)設(shè)計(jì)的預(yù)期要求。②發(fā)現(xiàn)代碼中不符合編碼規(guī)范的地方。③準(zhǔn)確定位錯(cuò)誤，以便排除錯(cuò)誤。

具體而言，單元測(cè)試應(yīng)檢查和測(cè)試的內(nèi)容如下。

1.算法和邏輯

檢查算法和內(nèi)部各個(gè)處理邏輯的正確性，例如：某程序員編寫打印下降三角形九九乘法表的程序如下：***九九打印乘法表public

static

void

printTable()

{

for

(int

i

=

1;

i

<=

9;

i++)

{

for

(int

j

=

1;

j<=

9;

j++)

{System.out.print(String.format

("%d

*

%d

=

%-2d

",

i,

j,

i*j));}

System.out.println();

}

}

1.算法和邏輯通過檢查和測(cè)試應(yīng)能發(fā)現(xiàn)程序邏輯是錯(cuò)誤的，打印出來的不是下降三角形的九九乘法表，而是9*9的方陣。改正的辦法如下：for

(int

i

=

1;

i

<=

9;

i++)

{

for

(int

j

=

1;

j<=

9;

j++)

for

(int

i

=

1;

i

<=

9;

i++)

{

for

(int

j

=

1;

j<=i;

j++)

2.模塊接口

對(duì)模塊自身的接口做正確性檢查；確定形式參數(shù)個(gè)數(shù)、數(shù)據(jù)類型、順序是否正確；確定返回值類型，檢查返回值的正確性。檢查調(diào)用其他模塊的代碼的正確性；調(diào)用其他模塊時(shí)給定的參數(shù)類型正確與否、參數(shù)個(gè)數(shù)正確與否、參數(shù)順序正確與否，特別是具有多態(tài)的方法尤其需要注意。檢查返回值正確與否，有沒有誤解返回值所表示的意思。必要時(shí)可以對(duì)每個(gè)被調(diào)用的方法的返回值用顯式代碼如程序插樁，作正確性檢查，如果被調(diào)用方法出現(xiàn)異常或錯(cuò)誤程序應(yīng)該給予反饋，并添加適當(dāng)?shù)某鲥e(cuò)處理代碼。例如：某程序員編寫的求平均成績的代碼段如下：

public

class

getScoreAverage

{

public

float

getAverage(

String[]

scores

)

{

if

(scores==null

||

scores.length==0)

{

throw

new

NullPointerException();

}

float

sum

=

0.0F;

int

j=scores.length;

for

(int

i=0;

i<j;

i++)

{

sum

+=

scores[i];

}

return

sum/j;

}

public

static

void

main(String[]

args)

{

getScoreAverage

cj

=

new

getScoreAverage();

int

[]

scores

=

{60,80,70};

System.out.println(cj.getAverage(scores));

}

}2.模塊接口

程序中的問題是：函數(shù)內(nèi)部把成績當(dāng)成數(shù)值型數(shù)據(jù)來處理，直接進(jìn)行累加，而形式參數(shù)中存放成績的是字符型數(shù)組，所以接口和內(nèi)部實(shí)現(xiàn)是不一致的。要改正的話，既可以修改程序內(nèi)部實(shí)現(xiàn)，也可以修改接口，但如果事先還沒有把程序接口規(guī)定死的話，顯然修改接口要比修改內(nèi)部實(shí)現(xiàn)簡(jiǎn)單一些。2.模塊接口

檢查全局和局部數(shù)據(jù)結(jié)構(gòu)的定義（如：隊(duì)列、堆棧等）是否能實(shí)現(xiàn)模塊或方法所要求的功能。例如某程序中需要實(shí)現(xiàn)先來先服務(wù)的任務(wù)調(diào)度，但為此定義的數(shù)據(jù)結(jié)構(gòu)為棧，這顯然是錯(cuò)誤的，因?yàn)闂Ｓ糜趯?shí)現(xiàn)后進(jìn)者先出。改正的辦法是定義一個(gè)隊(duì)列，而不是棧。3.數(shù)據(jù)結(jié)構(gòu)

檢查各種邊界條件發(fā)生時(shí)程序執(zhí)行是否仍然正確，包括檢查判斷條件的邊界等，例如，某程序用于實(shí)現(xiàn)將百分制成績轉(zhuǎn)換為五級(jí)計(jì)分制成績，代碼如下：

ifcj>90print“優(yōu)秀”；ifcj<90andcj>80print“良好”；ifcj<80andcj>70print“中等”；ifcj<70andcj>60print“及格”；ifcj<60print“不及格”；4.邊界條件

顯然，程序中的判斷條件漏掉了相等的情況。

例如當(dāng)cj=90時(shí)，程序不會(huì)給出轉(zhuǎn)換結(jié)果。改正的辦法是在適當(dāng)?shù)奈恢?，加上?”。4.邊界條件

程序編寫時(shí)可能存在疏漏，應(yīng)對(duì)照程序詳細(xì)設(shè)計(jì)書的要求對(duì)程序進(jìn)行檢查和測(cè)試，看是否漏掉了某些原本需要的處理邏輯，也就是少了某些應(yīng)當(dāng)有的獨(dú)立路徑，或者某些獨(dú)立路徑存在處理錯(cuò)誤。例如，某程序用于實(shí)現(xiàn)將百分制成績轉(zhuǎn)換為五級(jí)計(jì)分制成績，代碼如下：

ifcj>=90print“優(yōu)秀”；ifcj<90andcj>=80print“良好”；ifcj<70andcj>=60print“及格”；ifcj<60print“不及格”；

5.獨(dú)立的路徑對(duì)照程序詳細(xì)設(shè)計(jì)書可以發(fā)現(xiàn)，程序漏掉了

cj<80andcj>=70這種情況。當(dāng)cj<80andcj>=70

時(shí)，程序無法給出轉(zhuǎn)換結(jié)果。5.獨(dú)立的路徑6.錯(cuò)誤處理

單元模塊應(yīng)能預(yù)見某些代碼運(yùn)行時(shí)可能出錯(cuò)的條件和情況，并設(shè)置適當(dāng)?shù)某鲥e(cuò)處理代碼，以便在相關(guān)代碼行運(yùn)行出現(xiàn)錯(cuò)誤時(shí)，能妥善處理，保證整個(gè)單元模塊處理邏輯的正確性，這種出錯(cuò)處理應(yīng)當(dāng)是模塊功能的一部分。6.錯(cuò)誤處理

例如，有代碼段如下：public

void

executeUpdate(String

sql)

{

Statement

stmt=null;

rs=null;

connect=DriverManager.getConnection(sConnStr,"sa","123");

stmt=connect.createStatement();

stmt.executeUpdate(sql);

stmt.close();

connect.close();

}6.錯(cuò)誤處理程序中，執(zhí)行數(shù)據(jù)庫操作的代碼行時(shí)存在出錯(cuò)的可能，如數(shù)據(jù)庫連接失敗等。因此，應(yīng)設(shè)置適當(dāng)?shù)某鲥e(cuò)處理代碼，以便在相關(guān)代碼行運(yùn)行出現(xiàn)異常時(shí)，能妥善處理。修改后的代碼段如下。6.錯(cuò)誤處理public

void

executeUpdate(String

sql)

{Statement

stmt=null;

rs=null;

try

{connect=DriverManager.getConnection(sConnStr,"sa","123");

stmt=connect.createStatement();

stmt.executeUpdate(sql);

stmt.close();

connect.close();

}

catch(SQLException

ex)

{

System.err.println(ex.getMessage());}

}6.錯(cuò)誤處理

若出現(xiàn)下列情況之一，則表明模塊的錯(cuò)誤處理功能包含有錯(cuò)誤或缺陷：程序執(zhí)行突然中斷，但沒有任何提示；在對(duì)錯(cuò)誤進(jìn)行處理之前，錯(cuò)誤條件已經(jīng)引起系統(tǒng)的干預(yù)出錯(cuò)的描述難以理解；出錯(cuò)的描述不足以對(duì)錯(cuò)誤定位，不足以確定出錯(cuò)的原因；顯示的錯(cuò)誤信息與實(shí)際的錯(cuò)誤原因不符；對(duì)錯(cuò)誤條件的處理不適宜等。7.輸入數(shù)據(jù)

應(yīng)當(dāng)對(duì)輸入數(shù)據(jù)進(jìn)行正確性、規(guī)范性或者合理性檢查，經(jīng)驗(yàn)表明，沒有對(duì)輸入數(shù)據(jù)進(jìn)行必要和有效的檢查，是造成軟件系統(tǒng)不穩(wěn)定或者執(zhí)行出問題的主要原因之一。例如某成績管理軟件，在成績輸入模塊，沒有對(duì)輸入的成績數(shù)據(jù)進(jìn)行合理性檢查，某個(gè)同學(xué)的某門課程成績應(yīng)當(dāng)是90分，一不小心輸入成了900分，數(shù)據(jù)保存后，在后來的求平均成績時(shí)，該同學(xué)的平均成績高達(dá)200多分，這顯然不符合情理，但出現(xiàn)這一錯(cuò)誤后，首先想到的可能是數(shù)據(jù)統(tǒng)計(jì)出錯(cuò)了，這種問題的原因排查也很麻煩。7.輸入數(shù)據(jù)

還有一種典型情況是，在系統(tǒng)登錄模塊，如果不對(duì)用戶名和密碼輸入的規(guī)范性和合理性進(jìn)行檢查，則惡意用戶有可能采用注入式攻擊等方式來試圖非法進(jìn)入系統(tǒng)。8.表達(dá)式、SQL語句

應(yīng)檢查程序中的表達(dá)式及SQL語句的語法和邏輯的正確性。對(duì)表達(dá)式應(yīng)該保證不含二義性，對(duì)于容易產(chǎn)生歧義的表達(dá)式或運(yùn)算符優(yōu)先級(jí)，如：&&、||、++、--等，可以采用擴(kuò)號(hào)“（）”運(yùn)算符避免二義性，這樣一方面能夠保證代碼執(zhí)行的正確性，同時(shí)也能夠提高代碼的可讀性。8.表達(dá)式、SQL語句

例如，&&和||是有優(yōu)先級(jí)差別的，&&的優(yōu)先級(jí)高于||，但這一點(diǎn)有時(shí)很容易被忽視，為此可以采用加“()”的方式，來寫相關(guān)的表達(dá)式。例如：職稱為工程師或講師，并且年齡小于35歲，寫成表達(dá)式應(yīng)當(dāng)是：

(ZC=“工程師”||ZC=“講師”)&&NL<35

如果不加括號(hào)，那么表達(dá)式的意思就和要求不一致了。8.表達(dá)式、SQL語句

又如，有以下包含SQL字符串的代碼：SqlCommand1.CommandText="DELETEFROMbj_jsWHEREBH='"&Trim(Me.TextBox1.Text)&"'ANDIDN="&Trim(Me.Textbox2.Text)&"'"

代碼中有錯(cuò)誤嗎？8.表達(dá)式、SQL語句

又如，有以下包含SQL字符串的代碼：SqlCommand1.CommandText="DELETEFROMbj_jsWHEREBH='"&Trim(Me.TextBox1.Text)&"'ANDIDN="&Trim(Me.Textbox2.Text)&"'"代碼中，“ANDIDN=”應(yīng)當(dāng)為“ANDIDN='”，類似于這樣的地方是很容易出錯(cuò)的。9.常量或全局變量的使用應(yīng)檢查常量和全局變量的使用是否正確。明確所使用的常量或全局變量的數(shù)據(jù)類型；保證常量數(shù)據(jù)類型和取值的恒定性，不能前后不一致。另外還要特別注意有沒有和全局變量同名的局部變量存在，如果有，要清楚它們各自的作用范圍，不能混淆。10.標(biāo)識(shí)符定義

標(biāo)識(shí)符定義應(yīng)規(guī)范一致；保證變量命名既簡(jiǎn)潔又能夠見名知意，不宜過長或過短，各種標(biāo)識(shí)符應(yīng)規(guī)范、容易記憶和理解。11.程序風(fēng)格

檢查程序風(fēng)格的一致性、規(guī)范性；代碼必須符合企業(yè)規(guī)范，保證所有成員的代碼風(fēng)格一致、格式工整。例如：對(duì)數(shù)組做循環(huán)時(shí)，不要一會(huì)兒采用下標(biāo)變量從小到大的方式（如:for(I=0;I++；I<10)），一會(huì)兒又采用從大到小的方式(如:for(I=9;I--;I>=0))；應(yīng)該盡量采用統(tǒng)一的方式，要么統(tǒng)一從小到大，要么統(tǒng)一從大到小。建議采用for循環(huán)和While循環(huán)，不要采用do{}while循環(huán)等。12.注釋

應(yīng)檢查注釋是否完整；是否清晰簡(jiǎn)潔；是否正確的反映了代碼的功能。錯(cuò)誤的注釋比沒有注釋更糟，會(huì)讓程序閱讀者產(chǎn)生錯(cuò)誤的理解。應(yīng)檢查是否做了多余的注釋；對(duì)于簡(jiǎn)單的一看就懂的代碼沒有必要注釋。還有就是應(yīng)檢查對(duì)包、類、屬性、方法功能、參數(shù)、返回值的注釋是否正確且容易理解等。本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測(cè)試5.1.3

JUnit

單元測(cè)試入門實(shí)踐第5章軟件測(cè)試過程SoftwareQualityAssuranceandTesting57

JUnit是一個(gè)開源的Java語言單元測(cè)試框架，它是單元測(cè)試框架體系結(jié)構(gòu)xUnit的一個(gè)實(shí)例，并且是最為成功的一個(gè)。JUnit設(shè)計(jì)得非常小巧，但是功能卻十分強(qiáng)大。通過JUnit提供的API可以編寫出測(cè)試結(jié)果明確、可重用的單元測(cè)試腳本。JUnit有它自己的JUnit擴(kuò)展生態(tài)圈。多數(shù)Java的開發(fā)環(huán)境都已經(jīng)集成了JUnit作為單元測(cè)試的工具。

在Junit中，對(duì)源代碼的測(cè)試過程，可以簡(jiǎn)單的理解為：給定參數(shù)，調(diào)用被測(cè)試代碼，然后比較測(cè)試結(jié)果與預(yù)期結(jié)果是否一致。

給定什么樣的參數(shù)是需要精心設(shè)計(jì)的，以便用盡可能少的測(cè)試發(fā)現(xiàn)盡可能多的問題和缺陷，以提高測(cè)試效率。調(diào)用被測(cè)試代碼，只需要給定對(duì)象名和方法名即可。Junit中的Assert類提供了一系列的斷言，來檢查被測(cè)試方法的真實(shí)返回值，是否與期望結(jié)果相一致。被測(cè)源代碼publicclassCalculate{

publicint

Add(inta,intb)

{

returna+b; }

......}測(cè)試腳本assertEquals(6,newCalculate().Add(3,3));6=Add(3,3)

通過

6!=Add(3,3)

不通過

Assert類中最常用的是assertEquals()，參數(shù)expected是預(yù)期取值，參數(shù)actual為測(cè)試執(zhí)行后的實(shí)際取值，assertEquals(expected,actual)用于比較兩者是否相等。示例如下。

assertEquals(0,newCalculate().Subtract(3,3))

這一示例代碼給定參數(shù)（3，3），調(diào)用Calculate().Subtract()，測(cè)試實(shí)際執(zhí)行結(jié)果是否等于0。下面通過一個(gè)簡(jiǎn)單的例子，來體驗(yàn)一下JUnit單元測(cè)試的快速入門。assertEquals(

預(yù)期值，實(shí)際執(zhí)行結(jié)果)=？設(shè)有Calculate類，代碼如下。publicclassCalculate{ publicint

Add(inta,intb)

{

returna+b; } publicint

Subtract(inta,intb)

{

returnb-a; }

//有問題的代碼行 publicint

Multiply(inta,intb)

{

returna*b; } publicint

Divide(inta,intb)

{

returna/b; }}

注意，源代碼中有一行是有問題的，代碼中已經(jīng)做了標(biāo)注。（1）選中Calculate.java后，單擊鼠標(biāo)右鍵，依次選擇“New”、“Other...”。（2）在彈出的對(duì)話框中依次選擇“Java”、“JUnit”、“JUnitTestCase”，然后點(diǎn)擊“Next”按鈕。（3）在彈出的對(duì)話框中輸入和設(shè)置相關(guān)信息，主要是Name等，本入門示例中采用默認(rèn)的信息即可，然后點(diǎn)擊“Next”按鈕。（4）在彈出的對(duì)話框中勾選“Calculate”類，這樣就會(huì)默認(rèn)勾選“Calculate”類的所有方法，本例中有4個(gè)方法，然后點(diǎn)擊“Finish”按鈕，（5）這樣我們就可以得到一個(gè)測(cè)試代碼的基本結(jié)構(gòu)。

其中的語句fail("Notyetimplemented");

表示測(cè)試腳本并未完成，需要測(cè)試人員在此處編寫自己的測(cè)試代碼。（6）把第一條“fail("Notyetimplemented");”語句刪除，

并在相應(yīng)位置輸入如下代碼。

assertEquals(6,newCalculate().Add(3,3));

這表示給定參數(shù)（3，3），調(diào)用Calculate().Add()，然后比較實(shí)際執(zhí)行結(jié)果是否等于6。

把第2條“fail("Notyetimplemented");”語句刪除，并在相應(yīng)位置輸入代碼：

assertEquals(3,newCalculate().Subtract(6,3));把第3條“fail("Notyetimplemented");”語句刪除，并在相應(yīng)位置輸入代碼：assertEquals(18,newCalculate().Multiply(6,3));把第4條“fail("Notyetimplemented");”語句刪除，并在相應(yīng)位置輸入代碼：assertEquals(2,newCalculate().Divide(6,3));然后點(diǎn)擊綠色的執(zhí)行按鈕，執(zhí)行測(cè)試腳本CalculateTest.java。（7）執(zhí)行結(jié)束后，可以看到測(cè)試結(jié)果，

測(cè)試結(jié)果顯示，執(zhí)行了4條測(cè)試，Errors為0，F(xiàn)ailures為1，testSubtract()方法測(cè)試未通過，實(shí)際執(zhí)行結(jié)果與預(yù)期結(jié)果不一致，說明testSubtract()方法源代碼中存在問題。（8）找到源代碼中的Subtract（）方法，把returnb-a改為returna-b。（9）點(diǎn)擊綠色的執(zhí)行按鈕，再次執(zhí)行測(cè)試腳本。（10）執(zhí)行結(jié)束后可以看到測(cè)試結(jié)果。結(jié)果顯示：執(zhí)行了4條測(cè)試，Errors為0，F(xiàn)ailures為0，測(cè)試通過。

以上JUnit單元測(cè)試入門實(shí)踐，雖然十分簡(jiǎn)單，但能夠體現(xiàn)針對(duì)源代碼編寫測(cè)試腳本、執(zhí)行測(cè)試腳本，測(cè)試不通過，找到源代碼中出錯(cuò)位置，修正源代碼中的問題，再次執(zhí)行測(cè)試腳本后測(cè)試通過的完整過程。源代碼測(cè)試腳本執(zhí)行測(cè)試腳本測(cè)試通過測(cè)試不通過修正本節(jié)內(nèi)容就講到這里，再見！軟件質(zhì)量保證與測(cè)試5.2集成測(cè)試第5章軟件測(cè)試過程SoftwareQualityAssuranceandTesting5.2.1集成測(cè)試簡(jiǎn)介和相依性分析集成測(cè)試簡(jiǎn)介

集成測(cè)試（也叫組裝測(cè)試、聯(lián)合測(cè)試）是單元測(cè)試的邏輯擴(kuò)展。它是在單元測(cè)試的基礎(chǔ)上，把多個(gè)經(jīng)過單元測(cè)試的模塊按照軟件概要設(shè)計(jì)書組裝起來進(jìn)行測(cè)試，檢查模塊組裝后，其功能、業(yè)務(wù)流程等是否實(shí)現(xiàn)或符合要求。單元B單元A單元C集成測(cè)試簡(jiǎn)介

它的最簡(jiǎn)單的形式是：把兩個(gè)或者多個(gè)已經(jīng)測(cè)試過的單元組裝成一個(gè)組件，并且測(cè)試它們之間的接口。然后這些組件又聚合成程序的更大部分，并最終擴(kuò)展到將所有單元組裝在一起。單元B單元A單元C單元E單元D單元F單元H單元G單元I集成測(cè)試簡(jiǎn)介

在集成測(cè)試之前，單元測(cè)試應(yīng)該已經(jīng)完成，集成測(cè)試中所使用的對(duì)象應(yīng)該是已經(jīng)通過單元測(cè)試的軟件單元模塊。這一點(diǎn)很重要，因?yàn)槿绻幌冉?jīng)過單元測(cè)試，那么集成測(cè)試的效果將會(huì)受到很大影響，并且會(huì)大幅增加軟件單元模塊代碼糾錯(cuò)的代價(jià)。單元測(cè)試被測(cè)模塊單元測(cè)試集成測(cè)試被測(cè)模塊集成測(cè)試簡(jiǎn)介

一般這樣定義集成測(cè)試：按照概要設(shè)計(jì)規(guī)格說明，根據(jù)實(shí)際情況對(duì)程序單元、模塊采用適當(dāng)?shù)募蓽y(cè)試策略組裝起來，對(duì)模塊之間的接口、集成后的功能、相應(yīng)技術(shù)指標(biāo)及要求等進(jìn)行檢驗(yàn)的測(cè)試工作。集成測(cè)試能夠發(fā)現(xiàn)單個(gè)模塊測(cè)試時(shí)難以發(fā)現(xiàn)的問題，集成測(cè)試的主要依據(jù)是軟件的概要設(shè)計(jì)書，即驗(yàn)證程序和概要設(shè)計(jì)說明的一致性。集成測(cè)試簡(jiǎn)介

一般而言，所有的軟件項(xiàng)目都不能擺脫系統(tǒng)集成這個(gè)階段。不管采用什么開發(fā)模式，具體的開發(fā)工作總是要從一個(gè)一個(gè)的軟件單元做起，軟件單元只有經(jīng)過組裝才能形成一個(gè)有機(jī)的整體。具體的集成過程可能是顯性的也可能是隱性的。只要有組裝集成，就總是會(huì)出現(xiàn)一些常見問題，工程實(shí)踐中，幾乎不存在軟件單元組裝過程中不出任何問題的情況。單元測(cè)試集成測(cè)試系統(tǒng)測(cè)試集成測(cè)試簡(jiǎn)介

經(jīng)驗(yàn)表明，作為軟件測(cè)試的一個(gè)階段，集成測(cè)試是不可以或缺的，直接從單元測(cè)試過渡到系統(tǒng)測(cè)試是極不妥當(dāng)?shù)淖龇ǎ覍?duì)于復(fù)雜的軟件而言，集成測(cè)試需要花費(fèi)的時(shí)間通常會(huì)要超過單元測(cè)試。

集成測(cè)試簡(jiǎn)介開始集成測(cè)試的時(shí)間，總體上說應(yīng)該是在單元測(cè)試之后，但在實(shí)際中往往單元測(cè)試和集成可能有一部分工作同步進(jìn)行，先做完單元測(cè)試的模塊就可以先集成，以節(jié)約時(shí)間。也就是說集成測(cè)試工作和單元測(cè)試工作可以有一部分是并行的。單元測(cè)試集成測(cè)試并行集成測(cè)試簡(jiǎn)介集成測(cè)試的流程一般包括計(jì)劃、設(shè)計(jì)、實(shí)現(xiàn)、執(zhí)行和分析評(píng)估等階段，如下圖所示。

計(jì)劃階段設(shè)計(jì)階段開發(fā)階段執(zhí)行階段分析評(píng)估缺陷跟蹤制定出適合本項(xiàng)目的集成測(cè)試計(jì)劃設(shè)計(jì)集成測(cè)試方案開發(fā)測(cè)試腳本，生成測(cè)試用例，開發(fā)樁模塊和驅(qū)動(dòng)模塊執(zhí)行集成測(cè)試，記錄測(cè)試過程和結(jié)果生成集成測(cè)試評(píng)估報(bào)告結(jié)束集成測(cè)試的過程集成測(cè)試簡(jiǎn)介集成測(cè)試的目的是確保各單元組合在一起后能夠按既定要求協(xié)作運(yùn)行，并確保新增加的模塊、代碼等行為的正確性。集成測(cè)試主要是白盒測(cè)試和灰盒測(cè)試，所以一般由開發(fā)人員或白盒測(cè)試工程師來進(jìn)行集成測(cè)試。

集成測(cè)試的必要性在于，一些模塊雖然能夠單獨(dú)地工作，但并不能保證連接起來也能正常工作。程序在某些局部反映不出來的問題，有可能在全局上會(huì)暴露出來，影響功能的實(shí)現(xiàn)。此外，在某些開發(fā)模式，如迭代式開發(fā)中，設(shè)計(jì)和實(shí)現(xiàn)是迭代進(jìn)行的，在這種情況下，集成測(cè)試的意義還在于它能間接地驗(yàn)證概要設(shè)計(jì)是否具有可行性。集成測(cè)試簡(jiǎn)介相依性分析

相依性是模塊以各種方式相互聯(lián)系和依賴的關(guān)系。一般而言，相依性對(duì)實(shí)現(xiàn)協(xié)作和問題分解來說是必要的，或者說模塊之間要實(shí)現(xiàn)分工和協(xié)作就不可避免的會(huì)產(chǎn)生相依性。但也有相依性是由于特定的實(shí)現(xiàn)方案或者算法、某種編程語言或特定的目標(biāo)環(huán)境所引起的，和問題本身并無必然關(guān)系。相依性1.與問題本身有關(guān)，為實(shí)現(xiàn)問題分解和模塊協(xié)作而產(chǎn)生2.與問題本身無關(guān)，由特定的實(shí)現(xiàn)方案或算法、某種編程語言或特定的目標(biāo)環(huán)境所引起相依性分析有的模塊相依性是顯性的，如一對(duì)一的信息發(fā)送模塊和信息接收模塊之間的相依性關(guān)系；而有的模塊相依性是隱性的，如操作權(quán)限約束、定時(shí)約束等都是隱性相依性的例子。相依性1.顯性相依性2.隱形相依性相依性分析模塊相依性有的是內(nèi)在的，典型的如繼承關(guān)系。例如Adapter是父類，ListAdapter和SpinnerAdapter是它的子類，當(dāng)修改父類Adapter時(shí)，兩個(gè)子類繼承自父類的相關(guān)內(nèi)容都會(huì)受到影響。相依性分析有的模塊相依性是外在的，這種相依性與模塊內(nèi)部的實(shí)現(xiàn)機(jī)制無關(guān)，只是通過外部發(fā)生關(guān)聯(lián)，典型的例子是共用公共數(shù)據(jù)。例如，模塊A、B、C共用公共數(shù)據(jù)M，當(dāng)模塊A修改公共數(shù)據(jù)M時(shí)，會(huì)影響到使用這一公共數(shù)據(jù)的其他兩個(gè)模塊B和C。公共數(shù)據(jù)

M模塊A寫數(shù)據(jù)模塊B模塊C影響相依性分析

通過相依性分析，有助于理解集成測(cè)試的必要性，能夠幫助我們更加有針對(duì)性的進(jìn)行集成測(cè)試設(shè)計(jì)，提高集成測(cè)試的工作效率、實(shí)際效果和工作水平。相依性分析

常見的相依性關(guān)系如下：①合成和聚集②繼承③全局變量或公共數(shù)據(jù)④調(diào)用API⑤服務(wù)器對(duì)象⑥被用作消息參數(shù)的對(duì)象本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測(cè)試SoftwareQualityAssuranceandTesting5.2集成測(cè)試第5章軟件測(cè)試過程5.2.2需要進(jìn)行集成測(cè)試的原因需要進(jìn)行集成測(cè)試的原因一個(gè)單元模塊雖然能夠單獨(dú)的正常工作，但并不能保證多個(gè)單元模塊連接起來后也能正常工作。每一個(gè)單元模塊功能都正確，并不意味著多個(gè)單元模塊組成的業(yè)務(wù)流仍然正確無誤。程序在某些局部反映不出來的問題，有可能在全局上會(huì)暴露出來。單元測(cè)試之后之所以還需要進(jìn)行集成測(cè)試，包括以下多種原因和情況。需要進(jìn)行集成測(cè)試的原因①一個(gè)模塊可能對(duì)另一個(gè)模塊產(chǎn)生不利的影響例如，A模塊發(fā)送數(shù)據(jù)，B模塊接收數(shù)據(jù)并進(jìn)行加工，如果A模塊發(fā)送數(shù)據(jù)的速度快于B模塊加工數(shù)據(jù)的速度，則兩個(gè)模塊集成起來后連續(xù)工作的時(shí)間長了，就會(huì)出現(xiàn)阻塞或者是數(shù)據(jù)丟失。需要進(jìn)行集成測(cè)試的原因②將子功能合成時(shí)不一定產(chǎn)生所期望的主功能。例如，某成績管理軟件，把成績輸入功能設(shè)計(jì)成兩個(gè)子功能，輸入百分制成績和輸入五級(jí)記分制成績，但集成測(cè)試時(shí)發(fā)現(xiàn)，這兩項(xiàng)子功能合起來并不能覆蓋所有可能的成績輸入，因?yàn)槌煽冚斎霑r(shí)還可能出現(xiàn)“缺考”、“作弊”等特殊情況！主功能子功能1子功能2......功能缺失需要進(jìn)行集成測(cè)試的原因③獨(dú)立可接受的誤差，在多個(gè)模塊組裝后可能會(huì)被放大，超過可接受的誤差限度。例如，設(shè)某模塊A中變量X有誤差X，在后續(xù)的模塊B中對(duì)X進(jìn)行了求立方運(yùn)算，那么運(yùn)算后的相對(duì)誤差就是3倍的X。因?yàn)閅=X3兩邊微分得dY=3X2dX,兩邊再同除以Y和X3得：dY/Y=3dX/X需要進(jìn)行集成測(cè)試的原因我們?cè)賮砜匆粋€(gè)關(guān)于誤差被放大到難以接受的實(shí)例。某計(jì)算利息的程序，計(jì)算過程是模塊A由年利率計(jì)算得出單日的利率I_day，計(jì)算結(jié)果提供給模塊B乘以金額和天數(shù)，得出總的利息I_all。設(shè)年利率為3%。如果I_day保留5位小數(shù)，則I_day≈0.00008，設(shè)某客戶存款1億元，存期100天，算出的利息為80萬元。如果I_day保留7位小數(shù)，則I_day≈0.0000822，算出的利息應(yīng)為82.2萬元。這兩者之間的誤差達(dá)到了2.2萬元。需要進(jìn)行集成測(cè)試的原因④可能會(huì)有單元測(cè)試中未發(fā)現(xiàn)的接口方面的錯(cuò)誤。例如模塊A有三個(gè)形式參數(shù)Str_1，Str_2，Str_3，功能是實(shí)現(xiàn)把Str_1中包含的Str_2去掉后保存到Str_3中。模塊B調(diào)用模塊A時(shí)參數(shù)位置寫反了，把原始字符串作為第二個(gè)參數(shù)，而把要?jiǎng)h除的字符串作為了第一個(gè)參數(shù)。這種情況單元測(cè)試時(shí)有可能沒有發(fā)現(xiàn)，因?yàn)閱卧獪y(cè)試主要關(guān)注模塊內(nèi)部的具體實(shí)現(xiàn)，而通過集成測(cè)試是可以發(fā)現(xiàn)的。需要進(jìn)行集成測(cè)試的原因⑤在單元測(cè)試中無法發(fā)現(xiàn)時(shí)序問題。例如，某購票軟件中有購票和退票模塊，這兩個(gè)模塊單獨(dú)運(yùn)行時(shí)都沒有問題，但集成測(cè)試時(shí)不執(zhí)行購票模塊，而是直接執(zhí)行退票模塊軟件就出現(xiàn)問題了，因?yàn)橥似睍r(shí)讀不到有效購票數(shù)據(jù)，在對(duì)退票模塊做單元測(cè)試時(shí)是默認(rèn)已經(jīng)先執(zhí)行了購票模塊，是已經(jīng)有購票數(shù)據(jù)的。需要進(jìn)行集成測(cè)試的原因⑤在單元測(cè)試中無法發(fā)現(xiàn)時(shí)序問題。還有就是在程序并發(fā)中，也很容易出現(xiàn)時(shí)序問題。單元測(cè)試時(shí)一個(gè)一個(gè)模塊單獨(dú)執(zhí)行，相互之間沒有影響，測(cè)試運(yùn)行可能都沒有發(fā)現(xiàn)問題，但集成測(cè)試時(shí)，多個(gè)模塊并發(fā)執(zhí)行，操作的次序存在不確定性，如果對(duì)時(shí)序問題考慮不周，就會(huì)出現(xiàn)錯(cuò)誤。需要進(jìn)行集成測(cè)試的原因⑤在單元測(cè)試中無法發(fā)現(xiàn)時(shí)序問題。還是以購票軟件為例，當(dāng)購票和退票模塊并發(fā)執(zhí)行，如果出現(xiàn)以下情形，軟件就出錯(cuò)了：

購票模塊read票數(shù)............write票數(shù)=票數(shù)-1

退票模塊......read票數(shù)write票數(shù)=票數(shù)+1......時(shí)間T需要進(jìn)行集成測(cè)試的原因⑤在單元測(cè)試中無法發(fā)現(xiàn)時(shí)序問題。購票模塊執(zhí)行過程中，并發(fā)執(zhí)行了退票模塊，兩個(gè)模塊都讀取到了相同的初始“票數(shù)X”，退票模塊執(zhí)行后，“票數(shù)X”加了1，但由于購票模塊已經(jīng)讀取過了“票數(shù)”，所以這一修改并沒有更新到購票模塊，購票操作執(zhí)行后,票數(shù)X=X-1被寫回到了數(shù)據(jù)池，這樣就出錯(cuò)了。正常結(jié)果應(yīng)當(dāng)是：余票X=X+1-1退回一張票賣出一張票，余票仍然=X；而實(shí)際結(jié)果是：余票X=X-1少了一張票，退回的票“丟失了”！需要進(jìn)行集成測(cè)試的原因⑥在單元測(cè)試中無法發(fā)現(xiàn)資源競(jìng)爭(zhēng)問題例如，A模塊和B模塊運(yùn)行時(shí)都同時(shí)需要資源X和Y，當(dāng)前運(yùn)行環(huán)境下資源X和Y各有1個(gè)，A模塊先申請(qǐng)到了資源X，B模塊先申請(qǐng)到了資源Y，然后A模塊等待資源Y，B模塊等待資源X，A、B陷入死鎖。模塊A模塊B資源X資源Y占用等待等待占用需要進(jìn)行集成測(cè)試的原因⑦共享數(shù)據(jù)或全局?jǐn)?shù)據(jù)的問題例如，成績管理軟件中，成績是全局?jǐn)?shù)據(jù)，在輸入模塊獲得初值后傳入統(tǒng)計(jì)模塊進(jìn)行統(tǒng)計(jì)。但集成測(cè)試時(shí)發(fā)現(xiàn)，輸入模塊為方便接收各種不同類型的成績，把成績數(shù)據(jù)默認(rèn)為字符類型，而在統(tǒng)計(jì)模塊，為便于計(jì)算，把成績數(shù)據(jù)默認(rèn)為數(shù)值類型，這樣兩個(gè)模塊一對(duì)接，就出現(xiàn)了數(shù)據(jù)類型不一致的問題。需要進(jìn)行集成測(cè)試的原因⑧數(shù)據(jù)單位、環(huán)境參數(shù)不統(tǒng)一的問題例如，某收費(fèi)軟件系統(tǒng)中有兩個(gè)模塊單元，一個(gè)稱重，一個(gè)計(jì)費(fèi)，但稱重模塊中重量單位為克，而計(jì)費(fèi)模塊中把重量的數(shù)據(jù)單位默認(rèn)為公斤，這樣當(dāng)稱重結(jié)果數(shù)據(jù)傳到計(jì)費(fèi)模塊后，費(fèi)用的計(jì)算結(jié)果肯定是錯(cuò)誤的。需要進(jìn)行集成測(cè)試的原因⑧數(shù)據(jù)單位、環(huán)境參數(shù)不統(tǒng)一的問題稱重重量：X=1500（克）

X=1500計(jì)費(fèi)1500*8=12000（元）需要進(jìn)行集成測(cè)試的原因⑧數(shù)據(jù)單位、環(huán)境參數(shù)不統(tǒng)一的問題下面用具體的數(shù)據(jù)來說明，設(shè)稱重模塊稱重的結(jié)果為1500，默認(rèn)單位為克，數(shù)據(jù)1500傳到計(jì)費(fèi)模塊后，計(jì)費(fèi)模塊重量單位默認(rèn)為公斤，于是把1500理解為1500公斤，按照每公斤8元的計(jì)費(fèi)標(biāo)準(zhǔn)計(jì)算得出的結(jié)果為需要繳費(fèi)12000元，這一結(jié)果顯然是錯(cuò)誤的，正確結(jié)果應(yīng)當(dāng)是12元。本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測(cè)試5.2集成測(cè)試第5章軟件測(cè)試過程SoftwareQualityAssuranceandTesting5.2.3集成測(cè)試方法和分析集成測(cè)試策略

集成測(cè)試的實(shí)施策略從集成的次數(shù)上來劃分，可以分為一次性集成和增量式集成。一次性集成也叫大爆炸式集成或非增量式集成。增量式集成測(cè)試又可以分為自底向上集成測(cè)試、自頂向下集成測(cè)試、三明治集成測(cè)試、核心系統(tǒng)優(yōu)先集成測(cè)試、分層集成測(cè)試等多種情況。集成測(cè)試策略集成測(cè)試1.一次性集成（也叫大爆炸式集成或非增量式集成）2.增量式集成測(cè)試自底向上集成自頂向下集成三明治集成核心系統(tǒng)優(yōu)先集成分層集成............集成測(cè)試策略

集成測(cè)試的實(shí)施策略從單元模塊集成的依據(jù)來劃分，可以分為基于分解的集成、基于事件（消息）的集成、基于調(diào)用的集成、分層集成等。集成測(cè)試策略

在對(duì)一個(gè)具體的軟件進(jìn)行集成測(cè)試時(shí)，應(yīng)當(dāng)從具體需要出發(fā)，根據(jù)被測(cè)軟件的特點(diǎn)，選擇合適的集成測(cè)試策略。一次性集成

在對(duì)軟件所有模塊逐個(gè)進(jìn)行單元測(cè)試后，采用一步到位的方法來構(gòu)造測(cè)試，按程序結(jié)構(gòu)圖將各個(gè)模塊單元全部聯(lián)接起來，把聯(lián)接后的程序當(dāng)作一個(gè)整體來進(jìn)行測(cè)試。一次性集成例如某軟件有A,B,C,D,E,F共6個(gè)單元模塊，結(jié)構(gòu)如圖5-1所示。在6個(gè)單元模塊都已經(jīng)完成單元測(cè)試之后，即可按照軟件結(jié)構(gòu)圖，把6個(gè)模塊組裝起來進(jìn)行一次性集成測(cè)試。一次性集成一次性集成的優(yōu)點(diǎn)有：①集成次數(shù)少，能快速完成集成測(cè)試②所需測(cè)試用例較少，測(cè)試工作量較小③不需要輔助性的驅(qū)動(dòng)模塊和樁模塊 一次性集成的缺點(diǎn)包括：①發(fā)現(xiàn)錯(cuò)誤的時(shí)間較遲②錯(cuò)誤較難定位③測(cè)試不夠不充分和徹底，即使通過測(cè)試，程序中可能還隱藏著一些錯(cuò)誤④測(cè)試的并行性差一次性集成一次性集成適用的情況主要是：①小型的、良構(gòu)的軟件系統(tǒng)②一個(gè)已經(jīng)存在的軟件系統(tǒng)，只是做了少量的修改③通過復(fù)用可信賴的構(gòu)件構(gòu)造的軟件系統(tǒng)增量式集成

按照某種關(guān)系，先把一部分模塊組裝起來進(jìn)行測(cè)試，然后逐步擴(kuò)大集成的范圍，最后再把整個(gè)程序組裝起來完成集成測(cè)試。增量式集成測(cè)試又可以分為自底向上集成測(cè)試、自頂向下集成測(cè)試、三明治集成測(cè)試、核心系統(tǒng)優(yōu)先集成測(cè)試、分層集成測(cè)試、基于使用的集成測(cè)試等多種情況。增量式集成

與一次性集成相比，增量式集成的優(yōu)缺點(diǎn)和適用情況分別如下。優(yōu)點(diǎn)：①集成測(cè)試可以較早的開始，測(cè)試的并行性較好②發(fā)現(xiàn)錯(cuò)誤的時(shí)間較早③錯(cuò)誤定位較為容易④測(cè)試比較充分增量式集成缺點(diǎn)：①需要驅(qū)動(dòng)模塊和樁模塊等輔助模塊②所需集成次數(shù)較多③所需測(cè)試用例較多，測(cè)試工作量較大適用情況：①增量式開發(fā)、框架式開發(fā)②并行軟件開發(fā)③較為復(fù)雜或者有一定規(guī)模的系統(tǒng)兩種集成策略的比較

一次性集成和增量式集成各有其優(yōu)缺點(diǎn)，它們的對(duì)比如下表。非增式測(cè)試增量式測(cè)試集成次數(shù)少，僅需1次多集成工作量較小較大所需測(cè)試用例較少較多驅(qū)動(dòng)模塊和樁模塊不需要需要發(fā)現(xiàn)錯(cuò)誤的時(shí)間較晚較早錯(cuò)誤定位較難較容易測(cè)試程度不徹底較為徹底測(cè)試的并行性差較好適用情況結(jié)構(gòu)良好的小型系統(tǒng)；原有系統(tǒng)做了少量的修改；通過復(fù)用可信賴的構(gòu)件構(gòu)造的軟件系統(tǒng)。增量式開發(fā)、框架式開發(fā)；并行軟件開發(fā)；較為復(fù)雜或者有一定規(guī)模的系統(tǒng)。集成測(cè)試分析

為做好集成測(cè)試工作，需要進(jìn)行多種測(cè)試分析，包括軟件結(jié)構(gòu)分析、模塊分析、接口分析等。軟件結(jié)構(gòu)分析

應(yīng)先對(duì)軟件結(jié)構(gòu)進(jìn)行分析。首先要明確系統(tǒng)的模塊單元結(jié)構(gòu)圖，這是集成測(cè)試的基本依據(jù)。其次要對(duì)系統(tǒng)各個(gè)組件之間的依賴關(guān)系進(jìn)行分析，然后據(jù)此確定集成測(cè)試的粒度，即集成模塊的大小。模塊分析

一般，可從以下幾個(gè)角度進(jìn)行模塊分析：①確定要集成的模塊；②明確這些模塊的關(guān)系；③把關(guān)系最密切的模塊首先集成在一起，再考慮外圍模塊；明確集成所需要的所有樁模塊和驅(qū)動(dòng)模塊，如果已有，則加進(jìn)來，如果沒有，則需要開發(fā)并加入到本次集成測(cè)試；消息流是否容易模擬，測(cè)試過程是否方便控制。接口分析接口分析要以概要設(shè)計(jì)為基礎(chǔ)，一般通過以下幾個(gè)步驟來完成：①確定系統(tǒng)的邊界、子系統(tǒng)的邊界和模塊的邊界。②確定模塊內(nèi)部的接口。③確定模塊間的接口。④確定子系統(tǒng)間的接口。⑤確定本軟件系統(tǒng)與操作系統(tǒng)的接口。⑥確定本軟件系統(tǒng)與硬件的接口。⑦確定本軟件系統(tǒng)與第三方軟件的接口。必須盡可能早地分析接口的可測(cè)試性，提前為后續(xù)的測(cè)試工作做好準(zhǔn)備。本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測(cè)試5.2.4自頂向下和自底向上集成SoftwareQualityAssuranceandTesting5.2集成測(cè)試第5章軟件測(cè)試過程在實(shí)際的軟件測(cè)試工作中，增量式集成是較為普遍采用的，增量式集成又可以分為自頂向下和自底向上兩種典型的情況。自頂向下和自底向上集成

自頂向下增量式集成是指，依據(jù)程序結(jié)構(gòu)圖，從頂層開始，按照層次由上到下的順序逐步擴(kuò)大集成的范圍，增加集成的模塊，來進(jìn)行集成測(cè)試。在逐步擴(kuò)大集成范圍，增加集成模塊的具體路徑選擇上,又可以分為廣度優(yōu)先和深度優(yōu)先。自頂向下增量式集成具體步驟如下：從軟件結(jié)構(gòu)圖的樹根開始，將程序的主控模塊作為測(cè)試驅(qū)動(dòng)；根據(jù)集成的路徑（深度優(yōu)先或廣度有限），每次加入一個(gè)或者幾個(gè)已經(jīng)完成了單元測(cè)試的下級(jí)模塊，其它相關(guān)模塊均用樁模塊代替；進(jìn)行集成測(cè)試，測(cè)試集成新模塊后有沒有產(chǎn)生錯(cuò)誤；上述過程從第2步重復(fù)進(jìn)行，直到所有單元都集成測(cè)試完畢。以深度優(yōu)先為例，自頂向下增量式集成的過程如下圖所示。自頂向下增量式集成自頂

向下

增量式

集成

(深度

優(yōu)先)自頂向下增量式集成的優(yōu)點(diǎn)有：集成測(cè)試可以較早的開始減少了驅(qū)動(dòng)模塊的開發(fā)如果底層接口未定義或可能修改，則可以避免提交不穩(wěn)定的接口自頂向下增量式集成的缺點(diǎn)有：樁模塊的開發(fā)代價(jià)較大底層模塊的無法預(yù)料的條件要求可能迫使頂層構(gòu)件的修改在軟件集成后，對(duì)底層模塊的調(diào)用和測(cè)試不夠充分。自頂向下增量式集成

自底向上增量式集成是指，依據(jù)程序結(jié)構(gòu)圖，集成從最底層的模塊開始，按照層次由下到上的順序逐步擴(kuò)大集成的范圍，增加集成的模塊，來進(jìn)行集成測(cè)試。同樣，在逐步擴(kuò)大集成范圍，增加集成模塊的具體路徑選擇上，也可以分為廣度優(yōu)先和深度優(yōu)先。自底向上增量式集成具體步驟如下：從軟件結(jié)構(gòu)圖的葉子節(jié)點(diǎn)開始，逐步增加上級(jí)或者同級(jí)模塊；根據(jù)集成的路徑（深度優(yōu)先或廣度優(yōu)先），每次加入一個(gè)或者幾個(gè)已經(jīng)完成了單元測(cè)試的上級(jí)或者同級(jí)模塊，其它相關(guān)模塊均用驅(qū)動(dòng)模塊代替；進(jìn)行集成測(cè)試，測(cè)試集成新模塊后有沒有產(chǎn)生錯(cuò)誤；上述過程從第2步重復(fù)進(jìn)行，直到所有都集成測(cè)試完畢。以深度優(yōu)先為例，自頂向下增量式集成的過程如后圖所示。自底向上增量式集成自底

向上

增量式

集成

(深度

優(yōu)先)

自底向上的增量式集成（Bottom-UpIntegration）方式是較常使用的方法。這種方式從最底層的模塊開始組裝和測(cè)試。因?yàn)槟K是自底向上進(jìn)行組裝的，對(duì)于一個(gè)給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）事前已經(jīng)完成組裝并經(jīng)過測(cè)試，所以不再需要編制樁模塊。自底向上增量式集成自底向上的增量式集成優(yōu)點(diǎn)如下：多組底層葉節(jié)點(diǎn)的測(cè)試和集成可以并行進(jìn)行不限制可測(cè)試性，對(duì)底層模塊的調(diào)用和測(cè)試較為分實(shí)現(xiàn)方便，不需要樁模塊測(cè)試人員能較好地鎖定軟件故障所在位置自底向上增量式集成自底向上的增量式集成缺點(diǎn)如下：驅(qū)動(dòng)模塊的開發(fā)成本較大高層構(gòu)件的可操作性和互操作性測(cè)試得不夠充分對(duì)于某些開發(fā)模式不適用，如使用XP開發(fā)方法，它會(huì)要求測(cè)試人員在全部軟件單元實(shí)現(xiàn)之前完成核心軟件部件的集成測(cè)試。自底向上增量式集成自底向上的增量式集成適用情況實(shí)現(xiàn)具體功能的復(fù)雜代碼在底層（多數(shù)軟件都是如此）在子系統(tǒng)的迭代和增量開發(fā)中，支持單位范圍內(nèi)的測(cè)試重要構(gòu)件在底層的系統(tǒng)自底向上的集成測(cè)試方案是工程實(shí)踐中最常用的集成測(cè)試方案。相關(guān)技術(shù)也較為成熟。自底向上增量式集成自頂向下集成自底向上集成優(yōu)點(diǎn)減少了驅(qū)動(dòng)模塊的開發(fā)；一開始便能讓測(cè)試者看到系統(tǒng)的框架可以自然地做到逐步求精；如果底層接口未定義或可能修改，則可以避免提交不穩(wěn)定的接口。多組底層葉節(jié)點(diǎn)的測(cè)試和集成可以并行進(jìn)行；不限制可測(cè)試性，對(duì)底層模塊的調(diào)用和測(cè)試較為充分；實(shí)現(xiàn)方便，不需要樁模塊；測(cè)試人員能較好地鎖定軟件故障所在位置；由于驅(qū)動(dòng)模塊模擬了所有調(diào)用參數(shù)，即使數(shù)據(jù)流并未構(gòu)成有向的非環(huán)狀圖，生成測(cè)試數(shù)據(jù)也沒有困難；特別適合于關(guān)鍵模塊在結(jié)構(gòu)圖底部的情況。兩種增量式集成的對(duì)比自頂向下集成自底向上集成缺點(diǎn)樁模塊的開發(fā)代價(jià)較大；底層模塊的無法預(yù)料的條件要求可能迫使上層模塊的修改；在軟件集成后，對(duì)底層模塊的調(diào)用和測(cè)試不夠充分；在輸入/輸出模塊接入系統(tǒng)以前，在樁模塊中表示測(cè)試數(shù)據(jù)有一定困難；由于樁模塊不能模擬數(shù)據(jù)，如果模塊間的數(shù)據(jù)流不能構(gòu)成有向的非環(huán)狀圖，一些模塊的測(cè)試數(shù)據(jù)難于生成；觀察和解釋測(cè)試輸出往往也是困難的。需要驅(qū)動(dòng)模塊；高層構(gòu)件的可操作性和互操作性測(cè)試得不夠充分；對(duì)于某些開發(fā)模式不適用，如使用XP開發(fā)方法，它會(huì)要求測(cè)試人員在全部軟件單元實(shí)現(xiàn)之前完成核心軟件部件的集成測(cè)試；整個(gè)程序（系統(tǒng)）的框架要后期才能看到；只有到測(cè)試過程的后期才能發(fā)現(xiàn)時(shí)序問題和資源競(jìng)爭(zhēng)問題。兩種增量式集成的對(duì)比

自頂向下集成和自底向上集成各有其優(yōu)缺點(diǎn)，為了取長補(bǔ)短，可以把兩者結(jié)合起來使用，這就是三明治式集成。三明治式集成的過程如下圖所示。三明治式集成三明治式集成

三明治式集成把自頂向下和自底向上集成結(jié)合起來使用后，可以同時(shí)具有自頂向下和自底向上兩種集成方式的一些優(yōu)點(diǎn)之外，能夠減少一些樁模塊和驅(qū)動(dòng)模塊的開發(fā)。本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測(cè)試5.2.5核心系統(tǒng)先行集成SoftwareQualityAssuranceandTesting5.2集成測(cè)試第5章軟件測(cè)試過程方法簡(jiǎn)介

核心系統(tǒng)先行集成測(cè)試法的思想是先對(duì)軟件核心部件進(jìn)行集成測(cè)試，在測(cè)試通過的基礎(chǔ)上再按各外圍軟件部件的重要程度逐個(gè)集成到核心系統(tǒng)中。每次加入一個(gè)外圍軟件部件都產(chǎn)生一個(gè)產(chǎn)品基線，直至最后形成穩(wěn)定的軟件產(chǎn)品。方法示意1.核心系統(tǒng)集成：核心模塊A+B+C2.增加外圍模塊D：核心模塊A+B+C模塊D3.增加外圍模塊E：核心模塊A+B+C模塊D模塊E..................

方法簡(jiǎn)介

核心系統(tǒng)先行集成測(cè)試法對(duì)應(yīng)的集成過程是一個(gè)逐漸趨于閉合的螺旋形曲線，代表產(chǎn)品逐步定型的過程。具體步驟如下:方法簡(jiǎn)介

步驟一:對(duì)核心系統(tǒng)中的每個(gè)模塊進(jìn)行單獨(dú)的、充分的測(cè)試，必要時(shí)使用驅(qū)動(dòng)模塊和樁模塊;步驟二:對(duì)于核心系統(tǒng)中的所有模塊一次性集合到被測(cè)系統(tǒng)中，解決集成中出現(xiàn)的各類問題。在核心系統(tǒng)規(guī)模相對(duì)較大的情況下，也可以按照自底向上的步驟，集成核心系統(tǒng)的各組成模塊。方法簡(jiǎn)介

步驟三:按照各外圍軟件部件的重要程度以及模塊間的相互制約關(guān)系，擬定外圍軟件部件集成到核心系統(tǒng)中的順序方案。方案經(jīng)評(píng)審以后，即可進(jìn)行外圍軟件部件的集成。步驟四:在外圍軟件部件添加到核心系統(tǒng)以前，外圍軟件部件應(yīng)先完成內(nèi)部的模塊級(jí)集成測(cè)試。步驟五:按順序不斷加入外圍軟件部件，排除外圍軟件部件集成中出現(xiàn)的問題，形成最終的用戶系統(tǒng)。方法簡(jiǎn)介

這種集成測(cè)試方法對(duì)于快速軟件開發(fā)很有效果，適合較復(fù)雜系統(tǒng)的集成測(cè)試，能保證一些重要的功能和服務(wù)的盡早實(shí)現(xiàn)。缺點(diǎn)是采用此法的系統(tǒng)一般應(yīng)能明確區(qū)分核心軟件部件和外圍軟件部件，核心軟件部件應(yīng)具有較高的耦合度，外圍軟件部件內(nèi)部也應(yīng)具有較高的耦合度，但各外圍軟件部件之間應(yīng)具有較低的耦合度。方法圖解

有一個(gè)軟件，結(jié)構(gòu)如圖所示。

圖中節(jié)點(diǎn)①②③④⑤構(gòu)成了軟件的核心系統(tǒng)，⑥⑦⑧⑨是次要模塊，可以把①②③④⑤先集成起來，得到一個(gè)可以運(yùn)行的核心系統(tǒng)，然后再每次增加一個(gè)外圍節(jié)點(diǎn)，直到所有部分集成完畢。本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測(cè)試5.2集成測(cè)試第5章軟件測(cè)試過程SoftwareQualityAssuranceandTesting5.2.6基于調(diào)用圖的集成基于調(diào)用圖的集成

可以基于模塊單元的調(diào)用關(guān)系，也就是調(diào)用圖來進(jìn)行集成，這樣可以減少對(duì)驅(qū)動(dòng)模塊和樁模塊的需要?；谡{(diào)用圖的集成主要有相鄰集成和成對(duì)集成。成對(duì)集成

節(jié)點(diǎn)對(duì)是指存在調(diào)用關(guān)系的一對(duì)節(jié)點(diǎn)，如下圖中的節(jié)點(diǎn)9和16，17和18等。成對(duì)集成成對(duì)集成

成對(duì)集成就是把節(jié)點(diǎn)對(duì)放在一起進(jìn)行集成。這樣可以免除樁模塊和驅(qū)動(dòng)模塊的開發(fā)工作。成對(duì)集成的方法就是對(duì)應(yīng)調(diào)用圖的每一個(gè)邊建立并執(zhí)行一個(gè)集成測(cè)試。相鄰集成

這里的相鄰是針對(duì)節(jié)點(diǎn)而言的，節(jié)點(diǎn)的鄰居就是跟該節(jié)點(diǎn)存在直接調(diào)用或者被調(diào)用關(guān)系的節(jié)點(diǎn)，包括調(diào)用該節(jié)點(diǎn)的上層節(jié)點(diǎn)和該節(jié)點(diǎn)調(diào)用的下層節(jié)點(diǎn)。在有向圖中，節(jié)點(diǎn)鄰居包括該節(jié)點(diǎn)的所有直接前驅(qū)節(jié)點(diǎn)和所有直接后繼節(jié)點(diǎn)。相鄰集成

相鄰集成就是基于調(diào)用和協(xié)作的關(guān)系，以某個(gè)節(jié)點(diǎn)為中心，把與其存在直接調(diào)用或者被調(diào)用關(guān)系的節(jié)點(diǎn)，包括調(diào)用該節(jié)點(diǎn)的上層節(jié)點(diǎn)和該節(jié)點(diǎn)調(diào)用的下層節(jié)點(diǎn)等，都放在一起進(jìn)行集成測(cè)試，如下圖所示，圖中分別以16和26號(hào)節(jié)點(diǎn)為中心，用陰影區(qū)域標(biāo)志出了兩組相鄰集成的范圍。相鄰集成基于調(diào)用圖的集成小結(jié)

基于調(diào)用圖的集成是從調(diào)用關(guān)系和協(xié)作關(guān)系出發(fā)，對(duì)成對(duì)節(jié)點(diǎn)或者相鄰節(jié)點(diǎn)進(jìn)行集成測(cè)試?；谡{(diào)用圖的集成的優(yōu)點(diǎn)有：①免除了驅(qū)動(dòng)器/樁的開發(fā)工作②接口關(guān)系測(cè)試充分③測(cè)試集中于銜接的功能性④測(cè)試和集成可以并行開始基于調(diào)用圖的集成小結(jié)

缺點(diǎn)有：①調(diào)用或協(xié)作的關(guān)系可能錯(cuò)綜復(fù)雜的，實(shí)施有難度②要充分測(cè)試底層構(gòu)件較困難，在復(fù)雜的軟件中，某些結(jié)構(gòu)關(guān)系沒有被單獨(dú)測(cè)試到③特定的調(diào)用或協(xié)作可能是不完全的④缺陷可能被隔離，而沒有被發(fā)現(xiàn)基于調(diào)用圖的集成小結(jié)基于調(diào)用圖的集成主要適用于以下兩種情況：需要盡快驗(yàn)證一個(gè)可運(yùn)行的調(diào)用或協(xié)作關(guān)系被測(cè)系統(tǒng)已清楚定義了構(gòu)件的調(diào)用和協(xié)作關(guān)系本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測(cè)試5.2集成測(cè)試第5章軟件測(cè)試過程SoftwareQualityAssuranceandTesting5.2.7高頻集成

早期的軟件開發(fā)一般采用“瀑布式”過程，把軟件的集成測(cè)試安排在開發(fā)的后期。在軟件項(xiàng)目后期才開始對(duì)軟件進(jìn)行集成測(cè)試，這樣會(huì)給軟件項(xiàng)目帶來很多不確定性，甚至是巨大風(fēng)險(xiǎn)，問題、缺陷和偏差在后期集中暴露出來，程序員往往會(huì)需要修改越來越多的缺陷，軟件無法按時(shí)交付，甚至于整個(gè)軟件項(xiàng)目最終以失敗而告終。高頻集成

高頻集成測(cè)試是指，同步于軟件開發(fā)過程，頻繁不斷的對(duì)已經(jīng)完成的代碼進(jìn)行集成測(cè)試。

這種方式一般是在開發(fā)完成部分代碼之后，隨即開始開始集成測(cè)試，而不必等到全部代碼開發(fā)完成，每次集成測(cè)試通過之后，即可得到一個(gè)產(chǎn)品基線，然后每新增一定的代碼量之后，都會(huì)加入到基線之中，并再次進(jìn)行集成測(cè)試。

高頻集成高頻集成代碼模塊代碼模塊基線集成代碼模塊集成代碼模塊代碼模塊代碼模塊集成代碼模塊代碼模塊代碼模塊集成集成

高頻集成測(cè)試方法頻繁不斷地將新代碼加入到一個(gè)已經(jīng)穩(wěn)定的基線中，這樣可以盡早地發(fā)現(xiàn)代碼中的問題，同時(shí)控制可能出現(xiàn)的基線偏差，而不至于等到最后階段各種問題、缺陷和偏差集中暴露，甚至于發(fā)現(xiàn)整個(gè)軟件根本就不是我們所需要的。高頻集成

采用高頻集成測(cè)試需要具備一定的條件:

1.可以持續(xù)獲得一個(gè)穩(wěn)定的增量，并且該增量自身已被驗(yàn)證沒有問題;

2.大部分有意義的功能增加可以在一個(gè)相對(duì)穩(wěn)定的時(shí)間間隔（如每個(gè)工作日）內(nèi)獲得;高頻集成

3.測(cè)試包和代碼的開發(fā)工作必須是并行進(jìn)行的，并且需要版本控制工具來保證始終維護(hù)的是測(cè)試腳本和代碼的最新版本;

4.必須借助于使用自動(dòng)化工具來完成，因?yàn)楦哳l集成一個(gè)顯著的特點(diǎn)就是頻繁集成，次數(shù)很多，顯然依靠人工的方法是不勝任的。高頻集成

高頻集成由于需要頻繁多次的進(jìn)行集成測(cè)試，工作量很大，依靠手工來完成的話，成本太高，效率太低，有自動(dòng)化集成測(cè)試工具能幫助完成高頻集成。例如，白天開發(fā)團(tuán)隊(duì)進(jìn)行代碼開發(fā)，下班前提交代碼，已經(jīng)配置好的測(cè)試平臺(tái)在晚上自動(dòng)化地把新增代碼與原有基線集成到一起完成測(cè)試，并將測(cè)試結(jié)果發(fā)到各個(gè)開發(fā)人員的電子郵箱中。

高頻集成高頻集成1.下班前提交2.夜間自動(dòng)完成集成測(cè)試3.反饋測(cè)試結(jié)果高頻集成測(cè)試一般采用如下步驟來完成:

步驟一:選擇集成測(cè)試自動(dòng)化工具。如很多Java項(xiàng)目采用Junit+Ant方案來實(shí)現(xiàn)集成測(cè)試的自動(dòng)化，也有其它一些商業(yè)集成測(cè)試工具可供選擇。步驟二:設(shè)置版本控制工具，以確保集成測(cè)試自動(dòng)化工具所獲得的版本是最新版本。如使用CVS進(jìn)行版本控制。步驟三:測(cè)試人員和開發(fā)人員負(fù)責(zé)編寫對(duì)應(yīng)程序代碼的測(cè)試腳本。高頻集成測(cè)試步驟步驟四:設(shè)置自動(dòng)化集成測(cè)試工具，每隔一段時(shí)間對(duì)配置管理庫中新添加的代碼進(jìn)行自動(dòng)化的集成測(cè)試，并將測(cè)試結(jié)果報(bào)告給開發(fā)人員和測(cè)試人員。步驟五:測(cè)試人員監(jiān)督代碼開發(fā)人員及時(shí)關(guān)閉不合格項(xiàng)。按照步驟三至步驟五不斷循環(huán)，直至形成最終軟件產(chǎn)品。高頻集成測(cè)試步驟

高頻集成方案能在開發(fā)過程中及時(shí)發(fā)現(xiàn)代碼中的問題和錯(cuò)誤，能直觀地看到開發(fā)團(tuán)隊(duì)的有效工程進(jìn)度。在此方案中，開發(fā)維護(hù)源代碼與開發(fā)維護(hù)軟件測(cè)試包被賦予了同等的重要性，這對(duì)有效防止錯(cuò)誤、及時(shí)糾正錯(cuò)誤都很有幫助。該方案的缺點(diǎn)在于測(cè)試包有時(shí)候可能不能暴露深層次的編碼錯(cuò)誤和圖形界面錯(cuò)誤等。高頻集成本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測(cè)試5.2集成測(cè)試第5章軟件測(cè)試過程SoftwareQualityAssuranceandTesting5.2.8其它集成測(cè)試方法客戶/服務(wù)器集成測(cè)試1.客戶/服務(wù)器結(jié)構(gòu)隨著網(wǎng)絡(luò)的發(fā)展和普及，越來越多的軟件為客戶/服務(wù)器的結(jié)構(gòu)形式，相應(yīng)的，客戶/服務(wù)器集成也應(yīng)用得日益廣泛?？蛻?服務(wù)器軟件結(jié)構(gòu)如圖所示。

客戶/服務(wù)器軟件由于分為客戶端和服務(wù)器端兩部分，其集成的過程需要經(jīng)過三個(gè)環(huán)節(jié)，具體如下：①客戶端+服務(wù)器樁模塊集成②服務(wù)器端+客戶樁模塊集成③客戶端+服務(wù)器端集成即先分別單獨(dú)測(cè)試客戶端和服務(wù)器端，而用樁模塊代替另一端，等到測(cè)試通過后，再把客戶端和服務(wù)器端組裝在一起測(cè)試。通過這樣三個(gè)環(huán)節(jié)的測(cè)試，來檢查驗(yàn)證客戶端和服務(wù)器端之間交互的正確性等。客戶/服務(wù)器集成測(cè)試

一些軟件具有明顯的層次，如圖所示，某軟件分為核心層、實(shí)用程序?qū)?、?yīng)用程序?qū)雍陀脩艚缑鎸?。分層集成測(cè)試就適用于這樣有明顯層次關(guān)系的系統(tǒng)。分層集成測(cè)試分層集成的具體步驟如下：劃分系統(tǒng)的層次，或者系統(tǒng)設(shè)計(jì)時(shí)就已經(jīng)有層次；確定每個(gè)層次內(nèi)部的集成策略，并分層進(jìn)行測(cè)試；確定層次間的集成策略，并把多個(gè)層次組裝起來測(cè)試。分層集成測(cè)試

分層集成一般只較為適用于具有明顯層次結(jié)構(gòu)的軟件系統(tǒng)。分層集成測(cè)試1.分層測(cè)試2.跨層測(cè)試

一個(gè)軟件可能有很多個(gè)功能，但不同的功能其重要性可能不一樣，或者進(jìn)度要求可能不一樣，例如某些功能可能急于要投入使用。為優(yōu)先測(cè)試最為重要的功能，最受關(guān)注的功能，或者急于要投入使用的功能，可以采用基于功能的集成測(cè)試。基于功能的集成測(cè)試

基于功能的集成測(cè)試具體步驟如下：①確定軟件中各個(gè)功能的優(yōu)先級(jí)別；②分析優(yōu)先級(jí)最高的功能路徑，把該路徑上的所有模塊集成到一起，必要時(shí)使用驅(qū)動(dòng)模塊和樁模塊；③增加一個(gè)關(guān)鍵功能，繼續(xù)步驟2，直到所有模塊都被集成到被測(cè)系統(tǒng)中。采用這一方法的目的是盡早測(cè)試和驗(yàn)證系統(tǒng)的關(guān)鍵功能?；诠δ艿募蓽y(cè)試

基于功能的集成，最主要的優(yōu)點(diǎn)就是可以直接驗(yàn)證系統(tǒng)中的主要功能，盡可能早地確認(rèn)所開發(fā)的系統(tǒng)中，關(guān)鍵功能是否得以實(shí)現(xiàn)。缺點(diǎn)是不適用復(fù)雜系統(tǒng)，對(duì)于部分接口測(cè)試不充分，容易漏掉大量接口錯(cuò)誤，測(cè)試開始的時(shí)候需要大量的樁模塊，以及容易出現(xiàn)較大的冗余測(cè)試?；诠δ艿募蓽y(cè)試

基于功能的集成，適用于以下情況：①主要功能具有較大風(fēng)險(xiǎn)性的產(chǎn)品；②探索型技術(shù)研發(fā)項(xiàng)目；③注重功能實(shí)現(xiàn)的項(xiàng)目；④對(duì)于所要實(shí)現(xiàn)的功能信心不強(qiáng)的項(xiàng)目?；诠δ艿募蓽y(cè)試

有的軟件項(xiàng)目，工期比較緊，需要加快項(xiàng)目的總體進(jìn)度，為盡可能早地進(jìn)行集成測(cè)試，提高開發(fā)與集成測(cè)試的并行性，可以采用基于進(jìn)度的集成測(cè)試，即把已經(jīng)開發(fā)好的部分盡可能先進(jìn)行集成，這樣就能有效地縮短后續(xù)工作所需的工期。

基于進(jìn)度的集成測(cè)試

基于進(jìn)度的集成的優(yōu)點(diǎn)有：具有比較高的并行度；能夠有效加快軟件開發(fā)進(jìn)度，縮短軟件項(xiàng)目的總體工期。而缺點(diǎn)是：可能最早開發(fā)出來的模塊之間缺乏整體性，只能分頭進(jìn)行集成，導(dǎo)致許多接口必須等到后期才能驗(yàn)證，但此時(shí)系統(tǒng)可能已經(jīng)很復(fù)雜，往往無法發(fā)現(xiàn)隱藏的接口問題；樁模塊和驅(qū)動(dòng)模塊的工作量可能會(huì)變得很龐大；由于進(jìn)度的原因，模塊可能很不穩(wěn)定且會(huì)不斷變動(dòng)，從而導(dǎo)致測(cè)試的重復(fù)和浪費(fèi)。基于進(jìn)度的集成僅適用于開發(fā)進(jìn)度優(yōu)先級(jí)高于軟件質(zhì)量的項(xiàng)目。基于進(jìn)度的集成測(cè)試本節(jié)內(nèi)容就講到這里，謝謝，再見！軟件質(zhì)量保證與測(cè)試SoftwareQualityAssuranceandTesting5.3.1系統(tǒng)測(cè)試概述

5.3系統(tǒng)測(cè)試第5章軟件測(cè)試過程系統(tǒng)測(cè)試是將經(jīng)過集成測(cè)試的軟件，作為計(jì)算機(jī)系統(tǒng)的一個(gè)部分，與系統(tǒng)中其他部分結(jié)合起來，在實(shí)際運(yùn)行環(huán)境下對(duì)整個(gè)軟硬件系統(tǒng)進(jìn)行的一系列測(cè)試，以發(fā)現(xiàn)軟件中潛在的問題。系統(tǒng)測(cè)試的對(duì)象不僅僅包括開發(fā)出來的的軟件，還包括軟件運(yùn)行所依賴的硬件和接口、操作系統(tǒng)、其它支持軟件以及相關(guān)數(shù)據(jù)等。什么是系統(tǒng)測(cè)試系統(tǒng)測(cè)試是將經(jīng)過集成測(cè)試的軟件，作為計(jì)算機(jī)系統(tǒng)的一個(gè)部分，與系統(tǒng)中其他部分結(jié)合起來，在實(shí)際運(yùn)行環(huán)境下對(duì)整個(gè)軟硬件系統(tǒng)進(jìn)行的一系列測(cè)試，以發(fā)現(xiàn)軟件中潛在的問題。系統(tǒng)測(cè)試的對(duì)象不僅僅包括開發(fā)出來的的軟件，還包括軟件運(yùn)行所依賴的硬件和接口、操作系統(tǒng)、其它支持軟件以及相關(guān)數(shù)據(jù)等。什么是系統(tǒng)測(cè)試系統(tǒng)測(cè)試的依據(jù)是軟件的規(guī)格說明書，通過測(cè)試驗(yàn)證軟件系統(tǒng)是否符合軟件規(guī)格，找出與軟件規(guī)格不符或與之矛盾的地方。

系統(tǒng)測(cè)試的依據(jù)學(xué)生管理系統(tǒng)軟件規(guī)格說明書是否符合

系統(tǒng)測(cè)試完全采用黑盒測(cè)試技術(shù)，因?yàn)檫@時(shí)已不需要考慮組件模塊的實(shí)現(xiàn)細(xì)節(jié)，而主要是根據(jù)需求分析時(shí)確定的標(biāo)準(zhǔn)檢驗(yàn)軟件是否滿足功能、性能和安全等方面的要求。系統(tǒng)測(cè)試采用的測(cè)試技術(shù)

系統(tǒng)測(cè)試所用的數(shù)據(jù)應(yīng)當(dāng)盡可能地像真實(shí)數(shù)據(jù)一樣精確和有代表性，也應(yīng)當(dāng)和真實(shí)數(shù)據(jù)的大小和復(fù)雜性相當(dāng)。如果測(cè)試數(shù)據(jù)很簡(jiǎn)單，不能反映軟件實(shí)際使用時(shí)的真實(shí)情況，那么這樣的系統(tǒng)測(cè)試就是浪費(fèi)時(shí)間，沒有意義，無法對(duì)軟件進(jìn)行有效的檢驗(yàn)和測(cè)試。系統(tǒng)測(cè)試采用的數(shù)據(jù)

要讓測(cè)試數(shù)據(jù)與真實(shí)數(shù)據(jù)的大小和復(fù)雜性相當(dāng)，一個(gè)簡(jiǎn)單的方法就是直接使用真實(shí)數(shù)據(jù)作為測(cè)試數(shù)據(jù)。