Testing method, device, electronic device and storage medium for unit to be tested

Abstract

The present application relates to the field of testing technology, and in particular to a testing method, device, electronic device, and storage medium for a unit to be tested, wherein the method comprises: obtaining source code to be compiled, compiling the source code to be compiled to obtain an .elf file and a .hex file, and writing the .elf file and the .hex file into a vehicle integrated unit (VIU); parsing and processing the .elf file in steps to create a test case set, and storing the test case set into a preset embedded unit testing framework; deploying the unit to be tested in the preset embedded unit testing framework to a target server based on a preset Jenkins automated deployment environment, and after the deployment is completed, testing the unit to be tested through the VIU to generate a unit test report and a code coverage result report for the unit to be tested. Thus, the limitations of the existing technology are overcome, the problems of high learning and use costs and difficulty in popularization of related technologies are solved, and the efficiency of unit testing is greatly improved.

Description

Technical Field

[0001] The present application relates to the field of testing technology, and in particular to a testing method, device, electronic device, and storage medium for a unit to be tested. Background Art

[0002] Unit testing involves checking and verifying the smallest testable unit in software. It is the most important activity for verifying code correctness and the most crucial step in system testing. It is particularly critical for embedded systems, which require high security and reliability. C / C++ remains the mainstream programming language for embedded software development. Unit testing is also the only testing method that requires code to be written. In the standard development process, unit test code is treated with the same importance as the actual program code.

[0003] The accelerating pace of embedded software and hardware upgrades places higher demands on embedded software quality and system stability. Since there's no universal testing framework for embedded software testing, it's impossible to write reusable, universal test cases, resulting in low test coverage. Therefore, it's crucial to choose a testing framework that's compatible, scalable, portable, and easy to use. Tessy, a tool commonly used in the automotive industry, automates test environment setup, test execution, result evaluation, and report generation. However, it lacks scalability, and the inefficient manual testing approach, supplemented by device testing, is also paid software.

[0004] A unit testing method for embedded systems is proposed in the related art. Test cases are automatically generated based on the software Unity, and stub functions in the use case source code are generated using Ruby tools. The target test cases are executed based on the compiled files and in a test environment built using Parasoft tools.

[0005] However, both Unity and Parasoft tools are paid software. Unity is only suitable for pure C language projects and is not compatible with C++ language projects. In addition, the Ruby language is relatively complex, difficult to operate, and has high learning and usage costs, making it difficult to promote and use. Summary of the Invention

[0006] The present application provides a testing method, device, electronic device and storage medium for a unit to be tested, which overcomes the limitations of the existing technology, solves the problems of high learning and use costs and difficulty in promoting related technologies, and greatly improves the efficiency of unit testing.

[0007] The first embodiment of the present application provides a method for testing a unit to be tested, comprising the following steps: obtaining a source code to be compiled, compiling the source code to be compiled to obtain an .elf file and a .hex file, and writing the .elf file and the .hex file into a vehicle identification unit (VMU).

[0008] VIU); parsing and processing the .elf file step by step to create a test case set, and storing the test case set in a preset embedded unit test framework; based on a preset Jenkins automated deployment environment, deploying the unit to be tested in the preset embedded unit test framework to a target server, and after the deployment is completed, testing the unit to be tested through the VIU, and generating a unit test report and a code coverage result report for the unit to be tested.

[0009] Optionally, in some embodiments, the above-mentioned testing method for the unit to be tested further includes: converting the unit test report into an HTML unit test report, the HTML unit test report including the total number of test cases, the total number of test case execution failures, and the execution results and execution failure reasons corresponding to the test cases displayed in a list form.

[0010] Optionally, in some embodiments, it is characterized in that it also includes: obtaining code coverage and branch coverage from the code coverage result report, and extracting failed test cases from the html unit test report; evaluating the unit to be tested based on the code coverage, the branch coverage and the failed test cases.

[0011] Optionally, in some embodiments, before storing the test case set into the preset embedded unit testing framework, it also includes: based on the preset Vscode integrated development environment, using the Googletest unit testing framework, combining CMake to compile the code and build the program to generate an executable .exe file; building the preset embedded unit testing framework according to the executable .exe file.

[0012] Optionally, in some embodiments, the step-by-step parsing and processing of the .elf file to create a test case set includes: converting the .elf file into a txt file; storing the data type and data structure information in the .txt file into a preset database; processing the data type stored in the preset database based on a preset first script program, and automatically creating the test case set based on the processed data type and data structure information based on a preset second script program.

[0013] The second aspect of the present application provides a testing device for a unit to be tested, including: an acquisition module for acquiring source code to be compiled, compiling the source code to be compiled to obtain an .elf file and a .hex file, and writing the .elf file and the .hex file into a vehicle integrated unit VIU processing module for parsing and processing the .elf file step by step to create a test case set, and storing the test case set into a preset embedded unit testing framework; and a generation module for deploying the unit to be tested in the preset embedded unit testing framework to a target server based on a preset Jenkins automated deployment environment, and after the deployment is completed, testing the unit to be tested through the VIU to generate a unit test report and a code coverage result report for the unit to be tested.

[0014] Optionally, the above-mentioned testing device for the unit to be tested is also used to: convert the unit test report into an HTML unit test report, the HTML unit test report including the total number of test cases, the total number of test case execution failures, and the execution results and execution failure reasons corresponding to the test cases displayed in a list form.

[0015] Optionally, in some embodiments, the above-mentioned testing device for the unit to be tested is also used to: obtain code coverage and branch coverage from the code coverage result report, and extract failed test cases from the html unit test report; evaluate the unit to be tested based on the code coverage, the branch coverage and the failed test cases.

[0016] Optionally, in some embodiments, before storing the test case set into the preset embedded unit testing framework, the processing module is also used to: based on the preset Vscode integrated development environment, use the Googletest unit testing framework, combine CMake to compile the code and build the program to generate an executable .exe file; and build the preset embedded unit testing framework based on the executable .exe file.

[0017] Optionally, in some embodiments, the processing module is further used to: convert the .elf file into a txt file; store the data type and data structure information in the .txt file into a preset database; process the data type stored in the preset database based on a preset first script program, and automatically create the test case set based on the processed data type and data structure information based on a preset second script program.

[0018] The third aspect of the present application provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the test method of the unit to be tested as described in the above embodiment.

[0019] A fourth aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the test method of the unit to be tested as described in the above embodiment.

[0020] Thus, by obtaining the source code to be compiled, compiling it to obtain .elf and .hex files, writing the .elf and .hex files to the vehicle integrated unit (VIU), and step-by-step parsing and processing the .elf files to create a test case set, the test case set is stored in a preset embedded unit testing framework, and based on a preset Jenkins automated deployment environment, the units to be tested in the preset embedded unit testing framework are deployed to the target server. After deployment is complete, the units to be tested are tested through the VIU, generating a unit test report and a code coverage result report for the units to be tested. This overcomes the limitations of existing technologies, solves the problems of high learning and use costs and difficulty in promoting related technologies, and greatly improves the efficiency of unit testing.

[0021] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0023] Figure 1 A flowchart of a method for testing a unit to be tested according to an embodiment of the present application;

[0024] Figure 2 A flowchart of a method for testing a unit to be tested according to a specific embodiment of the present application;

[0025] Figure 3 A flowchart of a compilation provided according to a specific embodiment of the present application;

[0026] Figure 4 A schematic diagram of a unit test framework provided according to a specific embodiment of the present application;

[0027] Figure 5 A flowchart of automatically generating a test case set according to a specific embodiment of the present application;

[0028] Figure 6 A code coverage statistics flow chart provided according to a specific embodiment of the present application;

[0029] Figure 7 A CI / CD (Continuous Integration / Continuous Delivery) Jenkins deployment flow chart provided according to a specific embodiment of the present application;

[0030] Figure 8 A defect flow chart for automatic triggering generation provided according to a specific embodiment of the present application;

[0031] Figure 9 Schematic diagram of a block diagram of a testing device for a unit to be tested according to an embodiment of the present application;

[0032] Figure 10 A schematic diagram of an electronic device provided according to an embodiment of the present application.

[0033] Explanation of reference numerals: 10 - testing device of unit to be tested, 100 - acquisition module, 200 - processing module and 300 - generation module. DETAILED DESCRIPTION

[0034] The following describes in detail embodiments of the present application, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0035] The following describes the test method, device, electronic device and storage medium of the unit to be tested of the embodiment of the present application with reference to the accompanying drawings. In response to the problem that the related technologies mentioned in the above background technology are expensive to learn and use and difficult to promote, the present application provides a test method for the unit to be tested, in which the source code to be compiled is obtained, the source code to be compiled is compiled to obtain a .elf file and a .hex file, and the .elf file and the .hex file are written to the vehicle integrated unit (VIU), and the .elf file is parsed and processed step by step to create a test case set, and the test case set is stored in a preset embedded unit test framework, and based on a preset Jenkins automated deployment environment, the unit to be tested in the preset embedded unit test framework is deployed to the target server, and after the deployment is completed, the unit to be tested is tested through the VIU, and a unit test report and a code coverage result report of the unit to be tested are generated. Thus, the limitations of the prior art are overcome, the problems that the related technologies are expensive to learn and use and difficult to promote are solved, and the efficiency of unit testing is greatly improved.

[0036] Specifically, Figure 1 A flowchart of a method for testing a unit to be tested provided in an embodiment of the present application.

[0037] like Figure 1 As shown, the testing method of the unit to be tested includes the following steps:

[0038] In step S101 , a source code to be compiled is obtained, the source code to be compiled is compiled to obtain an .elf file and a .hex file, and the .elf file and the .hex file are written into the vehicle integrated unit VIU.

[0039] Specifically, the present embodiment can use Hightech to compile source code. The source code follows the Autosar architecture and is compiled with multi-core support. The linker can link target files of different core architectures and generate a single output file. The final compilation outputs .elf and .hex files. The compiled program code is then flashed into the VIU chip using Lauterbach TRACE32.

[0040] In step S102, the .elf file is parsed and processed step by step to create a test case set, and the test case set is stored in a preset embedded unit test framework.

[0041] Optionally, in some embodiments, the test case set is created by parsing and processing the .elf file step by step, including: converting the .elf file into a txt file; storing the data type and data structure information in the .txt file into a preset database; processing the data type stored in the preset database based on a preset first script program, and automatically creating a test case set based on the processed data type and data structure information based on a preset second script program.

[0042] Among them, the preset embedded unit testing framework can use the Vscode integrated development environment, adopt the Googletest unit testing framework, and combine CMake to compile the code and build the program.

[0043] Specifically, the embodiment of the present application can use IAR software to convert the .elf file into a txt file, use the Python scripting language to parse and process the .elf file step by step and store it in the database, and then use the Python script to realize the automatic generation of print output use cases and test cases.

[0044] Optionally, in some embodiments, before storing the test case set into the preset embedded unit testing framework, it also includes: based on the preset Vscode integrated development environment, using the Googletest unit testing framework, combining CMake to compile the code and build the program to generate an executable .exe file; building the preset embedded unit testing framework according to the executable .exe file.

[0045] Specifically, the implementation of the Googletest unit testing framework needs to start from the following aspects:

[0046] (1) First, the program under test and the test cases need to be isolated in the project structure, that is, the program under test and the test cases need to be placed in different folders;

[0047] (2) Use TEST() / TEST_F() macros to declare test functions;

[0048] (3) The program execution results can be checked through ASSERT_* and EXPECT_* assertions;

[0049] (4) Create global events, TestSuite events, and TestCase events to facilitate operations before and after the test case;

[0050] (5) In the main() function, first call InitGoogleTest() to perform some initialization operations, then run all test cases through RUN_ALL_TESTS(), and output the execution results to an XML file.

[0051] CMakelists.txt file is written, and the common commands are as follows:

[0052] #The project name of this CMakeLists.txt

[0053] #Two variables will be automatically created, PROJECT_SOURCE_DIR and PROJECT_NAME

[0054] #${PROJECT_SOURCE_DIR}: The folder path where this CMakeLists.txt is located

[0055] #${PROJECT_NAME}: the project name of this CMakeLists.txt

[0056] project(xxx)

[0057] #Get all .cpp / .c / .cc files in the path and assign them to variables

[0058] aux_source_directory (path variable)

[0059] #Give the file name / path name or other string an alias, and use ${variable} to get the variable content

[0060] set(variable file name / path / ...)

[0061] #Add compilation options

[0062] add_definitions (compile option)

[0063] #Print message

[0064] message

[0065] #Compile the CMakeLists.txt of the subfolder

[0066] add_subdirectory(subfolder name)

[0067] #Generate .a static library from .cpp / .c / .cc files

[0068] #Note that the library file name is usually libxxx.so, just write xxx here

[0069] add_library(library file name STATIC file)

[0070] #Generate an executable file from the .cpp / .c / .cc file

[0071] add_executable(executable file name file

[0072] #Specify the .h header file path

[0073] include_directories(path

[0074] #Specify the .so / .a library file path

[0075] link_directories(path)

[0076] #Link the files generated by add_library or add_executable

[0077] #Note that the library file name is usually libxxx.so, just write xxx here

[0078] target_link_libraries (library file name / executable file name linked library file name)

[0079] In step S103, based on the preset Jenkins automated deployment environment, the unit to be tested in the preset embedded unit testing framework is deployed to the target server, and after the deployment is completed, the unit to be tested is tested through VIU to generate a unit test report and code coverage result report for the unit to be tested.

[0080] Specifically, in the embodiment of the present application, a Jenkins automated deployment environment can be built based on the CI / CD process, and the gtest unit test program can be deployed to the CI / CD server. The unit test execution can be automatically triggered when developing Push and Merge code, and the execution results are notified by email, and the unit test report is sent to project-related personnel. At the same time, the code coverage statistics plug-in is integrated into SonarQube, so that the code coverage information can be counted each time the unit test is executed.

[0081] Optionally, in some embodiments, the above-mentioned testing method for the unit to be tested further includes: converting the unit test report into an HTML unit test report, the HTML unit test report including the total number of test cases, the total number of test case execution failures, and the execution results and execution failure reasons corresponding to the test cases displayed in a list form.

[0082] Specifically, in the embodiment of the present application, the gtest2html plug-in can be used to convert the XML test report into an HTML report. The HTML report can clearly display the total number of test cases and the total number of failed execution cases, and display the execution results and execution failure reasons corresponding to the test cases in the test set in a list form.

[0083] Optionally, in some embodiments, the above-mentioned testing method for the unit to be tested further includes: obtaining code coverage and branch coverage from the code coverage result report, and extracting failed test cases from the html unit test report; evaluating the unit to be tested based on the code coverage, branch coverage and failed test cases.

[0084] Specifically, in order to facilitate relevant personnel to intuitively understand the test results and facilitate further processing of the defect management system based on the test results, the embodiment of the present application can evaluate the unit to be tested based on code coverage, branch coverage and test cases with test failures.

[0085] In order to enable those skilled in the art to further understand the testing method of the unit to be tested in the embodiment of the present application, it is described in detail below with reference to specific embodiments.

[0086] like Figure 2 As shown, Figure 2 The flowchart of the testing method of the unit to be tested proposed according to the embodiment of the present application is shown.

[0087] In the embodiment of the present application, the core process involves Hightech compiling the source code to generate an .elf executable file, which is then processed and parsed by Python and stored in a database. The test case set is then triggered by a Python script program, and the test case set is then incorporated into the test framework built by gtest. An automated deployment environment is built through Jenkins, and finally the burned VIU chip is connected via Ethernet and the VIU software is unit tested, ultimately obtaining a unit test report and a code coverage result report.

[0088] 1. Hightech compiles the source code and burns it;

[0089] like Figure 3 As shown, Figure 3 This is a flow chart for source code compilation, which uses Hightech software. The overall process involves creating a .bat batch file and executing it to pull and build the source code. If compilation errors occur, the compiler will return to troubleshoot the warnings until the compilation passes. This ultimately generates an executable binary .elf file and an executable hexadecimal .hex file. The compiled code is then flashed into the VIU chip using Lauterbach TRACE32, completing the VIU programming process.

[0090] 2. Build the basic framework for unit testing of embedded projects;

[0091] like Figure 4 As shown, Figure 4 This is a unit test framework diagram. It uses the Vscode integrated development environment, the Googletest unit test framework, and CMake to compile and build the program, generating an executable .exe file. The exe file generates an XML report, which is then converted to an HTML visual report using the gtest2html plugin.

[0092] The following is an example of building a project directory:

[0093] 1. src: stores the source file to be tested

[0094] 2. test: store main functions and test cases

[0095] 3. Build: compile and generate, place executable files

[0096] 4. gtest-1.7.0: gtest tool folder

[0097] 5. gtest2html: XML report to HTML report plug-in

[0098] An example of writing a Cmakelists.txt file is as follows:

[0099] The following is an example of the file content:

[0100] project(DEMO)

[0101] cmake_minimum_required(VERSION 3.10)

[0102] #gtest library

[0103] add_subdirectory(gtest-1.7.0)

[0104] include_directories(${CMAKE_SOURCE_DIR} / gtest-1.7.0 / googletest / include)

[0105] include_directories(${CMAKE_SOURCE_DIR} / gtest-1.7.0 / googlemock / include)

[0106] include_directories(${CMAKE_SOURCE_DIR} / gtest-1.7.0 / include)

[0107] #C,C++ mixed: compile C code into C++

[0108] set(CMAKE_CXX_FLAGS"${CMAKE_CXX_FLAGS}-DEX2-pthread-std=c++17"CACHESTRING"Set C++Compiler Flags"FORCE)

[0109] include_directories(src test)

[0110] aux_source_directory(. / src src)

[0111] aux_source_directory(. / test test)

[0112] add_executable(unit_test${src}${test})

[0113] target_link_libraries(unit_test gtest pthread)

[0114] 3. Design test cases and automatically generate test case sets;

[0115] like Figure 5 As shown, Figure 5 It automatically generates a test case set flow chart. The main process includes: using Python scripting language to parse and process the .elf file step by step and store it in the database, and then using Python scripts to print out test cases and automatically generate test cases.

[0116] like Figure 5 As shown, test case design is carried out to realize automatic generation of test case sets. The main process includes: using Python scripting language to parse and process the .elf file step by step and store it in the database, and then using Python scripts to print out test cases and automatically generate test cases.

[0117] In the actual implementation process, the implementation steps are as follows:

[0118] Step 1: Use IAR software to convert .elf into txt file;

[0119] Step 2: Python script 1 stores the data type and data structure information in the .txt file into the database;

[0120] Step 3: Python script 2 implements the processing of general data types;

[0121] Step 4: Python script 3 implements the processing of special data types;

[0122] Step 5: Python script program 4 automatically creates a test case set based on the data type and data structure stored in the DB.

[0123] 4. Conduct code coverage testing;

[0124] like Figure 6 As shown, Figure 6 It is a code coverage statistics flow chart. It uses gcov to count the line coverage, function coverage, branch coverage and other information of the code, and uses lcov to show the coverage more intuitively.

[0125] gcov is a C / C++ code coverage analysis tool that comes with GCC under Linux. If gcc is already installed in the development environment, gcov is not needed. gcov can generate code coverage information, and lcov is needed to intuitively display coverage. The main features of lcov are:

[0126] 1. Based on Html output, generate a complete HTML tree;

[0127] 2. Output includes overview, coverage percentage, and charts, allowing for quick browsing of coverage data;

[0128] 3. Support large projects and provide three levels of views: directory view, file view, and source code view.

[0129] To implement coverage statistics, the previous Cmakelists.txt file needs to be added or modified as follows:

[0130] add_definitions(-fprofile-arcs-ftest-coverage)

[0131] target_link_libraries(ca_test gtest pthread protobuf glog gcov)

[0132] To facilitate coverage statistics, create an automated execution shell script. The steps are as follows:

[0133] 1. Use the lcov command to generate probability statistics file

[0134] lcov-d. / -t ca_test-o. / ca.info-b. / -c--rc lcov_branch_coverage=1

[0135] Note: Branch coverage is disabled by default. Enable it with "--rc lcov_branch_coverage=1"

[0136] 2. Use the lcov--remove command to remove the specified directory

[0137] lcov --remove ca.info'* / include / *' -o result.info

[0138] illustrate:

[0139] (a) This command generates coverage information and blocks coverage information in the '* / include / *' directory.

[0140] (b) ca.info: overall coverage information;

[0141] (c) result.info: filtered coverage information

[0142] 3. Use the genhtml command to generate coverage reports

[0143] genhtml--rc genhtml_branch_coverage=1-o result result.info

[0144] Note: Branch coverage is off by default, turn it on with the command "--rc genhtml_branch_coverage=1".

[0145] Automatically execute unit test cases.

[0146] like Figure 7 As shown, Figure 7 This is a CI / CD Jenkins deployment flow chart. The main process is to compile / package local code through Jenkins through the version control server and automatically trigger deployment to the application server. The specific implementation details include the following:

[0147] (1) Build a Jenkins automated deployment environment based on the CI / CD process and deploy the gtest unit test program to the CI / CD server;

[0148] (2) Automatically trigger unit test execution when developing Push and Merge code;

[0149] (3) The unit test execution results are notified via email, and the unit test report is sent to project related personnel;

[0150] (4)SonarQube integrates a code coverage statistics plug-in to enable code coverage information statistics every time a unit test is executed.

[0151] 6. Generate HTML unit test report;

[0152] Use the gtest2html plugin to convert XML test reports into HTML reports. The HTML report clearly displays the total number of test cases and the number of failed test cases. It also lists the execution results and failure reasons for each test case in the test set.

[0153] 7. Test and evaluate the unit under test;

[0154] Unit testing is evaluated based on unit test reports and code coverage results. First, code coverage and branch coverage must meet project specifications. Second, failed test cases in unit test reports need to be analyzed, defects submitted, and their closure tracked.

[0155] 8. Automatically submit, manage and track defects;

[0156] like Figure 8 As shown, Figure 8 It automatically triggers the generation of defect flow charts. Once CI / CD is integrated with the defect management system, it can automatically trigger the creation and tracking of defects based on failed test cases in unit test execution reports, and send email notifications to module owners, thus automating the entire test pipeline.

[0157] According to the testing method of the unit to be tested proposed in the embodiment of the present application, by obtaining the source code to be compiled, compiling the source code to be compiled to obtain an .elf file and a .hex file, and writing the .elf file and the .hex file into the vehicle integrated unit (VIU), parsing and processing the .elf file step by step to create a test case set, and storing the test case set in a preset embedded unit test framework. Based on the preset Jenkins automated deployment environment, the unit to be tested in the preset embedded unit test framework is deployed to the target server. After the deployment is completed, the unit to be tested is tested through the VIU to generate a unit test report and a code coverage result report for the unit to be tested. In this way, the limitations of the existing technology are overcome, the problems of high learning and use costs and difficulty in popularization of related technologies are solved, and the efficiency of unit testing is greatly improved.

[0158] Next, a test device for a unit to be tested according to an embodiment of the present application will be described with reference to the accompanying drawings.

[0159] Figure 9 Schematic diagram of a test device for a unit to be tested according to an embodiment of the present application.

[0160] like Figure 9 As shown, the testing device 10 for the unit to be tested includes: an acquisition module 100 , a processing module 200 and a generation module 300 .

[0161] Among them, the acquisition module 100 is used to obtain the source code to be compiled, compile the source code to be compiled to obtain an .elf file and a .hex file, and write the .elf file and the .hex file into the vehicle integrated unit VIU; the processing module 200 is used to parse and process the .elf file step by step to create a test case set, and store the test case set into a preset embedded unit test framework; and the generation module 300 is used to deploy the unit to be tested in the preset embedded unit test framework to the target server based on the preset Jenkins automated deployment environment, and after the deployment is completed, test the unit to be tested through the VIU to generate a unit test report and a code coverage result report for the unit to be tested.

[0162] Optionally, the above-mentioned testing device 10 for the unit to be tested is also used to: convert the unit test report into an HTML unit test report, the HTML unit test report includes the total number of test cases, the total number of test case execution failures, and the execution results and execution failure reasons corresponding to the test cases displayed in a list form.

[0163] Optionally, in some embodiments, the above-mentioned testing device 10 for the unit to be tested is also used to: obtain code coverage and branch coverage from the code coverage result report, and extract failed test cases from the html unit test report; evaluate the unit to be tested based on the code coverage, branch coverage and failed test cases.

[0164] Optionally, in some embodiments, before storing the test case set into the preset embedded unit testing framework, the processing module 200 is also used to: based on the preset Vscode integrated development environment, use the Googletest unit testing framework, combine CMake to compile the code and build the program to generate an executable .exe file; and build the preset embedded unit testing framework based on the executable .exe file.

[0165] Optionally, in some embodiments, the processing module 200 is specifically used to: convert the .elf file into a txt file; store the data type and data structure information in the .txt file into a preset database; process the data type stored in the preset database based on a preset first script program, and automatically create a test case set based on the processed data type and data structure information based on a preset second script program.

[0166] It should be noted that the explanation of the embodiment of the testing method for the unit to be tested mentioned above is also applicable to the testing device for the unit to be tested in this embodiment, and will not be repeated here.

[0167] According to the test device of the unit to be tested proposed in the embodiment of the present application, by obtaining the source code to be compiled, compiling the source code to be compiled to obtain .elf files and .hex files, and writing the .elf files and .hex files into the vehicle integrated unit VIU, and parsing and processing the .elf files step by step to create a test case set, and storing the test case set in a preset embedded unit test framework, and based on the preset Jenkins automated deployment environment, deploying the unit to be tested in the preset embedded unit test framework to the target server, and after the deployment is completed, testing the unit to be tested through the VIU, generating a unit test report and a code coverage result report for the unit to be tested. In this way, the limitations of the existing technology are overcome, the problems of high learning and use costs and difficulty in popularization of related technologies are solved, and the efficiency of unit testing is greatly improved.

[0168] Figure 10This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. The electronic device may include:

[0169] A memory 1001 , a processor 1002 , and a computer program stored in the memory 1001 and executable on the processor 1002 .

[0170] When the processor 1002 executes the program, the testing method of the unit to be tested provided in the above embodiment is implemented.

[0171] Furthermore, the electronic device further includes:

[0172] The communication interface 1003 is used for communication between the memory 1001 and the processor 1002 .

[0173] The memory 1001 is used to store computer programs that can be run on the processor 1002 .

[0174] The memory 1001 may include a high-speed RAM (Random Access Memory) memory, and may also include a non-volatile memory, such as at least one disk memory.

[0175] If the memory 1001, the processor 1002, and the communication interface 1003 are implemented independently, the communication interface 1003, the memory 1001, and the processor 1002 can be connected to each other via a bus and communicate with each other. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 10 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0176] Optionally, in a specific implementation, if the memory 1001, the processor 1002 and the communication interface 1003 are integrated on a chip, the memory 1001, the processor 1002 and the communication interface 1003 can communicate with each other through an internal interface.

[0177] The processor 1002 may be a CPU (Central Processing Unit), or an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of the present application.

[0178] An embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon, which implements the above-mentioned testing method for the unit to be tested when the program is executed by a processor.

[0179] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification and features of different embodiments or examples without contradiction.

[0180] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of technical features indicated. Thus, a feature specified as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of this application, "N" means at least two, for example, two, three, etc., unless otherwise specifically defined.

[0181] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may be performed out of the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present application belong.

[0182] It should be understood that various parts of the present application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiment, the N steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array, a field programmable gate array, etc.

[0183] Those skilled in the art will understand that all or part of the steps in the method of the above embodiment can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.

[0184] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A method for testing a unit to be tested, characterized in that: The following steps are involved: Obtaining source code to be compiled, compiling the source code to be compiled to obtain a .elf file and a .hex file, and writing the .elf file and the .hex file into a vehicle integrated unit VIU; Parsing and processing the .elf file step by step to create a test case set, and storing the test case set in a preset embedded unit test framework; as well as Based on the preset Jenkins automated deployment environment, deploy the unit to be tested in the preset embedded unit testing framework to the target server, and after the deployment is completed, test the unit to be tested through the VIU to generate a unit test report and code coverage result report for the unit to be tested; The step-by-step parsing and processing of the .elf file to create a test case set includes: Convert the .elf file into a txt file; The data type and data structure information in the txt file are stored in a preset database; the data type stored in the preset database is processed based on a preset first script program, and based on a preset second script program, the test case set is automatically created according to the processed data type and data structure information.

2. The method according to claim 1, characterized in that Also includes: The unit test report is converted into an HTML unit test report, wherein the HTML unit test report includes the total number of test cases, the total number of test case execution failures, and the execution results and execution failure reasons corresponding to the test cases displayed in a list form.

3. The method according to claim 2, characterized in that Also includes: Obtain code coverage and branch coverage from the code coverage result report, and extract test cases that failed from the HTML unit test report; The unit to be tested is evaluated according to the code coverage, the branch coverage, and the test cases in which the test fails.

4. The method according to claim 2, characterized in that Before storing the test case set in the preset embedded unit test framework, the method further includes: Based on the preset Vscode integrated development environment, the Googletest unit testing framework is used, combined with CMake to compile the code and build the program to generate an executable .exe file; Construct the preset embedded unit test framework according to the executable .exe file.

5. A testing device for a unit to be tested, characterized in that: include: An acquisition module is used to obtain the source code to be compiled, compile the source code to be compiled to obtain an .elf file and a .hex file, and write the .elf file and the .hex file into the vehicle integrated unit VIU; A processing module is used to parse and process the .elf file step by step to create a test case set, and store the test case set in a preset embedded unit test framework; as well as A generation module is used to deploy the unit to be tested in the preset embedded unit testing framework to the target server based on the preset Jenkins automated deployment environment, and after the deployment is completed, test the unit to be tested through the VIU to generate a unit test report and a code coverage result report for the unit to be tested; The step-by-step parsing and processing of the .elf file to create a test case set includes: Convert the .elf file into a txt file; The data type and data structure information in the txt file are stored in a preset database; the data type stored in the preset database is processed based on a preset first script program, and based on a preset second script program, the test case set is automatically created according to the processed data type and data structure information.

6. The device according to claim 5, characterized in that Also used for: The unit test report is converted into an HTML unit test report, wherein the HTML unit test report includes the total number of test cases, the total number of test case execution failures, and the execution results and execution failure reasons corresponding to the test cases displayed in a list form.

7. The device according to claim 6, characterized in that Also used for: Obtain code coverage and branch coverage from the code coverage result report, and extract test cases that failed from the HTML unit test report; The unit to be tested is evaluated according to the code coverage, the branch coverage, and the test cases in which the test fails.

8. An electronic device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method for testing a unit to be tested according to any one of claims 1 to 4.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: The program is executed by a processor to implement the method for testing a unit to be tested as claimed in any one of claims 1 to 4.

Images