查找嵌入式C语言程序/软件中的缺陷的多种技术（3）

为了确保程序运行一切正常，我们重新运行整个分析过程。首先，我们开启运行时内存监测并运行应用程序，一切表现正常。然后我们开启内存监测并运行单元测试，一个任务被报告出来：

　　我们的单元测试检测到reportSensorFailure()函数的行为已经发生了改变。这是由于我们已经对finalize()函数进行了修改——为了纠正之前报告的一个问题所做的修改。此处报告的任务是为了让我们注意此修改，并提示我们应该对测试用例进行相应的审查，并且确定是否应该对代码或者测试用例进行相应的修改，以表示这种新的行为实际上是我们所预期的行为。在检查完代码之后，我们发现后者（修改）是正确的并且应该更新断言的正确条件。

　　/* CPPtest_TEST_CASE_BEGIN test_reportSensorFailure */

　　/* CPPTEST_TEST_CASE_CONTEXT void reportSensorFailure(void) */

　　void sensor_tests_test_reportSensorFailure()

　　{

　　/* Pre-condition initialization */

　　/* Initializing global variable messages */

　　{

　　messages = 0 ;

　　}

　　{

　　/* Tested function call */

　　reportSensorFailure();

　　/* Post-condition check */

　　CPPTEST_ASSERT(0 == ( messages ));

　　}

　　}

　　/* CPPTEST_TEST_CASE_END test_reportSensorFailure */

　　作为最终的确认，我们需要独立地运行整个程序——在IDE中关闭掉运行时内存监测来对程序进行构建。结果显示一切如我们所预期一样运行。

　　总结

　　作为全文的结尾，让我们一起对上述各个步骤进行一个鸟瞰式的总结。

　　首先，我们开发的程序并未如我么所预期那样运行，我们不得不在两种解决方法中选择一种来查找程序中的错误：通过运行调试器或者使用自动错误检测技术。

　　如果我们使用调试器运行代码来查找错误，我们将会看到一些很奇怪的现象：程序中的一些变量总是被赋予了相同的值。基于这种现象我们不得不通过排除法来查找问题的原因——即在应该使用比较运算符的地方我们错误地使用了赋值运算符。而静态代码分析则能为我们自动地检查出该逻辑错误。运行时内存分析是不可能检查出这种错误的，因为这种错误与内存无关。数据流分析也很有可能找不到这类错误因为数据流分析仅仅是通过这些路径而不会验证这些条件的正确性。

　　当我们解决了这个问题后，程序可以运行了，但是仍然还有内存相关的问题。内存相关的问题是很难被调试器发现的；当用户使用调试器调试程序时，用户并不知道内存的实际大小。但是自动错误检查工具能够做到这点。因此，为了查找这些内存问题，我们将整个程序进行插装，并使用运行时内存分析工具来运行程序。这样我们就能知道到底是那一片内存发生了写溢出错误。

　　尽管如此，在审查覆盖率分析结果的时候，我们注意到在目标板上测试的时候，并不是全部代码都被覆盖到了。通过自动化的工具得到这样的覆盖率信息是简单的，因为工具会自动地

　　跟踪覆盖率，但是，如果我们是通过调试器，就不得不判断哪一部分程序经过了验证。而这通常只能依靠我们人工记录的方式来实现。

　　当工具提醒我们一些代码未被覆盖到时，我们决定改变单元测试来额外地增加我们测试执行的覆盖率。这就揭示了程序中另外一些问题。在目标系统的正常测试中，覆盖所有函数也许是不可能完成的任务，因为其中一些函数可能是硬件的失败处理函数或仅在某些小概率的特定情况下才会被调用的函数。而对这些函数的测试对于一些注重安全性的程序而言又是至关重要的。试想在飞机上用来处理速度传感器问题的程序中存在着代码错误：我们会有系统崩溃的危险，而不是导致某个设备为非工作状态。因此，通过创建单元测试用例来覆盖这类型的执行路径往往是对其进行有效测试的唯一方法。

　　接下来，我们修复了工具检查到的所有问题，同时通过验证相应的结果创建了一个回归测试用例（作为报告的任务之一引导我们完成）。然后我们运行数据流分析来覆盖在目标系统上即便使用单元测试也未执行到的路径。在此之前，我们几乎已经达到了100%的代码行覆盖率，但是我们的路径覆盖率却未达到这个水平。BugDetective帮我们发现了这些方面的一些潜在问题。这些问题可能并没有实际发生或者有可能永远不会发生。也许在实际运行时，这些问题仅仅会在当其条件满足的情况下才会出现，并且在现实生活中，这些条件可能永远不可能满足。尽管如此，我们不能保证随着代码的升级，应用程序不会执行到这些路径。

　　安全起见，我们仍然修改了所报告的问题以排除任何可能影响它的实际应用执行的风险。在修改代码的同时，我们同时也引入了回归测试，当我们再次运行单元测试时立即被检测到。在所有的自动化错误检测方法中，回归测试是唯一能够帮助我们检查到代码是否发生了功能性的改变的方法，并且能验证出对代码进行的修改是否引入了功能性的错误以及不可预知的副作用。最后，我们修改了回归测试套件，并重新测试代码，发现一切运行正常。

　　正如读者所见，我们使用的一切测试方法——基于模式的静态代码分析、内存分析、单元测试、数据流分析以及回归测试——并不是相互竞争的关系，恰好相反，它们是一种互补的关系。将上述工具结合使用，它们就是一套具有强大作用的工具集，并为嵌入式C语言程序/软件提供一个无可比拟的自动化错误检测解决方案。

　　总而言之，通过自动地查找很多关于内存和其它编码的缺陷，我们成功地让程序运行起来了。尽管如此，值得注意的是，最危险的缺陷却是实际的功能性错误：例如程序并未如所指定的要求运行。而不幸的是，这些错误往往是非常难以被发现的。

　　查找这类缺陷的最好的一个方式就是通过同行代码审查来实现。即另指派至少一人来检查代码并且审查代码与需求内容的一致性，这样用户就能对实际程序是否会如预期那样运行有一个很好的*估。

　　另外一个十分有用的策略是围绕代码创建一个回归测试套件，这能帮助用户快捷地验证代码与规范的一致性。在本文所描述的示例情景中，单元测试被用来强制执行应用程序级的运行时内存监测所未覆盖到的代码：它能覆盖到当前程序的功能性，在此之后，我们对代码做了一些修改，它能提醒我们代码出现的相应的功能性问题。事实上，这种单元测试用例应该被更早地创建起来：理想情况下，当用户在实现程序的功能时就应该被创建起来。这样，用户就能得到更高的覆盖率并同时构建起一个更强壮的“安全网”来捕捉关键的功能性改变。

　　Parasoft的C++test能帮助用户完成这两个任务：从自动化到管理同行代码审查流程，以及帮助团队创建，持续地运行并维护一个高效的回归测试套件。

　　关于Parasoft C++test

　　Parasoft C++test是一个经广泛的最佳实践证明能提升软件开发团队开发效率以及软件质量的自动化集成解决方案。C++test能进行诸如编码策略增强、静态代码分析、运行时内存监测、自动同行代码审查以及单元和组件测试，从而为软件开发团队提供一种更加实用的方法来确保其C以及C++程序能如所预期那样工作。C++test可以用于在通用开发IDE下的桌面平台中，以及在回归测试时通过命令行以批处理模式的方式运行。同时，C++test还集成了Parasoft的报告系统，该系统能提供具有细分能力的基于Web 的仪表板，这使得开发团队根据C++test的测试结果和其他的一些关键进程指标来更加方便地跟踪项目的状态和趋势。

　　通过在宿主机上进行大量的测试以及在目标系统中进行的平滑的验证，C++test能够帮助软件开发团队减少花在嵌入式系统开发中的时间、精力以及成本。随着代码在宿主机上的构建，C++test的自动化框架使得开发者能在目标硬件系统尚未准备好的情况下就开始测试以提升代码质量。这大大地缩短了花在目标系统上测试的时间。早期在宿主机上构建的测试套件可以被重用来在仿真器或真实的目标板上验证程序的功能性。