第結構化實現

會計學1第結構化實現

僅就測試而言，它的目標是發(fā)現軟件中的錯誤，但是，發(fā)現錯誤并不是我們的最終目的。軟件工程的根本目標，是開發(fā)出高質量的完全符合用戶需要的軟件產品，因此，通過測試發(fā)現軟件錯誤之后還必須診斷并改正錯誤，這就是調試（也稱為糾錯）的任務。調試是測試階段最困難的工作。在對測試結果進行收集和評價的時候，軟件產品所達到的可靠性也逐漸明朗了。軟件可靠性模型使用故障率數據，預測軟件的可靠性。

第1頁/共113頁4.1編

碼4.2軟件測試概述4.3白盒測試技術4.4黑盒測試技術4.5測試策略4.6調試4.7軟件可靠性4.8小結第2頁/共113頁4.1編

碼4.1.1選擇適當的程序設計語言程序設計語言是人和計算機通信的基本工具，它的特點不可避免地會影響人思維和解決問題的方式，會影響人和計算機通信的方式和質量，也會影響其他人閱讀和理解程序的難易程度。因此，編碼之前的一項重要工作就是選擇一種適當的程序設計語言。適當的程序設計語言能使程序員在根據設計編碼時遇到的困難最少，可以減少需要的程序測試量，并且可以寫出更容易閱讀和更容易維護的程序。由于軟件系統(tǒng)的絕大部分成本用在生命周期的測試和維護階段，因此容易測試和容易維護是極端重要的。返回目錄第3頁/共113頁

總的說來。高級語言明顯優(yōu)于匯編語言，因此，除了在很特殊的應用領域（例如，對程度執(zhí)行時間和使用的空間都有很嚴格限制的情況；需要產生任意的甚至非法的指令序列；體系結構特殊的微處理機，以致在這類機器上通常不能實現高級語言編譯程序），或者大型系統(tǒng)中執(zhí)行時間非常關鍵的（或直接依賴于硬件的）一小部分代碼需要用匯編語言書寫之外，其他程序應該一律用高級語言書寫。為了使程序容易測試和維護以減少生命周期的總成本，選用的高級語言應該有理想的模塊化機制，以及可讀性好的控制結構和數據結構；為了便于調試和提高軟件可靠性，語言特點應該使編譯程序能夠盡可能多地發(fā)現程序中的錯誤；為了降低軟件開發(fā)和維護的成本，選用的語言應該有良好的獨立編譯機制。上述這些要求是選擇語言的理想標準，但是在實際選用語言時不能僅僅考慮理論上的標準，還必須同時考慮實用方面的各種限制。

第4頁/共113頁4.1.2正確的編碼風格雖然選取了好的程序設計語言有助于寫出既可靠又容易閱讀、容易維護的程序，但是，工具再好使用不當也不會達到預期的效果。按照軟件工程方法學開發(fā)軟件，程序是表達軟件設計結果的一種更具體的形式，程序的質量基本上由設計的質量決定，但是，編碼風格也在很大程度上決定著程序的質量。所謂編碼風格就是程序員在編寫程序時遵循的具體準則和習慣做法。源程序代碼的邏輯簡明清晰、易讀易懂是好程序的一個重要標準，為了寫出好程序應該遵循下述規(guī)則。第5頁/共113頁1.程序內部必須有正確的文檔所謂程序內部的文檔包括恰當的標識符、適當的注解和程序的視覺組織等等。選取含義鮮明的名字，使它能正確地提示程序對象所代表的實體，這對于幫助閱讀者理解程序是很重要的。如果使用縮寫，那么縮寫規(guī)則應該一致，并且應該給每個名字加注解。第6頁/共113頁

注解是程序員和程序讀者通信的重要手段，正確的注解非常有助于對程序的理解。通常在每個模塊開始處有一段序言性的注解，簡要描述模塊的功能、主要算法、接口特點、重要數據以及開發(fā)簡史。插在程序中間與一段程序代碼有關的注解，主要解釋包含這段代碼的必要性。對于用高級語言書寫的源程序，不需要用注解的形式把每個語句翻譯成自然語言，應該利用注解提供一些額外的信息。應該用空格或空行清楚地區(qū)分注解和程序。注解的內容一定要正確，錯誤的注解不僅對理解程序毫無幫助，反而會妨礙對程序的理解。程序清單的布局對于程序的可讀性也有很大影響，應該利用適當的階梯形式使程序的層次結構清晰明顯。第7頁/共113頁2.數據說明應便于查閱易于理解雖然在設計期間已經確定了數據結構的組織和復雜程度，然而數據說明的風格卻是在寫程序時確定的。為了使數據更容易理解和維護，有一些比較簡單的原則應該遵循。數據說明的次序應該標準化（例如，按照數據結構或數據類型確定說明的次序）。有次序就容易查閱，因此能夠加速測試、調試和維護的過程。當多個變量名在一個語句中說明時，應該按字母順序排列這些變量。如果設計時使用了一個復雜的數據結構，則應該用注解說明用程序設計語言實現這個數據結構的方法和特點。第8頁/共113頁3.語句應該盡量簡單清晰設計期間確定了軟件的邏輯結構，然而個別語句的構造卻是編寫程序的一個主要任務。構造語句時應該遵循的原則是，每個語句都應該簡單而直接，不能為了提高效率而使程序變得過分復雜。下述規(guī)則有助于使語句簡單明了：●不要為了節(jié)省空間而把多個語句寫在同一行；●盡量避免復雜的條件測試；●盡量減少對“非”條件的測試；●避免大量使用循環(huán)嵌套和條件嵌套；●利用括號使邏輯表達式或算術表達式的運算次序清晰直觀。第9頁/共113頁4.正確的輸入/輸出風格在設計和編寫程序時應該考慮下述有關輸入/輸出風格的規(guī)則：●對所有輸入數據都進行檢驗；●檢查輸入項重要組合的合法性；●保持輸入格式簡單；●使用數據結束標記，不要求用戶指定數據的數目；●明確提示交互式輸入的請求，詳細說明可用的選擇或邊界數值；●當程序設計語言對格式有嚴格要求時，應保持輸入格式一致；●設計良好的輸出報表；●給所有輸出數據加標志。第10頁/共113頁5.不要盲目追求高效率效率主要指處理機時間和存儲器容量兩個方面。雖然值得提出提高效率的要求，但是在進一步討論這個問題之前應該記住三條原則：首先，效率是性能要求，因此應該在需求分析階段確定效率方面的要求。軟件應該像對它要求的那樣有效，而不應該如同人類可能做到的那樣有效。其次，效率是靠好設計來提高的。第三，程序的效率和程序的簡單程度是一致的。不要犧牲程序的清晰性和可讀性來不必要地提高效率。

第11頁/共113頁4.2軟件測試概述測試階段的目標測試的基本原則測試的基本步驟靜態(tài)分析與動態(tài)測試返回目錄第12頁/共113頁軟件測試的目標什么是測試？它的目標是什么？G.Myers給出了關于測試的一些規(guī)則，這些規(guī)則也可以看作是測試的目標或定義：（1）測試是為了發(fā)現程序中的錯誤而執(zhí)行程序的過程；（2）好的測試方案是極可能發(fā)現迄今為止尚未發(fā)現的錯誤的測試方案；（3）成功的測試是發(fā)現了至今為止尚未發(fā)現的錯誤的測試。

第13頁/共113頁完全測試是不可能的軟件測試時有風險的活動測試無法顯示潛伏的軟件缺陷和故障充分注意測試中的群集現象殺蟲劑現象并非所有的軟件缺陷都要修復軟件測試必須有預期結果盡早地、不斷地進行軟件測試程序員應該避免檢查自己的程序測試的基本原則第14頁/共113頁軟件測試的基本步驟單元測試集成測試確認測試系統(tǒng)測試驗收測試第15頁/共113頁靜態(tài)分析與動態(tài)測試靜態(tài)方法桌前檢查代碼會審步行檢查調用圖數據流分析圖第16頁/共113頁4.2.3兩類測試方法怎樣對程序進行測試呢？測試任何產品都有兩種方法：如果已經知道了產品應該具有的功能，可以通過測試來檢驗是否每個功能都能正常使用；如果知道產品內部預定的工作過程，可以通過測試來檢驗產品內部動作是否按照規(guī)格說明書的規(guī)定正常進行。前一個方法稱為黑盒測試，后一個方法稱為白盒測試。第17頁/共113頁

對于軟件測試而言，黑盒測試法把程序看成一個黑盒子，完全不考慮程序的內部結構和處理過程。也就是說，黑盒測試是在程序接口進行的測試，它只檢查程序功能是否能按照規(guī)格說明書的規(guī)定正常使用，程序是否能適當地接收輸入數據產生正確的輸出信息，并且保持外部信息（如，數據庫或文件）的完整性。黑盒測試又稱為功能測試。與黑盒測試法相反，白盒測試法的前提是可以把程序看成裝在一個透明的白盒子里，也就是完全了解程序的結構和處理過程。這種方法按照程序內部的邏輯測試程序，檢驗程序中的每條通路是否都能按預定要求正確工作。白盒測試又稱為結構測試。第18頁/共113頁

粗看起來，不論采用上述哪種測試方法，只要對每一種可能的情況都進行測試，就可以得到完全正確的程序。包含所有可能情況的測試稱為窮盡測試，對于實際程序而言，窮盡測試通常是不可能做到的。

因為不可能進行窮盡測試，所以軟件測試不可能發(fā)現程序中的所有錯誤，也就是說，通過測試并不能證明程序是正確的。但是，我們的目的是要通過測試保證軟件的可靠性，因此，必須仔細設計測試方案，力爭用盡可能少的測試發(fā)現盡可能多的錯誤。第19頁/共113頁4.2.4軟件測試準則為了能夠設計出有效的測試方案，軟件工程師必須充分理解并正確運用指導軟件測試工作的基本準則。下面敘述主要的測試準則：●所有測試都應該能夠追溯到用戶需求。正如前面講過的，軟件測試的目標是發(fā)現程序中的錯誤。從用戶角度看，最嚴重的錯誤是程序不能滿足用戶需求的那些錯誤，因此應該圍繞用戶的需求來測試程序。●應該在開始測試之前預先制定出測試計劃。一旦完成了需求分析就可以著手制定測試計劃，在確定了設計模型之后就可以立即開始設計詳細的測試方案。因此，在編碼之前就可以對所有測試工作進行計劃和設計。第20頁/共113頁●在軟件測試過程中應該應用Pareto原理。Pareto原理告訴我們，測試所發(fā)現的錯誤中的80%很可能是由程序中20%的模塊造成的。因此，應該盡量找出這些可疑的模塊并徹底地測試它們?！駪搹摹靶∫?guī)模”測試開始，逐步過渡到“大規(guī)?！睖y試。通常，首先測試單個程序模塊，進一步的測試重點隨后轉向在集成的模塊簇中尋找錯誤，最后對整個軟件系統(tǒng)進行測試。第21頁/共113頁●窮舉測試是不可能的。在上一小節(jié)已經舉例說明了這個事實，此處不再贅述。這個事實表明，測試只能證明程序中有錯誤，不能證明程序中沒有錯誤。但是，精心設計測試方案，有可能充分覆蓋程序邏輯并發(fā)現大部分程序錯誤?！駷榱诉_到最佳的測試效果，應該由獨立的第三方來從事測試工作。所謂“最佳測試效果”是指用盡可能少的測試方案發(fā)現了盡可能多的程序錯誤。由于在4.2.2小節(jié)中已經講過的原因，創(chuàng)建軟件系統(tǒng)的軟件工程師并不是完成全部測試工作的最佳人選（他們通常主要承擔模塊測試工作）。第22頁/共113頁4.3白盒測試技術

白盒測試方法是按照程序內部預期應有的邏輯測試程序，檢驗程序中的每條執(zhí)行通路是否都能按預定要求正確工作。設計測試方案是測試階段的關鍵技術問題。所謂測試方案包括下述三方面內容：具體的測試目的（例如，要測試的具體功能），應該輸入的測試數據和預期的輸出結果。通常又把測試數據和預期的輸出結果稱為測試用例。不同的測試數據發(fā)現程序錯誤的能力差別很大，為了提高測試效率降低測試成本，應該選用高效的測試數據。因為不可能進行窮盡的測試，選用少量“最有效的”測試數據，做到盡可能完備的測試就更重要了。返回目錄第23頁/共113頁4.3.1邏輯覆蓋邏輯覆蓋是設計白盒測試方案的一種常用技術。通常不可能進行窮盡的測試，因此，有選擇地執(zhí)行程序中某些最有代表性的通路，是用白盒方法測試程序時對窮盡測試惟一可行的替代辦法。所謂邏輯覆蓋，是對一系列測試過程的總稱，這組測試過程逐漸進行越來越完整的通路測試。測試數據執(zhí)行（或稱為覆蓋）程序邏輯的程度可以劃分成哪些不同的等級呢？從覆蓋源程序語句的詳盡程度分析，大致有以下一些不同的覆蓋標準。第24頁/共113頁1.語句覆蓋為了暴露程序中的錯誤，至少每個語句應該執(zhí)行一次。語句覆蓋的含義是，選擇足夠多的測試數據，使被測程序中每個語句至少執(zhí)行一次。

例如，圖4.2是一個被測模塊的流程圖，它的源程序（用PASCAL語言書寫）應該如下：圖4.2

被測試模塊的流程圖

第25頁/共113頁PROCEDUREEXAMPLE（A，B：REAL；VARX：REAL）；BEGINIF（A＞1）AND（B＝0）THENX：＝X／A；IF（A＝2）OR（X＞1）THENX：＝X＋1END；為了使每個語句都執(zhí)行一次，程序的執(zhí)行路徑應該是sacbed，為此只需要輸入下面的測試數據（實際上X可以是任意實數）：A＝2，B＝0，X＝4第26頁/共113頁2.判定覆蓋判定覆蓋又叫分支覆蓋，它的含義是，不僅每個語句必須至少執(zhí)行一次，而且每個判定的每種可能的結果都應該至少執(zhí)行一次，也就是每個判定的每個分支都至少執(zhí)行一次。對于上述例子來說，能夠分別覆蓋路徑sacbed和sabd的兩組測試數據，或者可以分別覆蓋路徑sacbd和sabed的兩組測試數據，都滿足判定覆蓋標準。例如，用下面兩組測試數據就可做到判定覆蓋：Ⅰ.

A＝3，B＝0，X＝3（覆蓋sacbd）Ⅱ.

A＝2，B＝1，X＝1（覆蓋sabed）判定覆蓋比語句覆蓋強，但是對程序邏輯的覆蓋程度仍然不高，例如，上面的測試數據只覆蓋了程序全部路徑的一半。第27頁/共113頁3.條件覆蓋條件覆蓋的含義是，不僅每個語句至少執(zhí)行一次，而且使判定表達式中的每個條件都取到各種可能的結果。圖4.2的例子中共有兩個判定表達式，每個表達式中有兩個條件，為了做到條件覆蓋，應該選取測試數據使得在a點有下述各種結果出現：A＞1，A≤1，B＝0，B≠0

在b點有下述各種結果出現：A＝2，A≠2，X＞1，X≤1第28頁/共113頁只需要使用下面兩組測試數據就可以達到上述覆蓋標準：Ⅰ.A＝2，B＝0，X＝4（滿足A＞1，B＝0，A＝2和X＞1的條件，執(zhí)行路徑sacbed）Ⅱ.A＝1，B＝1，X＝1（滿足A≤1，B≠0，A≠2和X≤1的條件，執(zhí)行路徑sabd）第29頁/共113頁

條件覆蓋通常比判定覆蓋強，因為它使判定表達式中每個條件都取到了兩個不同的結果，判定覆蓋卻只關心整個判定表達式的值。例如，上面兩組測試數據也同時滿足判定覆蓋標準。但是，也可能有相反的情況：雖然每個條件都取到了兩個不同的結果，判定表達式卻始終只取一個值。例如，如果使用下面兩組測試數據，則只滿足條件覆蓋標準并不滿足判定覆蓋標準（第二個判定表達式的值總為真）：Ⅰ.A＝2，B＝0，X＝1（滿足A＞1，B＝0，A＝2和X≤1的條件，執(zhí)行路徑sacbed）Ⅱ.A＝1，B＝1，X＝2（滿足A≤1，B≠0，A≠2和X＞1的條件，執(zhí)行路徑sabed）第30頁/共113頁4.判定/條件覆蓋既然判定覆蓋不一定包含條件覆蓋，條件覆蓋也不一定包含判定覆蓋，自然會提出一種能同時滿足這兩種覆蓋標準的邏輯覆蓋，這就是判定/條件覆蓋。它的含義是，選取足夠多的測試數據，使得判定表達式中的每個條件都取到各種可能的值，而且每個判定表達式也都取到各種可能的結果。對于圖4.2的例子而言，下述兩組測試數據滿足判定/條件覆蓋標準：Ⅰ.A＝2，B＝0，X＝4Ⅱ.A＝1，B＝1，X＝1

但是，這兩組測試數據也就是為了滿足條件覆蓋標準最初選取的兩組數據，因此，有時判定/條件覆蓋也并不比條件覆蓋更強。第31頁/共113頁5.條件組合覆蓋條件組合覆蓋是更強的邏輯覆蓋標準，它要求選取足夠多的測試數據，使得每個判定表達式中條件的各種可能組合都至少出現一次。對于圖4.2的例子，共有八種可能的條件組合，它們是：（1）A＞1，B＝0（2）A＞1，B≠0（3）A≤1，B＝0（4）A≤1，B≠0（5）A＝2，X＞1（6）A＝2，X≤1（7）A≠2，X＞1（8）A≠2，X≤1

和其他邏輯覆蓋標準中的測試數據一樣，條件組合（5）～（8）中的X值是指在程序流程圖第二個判定框（b點）的X值。第32頁/共113頁

下面的四組測試數據可以使上面列出的八種條件組合每種至少出現一次：Ⅰ.A＝2，B＝0，X＝4（針對1，5兩種組合，執(zhí)行路徑sacbed）Ⅱ.A＝2，B＝1，X＝1（針對2，6兩種組合，執(zhí)行路徑sabed）Ⅲ.A＝1，B＝0，X＝2（針對3，7兩種組合，執(zhí)行路徑sabed）Ⅳ.A＝1，B＝1，X＝1（針對4，8兩種組合，執(zhí)行路徑Sabd）第33頁/共113頁

顯然，滿足條件組合覆蓋標準的測試數據，也一定滿足判定覆蓋、條件覆蓋和判定/條件覆蓋標準。因此，條件組合覆蓋是前述幾種覆蓋標準中最強的。但是，滿足條件組合覆蓋標準的測試數據并不一定能使程序中的每條路徑都執(zhí)行到，例如，上述四組測試數據都沒有測試到路徑sacbd。第34頁/共113頁4.3.2控制結構測試另外一類重要的白盒測試技術，是根據程序的控制結構設計測試用例的技術，本節(jié)講述其中一些常用的技術。1.流圖按照程序的控制結構設計測試用例時，往往需要仔細分析程序的控制流。為了突出表現程序的控制流，可以使用流圖（也稱為程序圖）。流圖僅僅描繪程序的控制流程，它完全不表現對數據的具體操作以及分支或循環(huán)的具體條件。第35頁/共113頁

在流圖中用圓表示節(jié)點，一個圓代表一條或多條語句。程序流程圖中一個順序執(zhí)行的處理框序列和一個菱形判定框，可以映射成流圖中的一個節(jié)點。流圖中的箭頭線稱為邊，它和程序流程圖中的箭頭線類似，代表控制流。在流圖中一條邊必須終止于一個節(jié)點，即使這個節(jié)點并不代表任何語句（實際上相當于一個空語句）。由邊和節(jié)點圍成的面積稱為區(qū)域，當計算區(qū)域數時應該包括圖外部未被圍起來的那個區(qū)域。第36頁/共113頁圖4.3舉例說明把程序流程圖映射成流圖的方法。

圖4.3把程序流程圖映射成流圖（a）程序流程圖；（b）流圖第37頁/共113頁

事實上，用任何方式表示的過程設計結果，都可以翻譯成流圖。下面講述基本路徑測試方法時，將把用PDL描述的一個處理過程轉換成流圖。當過程設計結果中包含復合條件時，翻譯成流圖的方法稍微復雜一些。所謂復合條件，就是在判定條件中包含了一個或多個布爾運算符（邏輯OR，AND，NAND，NOR）。在這種情況下，應該把復合條件分解為若干個簡單條件，每個簡單條件對應流圖中的一個節(jié)點。通常把包含條件的節(jié)點稱為判定節(jié)點，從每個判定節(jié)點引出兩條或多條邊。第38頁/共113頁

圖4.4是由包含復合條件的PDL片斷翻譯成的流圖，注意，與復合條件“aORb”對應的節(jié)點有兩個，這兩個節(jié)點分別標記為“a”和“b”。圖4.4

由包含復合條件的PDL映射成的流圖

第39頁/共113頁

基本路徑測試是一種常用的白盒測試技術。使用這種技術設計測試用例時，首先計算被測過程的邏輯復雜度，并依據算出的復雜度定義執(zhí)行路徑的基本集合，從該基本集合導出的測試用例可以保證程序中的每條語句至少被執(zhí)行一次，而且每個判定條件在執(zhí)行時都分別取true（真）和false（假）兩個值。使用基本路徑測試技術設計測試用例的步驟如下：第1步依據過程設計的結果畫出相應的流圖。

2.基本路徑測試第40頁/共113頁

例如，為了測試下列的用PDL描述的求平均值的過程，首先畫出圖4.5所示的流圖。注意，為了正確地畫出流圖，我們把被映射為流圖節(jié)點的PDL語句編了號。圖4.5

求平均值過程的流圖第41頁/共113頁第2步計算流圖的環(huán)形復雜度。環(huán)形復雜度定量度量程序邏輯的復雜程度。畫出描繪程序控制流的流圖之后，可以使用下述三種方法中的任一種來計算環(huán)形復雜度。（1）流圖中的區(qū)域數等于環(huán)形復雜度。（2）流圖G的環(huán)形復雜度V（G）由下式計算：V（G）＝E－N＋2

其中，E是流圖中邊的條數，N是流圖中節(jié)點數。（3）流圖G的環(huán)形復雜度V（G）也可由下式計算：V（G）＝P＋1

其中，P是流圖中判定節(jié)點的數目。例如，使用上述任何一種方法，都可以計算出圖4.5所示流圖的環(huán)形復雜度為6。第42頁/共113頁第3步確定線性獨立路徑的基本集合。所謂線性獨立路徑是指這樣的路徑，該路徑至少引入了程序的一個新處理語句集合或一個新條件，用流圖術語描述，獨立路徑中至少包含一條在定義該路徑之前不曾用過的邊。使用基本路徑測試法設計測試用例時，程序的環(huán)形復雜度決定了程序中獨立路徑的數量，而且這個數是確保程序中所有語句至少被執(zhí)行一次所需要的測試數量的上限。第43頁/共113頁

第4步設計出可強制執(zhí)行基本集合中每條路徑的測試用例。應該選取測試數據，使得在測試每條路徑時都適當地設置好了各個判定節(jié)點的條件。在測試過程中，執(zhí)行每個測試用例并把程序實際輸出的結果與預期結果相比較。一旦執(zhí)行完全部測試用例，就可以確保程序中所有語句都至少被執(zhí)行了一次，而且每個判定條件都分別取過true值和false值。應該注意，某些獨立路徑（例如，本例中的路徑1和路徑3）不能以獨立的方式測試，也就是說，程序的正常流程不能形成獨立執(zhí)行該路徑所需要的數據組合（例如，為了執(zhí)行本例中的路徑1，需要滿足條件total.valid＞0，然而獨立執(zhí)行路徑1無法滿足這個條件）。在這種情況下，這些路徑必須作為另一個路徑的一部分來測試。第44頁/共113頁3.條件測試盡管基本路徑測試技術簡單而且高效，但是僅有這種技術仍然不夠，還需要同時使用其他控制結構測試技術，才能進一步提高白盒測試的質量。用條件測試技術設計出的測試用例，能夠檢查程序模塊中包含的邏輯條件。一個簡單條件是一個布爾變量或一個關系表達式，在布爾變量或關系表達式之前還可能有一個NOT（“┐”）算符。關系表達式的形式如下：E1＜關系算符＞E2

其中，E1和E2是算術表達式，而＜關系算符＞是下列算符之一：“＜”，“≤”，“＝”，“≠”，“＞”或“≥”。復合條件由兩個或多個簡單條件、布爾算符和括弧組成。布爾算符有OR（“｜”），AND（“&”）和NOT（“┐”）。不包含關系表達式的條件稱為布爾表達式。第45頁/共113頁

因此，一個條件中可能包含布爾變量、布爾算符、布爾括?。ɡㄗ『唵螚l件或復合條件）、關系算符及算術表達式等成分。如果條件不正確，則至少組成該條件的一個成分不正確。因此，條件錯誤的類型如下：●布爾變量錯。●布爾算符錯（布爾算符不正確，遺漏布爾算符或有多余的布爾算符）。●布爾括弧錯?！耜P系算符錯?！袼阈g表達式錯。

第46頁/共113頁

條件測試方法著重測試程序中的每個條件，這種測試方法有下述兩個優(yōu)點：（1）容易度量條件的測試覆蓋率；（2）程序中條件的測試覆蓋率可以指導附加測試的設計。條件測試的目的，不僅僅是檢測程序條件中的錯誤，而且也檢測程序中其他類型的錯誤。如果程序P的測試集能有效地檢測P中條件的錯誤，則它很可能也可以有效地檢測P中的其他錯誤。此外，如果一個測試策略對檢測條件錯誤是有效的，則該策略很可能對檢測程序的其他錯誤也是有效的。

第47頁/共113頁

軟件工程師們已經提出了許多條件測試策略。分支測試可能是最簡單的條件測試策略。對于復合條件C來說，C的真分支和假分支以及C中的每個簡單條件，都應該至少執(zhí)行一次。域測試要求對一個關系表達式執(zhí)行三個或四個測試。對于形式為E1＜關系算符＞E2的關系表達式來說，需要三個測試分別使E1的值大于、等于或小于E2的值。如果＜關系算符＞錯誤而E1和E2正確，則這三個測試能夠發(fā)現關系算符的錯誤。為了發(fā)現E1和E2中的錯誤，讓E1值大于（或小于）E2值的測試數據應該使這兩個值之間的差別盡可能小。第48頁/共113頁

在上述種種條件測試技術的基礎上，K.C.Tai提出了一種被稱為BRO（BranchandRelationalOperator）測試的條件測試策略。如果在條件中所有布爾變量和關系算符都只出現一次而且沒有公共變量，則BRO測試保證能發(fā)現該條件中的分支錯和關系算符錯。

BRO測試利用條件C的條件約束來設計測試用例。包含n個簡單條件的條件C的條件約束定義為（D1，D2，…，Dn）其中Di（0＜i≤n）表示條件C中第i個簡單條件的輸出約束。如果在條件C的一次執(zhí)行過程中，C中每個簡單條件的輸出都滿足D中對應的約束，則稱C的這次執(zhí)行覆蓋了C的條件約束D。對于布爾變量B來說，B的輸出約束指出，B必須是真（t）或假（f）。類似地，對于關系表達式來說，用符號＞，＝和＜指定表達式的輸出約束。第49頁/共113頁4.循環(huán)測試循環(huán)是絕大多數軟件算法的基礎，但是，在測試軟件時卻往往未對循環(huán)結構進行足夠的測試。循環(huán)測試是一種白盒測試技術，它專注于測試循環(huán)結構的有效性。圖4.6

三種循環(huán)

在結構化的程序中通常只有三種循環(huán)，分別是簡單循環(huán)、串接循環(huán)和嵌套循環(huán)，如圖4.6所示。第50頁/共113頁

下面分別討論不同類型循環(huán)的測試方法。（1）簡單循環(huán)應該使用下列測試集來測試簡單循環(huán)，其中n是允許通過循環(huán)的最大次數?！裉^循環(huán)?！裰煌ㄟ^循環(huán)一次?！裢ㄟ^循環(huán)兩次?！裢ㄟ^循環(huán)m次，其中m＜n－1?！裢ㄟ^循環(huán)n－1，n，n＋1次。第51頁/共113頁（2）嵌套循環(huán)如果把簡單循環(huán)的測試方法直接應用到嵌套循環(huán)，可能的測試數就會隨嵌套層數的增加按幾何級數增長，這會導致不切實際的測試數目。B.Beizer提出了一種能減少測試數的方法?！駨淖顑葘友h(huán)開始測試，把所有其他循環(huán)都設置為最小值?！駥ψ顑葘友h(huán)使用簡單循環(huán)測試方法，而使外層循環(huán)的迭代參數（例如，循環(huán)計數器）取最小值，并為越界值或非法值增加一些額外的測試?！裼蓛认蛲?，對下一個循環(huán)進行測試，但保持所有其他外層循環(huán)為最小值，其他嵌套循環(huán)為“典型”值?！窭^續(xù)進行下去，直到測試完所有循環(huán)。第52頁/共113頁（3）串接循環(huán)如果串接循環(huán)的各個循環(huán)都彼此獨立，則可以使用前述的測試簡單循環(huán)的方法來測試串接循環(huán)。但是，如果兩個循環(huán)串接，而且第一個循環(huán)的循環(huán)計數器值是第二個循環(huán)的初始值，則這兩個循環(huán)并不是獨立的。當循環(huán)不獨立時，建議使用測試嵌套循環(huán)的方法來測試串接循環(huán)。第53頁/共113頁4.4黑盒測試技術

黑盒測試著重檢驗程序的功能是否滿足對它的需求，也就是說，黑盒測試讓軟件工程師設計出能充分檢查程序所有功能需求的輸入條件集。黑盒測試技術并不能取代白盒測試技術，它是與白盒測試技術互補的方法。黑盒測試很可能發(fā)現白盒測試不易發(fā)現的其他不同類型的錯誤。確切地說，黑盒測試力圖發(fā)現下述類型的錯誤：●程序功能不正確或遺漏了用戶需要的功能；●界面錯誤；●數據結構錯誤或外部數據庫訪問錯誤；●性能達不到要求；●初始化和終止錯誤。通常，白盒測試在測試過程的早期階段進行，而黑盒測試則主要用在測試過程的后期。黑盒測試故意不考慮程序的控制結構，而把注意力集中于信息域。返回目錄第54頁/共113頁設計黑盒測試用例時應該仔細考慮下述問題：●怎樣測試程序功能的有效性?●哪些類型的輸入可構成高效的測試用例?●程序是否對特定的輸入值特別敏感?●怎樣劃定數據類的邊界?●系統(tǒng)能夠承受什么樣的數據率和數據量?●數據的特定組合將對系統(tǒng)運行產生什么影響?

第55頁/共113頁

應用黑盒測試技術可以設計出滿足下述標準的測試用例集：1.所設計出的測試用例能夠減少為達到合理測試而需要設計的附加測試用例的數目；2.所設計出的測試用例能夠告訴我們，是否存在某些類型的錯誤，而不是僅僅指出與特定測試相關的錯誤是否存在。第56頁/共113頁4.4.1等價劃分等價劃分是一種黑盒測試技術，這種方法首先把程序的輸入域劃分成若干個數據類，然后根據劃分出的輸入數據種類設計測試用例。一個理想的測試用例能夠獨自發(fā)現一類錯誤（例如，對所有字符數據的處理都不正確）。以前曾經講過，窮盡的黑盒測試（即使用所有有效的和無效的輸入數據測試程序）通常是不現實的。因此，只能選取少量最有代表性的輸入數據作為測試數據，以便用較小的代價測試出較多的程序錯誤。第57頁/共113頁

什么樣的輸入數據是最有代表性的呢?如果把所有可能的輸入數據（既包括有效的輸入數據也包括無效的輸入數據）劃分成若干個等價類，則可以合理地做出下述假定：每類數據中的一個典型值在測試中的作用與這一類中所有其他值的作用相同。因此，可以從每個等價類中只取一組數值作為測試數據。這樣選取的測試數據最有代表性，最可能發(fā)現程序中的錯誤。事實上，等價劃分法力圖設計出一個能發(fā)現若干類錯誤的測試用例，從而減少必須設計的測試用例的數目。第58頁/共113頁

使用等價劃分法設計測試方案首先需要劃分輸入數據的等價類，為此需要研究程序的功能說明，從而確定輸入數據的有效等價類和無效等價類。在確定輸入數據的等價類時常常還需要分析輸出數據的等價類，以便根據輸出數據的等價類導出對應的輸入數據等價類。第59頁/共113頁

劃分等價類需要經驗，下述幾條啟發(fā)式規(guī)則可能有助于等價類的劃分：●如果規(guī)定了輸入值的范圍，則可劃分出一個有效的等價類（輸入值在此范圍內），兩個無效的等價類（輸入值小于最小值或大于最大值）；●如果規(guī)定了輸入數據的個數，則類似地也可以劃分出一個有效的等價類和兩個無效的等價類；●如果規(guī)定了輸入數據的一組值，而且程序對不同輸入值做不同處理，則每個允許的輸入值是一個有效的等價類，此外還有一個無效的等價類（任一個不允許的輸入值）；●如果規(guī)定了輸入數據必須遵循的規(guī)則，則可以劃分出一個有效的等價類（符合規(guī)則）和若干個無效的等價類（從各種不同角度違反規(guī)則）；●如果規(guī)定了輸入數據為整型，則可以劃分出正整數、零和負整數等三個有效類；●如果程序的處理對象是表格，則應該使用空表，以及含一項或多項的表。第60頁/共113頁

以上列出的啟發(fā)式規(guī)則只是測試時可能遇到的情況中的很小一部分，實際情況千變萬化，根本無法一一列出。為了正確劃分等價類，一是要注意積累經驗，二是要正確分析被測程序的功能。此外，在劃分無效的等價類時還必須考慮編譯程序的檢錯功能，一般說來，不需要設計測試數據用來暴露編譯程序肯定能發(fā)現的錯誤。最后說明一點，上面列出的啟發(fā)式規(guī)則雖然都是針對輸入數據說的，但是其中絕大部分也同樣適用于輸出數據。第61頁/共113頁

劃分出等價類以后，根據等價類設計測試方案時主要使用下面兩個步驟：（1）設計一個新的測試方案以盡可能多地覆蓋尚未被覆蓋的有效等價類，復重這一步驟直到所有有效等價類都被覆蓋為止；（2）設計一個新的測試方案，使它覆蓋一個而且只覆蓋一個尚未被覆蓋的無效等價類，重復這一步驟直到所有無效等價類都被覆蓋為止。注意，通常程序發(fā)現一類錯誤后就不再檢查是否還有其他錯誤，因此，應該使每個測試方案只覆蓋一個無效的等價類。第62頁/共113頁4.4.2邊界值分析經驗表明，處理邊界情況時程序最容易發(fā)生錯誤。例如，許多程序錯誤出現在下標、純量、數據結構和循環(huán)等等的邊界附近。因此，設計使程序運行在邊界情況附近的測試方案，暴露出程序錯誤的可能性更大一些。使用邊界值分析方法設計測試方案首先應該確定邊界情況，這需要經驗和創(chuàng)造性，通常輸入等價類和輸出等價類的邊界，就是應該著重測試的程序邊界情況。選取的測試數據應該剛好等于、剛剛小于和剛剛大于邊界值。也就是說，按照邊界值分析法，應該選取剛好等于、稍小于和稍大于等價類邊界值的數據作為測試數據，而不是選取每個等價類內的典型值或任意值作為測試數據。通常設計測試方案時總是聯合使用等價劃分和邊界值分析兩種技術。第63頁/共113頁4.4.3錯誤推測錯誤推測法在很大程度上依靠測試人員的直覺和經驗進行。它的基本做法是，列舉出程序中可能有的錯誤和容易發(fā)生錯誤的特殊情況，并且根據它們設計測試方案。對于程序中容易出錯的情況已有一些經驗總結出來，例如，輸入數據值為零或輸出數據值為零往往容易發(fā)生錯誤；如果輸入或輸出的數目允許變化（例如，被檢索的或程序生成的表的項數），則輸入或輸出的數目為0和1的情況（例如，表為空或只有一項）是容易出錯的情況。還應該仔細分析程序規(guī)格說明書，注意找出其中的遺漏或省略的部分，以便設計相應的測試方案，檢測程序員對這些部分的處理是否正確。

第64頁/共113頁

此外，經驗還告訴我們，在一段程序中已經發(fā)現的錯誤數目往往和尚未發(fā)現的錯誤數成正比。例如，在IBMOS／370操作系統(tǒng)中，用戶發(fā)現的全部錯誤的47%只與該系統(tǒng)4%的模塊有關。這個事實再次證實了本章4.2.4小節(jié)提到的Pareto原理。因此，在進一步測試時應該著重測試那些已經發(fā)現了有較多錯誤的程序段。第65頁/共113頁4.5測試策略

軟件測試策略把設計測試用例的方法集成到一系列經過周密計劃的測試步驟中去，從而大大提高軟件測試的效果，使得軟件開發(fā)獲得成功。任何測試策略都必須與測試計劃、測試用例設計、測試執(zhí)行以及測試結果數據的收集與分析緊密地結合在一起。4.5.1測試步驟除非是測試一個小程序，否則一開始就把整個系統(tǒng)作為一個單獨的實體來測試是不現實的。與開發(fā)過程類似，測試過程也必須分步驟進行，后一個步驟在邏輯上是前一個步驟的繼續(xù)。返回目錄第66頁/共113頁

從過程的觀點考慮測試，在軟件工程環(huán)境中的測試過程，實際上是順序進行的四個步驟的序列。最開始，著重測試每個單獨的模塊，以確保它作為一個單元來說功能是正確的。因此，這種測試稱為單元測試。單元測試大量使用白盒測試技術，檢查模塊控制結構中的特定路徑，以確保做到完全覆蓋并發(fā)現最大數量的錯誤。接下來，必須把模塊裝配（即集成）在一起形成完整的軟件包。在裝配的同時進行測試，因此稱為集成測試。集成測試同時解決程序驗證和程序構造這兩個問題。在集成過程中最常用的是黑盒測試用例設計技術，當然，為了保證覆蓋主要的控制路徑，也可能使用一定數量的白盒測試。在軟件集成完成之后，還需要進行一系列高級測試。必須測試在需求分析階段確定下來的確認標準，確認測試是對軟件滿足所有功能的、行為的和性能的需求的最終保證。在確認測試過程中僅使用黑盒測試技術。第67頁/共113頁4.5.2單元測試通常，單元測試和編碼屬于軟件工程過程的同一個階段。在編寫出源程序代碼并通過了編譯程序的語法檢查之后，可以應用人工測試和計算機測試這樣兩種類型的測試，完成單元測試工作。這兩種類型的測試各有所長，互相補充。下面講述和單元測試有關的問題。1.單元測試的重點在單元測試期間應該著重從下述五個方面對模塊進行測試：模塊接口，局部數據結構，重要的執(zhí)行通路，出錯處理通路，影響上述各方面特性的邊界條件。第68頁/共113頁

（1）模塊接口（2）局部數據結構

（3）重要的執(zhí)行通路（4）出錯處理通路（5）邊界條件第69頁/共113頁2.代碼審查人工測試源程序可以由編寫者本人非正式地進行，也可以由審查小組正式進行。后者稱為代碼審查，它是一種非常有效的程序驗證技術，對于典型的程序來說，可以查出30%～70%的邏輯設計錯誤和編碼錯誤。審查小組最好由下述四人組成：●組長，他應該是一個很有能力的程序員，而且沒有直接參與這項工程；●程序的設計者；●程序的編寫者；●程序的測試者。如果一個人既是程序的設計者又是編寫者，或既是編寫者又是測試者，則審查小組中應該再增加一個程序員。第70頁/共113頁

審查之前，小組成員應該先研究設計說明書，力求理解這個設計。為了幫助理解，可以先由設計者扼要地介紹他的設計。在審查會上由程序的編寫者解釋他是怎樣用程序代碼實現這個設計的，通常是逐個語句地講述程序的邏輯，小組其他成員仔細傾聽他的講解，并力圖發(fā)現其中的錯誤。當發(fā)現錯誤時由組長記錄下來，審查會繼續(xù)進行（審查小組的任務是發(fā)現錯誤而不是改正錯誤）。審查會還有另外一種常見的進行方法（稱為預排）：由一個人扮演“測試者”，其他人扮演“計算機”。會前測試者準備好測試方案，會上由扮演計算機的成員模擬計算機執(zhí)行被測試的程序。當然，由于人執(zhí)行程序速度極慢，因此測試數據必須簡單，測試方案的數目也不能過多。但是，測試方案本身并不十分關鍵，它只起一種促進思考引起討論的作用。在大多數情況下，通過向程序員提出關于他的程序的邏輯和他編寫程序時所做的假設的疑問，可以發(fā)現的錯誤比由測試方案直接發(fā)現的錯誤還多。第71頁/共113頁

代碼審查比計算機測試優(yōu)越的是：一次審查會上可以發(fā)現許多錯誤；用計算機測試的方法發(fā)現錯誤之后，通常需要先改正這個錯誤才能繼續(xù)測試，因此錯誤是一個一個地發(fā)現并改正的。也就是說，采用代碼審查的方法可以減少系統(tǒng)驗證的總工作量。實踐表明，對于查找某些類型的錯誤來說，人工測試比計算機測試更有效；對于其他類型的錯誤來說則剛好相反。因此，人工測試和計算機測試是互相補充，相輔相成的，缺少其中任何一種方法都會使查找錯誤的效率降低。第72頁/共113頁3.驅動程序和存根程序模塊并不是一個獨立的程序，因此必須為每個單元測試開發(fā)驅動軟件和（或）存根軟件。通常驅動程序也就是一個“主程序”，它接收測試數據，把這些數據傳送給被測試的模塊，并且印出有關的結果。存根程序代替被測試的模塊所調用的模塊。因此存根程序也可以稱為“虛擬子程序”。它使用被它代替的模塊的接口，可能做最少量的數據操作，印出對入口的檢驗或操作結果，并且把控制歸還給調用它的模塊。第73頁/共113頁圖4.7

正文加工系統(tǒng)的層次圖

例如，圖4.7是一個正文加工系統(tǒng)的部分層次圖，假定要測試其中編號為3.0的關鍵模塊——正文編輯模塊。第74頁/共113頁

因為正文編輯模塊不是一個獨立的程序，所以需要有一個測試驅動程序來調用它。這個驅動程序說明必要的變量，接收測試數據——字符串，并且設置正文編輯模塊的編輯功能。因為在原來的軟件結構中，正文編輯模塊通過調用它的下層模塊來完成具體的編輯功能，所以需要有存根程序簡化地模擬這些下層模塊。為了簡單起見，測試時可以設置的編輯功能只有修改（CHANGE）和添加（APPEND）兩種，用控制變量CFUNCT標記要求的編輯功能，而且只用一個存根程序模擬正文編輯模塊的所有下層模塊。下面是用偽碼書寫的存根程序和驅動程序。第75頁/共113頁4.5.3集成測試集成測試是測試和組裝軟件的系統(tǒng)化技術，在把模塊按照設計要求組裝起來的同時進行測試，主要目標是發(fā)現與接口有關的問題。例如，數據穿過接口時可能丟失；一個模塊對另一個模塊可能有由于疏忽而造成的有害影響；把子功能組合起來可能不產生預期的主功能；個別看來是可以接受的誤差可能積累到不能接受的程度；全程數據結構可能有問題等等。不幸的是，可能發(fā)生的接口問題多得不勝枚舉。由模塊組裝成程序時有兩種方法。一種方法是先分別測試每個模塊，再把所有模塊按設計要求放在一起結合成所要的程序，這種方法稱為非漸增式測試方法；另一種方法是把下一個要測試的模塊同已經測試好的那些模塊結合起來進行測試，測試完以后再把下一個應該測試的模塊結合進來測試。這種每次增加一個模塊的方法稱為漸增式測試。第76頁/共113頁

非漸增式測試一下子把所有模塊放在一起，并把整個程序作為一個整體來進行測試，測試者面對的場面往往混亂不堪。測試時會遇到許許多多的錯誤，改正錯誤更是極端困難，因為在龐大的程序中想要診斷定位一個錯誤是非常復雜非常困難的。而且一旦改正一個錯誤之后，馬上又會遇到新的錯誤，這個過程會繼續(xù)下去，看起來好像永遠也沒有盡頭。漸增式測試與“一步到位”的非漸增式測試相反，把程序劃分成小段來構造和測試，在這個過程中比較容易分離和改正錯誤；對接口可能進行更徹底的測試；而且可以使用系統(tǒng)化的測試方法。因此，在進行集成測試時普遍使用漸增式測試方法。下面討論兩種不同的漸增式集成策略。第77頁/共113頁1.自頂向下集成自頂向下的集成（結合）方法是一個日益為人們廣泛采用的組裝軟件的途徑。從主控制模塊（主程序）開始，沿著軟件的控制層次向下移動，從而逐漸把各個模塊結合起來。在把附屬于（以及最終附屬于）主控制模塊的那些模塊組裝到軟件結構中去時，或者使用深度優(yōu)先的策略，或者使用寬度優(yōu)先的策略。

第78頁/共113頁圖4.8

自頂向下結合

參看圖4.8，深度優(yōu)先的結合方法先組裝在軟件結構的一條主控制通路上的所有模塊。選擇一條主控制通路取決于應用的特點，并且有很大任意性。

例如，選取左通路，首先結合模塊M1、M2和M5；其次，M8或M6（如果為了使M2具有適當功能需要M6的話）將被結合進來。然后構造中央的和右側的控制通路。而寬度優(yōu)先的結合方法，是沿軟件結構水平地移動，把處于同一個控制層次上的所有模塊組裝起來。對于圖4.8來說，首先結合模塊M2、M3和M4（代替存根程序S4）。然后結合下一個控制層次中的模塊M5、M6和M7；如此繼續(xù)進行下去，直到所有模塊都被結合進來為止。第79頁/共113頁2.自底向上集成自底向上測試從“原子”模塊（即在軟件結構最低層的模塊）開始組裝和測試。因為是從底部向上結合模塊，總能得到需要的下層模塊處理功能，所以不需要存根程序。

第80頁/共113頁圖4.9自底向上結合

首先把模塊組合成簇1、簇2和簇3，使用驅動程序（圖中用虛線方框表示）對每個子功能簇進行測試。簇1和簇2中的模塊附屬于模塊Ma，去掉驅動程序D1和D2，把這兩個簇直接同Ma連接起來。類似地，在和模塊Mb結合之前去掉簇3的驅動程序D3。最終Ma和Mb這兩個模塊都與模塊Mc結合起來。圖4.9描繪了自底向上的結合過程。

第81頁/共113頁3.兩種集成測試策略的比較一般說來，一種方法的優(yōu)點正好對應于另一種方法的缺點。自頂向下測試方法的主要優(yōu)點是不需要測試驅動程序，能夠在測試階段的早期實現并驗證系統(tǒng)的主要功能，而且能在早期發(fā)現上層模塊的接口錯誤。自頂向下測試方法的主要缺點是需要存根程序，可能遇到與此相聯系的測試困難，低層關鍵模塊中的錯誤發(fā)現較晚，而且用這種方法在早期不能充分展開人力?？梢钥闯?，自底向上測試方法的優(yōu)缺點與上述自頂向下測試方法的優(yōu)缺點剛好相反。

第82頁/共113頁

在測試實際的軟件系統(tǒng)時，應該根據軟件的特點以及工程進度安排，選用適當的測試策略。一般說來，純粹自頂向下或純粹自底向上的策略可能都不實用，人們在實踐中創(chuàng)造出許多混合策略：改進的自頂向下測試方法

混合法

第83頁/共113頁

在進行集成測試的時候，測試人員應該盡早識別出被測程序中的關鍵模塊。所謂關鍵模塊是指具有下述一個或多個特征的模塊：（1）與多項軟件需求有關；（2）含有高層控制功能（模塊位于程序結構的較高層次）；（3）模塊本身是復雜的或容易出錯的（可以用環(huán)形復雜度指示模塊的復雜程度）；（4）有確定的性能需求。在集成測試期間應該盡可能早地測試關鍵模塊，此外，回歸測試也應該著重測試關鍵模塊的功能。第84頁/共113頁4.回歸測試在集成測試期間，每當一個新模塊作為被測程序的一部分加進來的時候，軟件就發(fā)生了變化：可能建立了新的數據流路徑，也可能出現了新的I／O操作或者激活了新的控制邏輯。這些變化有可能使原來正常工作的程序功能出現問題。在集成測試范疇中，所謂回歸測試是指重新執(zhí)行已經做過的測試的某個子集，以保證上述這些變化沒有帶來非預期的副作用。更廣義地說，任何成功的測試都會發(fā)現錯誤，而且必須改正所發(fā)現的錯誤。每當改正軟件錯誤的時候，軟件配置的某些成分（程序、文檔或數據）也被修改了?；貧w測試就是用于保證由于測試或其他原因引起的軟件變化，不會導致非預期的行為或額外錯誤的測試活動。

第85頁/共113頁4.5.4確認測試確認測試也稱為驗收測試，它的目標是驗證軟件的有效性。如果軟件的功能和性能如同用戶所合理地期待的那樣，那么，軟件就是有效的。需求分析階段產生的軟件需求規(guī)格說明，準確地描述了用戶對軟件的合理期望，因此是軟件有效性的標準，也是進行確認測試的基礎。第86頁/共113頁1.確認測試的范圍確認測試必須有用戶積極參與，或者以用戶為主進行。用戶應該參加設計測試方案，使用用戶接口輸入測試數據并且分析評價測試的輸出結果。為了使用戶能夠積極主動地參與確認測試，特別是為了使用戶能有效地使用這個系統(tǒng)，通常在驗收之前由開發(fā)部門對用戶進行培訓。確認測試一般使用黑盒測試法。應該仔細設計測試計劃和測試過程，測試計劃包括要進行的測試的種類和進度安排，測試過程規(guī)定用來檢驗軟件是否與需求一致的測試方案。通過測試要保證軟件能滿足所有功能要求，能達到每個性能要求，文檔資料是準確而完整的，此外，還應該保證軟件能滿足其他預定的要求（例如，可移植性、兼容性和可維護性等）。第87頁/共113頁

確認測試有兩種可能的結果：●功能和性能與用戶要求一致，軟件是可以接受的；●功能或性能與用戶的要求有差距。在確認測試期間發(fā)現的問題，往往和需求分析階段分析員所犯的錯誤有關，而且這類問題的涉及面通常比較廣，因此解決起來也比較困難。為了確定解決確認測試過程中發(fā)現的軟件缺陷或錯誤的策略，軟件工程師通常需要和用戶充分協商。第88頁/共113頁2.復查軟件配置確認測試的一項重要任務是復查軟件配置。復查的目的是，保證軟件配置的所有成分都齊全，各方面的質量都符合要求，文檔內容與程序完全一致，具有軟件維護階段所必須的細節(jié)，而且全部文檔都已經編好目錄。除了按軟件開發(fā)合同規(guī)定的內容和要求，由人工審查軟件配置之外，在確認測試的過程中還應該嚴格遵循用戶手冊以及其他操作程序，以便檢驗這些手冊的完整性和正確性。必須仔細記錄測試期間發(fā)現的遺漏或錯誤，并且適當地補充和改正。第89頁/共113頁3.Alpha測試和Beta測試如果軟件是為一個客戶開發(fā)的，則可以進行一系列驗收測試以便用戶確認所有需求都已滿足了。驗收測試是由最終用戶而不是系統(tǒng)的開發(fā)者進行的。事實上，驗收測試可以持續(xù)幾個星期或幾個月，因此可以發(fā)現隨著時間流逝可能會降低系統(tǒng)質量的累積錯誤。如果一個軟件是為許多客戶開發(fā)的（例如，向大眾出售的盒裝軟件產品），那么讓每個客戶都進行正式的驗收測試是不現實的。在這種情況下，絕大多數軟件開發(fā)商都使用被稱為Alpha測試和Beta測試的過程，來發(fā)現那些看起來只有最終用戶才能發(fā)現的錯誤。第90頁/共113頁Alpha測試由用戶在開發(fā)者的場所進行，并且在開發(fā)者對用戶的“指導”下進行測試。開發(fā)者負責記錄錯誤和使用中遇到的問題?？傊珹lpha測試是在受控的環(huán)境中進行的。

Beta測試由軟件的最終用戶們在一個或多個客戶場所進行。與Alpha測試不同，開發(fā)者通常不在Beta測試的現場，因此，Beta測試是軟件在開發(fā)者不能控制的環(huán)境中的“真實”應用。用戶記錄下在Beta測試過程中遇到的一切問題（真實的或想象的），并且定期把這些問題報告給開發(fā)者。接收到Beta測試期間報告的問題之后，軟件開發(fā)者對產品進行修改，并準備向全體客戶發(fā)布最終的軟件產品。第91頁/共113頁4.6調試

僅就測試而言，它的目標是發(fā)現軟件中的錯誤，但是，發(fā)現錯誤并不是我們的最終目的。軟件工程的根本目標，是開發(fā)出高質量的完全符合用戶需要的軟件產品，因此，通過測試發(fā)現軟件錯誤之后還必須診斷并改正軟件錯誤，這就是調試（也稱為糾錯）的任務。調試作為成功的測試的后果而出現，也就是說，調試是在測試發(fā)現錯誤之后排除錯誤的過程。雖然調試可以而且應該是一個有序的過程，但是在很大程度上它仍然是一項技巧。軟件工程師在評估測試結果時，往往僅面對著軟件問題的癥狀，也就是說，錯誤的外部表現和它的內在原因之間可能并沒有明顯的聯系。調試就是把癥狀和原因聯系起來的尚未被人很好理解的智力過程。返回目錄第92頁/共113頁

調試不是測試，但是它與測試關系密切，它總是發(fā)生在測試之后。如圖4.10所示，調試過程從執(zhí)行一個測試用例開始，評估測試結果，如果發(fā)現實際結果與預期結果不一致，則這種不一致就是一個癥狀，它表明在軟件中存在著隱藏的問題。調試過程試圖找出產生癥狀的原因，并且改正軟件錯誤。圖4.10

調試過程

4.6.1調試過程第93頁/共113頁4.6.2調試途徑無論采用什么方法，調試的根本目標都是尋找出現軟件錯誤的原因并正確地改正。這個目標是通過把系統(tǒng)的評估、直覺和運氣結合起來實現的。常見的調試途徑有蠻干法、回溯法和原因排除法等三種方法1.蠻干法2.回溯法3.原因排除法上述每一種方法都可以使用調試工具輔助完成，但是工具并不能代替對全部設計文檔和源程序的仔細評估。

第94頁/共113頁

一旦找到錯誤就必須改正它，但是，前面已經提醒過，改正一個錯誤可能引入更多的其他錯誤，以至“得不償失”。因此，在動手改正軟件錯誤之前，每個軟件工程師都應該仔細考慮下述三個問題：●是否同樣的錯誤也存在于程序的其他地方?在許多情況下，一個程序錯誤是由錯誤的邏輯思維模式引起的，而這種邏輯思維模式也可能用在別的地方。仔細分析這種邏輯模式，可能會發(fā)現其他錯誤?！駥⒁M行的修改可能會引入的“下一個錯誤”是什么？在改正錯誤之前應該仔細研究源程序（最好也研究設計文檔），以評估邏輯和數據結構的耦合程度。如果所要做的修改位于程序的高耦合段中，則在修改時必須特別小心謹慎?！駷榉乐菇窈蟪霈F類似的錯誤，應該做什么？如果我們不僅修改了軟件產品還改進了軟件過程，則不僅排除了現有程序中的錯誤，還避免了今后在程序中可能出現的錯誤。第95頁/共113頁4.7軟件可靠性4.7.1基本概念1.軟件可靠性的定義對于軟件可靠性有許多不同的定義，其中多數人承認的一個定義是：軟件可靠性是程序在給定的時間間隔內，按照規(guī)格說明書的規(guī)定成功地運行的概率。在上述定義中包含的隨機變量是時間間隔。顯然，隨著運行時間的增加，運行時遇到程序錯誤的概率也將增加，即可靠性隨著給定的時間間隔的加大而減少。根據IEEE的定義，術語“錯誤”的含義是由開發(fā)人員造成的軟件差錯，而術語“故障”的含義是由錯誤引起軟件的不正確行為。在下面的論述中，我們將按照IEEE規(guī)定的含義使用這兩個術語。返回目錄第96頁/共113頁2.軟件的可用性通常用戶也很關注軟件系統(tǒng)可以使用的程度。一般說來，對于任何其故障是可以修復的系統(tǒng)，都應該同時使用可靠性和可用性衡量它的優(yōu)劣程度。軟件可用性的一個定義是：軟件可用性是程序在給定的時間點，按照規(guī)格說明書的規(guī)定，成功地運行的概率?？煽啃院涂捎眯灾g的主要差別是，可靠性意味著在0到t這段時間間隔內系統(tǒng)沒有失效，而可用性只意味著在時刻t，系統(tǒng)是正常運行的。因此，如果在時刻t系統(tǒng)是可用的，則有下述種種可能：在0到t這段時間內，系統(tǒng)一直沒失效（可靠）；在這段時間內失效了一次，但是又修復了；在這段時間內失效了兩次修復了兩次；……

第97頁/共113頁

如果在一段時間內，軟件系統(tǒng)故障停機時間分別為td1，td2…，正常運行時間分別為tu1，tu2，…，則系統(tǒng)的穩(wěn)態(tài)可用性為：（4.1）其中Tup＝∑tui，Tdown＝∑tdi

第98頁/共113頁

如果引入系統(tǒng)平均無故障時間MTTF和平均維修時間MTTR的概念，則（4.1）式可以變成

（4.2）平均維修時間MTTR是修復一個故障平均需要用的時間，它取決于維護人員的技術水平和對系統(tǒng)的熟悉程度，也和系統(tǒng)的可維護性有重要關系，本書下一章將討論軟件維護問題。平均無故障時間MTTF是系統(tǒng)按規(guī)格說明書規(guī)定成功地運行的平均時間，它主要取決于系統(tǒng)中潛伏的錯誤的數目，因此和測試的關系十分密切。第99頁/共113頁4.7.2估算平均無故障時間的方法軟件的平均無故障時間MTTF是一個重要的質量指標，往往作為對軟件的一項要求，由用戶提出來。為了估算MTTF，首先引入一些有關的量。1.符號在估算MTTF的過程中使用下述符號表示有關的數量：

ET——測試之前程序中錯誤總數；

IT——程序長度（機器指令總數）；

τ——測試（包括調試）時間；

Ed（τ）——在0至τ期間發(fā)現的錯誤數；

Ec（τ）——在0至τ期間改正的錯誤數。第100頁/共113頁2.基本假定根據經驗數據，可以作出下述假定：（1）在類似的程序中，單位長度里的錯誤數ET／IT近似為常數。美國的一些統(tǒng)計數字表明，通常0.5×10－2≤ET／IT≤2×10－2

也就是說，在測試之前每1000條指令中大約有5～20個錯誤。第101頁/共113頁

（2）失效率正比于軟件中剩余的（潛藏的）錯誤數，而平均無故障時間MTTF與剩余的錯誤數成反比。此外，為了簡化討論，假設發(fā)現的每一個錯誤都立即正確地改正了（即，調試過程沒有引入新的錯誤）。因此Ec（τ）＝Ed（τ）剩余的錯誤數為Er（τ）＝ET－Ec（τ）（4.3）單位長度程序中剩余的錯誤數為εr（τ）＝ET／IT－Ec（τ）／IT

第102頁/共113頁3.估算平均無故障時間經驗表明，平均無故障時間與單位長度程序中剩余的錯誤數成反比，即（4.5）其中K為常數，它的值應該根據經驗選取。美國的一些統(tǒng)計數字表明，K的典型值是200