10.1軟件測試的定義

10.2實例：圖書借閱系統(tǒng)的功能函數10.3“軟件測試計劃說明書”的書寫格式

10.4靜態(tài)測試

10.5覆蓋測試

10.6黑盒測試方法 10.7“缺陷報告單”的書寫格式

10.8軟件測試過程本章小結

習題

第10章軟件測試10.1軟件測試的定義

1983年，IEEE給出的軟件測試的定義是：軟件測試是使用人工或自動的手段來運行或測定某個軟件系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或弄清預期結果與實際結果之間的差別。這個定義明確指出：軟件測試的目的是為了檢驗軟件系統(tǒng)是否滿足軟件需求。這里強調了軟件需求的重要性，因此軟件需求是軟件測試人員判斷軟件是否有缺陷的依據，就像法官判斷案件嫌疑人是否犯法所依據的法律一樣。10.2案例：圖書借閱系統(tǒng)的功能函數

1.圖書借閱系統(tǒng)功能分解通過分析，系統(tǒng)具有如下功能：①圖書卡的注冊、注銷和信息查詢；②圖書借閱；③圖書信息的查閱：按照作者姓名查閱、按照書名查閱；④圖書返還。圖書借閱系統(tǒng)的模塊設計如圖10-1所示。圖10-1圖書借閱系統(tǒng)的模塊

2.函數關系從圖10-1可以看出，本系統(tǒng)可以劃分為如下函數：

Return_book()：還書函數；

findbook_bname()：按書名查找圖書函數；

findbook_bauthor()：按作者名查找圖書函數；

lend_book()：借書函數；

cardreg()：卡注冊函數；

cardunreg()：卡注銷函數；

cardreginfo()：卡的注冊信息查詢函數；

card_op()：卡的操作與管理函數。其中，card_op()函數調用三個函數：cardreg()、cardunreg()、cardreginfo()。函數調用關系如圖10-2所示。10.3“軟件測試計劃說明書”的書寫格式“軟件測試計劃說明書”的書寫格式如下：

1引言

(1)測試背景這部分簡要地闡述文檔所說明的系統(tǒng)和軟件的目的。這部分將大概描述系統(tǒng)背景、軟件的本質；確定這個方案的發(fā)起人、受益人、使用者、開發(fā)者和維護機構；確定當前的狀況并計劃操作地點。

(2)測試目標

·確定現有項目的信息和應測試的軟件配置；

·列出測試需求；

·推薦可采用的測試策略，并對這些策略加以說明，確定測試達到的標準；

·確定所需的測試資源，并對測試的工作量進行估計。

2測試范圍列出軟件需要進行的測試工作范圍和不需要進行的測試工作范圍；對于不實施某種測試，應該陳述具體的理由。例如，“將不實施安裝測試，該項目將不提供安裝版本”。

3測試的策略與方法測試人員采用的測試方法，如回歸測試、功能測試、自動測試等。

4測試通過/不通過的標準測試是否通過的界定標準以及沒有通過時的處理方法。

5停測標準給出每個測試階段停止測試的標準。

6測試環(huán)境測試所需的硬件支持和軟件環(huán)境等。

7測試人力資源分配列出測試所需人力資源以及軟件測試人員的培訓計劃。

8測試進度安排制定每一個階段的詳細測試進度安排表。

9風險估計和危機處理估計測試過程中潛在的風險以及面臨危機時的解決辦法。

10制定應交付的測試工作產品指明應交付的文檔、測試代碼和測試工具，一般包括下列文檔：測試計劃、測試方案、測試用例、測試日志、測試總結報告、測試工具等。10.4靜態(tài)測試軟件測試方法分白盒測試和黑盒測試；從計算機運行狀態(tài)分為動態(tài)測試和靜態(tài)測試。動態(tài)測試通過運行被測程序，輸入有效的測試用例，驗證功能是否達到軟件需求從而找出程序缺陷。靜態(tài)測試時計算機并不真正運行被測試的程序，它只對被測程序的數據流和控制流等信息進行分析，找出系統(tǒng)的缺陷，做出測試報告，因此靜態(tài)測試又稱為“靜態(tài)分析”。靜態(tài)測試的目的是檢查代碼與設計的一致性、代碼的可讀性、代碼和算法的正確性、代碼結構的合理性等。例如：

(1)檢查程序風格的一致性、規(guī)范性；

(2)檢查算法的邏輯正確性，確定算法是否為最佳算法并實現了所要求的功能；

(3)檢查模塊接口的正確性，形參的個數、數據類型、順序是否正確，確定返回值類型及返回值的正確性；

(4)檢查程序輸入參數的合法性；

(5)檢查程序有無適當的異常處理模塊；

(6)檢查程序常量或全局變量、表達式、語句是否正確，是否含有二義性；

(7)檢查程序代碼是否可以優(yōu)化。10.5覆蓋測試白盒測試也稱做結構測試或邏輯驅動測試，它的目的是了解和檢測產品的內部工作過程，在測試手段上使用的是覆蓋測試方法，可以分為如下六種覆蓋測試方法：語句覆蓋、判斷覆蓋、條件覆蓋、判斷/條件覆蓋、條件組合覆蓋和路徑覆蓋。這里給出了測試用例的格式，如表10-1所示。表10-1測試用例的格式在此，對表中一些項目做以說明：編號—根據項目進行編號，如：test1，test2，…，這里用的是T1，T2，…；執(zhí)行結果—執(zhí)行本測試用例所需的每一步操作。預期輸出—描述被測項目或被測特性所希望或要求達到的輸出或指標。這里還需要指出，測試用例的撰寫人和執(zhí)行測試的人不一定是同一個人。

1.利用語句覆蓋方法設計測試用例語句覆蓋是指設計若干個測試用例，使得被測試程序中的每條可執(zhí)行語句至少被執(zhí)行一次。在保證完成要求的情況下，測試用例的數目越少越好。

1)任務描述下面是一段簡單的C語言程序，請使用語句覆蓋方法完成測試用例的設計任務。inttesting(intx,inty){intpolo888=0;if(x>0&&y>0){polo888=x+y-10; //語句塊1}else{polo888=x+y+10; //語句塊2}

if(polo888<0){polo888=0;

//語句塊3}returnpolo888;

//語句塊4}

2)方法步驟做白盒測試時，一般不直接根據源代碼設計測試用例和編寫測試代碼，通常是根據流程圖來設計測試用例和編寫測試代碼，本任務的程序流程圖如圖10-3所示。圖10-3程序流程圖在圖10-3中共有兩個選擇分支，要從“開始”到“結束”覆蓋各語句必須覆蓋“語句塊1”、“語句塊2”、“語句塊3”、“語句塊4”。所以表10-2給出了語句覆蓋的測試用例。本任務的測試用例如表10-2所示。表10-2語句覆蓋測試用例這樣，通過兩個測試用例即達到了語句覆蓋的要求，當然，測試用例(測試用例組)并不是唯一的。用例T1：達到了覆蓋“語句塊1”和“語句塊4”的目的；用例T2：達到了覆蓋“語句塊2”和“語句塊3”的目的；因此本用例達到了語句覆蓋的目的。

3)任務總結測試的充分性分析：假設第一個判斷語句if(x>0&&y>0)中的“&&”被程序員錯誤地寫成了“||”，即if(x>0||y>0)，使用上面設計出來的一組測試用例來進行測試，仍然可以達到100%的語句覆蓋，所以語句覆蓋不能完全發(fā)現上述的邏輯錯誤。

2.利用判定(分支)覆蓋方法設計測試用例

1)任務描述任務描述同1。任務：利用判定覆蓋方法設計測試用例。

2)方法步驟判定覆蓋測試是設計若干測試用例，使得程序中的每個判定結果至少都獲得一次“真”值和“假”值。也就是說，程序中的每個取“真”、“假”的分支至少經歷一次。該方法也叫“分支覆蓋”測試方法。在本例中共有兩個判斷if(x>0&&y>0)(記為P1)和if(polo888<0)(記為P2)。測試用例如表10-3所示。表10-3判定覆蓋測試用例

3)任務總結在上述的測試用例中，兩個判斷P1和P2取“真”、“假”值的每個分支都被執(zhí)行了一遍，所以滿足了判斷覆蓋的標準。假設第一個判斷語句if(x>0&&y>0)中的“&&”被程序員錯誤地寫成了“||”，即if(x>0||y>0)，使用上面設計出來的一組測試用例來進行測試，仍然可以達到100%的判定覆蓋，所以判定覆蓋也不能完全發(fā)現上述的邏輯錯誤。由于可執(zhí)行語句不在判定的真分支上就在假分支上，所以，滿足了判定覆蓋要求就一定滿足語句覆蓋要求，反之則不然。因此，判定覆蓋比語句覆蓋強。

3.利用條件覆蓋方法設計測試用例

1)任務描述任務描述同1。任務：利用條件覆蓋方法設計測試用例。

2)方法步驟條件覆蓋方法是設計一組測試用例使程序中的每個條件都取真值和假值各取至少一次。在本例中分析的條件有三個：

x>0(記為C1)、y>0(記為C2)和polo888<0(記為C3)，但polo888<0是由x、y取值決定的，x，y取值全覆蓋就把polo888的真、假值各取一遍了。3)測試用例條件覆蓋測試用例如表10-4所示。表10-4條件覆蓋測試用例

4)任務總結上面的測試用例同時也到達了100%判定覆蓋的要求，但并不能保證達到100%條件覆蓋要求的測試用例(組)都能到達100%的判定覆蓋要求。既然條件覆蓋不能100%達到判定覆蓋的要求，也就不一定能夠達到100%的語句覆蓋要求了。4.利用判定與條件覆蓋測試方法設計測試用例

1)任務描述任務描述同1。任務：利用判定與條件覆蓋方法設計測試用例。

2)方法步驟判定與條件覆蓋是指執(zhí)行被測試程序時，程序中每個判斷條件的真、假值分支至少被執(zhí)行一遍，并且每個判斷條件的內部判斷式的真假值分支也要被執(zhí)行一遍。即同時滿足100%判定覆蓋和100%條件覆蓋的要求。本例中的判斷為“x>0&&y>0”，內部判斷式為：x>0和y>0。判定與條件覆蓋測試用例如表10-5所示。表10-5判定與條件覆蓋測試用例

3)任務總結達到100%判定與條件覆蓋要求就一定能夠達到100%條件覆蓋、100%判定覆蓋和100%語句覆蓋的要求。

5.利用條件組合覆蓋方法設計測試用例

1)任務描述任務描述同1。任務：利用條件組合覆蓋方法設計測試用例。

2)方法步驟條件組合覆蓋是指設計若干個測試用例，執(zhí)行被測試程序時，程序中每個判斷條件的內部判斷式的各種真假組合都至少被執(zhí)行一遍?？梢?，滿足條件組合覆蓋的測試用例組一定滿足判定覆蓋、條件覆蓋、判定與條件覆蓋。注意：

(1)條件組合只針對同一個判斷語句內存在多個條件的情況，使得所有條件的各種可能的值至少出現一次。

(2)不同的判斷語句內的條件取值之間無需組合。

(3)對于單條件的判斷語句，只需要滿足自己的所有取值即可。測試用例如表10-6所示。表10-6條件組合覆蓋測試用例

3)任務總結

100%滿足條件組合要求一定滿足100%條件覆蓋要求和100%判定覆蓋要求。上面的測試用例中，經歷了兩條路徑a—c—e—f和a—b—d—f，而被測試程序存在三條路徑。所以這種測試方法不一定能覆蓋程序的全部路徑。

6.利用路徑覆蓋方法設計測試用例

1)任務描述任務描述同1。任務：利用路徑覆蓋方法設計測試用例。

2)方法步驟路徑測試著眼于路徑分析，完成路徑測試的理想情況是做到了路徑覆蓋。路徑覆蓋也是白盒測試最為典型的測試方法。路徑覆蓋要求設計若干測試用例，執(zhí)行被測試程序時，能夠覆蓋程序中所有可能的路徑。本任務有四條路徑：a—b—d—f，a—c—d—f，a—b—e—f，a—c—e—f。路徑覆蓋測試用例應該能夠覆蓋這四條路徑。測試用例如表10-7所示。表10-7路徑覆蓋測試用例

3)任務總結由上表可見，100%滿足路徑覆蓋，并不一定能100%滿足條件覆蓋(C2只取到了真)，但一定能100%滿足判定覆蓋(因為路徑經歷的就是某判斷的分支)。上述六種邏輯覆蓋從弱到強的排列順序是：語句覆蓋→判定覆蓋→條件覆蓋→判定與條件覆蓋→條件組合覆蓋→路徑覆蓋。它們之間的關系可用圖10-4表示(路徑覆蓋很難在該圖表示出來)。圖10-4覆蓋測試方法關系圖我們應該清楚，沒有一個測試方法能夠找出軟件的所有缺陷。即便對程序做到了路徑覆蓋測試，也不能保證源代碼就不存在其他問題。因此我們要善于應用多種測試方法對程序進行測試。10.6黑盒測試方法黑盒測試方法是在已知軟件產品功能設計的情況下，對其進行測試以確認其是否實現了的軟件產品的功能要求。該方法把被測程序視作黑盒，不考慮程序內部的邏輯結構和內部特性，只依據軟件的需求規(guī)格說明，輸入相應的數據，檢查程序的輸出是否符合它的功能要求。使用黑盒測試主要是為了發(fā)現以下錯誤：

(1)是否有不正確的功能；

(2)是否有遺漏的功能；

(3)在接口上，是否能夠正確地接收輸入數據并產生正確的輸出結果；

(4)是否有數據結構錯誤或外部信息訪問錯誤；

(5)性能上是否能夠滿足要求；

(6)是否有程序初始化和終止方面的錯誤。黑盒測試有以下顯著特點：

(1)黑盒測試不考慮軟件的具體實現，當軟件內部實現發(fā)生變化時，測試用例仍然可以使用。

(2)黑盒測試用例的設計可以和軟件實現同時進行，這樣能夠壓縮總的開發(fā)時間。

(3)對一些外購軟件、參數化軟件包以及某些自動生成的軟件，由于無法得到源程序，只能選擇黑盒測試對其進行測試。黑盒測試的優(yōu)點如下：

(1)適用于各個測試階段；

(2)從產品功能角度進行測試；

(3)容易生成測試數據。黑盒測試的缺點如下：

(1)某些代碼得不到測試；

(2)無法發(fā)現軟件需求說明書本身的錯誤；

(3)不易進行充分性測試。實現黑盒測試的內容常用的測試方法包括等價類劃分法和邊界值分析法。

1.利用等價類劃分法設計測試用例

1)任務描述在C語言中有這樣的規(guī)定：“變量標識符由字母、數字和下劃線組成，并且首字符只能是字母和下劃線，標識符的有效字符個數是8個，最大字符數是80個”。請利用等價類劃分方法設計測試用例。

2)方法步驟等價類劃分法是把全部的輸入數據劃分成若干的等價類，在每一個等價類中取一個數據來進行測試，這樣就等價于把該等價類中全部數據取出進行了測試，就能以較少的具有代表性的數據進行測試，從而取得很好的測試效果。等價類又分為有效等價類和無效等價類兩類。有效等價類指對于程序的需求說明而言合理的、有意義的輸入數據所構成的子集合；利用它可以檢驗程序是否實現了預期的功能和性能。無效等價類指對于程序的需求說明而言不合理的、沒有意義的輸入數據所構成的集合；利用它可以檢驗程序是否實現了異常處理功能。使用等價類劃分法設計測試用例，首先必須在分析需求規(guī)格說明的基礎上劃分等價類，然后列出等價類表，其格式如表10-8所示。對于本任務，等價類表如表10-9所示。表10-8等價類表格式表10-9標識符定義的等價類表

對于本任務，用等價類劃分方法設計的測試用例見表10-10所示。表10-10標識符定義測試用例

3)任務總結一般情況下，劃分等價類的方法如下：

(1)如果輸入條件規(guī)定了數據的范圍和取值個數，可以確定一個有效等價類和兩個無效等價類。例如：100<X<999，有效等價類為(100，999)，無效等價類為“小于100”和“大于999”。

(2)如果輸入條件規(guī)定了一個必須成立的情況(如輸入數據必須是某個日期)，可以劃分為一個有效等價類“輸入某個日期格式字符串”和一個無效等價類“輸入非日期格式字符串”。

(3)如果輸入條件是一個布爾量，則可以確立一個有效等價類和一個無效等價類。

4)課堂練習對下面程序描述用等價類劃分方法設計測試用例。

(1)三角形組成問題。輸入三個數，分別作為三角形的三條邊(要求都是整數，取值范圍在1～100之間)。判斷是否能組成三角形，請給出測試用例。(提示：利用三角形組成的條件。)

(2)平方根函數。要求當輸入值大于等于0時，返回輸入數的平方根；當輸入值小于0時，顯示錯誤信息“平方根錯誤，輸入值小于0”，并返回0。請設計測試此函數的設計用例。

2.利用邊界值分析方法設計測試用例

1)任務描述下面是圖書信息查詢系統(tǒng)(前面給出過軟件需求和函數結構)的圖書卡注冊信息瀏覽函數cardreginfo()結構。

{

FILE*fp;

inti,n=0;

fp=fopen("car.txt","r"); //打開卡信息文件

for(i=0;fread(&car[i],sizeof(structcard),1,fp)!=0;i++)

{

printf("第%d張卡<卡號：%d姓名：%s班級：

%d>\n",i+1,card[i].carnum,card[i].studentname,card[i].studentclass);

n=n+1;

}

fclose(fp);

printf("目前共有%d本書\n",n);

printf("按任意鍵\n");

getch();

}其中，card.txt文件存放有學生信息：卡號、姓名、班級。請利用邊界值分析方法設計測試用例。

2)方法步驟邊界值分析法是一種補充等價類劃分法的測試用例設計技術，它不是選擇等價類的任意元素，而是選擇等價類邊界的測試用例。常見的邊界值有：

(1)對16bit的整型數而言，-32767和32768是邊界；

(2)屏幕上光標的最左上角和最右下角位置；

(3)報表的第一行和最后一行；

(4)數組元素的第一個和最后一個元素；

(5)循環(huán)的第0次、第1次和倒數第2次、最后一次。對于本測試模塊cardreginfo()中循環(huán)語句：

for(i=0;fread(&card[i],sizeof(structcard),1,fp)!=0;i++)可以設置邊界如下：

(1)?i=-1，0；

(2)?i作為一個int整型變量，取邊界值-32768，-32769，32767，32768。表10-11給出了本任務的邊界值分析測試用例。表10-11邊界值分析測試用例

3)任務總結根據長期的測試工作實踐可知，大量的錯誤發(fā)生在輸入或輸出的邊界上。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。利用邊界值分析法進行用例設計時應該注意：

(1)如果對輸入條件范圍進行了界定，則以邊界內部以及恰巧超出范圍邊界的值作為測試用例。

(2)應當選取正好等于、剛剛大于或剛剛小于邊界的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據。

(3)在軟件需求說明中，對于輸出條件也可以用上面的兩個原則進行測試用例的設計。

(4)如果在軟件需求說明中描述的輸入或者輸出是一個有序集合(如：順序文件、表格等)，那么就選擇集合中的第一個和最后一個元素作為測試用例。

(5)如果程序使用了一個內部數據結構，應該選取這個內部數據結構的邊界值作為測試用例。

(6)分析軟件需求說明，找出其他可能的邊界條件。10.7“缺陷報告單”的書寫格式對測試過程中的每個缺陷都應該填寫一份缺陷報告單，如表10-12所示。表10-12缺?陷?報?告?單表格中有關項目的說明：

(1)嚴重程度。致命性錯誤：數據丟失，數據計算錯誤、系統(tǒng)崩潰和死機；嚴重功能性錯誤：規(guī)定的功能沒有實現或不完整、設計不合理造成性能低下，影響系統(tǒng)的運行；警告性錯誤：不影響系統(tǒng)運行的功能問題，例如，某變量定義之后在本程序中沒有用到過。建議性錯誤：如代碼規(guī)范等問題。

(2)重現幾率分為四個等級：小于等于30%、大于30%小于60%、大于60%小于80%，大于80%小于等于100%(這個規(guī)定可以根據實際項目確定)；

(3)優(yōu)先級別(指優(yōu)先安排修正該缺陷的緊迫程度)分為三個級別：高、中、低；

(4)處理結果分為兩種：已經解決、尚未解決；

(5)修改方式分為四種：修改相關代碼、刪除相關功能模塊、改變設計、不做修改。10.8軟件測試過程軟件測試過程按測試階段的先后順序大致可分為單元測試、集成測試、系統(tǒng)測試三個階段。在開發(fā)期間對模塊進行單元測試，在相關聯的模塊都通過單元測試后，合并(成為一個大模塊后)進行集成測試，在各個“大模塊”測試完成后，進行整個系統(tǒng)的測試。

1.單元測試單元測試是對軟件基本組成單元進行的測試。單元測試的對象是軟件設計的最小單位—模塊。例如“圖書借閱系統(tǒng)”中有下面單元：

Return_book()：還書函數； findbook_bname()：按書名查找圖書函數；

lend_book()：借書函數； findbook_bauthor()：按作者名查找圖書函數；

cardreg()：卡注冊函數； cardunreg()：卡注銷函數；

cardreginfo()：卡的注冊信息查詢函數；

card_op()：卡的操作與管理函數。這里的每個函數是一個單元模塊。單元測試的主要內容是模塊接口測試。模塊接口測試中的被測模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯系，用一些輔助模塊去模擬與被測模塊相關聯的模塊。這些輔助模塊可分為兩種：

(1)驅動模塊：相當于被測模塊的主程序。它接收測試數據，把這些數據傳送給被測模塊，最后輸出實測結果。例如，模塊A要調用模塊B，在測試模塊B時，要編寫一個驅動模塊(模擬模塊A對B的調用功能)來調用模塊B，檢查模塊B是否存在缺陷。

(2)樁模塊：用以代替被測模塊調用的子模塊。樁模塊可以做少量的數據操作，不需要把子模塊所有功能都帶進來，但不允許什么事情也不做。例如，模塊A要調用模塊B，現在測試模塊A時，要編寫一個樁模塊(代替模塊B的功能)被模塊A調用，(假設模塊B是正確的)檢查模塊A是否存在缺陷。被測模塊、與它相關的驅動模塊以及樁模塊共同構成了一個“測試環(huán)境”，如圖10-5所示。在單元測試過程中對于每個單元測試完畢都要填寫表10-12所示的《缺陷報告》。圖10-5被測模塊、驅動模塊以及樁模塊

2.集成測試集成測試的方式有以下兩種。

1)非增值式集成測試非增值式集成測試的方法是：先分別測試每個模塊，然后再把所有模塊按設計要求放在一起結合成所需要實現的程序而進行測試。圖10-6所示的是整個程序模塊結構，共包含9個模塊。圖10-6整個程序模塊結構具體測試計劃如下：

(1)對模塊<按照書名查詢>進行單元測試。為<按照書名查詢>設計驅動模塊Driver1，來模擬<系統(tǒng)主函數>模塊對<按照書名查詢>的調用。如圖10-7所示。圖10-7對模塊<按照書名查詢>進行單元測試

(2)對模塊<按照作者名字查詢>進行單元測試。為<按照作者名字查詢>設計驅動模塊Driver2，來模擬<系統(tǒng)主函數>模塊對<按照作者名字查詢>的調用。如圖10-8所示。圖10-8對模塊<按照作者名字查詢>進行單元測試

(3)對模塊<圖書返還>進行單元測試。為<圖書返還>設計驅動模塊Driver3，來模擬<系統(tǒng)主函數>模塊對<圖書返還>的調用。如圖10-9所示。圖10-9對模塊<圖書返還>進行單元測試

(4)對模塊<圖書卡的操作與管理>進行單元測試。為<圖書卡的操作與管理>設計驅動模塊Driver4，來模擬<系統(tǒng)主函數>模塊對<圖書卡的操作與管理>的調用。為模塊<圖書卡的操作與管理>設計樁模塊Stub1，來模擬模塊<卡的注冊信息查詢>被<圖書卡的操作與管理>的調用。如圖10-10所示。圖10-10對模塊<圖書卡的操作與管理函數>進行單元測試

(5)對模塊<卡的借閱信息瀏覽>、<卡的注冊信息查詢>、<圖書卡的注銷>、<圖書卡的注冊>進行單元測試。為<卡的借閱信息瀏覽>、<卡的注冊信息查詢>、<圖書卡的注銷>、<圖書卡的注冊>分別設計驅動模塊Driver5、Driver6、Driver7、Driver8來模擬<圖書卡的操作與管理>模塊對它們的分別調用。如圖10-11所示。圖10-11對模塊<卡的借閱信息瀏覽>、<卡的注冊信息查詢>、<圖書卡的注銷>、<圖書卡的注冊>進行單元測試

(6)對模塊<圖書借閱>進行單元測試。為<圖書借閱>設計驅動模塊Driver9，來模擬<系統(tǒng)主函數>模塊對<圖書借閱>的調用。如圖10-12所示。圖10-12對模塊<圖書借閱>進行單元測試

(7)對主模塊<系統(tǒng)主函數>進行單元測試。為主模塊<系統(tǒng)主函數>設計五個樁模塊Stub2、Stub3、Stub4、Stub5、Stub6分別模擬<按照書名查詢>、<按照作者名字查詢>、<圖書返還>、<圖書卡的操作與管理>、<圖書借閱>模塊被主模塊的調用。如圖10-13所示。

(8)把所有模塊按設計要求放在一起結合成所需要實現的程序而進行系統(tǒng)測試圖10-13對主模塊<系統(tǒng)主函數>進行單元測試

2)增值式集成測試方式增值式集成測試方式有以下三種。

(1)自頂向下增值測試方式。自頂向下增值測試方式的方法是：主控模塊作為驅動模塊，所有與主控模塊直接相連的模塊(記為X)作為被測模塊；根據集成的方式(深度或廣度)，每次把從屬于X的一個樁模塊替換成真正的模塊Y及Y的樁模塊(如果Y有樁模塊)，依此不斷集成下去，直到全部模塊被集成為止。在每個模塊被集成時，都必須已經通過了單元測試；進行回歸測試以確定集成新模塊后沒有引入錯誤。這種組裝方式將模塊按系統(tǒng)程序結構，沿著控制層次自頂向下進行組裝。自頂向下的增值方式在測試過程中較早地驗證了主要的控制和判斷點。選用按深度方向組裝的方式，可以首先實現和驗證一個軟件的完整功能。圖10-14表示的是按照深度優(yōu)先方式遍歷的自頂向下增值的集成測試實例。圖10-14自頂向下增值測試方式在樹狀結構圖中，按照先左后右的順序確定模塊集成路線：①如圖10-14(a)所示，先對頂層的主模塊A進行單元測試。就是對模塊A配以樁模塊S1、S2和S3，用來模擬它所實際調用的模塊B、C、D，然后進行測試；②如圖10-14(b)所示，用實際模塊B替換掉樁模塊S1，與模塊A連接，再對模塊B配以樁模塊S4，用來模擬模塊B對E的調用，然后進行測試；③圖10-14(c)是將模塊E替換掉樁模塊S4并與模塊B相連，然后進行測試；④判斷模塊E沒有葉子結點，也就是說以A為根結點的樹狀結構圖中的最左側分支深度遍歷結束，轉向下一個分支；⑤如圖10-14(d)所示，模塊C替換掉樁模塊S2，連到模塊A上，然后進行測試；判斷模塊C沒有樁模塊，轉到樹狀結構圖的最后一個分支；⑥如圖10-14(e)所示，模塊D替換掉樁模塊S3，連到模塊A上，同時給模塊D配以樁模塊S5，來模擬其對模塊F的調用，然后進行測試；⑦如圖10-14(f)所示，去掉樁模塊S5，替換成實際模塊F連接到模塊D上，然后進行測試；⑧對樹狀結構圖進行了完全測試，測試結束。

(2)自底向上增值測試方式。自底向上增值測試方式與自頂向下增值測試方式正好相反。圖10-15表示的是按照自底向上增值方式集成測試的例子。圖10-15自底向上增值測試方式①首先，對處于樹狀結構圖中葉子結點位置的模塊E、C、F進行單元測試，如圖10-15(a)、圖10-15(b)和圖10-15(c)所示，分別配以驅動模塊D1、D2和D3，用來模擬模塊B、模塊A和模塊D對它們的調用。②然后，如圖10-15(d)和圖10-15(e)所示，去掉驅動模塊D1和D3，替換成模塊B和D分別與模塊E和F相連，并且設立驅動模塊D4和D5進行局部集成測試。最后，如圖10-15(f)所示，對整個系統(tǒng)結構進行集成測試。

(3)混合增值測試方式。自頂向下增值方式和自底向上增值方式各有優(yōu)缺點。通常是把以上兩種方式結合起來進行測試，即混合增值測試方式。

3.系統(tǒng)測試系統(tǒng)測試是將已經集成好的軟件系統(tǒng)與計算機硬件、外設、某些支撐軟件、數據和人員等結合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行一系列的確認測試。

1)常見的系統(tǒng)測試方法常見的系統(tǒng)測試方法有：恢復測試、安全測試、強度測試、性能測試、可靠性測試、兼容性測試?；謴蜏y試是通過各種手段，強制性地讓