parasoft c/c++嵌入式单元测试：扩大覆盖率，结果验证

验证结果

接下来的一步是运行测试用例，然后审查结果。如果你想，你也可以在运行之前检查它们。但从实际来看，最好是先运行它们。我们选中“proc.c”文件，然后在配置菜单中选择“运行单元测试（Run Unit Tests）”。不到一分钟（包括下载、执行和上传），我们得到结果：11个测试用例通过，27个测试用例运行异常。当我们仔细检查失败的原因时，我们会发现这主要是由三个功能导致的： “average”、 “update_brake_signal” 和 “brake_control”。 它们都需要指针作为参数（如下图所示），而在测试用例中给它们传递了空值。

现在我们必须做出决定。如果我们的代码是非常安全的，当传递空值时是不会崩溃的。否则，我们就姑且认为这样的情况不会发生，并删除这些测试用例。 我们采用一种混合的方法。因为功能“average” 和“brake_control”是用来被其他功能调用的，我们放置一个“if”保护语句。功能“update_brake_signal”仅仅从“brake_control”而来，所以我们不需要对它进行多余的保护。我只需要删除那些通过右键单击的测试案例，并选择适当的C++test操作。

再一次的运行，我们完成了25个测试用例和72%的语句覆盖率，得到了77个结果验证。下图显示的代码是与功能“brake_control”和“average”相关。语句覆盖通过高亮显示。它也显示在小窗口的右下角中。测试用例显示在“test case explorer”的左侧。需要进行验证的结果显示在下面的窗口面板中。

现在，我们要进行测试并验证结果。通过这样的步骤，才会得到有意义的断言。因为有了C++test，需要的工作量大大减少。如果你决定将断言作为最重要的变量，C++test会进一步减少你的工作量。如果代码运行良好，可以将结果一起验证。这基本上是“冻结（freezes）”的当前状态。然后，你需要仔细检查代码中最重要的部分。如果它影响到系统安全，那么需要检查所有的内容。

扩大覆盖面

目前我们的语句覆盖率为72%，而我们的目标是100%。“brake_control”只有25％的语句覆盖。我们可以看到，它基本上在第一个“if”语句中就退出了，这是我们增加的对空指标的一种保护。显然，我们需要提供一个测试案例，可以通过非空指针到制动信号变量。我们可以复制、修改现有的测试案例，或者使用测试用例向导。测试用例向导中指明哪些功能要测试，然后图形编辑器引导设置前置条件，参数，后置条件和预期值。这种方法可以限定测试案例。对于简单的类型，向导往往是非常有效的。但对于没有工厂函数的复杂类型，复制和修改可能更有效。关于向导有一件事值得关注：功能里使用的和要求进行初始化的所有变量，它都可以自动识别。如果手动编写测试用例， 你最初可能会忽略这一点。这种情况下，需要额外的调试以便弄清楚为什么测试案例没有按照预期进行。

在本例中，使用向导创建一个传递指针到分配s32类型(“spd_diff” equal to +100 for one and -100 for the other)，并设置两个值为10的变量（“Speed_Diff_Threshold” 和“Brake_Signal_Coeff” ）的测试用例只用了一两分钟。同时运行这两个案例之后，我们的覆盖率提高到了97%，其中“update_brake_signal”和“brake_control”全部覆盖。要达到覆盖率100%需要使用向导，这一次是针对功能“update_speed”的。这一过程同样只需要一两分钟。这个功能并不复杂，和容易在没有覆盖到的if语句中找到一组变量值。最后，我们的覆盖率就达到了100%。