软件调试过程：如何进行以及如何改进

引言

当然，每个人都听说过 RAD、RUP、CASE、迭代、瀑布模型等等，有些人甚至在这些方面是专家。 但是等等！ 软件开发人员也需要服务和支持，其中最重要的部分是调试。 在整个软件生命周期中，有多少百分比的开发工作花在调试上？ 你可以在各种文章和书籍中找到估计值，但很明显这个百分比很高！ 不幸的是，这就是现实......

在本文中，我试图描述调试过程，概括我的经验。 调试是一种不如开发正式的活动，我想改变这一点，因为形式化过程的优势之一是改进过程的可能性。 我还将根据其正式描述，提供一些改进调试过程的建议。

流程

与软件开发不同，调试本质上是迭代的。（我指的是一般的开发，意识到在复杂的项目中，开发也可以而且应该采用迭代方式）。一般来说，调试包括三个主要阶段

1. 描述 Bug。
   也许这本身不是调试的一部分，但它非常重要，所以我将其包含在此处。 你应该从用户那里获得尽可能多的细节：产品版本、操作系统版本、重现该 Bug 所需的所有条件。
2. 获取 Bug “出现”时的程序快照。
   尝试重现该 Bug 并捕获状态（变量、寄存器、文件等）和操作（程序此刻正在做什么，正在运行哪个函数）。 有时这很简单：例如，程序崩溃了，你可以直接切换到你的调试器来查看问题。 但在其他情况下，你必须执行多次迭代才能捕获快照。 在某些情况下，你甚至必须回到第 1 步。在其他情况下，你将从下一步返回到这里。
3. 分析快照（状态/操作）并搜索 Bug 的原因。
   状态和操作可能不正确，因此此阶段的一个子步骤是确定它们是否正确。 以下状态/操作组合分类有助于指导进一步分析（“+” & “-” 分别表示“正确” & “错误”）
   
   • +/+ : 不可重现的 Bug；
     你有一个不正确的描述或不同的环境（操作系统等）
   • +/- : 容易找到的 Bug；
     你必须添加一些检查（空指针、除以零等）或额外的实现
   • -/+ : 需要搜索其来源的 Bug；
     你可以使用的方法包括
     
     • 从之前的时刻进行跟踪，
     • 跟踪状态组件被使用/更改的地方
     • 使用不同的输入数据进行跟踪
     • 你的经验可能会指出程序中的关键位置（例如，用户输入处理的开始）
   • -/- : 与 -/+ 相同，但由于情况的困难，在某些情况下，一些解决方法可能就足够了，即使操作正确 (+)。
4. 修复 Bug。
   关于 Bug 修复的想法可能出现在调试过程的任何阶段，但只能实施一个，即 1) 修复描述的 Bug 所属的 Bug 类型，并且不会在其他位置和/或使用其他输入数据引入其他 Bug。

经验和程序知识在调试的所有阶段都起着关键作用。 这些知识有助于获取程序快照和搜索 Bug 的来源。 需要注意的关键位置的示例包括用户输入处理的开始、多功能过程等。 因此，以下想法可能有助于牢记在心。

为了改进调试

• 构建更智能的调试工具。 由于这些工具几乎将在调试的所有阶段中使用，因此“教”它们程序将很有用，并且程序本身应该帮助调试器。
• 创建一个关于程序关键文档的系统/数据库，这些文档在调试中有用，例如“如果 A 方面存在问题，那么查看（设置断点等）A1、A2、… 等关键位置”。 数据库应支持搜索。

拥有一个好的调试器！ :)