當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

麻省理工18年春软件构造课程阅读13“调试”

發布時間：2023/12/10 编程问答 38 豆豆

生活随笔收集整理的這篇文章主要介紹了麻省理工18年春软件构造课程阅读13“调试” 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

本文內容來自MIT_6.031_sp18: Software Construction課程的Readings部分，采用CC BY-SA 4.0協議。

由于我們學校（哈工大）大二軟件構造課程的大部分素材取自此，也是推薦的閱讀材料之一，于是打算做一些翻譯工作，自己學習的同時也能幫到一些懶得看英文的朋友。另外，該課程的閱讀資料中有的練習題沒有標準答案，所給出的“正確答案”為譯者所寫，有錯誤的地方還請指出。

（更新：從第10章開始只翻譯正確答案）

譯者：李秋豪

審校：

V1.0 Sun Apr 22 17:13:43 CST 2018

本次課程的目標

今天的課程旨在告訴你如何系統的進行調試（systematic debugging）。

有時候你除了調試別無選擇——特別是bug只在整合整個系統后才出現，或者是由用戶使用后報告的（一般很難定位bug的位置）。對于這些情況，我們就可以使用系統的策略來提高調試的效率。

關于調試有一本很好的書： Why Programs Fail，本次閱讀材料的很大部分素材都來自于它。

復現bug

首先我們要做的是找到一個小、能夠重復產生bug/failure的測試用例。如果這個bug是在回歸測試中發現的，那么很幸運，你已經有了這樣的測試用例。但如果這個bug是由用戶報告的，你可能需要一些努力才能復現它。特別是對于GUI和多線程程序，bug的產生可能依賴于事件的事件和線程的執行，其復現會變得很困難。

然而，你為找到測試用例所付出的努力都會是值得的，因為你在后面搜尋bug和修復bug的時候都會不斷用到它。另外，當你成功修復bug后，應該將復現bug的測試用例添加到測試套件中進行回歸測試，確保bug不會再次發生。當你有針對bug的測試用例后，讓測試通過就變成了你的目標。

下面給出了一個例子。假設你寫了這樣一個方法：

/*** Find the most common word in a string.* @param text string containing zero or more words, where a word* is a string of alphanumeric characters bounded by nonalphanumerics.* @return a word that occurs maximally often in text, ignoring alphabetic case.*/ public static String mostCommonWord(String text) {... }

一個用戶將莎士比亞的戲劇作為輸入調用了這個方法，比如說mostCommonWord(allShakespearesPlaysConcatenated), 并且發現這個方法并沒有像 "the" 或 "a" 這樣的英語單詞，而是返回了意料之外的"e".

莎士比亞的戲劇有超過100000行的規模以及超過800000個單詞的豐富度，所以這樣的輸入會讓普通的調試變得非常困難，例如使用print或者斷點來調試。所以我們的第一個工作就是減少輸入的規模，同事確保程序會產生相同或相似的bug，這有很多思路：

只使用原輸入的前一半，bug還會發生嗎？（二分查找！這總是一個不錯的主意）
戲劇中單行的輸入會有同樣的bug嗎？
戲劇中單章的輸入會有同樣的bug嗎？

一旦你找到了小的測試用例，接下來就使用這個測試用例來修復bug，然后用原輸入再次測試，確保你修復了相同的bug。

閱讀小練習

Reducing a bug to a test case

假設用戶報告說 mostCommonWord("chicken chicken chicken beef") 返回 "beef" 而非 "chicken".

為了在調試前縮短和簡化輸入，以下哪一個輸入是值得嘗試的？

[x] mostCommonWord("chicken chicken beef")
[ ] mostCommonWord("Chicken Chicken Chicken beef")
[ ] mostCommonWord("chicken beef")
[ ] mostCommonWord("a b c")
[x] mostCommonWord("b b c")

注意，選出所有可能的選項而不只是最簡單的那個（因為最簡單的測試用例可能不會復現bug！）

Regression testing

假設你將輸入 "chicken chicken chicken beef" 簡化為了 "c c b" （依然能夠觸發bug）。隨后你利用這個測試修復了bug，然后觀察到 "c c b" 和 "chicken chicken chicken beef" 都可以返回正確的答案。

現在你應該在測試用例套件中加上哪一個測試用例？

[ ] assertEquals("chicken", mostCommonWord("chicken chicken chicken beef"))
[x] assertEquals("c", mostCommonWord("c c b"))
[ ] assertEquals("c", mostCommonWord("c b"))
[ ] you shouldn’t change the test suite, because you haven’t changed the spec

用科學的方法發現bug

為了找到bug和它產生的原因，你可以使用以下方法：

研究數據. 通過推敲產生bug的測試用例，產生的錯誤結果，失敗的斷言檢查及其對應的棧情況。

提出假設. 針對剛剛的研究提出假設：bug大概是在什么位置，不可能在什么位置，大概是什么原因。首先做一個大致的假設總是有幫助的。

進行試驗. 針對你的假設進行試驗。試驗時記得對過程進行觀察——例如放置“探針”收集數據（對系統的影響越小越好）。

重復之前步驟. 分析剛剛試驗的數據，結合你已經知道和推理出來的結論，做出新的假設。這通常意味著你將bug的范圍縮小或者產生的原因明確了。

上述的4個步驟并不一定對每一個bug都是需要的。如果你設計符合“快速失敗”，那么bug很可能就在異常附近，棧蹤跡也會幫助你很快發現錯誤的位置。那么什么時候需要使用上面提到的調試方法呢？一個不錯的判斷方法就是“十分鐘規則”。如果你利用非系統的/ad-hoc（譯者注：指臨時決定的）手段調試超過10分鐘，那么你就需要利用科學系統的方法重頭開始調試了。

作為這種轉變的一部分，你也需要將你的調試過程從腦袋中拿出來——它的“內存”很有限——并開始做筆記（紙上或者電腦上），內容包括：

假設. 基于現在你知道到的，對bug的位置和原因提出假設。
試驗. 你將會怎么對假設進行試驗。
預言. 基于你的假設，試驗的結果會是什么？
觀察. 試驗的最終結果是什么。

這些筆記應該和你之前上過的科學課的筆記很像。在接下來的幾節中，我們會介紹在調試代碼時會用到的各種類型的假設、試驗。

閱讀小練習

Scientific method

基于我們上面講過的“科學調試方法”，判斷以下各個陳述應該屬于調試的哪一個階段？

用戶報告 mostCommonWord("chicken chicken chicken beef") 返回 "beef" 而不是 "chicken".

--> 研究數據

并不是造成錯誤的原因，真正應該在意的是它們出現的次數。

--> 提出假設

運行測試用例 mostCommonWord("a a a b").

--> 進行試驗

1. 研究數據

棧蹤跡（stack trace）是異常中很重要的一個信息，因為它們會告訴你關于bug位置和原因的各種信息。

在棧蹤跡中，頂部是最近一次的調用，最早的調用在底部。有時候頂部的調用是你自己的代碼，但是異常也可能是由你的代碼調用的庫函數拋出的，這時頂部的調用就不是你的代碼了。與此相似，底部的調用即可能是你的 main 方法，也可能是最終調用你的方法的系統代碼。

總之，你的代碼（bug最可能發生的地方）經常會出現在棧蹤跡的中間部分。

閱讀小練習

Reading a stack trace

假設你在運行Java程序后收到了一個異常，并得到了以下棧蹤跡：

java.lang.NullPointerExceptionat java.util.Objects.requireNonNull(Objects.java:203)at java.util.AbstractSet.removeAll(AbstractSet.java:169)at turtle.TurtleSoup.drawPersonalArt(TurtleSoup.java:29)at turtle.TurtleSoupTest.testPersonalArt(TurtleSoupTest.java:39)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:498)at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)at org.junit.runners.ParentRunner.run(ParentRunner.java:363)at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

哪一行代碼真正拋出了這個異常？

文件名: Objects.java

行數: 203

當異常被拋出時，你的代碼所執行的最后一句是什么？

文件名: TurtleSoup.java

行數: 29

你的代碼的入口點是什么？即你的代碼被第一次調用是在哪里？

方法名稱: testPersonalArt

2. 提出假設

我們知道，異常拋出的地方并不一定是bug的起源位置，即有bug的代碼可能會將錯誤結果傳給正常代碼，正常代碼在執行后才會拋出異常。所以你的假設應該是針對bug的起源位置以及它產生的原因。

一個很有幫助的方法就是將你的程序想象成一個數據流，或者是一個算法的幾個步驟。現在讓我們思考一下 mostCommonWord() 這個例子（通過三個幫助方法明確了步驟）：

/*** Find the most common word in a string.* ...*/ public static String mostCommonWord(String text) {List<String> words = splitIntoWords(text);Map<String,Integer> frequencies = countOccurrences(words);String winner = findMostFrequent(frequencies);return winner; }

mostCommonWord() 的數據流如下圖所示：

假設我們在 countOccurrences()中得到了一個異常。那么我們可以在分析錯誤的時候將 countOccurrences()以后的數據流排除在外，例如我們沒有必要去 findMostFrequent()中檢查bug，因為異常以后的控制流在異常發生時還沒有執行到。

基于已知的信息，我們可以逆序對錯誤的原因進行假設：

bug在 countOccurrences之中：它的輸入合法但是卻拋出了異常。
bug存在于 splitIntoWords 和 countOccurrences的連接中：這兩個方法都遵守了契約，但前者的后置條件沒有滿足后者的前置條件，所以產生了bug。
bug存在于 splitIntoWords中：它的輸入合法但是卻拋出了異常
bug存在于 mostCommonWord的輸入：即text未能滿足這個方法的前置條件。

應該從哪一個假設開始呢？調試是一個搜索的過程，所以你可以使用二分查找來加速這個過程——先將數據流對半分開，例如假設bug存在于第一個方法和第二個方法的連接中，然后利用下面會提到方法（例如打印狀態、斷點、斷言）來對假設進行試驗。最后通過試驗的結果判斷bug存在于前半部分還是后半部分。

切片

上面 mostCommonWord() 的數據流就是一個切片（slicing）的例子。它意思是說找到程序中計算出特定值的那個片段（slice）。當你的程序報錯時——即程序計算出了一個錯誤的值，對應的片段就是那些（幫助）計算出錯誤的值的代碼。bug就存在于這個片段之中，也就是你的搜索范圍。

對于切片操作有自動化工具，不過它們還不是很有效。但是程序員也會自然的進行切片——在腦海里——對bug可能存在或不可能存在的地方做出假設。這對于程序審查是很有用的技巧，我們接下來就對它加深一下理解。

這里有一個例子。假設x是一個整型局部變量，它的值不應該為負。但是在某一個時候調試的print語句輸出了錯誤的結果：

int x = 0; // must be >= 0 ... System.out.println("x=" + x); // prints a negative number

產生錯誤結果的片段會是哪一個呢？讓我們對...部分做一下研究，找出合理的代碼。

首先我們要找出直接對x賦值的語句：

int x = 0; // must be >= 0 ...x += bonus; ... System.out.println("x=" + x); // prints a negative number

由于 bonus 會對x的結果產生影響，所以和它相關的代碼也應該在片段之中：

int x = 0; // must be >= 0 final int bonus = getBonus(); ...x += bonus; ... System.out.println("x=" + x); // prints a negative number

所以現在 getBonus() 也應該在片段之中，因為它負責計算 bonus 。

片段也應該包括能夠影響已有片段的分支控制語句：

int x = 0; final int bonus = getBonus(); ...if (isWorthABonus(s)) {x += bonus;} ... System.out.println("x=" + x); // prints a negative number

if 語句控制了 x += bonus 是否會被執行，而這也讓方法 isWorthABonus()成為了片段的一部分，而 s 又是該方法的參數，所以和s有關的語句也屬于片段：

int x = 0; final int bonus = getBonus(); ... for (final Sale s : salesList) {...if (isWorthABonus(s)) {x += bonus;}... } ... System.out.println("x=" + x); // prints a negative number

for 不僅決定了s值，間接決定了 x += bonus是否會被執行，也影響了 x += bonus會被執行了次數。

現在，由于 for 語句使用到了 salesList，所以我們也應該將其包含到片段之中，我們發現 salesList是一個參數：

int calculateTotalBonus(final List<Sale> salesList) {...int x = 0;final int bonus = getBonus();...for (final Sale s : salesList) {...if (isWorthABonus(s)) {x += bonus;}...}...System.out.println("x=" + x); // prints a negative number... }

我們可以繼續深入，分析 salesList 是如何生成并傳入的，但是現在先停下來。我們已經找到了這個方法內計算x語句的片段（代碼）。接下來要做的就是研究這個片段中的代碼并提出有用的假設：

x+=bonus 賦值語句：可能是由于 bonus 為負數，所以 x+=bonus 最終的結果為負了。這個假設也間接指明了 getBonus() 返回了負的結果。
if 分支控制：可能 isWorthABonus() 返回太多次true，導致 x 的加法溢出，產生了負的結果。
for 循環語句：可能是這個循環的次數過多，最終導致 x 的加法溢出，產生了負的結果。
方法的參數：可能 salesList傳入了一個不好的值，里面有太多的“sales”。

通過小心的切片操作（閱讀代碼），我們成功分析出了哪一些代碼是可能存在bug的，哪一些是不會對bug產生貢獻的。例如上面的 ... 在查找bug時就可排除在外。

值得一提的是，我們的設計可以幫助（或者阻礙）我們進行切片。其中一個良好的設計就是使用不變性（immutability）。例如在上面對 bonus進行切片時，我們看到它的聲明是final int bonus = getBonus(), 我們立即意識到這是一個不變索引指向的不變對象，所以我們也不用再尋找 bonus的代碼片段了。這會大大節省我們的時間。不過，當我們看到 final Sale s時，雖然s的索引不可能改變，但是Sale是一個可變類型，所以我們依然要注意s的改造者的使用。

另一個良好的設計就是將作用域最小化。上面的例子中所有的變量都是局部變量，而且作用域都是最小的，所以我們的搜索范圍也會跟著減少。相反，如果我們是用的實例成員，那么搜索范圍將擴大到整個類，如果使用的是全局變量，那么搜索范圍將擴大到整個程序。

閱讀小練習

Slicing

在以下代碼中，哪些行屬于 tax 對應的切片片段？

double total = 0.0; double tax = 0.0; double taxRate = 0.06; for (final Item item : items) {total += item.getPrice();if (isOutOfStateCustomer) {taxRate /= 2;}if (item.isTaxable()) {tax += item.getPrice() * taxRate;} } total += tax; return total;

[ ] double total = 0.0;
[x] double tax = 0.0;
[x] double taxRate = 0.06;
[x] for (final Item item : items) {
[ ] total += item.getPrice();
[x] if (isOutOfStateCustomer) {
[ ] taxRate /= 2;
[x] if (item.isTaxable()) {
[x] tax += item.getPrice() * taxRate;
[ ] total += tax;
[ ] return total;

Slicing 2

在以下代碼中，哪些行屬于 a 對應的切片片段？

int[] incrementAll(int[] a) {int[] b = a;for (int i = 0; i < a.length; ++i) {++b[i];}return b; }

[x] int[] incrementAll(int[] a) {
[x] int[] b = a;
[x] for (int i = 0; i < a.length; ++i) {
[x] ++b[i];
[ ] return b;

譯者注：這里注意別名

Delta(Δ)調試法

這種調試方法主要是用到了測試用例之間的區別，即如果兩個相似的測試用例測試后有不同的結果，那么bug很可能就是由它們的差別部分導致的。例如 mostCommonWords("c c b")測試工作正常，但是 mostCommonWords("c c, b") 卻失敗了，那么問題很可能就出在c,和c之間的差別上。

這種調試方法由于看重于成功與失敗的差異，被稱作 delta 調試。delta調試也有自動化的工作，不過現在還沒有廣泛的應用。

假設的優先級

當你在對bug的位置和原因提出假設時，心里應該有一個大致的構想，哪一個區域的產生bug的可能性大，哪一個區域可能性小。例如，對于已經被良好測試過并長期使用過的模塊，我們就會認為它出現bug的可能性很低。Java的編譯器，JVM，操作系統，Java庫設置硬件都應該比你寫的代碼更加可信（譯者注：當然你也可能是Linus這樣的天才...），因為它們都經過大量的調試和測試。在沒有好的理由前，你不應該懷疑這些（底層）的模塊和平臺。

閱讀小練習

Priorities

假設你正在調試 quadraticRoots 方法：

/*** Solves quadratic equation ax^2 + bx + c = 0.* * @param a quadratic coefficient, requires a != 0* @param b linear coefficient* @param c constant term* @return a list of the real roots of the equation*/ public static List<Double> quadraticRoots(int a, int b, int c) { ... }

將下面的行為做一個優先級排序，即你應該先進行什么假設:

將 ArrayList替換為 LinkedList. --> 4

在方法中嵌入一些 println() 語句打印出計算過程的中間值 --> 3

寫出能夠使bug復現的測試用例 --> 1

使用覆蓋率工具檢查是否有測試沒有覆蓋到的代碼 --> 2

3. 進行試驗

你提出的假設應該有前置條件，例如“我認為x在這個時刻有一個不合法的值”或者“我認為這一行代碼永遠不會被執行”。而你的試驗應該去測試這個前置條件是否被滿足。最好的試驗應該像“探針（probe）”一樣，在最小化對系統的影響下觀察系統的狀態。

一個常見的探針就是print語句。它的一個優點就是幾乎能在所有的編程語言中實現。缺點在于你必須記住在試驗完成后去掉這些print。要注意的是，不要在多個print中輸出同樣或者沒有描述性的語句，例如在很多位置都僅僅輸出hi!，你很可能就會不知道到底是哪一個位置在輸出，與此相反， start of calculateTotalBonus這樣的輸出就很有意義，也很清楚。

另一種常用的探針是斷言檢查，它會測試變量的值或者對象的內部狀態。在上面的例子中，x不允許為負數，我們就可以插入 assert(x >= 0); 語句。斷言的優點在于你不需要自己去檢查狀態，而且斷言不會在調試和測試完成后殘留在程序中。它的缺點在于Java默認是關閉斷言的，所以有時間你會發現斷言檢查總是通過，其實是它們沒有被執行。我們在之前的閱讀中談到過斷言相關的問題。

第三種探針是調試器（debugger）中的斷點，它會使程序在特定的地方停下來，并允許你進行單步執行或檢查此時程序的各種狀態。調試器是一種很強大的工具，你應該花一些時間去學習它。

閱讀小練習

Probes

下面是一個已經被調試過的程序，不過里面還殘留了一些“探針”：

/*** Convert from one currency to another.* @param fromCurrency currency that customer has (e.g. DOLLAR)* @param fromValue value of fromCurrency that customer has (e.g. $145.23)* @param toCurrency currency that customer wants (e.g. EURO). * Must be different from fromCurrency.* @return value of toCurrency that customer will get,* after applying the conversion rate and bank fee*/ public static double convertCurrency(Currency fromCurrency, double fromValue, Currency toCurrency) {assert(fromCurrency != null && toCurrency != null);assert(! fromCurrency.equals(toCurrency));double rate = getConversionRate(fromCurrency, toCurrency);System.out.println("conversion rate is " + rate);double fee = getFee();assert(fee == 0.01); // right now the bank charges 1%return fromValue * rate * (1-fee); }

在提交（commit+push）代碼之前，哪一些語句應該被移除？

[ ] assert(fromCurrency != null && toCurrency != null);
[ ] assert(! fromCurrency.equals(toCurrency));
[ ] double rate = getConversionRate(fromCurrency, toCurrency);
[x] System.out.println("conversion rate is " + rate);
[ ] double fee = getFee();
[x] assert(fee == 0.01); // right now the bank charges 1%
[ ] return fromValue * rate * (1-fee);

Using a debugger

在這個練習中，你需要使用到Eclipse或其他IDE。

創建一個新的Java類Hailstone.java：

import java.util.ArrayList; import java.util.List;public class Hailstone {public static List<Integer> hailstoneSequence(int n) {List<Integer> list = new ArrayList<Integer>();while (n != 1) {list.add(n);if (n % 2 == 0) {n = n / 2;} else {n = 3 * n + 1;}}list.add(n);return list;}public static void main(String[] args) {System.out.println("hailstoneSequence(5)=" + hailstoneSequence(5));}}

在第8行 (list.add(n)) 設置斷點，然后使用Run → Debug來運行調試器，程序應該在斷點位置停下來，通過調試器檢查相應的變量和程序狀態回答以下問題：

現在列表中有幾個元素？

現在使用單步執行 Step Over (Run → Step Over, 在工具欄上也有對應的按鈕) 來執行第8行語句，現在列表中有幾個元素？

現在繼續單步執行直到（或者Run → Resume）再次遇到第8行 list.add(n) ，然后使用Run → Step Into，現在你所在的方法叫什么名字？

Integer.valueOf()

最后使用Step Return返回剛剛的調用位置，然后再次執行Step Into，現在你所在的方法叫什么名字？

ArrayList.add()

交換內容

如果你假設bug存在的模塊是可以更換的，例如有不同的實現類，那么你可以試著將其更換為另一種接口相同的模塊，觀察bug是否依然存在，例如：

如果你懷疑 binarySearch() 的實現，那么將其更換為一個更簡單的 linearSearch()
如果你懷疑是tjava.util.ArrayList的鍋，將其換為 java.util.LinkedList
如果你懷疑JVM（Java運行時），試著使用一個不同版本的Java
如果你懷疑是操作系統的鍋，換一個操作系統試試。
如果你懷疑是硬件的鍋，那么在另一臺機器上試試

然而，你可能會在這種更換上浪費很多精力，正如前面所說，除非你有好的理由，不要首先懷疑這些經過大量測試或使用的模塊和平臺。

別急著修復

很多時候，程序員會試著在試驗的過程中同時修復bug，而不僅僅是設置并觀察探針。這中方法基本上都是錯誤的。首先，這會導致ad-hoc（譯者注：指臨時決定的）和猜想-測試編程。其次，你的修改通常僅僅“掩蓋”了bug而不是修復了它——就好比你是在治療癥狀而不是病理本身。

例如，如果你得到了 ArrayOutOfBoundsException異常，不要僅僅加上處理異常的語句（甚至忽略它），或者加上一個測試索引的語句。你應該弄清除異常發生的本質原因，已經它能否被完全避免。

閱讀小練習

Premature Fixes

下面這段代碼已經調試了好一會兒了：

/*** @return true if and only if word1 is an anagram of word2* (i.e. a permutation of its characters)*/ boolean isAnagram(String word1, String word2) {try {if (word1.equals("")) return word2.equals("");for (int i = 0; i < word1.length; ++i) {if (! word2.contains(word1.charAt(i))) return false;}if (! isAnagram(word2, word1)) return false;else if (word2.length() == word1.length()) return true;else return false;} catch (StackOverflowError e) { return true; } }

以下六個選項中哪一些可能僅僅“掩蓋”了bug而不是完全修復了它？

[x] if (word1.equals("")) return word2.equals("")
[ ] if (! word2.contains(word1.charAt(i))) return false;
[ ] if (! isAnagram(word2, word1)) return false;
[ ] else if (word2.length() == word1.length()) return true;
[ ] else return false;
[x] catch (StackOverflowError e) { return true; }

4. 重復之前步驟

在試驗之后，思考并修改你的假設。如果你發現試驗的結果和假設的前置條件相悖，那么就重新進行假設。如果符合前置條件，就重新設計假設，讓它更有針對性，即能夠將bug產生的位置范圍進一步縮小。然后重復進行上述步驟。

要注意的是，確保你的源代碼和目標文件是最新的。如果你的所有觀察都顯得不正常，一個可能的原因就是你正在運行的程序不是你現在的代碼。這個時候需要刪除所有編譯好的文件然后重新編譯（在Eclipse中是Project → Clean）。

修復bug

當你找到bug的位置并分析出它的本質原因后，接下來的步驟就是修復它。還是那句話，不要僅僅“掩蓋”住bug，而是要問問自己這個bug到底是怎么產生的，它是一個代碼拼寫錯誤？還是參數設計錯誤，還是接口不一致導致的錯誤？

在修改bug時，也要考慮到bug本身是否和其他位置的代碼或者位置的模塊有關聯，即修改代碼會不會帶來副作用。另外，也要想一想這種bug在別處是否存在（只是還沒有出現）。

在修復完成后，記得在你的測試套件中添加上這個bug的測試用例（回歸測試），然后重新進行測試，確保沒有新的bug出現。

一些別的建議

尋求別人的幫助. 向別人解釋你的設計通常都會幫助你理清思路，即使對方根本不知道你在說什么。這種方法被稱為小黃鴨調試法或者泰迪熊調試法。即在計算機實驗室里放一只巨大的泰迪熊，定下一條規則：當你試圖告訴別人你的設計前，先“告訴”這只泰迪熊——令人驚訝的是，這只泰迪熊解決了很多問題。向別人稱述你的代碼設計將有助于你認識到問題所在。

睡一覺. 如果你太累的話，調試會變得沒有效率，畢竟磨刀不誤砍柴工（Trade latency for efficiency）。

總結

在這篇閱讀中，我們學習了如何系統的進行調試：

構建測試用例復現bug，并將其添加到測試套件中
使用科學的方法發現bug：
- 調試提出假設
- 利用探針（print、assert、debugger）來觀察程序的行為并測試假設的前置條件是否滿足
徹底而非草率的修復bug

對于我們課程的三個目標，這篇閱讀主要針對的是遠離bug：我們試著剔除bug，并利用回歸測試防止bug重新出現。

轉載于:https://www.cnblogs.com/liqiuhao/p/8908365.html

總結

以上是生活随笔為你收集整理的麻省理工18年春软件构造课程阅读13“调试”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： java知识体系 servlet_03-
下一篇： css3 pointer-events: