《信息系統(tǒng)分析與設計》課件4第6章

第6章系統(tǒng)測試、實施與維護6.1軟件測試

6.2調(diào)試

6.3系統(tǒng)實施6.4系統(tǒng)維護

實驗五習題6.1軟件測試6.1.1測試的基本概念軟件測試是對軟件計劃、軟件設計、軟件編碼進行查錯和糾錯的活動。測試的目的是為了找出軟件開發(fā)過程中各個階段的錯誤，以便分析錯誤的性質(zhì)和確定錯誤的位置，并糾正錯誤。軟件測試伴隨著程序設計的出現(xiàn)而出現(xiàn)，隨著軟件技術(shù)的發(fā)展，人們對軟件測試的認識也在不斷加深。通常人們認為“軟件測試是為了證明軟件是正確的”。實際上這種認識是錯誤的。1983年，IEEE提出的軟件工程標準術(shù)語中軟件測試的定義是：“使用人工或自動手段來運行或測定某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求，或弄清預期結(jié)果與實際結(jié)果之間的差別”。G.J.Myers則認為“程序測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程”。上面的兩種定義有不同的強調(diào)方面，關(guān)于軟件測試的概念，我們要注意以下兩點：

(1)軟件測試是為了發(fā)現(xiàn)程序中的錯誤而不是證明程序的正確性。按照Myers的觀點，“成功的測試是發(fā)現(xiàn)了至今尚未發(fā)現(xiàn)的錯誤的測試”。當然測試的目的不僅僅是發(fā)現(xiàn)錯誤，還包含檢驗、評價等。

(2)軟件測試方法不僅僅是執(zhí)行程序，也包括人工方法。事實上，人工測試在某些測試階段可以發(fā)現(xiàn)大部分的錯誤。6.1.2測試的基本原則要高質(zhì)量地完成測試工作，找出軟件中的錯誤，應該遵守下面的一些基本原則：

(1)測試隊伍與開發(fā)隊伍應分別建立。開發(fā)和測試工作兩者在思想和方法上都是不一樣的，為了保證測試的質(zhì)量，應分別建立開發(fā)和測試隊伍。開發(fā)工作是建設性的，而在測試階段，人們設計出一系列的輸入數(shù)據(jù)(稱為測試用例)，目的是為了“破壞”已經(jīng)建造好的軟件。就像給硬件產(chǎn)品做高低溫試驗、震動試驗、破壞性試驗一樣。而且一般程序編寫者往往認為自己編寫的程序是正確的，要他們找出自己程序中的錯誤是十分困難的。

(2)設計測試用例時，要給出測試的預期結(jié)果。一個測試用例應由兩部分組成：①對程序進行測試的一組輸入數(shù)據(jù)的描述；②由這一組輸入數(shù)據(jù)所產(chǎn)生的程序的預期輸出結(jié)果的描述。預期輸出結(jié)果不一定是精確的輸出結(jié)果，對于一些復雜的計算，人工計算結(jié)果可能需要很大的工作量，可以給出一個對輸出結(jié)果有效范圍的描述。

(3)設計測試用例時，應包括對有效的和期望的輸入條件的測試，也應包括對無效的和非期望的輸入條件的測試。一個程序不僅當輸入合法時能正確運行，而且當有非法輸入時，應該能夠拒絕這些非法輸入，并給出適當?shù)奶崾拘畔ⅰ?/p>

(4)在程序修改之后，要進行回歸測試。對程序的任何修改都有可能引入新的錯誤，所以必須進行回歸測試，即將以前的所有測試用例再次輸入測試，而不是僅僅測試以前結(jié)果不正確的測試用例?；貧w測試有助于發(fā)現(xiàn)由于修改程序而引入的新錯誤。

(5)對發(fā)現(xiàn)錯誤較多的程序段，應進行深入的測試。如果發(fā)現(xiàn)某個程序段錯誤較多，則表明這個程序段質(zhì)量很低，有可能隱藏有更多的錯誤，應該進行深入的測試。6.1.3測試方法軟件測試方法有多種，這些測試方法具有不同的思路和出發(fā)點?？偟膩碚f，測試方法可分為靜態(tài)測試方法和動態(tài)測試方法兩大類。所謂靜態(tài)測試方法，是指不在計算機上運行被測試程序，而是采用其他手段達到對程序進行檢測目的的測試方法。靜態(tài)測試方法包括人工測試方法和計算機輔助靜態(tài)分析方法。所謂動態(tài)測試方法，是指在計算機上運行被測試程序，并用所設計的測試用例對程序進行檢測的方法。動態(tài)測試方法根據(jù)設計測試用例的思想不同可分為白盒測試、黑盒測試以及窮舉測試等。下面分別介紹各種測試方法。

1.人工測試方法人工測試方法是指依靠人而不是計算機來對程序進行檢測的方法。人工測試可以找出計算機測試不容易發(fā)現(xiàn)的錯誤，可以減少系統(tǒng)測試的總工作量。根據(jù)統(tǒng)計，人工測試能有效地發(fā)現(xiàn)30%～70%的邏輯設計和編碼錯誤。人工測試可以采用人工運行和代碼審查的方式。代碼審查可以由程序編寫者本人非正式地進行，也可以由審查小組正式進行。代碼審查主要是對照常見程序錯誤清單對程序代碼進行分析審查，并將發(fā)現(xiàn)的錯誤記錄下來。表6.1是由Myers提供的常見程序錯誤清單，該表主要針對FORTRAN一類的程序設計語言所編寫的程序，其他的程序設計語言編寫的程序也可參照該清單。表中的參數(shù)相當于C語言中函數(shù)的形式參數(shù)，而變元相當于C語言中函數(shù)調(diào)用時的實際參數(shù)。表6.1

Myers提供的常見程序錯誤清單一、模塊接口檢查表1.模塊接收的輸入?yún)?shù)個數(shù)與模塊的變元個數(shù)是否一致？2.參數(shù)與變元的屬性是否匹配？3.參數(shù)與變元所用的單位是否一致？4.傳送給被調(diào)用模塊的變元的數(shù)目是否等于那個模塊的參數(shù)的數(shù)目？5.傳送給被調(diào)用模塊的變元屬性和參數(shù)的屬性是否一致？6.傳送給被調(diào)用模塊的變元的單位和參數(shù)的單位是否一致？7.傳送給內(nèi)部函數(shù)的變元屬性、數(shù)目和次序是否正確？8.是否修改了只是作為輸入用的變元？9.全程變量的定義在各個模塊中是否一致？10.有沒有把常數(shù)當作變量來傳送？二、完成外部輸入/輸出時的檢查表1.文件屬性是否正確？2.打開文件語句是否正確？3.格式說明與輸入輸出語句給出的信息是否一致？4.緩沖區(qū)大小與記錄大小是否匹配？5.是否所有文件在使用前都已打開了？6.對文件結(jié)束條件的判斷和處理是否正確？7.對輸入輸出錯誤的處理是否正確？8.輸出信息中有沒有正文錯誤？三、模塊局部數(shù)據(jù)結(jié)構(gòu)的檢查表1.有沒有不正確或不一致的說明？2.有沒有不正確的初始化和缺省值？3.有沒有錯誤的變量名？4.有沒有不相容的數(shù)據(jù)類型？5.有沒有下溢、上溢或地址錯誤？四、計算錯誤檢查表1.對運算優(yōu)先次序的錯誤理解或錯誤處理。2.發(fā)生了混合運算(運算對象的類型不相容)。3.初始化錯誤。4.計算精度不夠。5.表達式的符號表示錯誤。五、比較錯誤的檢查表1.不同數(shù)據(jù)類型的數(shù)據(jù)進行比較。2.邏輯運算符或其優(yōu)先次序用錯。3.本應相等的數(shù)據(jù)，由于精度原因而不相等。4.變量本身有錯或比較有錯。5.循環(huán)終止不正確或循環(huán)不止。6.“差1”錯(多一次或少一次循環(huán))。7.當遇到發(fā)散的迭代不能擺脫出來。8.循環(huán)控制變量修改有錯。六、出錯處理的檢查表1.對錯誤的描述難以理解。2.指明的錯誤并非實際遇到的錯誤。3.出錯后尚未進行錯誤處理，錯誤條件已引起了系統(tǒng)干預。4.對錯誤的處理不正確。5.提供的錯誤信息不足，以致無法找到出錯的原因。人工測試還可以采用軟件審查的方式，它可以用于系統(tǒng)開發(fā)的各個階段，對產(chǎn)品的質(zhì)量進行評審。限于篇幅，本書不再詳細介紹。

2.計算機輔助靜態(tài)分析方法計算機輔助靜態(tài)分析方法是利用計算機測試工具對被測程序的特性進行分析方法的總稱。靜態(tài)分析工具主要有下面幾種形式：

(1)靜態(tài)確認工具：對程序進行靜態(tài)分析和確認，收集一些程序中的信息，以查找程序中的各種缺陷和可疑的程序構(gòu)造。例如，使用了一個尚未賦值的變量，或者賦了值的變量一直沒有使用等。

(2)符號執(zhí)行工具：以符號值作為程序的輸入，使程序符號執(zhí)行，對程序的運算規(guī)律加以檢驗。

(3)程序驗證工具：交互式程序驗證系統(tǒng)是證明程序正確性的一種工具。它通過系統(tǒng)內(nèi)部基于符號的邏輯變換和結(jié)構(gòu)歸納，提取程序的語義和結(jié)構(gòu)的要點來分析證明程序的正確性。

3.黑盒測試黑盒測試又稱功能測試，即不管程序內(nèi)部是如何編制的，只考慮程序輸入和輸出之間的關(guān)系，或只考慮程序的功能。因此，測試者必須根據(jù)軟件的規(guī)格說明書來確定和設計測試用例。黑盒測試也被稱為數(shù)據(jù)驅(qū)動測試或基于規(guī)格說明書的測試。黑盒測試適合于對內(nèi)部結(jié)構(gòu)未知的軟件進行測試，例如對于外購的軟件包，只能根據(jù)軟件包的功能說明書進行測試。另外，用戶對系統(tǒng)的驗收測試也使用黑盒測試方法，因為用戶關(guān)心的是軟件能否實現(xiàn)所需的功能。也可以說，黑盒測試是從用戶觀點進行的測試。

4.白盒測試白盒測試也稱為結(jié)構(gòu)測試，它是根據(jù)被測試程序的邏輯結(jié)構(gòu)設計測試用例。使用白盒測試方法需要了解程序的內(nèi)部結(jié)構(gòu)，對程序的不同邏輯路徑進行測試。由于采用不同方法設計測試用例對程序的邏輯路徑覆蓋的程度不一，因此白盒測試又被稱為基于“覆蓋”的測試。覆蓋率越高，測試越充分。

5.窮舉測試軟件測試的主要目的是查找軟件中存在的錯誤，而不能證明軟件的正確性。實際上采用一般的測試方法根本無法證明軟件的正確性。有人主張通過白盒或黑盒測試方法對所有可能的情況進行測試，如果所有的情況都是正確的，則可證明程序是正確的。這種方法被稱為窮舉測試，實際上除了一些簡單的程序外，它是無法實現(xiàn)的。使用黑盒測試進行窮舉測試，必須窮舉所有可能的輸入數(shù)據(jù)。舉一個簡單的例子，假設輸入三個無符號整數(shù)作為三角形的三條邊長，判斷該三角形是否為直角三角形。C語言中無符號整數(shù)的范圍為0～216?1，如果要窮舉所有的輸入數(shù)據(jù)，則測試用例數(shù)為216*216*216≈3*1014，假定程序每執(zhí)行一次需要1ms，則需要一萬年。白盒測試要實現(xiàn)窮舉測試同樣難以實現(xiàn)，當程序中包含有較復雜的循環(huán)和條件語句嵌套時，可能的執(zhí)行路徑數(shù)目同樣很多，測試用例要覆蓋所有的執(zhí)行路徑是根本不可能的。6.1.4設計測試用例使用白盒測試和黑盒測試都需要設計測試用例，上一節(jié)中已經(jīng)提到要將所有可能的情況窮舉出來是不可能的，因此在設計測試用例時必須依據(jù)一定的原則，以保證既能對程序進行充分的測試，而測試用例的數(shù)目又不能太大。本節(jié)將介紹常用的白盒和黑盒測試用例設計的方法。

1.白盒測試白盒測試根據(jù)模塊設計階段對模塊內(nèi)部邏輯結(jié)構(gòu)的描述設計測試用例。根據(jù)測試用例對模塊所有可能執(zhí)行路徑的覆蓋程度，可將其分為語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋和路徑覆蓋。

1)語句覆蓋語句覆蓋要求所設計的用例使程序中的每一條語句至少執(zhí)行一次，這是覆蓋程度很低的一種覆蓋標準。下面是一個簡單的例子。假設程序的流程圖如圖6.1所示，對應的C語言源程序片段如下：

X=0;

if(A>1||B>2) X=A+B;

printf(“%d”,X);現(xiàn)在按語句覆蓋標準設計測試用例，只需設計一組測試用例使條件“A>1orB>2”成立即可，例如：輸入數(shù)據(jù)：A=2，B=0；輸出數(shù)據(jù)：X=2。圖6.1被測試程序的流程圖這組測試用例雖然覆蓋了所有的語句，但對條件語句的分支測試不充分，只測試了條件為真的分支。如果條件表達式中的第一個條件表達式A>1誤寫為A=1(C語言中該表達式值為真)，則這組測試用例無法檢測該錯誤。同樣，如果條件表達式中的第二個條件表達式B>2寫錯，則這組測試用例也不能檢測出程序的錯誤。

2)判定覆蓋判定覆蓋要求對程序中所有判定的分支都必須能夠執(zhí)行到。對于上面的例子，可設計兩組測試用例。第一組輸入數(shù)據(jù)：A=2，B=0；輸出數(shù)據(jù)：X=2；第二組輸入數(shù)據(jù)：A=1，B=0；輸出數(shù)據(jù)：X=0。這兩組測試用例分別使條件語句中的條件表達式取“真”和“假”，很顯然也是語句覆蓋，但對程序的測試比語句覆蓋更充分。判定覆蓋也是一種較弱的覆蓋，這里的例子對條件表達式中B>2的測試很不充分，沒有測試該表達式為真的情況。

3)條件覆蓋條件覆蓋是指設計的測試用例能使程序中判定的每一個條件的可能取值都滿足一次。對于上面的例子，判定中有兩個條件，每個條件的可能取值為：條件1：A>1 真 記為T1

假(A≤1) 記為F1條件2：B>2 真 記為T2

假(B≤2) 記為F2可以設計兩組測試用例： 第一組輸入數(shù)據(jù)：A=2，B=3；輸出數(shù)據(jù)：X=2； 滿足T1、T2；第二組輸入數(shù)據(jù)：A=1，B=0；輸出數(shù)據(jù)：X=0； 滿足F1、F2。在大部分情況下，條件覆蓋比判定覆蓋強，因為它使判定表達式中每個條件都取得了可能的值，而判定覆蓋只關(guān)心整個判定的取值。讀者可以很容易地看出，這里的兩組測試用例也滿足判定覆蓋的要求。但條件覆蓋并不一定總是滿足判定覆蓋的要求，對上面的例子，我們看下面的兩組測試用例：第一組輸入數(shù)據(jù)：A=2，B=0；輸出數(shù)據(jù)：X=2；滿足T1、F2；第二組輸入數(shù)據(jù)：A=1，B=3；輸出數(shù)據(jù)：X=4；滿足F1、T2。這兩組測試用例雖然滿足條件覆蓋的要求，但它不滿足判定覆蓋的要求。

4)判定/條件覆蓋判定/條件覆蓋是指設計足夠的測試用例，使其既滿足條件覆蓋的要求，又滿足判定覆蓋的要求。要求判定中每一個條件所有的取值都能滿足一次，而且保證判定的每個分支都能執(zhí)行到一次。很顯然，判定/條件覆蓋比前面的幾種覆蓋標準更強。判定/條件覆蓋仍然有一定的不足，表面看起來它測試了所有條件的所有可能取值，但實際上往往有某些條件掩蓋了另一些條件。假設判定由兩個條件構(gòu)成，例如“xandy”，如果x取值為“假”，則不管此時y的取值為“真”還是為“假”，整個判定的值均為“假”。

5)條件組合覆蓋條件組合覆蓋是指設計足夠的測試用例，使得判定中各種條件可能的取值組合都能滿足一次。對上面例子中的程序，判定中共有兩個條件表達式，每個條件都有兩種取值，因此共有四種取值組合，它們是：

(1)A>1,B>2；

(2)A>1,B≤2；

(3)A≤1,B>2；

(4)A≤1,B≤2。請讀者自行設計四組輸入數(shù)據(jù)分別滿足不同的取值組合，本書不再贅述。很顯然，條件組合覆蓋的測試用例必定滿足判定/條件覆蓋、條件覆蓋和判定覆蓋的要求。

6)路徑覆蓋路徑覆蓋是指設計足夠的測試用例，使其覆蓋程序中所有可能的路徑。前面在介紹窮舉測試時，我們提到對于一些含有復雜條件和循環(huán)嵌套的程序，其可能路徑的數(shù)目很大，路徑覆蓋是無法實現(xiàn)的。對于一些簡單的程序，路徑覆蓋還是可以實現(xiàn)的，我們看圖6.2所示的程序流程示意圖。圖6.2被測程序的流程圖該流程圖中共有兩個判定，程序執(zhí)行的所有可能的路徑共有4種：sace、sade、sbce和sbde。對于一些含有循環(huán)及條件嵌套的程序，由于其可能的執(zhí)行路徑數(shù)目巨大，要實行真正的路徑覆蓋是不可能的。對于這樣一些程序，可以采取一些方法來簡化測試用例的設計，例如通常可以將循環(huán)簡化為進入循環(huán)和不進入循環(huán)的分支操作，則執(zhí)行路徑的數(shù)目將大大減少。

2.黑盒測試黑盒測試是根據(jù)功能說明書進行的測試，測試者只知道程序的輸入和輸出之間的關(guān)系或程序的功能。測試者必須仔細地研究程序的功能說明，找出程序的功能信息或輸入和輸出之間的關(guān)系，然后設計測試用例并推斷測試結(jié)果的正確性。常用的黑盒測試方法有等價類劃分、邊界值分析等。

1)等價類劃分等價類劃分是黑盒測試常用的一種方法。它的基本思想是：將所有可能的輸入情況劃分為若干個等價類，然后為每一個等價類設計一個測試用例，如果這個測試用例程序的輸出結(jié)果是正確的，則認為對該類的所有數(shù)據(jù)該程序都能得到正確的輸出結(jié)果。等價類劃分方法測試的質(zhì)量取決于等價類劃分是否合理，這往往依賴于測試人員的經(jīng)驗。下面是等價類劃分經(jīng)常采用的一些規(guī)則：

(1)如果規(guī)定了輸入值的范圍或值的個數(shù)，則取一個有效等價類、兩個無效等價類。例如，功能說明書規(guī)定“項數(shù)為1～10”，則取一個有效等價類“項數(shù)在1～10之間”，兩個無效等價類“項數(shù)<1”和“項數(shù)>10”。

(2)如果輸入項規(guī)定了值的集合，則取一個有效等價類和一個無效等價類。例如規(guī)定電話號碼“以數(shù)字開頭”，則取一個有效等價類“以數(shù)字開頭”，一個無效等價類“以字母或其他字符開頭”。

(3)如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序?qū)Σ煌斎胫颠M行不同處理，則每個允許的輸入值分別是一個有效等價類，此外還有一個無效等價類。

(4)如果規(guī)定了輸入數(shù)據(jù)的規(guī)則，則取符合規(guī)則的一個有效等價類和若干不符合規(guī)則的無效等價類。

(5)如果規(guī)定了輸入數(shù)據(jù)是整形，則可以劃分出負整數(shù)、零、正整數(shù)三個等價類。以上只是一些可供參考的規(guī)則，實際工作中應仔細分析程序輸入數(shù)據(jù)的要求，劃分出有代表性的有效等價類和無效等價類。在確定輸入數(shù)據(jù)的等價類時，常常還需要分析輸出數(shù)據(jù)的等價類，以便根據(jù)輸出數(shù)據(jù)等價類導出輸入數(shù)據(jù)的等價類。例如，輸入三角形的三條邊長，判斷三角形是普通三角形、等腰三角形還是等邊三角形，在設計等價類時顯然應根據(jù)輸出結(jié)果進行等價類的劃分。在劃分有效等價類之后，按照等價類設計測試用例時應該注意：

(1)設計一個測試用例，使其覆蓋盡可能多的尚未覆蓋的有效等價類。

(2)設計一個測試用例，使其只覆蓋一個無效等價類。之所以如此要求，是因為經(jīng)驗表明，程序員往往更注意有效輸入，而忽視對無效輸入數(shù)據(jù)的處理。現(xiàn)在來看一個簡單的例子。假設程序要求輸入某城市的電話號碼，電話號碼由三個部分構(gòu)成。這三個部分的名稱與內(nèi)容分別是：地區(qū)碼：空白或三位數(shù)字；前綴：非“0”或“1”開頭的三位數(shù)字；后綴：四位數(shù)字。假定被測試的程序接收符合上述規(guī)則的所有號碼，拒絕所有不符合規(guī)則的號碼?，F(xiàn)在使用等價類劃分法來對其進行測試。第一步，劃分等價類。劃分的等價類以表格形式(表6.2)給出，并給每個等價類一個惟一的編號。表6.2電話號碼的等價類劃分輸入條件有效等價類無效等價類地區(qū)碼空白(1)，3位數(shù)字(2)有非數(shù)字字符(5)，少于3位數(shù)字(6)，多于3位數(shù)字(7)前綴從200到999之間的數(shù)字(3)有非數(shù)字字符(8)，起始位為‘0’(9)，起始位為“1”(10)位數(shù)字(11)，多于3位數(shù)字(12)后綴4位數(shù)字(4)有非數(shù)字字符(13)，少于4位數(shù)字(14)，多于4位數(shù)字(15)第二步，確定測試用例。表中有四個有效等價類，可使用下面兩個測試用例：測試數(shù)據(jù)測試范圍 期望結(jié)果()276-2345等價類(1)(3)(4) 有效(635)805-9321等價類(2)(3)(4) 有效對于11個無效等價類，應選擇11個測試用例。限于篇幅，這里不再一一給出。

2)邊界值分析法在等價類劃分法中，代表一個等價類的測試數(shù)據(jù)可以在這個類的允許值范圍內(nèi)任意選擇。假設輸入數(shù)據(jù)x的有效范圍為[1.0，10.0]，則設計測試用例時，有效等價類的輸入數(shù)據(jù)可為1～10之間的任意數(shù)據(jù)，例如2.0。如果程序員將x>=1.0錯寫為x>1.0，則所選定的測試用例將不能檢測到這類錯誤。如果選擇有效范圍的邊界上的測試用例，則對這類錯誤的測試效果將很好，這就是邊界值分析的基本思想。各種資料和經(jīng)驗也表明，程序員在程序設計過程中往往對輸入輸出數(shù)據(jù)有效范圍的邊界不夠重視，在處理邊界情況時，程序最容易發(fā)生錯誤。使用邊界值分析方法設計測試用例，暴露程序錯誤的可能性將更大。在對邊界值進行分析，進行測試用例設計時，可參考下面的一些規(guī)則：

(1)如果輸入條件規(guī)定了取值范圍，則應對該范圍的邊界內(nèi)附近、恰好在邊界上和邊界外附近設計測試用例。例如，規(guī)定輸入值的有效范圍為[1.0，10.0]，則應對0.9、1.0、1.1、9.9、10.0、10.1設計測試用例。

(2)如果輸入條件規(guī)定了數(shù)據(jù)的個數(shù)，則應對最小個數(shù)、最大個數(shù)、比最小個數(shù)少1、比最大個數(shù)多1等情況設計測試用例。

(3)對軟件規(guī)格說明中的每一個輸出條件仿照前面對輸入條件使用的(1)、(2)原則設計測試用例。邊界值分析法通常不作為一種獨立的測試方法，而是作為其他測試方法的一種補充。例如，使用等價類劃分法設計測試用例后，再使用邊界值分析法補充部分測試用例對邊界情況進行測試。黑盒測試方法除了上面介紹的兩種之外，常見的還有因果圖、錯誤推測法和判定表驅(qū)動測試等。本書在此不進行詳細介紹。6.1.5測試過程與步驟軟件測試的過程如圖6.3所示。圖6.3中的輸入有兩類，即：

(1)軟件，即待測試的軟件，包括設計階段相關(guān)的文檔和源程序清單等。

(2)測試構(gòu)造，包括測試計劃、測試用例及預期的測試結(jié)果。將得到的測試結(jié)果與預期結(jié)果比較，如果不符，則意味著錯誤，需要糾正，經(jīng)過糾錯后的軟件需要再進行回歸測試，如此反復地進行；如果相符，則根據(jù)測試過程中錯誤發(fā)生的情況建立可靠性模型，作為系統(tǒng)付諸實施后的維護工作的依據(jù)。這一點正如前面所講的，測試的目的并不是證明軟件的正確性，測試通過的軟件仍然可能含有錯誤。大型軟件的測試工作一般分為模塊測試、集成測試、確認測試和系統(tǒng)測試四個階段。下面我們對每個階段的主要內(nèi)容和方法進行簡單的介紹。6.1.6模塊測試程序模塊是構(gòu)成信息系統(tǒng)中軟件部分的基本單位，模塊的測試是信息系統(tǒng)軟件測試的第一步。模塊測試又叫單元測試，經(jīng)驗表明模塊測試發(fā)現(xiàn)的錯誤占錯誤總數(shù)的65%，其重要性顯而易見。一個模塊具有以下屬性：

(1)名字；

(2)應完成的功能；

(3)實現(xiàn)功能所應采用的算法；

(4)內(nèi)部使用的數(shù)據(jù)結(jié)構(gòu)；

(5)模塊接口。一個模塊可被其他模塊調(diào)用，因此要接收輸入?yún)?shù)，并在該模塊執(zhí)行完成后給調(diào)用模塊返回輸出參數(shù)。該模塊在執(zhí)行過程中也可能調(diào)用其他模塊，因此需要輸出數(shù)據(jù)作為被調(diào)用模塊的輸入?yún)?shù)，并接收被調(diào)用模塊返回的輸入數(shù)據(jù)。

1.模塊測試的內(nèi)容模塊測試針對模塊的各項屬性進行檢驗測試，主要內(nèi)容有：

1)模塊接口測試在測試模塊的其他屬性之前，首先應對穿過模塊接口的數(shù)據(jù)進行測試。如果數(shù)據(jù)不能正確地在模塊之間傳遞，其他的動態(tài)測試將不能正常進行。在對模塊接口進行測試和檢驗時，應著重參照Myers提供的常見程序錯誤清單中的“模塊接口檢查表”和“完成外部輸入/輸出時的檢查表”來逐項檢查。

2)局部數(shù)據(jù)結(jié)構(gòu)對于一個模塊來說，局部數(shù)據(jù)結(jié)構(gòu)通常是錯誤的發(fā)源地，應該設計相應的測試用例，以便發(fā)現(xiàn)下列類型的錯誤：

(1)不一致或不正確的說明；

(2)錯誤的初始化或錯誤的缺省值；

(3)不相容的數(shù)據(jù)類型；

(4)上溢、下溢和地址異常。除了局部數(shù)據(jù)結(jié)構(gòu)外，如有可能，在模塊測試期間也應檢查全局數(shù)據(jù)對模塊的影響。

3)覆蓋條件和路徑測試在單元測試期間，必須對重要模塊的基本路徑進行測試。應設計測試用例，用來發(fā)現(xiàn)由于不正確的計算、比較或不適當?shù)目刂屏鞫斐傻腻e誤。計算中常見的錯誤有：

(1)算術(shù)運算優(yōu)先次序不正確或誤解了運算次序；

(2)運算方式不正確；

(3)初始化不正確；

(4)精度不夠；

(5)表達式的符號表示不正確。程序中的比較運算和控制流向關(guān)系密切，通常在比較之后發(fā)生控制流的變化。測試用例應發(fā)現(xiàn)下述錯誤：

(1)不同數(shù)據(jù)類型的數(shù)據(jù)進行比較；

(2)邏輯運算符不正確或優(yōu)先次序不正確；

(3)因為精度問題造成期待相等的數(shù)據(jù)不相等；

(4)循環(huán)終止條件不正確；

(5)不正確地修改循環(huán)變量。

4)錯誤處理良好的程序設計應能預先估計到運算中可能發(fā)生的錯誤和異常，例如誤操作或不正確的輸入數(shù)據(jù)，并給出相應的處理措施。在模塊測試時，應有意地進行不合理輸入，檢查程序的錯誤處理能力。主要注意檢查如下幾種情況：

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

(2)輸出的出錯信息與實際不符；

(3)錯誤處理不正確；

(4)在錯誤處理之前，錯誤已引起系統(tǒng)干預。操作系統(tǒng)一般都具有一定的錯誤捕獲能力，但是它給出的錯誤信息一般比較籠統(tǒng)，應用程序應在操作系統(tǒng)捕獲錯誤之前，對錯誤進行處理。

5)邊界測試對輸入輸出數(shù)據(jù)的各種等價類邊界，以及分支條件和循環(huán)條件的邊界，都應測試模塊能否正確工作。

2.模塊測試的步驟與方法單元測試常被當作編碼的附屬步驟，當編碼完成后，程序員首先進行初步檢查，然后可由專門的測試人員或采用碼審查會的形式來進行測試。在確認沒有語法錯誤之后，可針對每個模塊單獨地進行測試工作。模塊的動態(tài)測試采取白盒測試的方法，根據(jù)模塊設計階段得到的模塊的邏輯結(jié)構(gòu)設計測試用例。由于模塊不是完整獨立的程序，往往不能獨立地運行，在整個系統(tǒng)中既可能被別的模塊調(diào)用，也可能調(diào)用其他的模塊。要進行動態(tài)測試，必須要模擬這兩類關(guān)系以建立一個獨立的測試環(huán)境。在單元測試過程中，需要設計兩類輔助測試模塊來模擬這兩類關(guān)系。用以模擬被測模塊的上級調(diào)用模塊稱為驅(qū)動模塊；模擬被測模塊運行過程中所調(diào)用的模塊稱為樁模塊。驅(qū)動模塊的作用是：在單元測試中從外部接受測試數(shù)據(jù)；把測試數(shù)據(jù)轉(zhuǎn)發(fā)給被測模塊，運行被測模塊；接受被測模塊的測試結(jié)果數(shù)據(jù)；輸出結(jié)果數(shù)據(jù)。驅(qū)動模塊一般包含三種語句：輸入語句、仿照其上級模塊調(diào)用格式的調(diào)用語句、輸出語句。樁模塊用來代替被測模塊所調(diào)用的模塊。一般只需打印接口數(shù)據(jù)并返回，以便于檢測被測模塊與其下級模塊之間的接口，有時也需要用最簡單的方法來模擬它所替代的模塊的動作。驅(qū)動模塊和樁模塊只是為測試而編寫的，一般都很簡單，測試工作結(jié)束后它們就沒有用處了。模塊測試階段如果發(fā)現(xiàn)程序有錯，錯誤一般發(fā)生在編碼和模塊設計階段，應對編碼和模塊設計階段的工作進行檢查，改正錯誤后重新測試，直至模塊能完成規(guī)定的功能。6.1.7集成測試模塊測試完成后，每個模塊能正常完成規(guī)定的工作。進一步的工作就是將所有模塊組裝起來構(gòu)成一個完整的系統(tǒng)。

1.集成測試的基本方法實踐表明，單個模塊能正常工作，并不能保證組裝后也能正常工作。常見的原因有：

(1)模塊間的接口未經(jīng)過嚴格測試，可能存在錯誤；

(2)一個模塊可能會破壞另一個模塊的功能；

(3)把子功能組合起來不能產(chǎn)生預期的主功能；

(4)單個模塊可以接受的誤差在組裝后累計放大，超出可接受的程度。鑒于以上的原因，在模塊的組裝過程中必須進行測試，稱為集成測試或組裝測試。集成測試的主要目的是發(fā)現(xiàn)與接口有關(guān)的錯誤。如果集成測試階段發(fā)現(xiàn)錯誤，則可能是在總體設計階段設計軟件結(jié)構(gòu)時模塊之間接口定義有誤。集成測試主要有非漸增式測試和漸增式測試兩種方法。

(1)非漸增式測試的過程是：先對每個模塊進行測試，再將所有模塊按系統(tǒng)軟件結(jié)構(gòu)組裝，然后進行測試。一般用黑盒測試法設計測試用例。

(2)漸增式測試的過程是：逐個將未經(jīng)測試的模塊組裝到已經(jīng)測試過的模塊上，然后進行集成測試。它不嚴格區(qū)分模塊測試和集成測試階段。每加入一個新模塊都進行一次測試，重復此過程直到系統(tǒng)組裝完成。漸增式測試模塊組裝的順序可分為自頂向下結(jié)合和自底向上結(jié)合兩種方法。

1)自頂向下結(jié)合自頂向下結(jié)合的方法是：按照軟件結(jié)構(gòu)圖自頂向下進行結(jié)合，首先測試頂層模塊，然后逐步加入下層模塊?？刹扇∠葟V度后深度逐層安裝，或者先深度后廣度進行模塊結(jié)合。自頂向下結(jié)合方法不需要編寫驅(qū)動模塊，因為模塊被組裝進來時，它的上層模塊已安裝好。圖6.4所示的軟件結(jié)構(gòu)圖采用先廣度后深度逐層安裝時，模塊的安裝順序為A→B→C→D→E→F→G；若采用先深度后廣度結(jié)合方法，模塊的安裝順序則為A→B→E→C→F→D→G。圖6.4軟件結(jié)構(gòu)圖

2)自底向上結(jié)合自底向上結(jié)合的方法是：按照軟件結(jié)構(gòu)圖自底向上，逐步安裝與測試，直到測試結(jié)束。圖6.4的軟件結(jié)構(gòu)測試過程如圖6.5所示，分三步組裝測試(圖中di表示驅(qū)動模塊)。自底向上的結(jié)合方式只需要驅(qū)動模塊，不需要樁模塊。圖6.5自底向上結(jié)合對于復雜的軟件結(jié)構(gòu)，在底層進行模塊結(jié)合時一般按照子功能進行結(jié)合，把接近底層的模塊分為若干族，為每一族分別編寫驅(qū)動程序進行測試。

2.不同測試方法的比較非漸增式測試方法單元測試階段使用的輔助模塊較多，適合于較小規(guī)模的系統(tǒng)。而且如果系統(tǒng)規(guī)模很大，則測試中若發(fā)現(xiàn)錯誤，錯誤的定位將非常困難。漸增式測試逐步組裝系統(tǒng)，很容易發(fā)現(xiàn)錯誤發(fā)生在哪個模塊，適合于大規(guī)模的系統(tǒng)。采用自頂向下結(jié)合可在程序測試的早期實現(xiàn)并驗證系統(tǒng)的主要功能，及早發(fā)現(xiàn)上層的接口錯誤，但對底層關(guān)鍵模塊中的錯誤發(fā)現(xiàn)較晚。采用自頂向下結(jié)合不能多個測試小組同時工作，測試周期較長。采用自底向上測試的優(yōu)缺點與自頂向下相反，可以及早發(fā)現(xiàn)底層關(guān)鍵模塊中的錯誤，但到測試的后期才能看到系統(tǒng)的全貌。采用自底向上結(jié)合可以多個測試小組同時展開工作，測試不同的子系統(tǒng)。在實際測試工作中可以采取混合的測試策略，自底向上和自頂向下測試同時展開，對系統(tǒng)的上層采用自頂向下的組裝方法，而對系統(tǒng)的中、下層模塊采用自底向上組裝測試的方法。6.1.8確認測試確認測試，也稱為驗收測試。在集成測試之后，軟件已組裝完成，接口錯誤也已改正，下一步應該驗證軟件的有效性，由用戶參與測試，檢驗軟件功能是否與用戶的要求一致。確認測試通過黑盒測試法來證實軟件的功能與用戶要求是否一致。測試計劃和測試過程的目標是：檢查功能、性能要求是否達到，文檔資料是否正確完整以及其他要求如可移植性、錯誤恢復能力和易維護性等是否滿足。確認測試如果發(fā)現(xiàn)功能或性能與用戶要求有差距，通常與需求分析階段的差錯有關(guān)。因涉及面較廣，通常需要與用戶協(xié)商來妥善解決。確認測試由用戶試運行系統(tǒng)進行驗收，在測試前應對用戶進行培訓。信息系統(tǒng)試運行前的培訓工作的內(nèi)容請參考6.3節(jié)。對于一些通用的軟件，要求所有客戶進行驗收確認是不可能的。這類軟件確認測試一般分為兩個階段，稱為Alpha(α)測試和Beta(β)測試。Alpha測試在開發(fā)者的場所由用戶在開發(fā)者關(guān)注和控制的環(huán)境下進行。Beta測試則是在一個或多個客戶自己的場所由最終用戶進行，開發(fā)者不到場。客戶記錄下測試中遇到的所有問題，試運行一個階段后把這些問題報告給開發(fā)者。6.1.9系統(tǒng)測試軟件經(jīng)過確認測試后，最終還要與系統(tǒng)中的其他部分配套運行。系統(tǒng)測試的任務就是測試軟件與系統(tǒng)其他部分是否能正常配套工作。系統(tǒng)測試通常有以下幾類測試：

(1)恢復測試：通過人工干預使軟件出錯，檢查在故障狀態(tài)下系統(tǒng)的修復能力。

(2)安全測試：設計測試用例，突破軟件安全保護機構(gòu)的安全保密措施，檢驗系統(tǒng)是否有安全保密的漏洞。

(3)強度測試：檢驗系統(tǒng)負荷能力的最高限度。進行強度測試時，讓系統(tǒng)的運行處于資源的異常數(shù)量、異常頻率、異常批量的條件下。

(4)性能測試：檢驗安裝在系統(tǒng)內(nèi)的軟件的運行性能，一般與強度測試結(jié)合進行。對于專為某個特定的組織機構(gòu)開發(fā)的信息系統(tǒng)，一般在集成測試后即進入試運行，讓它實際地運行一段時間，對系統(tǒng)的功能和性能進行驗收測試。有關(guān)試運行階段的工作將在6.3節(jié)中介紹。6.1.10測試階段的主要文檔測試階段的主要文檔包括測試計劃和測試分析報告。單元測試作為編碼階段的附帶步驟，一般沒有獨立的文檔，這里講的測試主要是指整個程序系統(tǒng)的組裝測試和確認測試。

1.測試計劃測試計劃包括每項測試活動的內(nèi)容、進度安排、設計考慮、測試數(shù)據(jù)的整理方法及評價準則。表6.3為測試計劃的編寫提綱。表6.3測試計劃的編寫提綱

1.引言

1.1編寫目的

1.2背景

1.3定義

1.4參考資料2.計劃

2.1軟件說明

2.2測試內(nèi)容

2.3測試1(標識符)

2.3.1進度安排

2.3.2條件

2.3.3測試資料

2.3.4測試培訓

2.4測試2(標識符)3.測試設計說明

3.1測試l(標識符)

3.1.1控制

3.1.2輸入

3.1.3輸出

3.1.4過程

3.2測試2(標識符)4.評價準則

4.1范圍

4.2數(shù)據(jù)整理

4.3尺度

2.測試分析報告測試分析報告的編寫是為了把組裝測試和確認測試的結(jié)果、發(fā)現(xiàn)及分析寫成文件加以記載，具體的內(nèi)容要求如表6.4所示。表6.4測試分析報告編寫提綱1.引言

1.1編寫目的

1.2背景

1.3定義

1.4參考資料2.測試概要3.測試結(jié)果及發(fā)現(xiàn)

3.1測試1(標識符)

3.2測試2(標識符)4.對軟件功能的結(jié)論

4.1功能1(標識符)

4.1.1能力

4.1.2限制

4.2功能2(標識符)5.分析摘要

5.1能力

5.2缺陷和限制

5.3建議

5.4評價6.測試資源消耗6.2調(diào)試6.2.1調(diào)試方法軟件測試的目的是發(fā)現(xiàn)程序中是否有錯誤，錯誤在什么位置以及錯誤的原因。發(fā)現(xiàn)錯誤后應進行調(diào)試。調(diào)試工作包含兩個方面：一是查找錯誤的位置和原因，二是改正錯誤。查找錯誤的位置和原因是調(diào)試工作的重點，本節(jié)著重介紹如何確定錯誤的位置。測試中發(fā)現(xiàn)程序的運行結(jié)果與預期結(jié)果不符，僅從運行結(jié)果往往無法判斷，因此在調(diào)試程序時一般都會采取一些方法以獲得更多的信息。常用的一些調(diào)試方法有：

1)輸出存儲器內(nèi)容這種方法一般在調(diào)試匯編語言編寫的程序時使用。通過輸出存儲器的內(nèi)容獲取程序運行出現(xiàn)錯誤的現(xiàn)場，然后進行分析研究，判斷出錯的原因。這種方法由于輸出信息量極大，而且輸出的是某一時刻狀態(tài)，不能動態(tài)反映程序的執(zhí)行情況，往往很難從中查找出錯誤的原因。

2)打印語句在程序中插入打印語句輸出關(guān)鍵變量在程序運行過程中的動態(tài)值，可以檢驗在某個事件后，變量是否按預期的要求發(fā)生變化。這種方法需要修改源程序插入打印語句，可用于模塊測試或小型程序的調(diào)試。

3)自動調(diào)試工具利用調(diào)試工具來分析程序的動態(tài)行為。目前大部分的開發(fā)環(huán)境都提供一定的調(diào)試功能，也可以選擇一些獨立的調(diào)試工具軟件。一般調(diào)試工具提供的調(diào)試功能主要有：變量值觀察與修改、單步跟蹤、設置斷點等?？梢栽趫?zhí)行過程中觀察變量的動態(tài)變化。6.2.2調(diào)試策略在使用上面介紹的幾種常用調(diào)試方法調(diào)試程序時還需注意調(diào)試策略。例如，如何確定在程序中什么位置打印變量的值或設置斷點。常見的調(diào)試策略如下。

1)試探法分析測試結(jié)果，猜想錯誤發(fā)生的大致位置，再用前面介紹的調(diào)試方法確定出錯位置。這種方法效率一般很低。

2)回溯法這是一種對小型程序很有效的調(diào)試方法。從錯誤發(fā)生征兆的位置開始，人工往回追溯源程序代碼，直到征兆消失為止，進而找出錯誤的原因。

3)歸納法從一些線索(錯誤的跡象可能存在于一種或多種測試用例的結(jié)果中)著手，分析尋找它們之間的聯(lián)系，提出對錯誤原因的假設，然后再證明或否認假設。歸納法的工作過程如圖6.6所示。圖6.6歸納法調(diào)試過程

4)演繹法演繹法與歸納法過程相反，它首先列舉出一些可能的原因和假設，然后根據(jù)測試結(jié)果對列出的錯誤原因進行排除，分析余下的錯誤原因，不能確定就留下繼續(xù)分析，可確定就排除錯誤。對剩余不可確定的原因，再增加測試數(shù)據(jù)，重復測試過程，直到故障排除。圖6.7是演繹法實施的過程。圖6.7演繹法調(diào)試過程6.3系統(tǒng)實施6.3.1人員及崗位培訓系統(tǒng)實施是系統(tǒng)開發(fā)的最后一個階段，將系統(tǒng)設計階段的結(jié)果在計算機上實現(xiàn)。系統(tǒng)實施階段的主要任務除了前面章節(jié)中已介紹的程序設計與調(diào)試外，還包括計算機硬件設備的購置和安裝調(diào)試、操作人員的培訓和系統(tǒng)切換及試運行。為用戶單位培訓系統(tǒng)操作、維護、運行管理人員是信息系統(tǒng)開發(fā)過程中不可缺少的重要環(huán)節(jié)。對人員的培訓工作應該盡早進行，一方面是因為系統(tǒng)開發(fā)的各個階段都必須有用戶參加，盡早培訓可以更好地使系統(tǒng)分析人員與用戶進行溝通；另一方面，系統(tǒng)集成測試之后將投入試運行和實際運行，用戶接受培訓后可以更好地配合開發(fā)人員進行系統(tǒng)測試。一般對操作人員的培訓與編程和調(diào)試工作同時進行，培訓的主要內(nèi)容包括：

(1)系統(tǒng)整體結(jié)構(gòu)，系統(tǒng)概貌；

(2)系統(tǒng)分析設計思想和每一步考慮；

(3)系統(tǒng)輸入方式和操作方式的培訓；

(4)可能出現(xiàn)的故障以及故障的排除；

(5)系統(tǒng)文檔資料的分類以及檢索方式；

(6)數(shù)據(jù)的收集、統(tǒng)計渠道、統(tǒng)計口徑等；

(7)運行操作注意事項等。如果系統(tǒng)用戶對計算機技術(shù)不甚了解，對信息系統(tǒng)缺乏基本的認識，則在系統(tǒng)開發(fā)早期還應對用戶進行MIS及計算機基本知識的培訓，在系統(tǒng)試運行前還應對計算機系統(tǒng)的基本操作、漢字輸入方法等進行培訓。6.3.2試運行和系統(tǒng)轉(zhuǎn)換系統(tǒng)實施的最后一個階段就是新系統(tǒng)的試運行和新老系統(tǒng)的轉(zhuǎn)換。系統(tǒng)試運行階段的主要工作包括：

(1)系統(tǒng)的初始化，輸入原始數(shù)據(jù)記錄；

(2)記錄系統(tǒng)的運行數(shù)據(jù)和運行狀況；

(3)核對新系統(tǒng)和老系統(tǒng)(人工或計算機系統(tǒng))的輸出結(jié)果；

(4)對實際系統(tǒng)的輸入方式進行考查(是否方便、效率如何、安全可靠性、誤操作保護等)；

(5)對系統(tǒng)實際運行、響應速度(包括運算速度、傳遞速度、查詢速度、輸出速度等)進行實際測試。為特定用戶開發(fā)的專用信息系統(tǒng)一般在系統(tǒng)組裝完成后即進入試運行，試運行階段的工作包含了對系統(tǒng)進行確認測試和系統(tǒng)測試的任務。新系統(tǒng)開發(fā)完成后最終要代替老系統(tǒng)，完成系統(tǒng)的切換。系統(tǒng)切換有如下三種方式。

1)直接切換在確定新系統(tǒng)運行準確無誤時，立刻啟用新系統(tǒng)，終止老系統(tǒng)的運行。這種方式節(jié)省人員和設備費用，適用于一些處理過程不太復雜、數(shù)據(jù)不很重要的場合。

2)并行切換新老系統(tǒng)并行工作一段時間，經(jīng)過一段時間的考驗后，新系統(tǒng)正式替代老系統(tǒng)。對于較復雜的大型系統(tǒng)，這種方法提供了一個與舊系統(tǒng)運行結(jié)果進行比較的機會，可以對新舊兩個系統(tǒng)的時間要求、出錯次數(shù)和工作效率給以公正的評價。由于與舊系統(tǒng)并行工作，用戶消除了尚未認識新系統(tǒng)之前的驚慌與不安。這種方式的主要特點是安全、可靠，但費用和工作量都很大。

3)分段切換這種切換方式是上面兩種方式的結(jié)合。在新系統(tǒng)正式運行前，一部分一部分地替代老系統(tǒng)。切換過程中沒有正式運行的那一部分，可以在一個模擬環(huán)境中進行考驗。這種方式既保證了可靠性，又不至于費用太大。但是這種分段切換對系統(tǒng)的設計和實現(xiàn)都有一定的要求，否則無法實現(xiàn)這種分段切換。圖6.8是上面三種方式的示意圖。圖6.8系統(tǒng)切換的三種方式6.4系統(tǒng)維護6.4.1維護的內(nèi)容信息系統(tǒng)實施之后，由于各種因素的影響，例如系統(tǒng)運行環(huán)境的變化或者程序中存在未檢測到的錯誤等，為了保證系統(tǒng)的正常工作，要求系統(tǒng)不斷地完善并能適應各種變化，還需要進行系統(tǒng)的維護工作。系統(tǒng)維護的工作內(nèi)容大致包括：

(1)軟件的維護：運行中發(fā)現(xiàn)軟件測試階段未發(fā)現(xiàn)的錯誤，或者用戶對系統(tǒng)的功能要求發(fā)生變化，以及業(yè)務量的急劇增長等都有可能需要對軟件進行修改。

(2)數(shù)據(jù)文件及代碼的維護：隨著系統(tǒng)的變化，原有的數(shù)據(jù)文件或代碼不能適應新的需要，需要維護數(shù)據(jù)文件或修改舊的代碼系統(tǒng)。

(3)硬件的維護：包括計算機、網(wǎng)絡及相關(guān)設備的日常管理和維護工作。一旦硬件發(fā)生故障，必須有專門的人員進行修理。

(4)機構(gòu)和人員的變動：機構(gòu)和人員的變動有時也會對信息系統(tǒng)的流程和對設備及程序的維護工作產(chǎn)生影響。6.4.2軟件維護的分類軟件維護是信息系統(tǒng)維護的主要工作，軟件工程學科將軟件維護定義為“對現(xiàn)有運行軟件進行修改而同時保留其主要功能不變的過程”。通常軟件維護工作可分為如下四類。

1)改正性維護軟件測試不可能將所有潛在的錯誤都查找出來，設計再好的測試用例也難免存在遺漏。運行中必然會發(fā)現(xiàn)軟件錯誤，需要維護人員進行調(diào)試并改正錯誤。這類維護工作稱為改正性維護或糾錯性維護。

2)適應性維護計算機系統(tǒng)硬件及操作系統(tǒng)的更新?lián)Q代頻繁，而一個大型的信息系統(tǒng)軟件開發(fā)常常需要耗費巨資，因為系統(tǒng)運行環(huán)境的改變而廢棄不用是很不合算的。因此要求維護人員對原來的軟件進行修改，以適應新的軟硬件運行環(huán)境的要求。這類維護活動稱為適應性維護。

3)完善性維護當系統(tǒng)投入使用之后，用戶會提出增加新功能，修改已有的功能以及一般的改進和建議。為了滿足和部分滿足這類要求，所進行的維護活動稱為完善性維護。完善性維護占軟件維護工作的大部分。

4)預防性維護為了給未來的改進奠定更好的基礎而修改軟件的維護活動稱為預防性維護。這類維護活動相對較少。完善性維護占據(jù)了維護工作量的大部分，是最主要的維護活動。圖6.9是1987年由RogerS.Pressman統(tǒng)計的四種維護活動的分布情況。圖6.9四種維護工作量的分布維護工作的多少和難易程度取決于軟件設計的水平，軟件開發(fā)應該注意按照軟件工程方法的要求進行，以提高軟件的可維護性。軟件的可維護性由維護人員理解、改正、改動和改進軟件的難易程度來衡量。開發(fā)過程的每個階段必須有完備一致的文檔資料，在設計軟件結(jié)構(gòu)時應注意提高模塊之間的獨立性。完備一致的文檔資料有助于維護階段閱讀理解程序，對軟件維護之后相應的文檔資料也應該進行修改以保持軟件與文檔的一致性。模塊之間的獨立性可以避免維護工作中對某一個模塊的修改而影響到系統(tǒng)中的其他模塊。6.4.3維護的管理系統(tǒng)的各項維護工作都應有專人負責，并且通過一定的審批手續(xù)。系統(tǒng)硬件維護的管理相對簡單，本節(jié)我們主要討論軟件維護的管理，因為軟件維護相對影響較大，例如一個業(yè)務處理過程的修改，往往會影響其他過程或子系統(tǒng)。軟件維護工作應由相對固定的維護組織來承擔，一般應少吸收設計人員參加。這樣可以促使設計人員在設計時注意提高軟件的可維護性，另一方面不會影響設計人員從事新項目的開發(fā)工作。軟件維護首先由系統(tǒng)操作的各類人員或業(yè)務管理人員提出對某項工作的要求，申請形式可以是書面報告或填寫專門的維護申請表。維護要求被批準后，系統(tǒng)管理員組織維護人員實施維護，軟件維護的工作流程可參考圖6.10。圖6.10軟件維護工作流程維護要求按其類型分成兩條不同的處理路線。對于適應性和完善性維護來說，其性質(zhì)與開發(fā)工作類似。對每次的軟件維護活動都應作出維護記錄，并存入軟件維護數(shù)據(jù)庫中。維護記錄一般包含下面的一些內(nèi)容：●程序標識；●源語句數(shù)；●使用的程序設計語言；●程序安裝的日期；●自從安裝以來程序運行的次數(shù)；●自從安裝以來程序失效的次數(shù)；●程序改動的層次和標識；●因程序修改而增加的源語句數(shù)；●因程序修改而刪除的源語句數(shù)；●每個改動所耗費的人時數(shù)；●程序修改的日期；●軟件維護工程師的姓名；●維護要求表的標識；●維護類型；●維護開始和完成的日期；●累計用于維護的人時數(shù)；●該維護完成所帶來的純效益。實驗五

1．實驗目的本章主要介紹了系統(tǒng)軟件測試和調(diào)試以及系統(tǒng)的實施運行工作的內(nèi)容和基本方法，安排本次實驗的主要目的為：

(1)熟悉單元測試和集成測試的主要任務；

(2)掌握白盒測試和黑盒測試設計測試用例的主要方法；

(3)學習編寫測試計劃和測試報告；

(4)熟悉集成測試的主要步驟；

(5)熟練掌握常見開發(fā)工具的調(diào)試功能的使用方法，積累程序調(diào)試的經(jīng)驗。

2．實驗內(nèi)容對實驗四中編寫的各個模塊的代碼分別進行單元測試，排除錯誤，然后編寫集成測試計劃，進行集成測試，最后編寫測試報告。

3．實驗