麻省理工18年春软件构造课程阅读13“调试”
本文內(nèi)容來自MIT_6.031_sp18: Software Construction課程的Readings部分，采用CC BY-SA 4.0協(xié)議。
由于我們學(xué)校（哈工大）大二軟件構(gòu)造課程的大部分素材取自此，也是推薦的閱讀材料之一，于是打算做一些翻譯工作，自己學(xué)習的同時也能幫到一些懶得看英文的朋友。另外，該課程的閱讀資料中有的練習題沒有標準答案，所給出的“正確答案”為譯者所寫，有錯誤的地方還請指出。
（更新：從第10章開始只翻譯正確答案）
譯者：李秋豪
審校：
V1.0 Sun Apr 22 17:13:43 CST 2018
本次課程的目標
今天的課程旨在告訴你如何系統(tǒng)的進行調(diào)試（systematic debugging）。
有時候你除了調(diào)試別無選擇——特別是bug只在整合整個系統(tǒng)后才出現(xiàn)，或者是由用戶使用后報告的（一般很難定位bug的位置）。對于這些情況，我們就可以使用系統(tǒng)的策略來提高調(diào)試的效率。
關(guān)于調(diào)試有一本很好的書： Why Programs Fail，本次閱讀材料的很大部分素材都來自于它。
復(fù)現(xiàn)bug
首先我們要做的是找到一個小、能夠重復(fù)產(chǎn)生bug/failure的測試用例。如果這個bug是在回歸測試中發(fā)現(xiàn)的，那么很幸運，你已經(jīng)有了這樣的測試用例。但如果這個bug是由用戶報告的，你可能需要一些努力才能復(fù)現(xiàn)它。特別是對于GUI和多線程程序，bug的產(chǎn)生可能依賴于事件的事件和線程的執(zhí)行，其復(fù)現(xiàn)會變得很困難。
然而，你為找到測試用例所付出的努力都會是值得的，因為你在后面搜尋bug和修復(fù)bug的時候都會不斷用到它。另外，當你成功修復(fù)bug后，應(yīng)該將復(fù)現(xiàn)bug的測試用例添加到測試套件中進行回歸測試，確保bug不會再次發(fā)生。當你有針對bug的測試用例后，讓測試通過就變成了你的目標。
下面給出了一個例子。假設(shè)你寫了這樣一個方法：
/*** 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) {... }一個用戶將莎士比亞的戲劇作為輸入調(diào)用了這個方法，比如說mostCommonWord(allShakespearesPlaysConcatenated), 并且發(fā)現(xiàn)這個方法并沒有像 "the" 或 "a" 這樣的英語單詞，而是返回了意料之外的"e".
莎士比亞的戲劇有超過100000行的規(guī)模以及超過800000個單詞的豐富度，所以這樣的輸入會讓普通的調(diào)試變得非常困難，例如使用print或者斷點來調(diào)試。所以我們的第一個工作就是減少輸入的規(guī)模，同事確保程序會產(chǎn)生相同或相似的bug，這有很多思路：
- 只使用原輸入的前一半，bug還會發(fā)生嗎？（二分查找！這總是一個不錯的主意）
- 戲劇中單行的輸入會有同樣的bug嗎？
- 戲劇中單章的輸入會有同樣的bug嗎？
一旦你找到了小的測試用例，接下來就使用這個測試用例來修復(fù)bug，然后用原輸入再次測試，確保你修復(fù)了相同的bug。
閱讀小練習
Reducing a bug to a test case
假設(shè)用戶報告說 mostCommonWord("chicken chicken chicken beef") 返回 "beef" 而非 "chicken".
為了在調(diào)試前縮短和簡化輸入，以下哪一個輸入是值得嘗試的？
[x] mostCommonWord("chicken chicken beef")
[ ] mostCommonWord("Chicken Chicken Chicken beef")
[ ] mostCommonWord("chicken beef")
[ ] mostCommonWord("a b c")
[x] mostCommonWord("b b c")
注意，選出所有可能的選項而不只是最簡單的那個（因為最簡單的測試用例可能不會復(fù)現(xiàn)bug！）
Regression testing
假設(shè)你將輸入 "chicken chicken chicken beef" 簡化為了 "c c b" （依然能夠觸發(fā)bug）。隨后你利用這個測試修復(fù)了bug，然后觀察到 "c c b" 和 "chicken chicken chicken beef" 都可以返回正確的答案。
現(xiàn)在你應(yīng)該在測試用例套件中加上哪一個測試用例？
- [ ] 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
用科學(xué)的方法發(fā)現(xiàn)bug
為了找到bug和它產(chǎn)生的原因，你可以使用以下方法：
上述的4個步驟并不一定對每一個bug都是需要的。如果你設(shè)計符合“快速失敗”，那么bug很可能就在異常附近，棧蹤跡也會幫助你很快發(fā)現(xiàn)錯誤的位置。那么什么時候需要使用上面提到的調(diào)試方法呢？一個不錯的判斷方法就是“十分鐘規(guī)則”。如果你利用非系統(tǒng)的/ad-hoc（譯者注：指臨時決定的）手段調(diào)試超過10分鐘，那么你就需要利用科學(xué)系統(tǒng)的方法重頭開始調(diào)試了。
作為這種轉(zhuǎn)變的一部分，你也需要將你的調(diào)試過程從腦袋中拿出來——它的“內(nèi)存”很有限——并開始做筆記（紙上或者電腦上），內(nèi)容包括：
- 假設(shè). 基于現(xiàn)在你知道到的，對bug的位置和原因提出假設(shè)。
- 試驗. 你將會怎么對假設(shè)進行試驗。
- 預(yù)言. 基于你的假設(shè)，試驗的結(jié)果會是什么？
- 觀察. 試驗的最終結(jié)果是什么。
這些筆記應(yīng)該和你之前上過的科學(xué)課的筆記很像。在接下來的幾節(jié)中，我們會介紹在調(diào)試代碼時會用到的各種類型的假設(shè)、試驗。
閱讀小練習
Scientific method
基于我們上面講過的“科學(xué)調(diào)試方法”，判斷以下各個陳述應(yīng)該屬于調(diào)試的哪一個階段？
用戶報告 mostCommonWord("chicken chicken chicken beef") 返回 "beef" 而不是 "chicken".
--> 研究數(shù)據(jù)
并不是造成錯誤的原因，真正應(yīng)該在意的是它們出現(xiàn)的次數(shù)。
--> 提出假設(shè)
運行測試用例 mostCommonWord("a a a b").
--> 進行試驗
1. 研究數(shù)據(jù)
棧蹤跡（stack trace）是異常中很重要的一個信息，因為它們會告訴你關(guān)于bug位置和原因的各種信息。
在棧蹤跡中，頂部是最近一次的調(diào)用，最早的調(diào)用在底部。有時候頂部的調(diào)用是你自己的代碼，但是異常也可能是由你的代碼調(diào)用的庫函數(shù)拋出的，這時頂部的調(diào)用就不是你的代碼了。與此相似，底部的調(diào)用即可能是你的 main 方法，也可能是最終調(diào)用你的方法的系統(tǒng)代碼。
總之，你的代碼（bug最可能發(fā)生的地方）經(jīng)常會出現(xiàn)在棧蹤跡的中間部分。
閱讀小練習
Reading a stack trace
假設(shè)你在運行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
行數(shù): 203
當異常被拋出時，你的代碼所執(zhí)行的最后一句是什么？
文件名: TurtleSoup.java
行數(shù): 29
你的代碼的入口點是什么？即你的代碼被第一次調(diào)用是在哪里？
方法名稱: testPersonalArt
2. 提出假設(shè)
我們知道，異常拋出的地方并不一定是bug的起源位置，即有bug的代碼可能會將錯誤結(jié)果傳給正常代碼，正常代碼在執(zhí)行后才會拋出異常。所以你的假設(shè)應(yīng)該是針對bug的起源位置以及它產(chǎn)生的原因。
一個很有幫助的方法就是將你的程序想象成一個數(shù)據(jù)流，或者是一個算法的幾個步驟。現(xiàn)在讓我們思考一下 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() 的數(shù)據(jù)流如下圖所示：
假設(shè)我們在 countOccurrences()中得到了一個異常。那么我們可以在分析錯誤的時候?qū)?countOccurrences()以后的數(shù)據(jù)流排除在外，例如我們沒有必要去 findMostFrequent()中檢查bug，因為異常以后的控制流在異常發(fā)生時還沒有執(zhí)行到。
基于已知的信息，我們可以逆序?qū)﹀e誤的原因進行假設(shè)：
- bug在 countOccurrences之中：它的輸入合法但是卻拋出了異常。
- bug存在于 splitIntoWords 和 countOccurrences的連接中：這兩個方法都遵守了契約，但前者的后置條件沒有滿足后者的前置條件，所以產(chǎn)生了bug。
- bug存在于 splitIntoWords中：它的輸入合法但是卻拋出了異常
- bug存在于 mostCommonWord的輸入：即text未能滿足這個方法的前置條件。
應(yīng)該從哪一個假設(shè)開始呢？調(diào)試是一個搜索的過程，所以你可以使用二分查找來加速這個過程——先將數(shù)據(jù)流對半分開，例如假設(shè)bug存在于第一個方法和第二個方法的連接中，然后利用下面會提到方法（例如打印狀態(tài)、斷點、斷言）來對假設(shè)進行試驗。最后通過試驗的結(jié)果判斷bug存在于前半部分還是后半部分。
切片
上面 mostCommonWord() 的數(shù)據(jù)流就是一個切片（slicing）的例子。它意思是說找到程序中計算出特定值的那個片段（slice）。當你的程序報錯時——即程序計算出了一個錯誤的值，對應(yīng)的片段就是那些（幫助）計算出錯誤的值的代碼。bug就存在于這個片段之中，也就是你的搜索范圍。
對于切片操作有自動化工具，不過它們還不是很有效。但是程序員也會自然的進行切片——在腦海里——對bug可能存在或不可能存在的地方做出假設(shè)。這對于程序?qū)彶槭呛苡杏玫募记?#xff0c;我們接下來就對它加深一下理解。
這里有一個例子。假設(shè)x是一個整型局部變量，它的值不應(yīng)該為負。但是在某一個時候調(diào)試的print語句輸出了錯誤的結(jié)果：
int x = 0; // must be >= 0 ... System.out.println("x=" + x); // prints a negative number產(chǎn)生錯誤結(jié)果的片段會是哪一個呢？讓我們對...部分做一下研究，找出合理的代碼。
首先我們要找出直接對x賦值的語句：
int x = 0; // must be >= 0 ...x += bonus; ... System.out.println("x=" + x); // prints a negative number由于 bonus 會對x的結(jié)果產(chǎn)生影響，所以和它相關(guān)的代碼也應(yīng)該在片段之中：
int x = 0; // must be >= 0 final int bonus = getBonus(); ...x += bonus; ... System.out.println("x=" + x); // prints a negative number所以現(xiàn)在 getBonus() 也應(yīng)該在片段之中，因為它負責計算 bonus 。
片段也應(yīng)該包括能夠影響已有片段的分支控制語句：
int x = 0; final int bonus = getBonus(); ...if (isWorthABonus(s)) {x += bonus;} ... System.out.println("x=" + x); // prints a negative numberif 語句控制了 x += bonus 是否會被執(zhí)行，而這也讓方法 isWorthABonus()成為了片段的一部分，而 s 又是該方法的參數(shù)，所以和s有關(guān)的語句也屬于片段：
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 numberfor 不僅決定了s值，間接決定了 x += bonus是否會被執(zhí)行，也影響了 x += bonus會被執(zhí)行了次數(shù)。
現(xiàn)在，由于 for 語句使用到了 salesList，所以我們也應(yīng)該將其包含到片段之中，我們發(fā)現(xiàn) salesList是一個參數(shù)：
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... }我們可以繼續(xù)深入，分析 salesList 是如何生成并傳入的，但是現(xiàn)在先停下來。我們已經(jīng)找到了這個方法內(nèi)計算x語句的片段（代碼）。接下來要做的就是研究這個片段中的代碼并提出有用的假設(shè)：
- x+=bonus 賦值語句：可能是由于 bonus 為負數(shù)，所以 x+=bonus 最終的結(jié)果為負了。這個假設(shè)也間接指明了 getBonus() 返回了負的結(jié)果。
- if 分支控制：可能 isWorthABonus() 返回太多次true，導(dǎo)致 x 的加法溢出，產(chǎn)生了負的結(jié)果。
- for 循環(huán)語句：可能是這個循環(huán)的次數(shù)過多，最終導(dǎo)致 x 的加法溢出，產(chǎn)生了負的結(jié)果。
- 方法的參數(shù)：可能 salesList傳入了一個不好的值，里面有太多的“sales”。
通過小心的切片操作（閱讀代碼），我們成功分析出了哪一些代碼是可能存在bug的，哪一些是不會對bug產(chǎn)生貢獻的。例如上面的 ... 在查找bug時就可排除在外。
值得一提的是，我們的設(shè)計可以幫助（或者阻礙）我們進行切片。其中一個良好的設(shè)計就是使用不變性（immutability）。例如在上面對 bonus進行切片時，我們看到它的聲明是final int bonus = getBonus(), 我們立即意識到這是一個不變索引指向的不變對象，所以我們也不用再尋找 bonus的代碼片段了。這會大大節(jié)省我們的時間。不過，當我們看到 final Sale s時，雖然s的索引不可能改變，但是Sale是一個可變類型，所以我們依然要注意s的改造者的使用。
另一個良好的設(shè)計就是將作用域最小化。上面的例子中所有的變量都是局部變量，而且作用域都是最小的，所以我們的搜索范圍也會跟著減少。相反，如果我們是用的實例成員，那么搜索范圍將擴大到整個類，如果使用的是全局變量，那么搜索范圍將擴大到整個程序。
閱讀小練習
Slicing
在以下代碼中，哪些行屬于 tax 對應(yīng)的切片片段？
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 對應(yīng)的切片片段？
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(Δ)調(diào)試法
這種調(diào)試方法主要是用到了測試用例之間的區(qū)別，即如果兩個相似的測試用例測試后有不同的結(jié)果，那么bug很可能就是由它們的差別部分導(dǎo)致的。例如 mostCommonWords("c c b")測試工作正常，但是 mostCommonWords("c c, b") 卻失敗了，那么問題很可能就出在c,和c之間的差別上。
這種調(diào)試方法由于看重于成功與失敗的差異，被稱作 delta 調(diào)試 。delta調(diào)試也有自動化的工作，不過現(xiàn)在還沒有廣泛的應(yīng)用。
假設(shè)的優(yōu)先級
當你在對bug的位置和原因提出假設(shè)時，心里應(yīng)該有一個大致的構(gòu)想，哪一個區(qū)域的產(chǎn)生bug的可能性大，哪一個區(qū)域可能性小。例如，對于已經(jīng)被良好測試過并長期使用過的模塊，我們就會認為它出現(xiàn)bug的可能性很低。Java的編譯器，JVM，操作系統(tǒng)，Java庫設(shè)置硬件都應(yīng)該比你寫的代碼更加可信（譯者注：當然你也可能是Linus這樣的天才...），因為它們都經(jīng)過大量的調(diào)試和測試。在沒有好的理由前，你不應(yīng)該懷疑這些（底層）的模塊和平臺。
閱讀小練習
Priorities
假設(shè)你正在調(diào)試 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) { ... }將下面的行為做一個優(yōu)先級排序，即你應(yīng)該先進行什么假設(shè):
將 ArrayList替換為 LinkedList. --> 4
在方法中嵌入一些 println() 語句打印出計算過程的中間值 --> 3
寫出能夠使bug復(fù)現(xiàn)的測試用例 --> 1
使用覆蓋率工具檢查是否有測試沒有覆蓋到的代碼 --> 2
3. 進行試驗
你提出的假設(shè)應(yīng)該有前置條件，例如“我認為x在這個時刻有一個不合法的值”或者“我認為這一行代碼永遠不會被執(zhí)行”。而你的試驗應(yīng)該去測試這個前置條件是否被滿足。最好的試驗應(yīng)該像“探針（probe）”一樣，在最小化對系統(tǒng)的影響下觀察系統(tǒng)的狀態(tài)。
一個常見的探針就是print語句。它的一個優(yōu)點就是幾乎能在所有的編程語言中實現(xiàn)。缺點在于你必須記住在試驗完成后去掉這些print。要注意的是，不要在多個print中輸出同樣或者沒有描述性的語句，例如在很多位置都僅僅輸出hi!，你很可能就會不知道到底是哪一個位置在輸出，與此相反， start of calculateTotalBonus這樣的輸出就很有意義，也很清楚。
另一種常用的探針是斷言檢查，它會測試變量的值或者對象的內(nèi)部狀態(tài)。在上面的例子中，x不允許為負數(shù)，我們就可以插入 assert(x >= 0); 語句。斷言的優(yōu)點在于你不需要自己去檢查狀態(tài)，而且斷言不會在調(diào)試和測試完成后殘留在程序中。它的缺點在于Java默認是關(guān)閉斷言的，所以有時間你會發(fā)現(xiàn)斷言檢查總是通過，其實是它們沒有被執(zhí)行。我們在之前的閱讀中談到過斷言相關(guān)的問題。
第三種探針是調(diào)試器（debugger）中的斷點，它會使程序在特定的地方停下來，并允許你進行單步執(zhí)行或檢查此時程序的各種狀態(tài)。調(diào)試器是一種很強大的工具，你應(yīng)該花一些時間去學(xué)習它。
閱讀小練習
Probes
下面是一個已經(jīng)被調(diào)試過的程序，不過里面還殘留了一些“探針”：
/*** 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）代碼之前，哪一些語句應(yīng)該被移除？
[ ] 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。
創(chuàng)建一個新的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)) 設(shè)置斷點，然后使用Run → Debug來運行調(diào)試器，程序應(yīng)該在斷點位置停下來，通過調(diào)試器檢查相應(yīng)的變量和程序狀態(tài)回答以下問題：
現(xiàn)在列表中有幾個元素？
0
現(xiàn)在使用單步執(zhí)行 Step Over (Run → Step Over, 在工具欄上也有對應(yīng)的按鈕) 來執(zhí)行第8行語句，現(xiàn)在列表中有幾個元素？
1
現(xiàn)在繼續(xù)單步執(zhí)行直到（或者Run → Resume）再次遇到第8行 list.add(n) ，然后使用Run → Step Into，現(xiàn)在你所在的方法叫什么名字？
Integer.valueOf()
最后使用Step Return返回剛剛的調(diào)用位置，然后再次執(zhí)行Step Into，現(xiàn)在你所在的方法叫什么名字？
ArrayList.add()
交換內(nèi)容
如果你假設(shè)bug存在的模塊是可以更換的，例如有不同的實現(xiàn)類，那么你可以試著將其更換為另一種接口相同的模塊，觀察bug是否依然存在，例如：
- 如果你懷疑 binarySearch() 的實現(xiàn)，那么將其更換為一個更簡單的 linearSearch()
- 如果你懷疑是tjava.util.ArrayList的鍋，將其換為 java.util.LinkedList
- 如果你懷疑JVM（Java運行時），試著使用一個不同版本的Java
- 如果你懷疑是操作系統(tǒng)的鍋，換一個操作系統(tǒng)試試。
- 如果你懷疑是硬件的鍋，那么在另一臺機器上試試
然而，你可能會在這種更換上浪費很多精力，正如前面所說，除非你有好的理由，不要首先懷疑這些經(jīng)過大量測試或使用的模塊和平臺。
別急著修復(fù)
很多時候，程序員會試著在試驗的過程中同時修復(fù)bug，而不僅僅是設(shè)置并觀察探針。這中方法基本上都是錯誤的。首先，這會導(dǎo)致ad-hoc（譯者注：指臨時決定的）和猜想-測試編程。其次，你的修改通常僅僅“掩蓋”了bug而不是修復(fù)了它——就好比你是在治療癥狀而不是病理本身。
例如，如果你得到了 ArrayOutOfBoundsException異常，不要僅僅加上處理異常的語句（甚至忽略它），或者加上一個測試索引的語句。你應(yīng)該弄清除異常發(fā)生的本質(zhì)原因，已經(jīng)它能否被完全避免。
閱讀小練習
Premature Fixes
下面這段代碼已經(jīng)調(diào)試了好一會兒了：
/*** @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而不是完全修復(fù)了它？
- [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. 重復(fù)之前步驟
在試驗之后，思考并修改你的假設(shè)。如果你發(fā)現(xiàn)試驗的結(jié)果和假設(shè)的前置條件相悖，那么就重新進行假設(shè)。如果符合前置條件，就重新設(shè)計假設(shè)，讓它更有針對性，即能夠?qū)ug產(chǎn)生的位置范圍進一步縮小。然后重復(fù)進行上述步驟。
要注意的是，確保你的源代碼和目標文件是最新的。如果你的所有觀察都顯得不正常，一個可能的原因就是你正在運行的程序不是你現(xiàn)在的代碼。這個時候需要刪除所有編譯好的文件然后重新編譯（在Eclipse中是Project → Clean）。
修復(fù)bug
當你找到bug的位置并分析出它的本質(zhì)原因后，接下來的步驟就是修復(fù)它。還是那句話，不要僅僅“掩蓋”住bug，而是要問問自己這個bug到底是怎么產(chǎn)生的，它是一個代碼拼寫錯誤？還是參數(shù)設(shè)計錯誤，還是接口不一致導(dǎo)致的錯誤？
在修改bug時，也要考慮到bug本身是否和其他位置的代碼或者位置的模塊有關(guān)聯(lián)，即修改代碼會不會帶來副作用。另外，也要想一想這種bug在別處是否存在（只是還沒有出現(xiàn)）。
在修復(fù)完成后，記得在你的測試套件中添加上這個bug的測試用例（回歸測試），然后重新進行測試，確保沒有新的bug出現(xiàn)。
一些別的建議
尋求別人的幫助. 向別人解釋你的設(shè)計通常都會幫助你理清思路，即使對方根本不知道你在說什么。這種方法被稱為 小黃鴨調(diào)試法 或者泰迪熊調(diào)試法。即在計算機實驗室里放一只巨大的泰迪熊，定下一條規(guī)則：當你試圖告訴別人你的設(shè)計前，先“告訴”這只泰迪熊——令人驚訝的是，這只泰迪熊解決了很多問題。向別人稱述你的代碼設(shè)計將有助于你認識到問題所在。
睡一覺. 如果你太累的話，調(diào)試會變得沒有效率，畢竟磨刀不誤砍柴工（Trade latency for efficiency）。
總結(jié)
在這篇閱讀中，我們學(xué)習了如何系統(tǒng)的進行調(diào)試：
- 構(gòu)建測試用例復(fù)現(xiàn)bug，并將其添加到測試套件中
- 使用科學(xué)的方法發(fā)現(xiàn)bug：
- 調(diào)試提出假設(shè)
- 利用探針（print、assert、debugger）來觀察程序的行為并測試假設(shè)的前置條件是否滿足
- 徹底而非草率的修復(fù)bug
對于我們課程的三個目標，這篇閱讀主要針對的是遠離bug：我們試著剔除bug，并利用回歸測試防止bug重新出現(xiàn)。
轉(zhuǎn)載于:https://www.cnblogs.com/liqiuhao/p/8908365.html
總結(jié)
以上是生活随笔為你收集整理的麻省理工18年春软件构造课程阅读13“调试”的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java知识体系 servlet_03-
- 下一篇： css3 pointer-events: