Parasoft C/C++test怎么导入工程 Parasoft C/C++test头文件路径怎么补齐

Parasoft C/C++test导入工程的方法，以及头文件路径的补齐方式，其关键并不在于仅将源码文件夹选中。C/C++项目对编译器、宏定义、头文件目录、目标平台和构建脚本都存在依赖，如果这些信息没有被一同导入，工具所看到的代码便不是项目在真实编译时的代码，后续的静态分析、单元测试和规则检查都会因此出现偏差。Parasoft的文档中也曾提到，C/C++test能够通过构建数据文件、Visual Studio工程、CMake生成的JSON等方式，来收集输入范围和构建信息。

一、Parasoft C/C++test怎么导入工程

在导入工程之前，需要先确认项目是由IDE管理，还是通过Make、CMake、脚本或者交叉编译链来构建。不同项目的导入方式并不一样，不能只用“导入源码目录”这一种方法来处理，否则很容易缺少真实的编译参数。

1、先确认构建方式

如果项目是Visual Studio工程，可以直接使用它的解决方案或者项目文件；如果是CMake项目，可以使用它生成的compile_commands.json文件；如果是Make或者自定义脚本，一般需要通过构建跟踪的方式来生成BDF文件。C/C++test的命令行选项中也有说明，BDF可以通过trace选项、cpptestscan或者cpptesttrace等方式来生成。

2、导入构建数据

通过【Import】来导入工程文件、BDF文件或者compile_commands.json。

这一步的关键，是要把真实的构建命令带进来，这些命令里面包括了编译器、源文件、头文件路径、宏定义和编译选项。如果只导入了.c或者.cpp文件，工具虽然能看见源码，却不一定能正确地进行预处理，后面就可能大量地报告找不到头文件、宏未定义或者类型识别出错。

3、核对编译器配置

导入之后，需要检查编译器家族、编译器路径、语言标准和目标平台。在Parasoft的项目设置文档中曾提到，可以在编译器设置区域里指定C/C++源文件的编译器、链接器和编译器家族。对于嵌入式项目，尤其需要注意交叉编译器，不能用普通的GCC配置去代替ARM、TriCore、RH850这类工具链。

二、Parasoft C/C++test头文件路径怎么补齐

头文件路径补不齐，是C/C++test导入之后最常见的问题。这不一定说明源码本身有问题，更多的时候是因为工具没能拿到完整的include路径、宏定义或者编译条件。

1、先看报错出现的位置

如果报错都集中在工程内部头文件上，一般是项目的include目录没有添加完整；如果报错集中在编译器内置头文件或者标准库上，可能是编译器配置出错了；如果报错出现在芯片厂家SDK或者RTOS头文件上，多半是外部依赖的路径没有被带进来。

2、补充include目录

在【Build Settings】里补充项目头文件目录、平台SDK目录、第三方库目录和编译器内置头文件目录。

补充路径的时候，不能只添加当前报错文件所在的目录，而要顺着include的关系向上排查。比如源文件包含了project_config.h，而project_config.h又包含了芯片寄存器头文件和RTOS配置头文件，只补第一层路径往往是不够的。

3、补齐宏定义

很多头文件能不能生效，取决于宏定义。比如芯片型号、编译器类型、功能开关、平台版本，这些宏定义如果没有被带进来，工具就可能走入错误的条件编译分支。遇到头文件明明存在，但类型仍然识别失败的情况，就需要去检查宏定义，而不是只继续添加路径。

三、工程导入后怎么检查配置是否正确

工程导入完成之后，不建议马上去看规则违规的数量。需要先确认工程能不能被正确地预处理和分析，如果这一步没有做好，后面的结果就会夹杂很多由配置引起的干扰信息。

1、先进行小范围的分析

可以先选择一个核心模块，或者几个典型的源文件来运行分析，看一看是否还有大量的include错误、宏错误和类型错误。如果小范围的分析都跑不通，直接进行全量分析只会得到一堆无效的结果。

2、对比真实的编译日志

把C/C++test里面的编译参数和项目真实的构建日志拿来对比，重点看一看-I路径、-D宏定义、语言标准、编译器名称和目标平台是不是一致的。构建数据文件里记录的是构建过程的信息，Parasoft的文档也提到，trace会收集构建过程和输入范围的数据，并存入cpptest.bdf文件中。

3、固定工程配置

配置调通之后，需要把BDF、导入说明、编译器配置和关键的include路径都保存下来。后面在更换电脑、接入CI或者项目版本升级的时候，就可以按照同一个标准来复现，不用每次都重新去尝试路径。

总结

Parasoft C/C++test导入工程与补齐头文件路径这件事，可以按照“确认构建方式、导入真实的构建数据、核对编译器配置、补齐include路径和宏定义、再做小范围验证”这样的顺序来处理。C/C++test的分析结果可不可靠，在很大程度上要看工程配置是不是接近真实的编译环境。头文件路径不是看到缺了哪一个就机械地去补哪一个，而要结合构建日志、SDK路径、宏定义和工具链一起来核对，这样得到的静态分析和测试结果才会更加可信。