不管是什么样的重现问题的方法，只要有，就比没有强。但是如何让重现问题既可靠又方便呢？
最小化反馈周期：和软件开发的其他众多领域一样，问题重现也是要使反馈周期最小，所经过的周期越短，反馈就越及时，其相关性就越高。
因此，最先要关注的就是找出问题重现中哪些方面是不需要的，将它们剔除掉，称为将问题重现最小化。那么，哪些元素可以被剔除呢？往往这要靠直觉。你了解软件，并且知道哪些模块可能被一些特定输入所影响，如果直觉不对，那么一些非直接的方法可能会帮助到你。
改进问题重现不是一蹴而就的事，而是在整个诊断过程中要牢记在心的东西。
将不确定的缺陷变为确定的：要做到这一点，需要明白不确定性从何来？
1. 开始于不可预知的初始状态
当你的软件从未经初始化的内存读取数据时，通常会出问题。如果你有理由相信，是这个原因导致了不确定性问题，那么你最好的选择可能是使用调试内存分配器，来强制内存被初始化为一个众所周知的值，或用内存完整性检验软件来检测是否引用了未初始化的内存。
2. 与外部系统进行交互
由此引起的不确定性问题往往不是因为二者表现不一，而是因为时间上微妙的不同。解决的策略是能够精确控制从外部系统接收了什么，以及何时接收的。最好的选择可能不是试图直接控制外部系统，而是用你能控制的东西替换它，比如调试子系统或代替测试。
3. 故意地使用随机性
由此导致的不确定性听起来还是很正常的，幸运的是，大部分所谓使用随机数的软件都是通过确定性算法产生的伪随机数，因此这个是完全可以预测的行为。
4. 多线程
由此引起的不确定性最难处理。在多核系统盛行的今天，往往我们处理的并不是真正的并发。而在缺乏并发控制的结构化方法下，我们不得不依靠一些特殊的方法。因此，在处理方法中最有效的工具之一就是不起眼的sleep()方法，它允许你强制一个线程长时间等待而出现竞争状态。
例如，假设你正在工作的软件中多个乖哦工作线程并行处理工作项目，工作线程使用下面的java代码来获得工作项目：
if (item=workQueue.lockWorkItem())
{
item.process();
workQueue.writeResultAndUnlock(item);
}
你试图跟踪一个间歇出现的缺陷，有时同一个工作项目会同时分配给两个工作线程。遗憾的事，这种情况极少出现，那么，你可以将代码更改为如下形式来增加重现该问题的几率：
if (item=workQueue.lockWorkItem())
{
Thread.sleep(1000);
item.process();
workQueue.writeResultAndUnlock(item);
}
注意：尽管sleep()方法在重现问题和诊断阶段很有用，但在修复缺陷阶段它不是一个适合的方法。
自动化：一个自定义测试不仅能够方便的运行，而且当诊断结束开始修复的时候，对于即将编写完成的测试来说，它是一个很好的起点。如果确定缺陷重现需要通过日志，那么可以选择重放日志文件。
迭代：在诊断的过程中，你构建了足够多关于如何以及为何软件如此运行的信息，可以用此不断改进重现，如下图：
通过如下步骤反复改进：
1. 你确定一个特定的模块已包含在内，其中有导致缺陷的元素，这样可以创建一个更小的文件。
2. 进一步诊断，发现能通过用桩模块替代与第三方服务器交互的子系统，让问题每次都出现，桩模块可以很容易返回已经确定的响应。
3. 最后，把跟踪范围缩小到一个特定函数，通过设置一组具体的参数调用该函数来创建单元测试，以便重现问题。
如果真的不能重现问题该怎么办？
首先，不要轻易给出”缺陷不存在“的结论，除非尽力获取了更多额外信息，用尽了所有可用的办法依然不能重现问题。其次，在相同区域解决不同的问题，尽管没有你目前跟踪的缺陷那么严重和紧急，也许它们蒙蔽了真正缺陷所在，也许会让你找到重现问题的关键因素，当然，也许没有任何帮助。第三，试着让其他人参与其中，这样可以获取其他人的不同角度看待问题，尤其是反馈错误的人。第四，充分利用用户群体，有些时候，缺陷出现在外部系统而非开发系统中，但这需要用户为你收集所需要的信息，从某种角度来说，并不理想。最后，可以使用推测法，你所需要做的是把自己融入到软件中，在想象中执行软件，执行每一步，考虑有哪些出现错误的可能性，尝试解释你跟踪的缺陷。
正常来说，我们有能力重现问题，而在下一章中，我们将会看到如何用重现来诊断问题。