调试过程是不会发生在真空中的，因此提前了解基本知识，未雨绸缪，等你真的遇到一个缺陷时，会为你节省大量时间、精力并减少挫折感。
有效的自动化测试不仅仅意味着简单地使你的测试自动化，为了达到效益最大化，你的测试必须满足：
明确说明测试的结果是通过还是失败，每个测试输出一个结果——通过或者失败。
独立，运行一个测试程序之前不需要安装，测试运行前，能够自动安装任何它需要的环境，测试后能撤销对环境的修改。
单击运行所有测试，所有测试都可以一步运行，不会互相影响。
全面覆盖，做到接近完全覆盖是有可能的。
调试的时候是什么让自动化测试更有价值呢？
首先，经过良好测试的代码往往只有少量缺陷，最容易修复的缺陷就是根本不存在的缺陷。 发生错误后越快发现错误，修复起来越容易。 自动化测试是一个持续集成的关键推动因素。 自动化测试能使你经常发布新版本的软件且自信新发布的软件可以正常运行。 对于要测试的代码，需要构建成能够获取中间结果和内部结构的方式。 编写测试程序是在诊断过程中重现缺陷的极好方法。 完成诊断后，自动化测试可以提供强大的保护措施来防止回归。 自动化测试是重构的关键推动因素，是最有力的武器，可以确保代码在整个开发的生命周期中始终保持良好结构和灵活性。
代替测试(test doubles)是在测试过程中使用“虚拟”测试对象来代替真实的测试对象，最常见的是模拟测试和桩测试（模拟测试是主动的，可以验证如何以及何时被调用的预期结果，桩测试是被动的，调用时对已存数据简单的做出回应）。
一个源代码控制或配置管理系统是可以跟踪源代码和整个生命周期中所做出修改的历史信息的资源库。
这里不得不提的一个重要问题就是分支，它让我们可以支持在同一个时间内并行开发一个软件的多个版本，这样可以确保软件的稳定性和可维护性，但是它带来了大量的重复工作，因为分支一旦发生变更，主干也必须跟着变，与此同时，如果有多个分支，那么每个分支也必须做相同的处理。怎么做才比较好呢？尽可能晚用分支，坚持分支的单一层级，设置你的持续集成服务器来构建所有正处于活跃状态的分支，经常签入一些小的修改，只把确实需要在分支中进行的修改加入到分支中，将分支合并到主干中，立即将分支向主干合并，保持审计跟踪。
在调试过程中你需要控制的一个最重要的变量就是软件本身，你需要能识别并重新创建有明显缺陷的相同软件。
构建现代软件是一个复杂的过程，其中会使用很多需要以特定的顺序和方式来调用的工具，一个好的解决办法是将软件的这类知识编码为自动化构建的一部分。
自动化整个构建过程，从开始到完成。 永远不要再开发人员的机器上构建发布版的软件。 每当你修改软件时请运行测试。
不同的源代码对应不同的版本号。大部分的调试依赖于动态分析——在软件执行时检验它。但事实证明，很多缺陷可以通过静态检查源代码而被识别出来。
静态分析的伟大之处在于它给我们提供了一种几乎免费的缺陷检测的方式，我们可以简单地通过工具运行代码并找到问题所在，而不是等待一个错误出现，然后经历漫长的问题重现，诊断和修复过程。将静态分析集成到构建过程中。