BullsEye代码覆盖

Question

有人能告诉我如何在arm处理器上执行代码覆盖率分析吗？

我可以通过编写测试用例并在我的计算机上运行它们来进行代码覆盖率分析，但是，在没有在目标设备(arm处理器)上安装代码覆盖率工具的情况下，是否可以在arm处理器上运行代码时执行覆盖率分析？

这将节省大量时间，因为这样我就不会显式地为嵌入式C代码中涉及的所有函数和条件编写测试用例。

Answer 1

我对手臂没有特别的经验。我在如何收集嵌入式系统中的测试覆盖数据方面有经验(作为嵌入式测试覆盖率工具的设计者)。

你需要以下几点：

• 一种工具，它以紧凑的格式收集运行时测试覆盖率数据，并且在嵌入式系统中具有简单且易于定位的结构。
• 在您的嵌入式系统中有一些额外的空间，足以容纳运行时测试覆盖率数据。在一些空间极其有限的嵌入式系统中，这可能是一个问题。
• 一种导出机制，可以在方便的时候将数据从嵌入式系统复制到开发系统。
• 工具中的一种导入机制，可以接受这些导出的数据。

有了这三个元素之后，您现在可以收集测试覆盖率数据：

1. 基于开发系统编写的工具并进行编译。
2. 将对象文件导出到嵌入式系统。
3. 运行嵌入式应用程序，以任何您认为合适的方式执行测试。
4. 将覆盖范围数据导出到开发系统。
5. 导入测试覆盖工具以解释结果。

我不能说“牛眼”，它确实是做某种乐器的。我们的测试覆盖工具涵盖了各种语言(Java、C、C#、C++等等)，并且具有所有必要的属性(尽管我很难想象一个嵌入式PL/SQL应用程序！)。

我们的工具将测试覆盖数据存储为密集的布尔字节/位向量块(C和C++的选择，其他语言的字节向量)。这减少了对嵌入式系统的额外存储需求。如果这一点太多，我们的工具将允许您收集应用程序中较小部分的测试覆盖率数据，并将结果结合起来，为整个嵌入式应用程序提供测试覆盖率。您可以将多个测试作为一种权衡来运行，但您至少可以这样做，而脚本可以帮助改善这些步骤的乏味。

我们不要求测试覆盖向量(TCV)是如何从嵌入式系统导出的，因为这将限制我们的工具可以处理哪些系统。我们提供了一个“标准”导出函数，它简单地将向量块直接写入开发系统磁盘文件；在对开发系统本身进行测试覆盖率收集时，该导出系统的使用将保持不变(正如您已经在某种程度上表示的那样)。导出函数将添加到工具化应用程序中，并进行编译/链接，以启用使用。通常在程序退出时调用它，但是您可以在应用程序中的任何方便点调用它，包括由外部事件触发的点。该工具包含一个交互式组件，它将读取此类文件并构造摘要报告，并以交互方式向您展示已执行/未执行的代码。

在嵌入式上下文中，可以将导出函数替换为自己的导出函数。它只有大约50行代码，所以没有什么可替换的。在大多数嵌入式系统中，都有可用的额外I/O端口(并行输出位、串行端口，您可以说是这样)；其中一个代码是将二进制测试覆盖率数据感知到这个输出位的例程。任何嵌入式工程师都可以编写位序列化程序或发送字节到串行端口代码块，而不会遇到什么麻烦。此时，可以从嵌入式系统导出测试覆盖数据。如果您的嵌入式系统有一个文件系统，那么对代码的更改即使不存在，也是微不足道的。

最后一步是捕获这个比特流。这需要在开发系统上构建一个自定义程序，该程序读取一些可用的硬件输入(很容易找到串行端口，因此这很流行)，并在内存中重新生成测试覆盖率数据的位映像。默认的导出函数可以复制到自定义程序中，只需稍加修改就可以将数据移动到磁盘文件中。在这一步之后，测试覆盖交互组件可以读取覆盖数据；它并不关心它来自何处。

因此，通过对导出过程进行一些定制，您可以在几乎任意的嵌入式上下文中使用我们的工具。(我们有一个客户用它来测试内置在笔记本电脑电池中的微处理器！)一个称职的嵌入式工程师需要一天左右的时间来修改嵌入式版本的导出功能和开发系统驻留部分，然后您就可以收集到您的心脏内容的测试覆盖率。

这种技术是由我们的客户用我们的C、C++、C#和Java测试覆盖工具实现的。