Code verification method and device for heterogeneous environment, equipment and medium
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING QINGSONG YIKANG INFORMATION TECHNOLOGY CO LTD
- Filing Date
- 2026-04-29
- Publication Date
- 2026-07-21
Smart Images
Figure CN122432015A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a code verification method, apparatus, device, and medium for heterogeneous environments. Background Technology
[0002] With the evolution of microservice architecture, enterprise-level R&D systems are generally becoming heterogeneous, meaning that multiple programming languages such as Java, Go, and Python coexist, each with different dependency management and compilation mechanisms. Current automated testing tools typically require injecting test configurations, dependencies, and scripts into the business code repository, leading to bloated business codebases and security and compliance risks. Furthermore, due to the differences in build environments for different languages, existing solutions struggle to automatically adapt to different language types and complete code verification outside of the business production environment.
[0003] Therefore, how to verify heterogeneous code without being tied to the business environment has become a problem that needs to be solved. Summary of the Invention
[0004] This application provides a code verification method, apparatus, device, and medium for heterogeneous environments to solve the aforementioned technical problem of how to verify heterogeneous code without being in the business environment.
[0005] According to one aspect of the embodiments of this application, this application provides a code verification method for heterogeneous environments, comprising: in response to a code change event, identifying the language type from the changed business code repository and extracting dependency information; based on the language type and dependency information, constructing a shadow execution environment in an isolated execution space, wherein the shadow execution environment matches the runtime context of the business code repository; in the shadow execution environment, integrating a test framework and a coverage framework that match the language type by modifying the build configuration file; initiating a build instruction that matches the language type to run the test framework and coverage framework, thereby performing verification of the changed code and obtaining a verification report.
[0006] Optionally, the language type can be identified from the changed business code repository, and dependency information can be extracted, including: accessing the code files and build configuration files of the business code repository in read-only mode; identifying the file extensions from the code files and determining the language type of the business code repository based on the file extensions; and parsing the dependency coordinates and version numbers from the build configuration files to obtain dependency information.
[0007] Optionally, before initiating a build instruction matching the language type, the method further includes: in response to a code change event, extracting code change metadata from the business code repository, wherein the code change metadata includes the changed file, the changed line number, and the changed content; pulling existing verification assets corresponding to the business code repository from the isolated asset domain, wherein the existing verification assets include historically accumulated unit test code and mock object configurations; based on the code change metadata, calling a large language model to generate incremental verification assets for the changed code; performing semantic fusion and dependency completion on the existing verification assets and incremental verification assets to build a complete test code package; and injecting the complete test code package into the shadow execution environment.
[0008] Optionally, the verification of the changed code is performed to obtain a verification report, including: executing build instructions in the shadow execution environment to make the test framework run test cases and generate assertion pass rate; during the execution, triggering the coverage framework to collect code execution path data to generate raw coverage data file; aggregating assertion pass rate and raw coverage data file to generate verification report.
[0009] Optionally, after generating the original coverage data file, the method further includes: parsing the original coverage data file and extracting the code line identifiers to be tested and covered; obtaining the change line numbers from the code change metadata of the business code repository; matching the code line identifiers to be tested and covered with the change line numbers to calculate the incremental coverage for the changed code; and encapsulating the incremental coverage as part of the verification report.
[0010] Optionally, the method further includes: capturing exception information generated in the shadow execution environment in real time during the verification of the changed code; determining the exception type of the exception information and extracting the corresponding target field from the exception information, wherein the exception type includes assertion failure exceptions, execution timeout exceptions, full-process runtime exceptions and environment adaptation exceptions; encapsulating the target field into a problem list and encapsulating the problem list as part of the verification report.
[0011] Optionally, after generating the verification report, the method further includes: extracting a problem list, test pass rate, and coverage data from the verification report; comparing the test pass rate with a pass rate threshold and comparing the coverage data with a coverage threshold; triggering a multi-channel notification if the test pass rate is less than the pass rate threshold or the coverage data is less than the coverage threshold; and sending an early warning notification containing the problem list to the target object through the multi-channel notification.
[0012] According to another aspect of the embodiments of this application, this application provides a code verification device for heterogeneous environments, including: an identification module, configured to identify the language type from the changed business code repository and extract dependency information in response to a code change event; a build module, configured to build a shadow execution environment in an isolated execution space based on the language type and dependency information, wherein the shadow execution environment matches the runtime context of the business code repository; an integration module, configured to integrate a test framework and a coverage framework matching the language type in the shadow execution environment by modifying the build configuration file; and a startup module, configured to start a build instruction matching the language type to run the test framework and coverage framework, thereby performing verification of the changed code and obtaining a verification report.
[0013] According to another aspect of the embodiments of this application, this application provides an electronic device, including a memory, a processor, a communication interface and a communication bus. The memory stores a computer program that can run on the processor. The memory and the processor communicate with each other through the communication bus and the communication interface. When the processor executes the computer program, it implements the steps of the above method.
[0014] According to another aspect of the embodiments of this application, this application also provides a computer-readable medium having processor-executable non-volatile program code that causes the processor to perform the above-described method.
[0015] Compared with related technologies, the technical solutions provided in this application have the following advantages: This application provides a code verification method for heterogeneous environments, comprising: in response to a code change event, identifying the language type from the changed business code repository and extracting dependency information; based on the language type and dependency information, constructing a shadow execution environment in an isolated execution space, wherein the shadow execution environment matches the runtime context of the business code repository; in the shadow execution environment, integrating a test framework and coverage framework matching the language type by modifying the build configuration file; and initiating a build command matching the language type to run the test framework and coverage framework, thereby performing verification of the changed code and obtaining a verification report. By identifying the language type and dependency information of the code repository and dynamically constructing a shadow execution environment matching the business runtime context, the verification process is separated from the business environment. Furthermore, by integrating the test and coverage frameworks by modifying the build configuration file, automated verification of heterogeneous code is achieved without considering the business environment. This solves the problem of how to verify heterogeneous code without considering the business environment. Attached Figure Description
[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0017] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.
[0018] Figure 1 This is a schematic diagram of the hardware environment for an optional code verification method for heterogeneous environments provided according to an embodiment of this application; Figure 2 This is a flowchart of an optional code verification method for heterogeneous environments provided according to an embodiment of this application; Figure 3 This is a schematic diagram of an optional code verification and governance framework for heterogeneous environments provided according to an embodiment of this application; Figure 4 This is a block diagram of an optional code verification device for heterogeneous environments provided according to an embodiment of this application; Figure 5 This is a schematic diagram of an optional electronic device structure provided in an embodiment of this application. Detailed Implementation
[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0020] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustration and has no specific meaning in itself. Therefore, "module" and "part" may be used interchangeably.
[0021] With the evolution of microservice architecture, enterprise-level R&D systems are generally becoming heterogeneous, meaning that multiple programming languages such as Java, Go, and Python coexist, each with different dependency management and compilation mechanisms. Current automated testing tools typically require injecting test configurations, dependencies, and scripts into the business code repository, leading to bloated business codebases and security and compliance risks. Furthermore, due to the differences in build environments for different languages, existing solutions struggle to automatically adapt to different language types and complete code verification outside of the business production environment.
[0022] Therefore, how to verify heterogeneous code without being tied to the business environment has become a problem that needs to be solved.
[0023] To address the problems mentioned in the background art, according to one aspect of the embodiments of this application, an embodiment of a code verification method for heterogeneous environments is provided.
[0024] Optionally, in the embodiments of this application, the above-described code verification method for heterogeneous environments can be applied to, for example... Figure 1 The hardware environment shown consists of terminal 101 and server 103. Figure 1 As shown, server 103 is connected to terminal 101 via a network and can be used to provide services to the terminal or clients installed on the terminal. Database 105 can be set up on the server or independently of the server to provide data storage services for server 103. The network mentioned above includes, but is not limited to, wide area network, metropolitan area network or local area network. Terminal 101 includes, but is not limited to, PC, mobile phone, tablet computer, etc.
[0025] The code verification method for heterogeneous environments in this application embodiment can be executed by server 103, or it can be jointly executed by server 103 and terminal 101, such as... Figure 2 As shown, it includes: Step 201: In response to a code change event, identify the language type from the business code repository where the change occurred and extract dependency information; Step 202: Based on language type and dependency information, construct a shadow execution environment in an isolated execution space, wherein the shadow execution environment matches the runtime context of the business code repository; Step 203: In the shadow execution environment, integrate the test framework and coverage framework that match the language type by modifying the build configuration file; Step 204: Initiate the build command that matches the language type to run the test framework and coverage framework, thereby performing verification of the changed code and obtaining a verification report.
[0026] This application applies to enterprise-level microservice architecture scenarios, triggering a verification process when developers push code changes to a business code repository that includes multiple programming languages such as Java, Go, or Python.
[0027] In response to code change events, the system identifies file extensions in the business code repository to determine the language type and parses dependency coordinates and version numbers from the build configuration file to extract dependency information.
[0028] Based on language type and dependency information, a shadow execution environment is dynamically constructed in an isolated execution space. This shadow execution environment replicates the runtime context of the business code repository, thereby separating the verification execution process from the business production environment.
[0029] In a shadow execution environment, test frameworks and coverage frameworks that match the language type are integrated by modifying build configuration files rather than modifying business source code.
[0030] Initiate build commands that match the language type, such as `mvn test` for Java, `go test` for Go, and `pytest` for Python, to run the test framework and coverage framework to perform verification of the changed code and generate a verification report containing test pass rate and coverage data.
[0031] This application achieves automated verification of heterogeneous code without being required by the production environment. At the same time, by modifying configuration files instead of business source code, it avoids intrusion into the business code repository and ensures the compliance of the business code.
[0032] As an optional implementation, the language type is identified from the changed business code repository, and dependency information is extracted, including: accessing the code files and build configuration files of the business code repository in read-only mode; identifying the file extension from the code files and determining the language type of the business code repository based on the file extension; and parsing the dependency coordinates and version numbers from the build configuration file to obtain dependency information.
[0033] Access the modified business code repository's code files and build configuration files in read-only mode. The code files are source code files containing business logic, and the build configuration files are configuration files used to define dependencies and the build process.
[0034] By accessing the business code repository in read-only mode, only the file content is read without any write operations are performed, ensuring that no test configurations, dependencies, or scripts are injected into the business code repository during the entire verification process, thus achieving zero intrusion.
[0035] The system reads file extensions from code files and determines the programming language used in the code repository based on the extension. It scans code files in the business code repository and reads their filename extensions. For example, if a ".java" extension is detected, the language is determined to be Java; if ".go" is detected, it's Go; and if ".py" is detected, it's Python. This automatic language differentiation based on file extensions eliminates the need for manual annotation and solves the problem of heterogeneous language identification.
[0036] The system locates and reads the build configuration files in the business code repository. For example, for Java, the build configuration file is pom.xml, from which dependency coordinates (groupId:artifactId) and version numbers (version) are parsed; for Go, the build configuration file is go.mod, from which the module path and version requirements are parsed, and the module path is used as the dependency coordinates; for Python, the build configuration file is requirements.txt or pyproject.toml, from which the package name and version number are parsed, and the package name is used as the dependency coordinates. The parsed dependency coordinates and version numbers together constitute the dependency information.
[0037] By parsing the dependency coordinates and version numbers in the build configuration file, the dependency information required by the business code can be accurately obtained, providing a data foundation for the subsequent construction of a shadow execution environment that matches the runtime context of the business code repository.
[0038] As an optional embodiment, before initiating a build instruction matching the language type, the method further includes: in response to a code change event, extracting code change metadata from the business code repository, wherein the code change metadata includes the changed file, the changed line number, and the changed content; pulling existing verification assets corresponding to the business code repository from the isolated asset domain, wherein the existing verification assets include historically accumulated unit test code and mock object configurations; based on the code change metadata, calling a large language model to generate incremental verification assets for the changed code; performing semantic fusion and dependency completion on the existing verification assets and incremental verification assets to build a complete test code package; and injecting the complete test code package into the shadow execution environment.
[0039] When code is pushed to the business code repository, a code change event is triggered. The metadata of this code change is extracted from the business code repository, including the changed file, the changed line number, and the changed content. Among them, the changed file is the file that was submitted for modification, the changed line number is the specific line of code modified in each changed file, and the changed content is the specific code that was added, deleted, or modified.
[0040] The isolated asset domain is a storage space independent of the business code repository, used to store historically accumulated verification assets. Based on the identifier of the changed business code repository, the existing verification assets corresponding to that code repository are retrieved from the isolated asset domain, including historically accumulated unit test code and mock object configurations. The mock object configurations are used to replace real dependencies during testing, facilitating the isolation of test target code. By retrieving existing verification assets from the isolated asset domain, historically accumulated test results are preserved, avoiding duplicate generation.
[0041] The changes are taken as input: the changed file, the changed line number, and the changed content. The Large Language Model (LLM) is invoked, which understands the semantics of the changed code and automatically generates incremental verification assets for the changed code. These are unit test code snippets specifically used to test the newly added or modified code.
[0042] Existing validation assets are merged with incremental validation assets. During the merging process, the semantic relationships between the two are analyzed, potential naming conflicts or missing dependencies are resolved, and necessary dependency declarations and import statements are automatically completed, thereby building a complete and independently executable test code package.
[0043] By using semantic fusion and dependency completion, existing and incremental assets are integrated into a complete test code package, ensuring the integrity and executability of the test code.
[0044] The test code package is injected into the built shadow execution environment, deployed to the specified execution directory, and awaits subsequent build instructions to trigger execution.
[0045] As an optional implementation, performing verification of the changed code and obtaining a verification report includes: executing build instructions in a shadow execution environment to enable the test framework to run test cases and generate assertion pass rates; during execution, triggering the coverage framework to collect code execution path data to generate raw coverage data files; and aggregating the assertion pass rates and raw coverage data files to generate a verification report.
[0046] Based on the previously identified language type, a build instruction matching that language type is launched in the shadow execution environment. For example, the Java language executes the `mvn test` instruction when using the Maven build tool, the Go language executes the `go test` instruction, and the Python language executes the `pytest` instruction.
[0047] The built-in testing framework is invoked using build instructions. For example, Java uses the JUnit framework, Go uses the gotest framework, and Python uses the pytest framework. The testing framework automatically discovers and runs the complete test code package injected into the shadow execution environment. Each test case in the test code package contains several assertions (i.e., statements that judge the expected result). After the testing framework runs the test cases, it counts the percentage of successful assertions and generates an assertion pass rate.
[0048] During the build process, the integrated coverage framework is automatically triggered. The coverage framework uses bytecode instrumentation or source code instrumentation techniques to record which lines of code, branches, and methods were actually executed during test case runtime. After execution, the coverage framework outputs the collected code execution path data as a raw coverage data file.
[0049] The format of the raw coverage data file varies depending on the language. For example, Java uses .exec files, Go uses .out files, and Python uses .coverage files.
[0050] The system reads the assertion pass rate and raw coverage data files and aggregates them. The code execution path data in the raw coverage data file is converted into a visual coverage percentage (e.g., line coverage, branch coverage, etc.). The assertion pass rate and coverage data are then integrated into a structured validation report that includes both test pass rate (i.e., assertion pass rate) and coverage data.
[0051] This embodiment can automatically complete test execution and coverage collection in a shadow execution environment without manual intervention. Moreover, by using both assertion pass rate and coverage data as dual measures, it can comprehensively evaluate the functional correctness and test adequacy of the changed code.
[0052] As an optional embodiment, after generating the original coverage data file, the method further includes: parsing the original coverage data file and extracting the code line identifiers to be tested and covered; obtaining the change line numbers from the code change metadata of the business code repository; matching the code line identifiers to be tested and covered with the change line numbers to calculate the incremental coverage for the changed code; and encapsulating the incremental coverage as part of the verification report.
[0053] Read the raw coverage data file generated in the shadow execution environment. The raw coverage data file records the code location information actually covered during the execution of the test cases. Parse the file and extract the code line identifiers that are covered by the test. Each code line identifier corresponds to a specific code line in a file in the business code repository.
[0054] The changed line number is obtained from the previously extracted code change metadata. The code change metadata records which lines of code were specifically modified in this code change event. The changed line number is the line number position of the modified line of code in the original file.
[0055] The code line identifiers to be tested are matched one by one with the changed line numbers. If a changed line number appears in the code line identifiers to be tested, then that line of changed code is considered to be covered by the test; otherwise, it is considered not covered. The number of lines determined to be covered among all changed line numbers is counted, and divided by the total number of changed line numbers to calculate the incremental coverage rate for the changed code. Incremental coverage rate refers to the coverage rate calculated only for the currently tested code change lines, that is, the number of changed lines covered by the test divided by the total number of changed lines, which is different from full coverage rate, which covers all code.
[0056] Add incremental coverage to the validation report as a component. The original coverage data in the validation report is the full coverage, while the newly added incremental coverage is identified separately, making it easier for developers to focus on the test coverage of changed code.
[0057] This embodiment obtains the code line identifiers covered by the test by parsing the original coverage data file, and obtains the changed line numbers by obtaining the code change metadata. The two are matched to calculate incremental coverage only for the changed code, rather than full coverage. Incremental coverage better reflects the testing quality of this code change, avoiding the problem of untested changed code being masked by historical code coverage.
[0058] As an optional embodiment, the method further includes: capturing exception information generated in the shadow execution environment in real time during the verification of the changed code; determining the exception type of the exception information, extracting the corresponding target field from the exception information, wherein the exception type includes assertion failure exceptions, execution timeout exceptions, full-process runtime exceptions, and environment adaptation exceptions; encapsulating the target field into a problem list, and encapsulating the problem list as part of the verification report.
[0059] Throughout the entire process of executing build commands, running test frameworks, and coverage frameworks in the shadow execution environment, continuous monitoring and real-time capture of any exception information generated are performed. Exception information includes raw data such as error objects thrown during program runtime, error messages, and stack traces.
[0060] The captured exception information is categorized and identified to determine its exception type, and then the corresponding target fields are extracted based on the exception type. Exception types include assertion failure exceptions, execution timeout exceptions, full-process runtime exceptions, and environment adaptation exceptions.
[0061] Specifically, assertion failure exceptions are thrown by the native testing frameworks of various languages. For example, in Java, the JUnit framework throws an Assertion Error; in Go, the go test framework throws an Assertion failure panic; and in Python, the pytest framework throws an Assertion Error. This category also includes execution failures of custom assertions in the large language model generation validation assets. After capturing this type of exception, the following target fields are automatically extracted: the name of the test case to which the exception belongs, the line of code containing the assertion statement, the expected result, the actual execution result, and the location of the business code associated with the exception triggering it.
[0062] Specifically, execution timeout exceptions are thrown when the execution time of a test case exceeds a preset threshold. Dedicated timeout thresholds are preset for different languages and types of verification tasks; for example, the threshold is set to 5 seconds for ordinary interface tests and 30 seconds for complex logic tests. These thresholds can be dynamically adjusted according to the complexity of the business code. When the execution time of a verification task in the shadow environment exceeds the corresponding threshold, a timeout exception is immediately captured. After capture, the following target fields are automatically extracted: the timeout test case identifier, the executed time, the timeout threshold, and the running status when the task execution was interrupted. Simultaneously, the timeout task is forcibly terminated to release shadow container resources and avoid prolonged occupation of isolated execution space.
[0063] Specifically, full-process runtime exceptions are the native runtime exceptions captured throughout the entire chain of the verification task, from compilation to execution. These include, but are not limited to: code compilation failure exceptions (such as syntax errors, missing dependencies), class or function loading failure exceptions, parameter type mismatch exceptions, null pointer or null reference exceptions, file or resource access exceptions, etc. After capture, the full-chain traceability information is automatically extracted as target fields, including the stage at which the exception occurred (compilation stage, loading stage, or execution stage), the specific type of the exception, complete exception stack information, and the location of the associated business code or code change line.
[0064] Specifically, environment adaptation exceptions are those thrown during the adaptation process between the shadow environment and business code, including but not limited to: runtime version incompatibility exceptions (such as an outdated Java SDK version, a mismatch between the Python interpreter version and dependency packages), coverage framework integration failure exceptions, and dependency conflict exceptions between test code and business code. After capture, environment adaptation information is automatically extracted as target fields, including the language type of the exception, shadow environment configuration parameters, conflicting dependency or version information, and the specific configuration node where framework integration failed.
[0065] Individual capture and logging of environment adaptation anomalies helps troubleshoot shadow environment configuration issues and improves the stability of environment building.
[0066] All extracted target fields are structured and packaged into an issue list. Each issue in the issue list includes information such as error location, omissions, and notification suggestions. The issue list is added to the verification report as an independent component of the verification report.
[0067] This embodiment avoids delays in post-event investigation by capturing abnormal information in real time during the verification process. By classifying abnormalities into four categories—assertion failure, execution timeout, full-process runtime, and environment adaptation—and each category corresponding to specific target field extraction rules, it achieves structured extraction of abnormal information. The extracted target fields are encapsulated into a problem list and included in the verification report, so that the verification report not only includes pass rate and coverage data, but also failure cause location information, which makes it easier for developers to quickly locate the root cause of the problem.
[0068] As an optional embodiment, after generating the verification report, the method further includes: extracting a problem list, test pass rate, and coverage data from the verification report; comparing the test pass rate with a pass rate threshold and comparing the coverage data with a coverage threshold; triggering a multi-channel notification if the test pass rate is less than the pass rate threshold or the coverage data is less than the coverage threshold; and sending an early warning notification containing the problem list to the target object through the multi-channel notification.
[0069] Obtain the generated verification report, and extract the issue list, test pass rate, and coverage data from the verification report. The issue list is a collection of exception information captured and encapsulated during the verification process. The test pass rate is the assertion pass rate, which reflects the success rate of test cases. The coverage data includes full coverage and incremental coverage, which reflect the degree to which the code is covered by tests.
[0070] Preset pass rate and coverage thresholds. The pass rate threshold measures the minimum acceptable pass rate for tests, and can be set to 90%. The coverage threshold measures the minimum acceptable code coverage, and can be set to 80%.
[0071] The test pass rate is compared numerically with the pass rate threshold, and the coverage data is compared numerically with the coverage threshold. When the test pass rate is lower than the preset pass rate threshold, or the coverage data is lower than the preset coverage threshold, the verification result is determined to have failed to meet the quality requirements, triggering a multi-channel notification. Multi-channel notification refers to sending notifications simultaneously or selectively through multiple communication channels (e.g., email and SMS). The specific channel selection can be determined based on the tiered warning system.
[0072] Tiered early warning refers to classifying warning levels based on the degree to which verification results fail to meet thresholds, and using differentiated notification methods for different levels. For example, minor non-compliance is only notified via email, while severe non-compliance is notified simultaneously through multiple channels such as SMS and email.
[0073] The alert notification includes a list of issues so that the target audience can directly understand the specific reasons for the verification failure, the location of the error, and any omissions in the coverage. The target audience can be the person in charge of the business code repository or relevant personnel.
[0074] In this embodiment, after the verification report is generated, the test pass rate is compared with the pass rate threshold, and the coverage data is compared with the coverage threshold. The threshold judgment mechanism automatically evaluates whether the quality of the code changes meets the standards. When any indicator fails to reach the threshold, a multi-channel notification is automatically triggered to send the problem list to the relevant person in charge, so that the person in charge can directly locate the root cause of the problem and reduce the investigation cost.
[0075] Figure 3 This diagram illustrates a code verification governance framework for heterogeneous environments, as provided in this application embodiment. As shown, the business-aware domain detects code change trigger signals through multi-warehouse monitoring and code difference diff extraction, then enters the generation phase. In the generation phase, through artificial intelligence scheduling and asset reorganization, it receives code change trigger signals, calls a large language model to generate incremental verification assets, and performs semantic fusion and dependency completion with existing verification assets pulled from the isolated asset domain, outputting a complete test asset package. In the verification phase, the distributed shadow execution space (corresponding to the shadow execution environment of this application) receives the complete test asset package, compiles and executes the test code package in the isolated execution environment, and performs quality measurement on the execution results of the verification phase through a combination of quality measurement and report generation with a result traceability mechanism, generating a verification report and original measurement data (i.e., original coverage data files). In the notification phase, through risk detection and tiered multi-channel notification, it outputs a standardized problem list and tiered early warning information. Finally, developers or project leaders submit problem fixes and code optimizations based on the early warning information, forming a closed-loop governance process.
[0076] This application provides a code verification method for heterogeneous environments, comprising: in response to a code change event, identifying the language type from the changed business code repository and extracting dependency information; based on the language type and dependency information, constructing a shadow execution environment in an isolated execution space, wherein the shadow execution environment matches the runtime context of the business code repository; in the shadow execution environment, integrating a test framework and coverage framework matching the language type by modifying the build configuration file; and initiating a build command matching the language type to run the test framework and coverage framework, thereby performing verification of the changed code and obtaining a verification report. By identifying the language type and dependency information of the code repository and dynamically constructing a shadow execution environment matching the business runtime context, the verification process is separated from the business environment. Furthermore, by integrating the test and coverage frameworks by modifying the build configuration file, automated verification of heterogeneous code is achieved without considering the business environment. This solves the problem of how to verify heterogeneous code without considering the business environment.
[0077] According to another aspect of the embodiments of this application, this application provides a code verification device for heterogeneous environments, such as... Figure 4 As shown, it includes: The identification module 401 is used to identify the language type from the changed business code repository and extract dependency information in response to code change events; Module 402 is used to build a shadow execution environment in an isolated execution space based on language type and dependency information, wherein the shadow execution environment matches the runtime context of the business code repository; Integration module 403 is used to integrate language-type-matched test and coverage frameworks in a shadow execution environment by modifying the build configuration file; Startup module 404 is used to initiate build instructions that match the language type to run the test framework and coverage framework, thereby performing verification of the changed code and obtaining a verification report.
[0078] It should be noted that the identification module 401 in this embodiment can be used to execute step 201 in this application embodiment, the construction module 402 in this embodiment can be used to execute step 202 in this application embodiment, the integration module 403 in this embodiment can be used to execute step 203 in this application embodiment, and the startup module 404 in this embodiment can be used to execute step 204 in this application embodiment.
[0079] Optionally, the identification module 401 is specifically used to access the code files and build configuration files of the business code repository in read-only mode; identify the file extensions from the code files and determine the language type of the business code repository based on the file extensions; and parse the dependency coordinates and version numbers from the build configuration files to obtain dependency information.
[0080] Optionally, the device further includes an extraction module, used to extract code change metadata from the business code repository in response to a code change event before initiating a build instruction matching the language type. The code change metadata includes the changed file, the changed line number, and the changed content. The module also pulls existing verification assets corresponding to the business code repository from the isolated asset domain. These existing verification assets include historically accumulated unit test code and mock object configurations. Based on the code change metadata, the module calls a large language model to generate incremental verification assets for the changed code. The module performs semantic fusion and dependency completion on the existing and incremental verification assets to build a complete test code package. Finally, the module injects the complete test code package into the shadow execution environment.
[0081] Optionally, the startup module 404 is specifically used to execute build instructions in the shadow execution environment to enable the test framework to run test cases and generate assertion pass rates; during execution, it triggers the coverage framework to collect code execution path data to generate raw coverage data files; and it aggregates assertion pass rates and raw coverage data files to generate a verification report.
[0082] Optionally, the device further includes a parsing module, which, after generating the original coverage data file, parses the original coverage data file to extract the code line identifiers to be tested and covered; obtains the change line numbers from the code change metadata of the business code repository; matches the code line identifiers to be tested and covered with the change line numbers to calculate the incremental coverage for the changed code; and encapsulates the incremental coverage as part of the verification report.
[0083] Optionally, the device also includes a capture module for capturing exception information generated in the shadow execution environment in real time during the verification of the changed code; determining the exception type of the exception information; extracting the corresponding target field from the exception information; wherein the exception type includes assertion failure exceptions, execution timeout exceptions, full-process runtime exceptions, and environment adaptation exceptions; encapsulating the target field into a problem list; and encapsulating the problem list as part of the verification report.
[0084] Optionally, the device also includes an early warning module, which is used to extract a problem list, test pass rate, and coverage data from the verification report after the verification report is generated; compare the test pass rate with a pass rate threshold and compare the coverage data with a coverage threshold; trigger a multi-channel notification if the test pass rate is less than the pass rate threshold or the coverage data is less than the coverage threshold; and send an early warning notification containing the problem list to the target object through the multi-channel notification.
[0085] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should also be noted that the above modules, as part of a device, can operate in situations such as... Figure 1 The hardware environment shown.
[0086] According to another aspect of the embodiments of this application, this application provides an electronic device, such as... Figure 5 As shown, the system includes a memory 501, a processor 502, a communication interface 503, and a communication bus 504. The memory 501 stores a computer program that can run on the processor 502. The memory 501 and the processor 502 communicate through the communication interface 503 and the communication bus 504. When the processor 502 executes the computer program, it implements the steps of the above method.
[0087] The memory and processor in the aforementioned electronic devices communicate with each other via a communication bus and a communication interface. The communication bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into an address bus, a data bus, a control bus, etc.
[0088] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.
[0089] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0090] According to another aspect of the embodiments of this application, a computer-readable medium having processor-executable non-volatile program code is also provided.
[0091] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.
[0092] In specific implementation, the embodiments of this application can be referred to the above embodiments and have corresponding technical effects.
[0093] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.
[0094] For software implementation, the techniques described herein can be implemented by units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or external to the processor.
[0095] Those skilled in the art will recognize that the units and algorithm 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 this application.
[0096] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0097] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.
[0098] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0099] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0100] If the aforementioned function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks. It should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. In the absence of further restrictions, an element defined by the phrase "comprising a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0101] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement 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 claimed herein.
Claims
1. A code verification method for heterogeneous environments, characterized in that, include: In response to code change events, identify the language type from the changed business code repository and extract dependency information; Based on the language type and the dependency information, a shadow execution environment is constructed in an isolated execution space, wherein the shadow execution environment matches the runtime context of the business code repository; In the shadow execution environment, a test framework and coverage framework that match the language type are integrated by modifying the build configuration file; Initiate a build command that matches the language type to run the test framework and the coverage framework, thereby performing verification of the changed code and obtaining a verification report.
2. The method according to claim 1, characterized in that, The process of identifying the language type and extracting dependency information from the changed business code repository includes: Access the code files of the business code repository and the build configuration file in read-only mode; Identify the file extension from the code file and determine the language type of the business code repository based on the file extension; The dependency coordinates and version numbers are parsed from the build configuration file to obtain the dependency information.
3. The method according to claim 1, characterized in that, Before initiating a build instruction that matches the language type, the method further includes: In response to the code change event, code change metadata is extracted from the business code repository, wherein the code change metadata includes the changed file, the changed line number, and the changed content; Pull out existing verification assets corresponding to the business code repository from the isolated asset domain, wherein the existing verification assets include historically accumulated unit test code and mock object configurations; Based on the code change metadata, the large language model is invoked to generate incremental verification assets for the changed code; The existing verification assets and the incremental verification assets are semantically fused and dependency-completed to build a complete test code package; Inject the complete test code package into the shadow execution environment.
4. The method according to claim 1, characterized in that, The verification of the modified code is performed, and a verification report is obtained, including: The build instructions are executed in the shadow execution environment to cause the test framework to run test cases and generate assertion pass rates; During execution, the coverage framework is triggered to collect code execution path data to generate the original coverage data file; The assertion pass rate and the original coverage data file are aggregated to generate the verification report.
5. The method according to claim 4, characterized in that, After generating the raw coverage data file, the method further includes: Parse the original coverage data file and extract the identifiers of the code lines covered by the test. Obtain the line number of the change in the code change metadata of the business code repository; Match the identifier of the code line covered by the test with the changed line number, and calculate the incremental coverage for the changed code; The incremental coverage is encapsulated as part of the verification report.
6. The method according to claim 4, characterized in that, The method further includes: During the verification of the modified code, abnormal information generated in the shadow execution environment is captured in real time; Determine the exception type of the exception information, and extract the corresponding target field from the exception information. The exception type includes assertion failure exceptions, execution timeout exceptions, full-process runtime exceptions, and environment adaptation exceptions. The target field is encapsulated into a list of issues, and the list of issues is then encapsulated as part of the verification report.
7. The method according to claim 6, characterized in that, After generating the verification report, the method further includes: Extract the issue list, test pass rate, and coverage data from the verification report; The test pass rate is compared with the pass rate threshold, and the coverage data is compared with the coverage threshold; If the test pass rate is less than the pass rate threshold, or the coverage data is less than the coverage threshold, a multi-channel notification is triggered. The warning notification containing the list of issues is sent to the target object through the multi-channel notification.
8. A code verification device for heterogeneous environments, characterized in that, include: The identification module is used to identify the language type from the changed business code repository and extract dependency information in response to code change events; A building module is used to build a shadow execution environment in an isolated execution space based on the language type and the dependency information, wherein the shadow execution environment matches the runtime context of the business code repository; An integration module is used in the shadow execution environment to integrate a test framework and coverage framework that match the language type by modifying the build configuration file; The startup module is used to initiate build instructions that match the language type to run the test framework and the coverage framework, thereby performing verification of the changed code and obtaining a verification report.
9. An electronic device comprising a memory, a processor, a communication interface, and a communication bus, wherein the memory stores a computer program executable on the processor, and the memory and the processor communicate via the communication bus and the communication interface, characterized in that... When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.
10. A computer-readable medium having processor-executable non-volatile program code, characterized in that, The program code causes the processor to execute the method of any one of claims 1 to 7.