查找嵌入式C语言程序/软件中的缺陷的多种技术
当我们解决了这个问题后，程序可以运行了，但是仍然还有内存相关的问题。内存相关的问题是很难被调试器发现的;当用户使用调试器调试程序时，用户并不知道内存的实际大小。但是自动错误检查工具能够做到这点。因此，为了查找这些内存问题，我们将整个程序进行插装，并使用运行时内存分析工具来运行程序。这样我们就能知道到底是那一片内存发生了写溢出错误。
尽管如此，在审查覆盖率分析结果的时候，我们注意到在目标板上测试的时候，并不是全部代码都被覆盖到了。通过自动化的工具得到这样的覆盖率信息是简单的，因为工具会自动地跟踪覆盖率，但是，如果我们是通过调试器，就不得不判断哪一部分程序经过了验证。而这通常只能依靠我们人工记录的方式来实现。
2/3 首页上一页123下一页尾页
当工具提醒我们一些代码未被覆盖到时，我们决定改变单元测试来额外地增加我们测试执行的覆盖率。这就揭示了程序中另外一些问题。在目标系统的正常测试中，覆盖所有函数也许是不可能完成的任务，因为其中一些函数可能是硬件的失败处理函数或仅在某些小概率的特定情况下才会被调用的函数。而对这些函数的测试对于一些注重安全性的程序而言又是至关重要的。试想在飞机上用来处理速度传感器问题的程序中存在着代码错误插件电感器：我们会有系统崩溃的危险，而不是导致某个设备为非工作状态。因此，通过创建单元测试用例来覆盖这类型的执行路径往往是对其进行有效测试的唯一方法。
接下来，我们修复了工具检查到的所有问题，同时通过验证相应的结果创建了一个回归测试用例(作为报告的任务之一引导我们完成)。然后我们运行数据流分析来覆盖在目标系统上即便使用单元测试也未执行到的路径。在此之前，我们几乎已经达到了100%的代码行覆盖率，但是我们的路径覆盖率却未达到这个水平。 BugDetective帮我们发现了这些方面的一些潜在问题。这些问题可能并没有实际发生或者有可能永远不会发生。也许在实际运行时，这些问题仅仅会在当其条件满足的情况下才会出现，并且在现实生活中，这些条件可能永远不可能满足。尽管如此，我们不能保证随着代码的升级，应用程序不会执行到这些路径。