Embedded software testing method and device, equipment and medium

Abstract

The invention discloses an embedded software testing method and device, equipment and a medium, and relates to the technical field of computers, the embedded software testing method and device are applied to a Jenkins server, a plurality of testing nodes are mounted on the Jenkins server, each testing node comprises a to-be-tested piece and auxiliary testing equipment, and the method comprises the steps that task parameters of a testing task are extracted, screening out at least one target test node based on the task parameters and hardware environment parameters of the plurality of test nodes; the test task is issued to a target test node, so that the target test node configures a software environment and pulls a test case, and a test script of the test case is loaded to the software environment based on a CANoe target interface so as to perform a test; and uploading a test result to a project management server. According to the invention, full-process automation of test preparation, test execution and test feedback is realized, and the test accuracy, consistency and integrity are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of computer testing, and in particular to an embedded software testing method, device, equipment and medium. Background Art

[0002] In the field of automotive embedded software testing, the current common vehicle testing method is to manually write test cases and test scripts, manually build hardware test environments, and configure test projects according to different test tasks and the differences in test samples for different test projects. This manual testing process will consume huge human resources as the software iteration cycle continues to shorten. At the same time, due to the lack of control over test scripts and environments, it is easy to affect test accuracy and consistency. In addition, compared with pure software testing such as static code, the biggest difference between system testing of embedded software is that system testing needs to be combined with hardware. The hardware interfaces and peripherals of different projects are different. Repeatedly building the test environment also requires a lot of manpower. Different test contents of the same project also require different test environments. Currently, most automated tests are aimed at pure software testing and do not consider the control of the test hardware environment.

[0003] Therefore, the above technical problems need to be solved by those skilled in the art urgently. Summary of the invention

[0004] In view of this, the purpose of the present invention is to provide an embedded software testing method, device, equipment and medium, which can realize the full process automation of test preparation, test execution and test feedback, and improve the accuracy, consistency and integrity of the test. The specific scheme is as follows:

[0005] In a first aspect, the present application discloses an embedded software testing method, which is applied to a Jenkins server, wherein a plurality of test nodes are mounted on the Jenkins server, wherein the test nodes include a device under test and an auxiliary test device, and the embedded software is run on the device under test. The method comprises:

[0006] Extracting a target task parameter of the test task according to a task sequence number of the test task, and selecting at least one target test node from the plurality of test nodes based on the target task parameter and hardware environment parameters of the plurality of test nodes;

[0007] The test task is sent to the target test node so that the target test node configures the software environment and pulls the test case, and then the test script of the test case is loaded into the software environment based on the target interface of CANoe, so as to test the embedded software on the DUT of the target test node; wherein the software environment is stored in the version control server, and the test case is stored in the project management server;

[0008] The generated test results are uploaded to the project management server.

[0009] Optionally, the Jenkins server includes a preset database, the preset database includes an environment parameter list for each test node created according to a preset field structure, the environment parameter list includes the hardware environment parameters of the test node, and the preset field structure is obtained based on the tag name of the test node, the number of network communication channels supported by the test node, and the test functions supported by the test node.

[0010] Optionally, the selecting at least one target test node from the plurality of test nodes based on the target task parameter and the hardware environment parameters of the plurality of test nodes includes:

[0011] Determine the required hardware environment conditions based on the target task parameters;

[0012] The corresponding environmental parameter list is determined from the preset database according to the required hardware environment conditions, and the test node corresponding to the environmental parameter list is determined as the target test node.

[0013] Optionally, the selecting at least one target test node from the plurality of test nodes based on the target task parameter and the hardware environment parameters of the plurality of test nodes includes:

[0014] The status of the plurality of test nodes mounted to the Jenkins server is displayed through the node list of the Jenkins server; wherein the status includes an online status and an offline status;

[0015] At least one target test node is selected from candidate test nodes based on the target task parameters and the hardware environment parameters of the plurality of test nodes; wherein the candidate test node is an online test node in the node list.

[0016] Optionally, after uploading the generated test results to the project management server, the process further includes:

[0017] An upload path is obtained from the test task, the generated test logs are integrated according to the target parameters of the test case, and the integrated test logs are uploaded to a designated area through the upload path.

[0018] Optionally, the embedded software testing method further includes:

[0019] If there are currently multiple test tasks, and the target test node corresponding to the multiple test tasks is the same node, the multiple test tasks are sorted based on the task scheduling mechanism of the Jenkins server, and the multiple test tasks are executed according to the sorting results.

[0020] Optionally, after selecting at least one target test node from the plurality of test nodes, the method further includes:

[0021] Based on the task scheduling mechanism of the Jenkins server, the idle state of at least one of the target test nodes is determined, and the current target test node is determined according to the idle state of at least one of the target test nodes. The software environment is configured through the current target test node, and the test case is pulled. Then, the test script of the test case is loaded into the software environment based on the target interface of CANoe.

[0022] In a second aspect, the present application discloses an embedded software testing device, which is applied to a Jenkins server, wherein a plurality of test nodes are mounted on the Jenkins server, wherein the test nodes include a device under test and an auxiliary test device, and the embedded software runs on the device under test, wherein the device comprises:

[0023] A test node screening module, used for extracting target task parameters of the test task according to the task sequence number of the test task, and screening out at least one target test node from the plurality of test nodes based on the target task parameters and the hardware environment parameters of the plurality of test nodes;

[0024] An embedded software testing module is used to send the test task to the target test node so that the target test node configures the software environment and pulls the test case, and then loads the test script of the test case into the software environment based on the target interface of CANoe, so as to test the embedded software on the DUT of the target test node; wherein the software environment is stored in a version control server, and the test case is stored in a project management server;

[0025] The test result uploading module is used to upload the generated test results to the project management server.

[0026] In a third aspect, the present application discloses an electronic device, comprising:

[0027] Memory, used to store computer programs;

[0028] The processor is used to execute the computer program to implement the above disclosed embedded software testing method.

[0029] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the embedded software testing method disclosed above is implemented.

[0030] It can be seen that the present application proposes an embedded software testing method, which is applied to a Jenkins server, wherein multiple test nodes are mounted on the Jenkins server, wherein the test nodes include a device to be tested and an auxiliary test device, and the embedded software is run on the device to be tested, and the method comprises: extracting the target task parameters of the test task according to the task sequence number of the test task, and filtering out at least one target test node from the multiple test nodes based on the target task parameters and the hardware environment parameters of the multiple test nodes; sending the test task to the target test node so that the target test node configures the software environment and pulls the test case, and then loading the test script of the test case into the software environment based on the target interface of CANoe, so as to test the embedded software on the device to be tested of the target test node; wherein the software environment is stored in a version control server, and the test case is stored in a project management server; and uploading the generated test results to the project management server. It can be seen from the above that the present application is based on the pipeline of the Jenkins server, combining the project management server, the version control server and the test node together to form a complete automation link, and at the same time, configuring different hardware environments to the Jenkins server in the form of nodes to use the Jenkins server to achieve the management of the hardware environment. Furthermore, target test nodes that meet the conditions are screened according to the target task parameters and the hardware environment parameters of each test node, and the software environment is configured and test cases are pulled based on the target test nodes. The generated test results are then uploaded to the project management server, thereby achieving full process automation of test preparation, test execution, and test feedback, improving test accuracy, consistency, and completeness, and greatly improving test efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0032] Figure 1 A flow chart of an embedded software testing method disclosed in this application;

[0033] Figure 2 A schematic diagram of an embedded test system disclosed in this application;

[0034] Figure 3 A flow chart of a specific embedded software testing method disclosed in this application;

[0035] Figure 4 This is a schematic diagram of the structure of an embedded software testing device disclosed in this application;

[0036] Figure 5 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0037] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0038] The current common vehicle testing method is to manually write test cases and test scripts, manually build the hardware test environment, and configure the test project according to different test tasks and the differences in test samples for different test projects. This manual testing process consumes huge human resources and easily affects the accuracy and consistency of the test. In addition, the system testing of embedded software needs to be combined with hardware. The hardware interfaces and peripherals of different projects are different. Repeatedly building the test environment also requires a lot of manpower. Most of the current automated testing is aimed at pure software testing, and the management and control of the test hardware environment is not considered.

[0039] To this end, an embodiment of the present application proposes an embedded software testing solution that can achieve full process automation of test preparation, test execution, and test feedback, thereby improving test accuracy, consistency, and completeness.

[0040] The present application embodiment discloses an embedded software testing method, see Figure 1 and Figure 2 As shown, it is applied to a Jenkins server, a plurality of test nodes are mounted on the Jenkins server, the test nodes include a device under test and an auxiliary test device, and the embedded software runs on the device under test. The method includes:

[0041] Step S11: extracting target task parameters of the test task according to the task sequence number of the test task, and selecting at least one target test node from the plurality of test nodes based on the target task parameters and the hardware environment parameters of the plurality of test nodes.

[0042] In this embodiment, fill in the test project, test scope, SVN (Subversion) address of the test project, number of retests, test log upload address, etc. in the project management server to obtain the task sequence number of the test task, and log in to the Jenkins website on any server end interconnected with the Jenkins server to determine the corresponding Jenkins project, fill in the task sequence number, obtain the corresponding test task, and obtain the target task parameters. Furthermore, at least one target test node is selected from the multiple test nodes based on the target task parameters and the hardware environment parameters of the multiple test nodes.

[0043] Specifically, this embodiment creates an environmental parameter list of the hardware environment parameters of each test node according to the preset field structure, saves the environmental parameter list of each test node to the preset database of the Jenkins server, and maintains it in the Jenkins server. The preset field structure includes the label name of the test node, the number of network communication channels supported by the test node, and the test functions supported by the test node. Further, the required hardware environment conditions are determined based on the target task parameters, and the corresponding environmental parameter list is determined from the preset database according to the required hardware environment conditions, and then the test node corresponding to the environmental parameter list is determined as the target test node. The environmental parameter list is shown in Table 1:

[0044] Table 1

[0045]

[0046] That is to say, this embodiment saves the environmental parameter list of each test node (that is, the slave node of the Jenkins server) to a preset database in advance. The parameters in the environmental parameter list are defined according to the preset field structure, such as the test node label, the number of CAN channels, the number of Ethernet channels, the number of oscilloscope channels, whether the hardware environment supports communication testing, whether the hardware environment supports diagnostic testing, and whether the hardware environment supports fault management testing. Furthermore, the required hardware environment conditions are determined based on the target task parameters, and the corresponding environmental parameter list is determined from the preset database according to the required hardware environment conditions, and then the test node corresponding to the environmental parameter list is determined as the target test node. For example, the required hardware environment conditions include requiring the hardware environment to support communication testing and the hardware environment to support fault management testing. In this case, the environmental parameter list that meets the conditions is determined from the preset database, and the corresponding test node is determined as the target test node.

[0047] In this embodiment, since some test nodes may be offline due to faults and cannot work normally, when screening test nodes based on a preset database, target test nodes are screened out from all online test nodes. In this way, it is necessary to display the status of the test nodes. Specifically, the status of the multiple test nodes mounted to the Jenkins server is displayed through the node list of the Jenkins server, and then at least one target test node is screened out from the online test nodes (alternative test nodes) in the node list based on the target task parameters and the hardware environment parameters of the multiple test nodes, wherein the status includes an online status and an offline status.

[0048] In summary, this embodiment takes the Jenkins server as the main node, and manages the hardware environment of the test node through the Jenkins server to achieve flexible online and offline and capacity expansion of the hardware environment. Specifically, this embodiment is classified according to the test type adapted by each slave test node, such as communication, diagnosis, network management, and test hardware such as smart cameras, all-in-one machines, domain controllers, and hardware configurations of test nodes, such as CAN signal analyzers, Ethernet signal analyzers, signal jammers, oscilloscopes, and signal generators carried, and the hardware environment parameters of all test nodes are stored in a preset database.

[0049] Step S12: Send the test task to the target test node so that the target test node configures the software environment and pulls the test case, and then loads the test script of the test case into the software environment based on the target interface of CANoe, so as to test the embedded software on the device under test of the target test node; wherein the software environment is stored in the version control server, and the test case is stored in the project management server.

[0050] In this embodiment, the test task is sent to the target test node for execution. The target test node pulls the software environment from the version control server and the test case from the project management server, and then loads the test script of the test case into the software environment based on the target interface of CANoe, so as to test the embedded software on the DUT of the target test node. Among them, the version control server includes the SVN server and the Git server, and the auxiliary test equipment includes the program-controlled power supply, relays and communication equipment.

[0051] That is, after the task is triggered, the target test node will pull the software environment from the version control server and the test case from the project management server according to the project configuration, and then use the target interface of CANoe to call the python script to load the test script of the test case into the software environment.

[0052] Furthermore, if there are currently multiple test tasks, and the target test nodes corresponding to the multiple test tasks are the same node, the multiple test tasks are sorted based on the task scheduling mechanism of the Jenkins server, and the multiple test tasks are executed according to the sorting results. For example, if there are currently 5 test tasks, and the target test nodes screened by the 5 test tasks are the same node, the 5 test tasks can be sorted according to factors such as task determination time, and when the first test task among the 5 test tasks is executed, the remaining 4 test tasks are waiting.

[0053] Further, the idle state of at least one target test node is determined based on the task scheduling mechanism of the Jenkins server, and the current target test node is determined according to the idle state of at least one target test node, and then the software environment is configured through the current target test node. For example, if three target test nodes are screened out, one of the three target test nodes may be busy and unable to execute the test task. Therefore, this embodiment needs to determine an idle target test node from the three target test nodes, and configure the software environment through the target test node and the version control system.

[0054] In addition, the present embodiment can also set the number of retests, and automatically select failed use cases for retesting according to the set number of retests, so as to reduce the test error rate.

[0055] Step S13: Upload the generated test results to the project management server.

[0056] In this embodiment, the generated test results are uploaded to the project management server, and the upload path is obtained from the test task. Then, the generated test logs are integrated according to the target parameters of the test case, and the integrated test logs are uploaded to the designated area through the upload path, wherein the designated area includes but is not limited to a public disk or Feishu cloud document, etc., and the target parameter can be the upper-level application name of the test case.

[0057] See also Figure 3As shown, the specific process is as follows: (1) prepare and trigger the test task; (2) select the appropriate target test node according to the hardware environment and issue the test task; (3) prepare the test environment and script; (4) execute the test script and output the test results; (5) upload the test results; (6) store the test log. It can be seen that this application automatically manages and executes the entire test process through the Jenkins pipeline to form a complete automation link. Through real-time data interaction with SVN, Git, and JIRA servers, the accuracy, consistency, and integrity of the test are ensured. The Jenkins master-slave node function is used to complete the management and control of the test hardware environment, avoiding repeated construction of test hardware. At the same time, the hardware platform feature storage and retrieval are completed, thereby realizing automatic matching and scheduling of the hardware environment. The test slave node can be offline or online in real time according to actual needs, realizing dynamic management of the slave node, facilitating the maintenance of the test bench and temporary scheduling for manual testing and other scenarios. All execution work is completed by the automated test system, freeing the test human resources from repetitive work and greatly improving the test efficiency.

[0058] It can be seen that the present application proposes an embedded software testing method, which is applied to a Jenkins server, wherein multiple test nodes are mounted on the Jenkins server, wherein the test nodes include a device to be tested and an auxiliary test device, and the embedded software is run on the device to be tested, and the method comprises: extracting the target task parameters of the test task according to the task sequence number of the test task, and filtering out at least one target test node from the multiple test nodes based on the target task parameters and the hardware environment parameters of the multiple test nodes; sending the test task to the target test node so that the target test node configures the software environment and pulls the test case, and then loading the test script of the test case into the software environment based on the target interface of CANoe, so as to test the embedded software on the device to be tested of the target test node; wherein the software environment is stored in a version control server, and the test case is stored in a project management server; and uploading the generated test results to the project management server. It can be seen from the above that the present application is based on the pipeline of the Jenkins server, combining the project management server, the version control server and the test node together to form a complete automation link, and at the same time, configuring different hardware environments to the Jenkins server in the form of nodes to use the Jenkins server to achieve the management of the hardware environment. Furthermore, target test nodes that meet the conditions are screened according to the target task parameters and the hardware environment parameters of each test node, and the software environment is configured and test cases are pulled based on the target test nodes. The generated test results are then uploaded to the project management server, thereby achieving full process automation of test preparation, test execution, and test feedback, improving test accuracy, consistency, and completeness, and greatly improving test efficiency.

[0059] Correspondingly, the present application also discloses an embedded software testing device, see Figure 4 As shown, the device comprises:

[0060] A test node screening module 11 is used to extract a target task parameter of the test task according to a task sequence number of the test task, and screen out at least one target test node from the plurality of test nodes based on the target task parameter and hardware environment parameters of the plurality of test nodes;

[0061] The embedded software testing module 12 is used to send the test task to the target test node so that the target test node configures the software environment and pulls the test case, and then loads the test script of the test case into the software environment based on the target interface of CANoe, so as to test the embedded software on the DUT of the target test node; wherein the software environment is stored in the version control server, and the test case is stored in the project management server;

[0062] The test result uploading module 13 is used to upload the generated test results to the project management server.

[0063] Among them, for more specific working processes of the above-mentioned modules, please refer to the corresponding contents disclosed in the aforementioned embodiments, which will not be repeated here.

[0064] It can be seen that the present application proposes an embedded software testing method, which is applied to a Jenkins server, wherein multiple test nodes are mounted on the Jenkins server, wherein the test nodes include a device to be tested and an auxiliary test device, and the embedded software is run on the device to be tested, and the method comprises: extracting the target task parameters of the test task according to the task sequence number of the test task, and filtering out at least one target test node from the multiple test nodes based on the target task parameters and the hardware environment parameters of the multiple test nodes; sending the test task to the target test node so that the target test node configures the software environment and pulls the test case, and then loading the test script of the test case into the software environment based on the target interface of CANoe, so as to test the embedded software on the device to be tested of the target test node; wherein the software environment is stored in a version control server, and the test case is stored in a project management server; and uploading the generated test results to the project management server. It can be seen from the above that the present application is based on the pipeline of the Jenkins server, combining the project management server, the version control server and the test node together to form a complete automation link, and at the same time, configuring different hardware environments to the Jenkins server in the form of nodes to use the Jenkins server to achieve the management of the hardware environment. Furthermore, target test nodes that meet the conditions are screened according to the target task parameters and the hardware environment parameters of each test node, and the software environment is configured and test cases are pulled based on the target test nodes. The generated test results are then uploaded to the project management server, thereby achieving full process automation of test preparation, test execution, and test feedback, improving test accuracy, consistency, and completeness, and greatly improving test efficiency.

[0065] Furthermore, an embodiment of the present application also provides an electronic device. Figure 5 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content in the diagram cannot be considered as any limitation on the scope of use of the present application.

[0066] Figure 5A schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a display screen 23, an input / output interface 24, a communication interface 25, a power supply 26, and a communication bus 27. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the embedded software testing method disclosed in any of the aforementioned embodiments. In addition, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0067] In this embodiment, the power supply 26 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 25 can create a data transmission channel between the electronic device 20 and the external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present application, and is not specifically limited here; the input and output interface 24 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0068] In addition, the memory 22, as a carrier for storing resources, may be a read-only memory, a random access memory, a disk or an optical disk, etc., and the resources stored thereon may include a computer program 221, and the storage method may be temporary storage or permanent storage. In addition to including a computer program that can be used to complete the embedded software testing method performed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 221 may further include a computer program that can be used to complete other specific tasks.

[0069] Furthermore, an embodiment of the present application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the embedded software testing method disclosed above is implemented.

[0070] For the specific steps of the method, reference may be made to the corresponding contents disclosed in the aforementioned embodiments, which will not be described in detail here.

[0071] The various embodiments in this application are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0072] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0073] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0074] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0075] The above is a detailed introduction to an embedded software testing method, device, equipment, and storage medium provided by the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. An embedded software testing method, characterized in that: Applied to a Jenkins server, a plurality of test nodes are mounted on the Jenkins server, the test nodes include a device under test and auxiliary test equipment, and the embedded software runs on the device under test. The method includes: Extracting a target task parameter of the test task according to a task sequence number of the test task, and selecting at least one target test node from the plurality of test nodes based on the target task parameter and hardware environment parameters of the plurality of test nodes; The test task is sent to the target test node so that the target test node configures the software environment and pulls the test case, and then the test script of the test case is loaded into the software environment based on the target interface of CANoe, so as to test the embedded software on the DUT of the target test node; wherein the software environment is stored in the version control server, and the test case is stored in the project management server; The generated test results are uploaded to the project management server.

2. The embedded software testing method according to claim 1, characterized in that: The Jenkins server includes a preset database, which includes an environment parameter list of each test node created according to a preset field structure, the environment parameter list includes the hardware environment parameters of the test node, and the preset field structure is obtained based on the label name of the test node, the number of network communication channels supported by the test node, and the test functions supported by the test node.

3. The embedded software testing method according to claim 2, characterized in that: The step of selecting at least one target test node from the plurality of test nodes based on the target task parameter and the hardware environment parameters of the plurality of test nodes includes: Determine the required hardware environment conditions based on the target task parameters; The corresponding environmental parameter list is determined from the preset database according to the required hardware environment conditions, and the test node corresponding to the environmental parameter list is determined as the target test node.

4. The embedded software testing method according to claim 1, characterized in that: The step of selecting at least one target test node from the plurality of test nodes based on the target task parameter and the hardware environment parameters of the plurality of test nodes includes: The status of the plurality of test nodes mounted to the Jenkins server is displayed through the node list of the Jenkins server; wherein the status includes an online status and an offline status; At least one target test node is selected from candidate test nodes based on the target task parameters and the hardware environment parameters of the plurality of test nodes; wherein the candidate test node is an online test node in the node list.

5. The embedded software testing method according to claim 1, characterized in that: After uploading the generated test results to the project management server, the method further includes: An upload path is obtained from the test task, the generated test logs are integrated according to the target parameters of the test case, and the integrated test logs are uploaded to a designated area through the upload path.

6. The embedded software testing method according to claim 1, characterized in that: Also includes: If there are currently multiple test tasks, and the target test node corresponding to the multiple test tasks is the same node, the multiple test tasks are sorted based on the task scheduling mechanism of the Jenkins server, and the multiple test tasks are executed according to the sorting results.

7. The embedded software testing method according to any one of claims 1 to 6, characterized in that: After selecting at least one target test node from the plurality of test nodes, the method further includes: Based on the task scheduling mechanism of the Jenkins server, the idle state of at least one of the target test nodes is determined, and the current target test node is determined according to the idle state of at least one of the target test nodes. The software environment is configured through the current target test node, and the test case is pulled. Then, the test script of the test case is loaded into the software environment based on the target interface of CANoe.

8. An embedded software testing device, characterized in that: Applied to a Jenkins server, a plurality of test nodes are mounted on the Jenkins server, the test nodes include a device under test and auxiliary test equipment, and the device runs embedded software. The device includes: A test node screening module, used for extracting target task parameters of the test task according to the task sequence number of the test task, and screening out at least one target test node from the plurality of test nodes based on the target task parameters and the hardware environment parameters of the plurality of test nodes; An embedded software testing module is used to send the test task to the target test node so that the target test node configures the software environment and pulls the test case, and then loads the test script of the test case into the software environment based on the target interface of CANoe, so as to test the embedded software on the DUT of the target test node; wherein the software environment is stored in a version control server, and the test case is stored in a project management server; The test result uploading module is used to upload the generated test results to the project management server.

9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the embedded software testing method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: Used to store a computer program; wherein, when the computer program is executed by a processor, the embedded software testing method according to any one of claims 1 to 7 is implemented.

Images