Question

我最近开始研究一个非常大的C ++项目，在完成90％的实施后，确定他们需要在测试期间展示100％的分支覆盖率。该项目托管在一个嵌入式平台（Green Hills Integrity）上。我正在寻找StackOverflow上其他人在类似环境中使用代码覆盖产品的建议和经验。我对这些类型的工具的正面和负面评论感兴趣。

Answer 1

100％的分支机构覆盖范围？这是非常必要的，特别是因为某些分支（例如状态机的case语句中的默认值）不可能运行。我希望有一些例外，如果没有，你可能需要了解在开始之前可以完成哪些覆盖测试并且无法完成 - 否则你最终会把你的头发拉出来，或者更糟 - 提供不正确的数据。

嵌入式系统的大多数覆盖测试实际上是在PC上执行的。代码移植，微控制器的某些方面在软件中模拟，并运行Bullseye或其他类似的PC代码覆盖实用程序。这样做的原因是，有太多的微控制器和编译器/调试器/测试环境为每个工具开发代码覆盖工具。

当针对特定嵌入式平台存在代码覆盖工具时，它们不像PC平台那样强大，可配置，易于使用和无错误。处理器通常不具备执行良好代码覆盖所需的跟踪功能（没有高端仿真硬件），而无需在固件中插入额外的调试代码，从而产生难以控制的后果和副作用，尤其是在时序问题中实时系统。

只要您可以抽象出特定于硬件的代码（并且因为您正确使用C ++，这应该很简单，对吗？-D），移植代码并不是非常困难。你将遇到的最大问题是类型，虽然在C ++中比在C中更好地指定但仍然存在一些问题。确保您使用的是types.h或类似的设置，以明确告诉编译器您使用的每种类型以及如何解释它。

之后，你可以到镇上测试PC上的核心逻辑。如果您有兴趣开发所需的软件仿真，您甚至可以测试低级硬件驱动程序，虽然时序问题可能有点麻烦。

MxVDev等软件测试工具为您执行了大量的微控制器仿真，并帮助解决了时序问题，但即使有这样的帮助，您仍然可以做一些工作。

如果您必须在系统本身上执行此操作，则需要为具有覆盖功能的处理器购买仿真器 - 这不是一个便宜的主张（许多仿真器对于整套工具和仿真硬件的成本高达3万美元），但它是汽车和航空航天工业等高可靠性环境中使用的众多工具之一。

- 亚当

免责声明：我为生产MxVDev的公司工作。

Answer 2

我们过去曾使用Cantata和vectorcast进行单元测试和代码覆盖。我们还使用Greenhills工具，这两个工具都与greenhills开发工具配合使用。我们在PPC模拟器上运行大部分测试，并通过JTAG pod运行依赖于目标硬件上的硬件的测试。 Canatata和Vector演员非常相似，而catata只是稍微容易使用，功能稍微多一点，但小额外的功能会对用户体验产生很大的影响。

通常，如果要实现高级别的分支覆盖，则需要设计可测试性代码。您测试的越多，您对编写可测试代码的了解就越多。

我们还尝试过PC测试而不是嵌入式测试，因为有了endianess，但这只是一个问题，但这只是硬件层面的一个问题。

此外，这些工具已通过RTCA / DO-178B标准认证。

Answer 3

与Adam一样，我们将嵌入式代码移植到基于PC的线束上，并在那里进行大部分覆盖和分析。我使用过AutomatedQA AQTime和Compuwares DevPartner，两者都是好产品，

如果您必须进行覆盖率，则需要使用覆盖率分析器来创建源的检测版本。有商业和开源工具可以做到这一点，但IMO，它增加了很多工作，没有太大的收获。

100％的覆盖率是雄心勃勃的，因为您需要大量的故障注入才能进入所有错误处理程序和异常处理程序。 IMO，这在线束中比在船上更容易。

值得指出的是，无论谁要求100％的代码覆盖率 100％代码覆盖率绝不等于100％测试覆盖率。例如考虑以下函数;

int div(int a, int b)
{
return (a/b);
}

100％的代码覆盖率只要求我们调用此函数一次，100％的测试覆盖率需要更多的调用。我自己的测试策略包括开发自动化测试用例以给我一个可接受的测试覆盖率，并使用代码覆盖工具纯粹作为寻找未经测试区域的辅助工具。在某种程度上，这取决于您的测试预算;对我来说，100％的代码覆盖率对于它提供的东西来说是昂贵的。

Answer 4

见SD C++ Test Coverage。这是一系列（分支）测试覆盖工具，适用于各种C ++（ANSI，GNU，MS ......）方言，即使在实际的嵌入式系统硬件中也能很好地工作，因为它具有非常小的占用空间，并且易于使用导出收集的测试覆盖率数据的方法。 GUI覆盖显示不依赖于您的实际嵌入式硬件，也会生成完整的覆盖报告摘要。

[我是提供这些工具的公司的负责人。]

嵌入式C ++项目的代码覆盖率分析

4 个答案: