2011-12-19 69 views
7

我为非POSIX嵌入式系统编写项目,因此无法使用gcc选项--coverage(我没有读取或写入)。我还能做什么来产生像gcov一样的输出。我有一个输出功能。如何对嵌入代码进行覆盖

+1

代码覆盖率要少得多常见于嵌入式系统完成。但对你而言,一个好的答案需要关于你的系统的更多细节。什么CPU?什么OS?什么编译器工具链? – TJD 2011-12-19 18:01:00

+1

你只需要写功能或读写功能吗?如果只是写入(打开,关闭,写入),你可以创建自己的,也许写输出到串行端口在其他地方存储/记录。 – 2011-12-19 18:36:55

+0

是否可以在可以使用coverage选项的系统上编译和运行测试? – 2011-12-19 21:30:55

回答

9

它可以通过带嵌入式跟踪的处理器,暴露跟踪端口的电路板设计以及合适的硬件调试器和相关软件来完成。例如,许多基于Cortex-M的器件都包含ARM的嵌入式跟踪宏单元(ETM),Keil的uVision IDE和ULINK-Pro调试器支持这种设备,以提供代码覆盖率和指令/源级跟踪以及实时分析。硬件跟踪的优点是非侵入性 - 代码可以实时运行。

如果您没有硬件支持,您可能不得不求助于模拟。许多工具链包括一个指令级仿真器,它将执行跟踪,代码覆盖和分析,但您可能必须创建调试脚本或代码存根以模拟硬件来强制执行所有路径。

第三种替代方法是在带有存根的桌面平台上构建代码,以取代目标硬件依赖关系,并对其执行测试和代码覆盖。您必须相信目标C编译器和测试系统编译器都会使用相同的语义翻译源代码。这里的优点是可用的调试工具通常优于嵌入式系统可用的调试工具。在任何硬件可用之前,您还可以测试大部分代码,并且在大多数情况下执行代码的速度要快得多,可能允许进行更广泛的测试。

没有POSIX API并不排除使用GCC,它只是排除了使用GNU C库。在没有POSIX的嵌入式系统上,使用替代C库,如Newlib。 Newlib有一个系统移植层,用于实现I/O和基本堆管理。

0

我们family of C/C++ test coverage tools仪器源代码,产生程序,你与你的嵌入式编译器来编译,将收集的测试覆盖率的数据变成了“小”数据结构添加到程序。这适用于各种方言,包括ANSI,GCC,Microsoft和GreenHills。

您必须将该数据结构从嵌入式执行上下文导出到PC上的文件;通常使用备用串行或并行端口以及特定于您的端口的一小部分自定义代码很容易。这些工具将提供测试覆盖率视图和摘要结果文件。

因此,在大多数实际情况下,您可以使用这些工具从嵌入式系统收集测试覆盖率数据。

1

免责声明:我所工作的公司(Rapita Systems)提供针对嵌入式应用的代码覆盖解决方案。

因为嵌入式系统带来了自己的,特殊的和广泛变化的需求,所以代码覆盖的“最佳”解决方案也有很大差异。

  • 如果您有基于跟踪的设备,如具有ETM或启用了NEXUS的部件的ARM芯片,则可以在不通过调试器进行检测的情况下执行覆盖。
  • 否则,你最有可能面临着基于仪器的解决方案:
    • 对于RAM有限的解决方案,很好地解决是写仪器到I/O端口
    • 或者,你可以记录仪器来一个RAM缓冲区,并使用各种方法从目标中提取这些数据。

当然,很多代码覆盖率的不同口味的还有:函数,语句,决策/分支,MC/DC