CN117539791A - 一种嵌入式软件的自动化测试系统 - Google Patents

Abstract

本发明公开了一种嵌入式软件的自动化测试系统，涉及软件测试技术领域，该系统公开了板卡能力定义和固件编译层、测试计划解析和用例生成层、程序部署和测试调度执行层，通过板卡固件生成与硬件板卡解耦，解决传统的CICD系统无法很好地支持硬件板卡多样性和差异性，导致流程的繁琐和效率的低下的问题；板卡硬件和程序版本，版本管理统一，有利于追溯管理；测试用例归类统一管理，合理复用；板卡测试计划自动解析，利于管理和自动化测试；板卡程序开发与测试工作解耦，提高代码开发、测试和功能迭代效率。

Description

一种嵌入式软件的自动化测试系统

技术领域

本发明涉及软件测试技术领域，更具体地说，它涉及一种嵌入式软件的自动化测试系统。

背景技术

基于DevOps理念的持续集成/持续交付(CICD)系统是一种自动化的软件构建、测试和部署流程，旨在加速软件发布并提高软件质量。它结合了开发和运营团队的协作，通过快速、频繁地交付高质量的软件来满足业务需求。

传统的CICD系统广泛应用于互联网等纯软件开发企业中，可以做到快速响应市场变化、提高业务灵活性和降低运营成本。

对于嵌入式软件开发公司，采用传统的CICD系统进行特定硬件板卡的软件开发和测试可能会遇到多种问题(硬件板卡多样性和差异性、硬件测试的复杂性、硬件板卡与软件的协同问题、硬件依赖性等)，导致不能实现自动化的软件构建、测试和部署及测试流程。

发明内容

针对现有技术存在的不足，本发明的目的在于提供一种嵌入式软件的自动化测试系统。

为实现上述目的，本发明提供了如下技术方案：

一种嵌入式软件的自动化测试系统，包括板卡能力定义和固件编译层、测试计划解析和用例生成层、程序部署和测试调度执行层；

所述板卡能力定义和固件编译层用于管理硬件板卡资源、管理源代码以及管理固件构建；

所述管理硬件板卡资源具体为支持yaml描述文件，描述硬件板卡的名称，CPU架构，包含的外设等信息；

所述管理源代码具体为支持根据配置文件，自动拉取对应的gitlab仓库，支持生成gitlog文件，并打包到镜像中，实时查看该镜像的版本信息；

所述管理固件构建具体为基于yaml格式配置文件，自动生成硬件板卡的程序固件配置文件；

所述测试计划解析和用例生成层用于根据板卡描述文件board_xxx.yml，描述特定板卡的外设列表，并通过系统自动生成特定的测试用例字典文件，根据测试用例字典文件，编译生成对应的测试用例代码；

所述程序部署和测试调度执行层用于根据板卡描述文件board_xxx.yml和测试用例字典文件，把测试用例字典文件对应到具体板卡，针对具体板卡执行固件程序和测试用例的部署和执行。

进一步的，一种嵌入式软件的自动化测试系统，该系统的执行流程包括如下步骤：

prepare代码拉取准备：利用源代码管理工具，拉取所有仓库源代码，并且生成version.txt,记录所有仓库的commit信息，打包一份完整的源代码到archived目录的src文件夹；

板卡固件代码编译：扫描所有firmware描述文件，在build目录下创建firmware镜像输出路径，编译所有对应的firmware，扫描所有test描述文件，在build目录下创建testsuite镜像输出路径，编译所有对应的testsuite；

生成测试计划：生成每个firmware的test_plan，默认全部平台运行所有testsuite,由于部分testsuite需要不同驱动支持，故每个firmware的test_plan不完全相同；

映射程序固件和板卡：分配执行并行测试的任务，每个board只能对应一个firmware，即一个test_plan；

部署固件和执行测试用例：所有board根据mapping的test_plan进行测试，deploy到target，所有测试运行完成后，收集所有测试报告；

测试结果汇总，测试结果归档：归档所有源代码、编译生成文件，测试报告，程序固件版本信息，上传服务器，发生测试结果邮件。

与现有技术相比，本发明具备以下有益效果：

板卡固件生成与硬件板卡解耦，解决传统的CICD系统无法很好地支持硬件板卡多样性和差异性，导致流程的繁琐和效率的低下的问题；板卡硬件和程序版本，版本管理统一，有利于追溯管理；测试用例归类统一管理，合理复用；板卡测试计划自动解析，利于管理和自动化测试；板卡程序开发与测试工作解耦，提高代码开发、测试和功能迭代效率。

附图说明

图1为一种嵌入式软件的自动化测试系统的原理框图；

图2为本发明流程框图。

具体实施方式

参照图1至图2

关于传统CICD软件平台(例如Jenkins)的使用不足、学习成本高和配置复杂等问题，可以从以下几个方面进行对比：

1.传统cicd软件平台不能有效覆盖嵌入式设备的软件开发领域：

Jenkins作为一种流行的CICD工具，虽然功能强大，但它主要面向通用软件开发场景，而不是专门针对嵌入式软件开发。这意味着在处理与硬件相关的任务时，Jenkins可能不足以提供特定的功能或集成，如直接支持硬件板卡的特定编程和测试需求。

在嵌入式开发领域，硬件的多样性和差异性要求CICD工具具备更高的灵活性和定制性，而Jenkins在这方面可能表现不足，特别是在处理硬件相关的自动化测试和部署方面。

2.学习成本高：

Jenkins的学习曲线相对陡峭，特别是对于那些不熟悉DevOps和持续集成概念的团队成员来说。它的界面和功能虽然强大，但对新用户来说可能显得复杂和不直观。

Jenkins的配置和使用需要具备一定的技术背景和经验，特别是在编写Pipeline脚本和设置复杂的工作流程方面。这可能导致在团队中需要专门的人员来维护和更新CICD流程。

3.配置复杂：

Jenkins的配置往往涉及多个步骤和细节，包括安装插件、配置任务、设置环境变量等。这些配置步骤不仅繁琐，而且容易出错，特别是在复杂的项目中。

Jenkins需要与多种工具和平台进行集成，例如源代码管理工具、构建工具和测试框架。每个工具的集成都可能需要特定的配置和调整，增加了整体的配置复杂度。

这些因素导致传统的CICD工具，如Jenkins，在嵌入式软件开发领域可能不是最理想的选择，特别是在考虑到嵌入式开发的特殊要求和复杂性时。

本发明所设计的嵌入式软件的自动化测试系统，可以很好解决的以上问题。

1.固件描述文件的设计和应用：

固件描述文件是一种配置文件，用于定义硬件板卡的功能和行为。本系统中，这些固件描述文件采用YAML这种易于理解和编辑的格式。

每个固件描述文件可以包含对应产品的最小可行产品(MVP)特性，以及针对不同外设驱动的排列组合。这种设计允许开发者通过配置文件来指定和修改产品的功能和行为，而无需改动代码本身。

2.一次提交实现多版本编译：

在本设计的系统中，软件开发者可以一次提交代码，系统则根据不同的固件描述文件自动编译出多个版本的产品软件。

这种方法的优点在于提高了开发效率，减少了重复工作。软件开发者不需要为每个产品版本单独编译和测试，而是通过配置文件来控制不同版本的生成。

3.自动化分级对比测试：

自动化分级对比测试是指系统能够自动运行测试用例，并将测试结果与预期结果或前一版本的结果进行对比，以便发现差异和潜在问题。

这种测试方法特别适用于持续集成环境，可以快速发现由最近的代码更改引入的错误。对于嵌入式软件开发来说，分级对比测试还可以帮助确认不同硬件配置下软件的表现是否一致。

本设计的系统设计方面的设计原则和特点，涵盖了多个关键组件和原则，从以下几个方面说明：

1.统一编程语言和脚本规范：

宿主机上运行的脚本统一使用Python编写。Python因其强大的库支持、易读性和灵活性，在自动化脚本编写中非常受欢迎。统一语言有助于维护一致的代码风格和降低理解难度。

硬件板卡上运行的脚本可以使用Shell或Python语言。这种灵活性允许根据具体的硬件环境和需求选择最合适的脚本语言。

2.配置文件和解析引擎：

所有配置文件统一采用YAML格式编写。YAML以其可读性和简洁性而著称，适合用于配置文件。

通过“YAML配置文件+YAML解析引擎+参数”的组合，可以轻松定义和修改硬件板卡的功能，无需直接修改源代码。这种设计提高了系统的灵活性和可维护性。

3.分层的系统架构：

系统分为“平台层、测试规划层、部署执行层”三个层次。每层负责不同的功能，如平台层完成板卡能力定义和固件编译，测试规划层负责测试计划解析和用例生成，部署执行层负责程序部署和测试调度执行等。这种分层架构有助于系统的模块化和清晰的职责划分。

4.CICD流水线平台的选择和配置：

系统采用GitLab+Docker+设备硬件板卡作为CICD自动测试流水线平台。GitLab提供代码管理和CI/CD自动化的能力，而Docker容器技术则用于部署GitLabRunner和其他必要的服务。

GitLabRunner在Linux系统中的Docker容器内运行，负责CI自动编译和CD自动部署产品程序到板卡，并执行测试用例以及收集和汇总测试数据和报告。

5.自主可控与快速迭代的优势：

使用开源的GitLab平台和Docker容器技术，使得整个系统的设计和搭建过程自主可控。这为系统的自定义和优化提供了极大的灵活性。

该系统设计特别适用于处理多样化硬件和快速迭代的需求，可以迅速适应不断变化的产品需求和技术环境。

1.测试用例描述文件的结构特点：

测试用例描述文件采用YAML格式编写，这种格式的优势在于其高度可读性和易于编辑的特点。YAML文件能够清晰地描述测试用例的结构和参数。

文件中可以定义多档运行参数，即不同级别的测试压力。这使得测试用例能够根据不同的测试需求灵活调整运行强度，例如，从基础功能测试到极限压力测试。

通过使用YAML的锚点(&)和合并键(<<)特性，可以实现测试用例及参数的临时修改和覆盖。这种方法提高了测试用例的复用性和灵活性，允许快速调整和定制测试参数，而无需重写整个测试用例。

2.生成测试计划的流程特点：

测试计划的生成过程自动整合了不同的测试用例和参数设置。这意味着测试计划可以根据预定义的逻辑和条件自动选择和组合相应的测试用例。

利用YAML文件中的锚点技术，可以实现测试用例的模块化和重用。测试计划可以通过引用不同的锚点来快速构建复杂的测试场景，而无需每次都编写全新的配置。

3.实际应用中的优势：

在实际的软件测试流程中，这种结构化和自动化的方法大大减少了手动编写和维护测试用例的工作量。它使得测试过程更加灵活和高效，特别是在需要快速适应变化的敏捷开发环境中。

这种方法特别适用于持续集成和持续部署(CI/CD)的环境，因为它允许测试计划快速适应代码的变更，确保软件的质量和性能始终符合最新的开发标准。

1.代码有效归档：

系统中采用FTP服务器来实现代码的有效归档，这是一种成熟且可靠的文件存储和传输方式。

在FTP服务器上，设立两个主要的仓库：产品版本仓库和固件发布仓库。产品版本仓库用于存放经过版本控制的源代码，保证代码的历史版本可以轻松追溯和访问。固件发布仓库则用于存放编译后的固件文件，方便在实际部署和测试中使用。

2.资料可控发布的分级管控：

分级管控机制确保不同级别的用户或部门可以根据权限访问相应的资料。例如，开发团队可以访问产品版本仓库以获取和修改源代码，而测试团队则主要访问固件发布仓库以进行测试。

“产品中心”作为一个管理节点，负责协调和控制资料的发布流程。这包括决定何时发布新的固件版本，以及控制对不同仓库的访问权限。这种分级管控机制有助于保持开发和测试流程的有序和高效。

3.系统架构中的集成：

在系统架构中，FTP服务器作为代码和固件的存储(备份)中心，与GitLab和Docker容器等其他组件紧密集成。这种集成确保了自动化流水线中的各个环节可以无缝协作，提高了整体的工作效率和可靠性。

这种集成还意味着当源代码在GitLab中更新时，相关的固件也可以自动编译并存放到固件发布仓库中，从而支持持续集成和持续部署的工作流。

综上所述，通过在系统中设置FTP服务器，并在其中设立产品版本仓库和固件发布仓库，结合分级管控的方法，系统为代码和资料的存储、发布及管理提供了一套有效和可靠的解决方案。这不仅确保了资料的安全性和可追溯性，也支持了高效的开发和测试流程。

以下是对“基于DevOps理念的实现，提高产品中心和工程中心之间有效协作”的拓展说明：

1.资料统一分类归档：

通过设立FTP服务器作为资料的中心仓库，所有的开发文档、固件、软件版本等都在此归档，确保所有资料按照一定的分类标准存储，便于管理和检索。

2.产品中心的定期发布固件：

产品中心负责定期将经过测试和验证的固件发布到FTP服务器的固件发布仓库中，确保工程中心和客户能够获取到最新的固件版本。

3.工程中心的产品功能迭代知晓：

工程中心通过GitLabCI/CD流程与FTP仓库的密切协作，可以实时监控到产品中心的功能迭代和固件更新，确保工程中心及时更新相关测试和开发环境。

4.工程中心的快速响应：

工程中心利用自动化的CI/CD流程，快速响应客户前期试用的反馈，及时调整开发和测试策略，以确保产品满足客户需求。

5.客户反馈和产品需求有效收集与评估实施：

产品中心和工程中心共同参与收集和评估客户的定制需求。通过FTP服务器中的资料归档和GitLab中的问题跟踪，两个中心可以协作处理客户反馈，共同决定产品的迭代方向。

6.DevOps理念的整体实施：

整个流程体现了DevOps的核心理念：快速迭代、自动化测试、持续集成和持续部署。通过GitLab的CI/CD集成和FTP服务器的仓库管理，产品中心和工程中心实现了高效的协作和沟通。

DevOps文化强调跨功能团队的协作，这种工作模式通过流程图中的紧密连接和反馈循环得到体现。每个部门不再孤立工作，而是在一个连贯的流程中共同推进产品的开发和发布。

通过上述流程和机制，本发明的系统不仅提高了产品中心和工程中心之间的协作效率，还加强了对客户需求的响应速度和产品质量的控制。这种基于DevOps理念的实现方式是现代软件和硬件开发环境中提高竞争力和市场适应性的关键。

本发明所设计的系统，基于分层解耦的设计理念，由“平台层、测试规划层、部署执行层”自上而下构成，系统框图如图1所示，描述如下：

设计原则

1、所有在host(宿主机)运行的脚本统一采用python语言编写；

2、系统采用gitlab作为cicd自动测试流水线平台，所有的配置文件统一采用yaml格式编写；

3、所有在target(硬件板卡)运行的脚本，可以采用shell或python脚本语言；

4、硬件板卡的程序开发者，只需要编写板卡功能描述文件(yaml格式)，不需要修改代码，通过“yaml配置文件+ymal解析引擎+参数”就可以实现绝大部分板卡的功能和软件性能测试功能(yaml解释器)。

5、平台层，完成板卡能力定义和固件编译功能；

6、测试规划层，完成测试计划解析和用例生成；

7、部署执行层，完成程序部署和测试调度执行等功能。

名词术语

1.hardware：某一款特定的硬件平台。

例子：hardware01,hardware02,hardware03。

2.platform：针对某一款硬件的不同固件实例(平台)，都是针对hardware01这款hardware的不同platform(板卡固件&驱动功能)；即不同平台(platform)运行不同的板卡固件和提供不同的外设驱动功能。

命名规则：<hardware>_xxx

例子：

hardware01_mini,意为：硬件板卡01号的最小系统；

hardware01_flash,意为：硬件板卡01号的带flash设备驱动的系统；

配置文件

1.firmware_xxx.yml，固件描述文件

解释：对应某一platform运行的软件二进制镜像,与平台应该是一对一的关系；用来生成对应platform的镜像文件。

命名规则：firmware_<platform>.yml

例子：firmware_hardware01_mini.yml

2.board_xxx.yml，板卡描述文件

解释：是hardware的实例，比如hardware01这款硬件，有2个相同的板卡，就是board_hardware01_id1,board_hardware01_id2。可以运行所有该hardware对应的所有firmware；用来描述特定板卡的实例,并通过系统自动生成指定运行特定的测试用例字典文件(测试计划test_plan)。

命名规则：board_<hardware>_idx

例子board_hardware01.yml

3.testsuite_xxx.yml,测试套描述文件

解析：测试套描述文件，描述测试套里面的所有测试用例，使用方法，firmware固件所需条件要求；

命名规则：testsuite_<testsuite>.yml

例子：testsuite_RT-Test.yml，意为：关于实时性测试代码集RT-Test的测试用例描述文件。

一种嵌入式软件的自动化测试系统，包括板卡能力定义和固件编译层、测试计划解析和用例生成层、程序部署和测试调度执行层；

所述板卡能力定义和固件编译层用于管理硬件板卡资源、管理源代码以及管理固件构建；

所述管理硬件板卡资源具体为支持yaml描述文件，描述target(硬件板卡)的名称，CPU架构，包含的外设等信息；

所述管理源代码具体为支持根据配置文件，自动拉取对应的gitlab仓库，支持生成gitlog文件，并打包到镜像中，实时查看该镜像的版本信息；

所述管理固件构建具体为基于yaml格式配置文件，自动生成target(硬件板卡)的firmware(程序固件)配置文件，实现针对同一target(硬件板卡)，生成多个版本firmware(程序固件)，如：最小系统，最小系统+存储，最小系统+网络；

所述测试计划解析和用例生成层用于根据板卡描述文件board_xxx.yml，描述特定板卡的外设列表，并通过系统自动生成特定的测试用例字典文件(测试计划test_plan)，根据测试用例字典文件(测试计划)，编译生成对应的测试用例代码；

所述程序部署和测试调度执行层用于根据板卡描述文件board_xxx.yml和测试用例字典文件(测试计划test_plan)，把测试计划对应到具体板卡，针对具体板卡执行固件程序和测试用例的部署和执行，系统具备调度和控制多板卡能力(调度器)，用于部署程序和执行测试用例，达到并发执行测试用例的功能。

系统执行流程，分为以下6个：

prepare，代码拉取准备；

build，板卡固件代码编译；

make_test_plan，生成测试计划；

mapping_firmware_and_board，映射程序固件和板卡；

running_test_and_report，部署固件和执行测试用例(部署执行层)。

1.prepare

1.1代码拉取准备。利用源代码管理工具，拉取所有仓库源代码，并且生成version.txt,记录所有仓库的commit信息。

1.2打包代码。打包一份完整的源代码到archived目录的src文件夹。

2.build

2.1生成firmware。扫描所有firmware描述文件，在build目录下创建firmware镜像输出路径，编译所有对应的firmware[例如：hardware01_mini文件夹，内含rootfs文件夹]。

2.2生成testsuite。扫描所有test描述文件，在build目录下创建testsuite镜像输出路径，编译所有对应的testsuite。

3.make_test_plan

3.1生成每个firmware的test_plan，默认全部平台运行所有testsuite,但是由于部分testsuite需要不同驱动支持，故每个firmware的test_plan不完全相同。

4.mapping_firmware_and_board

分配执行并行测试的任务，每个board只能对应一个firmware，即一个test_plan。

5.running_test_and_report

所有board根据mapping的test_plan进行测试，deploy到target，所有测试运行完成后，收集所有测试报告。

6.archive

归档所有源代码、编译生成文件，测试报告，程序固件版本信息；上传服务器，发生测试结果邮件。

【部署执行层】

在系统中，“部署测试层”或“部署执行层”在整个DevOps流程中扮演着至关重要的角色。以下是对其功能和重要性的描述和总结：

1.部署自动化：

部署执行层负责将成功通过集成和测试流程的代码自动部署到目标环境，这可能包括测试环境、预生产环境和生产环境。

这一层通过自动化工具(如GitLabRunner)和容器化技术(如Docker)来确保部署的一致性和可重复性。

2.测试调度和执行：

在代码部署后，部署测试层还负责调度和执行预定义的测试套件来验证新部署的代码。这可能包括单元测试、集成测试、系统测试和性能测试。

测试结果将决定代码是否准备好进行下一步操作，如进一步的测试、回退或推向生产。

3.环境配置和管理：

部署执行层也负责管理和配置运行测试所需的各种环境，包括软件配置、硬件配置、网络设置等。

这些环境配置确保了测试在一个与生产环境尽可能相似的环境中进行，以获得准确可靠的测试结果。

4.持续交付：

部署执行层是实现持续交付(CD)的关键环节，它允许团队快速且频繁地发布新版本的软件，这是DevOps实践的一个核心组成部分。

通过减少人为干预，这一层提高了部署速度，降低了部署过程中的错误和失败率。

5.反馈和监控：

部署测试层还通常包括对部署和运行状态的监控功能，以便快速响应任何问题。

它提供了持续反馈回环，确保了产品质量，并支持快速迭代。

在整个软件开发生命周期中，部署执行层作为将开发与运营连接起来的桥梁，其自动化和效率对于缩短发布周期、提高软件质量、加强运维协作具有决定性作用。

【yaml解释器】

在系统中，“yaml解释器”是一个核心组件，它将多个层次的配置文件转换为具体的测试计划和行动。以下是对它的作用和重要性的描述与总结：

1.集成配置文件：

Yaml解释器处理不同类型的YAML配置文件，包括固件描述(firmware_desc)、板卡描述(board_desc)以及测试套件描述(testsuite_desc)。

这些配置文件可能包含了各种测试参数、环境设置以及硬件特定的配置指令，这些对于自动化测试至关重要。

2.生成测试计划：

解释器将这些分散的配置文件整合为一个统一的测试计划。这可以包括不同板卡的测试，也可能包括在不同条件下的固件性能测试。

它可能还会根据不同测试计划(plan-1,plan-2,plan-3)生成具体的测试步骤和测试用例。

3.动态测试适配：

根据提供的硬件配置(例如，mini,mini-eth,mini-sd)，yaml解释器能够动态选择和适配相应的测试套件和测试计划。

这确保了测试计划的灵活性和定制性，允许针对不同的产品变种进行精确的测试。

4.转换为执行指令：

解释器不仅解析YAML文件，还将其转换为可以由测试环境执行的指令。这可能包括调用特定的测试框架、设置环境变量或者运行特定的测试脚本。

在执行层，根据解释器的输出，测试环境会执行相应的测试用例并收集结果。

5.自动化和效率提升：

Yaml解释器的使用大大提高了自动化测试的效率。通过预定义的配置文件，测试人员和开发人员不必手动编写复杂的测试指令。

它也简化了测试流程，因为测试人员可以通过更新YAML文件而不是更改测试框架本身的代码来调整测试计划。

综上所述，yaml解释器在系统中起着桥梁作用，它连接了配置管理和测试执行两个关键环节。通过它，系统可以自动地、高效地生成和适配测试计划，这对于实现持续集成和持续部署的目标至关重要。

【调度器】

在系统中，“调度器”是负责协调和管理测试执行流程的组件。它的功能和重要性可以从以下几个方面进行描述和总结：

1.测试流程协调：

调度器根据由yaml解释器生成的测试计划来协调测试流程。它确定何时以及如何启动每个测试用例，以及测试用例的运行顺序。

2.资源管理：

调度器负责管理测试过程中所需的资源，包括分配给测试用例的硬件和软件资源。它确保资源被有效利用，避免了冲突和瓶颈。

3.负载平衡：

在多个测试任务需要同时运行时，调度器负责平衡负载，以优化测试执行的效率和速度。

4.依赖关系处理：

如果某些测试用例有先后依赖关系，调度器会确保它们按照正确的顺序执行。

5.错误处理和重试逻辑：

当测试失败时，调度器可能会根据预设的规则进行错误处理，比如重新运行测试或将错误报告给开发团队。

6.测试结果聚合：

测试完成后，调度器通常负责聚合测试结果，并将结果传递给其他系统组件，如报告生成工具或仪表盘。

7.与其他组件的接口：

调度器与源代码管理系统、构建系统和报告系统等其他DevOps工具链组件有接口，以支持整个CICD流程的自动化和无缝集成。

综上，调度器在系统中是一个核心组件，它不仅确保了测试的有序进行，而且优化了资源的使用，提高了测试过程的自动化程度和效率。通过与yaml解释器和其他CICD组件的紧密协作，调度器支持快速迭代和持续改进，是实现DevOps目标的关键。

以上所述仅是本发明的优选实施方式，本发明的保护范围并不仅局限于上述实施例，凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理前提下的若干改进和润饰，这些改进和润饰也应视为本模板的保护范围。

以上对本发明的一个实施例进行了详细说明，但所述内容仅为本发明的较佳实施例，不能被认为用于限定本发明的实施范围。凡依本发明申请范围所作的均等变化与改进等，均应仍归属于本发明的专利涵盖范围之内。

Claims (2)

1.一种嵌入式软件的自动化测试系统，其特征在于，包括板卡能力定义和固件编译层、测试计划解析和用例生成层、程序部署和测试调度执行层；

所述板卡能力定义和固件编译层用于管理硬件板卡资源、管理源代码以及管理固件构建；

所述管理硬件板卡资源具体为支持yaml描述文件，描述硬件板卡的名称，CPU架构，包含的外设等信息；

所述管理源代码具体为支持根据配置文件，自动拉取对应的gitlab仓库，支持生成gitlog文件，并打包到镜像中，实时查看该镜像的版本信息；

所述管理固件构建具体为基于yaml格式配置文件，自动生成硬件板卡的程序固件配置文件；

所述测试计划解析和用例生成层用于根据板卡描述文件board_xxx.yml，描述特定板卡的外设列表，并通过系统自动生成特定的测试用例字典文件，根据测试用例字典文件，编译生成对应的测试用例代码；

所述程序部署和测试调度执行层用于根据板卡描述文件board_xxx.yml和测试用例字典文件，把测试用例字典文件对应到具体板卡，针对具体板卡执行固件程序和测试用例的部署和执行。

2.根据权利要求1所述的一种嵌入式软件的自动化测试系统，其特征在于，该系统的执行流程包括如下步骤：

prepare代码拉取准备：利用源代码管理工具，拉取所有仓库源代码，并且生成version.txt,记录所有仓库的commit信息，打包一份完整的源代码到archived目录的src文件夹；

板卡固件代码编译：扫描所有firmware描述文件，在build目录下创建firmware镜像输出路径，编译所有对应的firmware，扫描所有test描述文件，在build目录下创建testsuite镜像输出路径，编译所有对应的testsuite；

生成测试计划：生成每个firmware的test_plan，默认全部平台运行所有testsuite,由于部分testsuite需要不同驱动支持，故每个firmware的test_plan不完全相同；

映射程序固件和板卡：分配执行并行测试的任务，每个board只能对应一个firmware，即一个test_plan；

部署固件和执行测试用例：所有board根据mapping的test_plan进行测试，deploy到target，所有测试运行完成后，收集所有测试报告；

测试结果汇总，测试结果归档：归档所有源代码、编译生成文件，测试报告，程序固件版本信息，上传服务器，发生测试结果邮件。