声明：本文档的内容主要来源于书籍《软件调试修炼之道》作者Paul Butcher，属于读书笔记。
重现第一，提问第二
问题重现是实证过程的最强大武器，如果不能重现问题，你也无法证明修复了它
首先按照缺陷报告的描述的步骤来做， 抓住重点，包含三个控制因素
软件本身：确保你使用的软件版本和bug提交的版本一致，使用相同的编译工具和相同的编译参数。
软件运行环境：如果要与外界环境交互，则确保使用相同外部系统。比如测距仪，需要在同样的光照环境、温度和供电方式。
提供的输入：如果软件代码的运行和配置参数相关，则应该使用相同配置。
控制输入之详细说明
软件的输入可能时本地文件，也可能是用户的一系列操作或者是第三方设备
推测可能的输入：
- 回溯工作：错误位置明确时，该方法可能可以重现问题，或者提供有效线索
- 探测可能输入值：利用边界值分析法和分支覆盖法，经验表明，这两处最易出错
- 利用错误条件：编码时，人的天性是关注正常的情况，于是未处理的错误条件很可能诱发一系列bug,因此模拟错误条件可能可以重现问题
- 引入随机性：选取一系列不同的输入值，也叫模糊测试。该模糊测试器的关键特征是，可以根据一些列规则重新创建曾经的输入，以便能够随意重现问题
记录输入值：
- 程序日志：在JAVA中有日志功能，可以打开或者关闭，C语言可以采用独立文本
- 外部日志：这个在客户端和服务器端的软件中采用，独立的系统可以忽略
注意负载和压力：
- 有些缺陷只有软件在某种压力下运行是才能表现出来，这个在服务器端软件最明显，其必须通过压力测试；测距仪软件需要注意的在电池电量供应不足情况下，是否会运行出错！
改进问题重现
如何才能让问题重现即可靠又方便，并且代价最小？
- 最小化反馈周期：
- 将问题重现最小化：第一次就做到最小化不太可能，需要逐步删除不必要的方面，缩小问题重现的范围。
- 最大限度的减少重现所需的时间：有些bug只是需要时间来重现，因此需要采取措施使其早些发生，比如怀疑资源泄露，则可以故意营造资源耗尽的局面。
将不确定的缺陷变为确定的：
- 软件之美在于它的确定性，不确定性往往有以下几个原因：
- 开始于不可预知的状态：比如C/C++程序，使用未初始化的内存或变量。
- 与外部系统进行交互：这种情况，最好的选择是使用你能控制的东西代替外部系统，比如使用串口助手模拟外设发送指令。
- 故意使用随机性：软件中的随机函数，都是伪随机，只要种子一样，结果就相同
- 多线程：PC端的软件叫多线程，嵌入式端一般叫多任务，可以采取措施增加竞争情况，是问题更容易实现
自动化：
- 采用自动化测试，不但可以加快进程还可以见笑犯错误的几率
- 自动化测试：需要构建自动化测试框架和用户借口测试工具
- 重放日志文件：如果bug重现需要通过日志，则需要通过重放日志构造相同的操作序列
迭代：
- 在诊断过程中，随着获得软件运行信息越来越多，你可以使用这些信息不断改进你的重现。逐步缩小导致bug发生的范围，比如缩小到一个函数、一个变量、一段语句。 通过反复优化确保你的重现问题的程序既方便又可靠！
如果真的不能重现怎么办？
缺陷真的存在吗？
- 用户一般不会恶意报告缺陷，极有可能是软件出错了，也有可能是不清楚为何这样，误解了软件的一些方面。
在相同的区域解决不同的问题
- 重现问题的区域还有其它缺陷吗？如果有，也要一查到底。这样做可以清理这个区域的代码、使你从整体上更好的了解代码，并找到重现问题的关键因素。
让其他人参与其中
- 开发人员很容易有盲点，其工作重点是让编写的软件可以正确运行，而不是证明这个软件有缺陷，因此让别人参与进来时必要的。
充分利用用户群体
- 如果缺陷出现在外部系统中，获取应该让用户为你收集重要信息，不过这种方法往往并不理想。
推测
- 虽然实证方法是最好的，但是其不是唯一的解决办法，纯逻辑推理就是其中一种。该方法费时费力，在其它方法无效时，往往可以起到作用。该方法需要把自己融入到软件中，执行到每一步时，考虑有哪些错误的可能性，并尝试解释你跟踪的缺陷。