第結(jié)構(gòu)化實(shí)現(xiàn)

會計(jì)學(xué)1第結(jié)構(gòu)化實(shí)現(xiàn)

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

第1頁/共113頁4.1編

碼4.2軟件測試概述4.3白盒測試技術(shù)4.4黑盒測試技術(shù)4.5測試策略4.6調(diào)試4.7軟件可靠性4.8小結(jié)第2頁/共113頁4.1編

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

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

第4頁/共113頁4.1.2正確的編碼風(fēng)格雖然選取了好的程序設(shè)計(jì)語言有助于寫出既可靠又容易閱讀、容易維護(hù)的程序，但是，工具再好使用不當(dāng)也不會達(dá)到預(yù)期的效果。按照軟件工程方法學(xué)開發(fā)軟件，程序是表達(dá)軟件設(shè)計(jì)結(jié)果的一種更具體的形式，程序的質(zhì)量基本上由設(shè)計(jì)的質(zhì)量決定，但是，編碼風(fēng)格也在很大程度上決定著程序的質(zhì)量。所謂編碼風(fēng)格就是程序員在編寫程序時(shí)遵循的具體準(zhǔn)則和習(xí)慣做法。源程序代碼的邏輯簡明清晰、易讀易懂是好程序的一個(gè)重要標(biāo)準(zhǔn)，為了寫出好程序應(yīng)該遵循下述規(guī)則。第5頁/共113頁1.程序內(nèi)部必須有正確的文檔所謂程序內(nèi)部的文檔包括恰當(dāng)?shù)臉?biāo)識符、適當(dāng)?shù)淖⒔夂统绦虻囊曈X組織等等。選取含義鮮明的名字，使它能正確地提示程序?qū)ο笏淼膶?shí)體，這對于幫助閱讀者理解程序是很重要的。如果使用縮寫，那么縮寫規(guī)則應(yīng)該一致，并且應(yīng)該給每個(gè)名字加注解。第6頁/共113頁

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

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

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

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

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

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

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

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

被測試模塊的流程圖

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

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

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

在b點(diǎn)有下述各種結(jié)果出現(xiàn)：A＝2，A≠2，X＞1，X≤1第28頁/共113頁只需要使用下面兩組測試數(shù)據(jù)就可以達(dá)到上述覆蓋標(biāo)準(zhǔn)：Ⅰ.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頁

條件覆蓋通常比判定覆蓋強(qiáng)，因?yàn)樗古卸ū磉_(dá)式中每個(gè)條件都取到了兩個(gè)不同的結(jié)果，判定覆蓋卻只關(guān)心整個(gè)判定表達(dá)式的值。例如，上面兩組測試數(shù)據(jù)也同時(shí)滿足判定覆蓋標(biāo)準(zhǔn)。但是，也可能有相反的情況：雖然每個(gè)條件都取到了兩個(gè)不同的結(jié)果，判定表達(dá)式卻始終只取一個(gè)值。例如，如果使用下面兩組測試數(shù)據(jù)，則只滿足條件覆蓋標(biāo)準(zhǔn)并不滿足判定覆蓋標(biāo)準(zhǔn)（第二個(gè)判定表達(dá)式的值總為真）：Ⅰ.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.判定/條件覆蓋既然判定覆蓋不一定包含條件覆蓋，條件覆蓋也不一定包含判定覆蓋，自然會提出一種能同時(shí)滿足這兩種覆蓋標(biāo)準(zhǔn)的邏輯覆蓋，這就是判定/條件覆蓋。它的含義是，選取足夠多的測試數(shù)據(jù)，使得判定表達(dá)式中的每個(gè)條件都取到各種可能的值，而且每個(gè)判定表達(dá)式也都取到各種可能的結(jié)果。對于圖4.2的例子而言，下述兩組測試數(shù)據(jù)滿足判定/條件覆蓋標(biāo)準(zhǔn)：Ⅰ.A＝2，B＝0，X＝4Ⅱ.A＝1，B＝1，X＝1

但是，這兩組測試數(shù)據(jù)也就是為了滿足條件覆蓋標(biāo)準(zhǔn)最初選取的兩組數(shù)據(jù)，因此，有時(shí)判定/條件覆蓋也并不比條件覆蓋更強(qiáng)。第31頁/共113頁5.條件組合覆蓋條件組合覆蓋是更強(qiáng)的邏輯覆蓋標(biāo)準(zhǔn)，它要求選取足夠多的測試數(shù)據(jù)，使得每個(gè)判定表達(dá)式中條件的各種可能組合都至少出現(xiàn)一次。對于圖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

和其他邏輯覆蓋標(biāo)準(zhǔn)中的測試數(shù)據(jù)一樣，條件組合（5）～（8）中的X值是指在程序流程圖第二個(gè)判定框（b點(diǎn)）的X值。第32頁/共113頁

下面的四組測試數(shù)據(jù)可以使上面列出的八種條件組合每種至少出現(xiàn)一次：Ⅰ.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頁

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

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

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

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

圖4.4是由包含復(fù)合條件的PDL片斷翻譯成的流圖，注意，與復(fù)合條件“aORb”對應(yīng)的節(jié)點(diǎn)有兩個(gè)，這兩個(gè)節(jié)點(diǎn)分別標(biāo)記為“a”和“b”。圖4.4

由包含復(fù)合條件的PDL映射成的流圖

第39頁/共113頁

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

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

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

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

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

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

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

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

因此，一個(gè)條件中可能包含布爾變量、布爾算符、布爾括?。ɡㄗ『唵螚l件或復(fù)合條件）、關(guān)系算符及算術(shù)表達(dá)式等成分。如果條件不正確，則至少組成該條件的一個(gè)成分不正確。因此，條件錯(cuò)誤的類型如下：●布爾變量錯(cuò)?！癫紶査惴e(cuò)（布爾算符不正確，遺漏布爾算符或有多余的布爾算符）。●布爾括弧錯(cuò)?！耜P(guān)系算符錯(cuò)?！袼阈g(shù)表達(dá)式錯(cuò)。

第46頁/共113頁

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

第47頁/共113頁

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

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

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

三種循環(huán)

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

下面分別討論不同類型循環(huán)的測試方法。（1）簡單循環(huán)應(yīng)該使用下列測試集來測試簡單循環(huán)，其中n是允許通過循環(huán)的最大次數(shù)?！裉^循環(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)的測試方法直接應(yīng)用到嵌套循環(huán)，可能的測試數(shù)就會隨嵌套層數(shù)的增加按幾何級數(shù)增長，這會導(dǎo)致不切實(shí)際的測試數(shù)目。B.Beizer提出了一種能減少測試數(shù)的方法?！駨淖顑?nèi)層循環(huán)開始測試，把所有其他循環(huán)都設(shè)置為最小值。●對最內(nèi)層循環(huán)使用簡單循環(huán)測試方法，而使外層循環(huán)的迭代參數(shù)（例如，循環(huán)計(jì)數(shù)器）取最小值，并為越界值或非法值增加一些額外的測試?！裼蓛?nèi)向外，對下一個(gè)循環(huán)進(jìn)行測試，但保持所有其他外層循環(huán)為最小值，其他嵌套循環(huán)為“典型”值?！窭^續(xù)進(jìn)行下去，直到測試完所有循環(huán)。第52頁/共113頁（3）串接循環(huán)如果串接循環(huán)的各個(gè)循環(huán)都彼此獨(dú)立，則可以使用前述的測試簡單循環(huán)的方法來測試串接循環(huán)。但是，如果兩個(gè)循環(huán)串接，而且第一個(gè)循環(huán)的循環(huán)計(jì)數(shù)器值是第二個(gè)循環(huán)的初始值，則這兩個(gè)循環(huán)并不是獨(dú)立的。當(dāng)循環(huán)不獨(dú)立時(shí)，建議使用測試嵌套循環(huán)的方法來測試串接循環(huán)。第53頁/共113頁4.4黑盒測試技術(shù)

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

第55頁/共113頁

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

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

使用等價(jià)劃分法設(shè)計(jì)測試方案首先需要?jiǎng)澐州斎霐?shù)據(jù)的等價(jià)類，為此需要研究程序的功能說明，從而確定輸入數(shù)據(jù)的有效等價(jià)類和無效等價(jià)類。在確定輸入數(shù)據(jù)的等價(jià)類時(shí)常常還需要分析輸出數(shù)據(jù)的等價(jià)類，以便根據(jù)輸出數(shù)據(jù)的等價(jià)類導(dǎo)出對應(yīng)的輸入數(shù)據(jù)等價(jià)類。第59頁/共113頁

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

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

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

第64頁/共113頁

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

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

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

（1）模塊接口（2）局部數(shù)據(jù)結(jié)構(gòu)

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

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

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

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

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

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

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

第78頁/共113頁圖4.8

自頂向下結(jié)合

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

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

第80頁/共113頁圖4.9自底向上結(jié)合

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

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

第82頁/共113頁

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

混合法

第83頁/共113頁

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

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

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

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

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

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

調(diào)試過程

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

第94頁/共113頁

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

第97頁/共113頁

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

第98頁/共113頁

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

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

ET——測試之前程序中錯(cuò)誤總數(shù)；

IT——程序長度（機(jī)器指令總數(shù)）；

τ——測試（包括調(diào)試）時(shí)間；

Ed（τ）——在0至τ期間發(fā)現(xiàn)的錯(cuò)誤數(shù)；

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

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

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

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