軟件測試：調試

軟件測試：調試(DEBUGGING)簡單地講，調試是執(zhí)行一次成功的測試之后所要進行的工作。記住，所謂成功 的測試，是指它可以證明程序沒有實現(xiàn)預期的功能。調試是一個包含兩個步驟的過 程，從執(zhí)行了一個成功的測試用例、發(fā)現(xiàn)了一個問題之后開始。第一步，確定程序 中可疑錯誤的準確性質和位置；第二步，修改錯誤。雖然調試對于程序測試來說非常必要、不可或缺，但它似乎是軟件開發(fā)過程中 最不受程序員歡迎的部分之一。其主要原因可能包括以下幾點：個人自尊會從中阻撓。不管我們是否喜歡，調試都說明了程序員并不完美， 要么在軟件的設計，要么在程序編碼時會犯錯。熱情耗盡。在所有的軟件開發(fā)活動中，調試是最耗費腦力的苦差事，況且， 進行調試往往經受著來自機構或自身的巨大壓力，必須盡可能快地改正問 題?？赡軙允Х较?。調試是艱苦的腦力工作，因為發(fā)現(xiàn)的錯誤實際上可能會 出現(xiàn)在程序的任何語句中。也就是說，如果不首先檢查程序，我們就不能 絕對地肯定在一個薪金管理程序出具的支票中出現(xiàn)的數(shù)字錯誤不是由某個 子程序引起的，該子程序要求操作員將一個特定的表格傳輸給打印機。讓 我們以診斷一個物理系統(tǒng)為例子作對比，如汽車。假如汽車在爬坡時熄火 了（癥狀），那么我們可能會迅速而有效地排除掉某些部件調頻/調幅 收音機、速度表或汽車門鎖引起該故障的可能。根據我們對汽車引擎 的整體了解，該故障一定是發(fā)生在引擎上，我們甚至可以排除掉某些引擎 部件，如水箱和濾油器。必須自力更生。與其他軟件開發(fā)活動相比，關于調試過程的研究、資料和 正式的指南都比較少。盡管本書是關于軟件測試的，并不討論調試，但這兩個過程顯然是相互聯(lián)系的。 針對調試的兩個步驟，即錯誤定位和錯誤修改，對錯誤進行定位可能解決了 95的問題。因此，本章集中討論錯誤的定位過程，當然是假定某個成功的測試用例已經發(fā)現(xiàn)了一個錯誤。7.1 暴力法調試(Debugging by Brute Force)調試程序的最為普遍的模式是所謂的“暴力”方法。這種方法之所以流行，是 因為它不需要過多思考，是耗費腦力最少的方法，但同時也效率低下，通常來講不 是很成功。暴力調試方法可至少被劃分為三種類型：1.利用內存信息輸出來調試。2.根據一般的“在程序中插入打印語句”建議來調試。3.使用自動化的調試工具進行調試。 第一種類型，使用內存信息輸出（通常使用十六進制或八進制格式粗略地顯示所有的存儲區(qū)域）是最缺乏效率的暴力調試方法，原因如下：難以在內存區(qū)域寫源程序中的變量之間建立對應關系。即使對下復雜程度較低的程序，內存信息輸出也會產生數(shù)最非常龐大的數(shù) 據，其中的大多數(shù)都是與調試無關的。內存信息輸出顯示的是程序的靜態(tài)快照，僅能顯示出在某一個時刻程序的 狀態(tài)；為了發(fā)現(xiàn)錯誤，還需要研究程序的動態(tài)狀態(tài)（隨時間的狀態(tài)變化）。內存信息輸出很少可以精確地在錯誤發(fā)生的地方產生，因此無法顯示在錯 誤發(fā)生時程序的狀態(tài)。錯誤發(fā)生到輸出內存信息這段時間之內程序執(zhí)行的 活動，可能會掩蓋掉發(fā)現(xiàn)錯誤所需的線素。通過分析輸出的內存信息來發(fā)現(xiàn)問題的方法并不大多（因此很名程序員都 是密切注視，急切地渴望著錯誤能神奇地從內存信息輸出中自行暴露出 來）。第二種類型，在失效的程序中插入輸出變量值的語句，這種做法也不具有很強 的優(yōu)勢。它可能比內存信息輸出要好一些，因為可以顯示程序的動態(tài)狀態(tài)，讓我們 檢查的信息可以相對容易地與源程序聯(lián)系起來。但是這種方法同樣也有很多缺點：它不是鼓勵我們去思考程序中的問題，而主要是一種碰運氣的方法。它所產生的需要分析的數(shù)據量非常龐大。它要求我們修改程序，這些修改可能會掩蓋掉錯誤、改變關鍵的時序關系， 或者會引入新的錯誤。它可能對小型程序有效，但如果應用到大型程序，成本就相當高。況且對 于某些類型的程序，如操作系統(tǒng)或過程控制軟件，這種辦法甚至無法使用。第三種類型，自動化調試工具的工作機制類似于在程序中插入打印語句， 但是并不修改程序本身?？梢允褂镁幊陶Z言的調試功能，或使用特殊的交互式 調試工具來分析程序的動態(tài)狀態(tài)。可能會用到的典型的語言功能有：產生可打 印的語句執(zhí)行軌跡的機制、子程序調用以及/或者對特定變量的修改等。調試工 具的一個共同的功能是可以設置斷點，使程序在執(zhí)行到某條特定語句或改動了 某個特定變量的值時暫停執(zhí)行，然后程序員就可以檢查程序的當前狀態(tài)。同樣， 這種方法也主要是在碰運氣，常常會生成數(shù)量過于龐大的無關數(shù)據。這些暴力調試方法的主要問題在于：它們都忽略了思考的過程。我們可以 在調試程序和偵破謀殺案之間找出相似點來。實際上，在幾平所有的謀殺懸念 小說中，謎案都是通過仔細分析線索，將表面上不重要的細節(jié)全聯(lián)結起來而最 終偵破的。這不是一個使用蠻力的方法，要使用蠻力的是尋覓障礙物或搜尋財 寶。還有些證據表明，無論調試小組成員是富有經驗的程序員還是學生，肯動 腦筋而不是依賴別人幫助的人能夠更快、更準確地發(fā)現(xiàn)程序錯誤。因此，我們 建議僅在下列情況下使用暴力調試方法：（l）其他的方法都失敗了：（2）作為 我們下面將會討論的思考過程的補充，而不是替代方法。7.2 歸納法調試(Debugging by Induction)很顯然，認真的思考能夠發(fā)現(xiàn)大部分錯誤，甚至不需要調試人員使用調試 工具歸納是一種特殊的思考過程，可以從細節(jié)轉到全局，也就是從線索（即 錯誤的癥狀，可能是一個或多個測試用例的結果）出發(fā)，尋找線索之間的聯(lián)系。 歸納的過程如圖 7-1 所示。不能數(shù)據組織數(shù)據間聯(lián)系構造假設能證明假設不能 能修改錯誤圖 7-1 使用歸納法的調試過程歸納調試的步驟如下：1.確定相關數(shù)據。調試人員犯的一個主要錯誤是未能將所有可用的數(shù)據或癥 狀都考慮進去。第一步是列舉出所有知道的程序執(zhí)行的正確和不正確之處， 這些不正確之處即是癥狀，讓我們相信確實存在錯誤。那些相似卻不相同、 且未引起癥狀出現(xiàn)的測試用例提供了額外的有價值的線索。2.組織數(shù)據。記住，歸納意味著從特殊到一般，因此第二步是組織這些相關 數(shù)據，以便觀察線索間的模式，尤其重要的是要找到矛盾、事件，比如僅 當客戶的保險金賬戶收支不太平衡時出現(xiàn)的錯誤。我們可以采用圖 7-2 所 示的表格來組織現(xiàn)有的數(shù)據。“是什么”框列舉的是總體的癥狀，“在何處” 框描述了這些癥狀出現(xiàn)的地方，“多大程度”框描述了這些癥狀的范圍和重 要性。注意“是”和“否列，它們所描述的矛盾之處最終可能會導致對錯誤的假設。?IsIs notWhatWhereWhenTo what next圖 7-2 組織線索的一種方法3.做出假設。下一步是研究線索之間的聯(lián)系，利用線索結構里可能的模式做 出一個或多個關于錯誤原因的假設。如果還無法做出推測，就需要更多的數(shù)據。如果可能有多個假設存在，首先選擇最有能的一個。4.證明假設?？紤]到調試在進行時所承受的壓力，這個時期最主要的錯誤是 忽略了這個階段，直接跳到結論去改正問題。但是在繼續(xù)下一步之前，證 明這些假設的合理性是非常重要的。如果忽略了這一步，可能接下去只修 改了問題癥狀，而沒解決問題本身。應將假設與其最初的線索或數(shù)據相比 較，以此來證明假設的合理性，確定這些假設可以完全解釋這些線索的存 在。如果無法解釋，要么這些假設是無效的或不完整的，要么還有更多的 錯誤存在。舉一個簡單的例子、假設在第 4 章描述的考試評分軟件報告了一個明顯的錯 誤。錯誤是在某些但不是所有情況下，中間值似乎不正確。在某個特殊的測試用例 中，有 51 名學生被評分。正確打印出宋的平均分數(shù)為 73.2，但打印出的中間值是26 分，而不是預期的 82 分。經過對該測試用例及其他一些測試用例結果的檢查，線索按圖 7-3 所示的形式進行組織。?IsIs notWhat報告 3 中顯示的中間值不正確計算平均值或標準偏差時出現(xiàn)Where僅在報告 3 中出現(xiàn)在其它報告中出現(xiàn)。學生成績的計算似乎正確When當測試學生為 51 時發(fā)生在測試學生數(shù)量為 2 和 200時未發(fā)生To what next顯示的中間值為 26。當學生數(shù)量為 1 時也同樣發(fā)生，顯示 的中間值。圖 7-3 組織線索的例子下一步是通過尋找模式和矛盾之處，做出關于該錯誤的假設。我們看到的一個 矛盾是這個錯誤似乎出現(xiàn)在學生人數(shù)為奇數(shù)的測試用例中，這也許是個巧合，但看 來很重要，因為我們要根據學生人數(shù)為奇數(shù)或偶數(shù)而不同地計算中間值。還有一個 奇怪的模式：在些測試用例中，計算出來的中間值總是小于或等于學生的人數(shù)（26 小等于 51，l 小等于 1）。這時，一個可能的方法是再重新運行一次學生人數(shù)為 51 名的測試用例，給學生打與以前不同的分數(shù)，看一下是如何影響中間依的計算的。 如果中間值仍然是 26，那么“否多大程度”框可以填上“中間值似乎與實際分 數(shù)無關”。盡管這個結果提供了一條有價值的線索，但即使沒有它，我們可能已經能夠猜出這個錯誤來。從現(xiàn)有數(shù)據計算出的中間值似乎等于學生人數(shù)的一半，經過四舍五入后得到最接近的一個整數(shù)。換句話說，如果將分數(shù)設想為存儲在一個分類 表里，該程序打印的是中間學生的人數(shù)而不是其成績。因此，我們有了一個關于該 錯誤準確性質的堅定的假設。下一步就是通過檢查代碼或執(zhí)行一些附加的測試用例 來證明這個假設。7.3 演繹法調試(Debugging by Deduction)演繹的過程是從一些普遍的理論或前提出發(fā)，使用排除和精煉的過程，達到一 個結論（錯誤的位置），參見圖 7- 4 。130列出可能 的原因使用排除 法提煉剩下 的假設證明剩下能 的假設修改錯誤都被排除不能收集更多 數(shù)據圖 7-4 使用演繹法的調試過程舉個謀殺犯的例子，與歸納過程相反，首先從一系列嫌疑人入手，通過排除（花 匠有當時不在現(xiàn)場的合理證詞）和提煉（罪犯可能是紅色頭發(fā)）的過程，判斷出管 家可能犯了罪。演繹的步驟如下：1.列舉出所有可能的原因或假設第一步是建立一份所有想象得到的錯誤線 索的清單，線索不需要有完整的解釋，它們純粹是一些推測，幫助我們組 織和分析現(xiàn)有的數(shù)據。2.利用數(shù)據排除可能的原因。詳細檢查所有的數(shù)據，尤其尋找存在矛盾的地 方（圖 7-2 可以用在此處），然后盡量排除所有可能的原因，僅留下一條， 如果所有的原因都排除掉了，需要增加額外的測試用例，得到更多的數(shù)據 來設計新的推測。如果剩下的原因多于一個，那么首先選擇最有可能的原 因，即主要假設。3.提煉剩下的假設。此時的可能原因也許是正確的,但可能不夠具體，不能指出錯誤來。因此，下一步是使用現(xiàn)有的線索來提煉這個推側舉例來說，我們可能會首先想到“對文件中最后事務的處理可能存在錯誤”，并將其提 煉為“緩沖區(qū)中的最后事務被文件結束指示器覆蓋” 。4.證明剩下的假設。這個重要步驟與歸納法中的第 4 步驟相同。 舉個例子，假設我們著手對第 4 章討論的 DISPLAY 命令進行功能測試。在由因果圖分析方法確定的 38 個測試用例中，我們首先使用 4 個測試用例。作為建立輸入條件過程的一部分，我們對內存進行初始化，將第一個、第五個、第九個、 字的值設置為 0000，將第二個、第六個、 字的值設置為 4444 ，將第三個、第 七個、字的值設置為 8888，將第四個、第八個、 字的值設置為 CCCC。也就 是說，每個內存字單元都初始化為每個字的首字節(jié)地址中的低位十六進制數(shù)字（23FC、23FD、23FE 和 23FF 地址的值為 C）。圖 7-5 顯示了這些測試用例、預期的輸出及測試用例的實際輸出。 顯然，我們遇到了一些問題，所有的測試用例都沒有產生預期的結果（全部都成功了）。讓我們從調試與第一個測試用例相關的錯誤開始。該命令表明，從 0 地址開始（默認情況），要顯示 E（十進制中的 14）個地址（回憶一下，規(guī)格說明定 義所有的輸出應每行包括 4 個字或 16 個字節(jié)）。測試用例的輸入預期的輸出實際的輸出DISPLAY0000 = 0000 4444 8888 CCCCM1INVALIDCOMMANDSYNTAXDISPLAY 21v-29 0000 4444 8888 CCCC = 4444 8888 CCCC 0000DISPLAY.11 = 0000 4444 8888 CCCC = 0000 4444 8888 CCCC = 0000 4444 8888 CCCCDISPLAY 8000-ENDM2 STORAGE REOUESTED IS BEYONDACTUALMEMORYLIMITS = 0000 4444 8888 CCCC圖 7-5 DISPLAY 命令的測試用例輸出結果為出現(xiàn)的不期望的錯誤信息列舉可能的原因：1.程序不能接受單詞 DISPLAY。2.程序不能接受句號。3.程序不允許第一個操作數(shù)為默認情況。程序要求在句號之前聲明一個存儲 地址。4.程序不允許 E 作為有效的字節(jié)數(shù)量。下一步是盡力排除這些原因。如果所有原因都排除掉了，那么需要退回去并擴 充一下原因的清單。如果剩下來的原因超過了一個，那么就需要檢驗額外的測試用 例以確定惟一的錯誤假設，或繼續(xù)使用可能性最大的原因。由于我們手上還有其他 測試用例，可以看到圖 7-5 中的第二個測試用例似乎可以排除掉第 1 條假設，而第 三個測試用例盡管產生了錯誤的結果，也似乎可以排除掉第 2 和第 3 條假設。下一步是提煉第 4 條假設。它看上去足夠具體，但直覺告訴我們實質的內容要 比表面上看到的多。它看上去似乎是一個更為一般的錯誤實例。那么我們可以認為 程序不能正確識別特殊的十六進制字符 AF 。在其他測試用例中缺少這些字符， 使得這聽起來是一個行得通的解釋。然而我們不能馬上得出結論，而應該首先考慮 所有的已知信息。第四個測試用例可能代表一個完全不同的錯誤，也可能提供了一 條關于當前錯誤的線索。假設系統(tǒng)的最高有效地址是 7FFF，那么第四個測試用例 將如何顯示一個明顯不存在的區(qū)域呢？顯示的值是我們初始化后的值而不是無用 的信息，這個事實讓我們推測該命令不知何故顯示了 07FFF 之間的某些內容。 我們可能會想到，這種錯誤也許會發(fā)生在程序將命令的操作數(shù)當成十進制數(shù)（而不 是規(guī)格說明中要求的十六進制數(shù)）的情況，第三個測試用例證實了這種假設，程序 并未顯示 32 個字節(jié)的內存單元的內容，而僅顯示了 16 個字節(jié)，這與我們的假設是 一致的，即“11”被當作了十進制數(shù)。因此，提煉后的假設是，程序將字節(jié)數(shù)當作 內存地址處理，并將輸出列表中的內存地址當作十進制數(shù)。最后的步驟是證明該假 設?？匆豢吹谒膫€測試用例，如果 8000 被解讀為十進制數(shù)，則對應的十六進制數(shù) 是 1F40 ，這樣就會產生我們所看到的輸出。作為進一步的證據，檢查第二個測試 測試用例。輸出是不正確的，但如果 21 和 29 被當作十進制數(shù)，那么內存地址 15 ID 中的內容將被顯示出來，這是與測試用例的錯誤結果是一致的。因此，我們幾 乎可以確切地定位錯誤了：程序認為操作數(shù)是十進制數(shù)，并將內存地址按十進制的 值打印出來，這與規(guī)格說明是不符的。而且，這個錯誤似乎是造成所有四個測試用 例產生錯誤結果的原因。經過一些思考，我們發(fā)現(xiàn)了這個錯誤，同時也解決了其他 三個乍看起來毫不相關的問題。注意，該錯誤可能在程序中的兩個地方顯現(xiàn)出來：解釋輸入命令的部分和在輸出列表上打印內存地址的部分。說句離題的話，這個可能由于錯誤理解規(guī)格說明而引起的錯誤進一步印證了我 們的建議，即程序員不應該測試自己編寫的程序。如果程序員在犯了這個錯誤之后 仍然去設計測試用例，很有可能在編寫測試用例時犯同樣的錯誤。換句話說，程序 員預料的輸出將不同于圖 7-5 所示的；這些輸出將是按操作數(shù)是十進制數(shù)的理解而 被計算出來的，因此這個基本的錯誤可能不會被察覺到。7.4 回溯法調試(Debugging by Backtracking)在小型程序中定位錯誤的一種有效方法是沿著程序的邏輯結構回溯不正確的 結果，直到找出程序邏輯出錯的位置。換句話說，從程序產生不正確結果（如打印 了不正確的數(shù)據）的地方開始，從該處觀察到的結果推斷出程序變量應該是些什么 值。在頭腦中，從這個位置開始逆向執(zhí)行程序，重復使用“如果程序在此處的狀態(tài) 是這樣的，那么程序在上面位置的狀態(tài)就必然是那樣的”過程，就能很快定位出錯 誤。使用這個過程，可以確定程序中從狀態(tài)符合預期值的位置點，到第一個狀態(tài)不 符合預期值的位置點之間的范圍。7.5 測試法調試(Debugging by Testing)最后一個“思維型”的調試方法是使用測試用例。這可能聽起來有些奇怪，因 為從本章一開始就將調試和測試區(qū)分了開來。然而，考慮下面兩種類型的測試用例。 供測試的測試用例，其目的是暴露出以前尚未發(fā)現(xiàn)的錯誤供調試的測試用例，其 目的是提供有用的信息，供定位某個被懷疑的錯誤之用。兩者之間的區(qū)別是，供測 試的測試用例會“胖”一些，因為我們盡量使用較少數(shù)量的測試用例來涵蓋較多的 條件，而供調試的測試用例則“瘦”一些，因為每個測試用例僅需要覆蓋一個或幾 個條件。換句話說，當發(fā)現(xiàn)了某個被懷疑的錯誤的癥狀之后，我們需要編寫與原先有所 變化的測試用例，盡量確定錯誤的位置。實際上，這種方法不是一個完全獨立的方 法；它常常結合歸納法一起使用，以獲得進行假設和/或證明假設所需的信息。它也 可以和演繹法一起使用，以排除有嫌疑的原因，提煉剩下的假設，并/或證明假設。7.6 調試的原則在本節(jié)中，我們將討論一系列的調試原則，在實質上也是心理學的原則。與第2 章的測試原則情況一樣，這些調試原則有很多在直觀上很明顯，但卻常常被遺忘 或忽略。由于調試的過程由兩部分組成，即定位錯誤及修改錯誤，因此我們也將討 論兩類原則，7.6.1 定位錯誤的原則1.動腦筋 前面的章節(jié)隱含指出，調試是一個解決問題的過程。最為有效的調試方法是動腦筋對錯誤癥狀的有關信息進行分析。一個高效的程序調試人員應該不使用計算機就能定位大多數(shù)的錯誤。2.如果遇到了僵局，就留到稍后解決 人類的潛意識是一個潛在的問題求解器。我們經常提到的所謂靈感，其實就是當人類的意識停留在諸如吃東西、走路或看電影之上時，潛意識卻正在思考另一個向題。如果在合理時間內（也許小型程序為 30 分鐘，大一點的程序為 幾個小時），我們還不能定位某個間題，就丟開它，做些其他的事情，因為思維 的效率開始明顯下降。忘記這個問題一段時間之后，我們的潛意識可能已經解 決了它，或者思維會煥然一新，可以重新檢查問題的癥狀。3.如果遇到了困境，就把問題描述給其他人聽 與其他人交談可能會幫助我們發(fā)現(xiàn)一些新的東西。事實上，經常是僅僅將問題描述給一個好的傾聽者時，我們就會突然找到問題的解決之道，而無需傾聽者提供任何幫助。4.僅將測試工具作為第二種手段 在試過了其他的方法之后才使用調試上具，并將其作為頭腦思考的輔助手段，而不是替代手段。正如本章前面所述，調試工具比如輸出和跟蹤工具，代表的是一種偶然的調試方法。經驗證明，不使用工具的人即使在調試并不熟悉的程序時，也要比使用工具的人更為成功。5.避免使用試驗法僅將其作為最后的手段 調試程序的新手最常犯的錯誤是為了解決問題而試驗性地去修改程序。調試者可能會說：“我知道什么出錯了，所以我要改動一下語句看一看會發(fā)生什么”。這種純粹是無計劃的方法甚至不屬于調試它表現(xiàn)的是盲目的行動。它獲 得成功的機會不僅很小，而且還會將新的錯誤引入程序，使問題更為復雜。7.6.2 修改錯誤的技術1.存在一個缺陷的地方，很有可能還存在其他缺陷這是對本書第 2 章原則的重申，即發(fā)現(xiàn)程序某個部分存在一個錯誤時，該 部分存在其他錯誤的可能性要高于沒有發(fā)現(xiàn)錯誤時的可能性。換句話說，錯誤 有扎堆的傾向。在修改某個問題的同時，應檢查下緊臨的地方，看看有沒有任 何可能是錯誤之處。2.應糾正錯誤本身，而不僅是其癥狀 另一個普遍的錯誤做法是只修改了錯誤的癥狀或僅僅是該錯誤的一個實例，而不是錯誤本身。如果所做的改正不符合錯誤的所有線索，那么可能只修改了錯誤的一部分。3.正確糾正錯誤的可能性并非 100%如果將這個觀點告訴一些人，他們當然會表示贊同，但是如果將它說給正 在修改錯誤的人聽，答案就可能不一樣了(“是的，對大多數(shù)情況是這樣，但這 個修改如此之小，它肯定百分之百地正確”）。我們永遠也不要假設為糾正錯誤 而增加到程序中的代碼是正確的。用新的語句替換原來的語句，這種修改要遠 比程序中原先的代碼更易發(fā)生錯誤。言外之意是應對錯誤的修改進行測試，也 許比對原先程序的測試還要嚴格。一個嚴格的回歸測試計劃可以確保對某個錯 誤的修改沒有在程序的其他位置引入另外的錯誤。4.正確修改錯誤的可能性隨著程序規(guī)模的增加而降低換句話說，根據我們的經驗，由于修改不正確而引人的錯誤與原始錯誤之比，在規(guī)模較大的程序中呈遞增趨勢。對于一個廣泛使用的大型程序，每發(fā)現(xiàn)6 個新錯誤，其中就有 l 個錯誤是由干先前對程序的改正而造成的。5.應意識改正錯誤會引入新錯誤的可能性 我們不僅需要考慮到不正確的修改，而且還必須考慮到某個看似正確的修改會產生未料到的副作用，比如引入了一個新錯誤。不僅存在修改無效的可能，還存在修改引入了新錯誤的可能。言外之意是，不僅應在修改之后對錯誤的情 境進行測試，還應執(zhí)行回歸測試以判斷是否引入了新錯誤。6.修改錯誤的過程也是臨時回到設計階段的過程 我們應該認識到修改錯誤也是程序設計的一種形式。在認識到修改易產生錯誤的性質之后，常識告訴我們，在設計階段使用的任何規(guī)程、方法和形式都同樣適用于錯誤修改階段。舉例來說，如果項目證明代碼檢查很管用，那么在 修改錯誤之后進行代碼檢查就顯得倍加重要。7.應修改源代碼，而不是目標代碼 在調試大型系統(tǒng)，尤其是用匯編語言編寫的系統(tǒng)時，偶爾會存在這樣的修改錯誤的傾向，即先立即修改目標代碼稍后再修改源程序這種方法帶來了兩個問題，（1）這通常是“通過試驗進行調試”的信號；（2）目標代碼與源程 序不同步，這意味著當程序重新編譯或重新匯編之后，同樣的錯誤很容易又浮 現(xiàn)出來，這是一種草率的、不專業(yè)的調試方法。7