軟件測試：調試

《軟件測試：調試》由會員分享，可在線閱讀，更多相關《軟件測試：調試（21頁珍藏版）》請在裝配圖網上搜索。

1、軟件測試:調試（DEBUGGINＧ) 簡樸地講，調試是執(zhí)行一次成功的測試之后所要進行的工作。記住,所謂成功 的測試，是指它可以證明程序沒有實現預期的功能。調試是一種涉及兩個環(huán)節(jié)的過 程，從執(zhí)行了一種成功的測試用例、發(fā)現了一種問題之后開始。第一步，擬定程序 中可疑錯誤的精確性質和位置;第二步，修改錯誤。 雖然調試對于程序測試來說非常必要、不可或缺,但它似乎是軟件開發(fā)過程中 最不受程序員歡迎的部分之一。其重要因素也許涉及如下幾點： ? 個人自尊會從中阻撓。不管我們與否喜歡,調試都闡明了程序員并不完美，　要么在軟件的設計,要么在程序編碼時會出錯。 ? 熱情耗盡。在所有的軟件開發(fā)活動中

2、,調試是最耗費腦力的苦差事，況且， 進行調試往往經受著來自機構或自身的巨大壓力,必須盡量快地改正問 題。 ? 也許會迷失方向。調試是艱苦的腦力工作，由于發(fā)現的錯誤事實上也許會 出目前程序的任何語句中。也就是說,如果不一方面檢查程序，我們就不能 絕對地肯定在一種薪金管理程序出具的支票中浮現的數字錯誤不是由某個 子程序引起的,該子程序規(guī)定操作員將一種特定的表格傳播給打印機。讓　我們以診斷一種物理系統(tǒng)為例子作對比，如汽車。如果汽車在爬坡時熄火 了(癥狀）,那么我們也許會迅速而有效地排除掉某些部件——調頻／調幅 收音機、速度表或汽車門鎖——引起該故障的也許。根據我們對汽車引擎　的整體理解，該故障一定

3、是發(fā)生在引擎上，我們甚至可以排除掉某些引擎 部件，如水箱和濾油器。 ? 必須自力更生。與其她軟件開發(fā)活動相比,有關調試過程的研究、資料和 正式的指南都比較少。 盡管本書是有關軟件測試的,并不討論調試，但這兩個過程顯然是互相聯系的。 針對調試的兩個環(huán)節(jié),即錯誤定位和錯誤修改，對錯誤進行定位也許解決了 95％的 問題。因此，本章集中討論錯誤的定位過程,固然是假定某個成功的測試用例已經 發(fā)現了一種錯誤。 ７.1 暴力法調試（Ｄｅbuggｉng by Ｂrute　Force) 調試程序的最為普遍的模式是所謂的“暴力”措施。這種措施之因此流行,是 由于它不需要

4、過多思考，是耗費腦力至少的措施，但同步也效率低下，一般來講不 是很成功。 暴力調試措施可至少被劃分為三種類型: 1. 運用內存信息輸出來調試。 2.?根據一般的“在程序中插入打印語句”建議來調試。 ３.?使用自動化的調試工具進行調試。 第一種類型，使用內存信息輸出(一般使用十六進制或八進制格式粗略地顯示 所有的存儲區(qū)域）是最缺少效率的暴力調試措施，因素如下： ??難以在內存區(qū)域寫源程序中的變量之間建立相應關系。 ? 雖然對下復雜限度較低的程序,內存信息輸出也會產生數最非常龐大的數 據,其中的大多數都是與調試無關的。 ? 內存信息輸出顯示的是程序的靜態(tài)快照,僅能顯示出

5、在某一種時刻程序的 狀態(tài)；為了發(fā)現錯誤,還需要研究程序的動態(tài)狀態(tài)(隨時間的狀態(tài)變化）。 ? 內存信息輸出很少可以精確地在錯誤發(fā)生的地方產生,因此無法顯示在錯 誤發(fā)生時程序的狀態(tài)。錯誤發(fā)生到輸出內存信息這段時間之內程序執(zhí)行的 活動，也許會掩蓋掉發(fā)現錯誤所需的線素。 ? 通過度析輸出的內存信息來發(fā)現問題的措施并不大多(因此很名程序員都 是密切注視，急切地渴望著錯誤能神奇地從內存信息輸出中自行暴露出 來)。 第二種類型,在失效的程序中插入輸出變量值的語句,這種做法也不具有很強 的優(yōu)勢。它也許比內存信息輸出要好某些，由于可以顯示程序的動態(tài)狀態(tài)，讓我們 檢查的信息可以相對容易地與源程序聯系起來

6、。但是這種措施同樣也有諸多缺陷: ? 它不是鼓勵我們去思考程序中的問題,而重要是一種碰運氣的措施。 ??它所產生的需要分析的數據量非常龐大。 ??它規(guī)定我們修改程序，這些修改也許會掩蓋掉錯誤、變化核心的時序關系， 或者會引入新的錯誤。 ??它也許對小型程序有效，但如果應用到大型程序，成本就相稱高。況且對　于某些類型的程序，如操作系統(tǒng)或過程控制軟件，這種措施甚至無法使用。 第三種類型,自動化調試工具的工作機制類似于在程序中插入打印語句, 但是并不修改程序自身?？梢允褂镁幊陶Z言的調試功能，或使用特殊的交互式 調試工具來分析程序的動態(tài)狀態(tài)。也許會用到的典型的語言功能有:產生

7、可打　印的語句執(zhí)行軌跡的機制、子程序調用以及/或者對特定變量的修改等。調試工 具的一種共同的功能是可以設立斷點,使程序在執(zhí)行到某條特定語句或改動了 某個特定變量的值時暫停執(zhí)行，然后程序員就可以檢查程序的目前狀態(tài)。同樣，　這種措施也重要是在碰運氣,常常會生成數量過于龐大的無關數據。 這些暴力調試措施的重要問題在于：它們都忽視了思考的過程。我們可以 在調試程序和偵破謀殺案之間找出相似點來。事實上，在幾平所有的謀殺懸念 故事中，謎案都是通過仔細分析線索,將表面上不重要的細節(jié)全聯結起來而最　終偵破的。這不是一種使用蠻力的措施,要使用蠻力的是尋覓障礙物或搜尋財 寶。 尚有些證據表白，無論調試

8、小構成員是富有經驗的程序員還是學生,肯動 腦筋而不是依賴別人協(xié)助的人可以更快、更精確地發(fā)現程序錯誤。因此，我們 建議僅在下列狀況下使用暴力調試措施:(ｌ）其她的措施都失敗了:（2）作為 我們下面將會討論的思考過程的補充，而不是替代措施。 7.2 歸納法調試（Dｅbuggｉnｇ by Iｎｄuｃｔｉoｎ) 很顯然，認真的思考可以發(fā)現大部分錯誤,甚至不需要調試人員使用調試　工具.歸納是一種特殊的思考過程,可以從細節(jié)轉到全局，也就是從線索(即 錯誤的癥狀，也許是一種或多種測試用例的成果）出發(fā)，尋找線索之間的聯系。 歸納的過程如圖 7-１ 所示。 不能

9、 數據 組織數據 ?間聯系?構造假設 能 證明假設 不能 能 修改錯誤 圖 ７-１ 　使用歸納法的調試過程 歸納調試的環(huán)節(jié)如下: 1. 擬定有關數據。調試人員犯的一種重要錯誤是未能將所有可用的數據或癥 狀都考慮進去。第一步是列舉出所有懂得的程序執(zhí)行的對的和不對的之處,　這些不對的之處即是癥狀,讓我們相信的確存在錯誤。那些相似卻不相似、 且未引起癥狀浮現的測試用例提供了額外的有價值的線索。 2. 組織數據。記住，歸納意味著從特殊到一般，因此第二步是組織這些有關 數據，以便觀測線索間的模式,特別重要的是要找到矛盾、事件,例如僅

10、 當客戶的保險金賬戶收支不太平衡時浮現的錯誤。我們可以采用圖 7-2 所 示的表格來組織既有的數據?！笆鞘裁础笨蛄信e的是總體的癥狀,“在何處” 框描述了這些癥狀浮現的地方，“多大限度”框描述了這些癥狀的范疇和重　要性。注意“是”和“否’列,它們所描述的矛盾之處最后也許會導致對 錯誤的假設。 ? Is Is nｏt What Wｈeｒe When To　what nexｔ 圖 ７-2 組織線索的一種措施 ３.?做出假設。下一步是研究線索之間的聯系，運用線索構造里也許的模式做　出一種或多種有關錯誤因素的假設。如果還無法做出推測,就需要更

11、多的 數據。如果也許有多種假設存在，一方面選擇最有能的一種。 4.?證明假設?？紤]到調試在進行時所承受的壓力,這個時期最重要的錯誤是 忽視了這個階段,直接跳到結論去改正問題。但是在繼續(xù)下一步之前,證 明這些假設的合理性是非常重要的。如果忽視了這一步，也許接下去只修 改了問題癥狀,而沒解決問題自身。應將假設與其最初的線索或數據相比 較,以此來證明假設的合理性,擬定這些假設可以完全解釋這些線索的存　在。如果無法解釋，要么這些假設是無效的或不完整的，要么尚有更多的 錯誤存在。 舉一種簡樸的例子、假設在第 4 章描述的考試評分軟件報告了一種明顯的錯　誤。錯誤是在某些但不是所

12、有狀況下，中間值似乎不對的。在某個特殊的測試用例 中,有 ５1 名學生被評分。對的打印出宋的平均分數為 7３.2，但打印出的中間值是 26　分，而不是預期的 8２ 分。通過對該測試用例及其她某些測試用例成果的檢查， 線索按圖 7-3　所示的形式進行組織。 ? Ｉｓ Ｉs not Ｗhat 報告 3 中顯示的中間值不正 確 計算平均值或原則偏差時出 現 Where 僅在報告 3 中浮現 在其他報告中浮現。學生成績 的計算似乎對的 When 當測試學生為　51 時發(fā)生 在測試學生數量為 2 和　2０0 時未發(fā)生 Tｏ what nｅxｔ 顯示的中間值

13、為　2６。當學生 數量為　1　時也同樣發(fā)生，顯示 的中間值。 圖 ７-3　 組織線索的例子 下一步是通過尋找模式和矛盾之處，做出有關該錯誤的假設。我們看到的一種　矛盾是這個錯誤似乎出目前學生人數為奇數的測試用例中,這也許是個巧合,但看 來很重要，由于我們要根據學生人數為奇數或偶數而不同地計算中間值。尚有一種 奇怪的模式：在些測試用例中，計算出來的中間值總是不不小于或等于學生的人數（26　小等于 ５1，l 小等于　1）。這時,一種也許的措施是再重新運營一次學生人數為 51 名的測試用例，給學生打與此前不同的分數,看一下是如何影響中間依的計算的。 如果中間值仍然是 ２6，那么“否

14、——多大限度”框可以填上“中間值似乎與實際分　數無關”。盡管這個成果提供了一條有價值的線索，但雖然沒有它，我們也許已經 可以猜出這個錯誤來。從既有數據計算出的中間值似乎等于學生人數的一半，通過 四舍五入后得到最接近的一種整數。換句話說，如果將分數設想為存儲在一種分類 表里，該程序打印的是中間學生的人數而不是其成績。因此,我們有了一種有關該 錯誤精確性質的堅定的假設。下一步就是通過檢查代碼或執(zhí)行某些附加的測試用例 來證明這個假設。 7.3 演繹法調試(Deｂugｇiｎg by Deｄuction) 演繹的過程是從某些普遍的理論或前提出發(fā)，使用排除和精煉的過程,達到

15、一 個結論(錯誤的位置）,參見圖 7－ ４ 。 列出也許 的因素 使用排除 法 提煉剩余 的假設 ?證明剩余?能　的假設  修改錯誤 都被排除?不能 收集更多　數據 圖　7-４ 　使用演繹法的調試過程 舉個謀殺犯的例子,與歸納過程相反,一方面從一系列嫌疑人入手,通過排除（花　匠有當時不在現場的合理證詞）和提煉（罪犯也許是紅色頭發(fā)）的過程,判斷出管 家也許犯了罪。演繹的環(huán)節(jié)如下: １.?列舉出所有也許的因素或假設．第一步是建立一份所有想象得到的錯誤線　索的清單，線索不需要有完整的解釋,它們純正是某些推測，協(xié)助我

16、們組　織和分析既有的數據。 ２.?運用數據排除也許的因素。具體檢查所有的數據,特別尋找存在矛盾的地 方（圖 7－2 可以用在此處），然后盡量排除所有也許的因素,僅留下一條, 如果所有的因素都排除掉了,需要增長額外的測試用例,得到更多的數據 來設計新的推測。如果剩余的因素多于一種，那么一方面選擇最有也許的原 因，即重要假設。 ３. 提煉剩余的假設。此時的也許因素也許是對的的,但也許不夠具體，不能指 出錯誤來。因此,下一步是使用既有的線索來提煉這個推側.舉例來說， 我們也許會一方面想到“對文獻中最后事務的解決也許存在錯誤”，并將其提 煉為“緩沖區(qū)中的最后事務被文獻結束批示器

17、覆蓋” 。 4. 證明剩余的假設。這個重要環(huán)節(jié)與歸納法中的第 ４ 環(huán)節(jié)相似。 舉個例子,假設我們著手對第 4 章討論的　DＩSＰLAY 命令進行功能測試。在由 因果圖分析措施擬定的 38 個測試用例中，我們一方面使用 4 個測試用例。作為建立 輸入條件過程的一部分，我們對內存進行初始化,將第一種、第五個、第九個、… 字的值設立為 000０,將第二個、第六個、… 字的值設立為 ４４44 　，將第三個、第　七個、…字的值設立為?。?8８，將第四個、第八個、… 字的值設立為 CＣCＣ。也就　是說,每個內存字單元都初始化為每個字的首字節(jié)地址中的低位十六進制數字 （２3FC、2３FD、23ＦE

18、 和 23FF　地址的值為 C)。 圖 7-5 顯示了這些測試用例、預期的輸出及測試用例的實際輸出。　顯然,我們遇到了某些問題,所有的測試用例都沒有產生預期的成果（所有都 成功了)。讓我們從調試與第一種測試用例有關的錯誤開始。該命令表白，從 0　地 址開始(默認狀況）,要顯示 E（十進制中的 14)個地址（回憶一下，規(guī)格闡明定　義所有的輸出應每行涉及　4 個字或　1６ 個字節(jié)）。 測試用例的輸入 預期的輸出 實際的輸出 ＤIＳＰLAY ０000 =　0０00　44４4 ８８8８ CＣCC M1?INＶALIＤ COMMAND SYNTAX DISPＬＡY　21v

19、-29 0000020　 ＝ 0０00　44４4 88８8 ＣＣCC 0000２0　= ４４44　888８ ＣCCC 00０0 DIＳPＬAY.11 000010 = ０000 44４4 8888　CCCC 00０010　= 0000 ４444 ８８88 ＣCCC 0000０0 =　0000 4444 ８８88　CＣCC ＤＩＳPLAY 8000-END Ｍ2 SＴＯRAGＥ　　 REOUEＳTED 　?。蒘 ＢEYONＤ?ＡCTUAL?MＥＭＯRY ＬIMＩＴS 00８0００ = 0000　４444 888８?。肅CＣ 圖 ７－５ DISPＬAY 命令的測試用例

20、輸出成果 為浮現的不盼望的錯誤信息列舉也許的因素: １．?程序不能接受單詞 DIＳPLAＹ。 2． 程序不能接受句號。 3. 程序不容許第一種操作數為默認狀況。程序規(guī)定在句號之前聲明一種存儲 地址。 ４.?程序不容許 E 作為有效的字節(jié)數量。 下一步是竭力排除這些因素。如果所有因素都排除掉了，那么需要退回去并擴 充一下因素的清單。如果剩余來的因素超過了一種,那么就需要檢查額外的測試用 例以擬定惟一的錯誤假設,或繼續(xù)使用也許性最大的因素。由于我們手上尚有其她 測試用例，可以看到圖?。?5 中的第二個測試用例似乎可以排除掉第　1 條假設,而第　三個測試用例盡管

21、產生了錯誤的成果,也似乎可以排除掉第 2　和第 3 條假設。 下一步是提煉第 4 條假設。它看上去足夠具體,但直覺告訴我們實質的內容要 比表面上看到的多。它看上去似乎是一種更為一般的錯誤實例。那么我們可以覺得 程序不能對的辨認特殊的十六進制字符 A～F 　。在其她測試用例中缺少這些字符， 使得這聽起來是一種行得通的解釋。然而我們不能立即得出結論，而應當一方面考慮　所有的已知信息。第四個測試用例也許代表一種完全不同的錯誤，也也許提供了一 條有關目前錯誤的線索。假設系統(tǒng)的最高有效地址是 ７FＦＦ,那么第四個測試用例　將如何顯示一種明顯不存在的區(qū)域呢？顯示的值是我們初始化后的值而不是無用 的信

22、息，這個事實讓我們推測該命令不知何故顯示了 0~7FＦＦ 　之間的某些內容。　我們也許會想到，這種錯誤也許會發(fā)生在程序將命令的操作數當成十進制數(而不　是規(guī)格闡明中規(guī)定的十六進制數）的狀況,第三個測試用例證明了這種假設,程序　并未顯示 32　個字節(jié)的內存單元的內容，而僅顯示了 16 個字節(jié)，這與我們的假設是 一致的,即“11”被當作了十進制數。因此，提煉后的假設是，程序將字節(jié)數當作 內存地址解決，并將輸出列表中的內存地址當作十進制數。最后的環(huán)節(jié)是證明該假 設。看一看第四個測試用例，如果 800０ 被解讀為十進制數,則相應的十六進制數　是 1Ｆ40 　,這樣就會產生我們所看到的輸出。作為進一步

23、的證據，檢查第二個測試 測試用例。輸出是不對的的,但如果　2１ 和　29　 被當作十進制數，那么內存地址 15～ ID　中的內容將被顯示出來,這是與測試用例的錯誤成果是一致的。因此,我們幾　乎可以確切地定位錯誤了：程序覺得操作數是十進制數，并將內存地址按十進制的 值打印出來，這與規(guī)格闡明是不符的。并且，這個錯誤似乎是導致所有四個測試用 例產生錯誤成果的因素。通過某些思考,我們發(fā)現了這個錯誤，同步也解決了其她 三個乍看起來毫不有關的問題。 注意,該錯誤也許在程序中的兩個地方顯現出來：解釋輸入命令的部分和在輸 出列表上打印內存地址的部分。 說句離題的話，這個也許由于錯誤理

24、解規(guī)格闡明而引起的錯誤進一步印證了我 們的建議,即程序員不應當測試自己編寫的程序。如果程序員在犯了這個錯誤之后 仍然去設計測試用例，很有也許在編寫測試用例時犯同樣的錯誤。換句話說，程序　員預料的輸出將不同于圖　7-5 　所示的；這些輸出將是按操作數是十進制數的理解而 被計算出來的,因此這個基本的錯誤也許不會被察覺到。 7.4 回溯法調試（Debｕｇgｉng　by Ｂａcｋtracking) 在小型程序中定位錯誤的一種有效措施是沿著程序的邏輯構造回溯不對的的 成果，直到找出程序邏輯出錯的位置。換句話說,從程序產生不對的成果（如打印 了不對的的數據）的地方開始,從該處觀測到的成果推

25、斷出程序變量應當是些什么 值。在頭腦中,從這個位置開始逆向執(zhí)行程序，反復使用“如果程序在此處的狀態(tài) 是這樣的,那么程序在上面位置的狀態(tài)就必然是那樣的”過程,就能不久定位出錯 誤。使用這個過程，可以擬定程序中從狀態(tài)符合預期值的位置點,到第一種狀態(tài)不 符合預期值的位置點之間的范疇。 7．5 測試法調試(Deｂｕggiｎｇ　by　Tｅstｉng) 最后一種“思維型”的調試措施是使用測試用例。這也許聽起來有些奇怪，因 為從本章一開始就將調試和測試辨別了開來。然而,考慮下面兩種類型的測試用例。 供測試的測試用例,其目的是暴露出此前尚未發(fā)現的錯誤．供調試的測試用例,其 目的是提供有用的信息

26、，供定位某個被懷疑的錯誤之用。兩者之間的區(qū)別是,供測　試的測試用例會“胖”某些,由于我們盡量使用較少數量的測試用例來涵蓋較多的 條件,而供調試的測試用例則“瘦”某些,由于每個測試用例僅需要覆蓋一種或幾　個條件。 換句話說,當發(fā)現了某個被懷疑的錯誤的癥狀之后，我們需要編寫與原先有所 變化的測試用例，盡量擬定錯誤的位置。事實上,這種措施不是一種完全獨立的方　法;它常常結合歸納法一起使用,以獲得進行假設和/或證明假設所需的信息。它也　可以和演繹法一起使用,以排除有嫌疑的因素,提煉剩余的假設，并/或證明假設。 ７．6 調試的原則 在本節(jié)中,我們將討論一系列的調試原則，在實

27、質上也是心理學的原則。與第 2　章的測試原則狀況同樣,這些調試原則有諸多在直觀上很明顯,但卻常常被遺忘 或忽視。由于調試的過程由兩部分構成，即定位錯誤及修改錯誤，因此我們也將討 論兩類原則, ７.6．1 定位錯誤的原則 1. ?動腦筋 前面的章節(jié)隱含指出，調試是一種解決問題的過程。最為有效的調試措施 是動腦筋對錯誤癥狀的有關信息進行分析。一種高效的程序調試人員應當不使 用計算機就能定位大多數的錯誤。 2．?如果遇到了僵局,就留到稍后解決　人類的潛意識是一種潛在的問題求解器。我們常常提到的所謂靈感,其實 就是當人類的意識停留在諸如吃東西、走路或看電影之上時

28、,潛意識卻正在思 考另一種向題。如果在合理時間內(也許小型程序為 30 分鐘，大一點的程序為 幾種小時）,我們還不能定位某個間題,就丟開它,做些其她的事情,由于思維 的效率開始明顯下降。忘掉這個問題一段時間之后，我們的潛意識也許已經解 決了它，或者思維會煥然一新，可以重新檢查問題的癥狀。 3.?如果遇到了困境，就把問題描述給其她人聽 與其她人交談也許會協(xié)助我們發(fā)現某些新的東西。事實上,常常是僅僅將 問題描述給一種好的傾聽者時，我們就會忽然找到問題的解決之道,而無需傾 聽者提供任何協(xié)助。 4.?僅將測試工具作為第二種手段 在試過了其她的措施之后才使用調試上具，并將其作為

29、頭腦思考的輔助手 段，而不是替代手段。正如本章前面所述，調試工具例如輸出和跟蹤工具,代 表的是一種偶爾的調試措施。經驗證明,不使用工具的人雖然在調試并不熟悉 的程序時,也要比使用工具的人更為成功。 ５. 避免使用實驗法——僅將其作為最后的手段 調試程序的新手最常犯的錯誤是為理解決問題而實驗性地去修改程序。調 試者也許會說：“我懂得什么出錯了，因此我要改動一下語句.看一看會發(fā)生什 么”。這種純正是無籌劃的措施甚至不屬于調試.它體現的是盲目的行動。它獲　得成功的機會不僅很小,并且還會將新的錯誤引入程序，使問題更為復雜。 7．６.２ 修改錯誤的技術

30、 1. 存在一種缺陷的地方,很有也許還存在其她缺陷 這是對本書第 2 　章原則的重申，即發(fā)現程序某個部分存在一種錯誤時,該 部分存在其她錯誤的也許性要高于沒有發(fā)現錯誤時的也許性。換句話說,錯誤 有扎堆的傾向。在修改某個問題的同步，應檢查下緊臨的地方，看看有無任　何也許是錯誤之處。 ２. 應糾正錯誤自身，而不僅是其癥狀 另一種普遍的錯誤做法是只修改了錯誤的癥狀或僅僅是該錯誤的一種實 例,而不是錯誤自身。如果所做的改正不符合錯誤的所有線索,那么也許只修 改了錯誤的一部分。 3.?對的糾正錯誤的也許性并非 100% 如果將這個觀點告訴某些人，她們固然會表達贊同，但是

31、如果將它說給正　在修改錯誤的人聽,答案就也許不同樣了(“是的,對大多數狀況是這樣，但這 個修改如此之小，它肯定百分之百地對的”）。我們永遠也不要假設為糾正錯誤 而增長到程序中的代碼是對的的。用新的語句替代本來的語句,這種修改要遠 比程序中原先的代碼更易發(fā)生錯誤。言外之意是應對錯誤的修改善行測試,也 許比對原先程序的測試還要嚴格。一種嚴格的回歸測試籌劃可以保證對某個錯 誤的修改沒有在程序的其她位置引入此外的錯誤。 4.?對的修改錯誤的也許性隨著程序規(guī)模的增長而減少 換句話說,根據我們的經驗，由于修改不對的而引人的錯誤與原始錯誤之 比，在規(guī)模較大的程序中呈遞增趨勢。對于一

32、種廣泛使用的大型程序，每發(fā)現 6 個新錯誤，其中就有 l 個錯誤是由干先前對程序的改正而導致的。 ５．?應意識改正錯誤會引入新錯誤的也許性　我們不僅需要考慮到不對的的修改,并且還必須考慮到某個看似對的的修 改會產生未料到的副作用,例如引入了一種新錯誤。不僅存在修改無效的也許, 還存在修改引入了新錯誤的也許。言外之意是,不僅應在修改之后對錯誤的情 境進行測試,還應執(zhí)行回歸測試以判斷與否引入了新錯誤。 6.?修改錯誤的過程也是臨時回到設計階段的過程 我們應當結識到修改錯誤也是程序設計的一種形式。在結識到修改易產生 錯誤的性質之后,常識告訴我們，在設計階段使用的任何規(guī)程、

33、措施和形式都 同樣合用于錯誤修改階段。舉例來說，如果項目證明代碼檢查很管用,那么在　修改錯誤之后進行代碼檢查就顯得倍加重要。 7. 應修改源代碼,而不是目的代碼　在調試大型系統(tǒng),特別是用匯編語言編寫的系統(tǒng)時,偶爾會存在這樣的修 改錯誤的傾向,即先立即修改目的代碼．稍后再修改源程序.這種措施帶來了 兩個問題,(1）這一般是“通過實驗進行調試”的信號;（2）目的代碼與源程 序不同步，這意味著當程序重新編譯或重新匯編之后,同樣的錯誤很容易又浮 現出來，這是一種草率的、不專業(yè)的調試措施。 7.7 錯誤分析 有關程序調試最后一種應結識之處是，調試除了有消滅程序中錯誤

34、的價值之 外，尚有其她重要作用:它可以告訴我們軟件錯誤的某些本質．我們對此理解得非 常之少．有關軟件錯誤本質的信息可覺得改善將來的設計、編碼和測試過程提供有 價值的反饋信息。 任何程序員和編程機構都可以從具體分析發(fā)現的錯誤,或至少一部分錯誤的過 程中獲得提高。錯誤分析是一項困難且費時的工作,相比“有百分之多少的錯誤是 邏輯設計錯誤”　、“有百分之多少的錯誤出目前 ＩF 語句中”這些膚淺的分類,它 蘊涵的內容要多得多。具體的錯誤分析會涉及如下內容: z?錯誤出目前什么地方?這個問題是最難回答的問題之一，它需要通過對程 序文檔和項目歷史進行回溯研究，但同步它也是最有價值

35、的問題。它規(guī)定 我們指出該錯誤的源頭和發(fā)生時間。舉例來說,錯誤的源頭也許是規(guī)格說　明中的一種模棱兩可的語句,對先前錯誤的一次修改，或對最后顧客需求 的一種錯誤理解, z 誰制造了這個錯誤？如果發(fā)既有 ６0　 ％的設計錯誤都是由 10 　名軟件分析 師中的某個人犯下的，或某程序員犯的錯是其她程序員的 ３　倍,難道這不 是相稱有用么?(不是為了懲罰某人,而是為了進行培訓。） z 哪些做得不對的?僅僅判斷錯誤的發(fā)生時間和浮現人員還不夠,其中丟失　的環(huán)節(jié)是精確地判斷出錯誤發(fā)生的因素。錯誤是由于某人寫得不清晰？是 由干某人缺少對該編程語言的培訓？是打字錯誤?假設做得不對？還是因 為沒有考慮有效輸入？

36、 z 如何避免該錯誤的浮現？在下一種項目中可以進行哪些調節(jié)以避免該問題 的浮現?此向題的答案就是我們所尋找的最為珍貴的反饋信息或知識。 z 為什么錯誤沒有早些發(fā)現?如果錯誤是在測試引入段發(fā)現的,我們就應當　研究為什么在更早些的測試階段、代碼審查和設計評審中沒有發(fā)現該錯誤。 z 該如何更早地發(fā)現錯誤？這個問題的答案是另一種珍貴的反饋信息。該如 何改善評審和測試過程以便在將來的項目中更早地發(fā)現同類型的錯誤？假 設分析的問題不是由最后顧客發(fā)現的（也就是說,是由測試用例發(fā)現的)，　我們就應意識發(fā)生了某些有價值的事情：我們編寫了一種成功的測試用例。 這個測試用例為什么會成功？我們與否能從中學習些什么，無論是針對該　程序還是將來的程序，設計出更多的成功用例? 再一次聲明,分析的過程是很艱難的，但是找到的答案為改善后續(xù)的編程實踐　提供極其珍貴的價值。值得警惕的是,絕大多數的程序員和編程機構都尚未使用這 種措施。