《我是程序员》调试经验总结学习

其实一直苦于不会调试，自己是半路出家，基本没有调试经验，只得总结别人的调试真传了。纵观各路方法，其实主要还是要多思考，找问题原因进行定位，然后再利用调试方法进行调试，最终找到问题关键所在，解决掉问题。但最重要的还是自己的分析能力和对信息的敏感度，这需要长期的锻炼，没有特别的捷径。对调试经验进行以下总结：

第一步：重现问题。这一步非常重要，如果可以，尽可能能够通过一定的步骤可以稳定的把问题重现出来。即使问题很难重现，能够找到偶尔重现的规律和概率对于解决问题也是很有帮助的。

第二步：缩小范围。这里会有一些技巧和经验，比如使用二分法去缩小出问题代码的数目。一般的问题都是修改引起的，把有问题的代码限定为最近的修改，一下子就把范围缩小了很多。单元测试的一个好处就是可以把每次可能出问题的范围做了一个控制，这样解决起来就容易很多。

第三步: 寻找原因。对于一般的问题，经过第一步第二部，第三步也就是看一下变量，就可以得出类似 “多写了一个分号“这样的原因。但是对于复杂的问题（比如你好死不死踩到了编译器的雷），这个时候，可能需要先大胆作出一些假设，然后放狗搜索，必要的时候做实验验证，才能得到令人信服的原因。

综上，我们首先要弄清楚问题是什么（第一步），控制好问题的边界（第二步），然后才是找到问题的原因(第三步)。

某博主说：

先理解step in、step out、step over、运行到光标处，会下断点删除断点，最好还能学学如何条件断点、然后学会用二分法调试，

当然最后还有一招就是 print变量 的办法！

某博主说：

我的程序在我做调试的时候都会出现大量的 输出参数代码 和 输出标记代码
输出参数代码不用多说
输出位置代码一般都是前一个后一个，然后一点点的缩小问题范围……

以下是某博主分享的详细步骤：

如何调试程序及调试程序基本步骤、方法详解

1.为什么要进行程序调试及调试程序的目的？

    程序调试是将编制的程序投入实际运行前，用手工或编译程序等方法进行测试，修正语法错误和逻辑错误的过程。
    这是保证计算机信息系统正确性的必不可少的步骤。
    测试时程序运行错误，无法根据提示的错误信息准确定位错误原因及错误位置。
    根据测试时所发现的错误信息和利用调试工具追踪的提示信息，两者相互结合综合判断错误发生原因和位置。
    找出错误原因和具体的错误位置，最终方便进行修正。

    测试本身也就属于程序调试的过程中的一部分。
    调试是验证程序的运行是否符合自己的设计。

2.调试的原则

​ 一、用头脑去分析思考与错误征兆有关的提示信息。

​ 二、避开死胡同。同一个问题验证完成，办法行不通。这样需要换种思路处理问题。

​ 三、只把调试工具当做查找错误位置及错误原因的手段。

    利用调试工具，理清楚程序中数据流转逻辑，可以帮助思考，但不能代替思考，
    因为调试工具只是辅助性的定位错误的方法。
    而解决实际问题需要根据调试的提示信息，自己判断思考出正确的处理方式。

​ 四、避免用试探法，最多只能把它当做最后手段。

​ 五、修改错误的一个常见失误是只修改了这个错误的征兆或这个错误的表现，而没有修改错误本身。
    如果提出的修改不能解释与这个错误有关的全部线索，那就表明只修改了错误的一部分。
    要找到问题的根源。思考为什么会引起这样的错误，是否是设计上就出现不合理的问题。

3.调试程序的思想

    首先要了解清楚 系统功能的业务，业务了解清楚后，根据业务功能进行测试来使业务数据流转（业务产生数据，数据体现业务）。
    当错误发生时，首先应该想到并且知道这个问题的产生所依赖的业务数据流程。
    比如：当点击表单提交后出现错误。这时应该思考：
        点击提交按钮后应该发生了哪些些数据流转过程：
        点击提交按钮后，这个按钮触发的是提交form表单的action 指向的是控制层的哪个方法或js脚本中的某个function,
        然后就是控制程方法接收数据后又调用的是service的哪个方法，继续直到到后台调用的是哪个数据库的sql
        再就是返回值返回页面数据的过程。
    在这个过程中业务数据跟着业务程序逻辑在流转。
    再根据页面展现的错误现象及报错提示信息，推测该错误可能会发生在这个业务数据流转过程中的哪个位置，
    从而确定我们调试的断点位置。调试，找出错误原因，提出解决方案，解决后再次测试。

    
4.程序调试步骤方法

​ 1）根据 错误提示信息 及 业务功能逻辑 的推理等信息（即与错误征兆有关的提示信息），找到有可能会导致错误发生的位置
异常错误日志信息定位错误发生位置。
日志信息的输出位置：

一是控制台输出，这是最及时的一种方式，在程序运行时可以很容易就看到日志输出信息。

二是输出日志信息到日志文件中，这种方式根据项目要求配置日志相关信息[日志输出级别、日志输出路径]
 这些日志信息分为以下几种（两种）：
【1】在系统程序代码中，对自己的日志信息进行标记。

错误日志

当程序执行发生错误时，在日志文件或控制台输出时就会输出到已标记的日志信息，根据输出的已标记信息通过工具搜索定位到具体的打印日志的方法。

【2】 错误信息没有我们标记的日志，而是在程序执行中发生错误导致的异常错误信息提示如下：

1》2019-07-01-13-05 [http-nio-192.168.200.169-8443-exec-1] [org.thymeleaf.TemplateEngine] [ERROR] - [THYMELEAF][http-nio-192.168.200.169-8443-exec-1] Exception processing template "findFlpcList": An error happened during template parsing (template: "class path resource [templates/findFlpcList.html]")
org.thymeleaf.exceptions.TemplateInputException: An error happened during template parsing (template: "class path resource [templates/findFlpcList.html]")
2》Caused by: org.attoparser.ParseException: Exception evaluating SpringEL expression: "#strings.substring(flpcDTO.createTime,0,10)" (template: "findFlpcList" - line 27, col 25)
3》Caused by: org.thymeleaf.exceptions.TemplateProcessingException: Exception evaluating SpringEL expression: "#strings.substring(flpcDTO.createTime,0,10)" (template: "findFlpcList" - line 27, col 25)
4》Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 10

这种在日志文件或控制台中输出的异常错误信息，我们看日志错误信息按照这种思路：

1》中表示了错误发生的位置，比如：
An error happened during template parsing (template: "class path resource [templates/findFlpcList.html
可以推测出：

发生错误的地方应该templates/findFlpcList.html文件中，原因是An error happened during template parsing模板解析时出错。在调试排查错误位置点时重点就可以在代码中的查找 findFlpcList.html 文件。

 2》、3》、4》的 Caused by中就显示了错误造成的原因。比如：
        Exception evaluating SpringEL expression: "#strings.substring(flpcDTO.createTime,0,10)" (template: "findFlpcList" - line 27, col 25)

就显示了在模版 findFlpcList  的27行 "#strings.substring(flpcDTO.createTime,0,10)"发生 SpringEL expression异常
紧接着看下一句
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 10
可以看出错误原因就是字符索引越界了，这样我们就可以推测可能为 flpcDTO.createTime 取值有问题或者（0,10）截取不对。

接下来要做的就是 将 flpcDTO.createTime 的值打印输出 查看具体值是什么，判断错误发生原因。这一步就是下面的调试。

 2.1）在IDE中进行启动debug调试模式，进行“标记断点” 。

注意：一般打断点的方式及位置是

​ 【1】在有可能发生错误的方法的第一行 逻辑程序 打程序断点。

​ 【2】方法中最有可能发生错误的那一行打程序断点。

​ 【3】在程序运行到断点位置暂停时，进行下一步调试，这时需要特别***注意观察***程序运行的每一步的数据是否为业务流程处理的正确数据。

 2.2）打印输出相关信息 ->system.out.println()

​ 【1】打印信息在方法中最有可能发生错误的那一行上一行或下一行，将程序执行的参数、返回结果值在控制台进行输出，检查输出的结果值是否为程序执行咱们想要的结果，进而判断错误发生点。

​ 【2】这种打印输出信息的方法也是在某些不支持debug的系统调试的一个重要方法。

3）在打断点和标记打印输出后，现在开始进行debug模式调试。

​ 当程序运行到断点，这时程序在一个暂停状态，我们需要进行程序单步向下执行，观察每一步中的输入参数数据是否正确或调用方法的返回值数据是否正确。当程序运行到一个方法时我们可以继续单步向下执行，不管方法内部的逻辑只关心返回值，也可以使用程序调试方法中的进入方法内部继续追踪程序（进入方法内部后继续单步执行或跳出方法内部），直到程序执行发生错误，判断是否为程序错误发生的实际位置。

​ 另一种情况当程序运行起来后，业务处理发生错误，并没有进入我们的断点或打印输出语句，这时就是我们推测的程序发生的位置不对，需要根据错误信息和业务处理流程逻辑重新推测错误发生位置，重新再次进行第 2.2）步。

​ 4）当查找问题时注意将问题细化拆解，看看一个大问题中，程序正确执行到哪一步，精确定位错误点。

5.1后台调试工具

调试的主要方法：（1）单步走 （2）进入方法内部（3）跳出方法，不管在那个工具中应该都有这样的功能，只是这些功能的快捷键不同。下面介绍几种工具

idea的debug调试功能
1）向下单步执行 [step over F8] ，就是程序一句一句的执行。

2）进入内部[step into F7]，就是进入调用方法的内部，接下在单步执行，一句一句的检查程序的执行情况。

3）强制进入内部[force step into Alt+shifit+F7]。

4) 跳出内部 [step out shift+F8] 就是跳出方法。

eclipse的debug调试功能
1）进入内部[step into F5]

2）向下单步执行 [step over F6]

3）跳出内部 [step return F7]

日志控制台的输出 logger.error()、logger.info()，根据日志信息提示，寻找问题出错的位置及出错原因。

常说一句话“看日志或控制台有没有报错输出。“
自己指定的 system.out.println() 的打印输出，这种方式是在自己根据预测的错误点的位置进行打印相关信息，进而验证和查看自己对错误原因及错误位置的定位。
模拟浏览器发送请求的工具 有： Postman、curl

 

5.2.前台浏览器调试工具方法

和后端调试工具应具有的调试功能相似，

在chrome,fireFox、ie、qq、360、浏览器中的调试快捷键通常都为 F12。按下F12快捷键进入调试模式，浏览器的调试目标 针对 js 、html、css 样式。
打印输出 console.log()、弹出信息方式alert()。

js脚本调试

html及css调试