Code integration test method, device and system, electronic equipment, computer storage medium and computer program product
By implementing code integration testing methods in chip design, automating merging checks and dynamic functional testing, the problem of front-end design engineers not being able to detect code errors in a timely manner is solved, and the management reliability and merging efficiency of the code hosting end are improved.
Patent Information
- Application Number
- CN202411534519.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-30
- Publication Date
- 2026-05-01
AI Technical Summary
In the front-end development process of chip design, errors in the code submitted by front-end design engineers are not detected in a timely manner, which leads to slowdowns in the verification process and poor reliability of code hosting management.
By using code integration testing methods, we obtain push operation event feedback of updated branch code from the code hosting end, perform merging checks, and merge the main branch code when the checks pass. Then, we perform dynamic functional testing on the top-level functional modules to ensure code quality.
It improves the reliability of code management on the code hosting platform, reduces the workload of later verification, and improves the reliability and efficiency of code merging.
Smart Images
Figure CN121958074A_ABST
Abstract
Description
Code integration testing methods, apparatus and systems, electronic devices, computer storage media, and computer program products. Technical Field
[0001] This disclosure relates to the field of computer technology, and more particularly to a code integration testing method, apparatus and system, electronic device, computer storage medium, and computer program product. Background Technology
[0002] In the field of chip design, front-end design (FE) is a crucial step in translating logic design into a physical design that can be implemented on silicon. Front-end design engineers (DEs) are responsible for tasks such as logic synthesis, timing analysis, placement, and routing. These stages demand extremely high levels of detail; even a small oversight can cause the chip to malfunction or fail to meet performance standards. However, even in the highly specialized field of chip design, front-end DEs can make basic syntax or logic errors when submitting code. If these errors are not detected early, they can lead to costly rework later and even affect the chip's release date.
[0003] In the front-end development process of chip design, code integration solutions such as Continuous Integration (CI) play a crucial role. As front-end design engineers complete the branch coding of specific lower-level functional modules, the branch code is submitted to the code hosting platform for branch merging.
[0004] Since the Design Verification (DV) team is responsible for verifying the correctness of the design, when there are errors in the code submitted by the front-end design engineers, the design verification team needs to spend a lot of time identifying and correcting these problems. This not only slows down the verification process, but also reduces the reliability of the code hosting management. Summary of the Invention
[0005] In view of the above, embodiments of this disclosure provide a code integration testing method, apparatus and system, electronic device, computer storage medium, and computer program product to solve the above problems.
[0006] According to a first aspect of the present disclosure, a code integration testing method is provided, comprising: obtaining operation event feedback of a push operation of update branch code of a lower-level functional module from a code hosting terminal; performing a merge check to merge the update branch code into the main branch code of the lower-level functional module according to the operation event feedback; when the merge check result indicates that the check has passed, notifying the code hosting terminal to merge the update branch code into the main branch code; obtaining the code of the top-level functional module on which the lower-level functional module depends from the code hosting terminal, and performing dynamic functional testing on the code of the top-level functional module.
[0007] According to a second aspect of the present disclosure, a code integration testing apparatus is provided, comprising: an acquisition module for acquiring operation event feedback of a push operation of update branch code of a lower-level functional module from a code hosting terminal; an inspection module for performing a merge check to merge the update branch code into the main branch code of the lower-level functional module based on the operation event feedback; a notification module for notifying the code hosting terminal to merge the update branch code into the main branch code when the merge check result indicates that the check has passed; and a testing module for acquiring the code of the top-level functional module on which the lower-level functional module depends from the code hosting terminal, and performing dynamic functional testing on the code of the top-level functional module.
[0008] According to a third aspect of the present disclosure, a code integration testing system is provided, comprising: a code hosting terminal; and a code integration testing apparatus according to the second aspect.
[0009] According to a fourth aspect of the present disclosure, an electronic device is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; the memory is used to store at least one executable instruction, the executable instruction causing the processor to perform the method as described in the first aspect.
[0010] According to a fifth aspect of the present disclosure, a computer storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the method described in the first aspect.
[0011] According to a sixth aspect of the present disclosure, a computer program product is provided, including computer instructions that, when executed by a processor, implement the method as described in the first aspect.
[0012] In the scheme of this embodiment, the operation event feedback of the push operation on the code hosting terminal is used to trigger the merging check of the update branch code of the lower functional module to the main branch code, and the code merging is performed when the merging check passes, which improves the reliability of code management on the code hosting terminal. In addition, the code of the top functional module is obtained and dynamic functional tests are performed to verify the impact of the update branch code of the lower functional module on the top functional module, which further improves the reliability of code management after the update branch code is merged. Attached Figure Description
[0013] To more clearly illustrate the technical solutions in the embodiments or related technologies of this disclosure, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in the embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings.
[0014] Figure 1 is a schematic architecture of a code integration testing system applicable to some embodiments of this disclosure.
[0015] Figure 2 is a flowchart of the code integration testing method of some other embodiments of this disclosure.
[0016] Figure 3 is a schematic block diagram of the code integration testing system applicable to the embodiment in Figure 2.
[0017] Figure 4 is a schematic flowchart of code integration testing methods for some specific examples of the embodiments in Figure 2.
[0018] Figure 5 is a structural block diagram of a code integration testing apparatus according to some other embodiments of this disclosure.
[0019] Figure 6 is a schematic diagram of the structure of an electronic device according to some other embodiments of the present disclosure. Detailed Implementation
[0020] To enable those skilled in the art to better understand the technical solutions in the embodiments of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art should fall within the protection scope of this disclosure.
[0021] The specific implementation of the embodiments of this disclosure is further described below with reference to the accompanying drawings. Figure 1 is a schematic architecture of a code integration testing system applicable to some embodiments of this disclosure. The code integration testing system in Figure 1 includes a development terminal 10, a code hosting terminal 20, and a code integration testing terminal 30. The code integration testing system is designed to provide a stable, reliable, and efficient integration testing platform to support the front-end work of chip design, from the initial design stage to the final manufacturable design stage.
[0022] Specifically, Development Terminal 10 is used for front-end development of chip design. It is equipped with a high-performance processor, ample memory, and a high-speed storage system to support complex design and simulation tasks. Furthermore, Development Terminal 10 is equipped with various Electronic Design Automation (EDA) tools to assist in different stages of the design process, such as logic synthesis, placement and routing, timing analysis, and power optimization. EDA tools typically include modules such as Synthesis, Place, Route, and Verification, which can process Hardware Description Language (HDL) code and translate it into a physical design that can be implemented on silicon. To achieve efficient collaboration and code management, the design team also uses code hosting platforms such as GitLab and continuous integration (CI) servers for version control of the code, automating the build and testing process to ensure code quality and timely feedback.
[0023] Furthermore, code hosting platforms such as GitLab and GitHub are adopted by chip design teams to improve code quality. These platforms not only provide code storage and management functions but also support automated continuous integration processes. Specifically, GitLab's Webhook is a server-to-server callback notification mechanism that allows GitLab to send HTTP POST requests to predefined URLs when specific events occur, such as code pushes, the creation or closure of merge requests. These event-triggered Webhooks can be used to automatically start build tasks in Jenkins, enabling continuous integration. For example, when a developer pushes an update to a GitLab repository, GitLab can notify the Jenkins server via a Webhook, triggering Jenkins to execute predefined build scripts and test suites. This integration method ensures that code changes are quickly built and tested, allowing for timely detection and fixing of issues, improving development efficiency and code quality. In addition, GitLab provides other components such as Merge Requests to manage code inspection and merging processes, and pipelines to visualize and automate the entire CI process. Through the collaborative work of these components, GitLab provides software development teams with a powerful set of tools to support modern agile development practices.
[0024] Furthermore, the code integration testing terminal 30 can be implemented as a code integration testing device. The code integration testing terminal 30 is used to automatically run a series of checks and tests after code submission, including static code analysis, code style checks, and syntax checks. In this way, potential errors can be identified and corrected as early as possible, reducing the workload of the DV team in the later verification process. The code integration testing terminal 30, through communication with the code hosting terminal 30, supports branch code management, code review, and merge requests—all effective tools for ensuring code quality and promoting team collaboration. Code reviews and merge requests ensure that code changes undergo rigorous review and testing before being merged into the main branch, thus preventing immature or defective code from affecting the entire project.
[0025] Figure 2 illustrates code integration testing methods according to some other embodiments of this disclosure. The code integration testing method in Figure 2 includes:
[0026] S210: Operation event feedback for obtaining the push operation of the updated branch code of the lower-level functional module from the code hosting terminal.
[0027] It should be understood that the code hosting terminal is used for the management and maintenance of various development functional modules. The development functional module can be any module in the functional architecture of the development project. For example, the development functional module can be a top-level functional module (i.e., top layer module) or a lower-level functional module of the top-level functional module. For example, the lower-level functional modules include, but are not limited to, subsystem modules (i.e., subsystem modules) and sub-modules (e.g., block modules).
[0028] It should also be understood that, as the starting point for automating the development process, developers can push updated branch code of lower-level functional modules to the code hosting platform. The code hosting platform then sends feedback information about the push event to CI devices or systems such as Jenkins via a webhook mechanism. This feedback triggers the subsequent automated process of code integration testing, ensuring that the updated branch code can be quickly integrated and tested. It should also be understood that the automated process of code integration testing can be implemented using script code or other types of code and configured as a code integration testing component on the development side.
[0029] S220: Based on the operation event feedback, perform a merge check to merge the updated branch code into the main branch code of the lower-level functional module.
[0030] It should be understood that CI devices or systems such as Jenkins, upon receiving push operation event feedback, can automatically execute a series of predefined inspection tasks, such as code style review, basic logic check, programming language syntax check, static code analysis, etc., to ensure that the commit of updated branch code conforms to project standards and reduce integration errors and potential defects.
[0031] S230: When the merge check result indicates that the check has passed, notify the code hosting provider to merge the updated branch code into the main branch code.
[0032] It should be understood that once the merge check in a CI appliance or system, such as Jenkins, confirms that the code is error-free, the CI appliance or system will send a command to a code hosting provider, such as GitLab, requesting that the updated branch be merged into the main branch. This notification can be implemented, for example, through API calls configured for the code hosting provider by the CI appliance or system, such as Jenkins, or through specific webhook callback functions.
[0033] S240: Obtain the code of the top-level functional module that the lower-level functional module depends on from the code hosting end, and perform dynamic functional testing on the code of the top-level functional module.
[0034] It should be understood that a top-level functional module may consist of multiple lower-level functional modules. After the code of a lower-level module is updated and merged into the main branch, it is verified whether these code updates will affect the functionality of the top-level functional module. Therefore, the CI appliance or system pulls the updated code of the top-level functional module from the code hosting repository and performs dynamic functional tests. Dynamic functional tests can include end-to-end tests, system integration tests, etc., to verify whether the inherent functionality of the top-level functional module is executed as expected, and whether updating the branch code introduces any logical or syntactic defects.
[0035] In the scheme of this embodiment, the operation event feedback of the push operation on the code hosting terminal is used to trigger the merging check of the update branch code of the lower functional module to the main branch code, and the code merging is performed when the merging check passes, which improves the reliability of code management on the code hosting terminal. In addition, the code of the top functional module is obtained and dynamic functional tests are performed to verify the impact of the update branch code of the lower functional module on the top functional module, which further improves the reliability of code management after the update branch code is merged.
[0036] In some examples, as shown in Figure 3, the update branch code is the development branch code. The development end 10 triggers a top-level code merge request by pushing the update branch code of the top-level functional module to the code hosting end 20, or by pushing the update branch code of a lower-level functional module, triggering a lower-level code merge request. The code hosting end 20 manages various development functional modules, as shown in Figure 3, including the top-level and lower-level functional modules. When the code hosting end 20 receives the development branch code of any development functional module, it sends an event feedback to the code integration testing end 30, triggering the merge check module to perform a merge check on the development branch code. After the merge check passes, the code hosting end 20 sends feedback indicating that the check passed, causing the code hosting end 20 to merge the development branch code into the main branch code belonging to the same development functional module.
[0037] Furthermore, the code integration testing endpoint 30 monitors the merging operations of development branches of top-level or lower-level functional modules. For example, as an example of obtaining the code of the top-level functional module that a lower-level functional module depends on from the code hosting endpoint, it can monitor the merging operations of the code hosting endpoint when merging update branch code into the main branch code. Then, based on the monitored merging operations, it can obtain the code of the top-level functional module that the lower-level functional module depends on from the code hosting endpoint. Thus, by monitoring the merging operations, the code of the top-level functional module can be obtained in a timely and reliable manner.
[0038] Regardless of whether the code integration test terminal 30 detects a merging operation of the development branch code of the top-level functional module or a lower-level functional module, the code integration test terminal 30 performs regression testing on the main branch code of the top-level functional module, either locally or by calling the test configuration of the development terminal 10. For example, as an example of obtaining the code of the top-level functional module that the lower-level functional module depends on from the code hosting terminal, it can monitor the merging operation of the update branch code of either the top-level or lower-level functional module to the main branch code of the top-level functional module. Then, upon receiving the merging event feedback of the merging operation, it obtains the main branch code of the top-level functional module that the lower-level functional module depends on from the code hosting terminal, thereby enabling reliable dynamic functional testing of the main branch code of the top-level functional module.
[0039] More specifically, to perform dynamic functional testing on the code of the top-level functional module, regression test cases can be obtained for the main branch code of the top-level functional module. These regression test cases include test input data related to the code of the lower-level functional modules. Then, the test input data is executed using the main branch code of the top-level functional module to obtain the results of the dynamic functional test. In other words, regression testing can efficiently detect the reliability of the main branch code of the top-level functional module. By using test input data related to the code of the lower-level functional modules, reliable and efficient regression testing is performed on the main branch code of the top-level functional module, greatly improving the efficiency of dynamic functional testing.
[0040] Furthermore, to perform dynamic functional testing on the code of the top-level functional modules, a close operation request with operation event feedback can be sent to the code hosting server when the dynamic functional test results indicate that the test has passed. In other words, after the dynamic functional test passes, it indicates that both the merging check of the updated branch code and the dynamic functional test have passed, saving communication interface resources on the code hosting server.
[0041] [P-137023-CN-PRI-1][HS2410901CCN]
[0042] In the example of Figure 3, the code integration test terminal 30 can execute regression tests locally and obtain the regression test results. Alternatively, the code integration test terminal 30 can call the test configuration of the development terminal 10 to execute regression tests and obtain the regression test results. Without loss of generality, as an example of performing merging checks based on operation event feedback, a merging check request for the updated branch code can be sent to the development terminal that pushed the updated branch code based on the operation event feedback, and the merging check result returned by the development terminal can be received. The merging check request instructs the development terminal to merge the updated branch code into the main branch code. In other words, the code integration test device can avoid the process of obtaining the updated branch code targeted by the merging check by sending a merging check request to the development terminal that pushed the updated branch code and receiving the merging check result returned by the development terminal. This eliminates the need to directly execute the merging check through the script program of the code integration test device, saving computational and communication resources.
[0043] In the example in Figure 3, when the static check conditions are met, the merge check module in the code integration test terminal 30 can perform static checks on the update branch code in the top-level functional module or the lower-level functional module. When the static check conditions are not met, the merge check is assumed to have passed, and the code integration test terminal 30 notifies the code hosting terminal 20 to perform the merge operation.
[0044] Without loss of generality, as an example of performing merging checks based on operation event feedback, we can determine whether the updated branch code meets the static code check conditions based on the operation event feedback. Then, if the updated branch code meets the static code check conditions, we perform a static code check to merge the updated branch code into the main branch code of the lower-level functional module. In other words, the merging check conditions characterize the necessity and priority of the merging check. Performing the static code check when the updated branch code meets the static code check conditions improves the reliability of the merging check. When the merging check conditions are not met, a check method with less data processing can be used compared to static code checks.
[0045] Specifically, as some examples of performing merging checks based on operation event feedback, it can be determined that the static code check conditions are met when updating branch code to development branch code. In other words, if updating branch code to development branch code indicates that the merging of the development branch code is highly reliable, and when the aforementioned static code check conditions are met, static code checks can identify logical errors and programming language syntax errors in the development branch code.
[0046] Alternatively, as another example of performing merging checks based on operation event feedback, when the updated branch code is not a development branch, the merging check can be directly deemed a failure, and a close operation request with operation event feedback can be sent to the code hosting provider. In other words, when the updated branch code is not a development branch, it indicates a low necessity for merging the non-development branch code into the main branch; therefore, directly deeming the merging check a failure ensures the reliability of code management on the code hosting provider.
[0047] The code integration testing method of some specific examples of the embodiment in Figure 2 will be described in detail below with reference to Figure 4. Figure 4 illustrates the data interaction and data flow control between the development end 10, the code hosting end 20, and the code integration testing device 30. The code integration testing method in Figure 4 includes the following steps:
[0048] Step S11: The development team 10 pushes the updated branch code of the lower-level functional module to the code hosting team 20. After the developers complete the development of the functional module locally, they execute `git add .` to add changes and `git commit -m "description"` to commit the changes.
[0049] [P-137023-CN-PRI-1][HS2410901CCN] Then use `git push origin branch_name` to push the updates to the GitLab remote repository. After pushing, developers can use the GitLab user interface to confirm the push status and check for any error messages. Then proceed to step S21.
[0050] Step S21: The code hosting terminal 20 determines whether there are code conflicts between the updated branch code and other code in the lower-level functional modules. For example, GitLab checks for conflicts when attempting automatic merging and highlights the conflict area in the console output. If yes, proceed to step S12; if no, proceed to step S31. For example, if a conflict is detected, GitLab will stop the merging process and send an event notification containing conflict information to Jenkins via a webhook.
[0051] Step S12: On the development side, resolve the code conflict by manually modifying the code or deleting the conflict. For example, the developer resolves the conflict in their local editor based on the conflict information provided by GitLab, marks the resolved file as resolved using gitadd, and then git commits and git pushes again to update the remote branch.
[0052] Step S31: The code integration testing device 30 receives operation event feedback from the code hosting terminal 20 in response to the push operation. For example, Jenkins is configured with triggers to listen for webhook events from GitLab. Once a push event is received, Jenkins will evaluate the build conditions and check if there are any new merge requests or code pushes.
[0053] Step S32: The code integration testing device 30 determines whether the updated branch code is a development branch code. For example, Jenkins determines whether it is a development branch based on the branch name or other identifiers, and starts the corresponding build process according to the project configuration. If yes, proceed to step S33; if no, proceed to step S22. Without loss of generality, when the updated branch code is not a development branch code, the merge check result is directly judged as a failed check, and a close operation request is sent to the code hosting terminal as feedback of the operation event.
[0054] Step S22: The code hosting client 20 directly determines the merge check result as failed and sends a close operation request to the code hosting client to close the code merge check. For example, GitLab updates the merge request status to failed and notifies Jenkins to close the relevant CI process. Jenkins then stops building and updates the status accordingly.
[0055] Step S33: When the static code analysis conditions are met, the code integration testing device 30 performs a static code analysis on the updated branch code to determine whether the static code analysis passes. For example, Jenkins runs a pre-configured static code analysis tool to check code quality and generate a report during the build process. If yes, proceed to step S24; if no, proceed to step S23. Without loss of generality, when the updated branch code is development branch code, it is determined that the static code analysis conditions are met. Then, when the updated branch code meets the static code analysis conditions, a static code analysis is performed to merge the updated branch code into the main branch code of the lower-level functional module.
[0056] Step S23: The code hosting server 20 ends the CI test task and continues to execute step S13. For example, GitLab marks the CI process as failed and notifies Jenkins to end the current task. Jenkins updates the build status to failed and notifies the development team.
[0057] Step S24: The code hosting terminal 20 merges the updated branch code into the main branch code and continues to execute steps S13 and S34. For example, GitLab completes the merge operation and notifies Jenkins of the successful merge via a webhook, and Jenkins updates the build status to successful.
[0058] [P-137023-CN-PRI-1][HS2410901CCN]
[0059] Step S13: On the development side 10, CI test result notifications are executed. For example, the CI test results can be displayed to the user through the user interface of the test program executing the code integration tests, or the user can be notified of the CI test results via a messaging program. For instance, developers can view test results through the Jenkins interface or receive test result notifications through an integrated instant messaging system such as Slack. Jenkins can also send test summaries via email to ensure team members receive timely feedback.
[0060] Step S34: The code integration testing apparatus 30 performs regression testing on the code of the top-level functional module. For example, Jenkins starts a regression test suite to verify whether changes to the main branch code of the top-level or lower-level functional module affect the functionality of the main branch of the top-level functional module and provides a test report. Jenkins updates the build status based on the regression test results and notifies GitLab of the test results via Webhook when necessary. Without loss of generality, the code integration testing apparatus 30 monitors the merging operation of the updated branch code of the lower-level or top-level functional module into the main branch code of its own module on the code hosting end, and then obtains the merged main branch code from the code hosting end. In addition, when performing regression testing, regression test cases for the code of the top-level functional module can be obtained. The regression test cases include test input data related to the code of the lower-level functional module. Then, the test input data is executed using the main branch code of the top-level functional module to obtain the results of dynamic functional testing. Then, when the results of dynamic functional testing indicate that the test has passed, a close operation request with operation event feedback is sent to the code hosting end.
[0061] The code integration testing apparatus of some other embodiments of this disclosure will now be described with reference to FIG5. FIG5 shows the code integration testing apparatus 500, which includes:
[0062] Get module 510, retrieve operation event feedback from the code hosting terminal for the push operation of the updated branch code of the lower-level functional modules.
[0063] The inspection module 520 performs a merge check to merge the updated branch code into the main branch code of the lower-level functional module based on the operation event feedback.
[0064] The notification module 530, when the merge check result indicates that the check has passed, notifies the code hosting terminal to merge the updated branch code into the main branch code.
[0065] Test module 540 obtains the code of the top-level functional module that the lower-level functional module depends on from the code hosting terminal, and performs dynamic functional testing on the code of the top-level functional module.
[0066] In the scheme of this embodiment, the operation event feedback of the push operation on the code hosting terminal is used to trigger the merging check of the update branch code of the lower functional module to the main branch code, and the code merging is performed when the merging check passes, which improves the reliability of code management on the code hosting terminal. In addition, the code of the top functional module is obtained and dynamic functional tests are performed to verify the impact of the update branch code of the lower functional module on the top functional module, which further improves the reliability of code management after the update branch code is merged.
[0067] In other embodiments, the testing module is specifically used to: monitor the merge operation of the code hosting terminal into the main branch code; and obtain the code of the top-level functional module on which the lower-level functional module depends from the code hosting terminal based on the monitored merge operation.
[0068] In other embodiments, the testing module is specifically used to: obtain regression test cases for the main branch code of the top-level functional module, the regression test cases including test input data related to the code of the lower-level functional module; execute the test input data using the main branch code of the top-level functional module to obtain the result of the dynamic functional test.
[0069] In other embodiments, the testing module is further configured to: send a shutdown operation request of the operation event feedback to the code hosting terminal when the result of the dynamic functional test indicates that the test has passed.
[0070] In other embodiments, the checking module is specifically used to: send a merge check request for the updated branch code to the development end that pushed the updated branch code based on the operation event feedback, and receive the merge check result returned by the development end, wherein the merge check request instructs the development end to merge the updated branch code into the merge check of the main branch code.
[0071] In other embodiments, the checking module is specifically used to: determine whether the updated branch code meets the static code check conditions based on the operation event feedback; and when the updated branch code meets the static code check conditions, perform a static code check to merge the updated branch code into the main branch code of the lower-level functional module.
[0072] In other embodiments, the checking module is further configured to: determine that the static code check conditions are met when the updated branch code is development branch code.
[0073] In other embodiments, the checking module is further configured to: when the updated branch code is not the development branch code, directly determine the result of the merge check as failing the check, and send a close operation request of the operation event feedback to the code hosting terminal.
[0074] It should be understood that the specific implementation of each module in the code integration testing device can be found in the description of the corresponding steps in the above-described code integration testing method embodiments, and has corresponding beneficial effects, which will not be repeated here. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the code integration testing device and modules described above can be referred to the corresponding process descriptions in the aforementioned code integration testing method embodiments, and will not be repeated here.
[0075] Referring to FIG6, a schematic diagram of an electronic device according to another embodiment of the present disclosure is shown. The specific embodiments of the present disclosure do not limit the specific implementation of the electronic device.
[0076] As shown in Figure 6, the electronic device may include: a processor 602 for executing program 610, a communications interface 604, a memory 606, and a communications bus 608.
[0077] The processor, communication interface, and memory communicate with each other via a communication bus.
[0078] A communication interface is used to communicate with other electronic devices or servers.
[0079] The processor is used to execute programs, specifically the relevant steps in the above method embodiments.
[0080] Specifically, the program may include program code, which includes computer operation instructions.
[0081] The processor may be a CPU, an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement embodiments of this disclosure. The smart device may include one or more processors of the same type, such as one or more CPUs; or it may include processors of different types, such as one or more CPUs and one or more ASICs.
[0082] Memory is used to store programs. Memory may include high-speed RAM, and may also include non-volatile memory, such as at least one disk drive.
[0083] The program may include multiple computer instructions, and specifically, the program may use multiple computer instructions to cause the processor to execute the various code integration test methods described in any of the foregoing method embodiments.
[0084] The specific implementation of each step in the program can be found in the corresponding descriptions of the steps, modules, or units in the above method embodiments, and has corresponding beneficial effects, which will not be repeated here. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described device, equipment, or module can be referred to the corresponding process descriptions in the foregoing method embodiments, and will not be repeated here.
[0085] This disclosure also provides a computer storage medium storing a computer program thereon, which, when executed by a processor, implements the methods described in any of the foregoing method embodiments. The computer storage medium includes, but is not limited to, compact disc read-only memory (CD-ROM), random access memory (RAM), floppy disk, hard disk, or magneto-optical disk.
[0086] This disclosure also provides a computer program product, including computer instructions that instruct a computing device to execute various code integration test methods in the above-described multiple method embodiments.
[0087] Furthermore, it should be noted that the user-related information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to sample data used for training the model, data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this disclosure are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with relevant regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.
[0088] It should be noted that, depending on the implementation needs, the various components / steps described in the embodiments of this disclosure can be broken down into more components / steps, or two or more components / steps or parts of the operation of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of this disclosure.
[0089] The methods described above according to embodiments of this disclosure can be implemented in hardware, firmware, or as software or computer code that can be stored in a recording medium (such as a CD-ROM, RAM, floppy disk, hard disk, or magneto-optical disk), or as computer code originally stored on a remote recording medium or a non-transitory machine-readable medium and subsequently stored on a local recording medium, downloaded over a network. Thus, the methods described herein can be stored on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an Application Specific Integrated Circuit (ASIC) or a Field Programmable Gate Array (FPGA)). It is understood that the computer, processor, microprocessor controller, or programmable hardware includes storage components (e.g., Random Access Memory (RAM), Read-Only Memory (ROM), Flash Memory, etc.) capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods described herein. Furthermore, when a general-purpose computer accesses code used to implement the methods shown herein, the execution of the code transforms the general-purpose computer into a dedicated computer for performing the methods shown herein.
[0090] Those skilled in the art will recognize that the units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments disclosed herein.
[0091] The above embodiments are only used to illustrate the embodiments of this disclosure, and are not intended to limit the embodiments of this disclosure. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the embodiments of this disclosure. Therefore, all equivalent technical solutions also fall within the scope of the embodiments of this disclosure, and the patent protection scope of the embodiments of this disclosure should be defined by the claims.
Claims
1. A code integration testing method, comprising: Get operation event feedback from the code hosting server for pushing updated branch code of lower-level functional modules; Based on the operation event feedback, perform a merge check to merge the updated branch code into the main branch code of the lower-level functional module; When the merge check result indicates that the check has passed, the code hosting terminal is notified to merge the updated branch code into the main branch code; The code of the top-level functional module, which the lower-level functional module depends on, is obtained from the code hosting terminal, and dynamic functional testing is performed on the code of the top-level functional module.
2. The code integration testing method according to claim 1, wherein, Obtaining the code of the top-level functional module that the lower-level functional module depends on from the code hosting terminal includes: monitoring the merge operation of the code hosting terminal into the main branch code; and obtaining the code of the top-level functional module that the lower-level functional module depends on from the code hosting terminal based on the monitored merge operation.
3. The code integration testing method according to claim 2, wherein, Performing dynamic functional testing on the code of the top-level functional module includes: obtaining regression test cases for the main branch code of the top-level functional module, wherein the regression test cases include test input data related to the code of the lower-level functional module; executing the test input data using the main branch code of the top-level functional module to obtain the result of the dynamic functional test.
4. The code integration testing method according to claim 3, wherein, The dynamic functional testing of the code of the top-level functional module also includes: when the result of the dynamic functional test indicates that the test has passed, sending a shutdown operation request of the operation event feedback to the code hosting terminal.
5. The code integration testing method according to claim 1, wherein, Based on the operation event feedback, perform a merge check to merge the updated branch code into the main branch code of the lower-level functional module, including: sending a merge check request for the updated branch code to the development end that pushed the updated branch code, and receiving the merge check result returned by the development end, wherein the merge check request instructs the development end to merge the updated branch code into the main branch code.
6. The code integration testing method according to claim 1, wherein, Based on the operation event feedback, a merge check is performed to merge the updated branch code into the main branch code of the lower-level functional module, including: determining whether the updated branch code meets the code static check conditions based on the operation event feedback; and performing a code static check to merge the updated branch code into the main branch code of the lower-level functional module when the updated branch code meets the code static check conditions.
7. The code integration testing method according to claim 6, wherein, Based on the operation event feedback, a merge check is performed to merge the updated branch code into the main branch code of the lower-level functional module, and further includes: when the updated branch code is development branch code, determining that the code static check condition is met.
8. The code integration testing method according to claim 7, wherein, Based on the operation event feedback, a merge check is performed to merge the updated branch code into the main branch code of the lower-level functional module. The merge check also includes: if the updated branch code is not the development branch code, the merge check result is directly determined to be a failed check, and a close operation request based on the operation event feedback is sent to the code hosting terminal.
9. A code integration testing apparatus, comprising: The module retrieves operation event feedback from the code hosting end regarding the push operation of the updated branch code of the lower-level functional modules; The inspection module performs a merge check based on the operation event feedback to merge the updated branch code into the main branch code of the lower-level functional module. The notification module, when the merge check result indicates that the check has passed, notifies the code hosting end to merge the updated branch code into the main branch code; The testing module obtains the code of the top-level functional module that the lower-level functional module depends on from the code hosting terminal, and performs dynamic functional testing on the code of the top-level functional module.
10. A code integration testing system, comprising: Code hosting platform; The code integration testing apparatus according to claim 9.
11. An electronic device, comprising: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the method according to any one of claims 1-8.
12. A computer storage medium having a computer program stored thereon, which, when executed by a processor, implements the method according to any one of claims 1-8.
13. A computer program product comprising computer instructions that, when executed by a processor, implement the method of any one of claims 1-8.