Software code testing method and device, electronic equipment and storage medium

Abstract

The invention discloses a software code testing method and device, electronic equipment and a storage medium, and relates to the technical field of software development or other related fields, and the method comprises the steps: taking a source code received by a version control system as a first target code to be tested, and synchronizing the first target code to a code review system; obtaining a code review result for the first target code; under the condition that the code review result shows that review is passed, a dynamic test tool is called to conduct code execution path test on the first target code, and a first test result is obtained; and under the condition that the first test result indicates that the test is passed, adding the first target code to the stock code to obtain a to-be-tested second target code, and calling the unit simulation tool to perform a working condition simulation test on the second target code to obtain a second test result. According to the method and the device, the technical problem that high-quality code delivery cannot be realized due to the fact that an automatic integration test process of software codes is not perfect in related technologies is solved.

Description

Technical Field

[0001] The present invention relates to the technical field of software development, and in particular to a software code testing method and device, electronic equipment, and storage medium. Background Art

[0002] With the development of electric and intelligent vehicles, the demand for software is becoming more and more complex, and the requirements for software development quality are also getting higher and higher. As the "brain" of the car, the Electronic Control Unit (ECU) controls the operation of the car. Software development and testing are key links in ECU development, and a large number of tests are required to ensure software quality and shorten the development cycle.

[0003] In order to improve testing efficiency and ensure testing accuracy, software testing methods have shifted from traditional handwritten testing to automated testing. At present, software testing automation is mainly functional testing automation, including unit testing, interface testing, integration testing, system testing, etc., using automated testing tools and hardware equipment to test the software and obtain test results.

[0004] However, in the prior art, due to the complexity of the ECU, it is difficult to design test cases, and due to the complexity of the ECU, the degree of test automation is low, the test efficiency is low, the test results are difficult to track, the test result report is difficult to generate, and the test result feedback is difficult.

[0005] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0006] The embodiments of the present invention provide a software code testing method and device, an electronic device, and a storage medium to at least solve the technical problem that the automated integrated testing process of software codes in related technologies is not perfect, resulting in the inability to achieve high-quality code delivery.

[0007] According to one aspect of an embodiment of the present invention, a software code testing method is provided, which is applied to an integrated deployment server of an in-vehicle system, wherein the integrated deployment server pre-deploys a version control system, a code review system, a dynamic testing tool and a unit simulation tool, and the software code testing method comprises: taking the source code received by the version control system as the first target code to be tested, and synchronizing the first target code to the code review system, wherein the code review system is used to open N code review ports, where N is a positive integer; obtaining the code review opinions for the first target code received by the N code review ports, and obtaining the code review result of the first target code; when the code review result indicates that the review is passed, calling the dynamic testing tool to perform a code execution path test on the first target code to obtain a first test result; when the first test result indicates that the code execution path test is passed, adding the first target code to the stock code to obtain a second target code to be tested, and calling the unit simulation tool to perform a working condition simulation test on the second target code to obtain a second test result.

[0008] Furthermore, the step of obtaining code review opinions for the first target code received by N code review ports to obtain a code review result for the first target code includes: when N code review opinions all indicate that the code is correct, setting the code review result to passed review, otherwise, setting the code review result to failed review; after obtaining the code review result of the first target code, the method also includes: when the code review result indicates failed review, obtaining code change suggestions recorded in all the code review opinions, and feeding back the code change suggestions to the development end of the source code.

[0009] Furthermore, the step of calling the dynamic testing tool to perform a code execution path test on the first target code to obtain a first test result includes: analyzing the execution logic of the first target code based on a preset analysis strategy, and generating a first test case based on the analysis result, wherein the first test case includes: a unit test case, an integration test case and a system test case; injecting the unit test case into the corresponding execution unit to obtain a unit test result, wherein the unit test result is used to indicate whether the function of the execution unit is correct; executing the integration test case to obtain an integration test result, wherein the integration test result is used to indicate whether the interface data exchange and control flow between the execution units are correct; executing the system test case to obtain a system test result, wherein the system test result is used to indicate whether the first target code runs correctly in the development environment; generating a first test result based on the unit test result, the integration test result and the system test result.

[0010] Furthermore, the preset analysis strategy includes: a static analysis strategy and a dynamic analysis strategy. The execution logic of the first target code is analyzed based on the preset analysis strategy, and the step of generating a first test case based on the analysis result includes: identifying branch statements, loop structures and function calls in the first target code based on the static analysis strategy to obtain M code execution paths of the first target code, where M is a positive integer; simulating the execution of the first target code based on the dynamic analysis strategy and the M code execution paths to obtain a code coverage report; if there are indicators in the code coverage report that are not met, re-analyze the execution logic of the first target code and correct the code execution path; if all indicators in the code coverage report are met, generate the first test case based on the M code execution paths.

[0011] Furthermore, after obtaining the first test result, the method also includes: when the first test result indicates that the code execution path test fails, prohibiting the first target code from being added to the existing code; generating a code repair report based on the code logic error record recorded in the first test result, and feeding back the code repair report to the development end of the source code.

[0012] Furthermore, the step of calling the unit simulation tool to perform an operating condition simulation test on the second target code to obtain a second test result includes: compiling the second target code to obtain a second test case; simulating the communication environment between the various automotive electronic control units of the vehicle-mounted system through the unit simulation tool to obtain a simulated operating condition; importing the second test case into the simulated operating condition, and executing the second test case to obtain the second test result.

[0013] According to another aspect of an embodiment of the present invention, an integrated deployment server for a vehicle-mounted system is also provided, including: a version control system, used to receive source code transmitted by a development end, and synchronize the source code as a first target code to be tested to a code review system; the code review system, used to receive the first target code, open N code review ports, and obtain code review opinions for the first target code received by the N code review ports, to obtain a code review result for the first target code, where N is a positive integer; a dynamic testing tool, used to perform a code execution path test on the first target code to obtain a first test result when the code review result indicates that the review is passed; a unit simulation tool, used to perform a working condition simulation test on the second target code to obtain a second test result when the first test result indicates that the code execution path test is passed, wherein the second target code is obtained by adding the first target code to the stock code.

[0014] According to another aspect of an embodiment of the present invention, there is also provided a testing device for software code, which is applied to an integrated deployment server of an in-vehicle system, wherein the integrated deployment server pre-deploys a version control system, a code review system, a dynamic testing tool and a unit simulation tool, and comprises: a synchronization unit, which is used to use the source code received by the version control system as a first target code to be tested, and synchronize the first target code to the code review system, wherein the code review system is used to open N code review ports, where N is a positive integer; an acquisition unit, which is used to acquire code review opinions for the first target code received by the N code review ports, and obtain a code review result for the first target code; a first test unit, which is used to call the dynamic testing tool to perform a code execution path test on the first target code to obtain a first test result when the code review result indicates that the review is passed; and a second test unit, which is used to add the first target code to the stock code to obtain a second target code to be tested when the first test result indicates that the code execution path test is passed, and call the unit simulation tool to perform a working condition simulation test on the second target code to obtain a second test result.

[0015] Furthermore, the acquisition unit includes: a setting module, which is used to set the code review result as passed when N code review opinions all indicate that the code is correct, otherwise, the code review result is set as failed; the software code testing device also includes: a first feedback module, which is used to obtain the code change suggestions recorded in all the code review opinions when the code review result indicates failed, and feed back the code change suggestions to the development end of the source code.

[0016] Furthermore, the first test unit includes: a first generation module, which is used to analyze the execution logic of the first target code based on a preset analysis strategy, and generate a first test case based on the analysis result, wherein the first test case includes: a unit test case, an integration test case and a system test case; an injection module, which is used to inject the unit test case into the corresponding execution unit to obtain a unit test result, wherein the unit test result is used to indicate whether the function of the execution unit is correct; a first execution module, which is used to execute the integration test case to obtain an integration test result, wherein the integration test result is used to indicate whether the interface data exchange and control flow between the execution units are correct; a second execution module, which is used to execute the system test case to obtain a system test result, wherein the system test result is used to indicate whether the first target code runs correctly in the development environment; a second generation module, which is used to generate a first test result based on the unit test result, the integration test result and the system test result.

[0017] Furthermore, the preset analysis strategy includes: a static analysis strategy and a dynamic analysis strategy, and the first generation module includes: an identification submodule, used to identify branch statements, loop structures and function calls in the first target code based on the static analysis strategy, and obtain M code execution paths of the first target code, where M is a positive integer; an execution submodule, used to simulate the execution of the first target code based on the dynamic analysis strategy and the M code execution paths, and obtain a code coverage report; a correction submodule, used to re-analyze the execution logic of the first target code and correct the code execution path when there are indicators in the code coverage report that do not meet the standards; a generation submodule, used to generate the first test case based on the M code execution paths when all indicators in the code coverage report meet the standards.

[0018] Furthermore, the testing device for the software code also includes: a prohibition module, used to prohibit the first target code from being added to the stock code when the first test result indicates that the code execution path test fails; a second feedback module, used to generate a code repair report based on the code logic error record recorded in the first test result, and feed back the code repair report to the development end of the source code.

[0019] Furthermore, the second test unit includes: a compilation module, used to compile the second target code to obtain a second test case; a simulation module, used to simulate the communication environment between the various automotive electronic control units of the vehicle-mounted system through the unit simulation tool to obtain a simulation working condition; a third execution module, used to import the second test case into the simulation working condition, and execute the second test case to obtain the second test result.

[0020] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is also provided, wherein the computer-readable storage medium includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute a testing method for any of the above-mentioned software codes.

[0021] According to another aspect of an embodiment of the present invention, there is also provided an electronic device, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement a testing method for any one of the above-mentioned software codes.

[0022] In the present invention, a testing method for software code is proposed, which can first use the source code received by the version control system as the first target code to be tested, and synchronize the first target code to the code review system, wherein the code review system is used to open N code review ports, N is a positive integer, and then obtain the code review opinions for the first target code received by the N code review ports to obtain the code review result of the first target code, and then, when the code review result indicates that the review is passed, call the dynamic testing tool to perform a code execution path test on the first target code to obtain a first test result, and finally, when the first test result indicates that the code execution path test is passed, add the first target code to the stock code to obtain a second target code to be tested, and call the unit simulation tool to perform a working condition simulation test on the second target code to obtain a second test result.

[0023] In the present invention, the received source code is synchronized to the code review system as the first target code to be tested by using the version control system to ensure that each code change is strictly reviewed, and N code review ports are opened to allow multiple reviewers to submit code review opinions in parallel. This multi-party review mechanism can not only improve the code quality, but also reduce potential errors and vulnerabilities in the code; in addition, the system can also obtain and integrate the review results in real time, and automatically call the dynamic test tool to perform code execution path testing if the review passes, so as to ensure the stability, correctness and reliability of the code under different execution paths, and add it to the stock code library after verification to form the second target code to be tested; next Then, the unit simulation tool is used to simulate the operation in the real environment, and the second target code is further subjected to working condition simulation test to verify the function and performance of the code during operation. The above-mentioned software code testing method not only improves the coverage and efficiency of code testing, but also significantly reduces the error risk caused by manual intervention through quality inspection and verification in multiple links, so that the final delivered code has higher quality assurance, effectively overcoming the shortcomings of the current imperfect automated integration testing process, and further solving the technical problem that the automated integration testing process of software code in related technologies is not perfect, resulting in the inability to achieve high-quality code delivery. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0025] Figure 1 is a flow chart of an optional software code testing method according to an embodiment of the present invention;

[0026] Figure 2 is a system diagram of an optional software continuous integration system according to an embodiment of the present invention;

[0027] Figure 3 is an optional implementation flow chart of software continuous integration according to an embodiment of the present invention;

[0028] Figure 4 is a schematic diagram of an optional integrated deployment server of a vehicle-mounted system according to an embodiment of the present invention;

[0029] Figure 5 is a schematic diagram of an optional software code testing device according to an embodiment of the present invention;

[0030] Figure 6The present invention is a hardware structure block diagram of an electronic device (or mobile device) for a software code testing method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0031] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings 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 should fall within the scope of protection of the present invention.

[0032] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0033] The following embodiments of the present invention can be applied to various systems / applications / devices that require software code testing and continuous integration and deployment of software code, and can implement a full coverage code automatic testing process based on an integrated deployment server. The present invention uses a version control system to collect code updates and synchronize them to a code review system, uses a code review system to provide multiple code review ports for reviewers to submit code review opinions, and then uses dynamic testing tools and working condition simulation tools to perform full coverage testing on the code, so as to improve the coverage and efficiency of code testing, and significantly reduce the risk of errors caused by manual intervention.

[0034] The present invention is described in detail below in conjunction with various embodiments.

[0035] Embodiment 1

[0036] According to an embodiment of the present invention, an embodiment of a testing method for software code is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0037] The implementation entity of the embodiment of the present invention can be an integrated deployment server of the vehicle-mounted system, which pre-deploys a version control system, a code review system, a dynamic testing tool and a unit simulation tool to execute the various implementation steps provided in Example 1 to ensure that each code change is subject to strict review, reduce potential errors and vulnerabilities in the code, and improve the coverage and efficiency of code testing through quality inspection and verification in multiple links, and reduce the risk of errors caused by manual intervention, so that the final delivered code has a higher quality assurance.

[0038] The embodiment of the present invention is described in detail below in conjunction with each step.

[0039] Figure 1 is a flow chart of an optional software code testing method according to an embodiment of the present invention, such as Figure 1 As shown, the method comprises the following steps:

[0040] Step S101, taking the source code received by the version control system as the first target code to be tested, and synchronizing the first target code to the code review system, wherein the code review system is used to open N code review ports, where N is a positive integer.

[0041] Specifically, the version control system (VCS) and the code review system are two extremely important tools in the software development process, playing a key role in code management and code quality control respectively.

[0042] Among them, the version control system is used to manage the modification history of files and directories in the code base (code warehouse). It allows developers to track changes to each file, record each modified version, support team collaboration, and ensure code consistency and traceability. In the embodiment of the present invention, git can be used as a version control system with the following characteristics: each developer's local git repository contains a complete code history and version information; git records the snapshot version of the file, rather than the difference of each change; git's branch management is very powerful, and branches can be easily created, merged, and deleted, which facilitates parallel development and isolated feature development; git is very efficient when processing large data sets and large projects, and its performance is better than many centralized version control systems.

[0043] In addition, the code review system is used to check and evaluate the quality and functionality of the code before the code is merged into the main branch. In the embodiment of the present invention, Gerrit can be used as a code review system. The main functions of Gerrit include: code changes submitted by developers need to be reviewed through Gerrit, and reviewers can make comments on the changes, request modifications, or approve the changes; Gerrit can track the entire life cycle of code changes, from submission, review to merging, to ensure the transparency and controllability of changes; Gerrit can be integrated with tools such as Jenkins and VectorCAST to realize the process of automated testing, building and code review, ensuring code quality while improving development efficiency; Gerrit provides a strict permission control mechanism, which can set different access rights for different users to the code repository to protect the security of the code.

[0044] In the embodiment of the present invention, the source code is first received by the git version control system, and then synchronized to the Gerrit code review system. Gerrit allows multiple people to conduct code review at the same time by opening N code review ports (N is a positive integer), thereby improving the efficiency of code review and the team's collaboration ability. Each code review port can handle one or more code change requests, and reviewers can conduct detailed reviews in their respective ports, make modification suggestions or approve code changes. In this way, it can be ensured that the code has been fully reviewed and tested before being merged into the main branch, reducing potential errors and defects in the code and improving the overall quality of the software.

[0045] Step S102, obtaining code review opinions for the first target code received by N code review ports, and obtaining a code review result of the first target code.

[0046] It should be noted that in the code review pipeline, by using Gerrit's REST API or the plug-in it provides, the review opinions of N code review ports (i.e., N reviewers) on the first target code are automatically obtained, including but not limited to: code syntax checking, logical analysis, specification compliance, and compatibility assessment with the existing code base.

[0047] Optionally, step S102 includes: when N code review opinions all indicate that the code is correct, setting the code review result as review passed; otherwise, setting the code review result as review failed.

[0048] In another optional embodiment, in addition to the case where "N code review opinions all indicate that the code is correct", a passing threshold may be set for determining the code review results. For example, when the majority (more than 50% or higher) of the review opinions are positive, the review is considered to have passed.

[0049] If an exception is encountered during the code review process, such as the reviewer fails to complete the review within the specified time, an automatic reminder mechanism can be set to notify the reviewer via email or instant message to complete the review task in time; if there are conflicts or different opinions in the review opinions, the Jenkins pipeline (specifically the code review pipeline in the embodiment of the present invention) can automatically suspend the merging process and notify the project leader or designated coordinator to intervene to summarize the opinions and resolve the conflicts.

[0050] Optionally, after obtaining the code review result of the first target code, the method further includes: when the code review result indicates that the review fails, obtaining code change suggestions recorded in all code review opinions, and feeding back the code change suggestions to the development end of the source code.

[0051] Another optional embodiment may also integrate an automatic code analysis tool. When the code review result is failed, the code problems are automatically analyzed and repair suggestions are generated. These repair suggestions can be fed back to the development side together with the code change suggestions of Gerrit to improve the repair efficiency. Alternatively, based on historical data and machine learning algorithms, the most likely effective repair plan or the most suitable repair personnel can be intelligently recommended to developers to speed up the problem solving process.

[0052] Furthermore, different weights can be set for each reviewer's feedback based on the reviewer's experience, expertise, and the accuracy of past reviews. When calculating the code review results, the overall review tendency can be more accurately reflected, reducing the subjective influence of individual reviewers. Through continuous code review results and actual test results, the reviewer weights can be dynamically adjusted to ensure the long-term effectiveness and fairness of the review system.

[0053] Step S103, when the code review result indicates that the review is passed, calling a dynamic testing tool to perform a code execution path test on the first target code to obtain a first test result.

[0054] Specifically, dynamic testing tools simulate user operations and system behaviors to verify the functions, performance, security and stability of the software in the actual operating environment, including but not limited to the following types: functional testing, which is to verify whether the software works as expected by inputting test cases and observing the output results; performance testing, which is to evaluate the performance of the software in a high-load, multi-user environment, such as response time, throughput and resource usage; stress testing, which is to run the software in extreme environments to test its stability and robustness; security testing, which is to detect the software's defense capabilities against attacks, such as SQL injection, XSS attacks, etc.; compatibility testing, which is to verify the operation of the software under different hardware, operating systems, and network environments.

[0055] In the embodiment of the present invention, VectorCAST can be used as a dynamic testing tool, which can provide a comprehensive test solution, including unit testing, integration testing and system testing, and can also support multiple test types, such as boundary value analysis, equivalence class partitioning, path testing, etc.

[0056] Another thing to note is that code execution path testing is a dynamic testing method, also known as path coverage testing or control flow testing, which aims to test all possible execution paths in the software. In software, a function or module may execute different paths based on different inputs and conditions. The goal of path testing is to ensure that each path is executed at least once to verify whether the logic and processing flow of the software are correct.

[0057] Path testing usually involves: generating test cases, that is, automatically or manually creating test cases to cover as many execution paths as possible; executing tests, that is, running test cases to observe the behavior and output of the software; analyzing results, that is, evaluating test coverage, such as counting how many code paths are covered by test cases and analyzing the reasons for uncovered paths.

[0058] The above-mentioned testing method helps to discover hidden defects and logical errors, and improve the robustness and reliability of the software. In a continuous integration environment, code execution path testing can be performed automatically to ensure that the software status can be fully tested after each code change. VectorCAST used in the embodiment of the present invention utilizes the concepts of dynamic testing and path testing, and provides a comprehensive testing framework to help developers and test engineers identify and fix problems in the code in the early stages of software development, thereby improving the overall quality of the software.

[0059] Optionally, step S103 includes: analyzing the execution logic of the first target code based on a preset analysis strategy, and generating a first test case based on the analysis result, wherein the first test case includes: a unit test case, an integration test case and a system test case; injecting the unit test case into the corresponding execution unit to obtain a unit test result, wherein the unit test result is used to indicate whether the function of the execution unit is correct; executing the integration test case to obtain an integration test result, wherein the integration test result is used to indicate whether the interface data exchange and control flow between the execution units are correct; executing the system test case to obtain a system test result, wherein the system test result is used to indicate whether the first target code runs correctly in the development environment; generating a first test result based on the unit test result, the integration test result and the system test result.

[0060] It should be noted that by injecting unit test cases into the corresponding execution units in the code to test the correctness of their independent functions, the unit test results can quickly feedback the functional status of the execution units. Then, integration testing is used to test the interface data exchange and control flow between the execution units to ensure that the modules work together correctly. Finally, the entire system is tested in the development environment to check whether the first target code can run normally in a specific application scenario.

[0061] Optionally, the preset analysis strategies include: static analysis strategies and dynamic analysis strategies, which are applied in different stages and situations to ensure code quality and system stability.

[0062] Among them, static analysis refers to the process of analyzing code without executing it, which is usually performed during the code writing or compilation stage, including but not limited to: syntax checking, code specification checking, code quality checking, security vulnerability detection, dependency analysis, and code duplication detection.

[0063] Dynamic analysis refers to the analysis of software behavior during code execution, usually performed during the software testing or running phase, including but not limited to: unit testing, integration testing, performance testing, compatibility testing, security testing, and coverage analysis.

[0064] Furthermore, the execution logic of the first target code is analyzed based on a preset analysis strategy, and the steps of generating a first test case based on the analysis results include: identifying branch statements, loop structures and function calls in the first target code based on a static analysis strategy, and obtaining M code execution paths of the first target code, where M is a positive integer; simulating the execution of the first target code based on a dynamic analysis strategy and the M code execution paths to obtain a code coverage report; if there are indicators in the code coverage report that are not met, re-analyzing the execution logic of the first target code and correcting the code execution path; if all indicators in the code coverage report are met, generating a first test case based on the M code execution paths.

[0065] It should be noted that identifying branch statements, loop structures, and function calls to obtain the execution path of the target code is a key step in software testing and code analysis. Among them, branch statement identification refers to analyzing conditional statements in the code, such as if, else, switch, etc., to determine the execution path under different conditions. Each conditional statement generates at least two paths according to the true or false situation, which helps to generate test cases covering all possible situations; loop structure identification refers to analyzing loop statements, such as for and while, considering all the logic in the loop body, including the boundary conditions of the loop, branch statements in the loop, etc. Since the number of loops may be uncertain, it is necessary to design test cases to cover at least one loop, loops that are not executed, and loops under boundary conditions; function call analysis refers to identifying function calls in the code, analyzing the function's parameters, return values, and the logical structure inside the function, which helps to ensure the correctness of the function and that all possible function call paths are covered.

[0066] Furthermore, based on the code execution path obtained by static analysis, the code can be simulated (i.e., running the code without connecting to the actual hardware or system) to collect runtime information, such as the value of variables, the order of function calls, etc., to verify whether the logic of the code works as expected, and at the same time calculate the code coverage. The code coverage report includes but is not limited to the following indicators: statement coverage (check whether each statement in the code is executed at least once); branch coverage (check whether the true and false branches of each conditional statement are executed at least once); condition coverage (for each logical condition in the conditional statement, check whether all possible combinations of conditions have been tested); path coverage (check whether all possible code execution paths are covered by test cases); function coverage (check whether each function is called by at least one test case).

[0067] Another thing to note is that the indicator does not meet the standard means that at least one coverage indicator in the code coverage report does not meet the predetermined minimum standard. For example, if the statement coverage is required to be at least 90%, but the actual coverage is only 85%, then the statement coverage indicator does not meet the standard, which indicates that there are untested areas in the code, which may hide undiscovered defects or errors. It is necessary to improve the coverage by modifying the test cases or adjusting the analysis strategy to ensure the integrity and reliability of the code.

[0068] In the embodiment of the present invention, if any indicator in the code coverage report does not meet the predetermined standard, the system will re-analyze the execution logic of the code, correct the code execution path and generate new test cases until all indicators meet the standard.

[0069] Optionally, after obtaining the first test result, the method also includes: when the first test result indicates that the code execution path test fails, prohibiting the first target code from being added to the existing code; generating a code repair report based on the code logic error record recorded in the first test result, and feeding back the code repair report to the development end of the source code.

[0070] It should be noted that legacy code refers to the existing code base that has been written and put into use before. This part of the code usually constitutes the basic framework of the software, and the newly developed code needs to work with it. In the continuous integration process, the legacy code is the code in the main branch or stable branch in the code repository, which represents the current stable state of the project.

[0071] Code logic error records are detailed records of code logic problems found during software testing, including but not limited to syntax errors, logic errors, runtime errors, etc., and usually include a detailed description of the error, the location where the error occurred (such as the file name and line number of the source code), possible causes, and suggested solutions. In automated testing, dynamic code testing tools such as VectorCAST automatically generate these error records.

[0072] Code fix reports are documents or information generated based on code logic error records to guide developers in fixing errors. The report usually lists all errors found, detailed descriptions of each error, and recommended steps for fixing them. It may also include the severity of the error, the priority of the fix, and the verification method after the fix. Code fix reports are a key component of the continuous integration process, ensuring that new code can only be merged into the stock code if all tests pass and the code meets the established standards, thereby maintaining the quality and stability of the code base.

[0073] In the embodiment of the present invention, if the dynamic code test result of VectorCAST shows that the code execution path test fails, that is, there is a code logic error, then the Jenkins pipeline will prohibit the code submitted this time (the first target code) from being added to the stock code, thereby preventing unstable or erroneous code from affecting the quality and stability of the entire project. At the same time, a code repair report will be automatically generated and fed back to the source code development end to help developers understand the problem in a timely manner and repair it, thereby ensuring the efficiency of software development and code quality.

[0074] Step S104, when the first test result indicates that the code execution path test has passed, the first target code is added to the stock code to obtain a second target code to be tested, and a unit simulation tool is called to perform a working condition simulation test on the second target code to obtain a second test result.

[0075] Optionally, step S104 includes: compiling the second target code to obtain a second test case; simulating the communication environment between each automotive electronic control unit of the vehicle system through a unit simulation tool to obtain a simulation working condition; importing the second test case into the simulation working condition, and executing the second test case to obtain a second test result.

[0076] Optionally, before merging the code into the main branch (i.e., adding the first target code to the stock code), use a suitable compiler to compile the second target code to ensure that the code has no syntax errors and complies with the project coding specifications. The choice of compiler should be based on the development environment and ECU platform requirements, such as using GCC (GNU Compiler Collection) or Clang for C / C++ code compilation.

[0077] After generating the second test case, use unit simulation tools such as VectorCAST or CANoe to simulate the communication environment between ECUs in the vehicle system, including setting network parameters, configuring communication protocols (such as CAN, LIN, FlexRay, Ethernet, etc.), and creating virtual ECU nodes to imitate the interaction scenarios in the real vehicle network. For example, use the ECU Wizard function of CANoe to quickly configure ECU models and communication scenarios.

[0078] Import the second test case into the set simulation environment, and test the performance of the second target code in various situations by simulating different working conditions (such as driving behavior, road environment, fault injection, etc.). The test results should be recorded and analyzed to ensure that the code can correctly respond to all preset working conditions after integration.

[0079] Optionally, after generating the second test case, a dynamic testing tool (such as VectorCAST) may be used to optimize the test case to ensure that all potential execution paths are covered.

[0080] The embodiment of the present invention can also add a performance test link after the code is merged to evaluate the performance impact of the second target code on the entire system, which can include testing of indicators such as response time, memory usage, CPU utilization, etc. For example, the integration test phase in the Jenkins pipeline is used in combination with hardware simulation tools (such as VectorCAST's VectorHMI plug-in) to monitor and evaluate the real-time performance of the software on the ECU.

[0081] In another optional embodiment, fault injection technology can also be used in the operating condition simulation test to simulate ECU hardware or software failures to test the fault handling capability and system stability of the second target code, for example, by modifying the test script in CANoe, or using a dedicated fault injection tool (such as VectorCAST's Fault Injection function). The test results can be used to improve the software's fault tolerance and recovery strategies.

[0082] Through the above steps S101 to S104, the source code received by the version control system can be first used as the first target code to be tested, and the first target code can be synchronized to the code review system, wherein the code review system is used to open N code review ports, N is a positive integer, and then obtain the code review opinions for the first target code received by the N code review ports to obtain the code review result of the first target code, and then, when the code review result indicates that the review is passed, call the dynamic testing tool to perform a code execution path test on the first target code to obtain a first test result, and finally, when the first test result indicates that the code execution path test is passed, add the first target code to the stock code to obtain the second target code to be tested, and call the unit simulation tool to perform a working condition simulation test on the second target code to obtain a second test result.

[0083] In the embodiment of the present invention, the received source code is synchronized to the code review system as the first target code to be tested by using the version control system to ensure that each code change is strictly reviewed, and N code review ports are opened to allow multiple reviewers to submit code review opinions in parallel. This multi-party review mechanism can not only improve the code quality, but also reduce potential errors and vulnerabilities in the code; in addition, the system can also obtain and integrate the review results in real time, and automatically call the dynamic test tool to perform code execution path testing if the review passes, so as to ensure the stability, correctness and reliability of the code under different execution paths, and add it to the stock code library after verification to form the second target code to be tested; then Next, the unit simulation tool is used to simulate the operation in the real environment, and the second target code is further subjected to working condition simulation testing to verify the function and performance of the code during operation. The above-mentioned software code testing method introduces version control systems, code review systems and dynamic testing tools, and performs quality inspections and verifications in multiple links. It not only improves the coverage and efficiency of code testing, but also significantly reduces the error risks caused by manual intervention, so that the final delivered code has higher quality assurance, effectively overcoming the shortcomings of the current imperfect automated integration testing process, and thus solves the technical problem that the automated integration testing process of software codes in related technologies is not perfect, resulting in the inability to achieve high-quality code delivery.

[0084] In a specific implementation, the software continuous integration system includes a continuous integration server based on Jenkins, a git version management system, a Gerrit code review tool, a VectorCAST dynamic testing tool, and hardware device tools CANoe and an automotive electronic control unit (ECU), wherein git, Gerrit, and VectorCAST plug-ins are installed on Jenkins to integrate the above tools.

[0085] Figure 2 is a system diagram of an optional software continuous integration system according to an embodiment of the present invention, such as Figure 2 As shown, the overall software system includes the following components: a code hosting server and a Jenkins continuous integration server, wherein the Jenkins continuous integration server interacts with the CANOE tool and the ECU.

[0086] It should be noted that the Jenkins continuous integration server, an open source continuous integration / continuous deployment (CI / CD) server, can automatically perform tasks such as building, testing, and deployment in software projects. Through its rich plug-in ecosystem, it can be integrated with various tools and support multiple types of building and testing strategies. Once Jenkins detects a new submission or code change in the code base, it will automatically trigger the build process to build the pipeline task, including: compiling, downloading executable files to ECU, VectorCAST testing, CANOE testing, and sending test reports.

[0087] The Jenkins-based continuous integration server is an easy-to-use continuous integration system that can continuously and automatically build / test software projects and monitor some executed tasks. With Jenkins, developers can automatically trigger the build, test, and deployment process after submitting code to a version control system (such as Git). This helps ensure code quality, reduce manual intervention, and accelerate the software development cycle. Create the corresponding pipeline project in Jenkins and configure the corresponding source code management, build triggers, and build steps to ensure that Jenkins can pull code from Git or other version control systems and automatically trigger the build process when the code changes. In the build step of the Jenkins pipeline, you need to write scripts or use existing scripts to start VectorCAST and CANOE to execute the corresponding test tasks and send test reports to developers. Through the Jenkins pipeline configuration, different test tasks can be automatically triggered after the code is submitted.

[0088] Furthermore, the Jenkins continuous integration server pulls code from the code hosting server, which integrates the git version control system and the Gerrit code review tool. The version control system git, i.e., a distributed version control system, is used to track the modification history of computer files and manage source code, allowing developers to perform version control in projects, including saving historical versions, branch development, merging changes, etc. The code review tool Gerrit, i.e., a code review system, is used in conjunction with the git version control system to provide a review environment for code changes. Before the code is merged into the main branch, Gerrit allows reviewers to review the code, provide feedback, and approve or reject the changes. When developers submit code changes through git, all changes are uploaded to the Gerrit server, and other team members can review these changes. Jenkins can be configured to listen to Gerrit events. When changes are uploaded, Jenkins can automatically run tests (such as VectorCAST tests) and wait for Gerrit's approval results. Developers submit changes to the git repository after making code modifications locally. Gerrit can provide permission control for the git repository hosted on the server, and its main function is code review.

[0089] Going further, VectorCAST refers to a dynamic code testing tool that is used to test the execution path of the software, detect potential defects and errors in the code, automatically generate test cases, perform unit testing, integration testing and system testing, and provide code coverage reports. Developers or Jenkins servers use VectorCAST to test newly submitted code. VectorCAST will automatically generate test cases based on the logic of the code, execute the test and report the results. If the test fails, Jenkins can be configured to prevent the code from being merged into the main branch until the problem is resolved.

[0090] CANOE is a tool for real-time simulation, testing, and diagnosis of automotive electronic control unit (ECU) buses. It can simulate the communication environment between ECUs to perform integration testing to ensure the reliability and performance of ECUs under actual working conditions. The Jenkins server can be configured to trigger CANOE integration test tasks to test the software on the ECU. If the software passes VectorCAST's unit and integration tests, Jenkins will automatically compile and download the software to the ECU, and then run CANOE for further integration testing.

[0091] ECU is an electronic device that controls specific functions of a car, such as an engine control unit, a brake control unit, etc. In the embodiment of the present invention, ECU is the object under test, which is used to run the software built and tested by the Jenkins pipeline. The Jenkins pipeline will automatically download the software that has passed the unit test and dynamic test to the ECU, and then use CANOE to perform integration testing on the software on the ECU to ensure that the software runs as expected on the ECU.

[0092] Based on the above tools and plug-ins being integrated and configured in the Jenkins server, the embodiment of the present invention further proposes a specific implementation process: Figure 3 is an optional implementation flow chart of software continuous integration according to an embodiment of the present invention, such as Figure 3 As shown, the implementation process includes:

[0093] Receive the target code submitted by developers to the git-based Gerrit platform, and the Jenkins server detects new submissions to Gerrit, triggering code review.

[0094] Trigger the VectorCAST dynamic code test task and notify relevant personnel to conduct code review. If the test results show a failure or code review-1, send a test report to the developer and notify the developer to fix the code. If all test results pass and code review+1, merge the target code submitted this time into the main branch of the repository.

[0095] The Jenkins server triggers the automatic build compilation task, synchronizes the latest code of the main branch of the warehouse, calls the compilation command to build the automatic compilation, and automatically downloads the successfully compiled executable file to the ECU.

[0096] The Jenkins server triggers the CANOE integration test task and sends a test report to the project team members after the test is completed.

[0097] The implementation mode of the present invention adds a code review (code review and dynamic testing) process before the code is merged, which saves manual verification time and can find problems early to avoid introducing bigger problems after merging, increasing the complexity of problem location and resolution; by combining CANOE and Jenkins, the development team can easily achieve the goal of continuous integration automated testing, which not only improves testing efficiency and code quality, but also helps to reduce errors, accelerate software development cycle and reduce maintenance costs; the report provided by Jenkins can be used to monitor and analyze the process of continuous integration automated testing, and by tracking data on test coverage, defect discovery and repair, etc., test cases can be continuously optimized and code quality can be improved.

[0098] The present invention is described below in conjunction with another optional embodiment.

[0099] Embodiment 2

[0100] An integrated deployment server for an in-vehicle system provided in this embodiment includes multiple implementation systems / tools for collaboratively executing the implementation steps in the above-mentioned embodiment 1.

[0101] Figure 4 is a schematic diagram of an optional integrated deployment server of a vehicle-mounted system according to an embodiment of the present invention, such as Figure 4 As shown, the device may include: a version control system 41, a code review system 42, a dynamic testing tool 43, and a unit simulation tool 44.

[0102] The version control system 41 is used to receive the source code transmitted by the development end, and synchronize the source code to the code review system as the first target code to be tested.

[0103] The code review system 42 is used to receive the first target code, open N code review ports, and obtain the code review opinions for the first target code received by the N code review ports to obtain the code review result of the first target code, where N is a positive integer.

[0104] The dynamic testing tool 43 is used to perform a code execution path test on the first target code to obtain a first test result when the code review result indicates that the review is passed.

[0105] The unit simulation tool 44 is used to perform a working condition simulation test on the second target code to obtain a second test result when the first test result indicates that the code execution path test has passed, wherein the second target code is obtained by adding the first target code to the stock code.

[0106] Each implementation system / tool ​​included in the integrated deployment server of the above vehicle-mounted system implements at least the following steps:

[0107] Step S101, taking the source code received by the version control system as the first target code to be tested, and synchronizing the first target code to the code review system, wherein the code review system is used to open N code review ports, where N is a positive integer.

[0108] Specifically, the version control system (VCS) and the code review system are two extremely important tools in the software development process, playing a key role in code management and code quality control respectively.

[0109] Among them, the version control system is used to manage the modification history of files and directories in the code base (code warehouse). It allows developers to track changes to each file, record each modified version, support team collaboration, and ensure code consistency and traceability. In the embodiment of the present invention, git can be used as a version control system with the following characteristics: each developer's local git repository contains a complete code history and version information; git records the snapshot version of the file, rather than the difference of each change; git's branch management is very powerful, and branches can be easily created, merged, and deleted, which facilitates parallel development and isolated feature development; git is very efficient when processing large data sets and large projects, and its performance is better than many centralized version control systems.

[0110] In addition, the code review system is used to check and evaluate the quality and functionality of the code before the code is merged into the main branch. In the embodiment of the present invention, Gerrit can be used as a code review system. The main functions of Gerrit include: code changes submitted by developers need to be reviewed through Gerrit, and reviewers can make comments on the changes, request modifications, or approve the changes; Gerrit can track the entire life cycle of code changes, from submission, review to merging, to ensure the transparency and controllability of changes; Gerrit can be integrated with tools such as Jenkins and VectorCAST to realize the process of automated testing, building and code review, ensuring code quality while improving development efficiency; Gerrit provides a strict permission control mechanism, which can set different access rights for different users to the code repository to protect the security of the code.

[0111] Step S102, obtaining code review opinions for the first target code received by N code review ports, and obtaining a code review result of the first target code.

[0112] It should be noted that in the code review pipeline, by using Gerrit's REST API or the plug-in it provides, the review opinions of N code review ports (i.e., N reviewers) on the first target code are automatically obtained, including but not limited to: code syntax checking, logical analysis, specification compliance, and compatibility assessment with the existing code base.

[0113] Optionally, step S102 includes: when N code review opinions all indicate that the code is correct, setting the code review result as review passed; otherwise, setting the code review result as review failed.

[0114] In another optional embodiment, in addition to the case where "N code review opinions all indicate that the code is correct", a passing threshold may be set for determining the code review results. For example, when the majority (more than 50% or higher) of the review opinions are positive, the review is considered to have passed.

[0115] If an exception is encountered during the code review process, such as the reviewer fails to complete the review within the specified time, an automatic reminder mechanism can be set to notify the reviewer via email or instant message to complete the review task in time; if there are conflicts or different opinions in the review opinions, the Jenkins pipeline (specifically the code review pipeline in the embodiment of the present invention) can automatically suspend the merging process and notify the project leader or designated coordinator to intervene to summarize the opinions and resolve the conflicts.

[0116] Optionally, after obtaining the code review result of the first target code, the method further includes: when the code review result indicates that the review fails, obtaining code change suggestions recorded in all code review opinions, and feeding back the code change suggestions to the development end of the source code.

[0117] Another optional embodiment may also integrate an automatic code analysis tool. When the code review result is failed, the code problems are automatically analyzed and repair suggestions are generated. These repair suggestions can be fed back to the development side together with the code change suggestions of Gerrit to improve the repair efficiency. Alternatively, based on historical data and machine learning algorithms, the most likely effective repair plan or the most suitable repair personnel can be intelligently recommended to developers to speed up the problem solving process.

[0118] Furthermore, different weights can be set for each reviewer's feedback based on the reviewer's experience, expertise, and the accuracy of past reviews. When calculating the code review results, the overall review tendency can be more accurately reflected, reducing the subjective influence of individual reviewers. Through continuous code review results and actual test results, the reviewer weights can be dynamically adjusted to ensure the long-term effectiveness and fairness of the review system.

[0119] Step S103, when the code review result indicates that the review is passed, calling a dynamic testing tool to perform a code execution path test on the first target code to obtain a first test result.

[0120] Specifically, dynamic testing tools simulate user operations and system behaviors to verify the functions, performance, security and stability of the software in the actual operating environment, including but not limited to the following types: functional testing, which is to verify whether the software works as expected by inputting test cases and observing the output results; performance testing, which is to evaluate the performance of the software in a high-load, multi-user environment, such as response time, throughput and resource usage; stress testing, which is to run the software in extreme environments to test its stability and robustness; security testing, which is to detect the software's defense capabilities against attacks, such as SQL injection, XSS attacks, etc.; compatibility testing, which is to verify the operation of the software under different hardware, operating systems, and network environments.

[0121] In the embodiment of the present invention, VectorCAST can be used as a dynamic testing tool, which can provide a comprehensive test solution, including unit testing, integration testing and system testing, and can also support multiple test types, such as boundary value analysis, equivalence class partitioning, path testing, etc.

[0122] Another thing to note is that code execution path testing is a dynamic testing method, also known as path coverage testing or control flow testing, which aims to test all possible execution paths in the software. In software, a function or module may execute different paths based on different inputs and conditions. The goal of path testing is to ensure that each path is executed at least once to verify whether the logic and processing flow of the software are correct.

[0123] Path testing usually involves: generating test cases, that is, automatically or manually creating test cases to cover as many execution paths as possible; executing tests, that is, running test cases to observe the behavior and output of the software; analyzing results, that is, evaluating test coverage, such as counting how many code paths are covered by test cases and analyzing the reasons for uncovered paths.

[0124] Optionally, after obtaining the first test result, the method also includes: when the first test result indicates that the code execution path test fails, prohibiting the first target code from being added to the existing code; generating a code repair report based on the code logic error record recorded in the first test result, and feeding back the code repair report to the development end of the source code.

[0125] It should be noted that legacy code refers to the existing code base that has been written and put into use before. This part of the code usually constitutes the basic framework of the software, and the newly developed code needs to work with it. In the continuous integration process, the legacy code is the code in the main branch or stable branch in the code repository, which represents the current stable state of the project.

[0126] Code logic error records are detailed records of code logic problems found during software testing, including but not limited to syntax errors, logic errors, runtime errors, etc., and usually include a detailed description of the error, the location where the error occurred (such as the file name and line number of the source code), possible causes, and suggested solutions. In automated testing, dynamic code testing tools such as VectorCAST automatically generate these error records.

[0127] Code fix reports are documents or information generated based on code logic error records to guide developers in fixing errors. The report usually lists all errors found, detailed descriptions of each error, and recommended steps for fixing them. It may also include the severity of the error, the priority of the fix, and the verification method after the fix. Code fix reports are a key component of the continuous integration process, ensuring that new code can only be merged into the stock code if all tests pass and the code meets the established standards, thereby maintaining the quality and stability of the code base.

[0128] In the embodiment of the present invention, if the dynamic code test result of VectorCAST shows that the code execution path test fails, that is, there is a code logic error, then the Jenkins pipeline will prohibit the code submitted this time (the first target code) from being added to the stock code, thereby preventing unstable or erroneous code from affecting the quality and stability of the entire project. At the same time, a code repair report will be automatically generated and fed back to the source code development end to help developers understand the problem in a timely manner and repair it, thereby ensuring the efficiency of software development and code quality.

[0129] Step S104, when the first test result indicates that the code execution path test has passed, the first target code is added to the stock code to obtain a second target code to be tested, and a unit simulation tool is called to perform a working condition simulation test on the second target code to obtain a second test result.

[0130] Optionally, before merging the code into the main branch (i.e., adding the first target code to the stock code), use a suitable compiler to compile the second target code to ensure that the code has no syntax errors and complies with the project coding specifications. The choice of compiler should be based on the development environment and ECU platform requirements, such as using GCC (GNU Compiler Collection) or Clang for C / C++ code compilation.

[0131] The integrated deployment server of the above-mentioned vehicle-mounted system first receives the source code transmitted by the development end through the version control system 41, and synchronizes the source code as the first target code to be tested to the code review system 42, and then receives the first target code through the code review system 42, opens N code review ports, and obtains the code review opinions for the first target code received by the N code review ports, and obtains the code review result of the first target code, where N is a positive integer. Then, through the dynamic testing tool 43, when the code review result indicates that the review is passed, a code execution path test is performed on the first target code to obtain a first test result. Finally, through the unit simulation tool 44, when the first test result indicates that the code execution path test is passed, a working condition simulation test is performed on the second target code to obtain a second test result, wherein the second target code is obtained by adding the first target code to the existing code.

[0132] In the embodiment of the present invention, the received source code is synchronized to the code review system as the first target code to be tested by using the version control system to ensure that each code change is strictly reviewed, and N code review ports are opened to allow multiple reviewers to submit code review opinions in parallel. This multi-party review mechanism can not only improve the code quality, but also reduce potential errors and vulnerabilities in the code; in addition, the system can also obtain and integrate the review results in real time, and automatically call the dynamic test tool to perform code execution path testing if the review passes, so as to ensure the stability, correctness and reliability of the code under different execution paths, and add it to the stock code library after verification to form the second target code to be tested; then Next, the unit simulation tool is used to simulate the operation in the real environment, and the second target code is further subjected to working condition simulation testing to verify the function and performance of the code during operation. The above-mentioned software code testing method introduces version control systems, code review systems and dynamic testing tools, and performs quality inspections and verifications in multiple links. It not only improves the coverage and efficiency of code testing, but also significantly reduces the error risks caused by manual intervention, so that the final delivered code has higher quality assurance, effectively overcoming the shortcomings of the current imperfect automated integration testing process, and thus solves the technical problem that the automated integration testing process of software codes in related technologies is not perfect, resulting in the inability to achieve high-quality code delivery.

[0133] Embodiment 3

[0134] A software code testing device provided in this embodiment includes multiple implementation units, each implementation unit corresponding to each implementation step in the above-mentioned embodiment 1.

[0135] Figure 5 is a schematic diagram of an optional software code testing device according to an embodiment of the present invention, such as Figure 5As shown, the device may include: a synchronization unit 51 , an acquisition unit 52 , a first test unit 53 , and a second test unit 54 .

[0136] The synchronization unit 51 is used to use the source code received by the version control system as the first target code to be tested, and synchronize the first target code to the code review system, wherein the code review system is used to open N code review ports, where N is a positive integer.

[0137] The acquisition unit 52 is used to acquire the code review opinions for the first target code received by the N code review ports, and obtain the code review result of the first target code.

[0138] The first testing unit 53 is used to call a dynamic testing tool to perform a code execution path test on the first target code to obtain a first testing result when the code review result indicates that the review is passed.

[0139] The second test unit 54 is used to add the first target code to the stock code to obtain the second target code to be tested when the first test result indicates that the code execution path test has passed, and call the unit simulation tool to perform a working condition simulation test on the second target code to obtain a second test result.

[0140] The testing device for the above-mentioned software code can first use the synchronization unit 51 to take the source code received by the version control system as the first target code to be tested, and synchronize the first target code to the code review system, wherein the code review system is used to open N code review ports, N is a positive integer, and then obtain the code review opinions for the first target code received by the N code review ports through the acquisition unit 52 to obtain the code review result of the first target code, and then through the first test unit 53, when the code review result indicates that the review is passed, call the dynamic test tool to perform a code execution path test on the first target code to obtain a first test result, and finally through the second test unit 54, when the first test result indicates that the code execution path test is passed, add the first target code to the existing code to obtain the second target code to be tested, and call the unit simulation tool to perform a working condition simulation test on the second target code to obtain a second test result.

[0141] In the embodiment of the present invention, the received source code is synchronized to the code review system as the first target code to be tested by using the version control system to ensure that each code change is strictly reviewed, and N code review ports are opened to allow multiple reviewers to submit code review opinions in parallel. This multi-party review mechanism can not only improve the code quality, but also reduce potential errors and vulnerabilities in the code; in addition, the system can also obtain and integrate the review results in real time, and automatically call the dynamic test tool to perform code execution path testing if the review passes, so as to ensure the stability, correctness and reliability of the code under different execution paths, and add it to the stock code library after verification to form the second target code to be tested; Next, the unit simulation tool is used to simulate the operation in the real environment, and the second target code is further subjected to working condition simulation testing to verify the function and performance of the code during operation. The above-mentioned software code testing method introduces version control systems, code review systems and dynamic testing tools, and through quality inspection and verification in multiple links, it not only improves the coverage and efficiency of code testing, but also significantly reduces the error risk caused by manual intervention, so that the final delivered code has higher quality assurance, effectively overcoming the shortcomings of the current imperfect automated integration testing process, and thus solves the technical problem that the automated integration testing process of software codes in related technologies is not perfect, resulting in the inability to achieve high-quality code delivery.

[0142] Optionally, the acquisition unit includes: a setting module, used to set the code review result as passed when N code review opinions all indicate that the code is correct, otherwise, setting the code review result as failed; the software code testing device also includes: a first feedback module, used to obtain the code change suggestions recorded in all code review opinions when the code review result indicates failed, and feed back the code change suggestions to the development end of the source code.

[0143] Optionally, the first test unit includes: a first generation module, which is used to analyze the execution logic of the first target code based on a preset analysis strategy, and generate a first test case based on the analysis result, wherein the first test case includes: a unit test case, an integration test case and a system test case; an injection module, which is used to inject the unit test case into the corresponding execution unit to obtain a unit test result, wherein the unit test result is used to indicate whether the function of the execution unit is correct; a first execution module, which is used to execute the integration test case to obtain the integration test result, wherein the integration test result is used to indicate whether the interface data exchange and control flow between the execution units are correct; a second execution module, which is used to execute the system test case to obtain the system test result, wherein the system test result is used to indicate whether the first target code runs correctly in the development environment; a second generation module, which is used to generate a first test result based on the unit test result, the integration test result and the system test result.

[0144] Optionally, the preset analysis strategy includes: a static analysis strategy and a dynamic analysis strategy, and the first generation module includes: an identification submodule, which is used to identify branch statements, loop structures and function calls in the first target code based on the static analysis strategy, and obtain M code execution paths of the first target code, where M is a positive integer; an execution submodule, which is used to simulate the execution of the first target code based on the dynamic analysis strategy and the M code execution paths, and obtain a code coverage report; a correction submodule, which is used to re-analyze the execution logic of the first target code and correct the code execution path when there are indicators in the code coverage report that are not met; and a generation submodule, which is used to generate a first test case based on the M code execution paths when all indicators in the code coverage report are met.

[0145] Optionally, the testing device for software code also includes: a prohibition module, used to prohibit the first target code from being added to the stock code when the first test result indicates that the code execution path test fails; a second feedback module, used to generate a code repair report based on the code logic error record recorded in the first test result, and feed back the code repair report to the development end of the source code.

[0146] Optionally, the second test unit includes: a compilation module, used to compile the second target code to obtain a second test case; a simulation module, used to simulate the communication environment between each automotive electronic control unit of the vehicle system through a unit simulation tool to obtain a simulation working condition; a third execution module, used to import the second test case into the simulation working condition, and execute the second test case to obtain a second test result.

[0147] The above-mentioned software code testing device may also include a processor and a memory. The above-mentioned synchronization unit 51, acquisition unit 52, first test unit 53, second test unit 54, etc. are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to realize corresponding functions.

[0148] The processor includes a kernel, and the kernel retrieves the corresponding program unit from the memory. One or more kernels can be set, and when the first test result indicates that the code execution path test has passed, the kernel parameters are adjusted to add the first target code to the stock code to obtain the second target code to be tested, and the unit simulation tool is called to perform a working condition simulation test on the second target code to obtain the second test result.

[0149] The above-mentioned memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one storage chip.

[0150] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialized program having the following method steps: using the source code received by the version control system as the first target code to be tested, and synchronizing the first target code to the code review system, wherein the code review system is used to open N code review ports, where N is a positive integer; obtaining the code review opinions for the first target code received by the N code review ports, and obtaining the code review result of the first target code; when the code review result indicates that the review is passed, calling the dynamic testing tool to perform a code execution path test on the first target code to obtain a first test result; when the first test result indicates that the code execution path test is passed, adding the first target code to the stock code to obtain a second target code to be tested, and calling the unit simulation tool to perform a working condition simulation test on the second target code to obtain a second test result.

[0151] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein when the computer program is running, a testing method for controlling a device where the computer-readable storage medium is located to execute the software code of any one of the above-mentioned embodiments one is implemented.

[0152] According to another aspect of an embodiment of the present invention, there is also provided an electronic device, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by one or more processors, the one or more processors implement a method for testing the software code of any one of the above-mentioned embodiments one.

[0153] Figure 6 1 is a hardware structure block diagram of an electronic device (or mobile device) for a software code testing method according to an embodiment of the present invention. Figure 6 As shown, the electronic device may include one or more ( Figure 6 The processor 602a, processor 602b, ..., processor 602n are used to illustrate) processor 602 (processor 602 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), and a memory 604 for storing data. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a keyboard, a power supply and / or a camera. It can be understood by those skilled in the art that Figure 6 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 6 More or fewer components as shown, or with Figure 6 Different configurations are shown.

[0154] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0155] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0156] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0157] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0158] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0159] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.

[0160] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A software code testing method, characterized in that: An integrated deployment server applied to an in-vehicle system, wherein the integrated deployment server pre-deploys a version control system, a code review system, a dynamic testing tool, and a unit simulation tool, and the software code testing method includes: Using the source code received by the version control system as a first target code to be tested, and synchronizing the first target code to the code review system, wherein the code review system is used to open N code review ports, where N is a positive integer; Obtaining code review opinions for the first target code received by the N code review ports to obtain a code review result of the first target code; When the code review result indicates that the review is passed, calling the dynamic testing tool to perform a code execution path test on the first target code to obtain a first test result; When the first test result indicates that the code execution path test passes, the first target code is added to the stock code to obtain a second target code to be tested, and the unit simulation tool is called to perform a working condition simulation test on the second target code to obtain a second test result.

2. The testing method according to claim 1, characterized in that: The step of obtaining code review opinions for the first target code received by the N code review ports to obtain a code review result of the first target code includes: If all N code review opinions indicate that the code is correct, the code review result is set to pass the review; otherwise, the code review result is set to fail the review; After obtaining the code review result of the first target code, the method further includes: When the code review result indicates that the review fails, the code change suggestions recorded in all the code review opinions are obtained, and the code change suggestions are fed back to the development end of the source code.

3. The testing method according to claim 1, characterized in that: The step of calling the dynamic testing tool to perform a code execution path test on the first target code to obtain a first test result includes: Analyze the execution logic of the first target code based on a preset analysis strategy, and generate a first test case based on the analysis result, wherein the first test case includes: a unit test case, an integration test case and a system test case; Injecting the unit test case into the corresponding execution unit to obtain a unit test result, wherein the unit test result is used to indicate whether the function of the execution unit is correct; Execute the integration test case to obtain an integration test result, wherein the integration test result is used to indicate whether the interface data exchange and control flow between the execution units are correct; Executing the system test case to obtain a system test result, wherein the system test result is used to indicate whether the first target code runs correctly in the development environment; A first test result is generated according to the unit test result, the integration test result and the system test result.

4. The testing method according to claim 3, characterized in that: The preset analysis strategy includes: a static analysis strategy and a dynamic analysis strategy. The execution logic of the first target code is analyzed based on the preset analysis strategy, and the step of generating a first test case based on the analysis result includes: Identify branch statements, loop structures, and function calls in the first target code based on the static analysis strategy, and obtain M code execution paths of the first target code, where M is a positive integer; Based on the dynamic analysis strategy and the M code execution paths, the first target code is simulated and executed to obtain a code coverage report; When there are indicators in the code coverage report that do not meet the standards, reanalyze the execution logic of the first target code and correct the code execution path; When all indicators in the code coverage report meet the standards, the first test case is generated according to the M code execution paths.

5. The testing method according to claim 1, characterized in that: After obtaining the first test result, the method further includes: If the first test result indicates that the code execution path test fails, prohibiting the first target code from being added to the stock code; A code repair report is generated based on the code logic error record recorded in the first test result, and the code repair report is fed back to the development end of the source code.

6. The testing method according to claim 1, characterized in that: The step of calling the unit simulation tool to perform a working condition simulation test on the second target code to obtain a second test result includes: Compiling the second target code to obtain a second test case; The unit simulation tool is used to simulate the communication environment between the automobile electronic control units of the vehicle system to obtain a simulation working condition; Import the second test case into the simulation working condition, and execute the second test case to obtain the second test result.

7. An integrated deployment server for an in-vehicle system, characterized in that: A testing method for executing the software code according to any one of claims 1 to 6, wherein the integrated deployment server of the vehicle-mounted system comprises: A version control system, for receiving source code transmitted by a development end, and synchronizing the source code as a first target code to be tested to a code review system; The code review system is used to receive the first target code, open N code review ports, and obtain code review opinions for the first target code received by the N code review ports to obtain a code review result of the first target code, where N is a positive integer; A dynamic testing tool, used for performing a code execution path test on the first target code to obtain a first test result when the code review result indicates that the review is passed; A unit simulation tool is used to perform a working condition simulation test on a second target code to obtain a second test result when the first test result indicates that the code execution path test has passed, wherein the second target code is obtained by adding the first target code to the stock code.

8. A software code testing device, characterized in that: An integrated deployment server applied to an in-vehicle system, wherein the integrated deployment server pre-deploys a version control system, a code review system, a dynamic testing tool, and a unit simulation tool, and the testing device for the software code includes: a synchronization unit, configured to use the source code received by the version control system as a first target code to be tested, and synchronize the first target code to the code review system, wherein the code review system is configured to open N code review ports, where N is a positive integer; an acquisition unit, configured to acquire code review opinions for the first target code received by the N code review ports, and obtain a code review result for the first target code; A first testing unit is used to call the dynamic testing tool to perform a code execution path test on the first target code to obtain a first test result when the code review result indicates that the review is passed; The second test unit is used to add the first target code to the existing code to obtain the second target code to be tested, and call the unit simulation tool to perform a working condition simulation test on the second target code to obtain a second test result when the first test result indicates that the code execution path test has passed.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located is controlled to execute the testing method of the software code according to any one of claims 1 to 6.

10. An electronic device, characterized in that: It comprises one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the software code testing method described in any one of claims 1 to 6.

Images