A code processing method and related products
By using a preset test mapping table and automated testing process in power switches, the problem of incomplete testing in code merging management was solved, the quality and efficiency of code merging were improved, and the success rate and coverage requirements were ensured before the code was merged.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING SIFANG JIBAO ENG TECH
- Filing Date
- 2026-04-28
- Publication Date
- 2026-06-12
Smart Images
Figure CN122195477A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a code processing method and related products. Background Technology
[0002] In the power industry, power switches are key devices ensuring the stable operation and efficient communication of power systems, making the quality and reliability of their software systems paramount. Code merging management is a crucial step in the development of power switch software, as it directly impacts the stability, security, and performance of the final delivered software.
[0003] As the power industry continues to demand intelligence and automation, the functions of power switches are becoming increasingly complex, and the software scale is continuously expanding. Code integration management is facing more severe challenges. However, the code integration management solutions provided in related technologies have problems such as incomplete testing and difficulty in locating code defects, which in turn reduces the quality and efficiency of code integration. Summary of the Invention
[0004] In view of the above problems, this application provides a code processing method and related products, which aim to improve the quality and efficiency of code integration.
[0005] The embodiments of this application disclose the following technical solutions: In a first aspect, embodiments of this application provide a code processing method, which may include: Obtain code merge request; whereby, code merge request represents a request to modify the code of the target business module in the target branch, and the code merge request includes the code to be merged; In response to a code merging request, the target test case information corresponding to the target business module is determined based on a preset test mapping table; wherein, the preset test mapping table represents the mapping relationship between each business module and each test case information in the target branch; The target test code corresponding to the code to be merged and the target test case information are jointly compiled to obtain the target binary file; the target binary file is used to upload to the target power switch, and the target power switch is used to run the target binary file in response to the target test command and generate the target test results; The target test results are validated to obtain the target validation results, which include the execution success rate and code coverage. If the execution success rate is greater than or equal to the first threshold, and the code coverage is greater than or equal to the second threshold, then the code to be merged is allowed to be merged into the code corresponding to the target business module. If the execution success rate is less than the first threshold, or the code coverage is less than the second threshold, then the code to be merged into the target business module will be rejected.
[0006] In conjunction with the first aspect, one possible implementation also includes determining the target business module in the following way: Retrieve the target branch code corresponding to the target branch; Determine the path to the changed files based on the code to be merged and the target branch code; The target business module is determined based on the changed file path and the preset test mapping table.
[0007] In conjunction with the first aspect, in one possible implementation, before determining the target test case information corresponding to the target business module based on a preset test mapping table, the following steps are also included: Determine whether the target branch contains the target test case file and target parameter file corresponding to the target business module; If the target branch contains a target test case file and a target parameter file, the target test case information will be matched according to the preset test mapping table. If the target test case file or target parameter file does not exist in the target branch, the code to be merged into the target business module will be rejected, and an alarm message will be generated.
[0008] In conjunction with the first aspect, one possible implementation also includes obtaining the target test results through the following methods: Establish a connection with the target power switch via the target protocol; The test environment of the target power switch is verified, and the environmental verification results are obtained. If the environment verification result is satisfactory, the test environment is initialized, and the target binary file is run in response to the target test command, and the target test result is generated.
[0009] In conjunction with the first aspect, one possible implementation also includes determining code coverage in the following ways: Based on the target test results, determine the total number of functions, the number of functions that were successfully executed, the total number of function lines, and the number of function lines that were successfully executed for the target business module. The first coverage rate is determined based on the total number of functions and the number of functions that were successfully executed. The second coverage ratio is determined based on the total number of function lines and the number of function lines that were successfully executed. Use the first and second coverage rates as code coverage.
[0010] In conjunction with the first aspect, in one possible implementation, the second threshold includes a first preset value and a second preset value. If the execution success rate is greater than or equal to the first threshold, and the first coverage rate is greater than or equal to the first preset value, and the second coverage rate is greater than or equal to the second preset value, then the code to be merged is allowed to be merged into the code corresponding to the target business module. If the execution success rate is less than the first threshold, or the first coverage rate is less than the first preset value, or the second coverage rate is less than the second preset value, then the code to be merged into the target business module will be rejected.
[0011] In conjunction with the first aspect, in one possible implementation, obtaining the code merge request includes: Create a feature branch or a fix branch; Modify the code of the target business module according to the functional branch or the fix branch, and update the target test cases corresponding to the target business module in a synchronous manner; Send the modified code to be merged to the remote feature branch; Generate and send a code merge request to the target branch via a remote feature branch.
[0012] In conjunction with the first aspect, one possible implementation also includes: If the target business module does not exist in the target branch, then the module type of the target business module is determined to be a new module; If the target business module exists in the target branch, then the module type of the target business module is determined to be a modification module.
[0013] Secondly, embodiments of this application provide a code processing apparatus, which may include: The acquisition unit is used to acquire code merge requests; wherein, the code merge request represents a request to modify the code of the target business module in the target branch, and the code merge request includes the code to be merged; The determination unit is used to determine the target test case information corresponding to the target business module based on the preset test mapping table in response to the code merging request; wherein, the preset test mapping table represents the mapping relationship between each business module and each test case information in the target branch; The compilation unit is used to jointly compile the code to be merged and the target test code corresponding to the target test case information to obtain the target binary file. The target binary file is used to upload to the target power switch, and the target power switch is used to run the target binary file in response to the target test command and generate the target test results. The verification unit is used to verify the target test results and obtain the target verification results; the target verification results include the execution success rate and code coverage. The processing unit is configured to allow the code to be merged into the code corresponding to the target business module if the execution success rate is greater than or equal to a first threshold and the code coverage is greater than or equal to a second threshold. The processing unit is also used to reject the code to be merged into the target business module if the execution success rate is less than the first threshold or the code coverage is less than the second threshold.
[0014] Thirdly, embodiments of this application provide a control device, including a processor and a memory, wherein the memory is used to store programs, instructions or code, and the processor is used to execute the programs, instructions or code in the memory to perform the code processing method as described in the first aspect.
[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which is loaded by a processor to execute the code processing method as described in the first aspect.
[0016] Beneficial effects: In this embodiment, in response to a code merging request, the system determines the target test case information corresponding to the target business module based on a preset test mapping table. Then, it jointly compiles the code to be merged and the target test code corresponding to the target test case information to obtain a target binary file. The system further verifies the target test results to obtain target verification results. If the execution success rate is greater than or equal to a first threshold, and the code coverage is greater than or equal to a second threshold, then the code to be merged is allowed to be merged into the code corresponding to the target business module. If the execution success rate is less than the first threshold, or the code coverage is less than the second threshold, then the code to be merged into the target business module is rejected.
[0017] The code merge request represents a request to modify the code of the target business module in the target branch, and the code merge request includes the code to be merged; the preset test mapping table represents the mapping relationship between each business module in the target branch and each test case information; the target binary file is used to upload to the target power switch, the target power switch is used to run the target binary file in response to the target test instructions, and generate the target test results; the target verification results include execution success rate and code coverage.
[0018] Thus, by compiling, testing, and verifying the code to be merged according to the testing granularity of the business module, the code quality during code merging is improved to a certain extent. Furthermore, the entire testing process in this embodiment is implemented through automated testing, thereby improving testing efficiency. Attached Figure Description
[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0020] Figure 1 A flowchart illustrating a code processing method provided in an embodiment of this application; Figure 2 A flowchart illustrating a code processing procedure provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a code processing device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a control device provided in an embodiment of this application. Detailed Implementation
[0021] As described above, in related technologies, code merging management solutions can be divided into two methods as illustrated in the following examples. However, both of these solutions have shortcomings and cannot meet the quality and efficiency requirements of code merging.
[0022] As an example, while unit testing processes exist in related technologies, they lack a complete process control mechanism. During development, after completing code development, developers need to write simple unit test cases themselves. Due to the lack of unified standards and specifications, the quality of test cases written by developers varies greatly, making it difficult to ensure that the unit test code fully covers all functions and branches. This results in some code logic not being adequately tested, and potential defects not being discovered in a timely manner, creating hidden dangers for subsequent software operation. For example, code branches under certain boundary conditions may not be covered by test cases, leading to errors when encountering specific inputs during actual operation, affecting the normal function of the power switch.
[0023] Furthermore, there is no robust process in place during the code merging testing phase to ensure the completeness of unit test execution. Specifically, the execution of unit tests relies entirely on the subjective actions of developers, lacking effective supervision and constraint mechanisms. This can lead to situations where test cases are missed; for example, developers may neglect to execute some test cases due to negligence or rushing to complete the merge. This approach fails to guarantee the quality of unit test execution, further compromising code robustness and ultimately impacting the reliability of the power switch software.
[0024] As another example, the unit testing process present in related technologies is not implemented in actual applications; integration testing is generally used instead. In actual R&D, although project documentation clearly includes requirements for unit testing, developers may skip the unit testing phase altogether to shorten the development cycle, choosing to perform integration tests only after integrating multiple modules. However, this approach results in a lack of independent testing and verification for individual modules before integration, making it impossible to discover and fix code defects within modules at an early stage.
[0025] Furthermore, the code integration testing relies solely on the results of integration tests, failing to precisely verify the core functions and boundary scenarios of individual modules. In other words, integration tests primarily focus on the interactions between modules and the overall functionality, making it difficult to comprehensively cover the detailed issues within individual modules. Due to this lack of precise testing for individual modules, when integration tests discover problems, it's difficult to quickly pinpoint the specific module with the defect, resulting in a broad investigation scope and low efficiency in localization. This not only increases development costs and time but also easily leads to defects being carried over to subsequent stages.
[0026] Based on this, embodiments of this application provide a code processing method, apparatus, and related products. The method includes: responding to an acquired code merging request, determining target test case information corresponding to a target business module based on a preset test mapping table; then jointly compiling the code to be merged and the target test code corresponding to the target test case information to obtain a target binary file; further verifying the target test results to obtain a target verification result; if the execution success rate is greater than or equal to a first threshold, and the code coverage is greater than or equal to a second threshold, then allowing the code to be merged into the code corresponding to the target business module; if the execution success rate is less than the first threshold, or the code coverage is less than the second threshold, then rejecting the merging of the code to be merged into the target business module.
[0027] The code merge request represents a request to modify the code of the target business module in the target branch, and the code merge request includes the code to be merged; the preset test mapping table represents the mapping relationship between each business module in the target branch and each test case information; the target binary file is used to upload to the target power switch, the target power switch is used to run the target binary file in response to the target test instructions, and generate the target test results; the target verification results include execution success rate and code coverage.
[0028] Thus, by compiling, testing, and verifying the code to be merged according to the testing granularity of the business module, the code quality during code merging is improved to a certain extent. Furthermore, the entire testing process in this embodiment is implemented through automated testing, thereby improving testing efficiency.
[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.
[0030] The collection and processing of relevant data (including but not limited to experimental data, test data, simulation data, user data, etc.) involved in this application shall strictly comply with the requirements of national laws and regulations when applied in the following embodiments, obtain the informed consent or separate consent of the subject obtaining the data information, and carry out data use and processing within the scope of laws and regulations and the authorization of the subject.
[0031] See Figure 1 The figure is a flowchart illustrating a code processing method provided in an embodiment of this application.
[0032] Combination Figure 1 As shown, the code processing method provided in this application embodiment may include: S11: Get the code merge request.
[0033] A code merge request represents a request to modify the code of a target business module in the target branch. For example, a code merge request can merge code from a feature branch or temporary branch into the target branch. The code to be merged is the code that modifies the target business module.
[0034] A code merge request can include code to be merged. Code to be merged refers to code changes in a feature branch or bug fix branch that need to be merged into the target branch, such as adding new features, bug fixes, etc., without specific limitations.
[0035] The target branch refers to the branch containing the target business module whose code has been modified. For example, the target branch can be the main branch, the development branch, or a branch within the development branch; no specific limitation is made here. In one possible implementation, the target branch can include multiple modules, and each module can include one or more business modules; no specific limitation is made here either.
[0036] The main branch (such as main or master) is a branch used to store stable, releasable code.
[0037] A development branch (e.g., develop) is a branch used to integrate all features under development; it is the main branch in the development process.
[0038] Sub-branches (also called nested branches) in a development branch refer to temporary branches created based on the develop branch, used to implement specific functions, fix problems, or conduct experimental development.
[0039] In one possible implementation, step S11 may include: A1: Create a feature branch or a fix branch.
[0040] A feature branch is a branch used to develop new features (such as a user login module). It can generally be created based on the main branch or the development branch, without any specific restrictions here.
[0041] A hotfix branch is a branch used to urgently fix production environment issues (such as security vulnerabilities). It can generally be created based on the main branch or the development branch, without any specific restrictions here.
[0042] It should be understood that by creating independent feature branches or fix branches, multiple developers can work independently on different branches, avoiding mutual interference. At the same time, by creating independent feature branches or fix branches, problematic code can only affect the current branch, avoiding impact on the main branch or other branches, thus improving the stability and reliability of the code.
[0043] A2: Modify the code of the target business module according to the functional branch or the repair branch, and update the target test cases corresponding to the target business module in sync.
[0044] The target business module refers to the code functional unit to be modified, such as the user authentication module, data storage module, etc., without specific limitations.
[0045] Target test cases refer to test scripts associated with the target business module, such as files with the ".cpp" extension.
[0046] It should be understood that by updating the target test cases synchronously, it is possible to ensure that code modifications and test coverage are synchronized, avoiding test omissions or failures; at the same time, updating existing test cases can prevent code changes from breaking the original functionality.
[0047] A3: Send the modified code to be merged to the remote feature branch.
[0048] Remote feature branches refer to branches stored in a remote repository, such as origin / feature / login, etc. A remote feature branch can be understood as a temporary code storage area or "transfer station" used for interaction with the target branch. It should be understood that by sending the modified code to be merged to a remote feature branch, code backup can be achieved to prevent code loss. On the other hand, other developers can pull the remote feature branch for viewing or development, improving the efficiency of code merging. At the same time, it can also automatically trigger CI pipeline operations, such as compilation and testing, to achieve continuous integration.
[0049] A4: Generate and send a code merge request to the target branch via a remote feature branch.
[0050] It should be understood that sending a code merge request to the target branch via a remote feature branch allows for the preservation of records of code changes and processing, thus meeting regulatory requirements.
[0051] The target business module refers to the business module corresponding to the code to be merged included in the code merging request. In this application embodiment, there can be one or more target business modules, which is not specifically limited here. This application embodiment takes one target business module as an example for illustration. The processing flow of other target business modules is the same as the code processing method provided in this application embodiment, so it will not be described again.
[0052] One possible implementation also includes determining the target business module in the following way: B1: Retrieves the target branch code corresponding to the target branch.
[0053] The target branch code refers to the complete set of code currently stored in the target branch, including all business modules and configuration files.
[0054] It should be understood that by obtaining the complete code baseline of the target branch, it can serve as a benchmark for subsequent comparison of changes. This ensures that change analysis is based on the latest code and avoids omissions or misjudgments due to branch lag.
[0055] B2: Determine the path to the change files based on the code to be merged and the target branch code.
[0056] Changing file paths refers to the list of file paths relative to the project root directory corresponding to the target branch.
[0057] It should be understood that by comparing the code to be merged with the target branch code, the path of the changed files in this change can be determined, so as to identify the target business module involved in this code merge, avoid interference from irrelevant files, and improve the efficiency of code merging. At the same time, automatically extracting the path through scripts or tools can reduce human error.
[0058] B3: Determine the target business module based on the changed file path and the preset test mapping table.
[0059] It should be understood that by determining the target business module based on the changed file path and the preset test mapping table, the mapping relationship between the file path and the business module can be maintained independently, thus avoiding hard-coding in the code; at the same time, when adding a new business module, only the preset test mapping table needs to be updated, without modifying the matching logic; in addition, only the test cases of the affected module are run, reducing test execution time. For example, when the payment module changes, the user module test is not run.
[0060] It should be understood that, in this embodiment of the application, initiating a code merge request through a standardized request process can make code changes traceable and recordable, avoid the code chaos caused by arbitrary merging, and improve the accuracy and reliability of code merging.
[0061] S12: In response to the code merge request, determine the target test case information corresponding to the target business module based on the preset test mapping table.
[0062] The pre-defined test mapping table refers to a predefined table that represents the mapping relationship between each business module and each test case information in the target branch.
[0063] Target test case information refers to the information required for subsequent testing of the code to be merged. In one possible implementation, target test case information may include, but is not limited to, information required for executing tests, such as the test suite name (e.g., ProductParseTest), test case file path, test case file, test case code, and dependent environment. No specific limitations are made here.
[0064] It should be understood that, in the embodiments of this application, the target test cases corresponding to the target business module can be quickly matched by a preset mapping table, which can reduce configuration errors and improve the accuracy and reliability of code integration.
[0065] In one possible implementation, prior to step S12, the following may also be included: C1: Determine if the target branch contains the target test case file and target parameter file corresponding to the target business module.
[0066] Test case files refer to scripts or configuration files that store test cases for a module, such as . / test / product_parse_test.cpp, etc.
[0067] Parameter files refer to the input data or environment configuration required for test cases, such as test_data.csv, env_config.yaml, etc.
[0068] It should be understood that by making the presence of target test case files or target parameter files in the target branch a prerequisite for continuing to obtain target test case information, problems such as test execution failure or omission of key scenarios due to missing files can be avoided. At the same time, test environment issues can be discovered before code is merged, reducing blockages in subsequent processes.
[0069] C2: If the target branch contains a target test case file and a target parameter file, then the target test case information will be matched according to the preset test mapping table.
[0070] It should be understood that if the target test case file and target parameter file exist in the target branch, it means that the files required for testing are complete. At this time, the target test case information can be determined to facilitate subsequent testing steps.
[0071] C3: If the target test case file or target parameter file does not exist in the target branch, the code to be merged into the target business module will be rejected, and an alarm message will be generated.
[0072] It should be understood that by making the integrity of the files required for testing a necessary condition for merging, "code without test coverage" is prevented from entering the target branch; at the same time, alert information can directly point to the root cause of the problem, reducing the investigation time for developers.
[0073] S13: Compile the target test code corresponding to the code to be merged and the target test case information together to obtain the target binary file.
[0074] The target binary file is used to upload to the target power switch, and the target power switch is used to run the target binary file in response to the target test command and generate the target test results.
[0075] The target binary file refers to the compiled executable file, which may include, but is not limited to, business logic and test logic, and is used to run tests on the target device.
[0076] Joint compilation refers to the process of combining the code to be incorporated and the target test code into a single executable file.
[0077] It should be understood that, in the application embodiments, by compiling the code to be merged together with the test code corresponding to the target test case to generate an executable binary file, it can be ensured that the code to be merged is compatible with the test environment and generate a binary file that can run on the target hardware (such as a power switch).
[0078] In one possible implementation, the target test results may also be obtained through the following methods: D1: Establish a connection with the target power switch via the target protocol.
[0079] The target protocol refers to the communication protocol supported by the target power switch. The target power switch refers to the embedded device under test, which typically has a network interface and specific protocol support, and is used for data exchange or control in power systems.
[0080] It should be understood that establishing a connection with the target power switch through the target protocol ensures compatibility and avoids connection failures due to protocol incompatibility.
[0081] D2: Verify the test environment of the target power switch and obtain the environment verification results.
[0082] The test environment refers to the set of conditions required to perform a test, such as the device status, software version, and network configuration.
[0083] The environment verification result refers to a Boolean value or structured data, indicating whether the environment meets the test requirements, for example, {"passed": True, "message": "OK"}.
[0084] It should be understood that by validating the test environment, it is possible to avoid performing tests in abnormal environments (such as equipment maintenance mode) and reduce invalid results.
[0085] D3: If the environment verification result is satisfactory, initialize the test environment, run the target binary file in response to the target test command, and generate the target test result.
[0086] Initializing the test environment means restoring the device to a known state to ensure that the test is repeatable (e.g., resetting the configuration before each test).
[0087] The target test command refers to the command or signal that triggers the device to perform a test.
[0088] The target test result refers to the output of the test execution, such as pass or fail, performance data, error logs, etc., without being specifically limited here.
[0089] It should be understood that by automating and precisely controlling the testing process (such as initialization, execution, and result collection), human error can be reduced; at the same time, since the target test results can include detailed test data, it is easier to reproduce and analyze problems.
[0090] S14: Verify the target test results to obtain the target verification results.
[0091] The target validation results include execution success rate and code coverage. Execution success rate refers to the percentage of target test cases that pass, reflecting the correctness of the code's functionality; code coverage refers to the degree to which test cases cover the code, which can include both function and line-by-line dimensions.
[0092] It should be understood that, in the embodiments of this application, the target binary file can be uploaded to the target power switch, tests can be run and results (such as pass / fail logs, code coverage data) can be collected, and code quality can be quantified through data to avoid subjective judgment; at the same time, since there may be untested logic in low coverage areas, the required supplementary test cases can be located through testing.
[0093] S15: If the execution success rate is greater than or equal to the first threshold, and the code coverage is greater than or equal to the second threshold, then the code to be merged is allowed to be merged into the code corresponding to the target business module.
[0094] The first threshold refers to the minimum success rate (e.g., 90%) to ensure that the function is basically correct.
[0095] The second threshold refers to the minimum code coverage (such as 80% function coverage or 70% line coverage) to ensure sufficient testing.
[0096] It should be understood that ensuring code quality through dual metrics and preventing low-quality code from being merged into the target branch means improving code stability by mandating that test pass rate and coverage meet the standards.
[0097] As an example, suppose the thresholds are set to an execution success rate ≥ 90%, function coverage ≥ 80%, and line coverage ≥ 70%; if the target validation result is an execution success rate of 95% (pass), a function coverage of 80% (pass), and a line coverage of 75% (pass), then merging is allowed.
[0098] S16: If the execution success rate is less than the first threshold, or the code coverage is less than the second threshold, then the code to be merged into the target business module will be rejected.
[0099] As an example, suppose the thresholds are set to an execution success rate of ≥90%, function coverage of ≥80%, and line coverage of ≥70%; if the target validation result is an execution success rate of 85% (not met), then the merge is rejected.
[0100] It should be understood that rejection can be triggered if either the execution success rate is less than the first threshold or the code coverage is less than the second threshold. This is to intercept low-quality code and prevent the problem from spreading to the production environment. In this way, problematic code can be detected and stopped at an early stage, reducing the cost of later repairs and improving the quality and efficiency of code merging.
[0101] It should be understood that, in the embodiments of this application, by compiling, testing and verifying the code to be merged according to the testing granularity of the business module, the code quality during code merging is improved to a certain extent. Furthermore, the entire testing process in the embodiments of this application is implemented through automated testing, thereby improving testing efficiency.
[0102] Based on the code processing method provided in the above embodiments, in one possible implementation, code coverage can also be determined in the following way: E1: Determine the total number of functions, the number of functions that were successfully executed, the total number of function lines, and the number of function lines that were successfully executed for the target business module based on the target test results.
[0103] A function refers to a function that is called during testing and returns normally.
[0104] Function lines refer to lines of code (such as if statements, assignment operations, etc.) that are executed during testing.
[0105] The total number of functions refers to the total number of functions in the target business module.
[0106] The number of functions that execute successfully refers to the number of functions that are actually called during the test.
[0107] The total number of function lines refers to the total number of all lines of code in the target business module (which may include blank lines, comment lines, or only count valid lines).
[0108] The number of lines of code that were successfully executed refers to the number of lines of code that were actually executed during the test.
[0109] E2: Determine the first coverage rate based on the total number of functions and the number of functions that were successfully executed.
[0110] It should be understood that the ratio of the number of successfully executed functions to the total number of functions can be used to determine the initial coverage rate. This serves to measure the extent to which tests cover the functions within a business module, reflecting "how many functions have been tested." Thus, if the function coverage rate is low (e.g., 60%), it's possible to directly check whether uncovered functions (e.g., disable_port()) require additional test cases. Furthermore, this is suitable for evaluating the overall test completeness of a business module; for example, the function coverage rate for the "port management module" should reach over 90% before release.
[0111] E3: Determine the second coverage based on the total number of function lines and the number of function lines that were successfully executed.
[0112] It should be understood that the second coverage rate can be determined by the ratio of the number of successfully executed function lines to the total number of function lines. This measure assesses the extent to which tests cover lines of code, reflecting "how many lines of code were executed," and is more granular than function coverage. This allows for the identification of uncovered code paths; furthermore, by analyzing line coverage differences (e.g., a function line coverage rate of only 50%), test cases can be designed specifically to cover the unexecuted lines.
[0113] E4: Use the first and second coverage rates as code coverage.
[0114] It should be understood that function coverage reflects overall coverage, while row coverage reflects detailed coverage; combining the two avoids the limitations of a single metric.
[0115] In one possible implementation, the second threshold includes a first preset value and a second preset value. If the execution success rate is greater than or equal to the first threshold, and the first coverage rate is greater than or equal to the first preset value, and the second coverage rate is greater than or equal to the second preset value, then the code to be merged is allowed to be merged into the code corresponding to the target business module. If the execution success rate is less than the first threshold, or the first coverage rate is less than the first preset value, or the second coverage rate is less than the second preset value, then the code to be merged is rejected from being merged into the target business module.
[0116] It should be understood that code quality is ensured through two-dimensional test metrics (first preset value and second preset value), and low-quality code is prevented from being merged into the target branch. In other words, code stability is improved by forcibly requiring coverage to meet the standard.
[0117] Based on the code processing method provided in the above embodiments, in one possible implementation, combined with... Figure 2 As shown in the embodiments of this application, a code processing flow is also provided, which can be divided into two parts: precondition configuration and core execution flow. The code processing flow provided in the embodiments of this application can be implemented based on Gtest and CI / CD power switches.
[0118] Gtest refers to a C++ unit testing framework for code development.
[0119] CI (Continuous Integration) refers to developers continuously merging code into the main branch, with each merge automatically triggering builds and tests (such as compilation, unit tests, and static analysis) to ensure code quality.
[0120] CD stands for Continuous Delivery / Deployment. Continuous Delivery means that code can be manually deployed to the production environment at any time through CI. Continuous Deployment means that code is automatically deployed to the production environment after passing all tests, without manual intervention.
[0121] Prerequisite configurations can include Git repository configuration, Gtest test case configuration, and CI / CD pipeline configuration.
[0122] (1) Git repository configuration: Deploy a Git server (or use GitLab / GitHub hosting platform), create a dedicated code repository for the power switch, divide it into modules according to business functions (such as product parsing module, port module, image module, etc.), and store the business code of each module and the corresponding Gtest unit test case code; at the same time, create and store a "module-test case" mapping table (JSON format), as shown in the example below: Code block: { "module_list (module list)": [ { "module_id (unique module identifier)": "001", "module_name (module name)": "product (product)", "business_files (business code)": [". / src / product_parse.c", ". / src / protocol_parse.h"], "test_suite": "ProductParseTest", "test_files (test case files)": [". / test / product_parse_test.cpp"] }, { "module_id": "002", "module_name": "port", "business_files": [". / src / port.c", ". / src / port.h"], "test_suite": "PortTest", "test_files": [". / test / port_test.cpp"] } ] } The branch protection policy is configured to prohibit direct commits to the development branch (develop) and only allow merge requests from feature branches / fix branches.
[0123] (2) Gtest test case configuration: Based on the Gtest framework, write unit test cases by module, and encapsulate the test cases of each module into an independent test suite (such as ProductParseTest and PortTest in the example above); for each business function, cover normal scenarios, abnormal scenarios, and boundary scenarios to ensure test sufficiency; and submit the test case code and business code to the Git repository simultaneously. Among them, Gtest test cases can be automatically generated according to the .c file corresponding to the business function.
[0124] (3) CI / CD pipeline configuration: Build a CI / CD platform (such as Jenkins, GitLab CI), and install necessary tools: Git diff code difference analysis tool, gcc compiler, gcov / lcov coverage statistics tool, SSH remote connection tool (MobaXterm); write pipeline configuration scripts (such as Jenkinsfile, .gitlab-ci.yml), configure the "code merge request triggers pipeline" rule, and realize the linkage between the pipeline and Git repository and power switch.
[0125] Based on the aforementioned prerequisite configuration, the core execution flow of this application embodiment may include: Step 1: Submit the code to be merged and initiate the code merge request.
[0126] As an example, in this application embodiment, a feature branch or a bugfix branch can be created based on an existing development branch (develop) specifically for developing a particular function or fixing bugs.
[0127] It should be understood that after modifying the business code of the target business module on a feature branch or fix branch, the corresponding Gtest unit test cases need to be updated synchronously. Specifically, if the code to be merged represents a new feature, new test cases need to be added; if the code to be merged represents modified logic, existing test cases need to be changed.
[0128] After completing the code modification and test case synchronization changes, you can use Git commands to submit the code to be merged to the remote feature branch, and initiate a code merge request (MR / PR) to the development branch (the main branch in the case of bug fixing) on the Git platform (such as GitLab).
[0129] It should be understood that by mandating that test cases be changed in sync with business code, "merging code without test coverage" is avoided, which is in line with the principles of Test-Driven Development (TDD). At the same time, by isolating changes in feature branches or fix branches, the risk of directly manipulating the main branch is reduced.
[0130] Step 2: Modify the module for automatic recognition.
[0131] As an example, in this embodiment of the application, when the CI / CD pipeline is triggered, the code to be merged into the target feature branch (i.e., feature branch or fix branch) and the target branch code of the target integration branch (i.e., target branch, such as development branch) are first pulled; then the Gitdiff tool can be used to compare these two parts of code to determine the path of the changed file for this change; further, the preset "module-test case" mapping relationship table (i.e., preset test mapping table) in the Git repository is read, and by comparing the changed file path and the "business_files" field in the preset test mapping table, the business module (i.e., target business module) corresponding to this code modification is determined.
[0132] If multiple files are modified and belong to different modules, all associated target business modules need to be identified. If a target business module does not exist in the target integration branch, it is determined that the target business module is a newly added module. The new module unit test verification process can be started to check whether there is a corresponding Gtest unit test case file in the functional branch and whether there is a relevant record in the mapping relationship table. If the check fails, the pipeline terminates and a prompt (i.e., an alarm message) is sent. If it passes or no new module is added, the subsequent steps continue.
[0133] It should be understood that due to the limited resources (such as memory and storage space) of the embedded environment of the power switch, full testing may take too long or be impossible to run. Therefore, by identifying the module type, only the changed parts are tested to shorten the pipeline execution time.
[0134] Step 3: Incremental test case matching and compilation with coverage.
[0135] As an example, in this embodiment of the application, when the pipeline is based on the identified target business module, it can match the corresponding target test case information from the "module-test case" mapping table. The target test case information includes the test suite name (such as ProductParseTest) and the test case file path. The compilation script is then called to configure the code coverage option of the gcc compiler (-fprofile-arcs-ftest-coverage) and jointly compile the business code of the target business module (i.e. the code to be merged) and the matched Gtest test case code (target test code).
[0136] If syntax errors or missing dependencies occur during compilation, the pipeline will immediately terminate, upload the compilation error log to the Git merge request page, refuse code merging, and notify the developers via email / message. If compilation is successful, a bin file that can run on the power switch, a gcno file (which stores code structure information during the compilation phase) required for code coverage statistics will be generated, and the compilation log will be saved.
[0137] It should be understood that if compilation fails (e.g., syntax errors, missing dependencies), the pipeline will immediately terminate and upload logs to the Git platform, allowing developers to quickly fix the problem and prevent it from being left over to the testing phase (e.g., if the hardware driver library libhardware.so is not correctly linked in a power switch, compilation will fail, and the pipeline will clearly indicate the missing dependency).
[0138] Step 4: Automatic loading of bin files and environment initialization.
[0139] As an example, in this embodiment of the application, the pipeline can establish a secure connection with the power switch via the SSH protocol and perform the following operations: F1: Test environment check.
[0140] Verify the power switch's remaining storage space (to meet the deployment requirements of the bin file), running memory, system version, and compatibility with the bin file.
[0141] F2: If the test environment check fails, terminate the pipeline, record the abnormal environment information (such as "less than 25MB of remaining storage space") and provide feedback, and refuse to merge the code.
[0142] F3: If the test environment check passes, upload the compiled bin file to the specified running directory of the power switch (e.g., / data / test / ), execute the chmod+x command to configure the execution permissions of the configuration file, and initialize the running environment (e.g., load the dependent dynamic library libgtest.so, perform basic switch initialization, etc.).
[0143] It should be understood that by automating the execution of test environment checks, initialization, and operation, configuration differences inherent in manual deployment are avoided, ensuring environmental consistency for each test. Simultaneously, test environment checks (such as remaining storage space) prevent test interruptions or device crashes due to insufficient resources (e.g., insufficient storage space on a power switch may affect real-time data logging).
[0144] Step 5: Automatic execution and result collection of incremental Gtest unit tests (i.e., target test results).
[0145] As an example, in this embodiment, the pipeline can trigger the execution of the bin file (i.e., the target binary file) in the power switch via remote commands, and use the gtest_filter parameter of Gtest to implement incremental test case execution. The filtering rules are generated based on the matched test suite names. An example command is as follows: . / data / test / ProductParse_test.bin --gtest_filter=ProductParseTest. --gtest_output=xml:test_result.xml The above command only executes all test cases under the test suite (ProductParseTest) corresponding to the "Product Parse Module"; if there are multiple target business modules, the test suite name is concatenated by "|" (e.g., --gtest_filter=ProductParseTest). |PortTest. ).
[0146] The pipeline uses the SCP tool to pull the test_result.xml test result file (i.e., the target test result) generated on the power switch. The test result file may include, but is not limited to, detailed information such as the total number of test cases executed, the number of passes, the number of failures, the error stack of failed test cases, and the execution steps.
[0147] Step 6: Unit test result verification (i.e., determining the target verification result).
[0148] As an example, in this embodiment of the application, the pipeline performs automated verification of the parsed test results: if all matched Gtest unit test cases are executed successfully (pass rate 100%), the next step of coverage verification process is initiated; if any test case fails or times out, the pipeline terminates, uploads a test failure report (including the name of the failed test case, the reason for the error, and the execution log) to the Git merge request page, rejects the code merge, and notifies the developers to locate and modify it.
[0149] Step 7: Calculate the code coverage of the target business module.
[0150] As an example, in an embodiment of this application, the pipeline can use the SCP tool to pull the gcda file (which stores code execution information during the test execution phase) generated after the unit test runs from the power switch.
[0151] This can be done by placing the file in the same directory as the locally generated gcno file, calling the gcov tool to perform coverage calculations, and only counting the coverage data of the business code of the target business module; then, the genhtml tool is used to generate a visual coverage report (HTML format), which clearly marks the list of uncovered functions, line numbers and corresponding code snippets.
[0152] Step 8: Coverage compliance verification.
[0153] As an example, in this embodiment, the pipeline extracts coverage data from the visualization report and verifies it according to preset thresholds (function coverage 100%, line coverage ≥90%). If the coverage of the target business module meets both thresholds, the pipeline determines that the coverage is up to standard, automatically merges the function branch and the target integration branch through GitLab API, completes the code merge, and generates a merge success report (including test results and coverage data). If no threshold is met, the pipeline terminates, uploads the coverage report (including uncovered gap data) to the Git merge request page, rejects the code merge, records the reason for non-compliance (e.g., "Product parsing module line coverage 85%, details of uncovered code"), and provides feedback to the developers to supplement test cases.
[0154] Step 9: Process log archiving and feedback.
[0155] As an example, in this embodiment of the application, the pipeline can archive the complete logs and result reports of the entire verification process (target business module identification, compilation, deployment, incremental testing, coverage verification) to the CI / CD platform server, and at the same time notify developers and reviewers to merge the results via email / platform message, ensuring that relevant personnel keep abreast of the progress.
[0156] It should be understood that this application embodiment incorporates unit testing into the critical stages of CI / CD and sets key assessment parameters such as 100% function coverage and ≥90% function line coverage to measure the success of unit testing, thereby achieving quantifiable quality assessment standards and improving the quality of code merging. Simultaneously, this application embodiment also achieves automatic identification of modified modules, automatic compilation of Gtest test code, automatic execution of module test cases, automatic verification of results, and automatic feedback of execution results by automatically binding the functional module names of the power switch with the unit test suite names of Gtest. This realizes a fully automated processing flow from development and testing to review, improving the efficiency of development and review.
[0157] Based on the code processing method provided in the above embodiments, see [link to relevant documentation]. Figure 3 This application also provides a schematic diagram of the structure of a code processing device.
[0158] Combination Figure 3 As shown, the code processing apparatus 30 provided in this application embodiment includes: The acquisition unit 31 is used to acquire code merging requests; wherein, the code merging request represents a request to modify the code of the target business module in the target branch, and the code merging request includes the code to be merged; The determination unit 32 is used to determine the target test case information corresponding to the target business module based on the preset test mapping table in response to the code merging request; wherein, the preset test mapping table represents the mapping relationship between each business module and each test case information in the target branch; Compilation unit 33 is used to jointly compile the code to be merged and the target test code corresponding to the target test case information to obtain the target binary file; wherein, the target binary file is used to upload to the target power switch, and the target power switch is used to run the target binary file in response to the target test command and generate the target test results; Verification unit 34 is used to verify the target test results and obtain the target verification results; wherein, the target verification results include execution success rate and code coverage. The processing unit 35 is configured to allow the code to be merged into the code corresponding to the target business module if the execution success rate is greater than or equal to the first threshold and the code coverage is greater than or equal to the second threshold. The processing unit 35 is also used to refuse to merge the code to be merged into the target business module if the execution success rate is less than the first threshold or the code coverage is less than the second threshold.
[0159] In one possible implementation, a module determination unit is also included, used to determine the target business module in the following ways: Retrieve the target branch code corresponding to the target branch; Determine the path to the changed files based on the code to be merged and the target branch code; The target business module is determined based on the changed file path and the preset test mapping table.
[0160] In one possible implementation, prior to determining unit 32, a judgment unit is further included, for: Determine whether the target branch contains the target test case file and target parameter file corresponding to the target business module; If the target branch contains a target test case file and a target parameter file, the target test case information will be matched according to the preset test mapping table. If the target test case file or target parameter file does not exist in the target branch, the code to be merged into the target business module will be rejected, and an alarm message will be generated.
[0161] In one possible implementation, a test result generation unit is also included, used for: Establish a connection with the target power switch via the target protocol; The test environment of the target power switch is verified, and the environmental verification results are obtained. If the environment verification result is satisfactory, the test environment is initialized, and the target binary file is run in response to the target test command, and the target test result is generated.
[0162] In one possible implementation, a code coverage determination unit is also included, which determines code coverage in the following ways: Based on the target test results, determine the total number of functions, the number of functions that were successfully executed, the total number of function lines, and the number of function lines that were successfully executed for the target business module. The first coverage rate is determined based on the total number of functions and the number of functions that were successfully executed. The second coverage ratio is determined based on the total number of function lines and the number of function lines that were successfully executed. Use the first and second coverage rates as code coverage.
[0163] In one possible implementation, the second threshold includes a first preset value and a second preset value, and the processing unit 35 is further configured to: If the execution success rate is greater than or equal to the first threshold, and the first coverage rate is greater than or equal to the first preset value, and the second coverage rate is greater than or equal to the second preset value, then the code to be merged is allowed to be merged into the code corresponding to the target business module. If the execution success rate is less than the first threshold, or the first coverage rate is less than the first preset value, or the second coverage rate is less than the second preset value, then the code to be merged into the target business module will be rejected.
[0164] In one possible implementation, the acquisition unit 31 is used for: Create a feature branch or a fix branch; Modify the code of the target business module according to the functional branch or the fix branch, and update the target test cases corresponding to the target business module in a synchronous manner; Send the modified code to be merged to the remote feature branch; Generate and send a code merge request to the target branch via a remote feature branch.
[0165] One possible implementation also includes: a module type identification unit. If the target business module does not exist in the target branch, then the module type of the target business module is determined to be a new module; If the target business module exists in the target branch, then the module type of the target business module is determined to be a modification module.
[0166] It should be noted that the code processing apparatus provided in this application embodiment has the same beneficial effects as the code processing method provided in the above embodiments, and therefore will not be described again.
[0167] In one possible implementation, see Figure 4 The figure is a schematic diagram of a control device provided in an embodiment of this application.
[0168] The control device may include a memory 411 and a processor 412. For example... Figure 4 As shown, the memory can be random access memory (RAM), flash memory, read-only memory (ROM), EPROM, non-volatile read-only memory (Electronic Programmable ROM), registers, hard disks, removable disks, etc.
[0169] The memory 411 can store computer instructions. When the computer instructions stored in the memory 411 are executed by the processor 412, the processor 412 can use them to execute code processing methods. The memory 411 can also store data.
[0170] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape) or a semiconductor medium (e.g., solid-state disk (SSD)).
[0171] This application also provides a readable storage medium for storing the methods provided in the above embodiments. Examples include random access memory (RAM), flash memory, read-only memory (ROM), EPROM, non-volatile read-only memory (EPROM), registers, hard disks, removable disks, or any other form of storage medium in the art.
[0172] In the embodiments of this application, the terms "first" and "second" (if they exist) are used only as name identifiers and do not represent the order of first and second.
[0173] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. Regarding the methods disclosed in the embodiments, since they correspond to the product embodiments disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the description of the product embodiments.
[0174] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A code processing method, characterized in that, The method includes: Obtain a code merge request; wherein, the code merge request represents a request to modify the code of a target business module in the target branch, and the code merge request includes the code to be merged; In response to the code merging request, target test case information corresponding to the target business module is determined based on a preset test mapping table; wherein, the preset test mapping table represents the mapping relationship between each business module and each test case information in the target branch; The code to be merged and the target test code corresponding to the target test case information are jointly compiled to obtain a target binary file; wherein, the target binary file is used to upload to the target power switch, and the target power switch is used to run the target binary file in response to the target test command and generate the target test result; The target test results are verified to obtain target verification results; wherein, the target verification results include execution success rate and code coverage. If the execution success rate is greater than or equal to the first threshold, and the code coverage is greater than or equal to the second threshold, then the code to be merged is allowed to be merged into the code corresponding to the target business module. If the execution success rate is less than the first threshold, or the code coverage is less than the second threshold, then the code to be merged into the target business module is rejected.
2. The code processing method according to claim 1, characterized in that, This also includes determining the target business module in the following ways: Obtain the target branch code corresponding to the target branch; Based on the code to be merged and the target branch code, determine the path to the changed file; The target business module is determined based on the changed file path and the preset test mapping table.
3. The code processing method according to claim 1, characterized in that, Before determining the target test case information corresponding to the target business module based on the preset test mapping table, the method further includes: Determine whether the target branch contains the target test case file and target parameter file corresponding to the target business module; If the target test case file and the target parameter file exist in the target branch, then the target test case information is matched according to the preset test mapping table; If the target test case file or the target parameter file does not exist in the target branch, the code to be merged into the target business module will be rejected, and an alarm message will be generated.
4. The code processing method according to claim 1, characterized in that, This also includes obtaining the target test results through the following methods: Establish a connection with the target power switch via the target protocol; The test environment of the target power switch is verified, and the environment verification results are obtained. If the environment verification result is satisfactory, the test environment is initialized, and the target binary file is run in response to the target test instruction, and the target test result is generated.
5. The code processing method according to claim 1, characterized in that, This also includes determining the code coverage in the following ways: Based on the target test results, determine the total number of functions, the number of functions that were successfully executed, the total number of function lines, and the number of function lines that were successfully executed for the target business module. The first coverage rate is determined based on the total number of functions and the number of functions that were successfully executed. The second coverage rate is determined based on the total number of function lines and the number of function lines that were successfully executed. The first coverage and the second coverage are used as the code coverage.
6. The code processing method according to claim 5, characterized in that, The second threshold includes a first preset value and a second preset value. If the execution success rate is greater than or equal to the first threshold, and the first coverage rate is greater than or equal to the first preset value, and the second coverage rate is greater than or equal to the second preset value, then the code to be merged is allowed to be merged into the code corresponding to the target business module. If the execution success rate is less than the first threshold, or the first coverage rate is less than the first preset value, or the second coverage rate is less than the second preset value, then the code to be merged into the target business module is rejected.
7. The code processing method according to any one of claims 1-6, characterized in that, The request to obtain code merging includes: Create a feature branch or a fix branch; Modify the code of the target business module according to the functional branch or the repair branch, and update the target test cases corresponding to the target business module synchronously. Send the modified code to be merged to the remote feature branch; The code merge request is generated and sent to the target branch through the remote function branch.
8. The code processing method according to claim 2, characterized in that, Also includes: If the target business module does not exist in the target branch, then the module type of the target business module is determined to be a new module; If the target business module exists in the target branch, then the module type of the target business module is determined to be a modification module.
9. A code processing device, characterized in that, The device includes: The acquisition unit is used to acquire code merging requests; wherein the code merging request represents a request to modify the code of a target business module in the target branch, and the code merging request includes the code to be merged. A determining unit is configured to, in response to the code merging request, determine the target test case information corresponding to the target business module based on a preset test mapping table; wherein, the preset test mapping table represents the mapping relationship between each business module and each test case information in the target branch; A compilation unit is used to jointly compile the code to be merged and the target test code corresponding to the target test case information to obtain a target binary file; wherein, the target binary file is used to upload to the target power switch, and the target power switch is used to run the target binary file in response to the target test command and generate the target test result; A verification unit is used to verify the target test results to obtain target verification results; wherein, the target verification results include execution success rate and code coverage. The processing unit is configured to allow the code to be merged into the code corresponding to the target business module if the execution success rate is greater than or equal to a first threshold and the code coverage is greater than or equal to a second threshold. The processing unit is further configured to refuse to merge the code to be merged into the target business module if the execution success rate is less than the first threshold or the code coverage is less than the second threshold.
10. A computer-readable storage medium, characterized in that, The computer program is stored thereon and is loaded by a processor to execute the code processing method as described in any one of claims 1-8.