你有没有曾经调式某段代码时，总觉得世界上有鬼？

你有没有曾经调式API时，总感觉是调用第三方的接口问题或者文档说明不对？

你有没有曾经调式一个bug 时，总感觉问题的来源是使用的方式不对？

你有没有在安装一个服务时，总感觉文档或者环境不相符合？

相信过程和方法，切勿被结果误导 ............

概述

调式代码很多时候类似于查案一样，只是结果的重要程度不同，查案为的是人民安稳，而我们调式则是为了系统的安稳。既然这样我们就不要冤枉任何一段代码和程序，以免他们受到不合理的惩罚。

以下的一些过程方法都来自于个人的总结，从个人角度说前人的一些方法都是经过长期的经验积累，当然参考性理论性都比较强，而作为个人的方法，则可能更适合像我等 DS 。

测试方法

代码过程式调式方法

代码调式首先要注意的是过程，你必须要理清楚导致最终结果的思路，也就是作案的过程，从作案过程中的一步步跟进得到作案结果。在作案过程分析中对于每一个疑点都必须打上标记（也就是代码中所提到的 log 信息）。经过这样的分析过程后，再进行黑盒测试，添加输入，验证结果。最终根据每一步的标记来验证你的判断，从而找到原因。

以上的方案是一种过程式的调式方式。这种方式的优点不言而喻，直接可以通过一个测试就可以分析清楚整个过程，但是这种方式很耗时间，理清楚自己的代码逻辑尚可，而想要理清楚他人逻辑代码则可要难于上青天。

单元测试调式方法

单元测试的基本目的是保证某个函数、类或者某个功能模块的正常运作，包括其异常情况的测试验证。而作为程序员最喜欢的验证方式莫过于“打桩”（打桩的含义就是提供假默认数据），这种方式调式起来非常方便，但是有一个不利的地方就是无法再次利用，因为在我们验证正常以后，很多开发人员都会将其注释或者删除，因此如果我们在开发环境开发完成，但我们希望在测试环境验证时，则必须又要重新写一篇打桩逻辑，那么这样看，到现网时，则会更加的麻烦。既然这么多不便，你可以尝试下面的做法。

添加一个单元测试类，这个类需要控制其权限，只有通过后台登录或者是命令行才可以执行，该类承载的作用就是对系统的关键逻辑进行检测，并且做出相应的测试输出结果。要相信所有的接口类都是可以通过单元测试类去完成测试的。很多时候程序员在质疑，这件事情是不是应该我们做？其实还真是需要我们去做，毕竟很多测试现在做的都是黑盒测试。

这种调式方法适合在开发过程中，并且可以保证我们现网的代码发布后运行正常。希望大家在计划开发时间时也将该过程并于开发阶段。

快速定位法

前面两个那么复杂的过程太理想化了？我的代码就只有 100 行，并且系统也不复杂。如果是这样的话，那么就快速的进行定位分析。很多时候会遇到

1、输入正常，输出异常；

2、输入正常，逻辑异常，输出异常；

3、输入异常，逻辑正常，输出正常；

4、输入异常，逻辑异常，输出无。

在个人的开发过程中，我经常会遇到上面的某种类型的问题，比如在 Node.js 开发过程中，遇到 string.length 提示 string 没有 length 方法。当时就昏头的在问自己，为什么其他 string 都有 length 方法，为什么这个就没有呢？应该很多同学都知道问题就在于这个 string 根本就不是 string ，只是说你自己把它理想化为 string 了，也就是你输入的本来就有问题。那么定位这个问题的最好办法就是打印输入，打印输出即可。

可能其他的程序没有这么简单，但是最基本的就是在主函数中的会遇到异常的函数都进行输入输出判断，那样就可以快速的定位。

切记：不要断章取义，自以为是。

上面的方法以及过程都只是基于 PHP 或者 Node.js 总结出来的，对于 C & C++ 可能存在相似或者相异处。不喜勿喷，且看且珍惜吧。