CN118689762A - 一种代码质量测试自动配置方法及相关设备 - Google Patents

Abstract

本申请公开了一种代码质量测试自动配置方法及相关设备，涉及代码质量检测领域，该方法包括：将待测试代码输入至目标编译器并根据文件生成规则进行编译操作，以生成中间文件，中间文件为待测试代码对应源文件和具有依赖关系的文件在编译过程产生的；获取配置文件库，配置文件库包括目标编译器的平台信息、源文件扩展名、依赖文件扩展名、代码测试软件工程配置文件路径和宏定义；基于目标代码测试软件的类型配置关键字库，关键字库包括源文件配置关键字、源文件格式关键字、头文件配置关键字、头文件格式关键字、宏定义配置关键字、宏定义格式关键字；基于配置文件库、关键字库、中间文件，自动配置目标代码测试软件的配置信息。

Description

一种代码质量测试自动配置方法及相关设备

技术领域

本说明书涉及代码质量检测领域，更具体地说，本申请涉及一种代码质量测试自动配置方法及相关设备。

背景技术

由于汽车级控制器高可靠性的特点，以及功能安全和信息安全的需要，各大主机厂早已不是只注重控制器软件的功能实现，而且由于功能测试本身的局限性，难以评估代码级别的测试覆盖度，以及测试用例的有限性不可能遍历所有输入情况，难以发现控制器软件潜在的缺陷。根据ISO 9126软件质量模型，评价软件质量有6个维度：功能性、可靠性、易用性、效率、维护性、可移植性。

评价软件可靠性的主要手段就是进行代码质量测试：找出缺陷代码，错误语句，运行风险代码和不满足编程规范的代码等。由于现在的车载控制软件普遍都是平台化，大多采用AUTOSAR平台，兼容多种处理器硬件，多种项目，这直接导致了软件架构比较复杂，代码量急剧增加，例如一个AUTOSAR平台的动力域控制器软件的代码量可以达到几个GByte，源文件(.c/.cpp)达到了3000个以上，头文件(.h)也达到了1000多个。

目前汽车控制器用得最多的编程语言还是C语言，做代码质量测试时首先需要提取项目中参与编译的源文件(例如.C文件)和被参与编译的源文件所包含的头文件.h文件，工程代码量不大的情况下，文件个数比较少，此部分工作手动配置完成即可，随着软件复杂程度的增加，此部分工作的复杂程序呈几何级数增长，而且容易出错，例如误添加了没有参与编译的源文件和头文件，或者少添加了参与编译的源文件和头文件都会造成代码质量测试工程编译错误，效率低下。有鉴于此，有必要提出了一种代码质量测试自动配置的方法。

发明内容

在发明内容部分中引入了一系列简化形式的概念，这将在具体实施方式部分中进一步详细说明。本申请的发明内容部分并不意味着要试图限定出所要求保护的技术方案的关键特征和必要技术特征，更不意味着试图确定所要求保护的技术方案的保护范围。

第一方面，本申请提出一种代码质量测试自动配置方法，包括：

将待测试代码输入至目标编译器并根据文件生成规则进行编译操作，以生成中间文件，其中，上述中间文件为上述待测试代码对应源文件和具有依赖关系的文件在编译过程产生的；

获取配置文件库，其中，上述配置文件库包括上述目标编译器的平台信息、源文件扩展名、依赖文件扩展名、代码测试软件工程配置文件路径和宏定义；

基于目标代码测试软件的类型配置关键字库，其中，上述关键字库包括源文件配置关键字、源文件格式关键字、头文件配置关键字、头文件格式关键字、宏定义配置关键字、宏定义格式关键字；

基于上述配置文件库、上述关键字库、上述中间文件，自动配置上述目标代码测试软件的配置信息。

在一种可行的实施方式中，上述中间文件包括目标文件和依赖文件，上述目标文件为上述源文件对应的编译后文件，上述目标文件与上述源文件包括相同的文件名称，上述依赖文件为与上述源文件具有依赖关系的文件对应的编译后文件，上述依赖文件与上述源文件具有依赖关系的文件包括相同的文件名称。

在一种可行的实施方式中，上述文件生成规则包括目标文件生成规则和依赖文件生成规则，上述目标文件生成规则包括源文件初始名称后缀信息和目标文件后缀信息的映射关系，上述依赖文件生成规则包括与上述源文件具有依赖关系的文件的后缀信息和依赖文件后缀信息的映射关系。

在一种可行的实施方式中，上述基于上述配置文件库、上述关键字库、上述中间文件，自动配置上述目标代码此时软件的配置信息，包括：

根据上述目标编译器的平台信息、上述源文件扩展名、上述目标文件生成规则在上述中间文件中遍历筛选，以获取源文件路径信息；

根据上述目标编译器的平台信息、上述依赖文件扩展名、上述依赖文件生成规则在上述中间文件中遍历筛选，以获取依赖文件路径信息；

根据上述源文件路径信息、上述依赖文件路径信息和上述关键字库，自动配置上述目标代码测试软件的配置信息。

在一种可行的实施方式中，还包括：

在上述目标编译器的平台信息为Windows平台、原文件扩展名是.c的情况下，在上述中间文件中遍历筛选.obj的文件，以获取上述源文件路径信息。

在一种可行的实施方式中，还包括：

在上述目标编译器的平台信息为Linux平台、原文件扩展名是.c的情况下，在上述中间文件中遍历筛选.o的文件，以获取上述源文件路径信息。

在一种可行的实施方式中，上述根据上述目标编译器的平台信息、上述依赖文件扩展名、上述依赖文件生成规则在上述中间文件中遍历筛选，以获取依赖文件路径信息，包括：

根据上述目标编译器的平台信息、上述依赖文件扩展名、上述依赖文件生成规则在上述中间文件中遍历筛选，以获取依赖文件内容；

将上述依赖文件内容的前n行丢弃，以获取上述依赖文件路径信息。

第二方面、本申请提出一种代码质量测试自动配置装置，包括：

编译单元，用于将待测试代码输入至目标编译器并根据文件生成规则进行编译操作，以生成中间文件，其中，上述中间文件为上述待测试代码对应源文件和具有依赖关系的文件在编译过程产生的；

获取单元，用于获取配置文件库，其中，上述配置文件库包括上述目标编译器的平台信息、源文件扩展名、依赖文件扩展名、代码测试软件工程配置文件路径和宏定义；

第一配置单元，用于基于目标代码测试软件的类型配置关键字库，其中，上述关键字库包括源文件配置关键字、源文件格式关键字、头文件配置关键字、头文件格式关键字、宏定义配置关键字、宏定义格式关键字；

第二配置单元，用于基于上述配置文件库、上述关键字库、上述中间文件，自动配置上述目标代码测试软件的配置信息。

第三方面，一种电子设备，包括：存储器、处理器以及存储在上述存储器中并可在上述处理器上运行的计算机程序，上述处理器用于执行存储器中存储的计算机程序时实现如上述的第一方面任一项的代码质量测试自动配置方法的步骤。

第四方面，本申请还提出一种计算机可读存储介质，其上存储有计算机程序，上述计算机程序被处理器执行时实现第一方面任一项的代码质量测试自动配置方法。

综上，本申请实施例的代码质量测试自动配置方法包括：将待测试代码输入至目标编译器并根据文件生成规则进行编译操作，以生成中间文件，其中，上述中间文件为上述待测试代码对应源文件和具有依赖关系的文件在编译过程产生的；获取配置文件库，其中，上述配置文件库包括上述目标编译器的平台信息、源文件扩展名、依赖文件扩展名、代码测试软件工程配置文件路径和宏定义；基于目标代码测试软件的类型配置关键字库，其中，上述关键字库包括源文件配置关键字、源文件格式关键字、头文件配置关键字、头文件格式关键字、宏定义配置关键字、宏定义格式关键字；基于上述配置文件库、上述关键字库、上述中间文件，自动配置上述目标代码测试软件的配置信息。本申请实施例提出的方法，通过自动化编译过程减少了人为错误，确保每个源文件都正确编译，依赖关系得到准确反映。自动编译和生成中间文件在源文件数量众多时大大提高了处理速度。集中管理编译器平台信息、文件扩展名和测试配置路径等，确保所有项目组件使用一致的设置，减少配置差异导致的问题。关键字库允许自定义配置代码测试软件的方式，适应不同的测试需求和工具。随着项目的发展，新增的文件类型和编译选项可以轻松加入到关键字库中，无需重构现有的测试配置。自动配置测试软件确保了包括所有必要文件在内的完整测试覆盖，减少了遗漏或错误包含文件的风险。在一个典型的汽车级控制器软件项目中，如一个基于AUTOSAR平台的动力域控制器，代码和文件数量可能非常庞大。传统的手动配置方法不仅耗时而且容易出错，尤其是在源文件或头文件频繁更新的环境中。本方案通过自动化这一过程，可以显著提高开发和测试的效率，减少因配置错误导致的延误，同时增加软件发布的稳定性和可靠性。

本申请提出的代码质量测试自动配置方法，本申请的其它优点、目标和特征将部分通过下面的说明体现，部分还将通过对本申请的研究和实践而为本领域的技术人员所理解。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本说明书的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本申请实施例提供的一种代码质量测试自动配置方法流程性示意图；

图2为本申请实施例提供的一种代码质量测试自动配置原理性示意图；

图3为本申请实施例提供的一种代码质量测试自动配置装置结构示意图；

图4为本申请实施例提供的一种代码质量测试自动配置电子设备结构示意图。

具体实施方式

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。

代码质量测试的常规做法是，根据嵌入式软件工程的编译方式例如,makefile脚本编译，python脚本编译，CodeWarrior编译器IDE界面等正向分析，分别研究具体工程的makefile脚本、python脚本、CodeWarrior编译器IDE界面的内容，获取到整个工程中参与编译的源文件及头文件等，而且IDE界面的软件通常只能靠人工去看界面的内容(工程源文件少时比较直观，工程源文件多时工作比较繁琐容易出错)；由于前期软件的过程使用的编译方式各种各样，无法统一，其具体的硬件IC、AUTOSAR平台版本等有关系，无法所有项目改成一种编译方式，通常由于移植工作量大的问题，实际开发工作中编译环境不轻易改变，给后面的开发代码质量测试工程的工作带来困扰，很难去实现自动化。

请参阅图1，为本申请实施例提供的一种代码质量测试自动配置方法流程性示意图，具体可以包括：

S110、将待测试代码输入至目标编译器并根据文件生成规则进行编译操作，以生成中间文件，其中，上述中间文件为上述待测试代码对应源文件和具有依赖关系的文件在编译过程产生的；

示例性的，将待测试的代码输入目标编译器，按照文件生成规则进行编译操作，以生成中间文件。中间文件是在编译过程中源文件及其依赖的头文件信息形成的。

S120、获取配置文件库，其中，上述配置文件库包括上述目标编译器的平台信息、源文件扩展名、依赖文件扩展名、代码测试软件工程配置文件路径和宏定义；

示例性的，获取配置文件库，包括目标编译器的平台信息、源文件扩展名、依赖文件扩展名、代码测试软件工程配置文件路径和宏定义等。配置文件库可能包括Windows平台或Linux平台、源文件扩展名.c、依赖文件扩展名.d、Polyspace配置文件路径等信息

S130、基于目标代码测试软件的类型配置关键字库，其中，上述关键字库包括源文件配置关键字、源文件格式关键字、头文件配置关键字、头文件格式关键字、宏定义配置关键字、宏定义格式关键字；

示例性的，定义用于自动配置代码测试软件的关键字和格式，确保可以从中间文件中提取正确的信息。关键字包括源文件和头文件的配置关键字及其格式。这些关键字用于解析和格式化测试配置文件中的条目。

S140、基于上述配置文件库、上述关键字库、上述中间文件，自动配置上述目标代码测试软件的配置信息。

示例性的，利用已定义的配置文件库和关键字库，结合从中间文件中提取的信息，自动填充或更新代码质量测试工具的配置文件。

综上，本申请实施例提出的方法，通过自动化编译过程减少了人为错误，确保每个源文件都正确编译，依赖关系得到准确反映。自动编译和生成中间文件(目标文件和依赖文件)在源文件数量众多时大大提高了处理速度。集中管理编译器平台信息、文件扩展名和测试配置路径等，确保所有项目组件使用一致的设置，减少配置差异导致的问题。关键字库允许自定义配置代码测试软件的方式，适应不同的测试需求和工具。随着项目的发展，新增的文件类型和编译选项可以轻松加入到关键字库中，无需重构现有的测试配置。自动配置测试软件确保了包括所有必要文件在内的完整测试覆盖，减少了遗漏或错误包含文件的风险。在一个典型的汽车级控制器软件项目中，如一个基于AUTOSAR平台的动力域控制器，代码和文件数量可能非常庞大。传统的手动配置方法不仅耗时而且容易出错，尤其是在源文件或头文件频繁更新的环境中。本方案通过自动化这一过程，可以显著提高开发和测试的效率，减少因配置错误导致的延误，同时增加软件发布的稳定性和可靠性。

在一些示例中，上述中间文件包括目标文件和依赖文件，上述目标文件为上述源文件对应的编译后文件，上述目标文件与上述源文件包括相同的文件名称，上述依赖文件为与上述源文件具有依赖关系的文件对应的编译后文件，上述依赖文件与上述源文件具有依赖关系的文件包括相同的文件名称。

示例性的，目标文件是源文件编译后生成的二进制文件，通常用于链接阶段生成执行文件。每个源文件(如.c或.cpp文件)会生成一个对应的目标文件(如.o文件)。

每个目标文件与其对应的源文件有相同的基本文件名，仅扩展名不同。例如，源文件main.c的目标文件将是main.o。

依赖文件包含了源文件与其依赖的头文件(.h文件)之间的关系。这些文件是为了优化编译过程，确保当头文件更新时，依赖这些头文件的源文件可以重新编译。

依赖文件的命名方式与目标文件类似，基于源文件名称生成。例如，源文件main.c的依赖文件将是main.d，里面列出了所有main.c依赖的头文件。

使用命令如gcc-c main.c-o main.o生成目标文件。

使用命令如gcc-M main.c生成依赖文件，通常通过一些脚本处理输出以生成格式化的.d文件，这些文件被用来在后续编译中自动检查依赖关系。

通过读取.d文件中的信息，自动化工具可以了解哪些源文件和头文件是相关联的，从而确保在代码质量分析时包括所有相关的文件。虽然目标文件在代码质量测试中不直接使用，它们的生成确保了源文件是可编译的，且编译环境是配置正确的。

根据编译平台和编译器的信息(从配置文件库获取)，设置适当的编译标志和路径。使用关键字库来定义测试工具需要的源文件路径、头文件路径和宏定义等配置项。

使用从中间文件.d解析的依赖关系和从配置文件库获取的信息，自动填充代码质量测试工具(如Polyspace,Coverity等)的配置文件，包括正确的文件路径、编译标志和其他必要的设置。

这种自动化的方法减少了人工干预的需求，降低了配置错误的可能性，并能够在大规模的项目中节省大量的时间和努力。自动分析依赖关系确保了测试的完整性，每次源文件或头文件更新后，都可以自动重新进行相关的代码质量测试，保证了项目质量的持续监控和提升。

在一些示例中，上述文件生成规则包括目标文件生成规则和依赖文件生成规则，上述目标文件生成规则包括源文件初始名称后缀信息和目标文件后缀信息的映射关系，上述依赖文件生成规则包括与上述源文件具有依赖关系的文件的后缀信息和依赖文件后缀信息的映射关系。

示例性的，关于目标文件和依赖文件的生成规则，它们都涉及到如何通过编译器将源文件(如.c文件)转化为相应的目标文件(如.o文件)和依赖文件(如.d文件)。这些规则不仅确保了编译过程的正确执行，而且为自动化工具提供了必要的信息来配置代码质量测试

具体的，定义目标文件的生成规则可以为：

％.o:％.c

gcc-c-o$@$<

定义依赖文件的生成规则可以为：

％d:％c

gcc-M$(CPPFLAGS)$<>$@.$$$$；\

sed's,\($*\)\.o[:]*,\1.o$@:,g'<$@.$$$$>$@；\

rm-f$@.$$$$

根据如上方法，嵌入式工程编译时编译器会生成我们需要的中间文件。

在一些示例中，上述基于上述配置文件库、上述关键字库、上述中间文件，自动配置上述目标代码此时软件的配置信息，包括：

根据上述目标编译器的平台信息、上述源文件扩展名、上述目标文件生成规则在上述中间文件中遍历筛选，以获取源文件路径信息；

根据上述目标编译器的平台信息、上述依赖文件扩展名、上述依赖文件生成规则在上述中间文件中遍历筛选，以获取依赖文件路径信息；

根据上述源文件路径信息、上述依赖文件路径信息和上述关键字库，自动配置上述目标代码测试软件的配置信息。

示例性的，使用目标编译器的平台信息、源文件扩展名和目标文件生成规则遍历中间文件，通过这些信息，可以确定哪些源文件根据目标文件生成规则被编译成了目标文件，从而准确地识别出所有已编译的源文件。

根据编译器的平台信息和依赖文件扩展名以及依赖文件生成规则，从中间文件中筛选出依赖文件，并获取依赖文件的路径信息。

根据收集的文件路径信息和预设的关键字库，自动化配置代码测试软件。整合源文件和依赖文件的路径信息，根据测试软件的要求填充其配置文件。

本申请实施例提出的方法，自动化配置大大减少了人力投入和配置错误。源文件或依赖文件的任何更改都可以快速反映在测试配置中，保持测试环境的实时更新。能够自动追踪依赖关系确保没有文件被遗漏，提升测试的全面性。这种方法的核心在于利用编译过程中自然产生的信息来支持测试过程，确保测试的及时性和全面性。

在一些示例中，还包括：

在上述目标编译器的平台信息为Windows平台、原文件扩展名是.c的情况下，在上述中间文件中遍历筛选.obj的文件，以获取上述源文件路径信息。

示例性的，在Windows平台上，C语言编译生成的目标文件通常具有.obj扩展名。源文件为.c，目标文件为.obj。遍历中间文件，扫描包含编译生成的.obj文件的目录。从每个.obj文件的命名和位置推断出其对应的.c源文件的路径。.obj文件和其对应的.c文件具有相同的基本文件名。

在一些示例中，还包括：

在上述目标编译器的平台信息为Linux平台、原文件扩展名是.c的情况下，在上述中间文件中遍历筛选.o的文件，以获取上述源文件路径信息。

示例性的，在Linux平台上，C语言编译生成的目标文件通常具有.o扩展名。源文件为.c，目标文件为.o。扫描包含编译生成的.o文件的目录。从每个.o文件的命名和位置推断出其对应的.c源文件的路径。与Windows类似，.o文件和其对应的.c文件通常具有相同的基本文件名。

在一些示例中，上述根据上述目标编译器的平台信息、上述依赖文件扩展名、上述依赖文件生成规则在上述中间文件中遍历筛选，以获取依赖文件路径信息，包括：

根据上述目标编译器的平台信息、上述依赖文件扩展名、上述依赖文件生成规则在上述中间文件中遍历筛选，以获取依赖文件内容；

将上述依赖文件内容的前n行丢弃，以获取上述依赖文件路径信息。

示例性的，在控制器软件工程里面遍历所有文件，根据依赖文件的扩展名，获取到所有的依赖文件,读取所有依赖文件里面的内容，一般情况下前面两(n)行是源文件和目标文件的绝对路径，需要丢弃，只需要提取所有的头文件(.h文件)的绝对路径，并去掉具体的h文件名，去掉重复，最终得到的就是编译所依赖的所有头文件且不包含文件名的路径。

在一些示例中，由于编译器编译时都需要生成目标文件(机器码)，编译时嵌入式编译器会在嵌入式工程的包含目录中去查找头文件(依赖关系)，所以配置嵌入式编译器根据每个编译的源文件单独生成相同文件名的目标文件，并将每个编译的源文件的依赖关系单独生成相同文件名的依赖文件；嵌入式编译器生成的文件在文中称为编译时编译器生成的中间文件。具体实现原理如图2所示，具体步骤包括：

S210、为了实现配置嵌入式编译器根据每个编译的源文件单独生成相同文件名的目标文件，并将每个编译的源文件的依赖关系单独生成相同文件名的依赖文件。由于目前使用的嵌入式编译环境大多数使用makefile去调度编译器、用python的scons模块去调度编译器、各个厂家的IDE界面等几大类，具体的环境配置方法可能各有区别；此处以使用最多的makefile文件去调度GCC编译器为例，实现代码如下：

定义目标文件的生成规则：

％.o:％.c

gcc-c-o$@$<

定义依赖文件的生成规则：

％d:％c

gcc-M$(CPPFLAGS)$<>$@.$$$$；\

sed's,\($*\)\.o[:]*,\1.o$@:,g'<$@.$$$$>$@；\

rm-f$@.$$$$

根据如上方法，嵌入式工程编译时编译器会生成我们需要的中间文件。

测试的输入是使用嵌入式编译器能编译通过的完整控制器软件工程文件，例如对于源文件是C语言的控制器软件工程包括.c文件(源文件)、.h文件(头文件)、编译脚本、编译时编译器生成的中间文件等。

S220、配置文件库：由用户填写工程项目的基本的信息，包括嵌入式编译器编译的平台(Windows平台或者Linux平台)；源文件扩展名(例如.c)；编译器输出的依赖文件的扩展名(例如.d)；代码质量测试软件工程配置文件及路径(例如：Polyspace软件配置文件及路径是D:\CodeTest\demo.psprj,具体工程配置文件扩展名参考软件的帮助手册，具体路径和用户新建工程时选择的路径有关)；宏定义等(包含但不仅限于以上配置信息)。

S230、参与编译的源文件提取模块：查询配置文件里面的嵌入式编译器编译的平台，如果是Windows平台则查找扩展名是.obj的文件，如果是Linux平台则查找扩展名是.o的文件,在控制器软件工程里面遍历所有文件，根据目标文件的扩展名，获取到所有的目标文件的文件名，然后查找和每个目标文件名字相同且扩展名是配置文件库中查询到的源文件扩展名的源文件，并得到其绝对路径。获取到的内容即是所有参与编译的包含源文件名的路径。

S240、参与编译的源文件的依赖头文件提取模块：查询配置文件里面的编译器输出的依赖文件的扩展名(例如.d),在控制器软件工程里面遍历所有文件，根据依赖文件的扩展名，获取到所有的依赖文件,读取所有依赖文件里面的内容，一般情况下前面两行是源文件和目标文件的绝对路径，需要丢弃，只需要提取所有的头文件(.h文件)的绝对路径，并去掉具体的h文件名，去掉重复，最终得到的就是编译所依赖的所有头文件且不包含文件名的路径。宏是一行代码，控制编译过程

S250、工程配置关键字库：由用户根据不同的代码质量测试软件填写具体的工程配置关键字内容。源文件配置关键字(例如：<source>)；源文件格式关键字(例如：<filepath＝"SourcePath"/>)；头文件配置关键字(例如：<include>)；头文件格式关键字(例如：<file path＝"IncludePath"order＝"％d"/>)；宏定义配置关键字(例如<optionflagname＝"-D">)，宏定义格式关键字(例如<element>Macro</element>)；包括但不仅限于以上关键字，具体的关键字内容根据具体使用的代码质量测试软件帮助手册得到。

S260、代码质量测试工程自动化配置模块：

读取工程配置关键字库中源文件配置关键字的内容，例如读取到的内容是：<source>；读取源文件格式关键字，例如读取到的内容是<file path＝"SourcePath"/>；

根据路径读取配置文件库里面的代码质量测试软件工程配置文件，例如读取到的内容是：D:\CodeTest\demo.psprj，读取此文件的具体内容，查找源文件配置关键字的内容，例如<source>，在此行的下面按源文件格式关键字的格式(例如：<file path＝"SourcePath"/>)一行一行地写入S230中获取到的所有参与编译的包含源文件名的路径(每个路径一行)，写入格式中的SourcePath分别用每一条源文件的路径替代。例如写入：<filepath＝"D:\CodeTest\source\demo.c"/>

在代码质量测试软件工程配置文件中查找头文件配置关键字(例如：<include>)，在此行的下面按头文件格式关键字(例如：<file path＝"IncludePath"order＝"％d"/>)一行一行地写入S240中获取到的编译所依赖的所有头文件的路径(每个路径一行)，写入格式中的IncludePath分别用每一条所依赖的头文件的路径替代，％d用数字代替，从0开始，每一条记录加1，依次递增。例如写入第一条记录：<file path＝"D:\CodeTest\inc"order＝"0"/>，其它的依此类推。

在代码质量测试软件工程配置文件中查找宏定义配置关键字(例如：<optionflagname＝"-D">)，在此行的下面按宏定义格式关键字(例如<element>Macro</element>),一行一行的写入S220中配置文件库里面的宏定义(每个宏定义一行)，写入格式中的Macro分别用每一条宏替代。例如对于宏定义USECANIF写入：<element>USECANIF</element>。

上述实施例以Mathworks公司的Polyspace软件为例，其它的不同代码质量测试软件比较特殊的配置参考以上实施例，在此不做赘述。

如图3所示，为本申请提出一种代码质量测试自动配置装置，包括：

编译单元21，用于将待测试代码输入至目标编译器并根据文件生成规则进行编译操作，以生成中间文件，其中，上述中间文件为上述待测试代码对应源文件和具有依赖关系的文件在编译过程产生的；

获取单元22，用于获取配置文件库，其中，上述配置文件库包括上述目标编译器的平台信息、源文件扩展名、依赖文件扩展名、代码测试软件工程配置文件路径和宏定义；

第一配置单元23，用于基于目标代码测试软件的类型配置关键字库，其中，上述关键字库包括源文件配置关键字、源文件格式关键字、头文件配置关键字、头文件格式关键字、宏定义配置关键字、宏定义格式关键字；

第二配置单元24，用于基于上述配置文件库、上述关键字库、上述中间文件，自动配置上述目标代码测试软件的配置信息。

如图4所示，本申请实施例还提供一种电子设备300，包括存储器310、处理器320及存储在存储器310上并可在处理器上运行的计算机程序311，处理器320执行计算机程序311时实现上述代码质量测试自动配置的任一方法的步骤。

由于本实施例所介绍的电子设备为实施本申请实施例中一种代码质量测试自动配置装置所采用的设备，故而基于本申请实施例中所介绍的方法，本领域所属技术人员能够了解本实施例的电子设备的具体实施方式以及其各种变化形式，所以在此对于该电子设备如何实现本申请实施例中的方法不再详细介绍，只要本领域所属技术人员实施本申请实施例中的方法所采用的设备，都属于本申请所欲保护的范围。

在具体实施过程中，该计算机程序311被处理器执行时可以实现图1对应的实施例中任一实施方式。

需要说明的是，在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详细描述的部分，可以参见其它实施例的相关描述。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式计算机或者其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

本申请实施例还提供了一种计算机程序产品，该计算机程序产品包括计算机软件指令，当计算机软件指令在处理设备上运行时，使得处理设备执行对应实施例中的代码质量测试自动配置的流程。

计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (10)

1.一种代码质量测试自动配置的方法，其特征在于，包括：

将待测试代码输入至目标编译器并根据文件生成规则进行编译操作，以生成中间文件，其中，所述中间文件为所述待测试代码对应源文件和具有依赖关系的文件在编译过程产生的；

获取配置文件库，其中，所述配置文件库包括所述目标编译器的平台信息、源文件扩展名、依赖文件扩展名、代码测试软件工程配置文件路径和宏定义；

基于目标代码测试软件的类型配置关键字库，其中，所述关键字库包括源文件配置关键字、源文件格式关键字、头文件配置关键字、头文件格式关键字、宏定义配置关键字、宏定义格式关键字；

基于所述配置文件库、所述关键字库、所述中间文件，自动配置所述目标代码测试软件的配置信息。

2.根据权利要求1所述的代码质量测试自动配置的方法，其特征在于，所述中间文件包括目标文件和依赖文件，所述目标文件为所述源文件对应的编译后文件，所述目标文件与所述源文件包括相同的文件名称，所述依赖文件为与所述源文件具有依赖关系的文件对应的编译后文件，所述依赖文件与所述源文件具有依赖关系的文件包括相同的文件名称。

3.根据权利要求2所述的代码质量测试自动配置的方法，其特征在于，所述文件生成规则包括目标文件生成规则和依赖文件生成规则，所述目标文件生成规则包括源文件初始名称后缀信息和目标文件后缀信息的映射关系，所述依赖文件生成规则包括与所述源文件具有依赖关系的文件的后缀信息和依赖文件后缀信息的映射关系。

4.根据权利要求3所述的代码质量测试自动配置的方法，其特征在于，所述基于所述配置文件库、所述关键字库、所述中间文件，自动配置所述目标代码此时软件的配置信息，包括：

根据所述目标编译器的平台信息、所述源文件扩展名、所述目标文件生成规则在所述中间文件中遍历筛选，以获取源文件路径信息；

根据所述目标编译器的平台信息、所述依赖文件扩展名、所述依赖文件生成规则在所述中间文件中遍历筛选，以获取依赖文件路径信息；

根据所述源文件路径信息、所述依赖文件路径信息和所述关键字库，自动配置所述目标代码测试软件的配置信息。

5.根据权利要求4所述的代码质量测试自动配置的方法，其特征在于，还包括：

在所述目标编译器的平台信息为Windows平台、原文件扩展名是.c的情况下，在所述中间文件中遍历筛选.obj的文件，以获取所述源文件路径信息。

6.据权利要求4所述的代码质量测试自动配置的方法，其特征在于，还包括：

在所述目标编译器的平台信息为Linux平台、原文件扩展名是.c的情况下，在所述中间文件中遍历筛选.o的文件，以获取所述源文件路径信息。

7.据权利要求4所述的代码质量测试自动配置的方法，其特征在于，所述根据所述目标编译器的平台信息、所述依赖文件扩展名、所述依赖文件生成规则在所述中间文件中遍历筛选，以获取依赖文件路径信息，包括：

根据所述目标编译器的平台信息、所述依赖文件扩展名、所述依赖文件生成规则在所述中间文件中遍历筛选，以获取依赖文件内容；

将所述依赖文件内容的前n行丢弃，以获取所述依赖文件路径信息。

8.一种代码质量测试自动配置装置，其特征在于，包括：

编译单元，用于将待测试代码输入至目标编译器并根据文件生成规则进行编译操作，以生成中间文件，其中，所述中间文件为所述待测试代码对应源文件和具有依赖关系的文件在编译过程产生的；

获取单元，用于获取配置文件库，其中，所述配置文件库包括所述目标编译器的平台信息、源文件扩展名、依赖文件扩展名、代码测试软件工程配置文件路径和宏定义；

第一配置单元，用于基于目标代码测试软件的类型配置关键字库，其中，所述关键字库包括源文件配置关键字、源文件格式关键字、头文件配置关键字、头文件格式关键字、宏定义配置关键字、宏定义格式关键字；

第二配置单元，用于基于所述配置文件库、所述关键字库、所述中间文件，自动配置所述目标代码测试软件的配置信息。

9.一种电子设备，包括：存储器和处理器，其特征在于，所述处理器用于执行存储器中存储的计算机程序时实现如权利要求1-7中任一项所述的代码质量测试自动配置方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-7中任一项所述的代码质量测试自动配置方法的步骤。