第11講軟件測試技術-白盒測試

一單元測試

單元測試集中檢測軟件設計的最小單元——模塊。通常，單元測試和編碼屬于軟件過程的同一個階段。在編寫出源程序代碼并通過了編譯程序的語法檢查之后，就可以用詳細設計描述作指南，對重要的執(zhí)行通路進行測試，以便發(fā)現模塊內部的錯誤?？梢詰萌斯y試和計算機測試這樣兩種不同類型的測試方法，完成單元測試工作。這兩種測試方法各有所長，互相補充。通常，單元測試主要使用白盒測試技術，而且對多個模塊的測試可以并行地進行。

單元測試重點1.模塊接口

首先應該對通過模塊接口的數據流進行測試，如果數據不能正確地進出，所有其他測試都是不切實際的。在對模塊接口進行測試時主要檢查下述幾個方面：參數的數目、次序、屬性或單位與變元是否一致；是否修改了只作輸入用的變元；全局變量的定義和用法在各個模塊中是否一致。單元測試重點2.局部數據結構

應該仔細設計測試方案，以便發(fā)現局部數據說明、初始化、默認值等方面的錯誤。

3.重要的執(zhí)行通路由于通常不可能進行窮盡測試，因此，在單元測試期間選擇最有代表性、最可能發(fā)現錯誤的執(zhí)行通路進行測試就是十分關鍵的。應該設計測試方案用來發(fā)現由于錯誤的計算、不正確的比較或不適當的控制流而造成的錯誤。單元測試重點4.出錯處理通路好的設計應該能預見出現錯誤的條件，并且設置適當的處理錯誤的通路，以便在真的出現錯誤時執(zhí)行相應的出錯處理通路或干凈地結束處理。不僅應該在程序中包含出錯處理通路，而且應該認真測試這種通路。當評價出錯處理通路時，應該著重測試下述一些可能發(fā)生的錯誤：(1)對錯誤的描述是難以理解的；(2)記下的錯誤與實際遇到的錯誤不同；(3)在對錯誤進行處理之前，錯誤條件已經引起系統干預；(4)對錯誤的處理不正確；(5)描述錯誤的信息不足以幫助確定造成錯誤的位置。代碼審查人工測試源程序可以先由編寫者本人非正式地進行，然后由審查小組正式進行。后者稱為代碼審查，它是一種非常有效的程序驗證技術，對于典型的程序來說，可以查出30%～70%

的邏輯設計錯誤和編碼錯誤。代碼審查審查小組最好由下述4人組成：(1)組長，應該是一個很有能力的程序員，而且沒有直接參與這項工程；(2)程序的設計者；(3)程序的編寫者；(4)程序的測試者。(5)其他人員代碼審查審查之前，小組成員應該先研究設計說明書，力求理解這個設計。為了幫助理解，可以先由設計者扼要地介紹他的設計。在審查會上由程序的編寫者解釋他是怎樣用程序代碼實現這個設計的，通常是逐個語句地講述程序的邏輯，小組其他成員仔細傾聽他的講解，并力圖發(fā)現其中的錯誤。審查會上進行的另外一項工作，是對照類似于上一小節(jié)中介紹的程序設計常見錯誤清單，分析審查這個程序。當發(fā)現錯誤時由組長記錄下，審查會繼續(xù)進行(審查小組的任務是發(fā)現錯誤而不是改正錯誤)。運行測試模塊并不是一個獨立的程序，因此必須為每個單元測試開發(fā)”驅動模塊”和(或)“樁模塊”(存根模塊)。通常驅動程序也就是一個“主程序”，它接收測試數據，把這些數據傳送給被測試的模塊，并且印出有關的結果。存根程序代替被測試的模塊所調用的模塊。因此存根程序也可以稱為“虛擬子程序”。它使用被它代替的模塊的接口，可能做最少量的數據操作，印出對入口的檢驗或操作結果，并且把控制歸還給調用它的模。Ⅱ.TESTDRIVER(*測試正文編輯模塊用的驅動程序*)說明長度為2500個字符的一個緩沖區(qū)；把CFUNCT置為希望測試的狀態(tài)；輸入字符串；調用正文編輯模塊停止或再次初啟；ENDTESTDRIVERⅠ.TESTSTUB(*測試正文編輯模塊用的存根程序*)初始化；輸出信息“進入了正文編輯程序”；輸出“輸入的控制信息是”CFUNCT；輸出緩沖區(qū)中的字符串；IFCFUNCT=CHANGETHEN把緩沖區(qū)中第二個字改為***ELSE在緩沖區(qū)的尾部加???ENDIF；輸出緩沖區(qū)中的新字符串；ENDTESTSTUB二集成測試

集成測試是測試和組裝軟件的系統化技術.例如，數據穿過接口時可能丟失；一個模塊對另一個模塊可能由于疏忽而造成有害影響；把子功能組合起來可能不產生預期的主功能；個別看來是可以接受的誤差可能積累到不能接受的程度；全程數據結構可能有問題等等。不幸的是，可能發(fā)生的接口問題多得不勝枚舉。

集成測試由模塊組裝成程序時有兩種方法。一種方法是先分別測試每個模塊，再把所有模塊按設計要求放在一起結合成所要的程序，這種方法稱為非漸增式測試方法；另一種方法是把下一個要測試的模塊同已經測試好的那些模塊結合起來進行測試，測試完以后再把下一個應該測試的模塊結合進來測試。這種每次增加一個模塊的方法稱為漸增式測試，集成測試非漸增式測試一下子把所有模塊放在一起，并把龐大的程序作為一個整體來測試，測試者面對的情況十分復雜。測試時會遇到許許多多的錯誤，改正錯誤更是極端困難，因為在龐大的程序中想要診斷定位一個錯誤是非常困難的。而且一旦改正一個錯誤之后，馬上又會遇到新的錯誤，這個過程將繼續(xù)下去，看起來好像永遠也沒有盡頭。漸增式測試與“一步到位”的非漸增式測試相反，它把程序劃分成小段來構造和測試，在這個過程中比較容易定位和改正錯誤；對接口可以進行更徹底的測試；可以使用系統化的測試方法。因此，目前在進行集成測試時普遍采用漸增式測試方法。漸增方式集成測試自頂向下集成自底向上集成回歸測試

任何成功的測試都會發(fā)現錯誤，而且錯誤必須被改正。每當改正軟件錯誤的時候，軟件配置的某些成分（程序、文檔或數據）也被修改了。回歸測試就是用于保證由于調試或其他原因引起的變化，不會導致非預期的軟件行為或額外錯誤的測試活動。回歸測試可以通過重新執(zhí)行全部測試用例的一個子集進行回歸測試用例集

回歸測試集（已執(zhí)行過的測試用例的子集）包括下述3類不同的測試用例：（1）檢測軟件全部功能的代表性測試用例；（2）專門針對可能受修改影響的軟件功能的附加測試；（3）針對被修改過的軟件成分的測試。在集成測試過程中，回歸測試用例的數量可能變得非常大。因此，應該把回歸測試集設計成只包括可以檢測程序每個主要功能中的一類或多類錯誤的那樣一些測試用例。一旦修改了軟件之后就重新執(zhí)行檢測程序每個功能的全部測試用例，是低效而且不切實際的。三確認測試

確認測試也稱為驗收測試，它的目標是驗證軟件的有效性。確認（validation）和驗證（verification）通常，驗證指的是保證軟件正確地實現了某個特定要求的一系列活動，而確認指的是為了保證軟件確實滿足了用戶需求而進行的一系列活動。確認測試的范圍確認測試必須有用戶積極參與，或者以用戶為主進行。用戶應該參與設計測試方案，使用用戶界面輸入測試數據并且分析評價測試的輸出結果。為了使得用戶能夠積極主動地參與確認測試，特別是為了使用戶能有效地使用這個系統，通常在驗收之前由開發(fā)單位對用戶進行培訓。確認測試通常使用黑盒測試法。應該仔細設計測試計劃和測試過程，測試計劃包括要進行的測試的種類及進度安排，測試過程規(guī)定了用來檢測軟件是否與需求一致的測試方案。通過測試和調試要保證軟件能滿足所有功能要求，能達到每個性能要求，文檔資料是準確而完整的，此外，還應該保證軟件能滿足其他預定的要求（例如，安全性、可移植性、兼容性和可維護性等）。確認測試確認測試有下述兩種可能的結果：（1）功能和性能與用戶要求一致，軟件是可以接受的；（2）功能和性能與用戶要求有差距。在這個階段發(fā)現的問題往往和需求分析階段的差錯有關，涉及的面通常比較廣，因此解決起來也比較困難。為了制定解決確認測試過程中發(fā)現的軟件缺陷或錯誤的策略，通常需要和用戶充分協商。軟件配置復查確認測試的一個重要內容是復查軟件配置。復查的目的是保證軟件配置的所有成分都齊全，質量符合要求，文檔與程序完全一致，具有完成軟件維護所必需的細節(jié)，而且已經編好目錄。除了按合同規(guī)定的內容和要求，由人工審查軟件配置之外，在確認測試過程中還應該嚴格遵循用戶指南及其他操作程序，以便檢驗這些使用手冊的完整性和正確性。必須仔細記錄發(fā)現的遺漏或錯誤，并且適當地補充和改正。Alpha和Beta測試

如果一個軟件是為許多客戶開發(fā)的（例如，向大眾公開出售的盒裝軟件產品），那么，讓每個客戶都進行正式的驗收測試是不現實的。在這種情況下，絕大多數軟件開發(fā)商都使用被稱為Alpha測試和Beta測試的過程，來發(fā)現那些看起來只有最終用戶才能發(fā)現的錯誤。Alpha測試由用戶在開發(fā)者的場所進行，并且在開發(fā)者對用戶的“指導”下進行測試。開發(fā)者負責記錄發(fā)現的錯誤和使用中遇到的問題?？傊?，Alpha測試是在受控的環(huán)境中進行的。Beta測試由軟件的最終用戶們在一個或多個客戶場所進行。與Alpha測試不同，開發(fā)者通常不在Beta測試的現場，因此，Beta測試是軟件在開發(fā)者不能控制的環(huán)境中的“真實”應用。用戶記錄在Beta測試過程中遇到的一切問題（真實的或想像的），并且定期把這些問題報告給開發(fā)者。接收到在Beta測試期間報告的問題之后，開發(fā)者對軟件產品進行必要的修改，并準備向全體客戶發(fā)布最終的軟件產品4白盒測試測試方案包括具體的測試目的（例如，預定要測試的具體功能），應該輸入的測試數據和預期的結果(測試用例)。不同的測試數據發(fā)現程序錯誤的能力差別很大，為了提高測試效率降低測試成本，應該選用高效的測試數據。4邏輯覆蓋

1.語句覆蓋

為了暴露程序中的錯誤,至少每個語句應該執(zhí)行一次。為了使每個語句都執(zhí)行一次，程序的執(zhí)行路徑應該是sacbed,為此只需要輸入下面的測試數據：A=2，B=0，X=4如果一個測試用例達不到全覆蓋要求,可設計多個,合起來覆蓋(1,0,0)和(2,-1,4)4邏輯覆蓋

2.判定覆蓋

判定覆蓋又叫分支覆蓋,它的含義是，不僅每個語句必須至少執(zhí)行一次，而且每個判定的每種可能的結果都應該至少執(zhí)行一次，也就是每個判定的每個分支都至少執(zhí)行一次。判定覆蓋比語句覆蓋強，但是對程序邏輯的覆蓋程度仍然不高，例如，上面的測試數據只覆蓋了程序全部路徑的一半。4邏輯覆蓋

3.條件覆蓋

條件覆蓋的含義是,不僅每個語句至少執(zhí)行一次，而且使判定表達式中的每個條件都取到各種可能的結果。條件覆蓋通常比判定覆蓋強，因為它使判定表達式中每個條件都取到了兩個不同的結果，判定覆蓋卻只關心整個判定表達式的值。條件覆蓋不一定包含判定覆蓋4邏輯覆蓋

5.條件組合覆蓋

條件組合覆蓋是更強的邏輯覆蓋標準,它要求選取足夠多的測試數據，使得每個判定表達式中條件的各種可能組合都至少出現一次。條件組合覆蓋是前述幾種覆蓋標準中最強的。但是，滿足條件組合覆蓋標準的測試數據并不一定能使程序中的每條路徑都執(zhí)行到。4邏輯覆蓋

8.路徑覆蓋路徑覆蓋的含義是，選取足夠多測試數據，使程序的每條可能路徑都至少執(zhí)行一次(如果程序圖中有環(huán)，則要求每個環(huán)至少經過一次)。5控制結構測試1.基本路徑測試

PROCEDUREaverage;/*這個過程計算不超過100個在規(guī)定值域內的有效數字的平均值；同時計算有效數字的總和及個數。*/INTERFACERETURNSaverage,total.input,total.valid;INTERFACEACCEPTSvalue,minimum,maximum;TYPEvalue［1…100］ISSCALARARRAY;TYPEaverage,total.input,total.valid;minimum,maximum,sumISSCALAR;TYPEiISINTEGER;1:i=1;total.input=total.valid=0;sum=0;2:DOWHILEvalue［i］<>-9993:ANDtotal.input<1004:incrementtotal.inputby1;5:IFvalue［i］>=minimum6:ANDvalue［i］<=maximum7：THENincrementtotal.validby1;sum=sum+value［i］;8:ENDIFincrementiby1;9:ENDDO10:IFtotal.valid>011:THENaverage=sum/total.valid;12:ELSEaverage=-999;13:ENDIFENDaverage5控制結構測試6條獨立路徑:(每個路徑,必須引入新結點)1-2-10-12-131-2-10-11-131-2-3-10-11-131-2-3-4-5-8-9-2..1-2-3-4-5-6-8-9-2..1-2-3-4-5-6-7-6-9-2.