Test report generation method, device and electronic equipment for refactoring code

Abstract

The application discloses a test report generation method and device for refactoring code and electronic equipment, and relates to the field of financial technology or other related technical fields, wherein the method comprises the following steps: generating M test cases based on log data of a financial system; after the source code of the financial system is refactored, performing regression testing on target code obtained by refactoring based on the M test cases to obtain test results of each test case; then, detecting the target code based on the M test cases to obtain uncovered code paths; subsequently, comparing source code segments and target code segments corresponding to the uncovered code paths to obtain code comparison results; and finally, generating a test report based on the test results of each test case and the code comparison results. The application solves the technical problem of low accuracy of testing the refactored code based on traditional regression testing technology.

Description

Technical Field

[0001] This application relates to the field of financial technology or other related technical fields, and more specifically, to a method, apparatus, and electronic device for generating test reports of refactored code. Background Technology

[0002] In the field of fintech, especially in the development and maintenance of core banking systems, code refactoring is an important means to improve system maintainability, performance and scalability. However, core banking systems are characterized by complex business logic, long transaction chains, high coupling and strict data consistency requirements. Even a small logical deviation introduced after code refactoring may lead to serious financial risks or business interruptions. Therefore, how to perform regression testing efficiently and accurately has become a key challenge.

[0003] Currently, existing regression testing solutions in the industry have the following shortcomings: First, recording-based solutions rely on specially recorded data before refactoring, failing to fully utilize existing real-world operational data in the production environment. This leads to a disconnect between test cases and production scenarios, resulting in insufficient test authenticity and coverage. Second, difference-based solutions primarily focus on consistency checks of output results, lacking in-depth analysis of changes at the internal logic level of the code, making it difficult to detect potential semantic deviations. Third, existing AI (Artificial Intelligence)-assisted test code generation solutions focus on generating test code itself, rather than regression verification mechanisms for refactoring scenarios, failing to address the problem of converting production data into test cases. Furthermore, solutions based on test case recommendation and selection mainly address the efficiency of filtering, without fundamentally solving the problems of verifying the authenticity of data sources and uncovered paths. Finally, while existing log analysis solutions utilize log data, they lack intelligent design capabilities for the log printing logic itself, resulting in inconsistent log quality and failing to organically combine the complementary strategies of "production log-driven" and "code logic comparison."

[0004] There is currently no effective solution to the technical problem of low accuracy of test results in the traditional regression testing techniques mentioned above. Summary of the Invention

[0005] This application provides a method, apparatus, and electronic device for generating test reports for refactored code, in order to at least solve the technical problem of low accuracy in testing refactored code based on traditional regression testing techniques.

[0006] According to one aspect of this application, a method for generating test reports for refactored code is provided, comprising: generating M test cases based on log data of a financial system, where M is a positive integer, and the log data is used to characterize the processing information of the financial system for transaction requests; after refactoring the source code of the financial system, performing regression testing on the refactored target code based on the M test cases to obtain the test results of each test case; detecting the target code based on the M test cases to obtain uncovered code paths; comparing the source code segments and target code segments corresponding to the uncovered code paths to obtain code comparison results; and generating a test report based on the test results of each test case and the code comparison results.

[0007] Optionally, before generating M test cases based on the log data of the financial system, the method for generating the test report for code refactoring also includes: deploying a log collection probe in the production environment of the financial system; parsing the abstract syntax tree corresponding to the source code using a pre-defined large model to obtain the key nodes in the abstract syntax tree, wherein the source code represented by the key nodes is at least one of the following types: branch judgment, loop body, exception handling block, database operation, external service call; generating a log printing strategy based on the key nodes in the abstract syntax tree and the code coverage requirements corresponding to the source code; and collecting log data based on the log printing strategy using the log collection probe.

[0008] Optionally, a log printing strategy is generated based on the key nodes in the abstract syntax tree and the code coverage requirements corresponding to the source code, including: generating L sub-strategies based on the key nodes and code coverage requirements, where L is a positive integer, and the L sub-strategies include at least one of the following: a print position sub-strategy, used to determine the print position of log data, where the print position includes the entry and exit points of the key nodes, the exception capture point, and the state change point; a log identification sub-strategy, used to identify P log levels, where P is a positive integer; a log output sub-strategy, used to determine the format of the printed log data based on a preset log template; and using the L sub-strategies as the log printing strategy.

[0009] Optionally, M test cases are generated based on the log data of the financial system, including: parsing the log data to obtain metadata and a log message body, wherein the metadata includes timestamp, log level, thread identifier, class name, and method name, and the log message body is used to represent the log printed text; extracting key fields from the log message body based on the metadata to obtain Q key fields, where Q is a positive integer, and the Q key fields include transaction serial number, request parameters, response result, and intermediate state; classifying all log records included in the log data based on the transaction serial number in the Q key fields to obtain R record sets, and generating R transaction execution trajectories based on the R record sets, where R is a positive integer, and the log records included in each record set belong to the same transaction chain; and generating M test cases based on the Q key fields and R transaction execution trajectories using a pre-set large model.

[0010] Optionally, after refactoring the source code of the financial system, the method for generating a test report for the refactored code further includes: performing a difference analysis on the source code and target code using a pre-set large model to obtain a difference list, wherein the difference list is used to record the source code segments and target code segments that differ before and after the code refactoring; marking the source code segments and target code segments in the difference list with change types to obtain the change types corresponding to the source code segments and target code segments, wherein the change type is one of the following: logical equivalence change, logical optimization change, interface change, data structure change, control flow change; determining the scope of change impact corresponding to the source code segments and target code segments based on the change type; generating a code change impact analysis report based on the scope of impact, change type, and change impact scope, wherein the code change impact analysis report is used to determine the scope of the target code for regression testing.

[0011] Optionally, the source code segment and target code segment corresponding to the uncovered code path are compared to obtain the code comparison result, including: inputting the source code segment and target code segment corresponding to the uncovered code path into a preset large model for semantic reasoning to obtain the first logical description text of the source code segment corresponding to the uncovered code path and the second logical description text of the target code segment; detecting S similarity scores corresponding to the first logical description text and the second logical description text, where S is a positive integer, and the S similarity scores include input constraint consistency score, processing logic consistency score, output mapping consistency score, and boundary behavior consistency score; performing a weighted summation of the S similarity scores to obtain the target similarity score, and determining the code comparison result based on the target similarity score.

[0012] Optionally, a test report is generated based on the test results and code comparison results of each test case, including: determining the risk level and vulnerability remediation suggestions of the target code based on the test results and code comparison results of each test case; and encapsulating the test results, code comparison results, risk level, and vulnerability remediation suggestions of each test case to obtain a test report.

[0013] According to another aspect of this application, a test report generation device for refactored code is also provided, comprising: a test case generation unit, used to generate M test cases based on log data of a financial system, wherein M is a positive integer, and the log data is used to characterize the processing information of the financial system for transaction requests; a regression testing unit, used to perform regression testing on the refactored target code based on the M test cases after refactoring the source code of the financial system, and obtain the test result of each test case; a path detection unit, used to detect the target code based on the M test cases and obtain the uncovered code paths; a code comparison unit, used to compare the source code segment and the target code segment corresponding to the uncovered code path and obtain the code comparison result; and a test report generation unit, used to generate a test report based on the test result of each test case and the code comparison result.

[0014] According to another aspect of this application, a computer program product is also provided, which stores a computer program, wherein a test report generation method is provided to control the computer program product to execute the refactoring code of any of the above-mentioned items during the execution of the computer program.

[0015] According to another aspect of this application, an electronic device is also provided, wherein the electronic device includes one or more processors and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement a test report generation method for refactoring code of any of the above.

[0016] In this application, M test cases are first generated based on the log data of the financial system, where M is a positive integer. The log data is used to characterize the processing information of the financial system for transaction requests. After reconstructing the source code of the financial system, regression testing is performed on the reconstructed target code based on the M test cases to obtain the test results of each test case. Subsequently, the target code is inspected based on the M test cases to obtain the uncovered code paths. Then, the source code segments corresponding to the uncovered code paths and the target code segments are compared to obtain the code comparison results. Finally, a test report is generated based on the test results of each test case and the code comparison results.

[0017] As described above, this application employs a dual verification method combining production log-driven testing and semantic comparison of uncovered paths. First, it generates M regression test cases using the processing logs of transaction requests from the financial system. After source code refactoring, regression testing is performed on the refactored target code based on these M test cases to obtain the test results for each case. Then, based on the test cases, the target code is inspected to identify uncovered code paths. The original source code segments corresponding to these uncovered paths are directly compared with the refactored target code segments to generate code comparison results. This achieves a comprehensive evaluation of the code refactoring quality, ensuring the correctness of regression testing of routine business logic while compensating for the technical deficiency of traditional testing methods in failing to cover the code paths of the refactored target code. This enables the timely detection of potential deep-seated logical deviations in the code, thus solving the technical problem of low accuracy in testing refactored code based on traditional regression testing techniques. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0019] Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a test report generation method for refactored code, according to an embodiment of this application.

[0020] Figure 2 This is a flowchart of an optional method for generating test reports for refactored code according to an embodiment of this application;

[0021] Figure 3 This is a flowchart of an optional regression testing method for refactored code according to an embodiment of this application;

[0022] Figure 4 This is a flowchart of an optional method for collecting production log data according to an embodiment of this application;

[0023] Figure 5 This is a flowchart of an optional test case generation method according to an embodiment of this application;

[0024] Figure 6 This is a flowchart of an optional method for determining code comparison results based on logical semantics, according to an embodiment of this application;

[0025] Figure 7 This is a schematic diagram of an optional test report generation device for refactored code according to an embodiment of this application;

[0026] Figure 8This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0027] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0028] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0029] It should also be noted that all information and data (including but not limited to information used for display and analysis) involved in this application are authorized by the user or fully authorized by all parties. For example, if there is an interface between this system and the relevant user or organization, before obtaining the relevant information, it is necessary to send a request to the aforementioned user or organization through the interface, and obtain the relevant information only after receiving consent from the aforementioned user or organization.

[0030] Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of relevant information and data involved in this application all comply with the relevant laws, regulations, and standards of the relevant regions, and necessary security measures have been taken. They do not violate public order and good morals. In addition, this application provides corresponding operation entry points for users to choose to agree to authorization or refuse authorization. If the user chooses to refuse authorization, the corresponding expert decision-making process will be initiated.

[0031] In one related technical embodiment, a regression testing scheme based on recording and playback is provided. This scheme performs regression testing on the program under test by acquiring the recorded data (including entry call request parameters, request parameters of the target execution method, and response values, etc.) obtained when the program under test is executed. Therefore, this scheme relies on the recording and playback mechanism, but the recorded data needs to be recorded before reconstruction, which cannot make full use of the real running data already available in the production environment.

[0032] In one related technical embodiment, a regression testing scheme based on difference comparison is provided. This scheme obtains a first output result and a second output result and performs a consistency check. When the first output result and the second output result are consistent and the response information is consistent, the reconstruction is determined to be successful. Furthermore, this scheme can also obtain the difference information by obtaining the full work bar information of the old and new versions and comparing the information. Based on the difference information and the automated case template, automated cases for regression verification are assembled. It can be seen that this type of scheme mainly focuses on the comparison of output results and lacks in-depth analysis of changes at the internal logic level of the code.

[0033] In one related technical embodiment, a test code generation scheme based on AI-assisted technology is provided. This scheme uses AI-assisted technology to extract the context of the code to be tested based on an abstract syntax tree, and sends key context information and prompt words to an AI large model to generate test code. In addition, this scheme can also generate unit test code based on structured context data through an agent. It should be noted that this type of scheme focuses on using AI to generate test code itself, rather than regression testing verification for refactoring scenarios.

[0034] In one related technical embodiment, a test case recommendation and selection scheme is provided. This scheme extracts feature vectors through a word embedding model and combines them with grammatical features to recommend regression test cases, thereby achieving automatic generation of test cases. This type of scheme mainly solves the problem of test case screening and generation efficiency.

[0035] In one related technical embodiment, a test script generation scheme based on log analysis is provided. This scheme obtains the source code of the test script from the test script program library, generates test script cases by combining the syntax analysis technology with the system log file, and generates log feature vectors by generating log feature vectors from the log data stored in the system and inputting them into a pre-trained model. Test cases are generated based on the model classification results. Although this type of scheme uses log data, it lacks the AI ​​model's understanding of the log printing logic.

[0036] In summary, the above-mentioned related technical embodiments have the following technical defects:

[0037] (1) Traditional regression testing solutions generally lack a complete mechanism to automatically convert real production environment logs into high-quality regression test cases, especially lacking the ability to use AI to intelligently design log printing logic to improve log quality from the source;

[0038] (2) Traditional regression testing schemes lack effective verification methods for code paths not covered by test cases, and cannot use AI to compare the code logic before and after refactoring to discover potential semantic deviations;

[0039] (3) Traditional regression testing schemes do not organically combine the two complementary verification strategies of production log-driven and code logic comparison, resulting in limited coverage and accuracy of regression testing.

[0040] In view of the above-mentioned technical deficiencies, this application aims to address the following technical issues:

[0041] (1) After code refactoring, regression test cases rely on manual writing or simple recording and playback, which cannot make full use of real running data in the production environment, resulting in test cases being disconnected from the production scenario and insufficient test coverage and authenticity;

[0042] (2) The printing logic of production logs relies on manual design by developers. The completeness, standardization and information content of the logs vary, and there is a lack of AI-assisted intelligent log design mechanism.

[0043] (3) For code paths not covered by test cases, there is a lack of effective regression verification methods, and the consistency of code logic before and after refactoring cannot be fully guaranteed.

[0044] The present invention will now be described in detail with reference to various embodiments.

[0045] Example 1

[0046] According to an embodiment of this application, an embodiment of a test report generation method for refactored code is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0047] The methods and embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a test report generation method for refactored code, according to an embodiment of this application. Figure 1As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0048] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0049] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the test report generation method for reconstructed code in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned test report generation method for reconstructed code. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0050] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0051] The display can be configured as a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0052] In the above operating environment, this application provides a test report generation system for refactored code (hereinafter referred to as the generation system) for executing the test report generation method of the refactored code in this application.

[0053] Figure 2 This is a flowchart of an optional method for generating test reports for refactored code according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0054] Step S201: Generate M test cases based on the log data of the financial system, where M is a positive integer and the log data is used to characterize the financial system's processing information for transaction requests.

[0055] Optionally, the generation system first collects log data from the financial system, then performs log parsing and extracts key fields from the log data to obtain Q key fields. Next, based on the Q key fields, it performs transaction trajectory association operations on the transaction records in the log data to obtain R transaction execution trajectories. Subsequently, it generates M test cases based on the extracted Q key fields and R transaction execution trajectories.

[0056] Optionally, the generation system directly generates test cases using real transaction logs from the production environment. This ensures that the input parameters and expected results in the generated test cases are highly consistent with the actual production scenario. Compared to test cases generated manually, the test cases generated by the generation system based on log data have higher authenticity and effectiveness. They can more accurately reflect the business logic and boundary conditions in the production environment, thereby helping to improve the scenario coverage of regression testing and the accuracy of the final test results. This solves the problem of traditional test data being out of touch with the actual production scenario.

[0057] Step S202: After reconstructing the source code of the financial system, regression testing is performed on the reconstructed target code based on M test cases to obtain the test results of each test case.

[0058] Optionally, the generation system uses automated refactoring tools to refactor the original source code of the financial system to obtain the refactored target code. Then, it deploys the pre-generated M test cases to the test environment, using the refactored target code as the test object, and executes the test cases one by one. During the test execution, the actual running results of each test case are recorded, including the return status code, response data, execution time, and whether an exception is thrown. Furthermore, the actual running results of each test case are compared with the expected output recorded in the test case to determine whether they are consistent. The test case is then marked as "verification passed" or "verification failed", thus obtaining the test result of each test case.

[0059] Optionally, the generation system generates M test cases based on log data from the real production environment to perform regression testing on the refactored target code. Since the test cases come from the real production environment, it can verify whether the refactored target code maintains the original functional correctness when handling real business scenarios. Through automated execution and result comparison, it can discover functional regression defects introduced by code refactoring, ensuring that the refactored target code maintains business logic consistency with the source code before refactoring on the code paths covered by the test cases, which helps to improve the stability of the financial system.

[0060] Step S203: Detect the target code based on M test cases to obtain the uncovered code paths.

[0061] Optionally, the generation system monitors the execution of the target code using a code coverage tool, and calculates the line coverage, branch coverage, and path coverage of the target code by M test cases. Based on the coverage data, it identifies the lines of code that were not executed or traversed by any of the M test cases, the code branches that were not traversed, and the exception handling paths that were not triggered, thereby obtaining the uncovered code paths.

[0062] Optionally, the generation system identifies blind spots in regression testing through code coverage technology. In complex financial core systems, it is difficult to fully cover all code paths in the refactored target code by relying solely on a limited number of test cases. By detecting which logical paths in the target code have not yet been verified, the generation system provides targeted detection targets for subsequent code comparison, which helps reduce the risk of missed tests due to insufficient coverage in traditional regression testing.

[0063] Step S204: Compare the source code segment and target code segment corresponding to the uncovered code path to obtain the code comparison result.

[0064] Optionally, for each uncovered code path identified, the generation system locates the corresponding source code segment in the source code before refactoring and the corresponding target code segment in the target code after refactoring. It uses an AI big data model to perform semantic-level understanding and abstraction of the code segments before and after refactoring, and generates natural language descriptions describing their business logic. Then, the AI ​​big data model compares the original logic description and the target logic description item by item, analyzes the consistency between the two in terms of input constraints, processing logic, output mapping, and boundary behavior, and obtains a semantic consistency score (i.e., target similarity score). Based on this, it determines whether the two code segments are consistent in logical semantics and generates code comparison results that include the degree of semantic difference (such as complete consistency, partial difference, and significant difference).

[0065] Optionally, the generation system compares the source code and target code corresponding to code paths that cannot be covered by regression testing. Even without test case execution, it can determine whether the code refactoring has changed the original business logic semantics of the source code, thereby making up for the inherent limitations of regression testing in code coverage. This helps to discover deep-seated logical risks that test cases cannot reach, and thus improves the accuracy and reliability of the final generated test report.

[0066] Step S205: Generate a test report based on the test results and code comparison results for each test case.

[0067] Optionally, the generation system integrates the execution statistics of test cases and the AI ​​logic comparison results of uncovered code paths by summarizing the test results of M test cases and the code comparison results of uncovered code paths. Combining the number of test cases that failed to execute and the degree of semantic difference represented by the code comparison results, the system comprehensively assesses the risk level of code refactoring. Furthermore, it generates specific repair suggestions for failed test cases and paths with significant semantic differences, and finally outputs a formatted regression test report.

[0068] Optionally, the generation system combines two detection strategies: regression testing based on test case execution results and semantic difference analysis based on uncovered path code. This forms a complete closed-loop regression testing mechanism, enabling the final generated test report to not only provide intuitive test results based on transaction execution trajectories but also a difference analysis mechanism for code logic changes. This helps developers to more comprehensively assess refactoring risks, thereby improving the code quality of the refactored financial system and ensuring its smooth operation.

[0069] As described above, this application employs a dual verification method combining production log-driven testing and semantic comparison of uncovered paths. First, it generates M regression test cases using the processing logs of transaction requests from the financial system. After source code refactoring, regression testing is performed on the refactored target code based on these M test cases to obtain the test results for each case. Then, based on the test cases, the target code is inspected to identify uncovered code paths. The original source code segments corresponding to these uncovered paths are directly compared with the refactored target code segments to generate code comparison results. This achieves a comprehensive evaluation of the code refactoring quality, ensuring the correctness of regression testing of routine business logic while compensating for the technical deficiency of traditional testing methods in failing to cover the code paths of the refactored target code. This enables the timely detection of potential deep-seated logical deviations in the code, thus solving the technical problem of low accuracy in testing refactored code based on traditional regression testing techniques.

[0070] In this embodiment, before generating M test cases based on the log data of the financial system, the generation system first deploys a log collection probe in the production environment of the financial system. The generation system then parses the abstract syntax tree corresponding to the source code using a preset large model to obtain the key nodes in the abstract syntax tree. The source code represented by the key nodes is at least one of the following types: branch judgment, loop body, exception handling block, database operation, and external service call. After that, the generation system generates a log printing strategy based on the key nodes in the abstract syntax tree and the code coverage requirements corresponding to the source code. Then, the generation system collects log data based on the log printing strategy using the log collection probe.

[0071] Optionally, the generation system deploys log collection probes in the production environment and uses a pre-set large model to perform abstract syntax tree parsing on the source code, achieving automatic identification of key nodes in the source code. Then, based on the identified key nodes and code coverage requirements, the generation system automatically generates a log printing strategy, including log printing location, level, and content templates, using the pre-set large model. The log collection probes then guide log data collection based on this strategy, thereby improving the quality of the collected log data. Specifically, the generation system intelligently analyzes the source code structure and generates log printing strategies by calling an AI large model, overcoming the problems of existing technologies where log printing logic relies on manual design by developers, leading to poor log integrity, insufficient standardization, and inconsistent information content. The log printing strategy generated based on key nodes ensures that logs can accurately capture key state changes and abnormal information in the business execution trajectory, improving the integrity of the collected production log data. This lays a solid data foundation for the subsequent automatic generation of high-quality regression test cases based on production logs, solving the technical defect of insufficient accuracy in test case generation caused by low log quality.

[0072] In this embodiment, the generation system first generates L sub-strategies based on key nodes and code coverage requirements, where L is a positive integer. The L sub-strategies include at least one of the following: a print location sub-strategy, used to determine the print location of log data, where the print location includes the entry and exit points of key nodes, the exception capture point, and the state change point; a log identification sub-strategy, used to identify P log levels, where P is a positive integer; and a log output sub-strategy, used to determine the format of the printed log data based on a preset log template. Then, the generation system uses the L sub-strategies as the log printing strategy.

[0073] Optionally, the generation system first refines the log printing strategy, decomposing it into a printing location sub-strategy, a log recognition sub-strategy, and a log output sub-strategy. This enables refined control over the generation of production logs. Specifically, the printing location sub-strategy ensures comprehensive coverage of key log nodes, guaranteeing the integrity of the transaction execution trajectory obtained through subsequent detection. The log recognition sub-strategy defines P log levels to achieve hierarchical management of log information, facilitating the differentiation between normal processes, warning messages, and error messages. The log output sub-strategy standardizes the log format through preset log templates, improving the structure and standardization of log data.

[0074] Optionally, compared to traditional technologies that rely on manual random or coarse log design, the generation system ensures the integrity, standardization, and consistency of log data by setting L sub-strategies. This reduces the difficulty of subsequent log parsing and data extraction, providing a reliable data foundation for automatically generating high-accuracy and high-coverage regression test cases based on production logs. This effectively solves the technical problem of low test case quality caused by non-standard log design, missing information, or chaotic format in existing technologies.

[0075] In this embodiment, the generation system first parses the log data to obtain metadata and a log message body. The metadata includes timestamps, log levels, thread identifiers, class names, and method names. The log message body represents the log print text. Then, the generation system extracts key fields from the log message body based on the metadata, obtaining Q key fields, where Q is a positive integer. The Q key fields include transaction serial number, request parameters, response results, and intermediate states. Next, the generation system classifies all log records in the log data based on the transaction serial number in the Q key fields, obtaining R record sets. Based on the R record sets, it generates R transaction execution trajectories, where R is a positive integer. The log records in each record set belong to the same transaction chain. Subsequently, the generation system generates M test cases based on the Q key fields and R transaction execution trajectories using a preset large model.

[0076] Optionally, the generation system automates the transformation from unstructured logs to standardized regression test cases by parsing log data, extracting key fields, aggregating data based on transaction serial numbers, and generating test cases from a large model. Specifically, the generation system first separates metadata from the log message body through log parsing, using metadata to provide contextual assistance. Simultaneously, it accurately extracts Q key fields from the log message body, including transaction serial numbers, request parameters, response results, and intermediate states, ensuring the authenticity and completeness of the test data. Second, based on transaction serial numbers, the generation system aggregates scattered log records into R record sets and reconstructs them into R transaction execution trajectories, effectively restoring the complex financial transaction chain logic and overcoming the technical shortcomings of fragmented single log information. Finally, the generation system automatically generates M test cases using a pre-set large model combined with key fields and transaction execution trajectories. This automatically identifies normal transactions, boundary conditions, and abnormal scenarios, generating high-quality test cases containing real inputs and expected outputs.

[0077] Optionally, the generation system automatically generates test cases using log data from real-world production environments, avoiding the subjectivity and limitations of manually writing test cases. This improves the representativeness and coverage of test cases. Furthermore, the test cases generated by the system based on transaction execution trajectories can cover the verification of key intermediate states, enabling regression testing to not only focus on the final output but also verify the correctness of internal logic. This effectively solves the technical problems of existing regression testing solutions, such as the disconnect between test data and production scenarios, low test case coverage, and the inability to fully verify the consistency of internal logic in refactored code.

[0078] In this embodiment, after reconstructing the source code of the financial system, the generation system first performs a difference analysis on the source code and target code using a preset large model to obtain a difference list. This difference list records the source code segments and target code segments that differ before and after the code reconstruction. Next, the generation system labels the source code segments and target code segments in the difference list with change types to obtain the corresponding change types. The change type can be one of the following: logical equivalence change, logical optimization change, interface change, data structure change, or control flow change. Then, the generation system determines the scope of impact of the changes corresponding to the source code segments and target code segments based on the change types. Subsequently, the generation system generates a code change impact analysis report based on the scope of impact, change types, and the scope of change impact. This report is used to determine the scope of the target code for regression testing.

[0079] Optionally, the generation system first performs a difference analysis on the source code and target code before and after refactoring using a pre-set large model, generates a difference list, and marks the difference code segments with change types to determine the scope of the change's impact. Finally, it generates a code change impact analysis report, achieving precise quantification and assessment of code refactoring risks. Specifically, the generation system utilizes the semantic understanding capabilities of the large model to not only identify textual differences on the surface of the code but also to deeply understand the semantic types of the changes, particularly distinguishing between logical equivalence and logical optimization. This avoids over-testing changes with no substantial impact, and by determining the scope of impact based on change types, it can accurately identify dependency chains affected by the refactoring.

[0080] Optionally, the generation system provides a clear target scope for regression testing by generating code change impact analysis reports. This allows testing resources to be concentrated on high-risk and affected code areas, avoiding the resource waste associated with full-scale testing. Simultaneously, the refined annotation of change types helps developers quickly understand the refactoring intent and potential risks, especially for high-risk types such as interface changes and control flow changes, enabling focused monitoring. This optimizes the regression testing execution strategy while ensuring system stability, addressing the technical shortcomings of existing technologies such as unclear regression testing scope and ambiguous testing focus.

[0081] In this embodiment, the generation system first inputs the source code segment and target code segment corresponding to the uncovered code path into a preset large model for semantic reasoning, obtaining the first logical description text of the source code segment corresponding to the uncovered code path and the second logical description text of the target code segment. Then, the generation system detects S similarity scores corresponding to the first and second logical description texts, where S is a positive integer. The S similarity scores include input constraint consistency score, processing logic consistency score, output mapping consistency score, and boundary behavior consistency score. Subsequently, the generation system performs a weighted summation of the S similarity scores to obtain the target similarity score, and determines the code comparison result based on the target similarity score.

[0082] Optionally, the generation system first uses a pre-defined large model to perform semantic reasoning on the source code segments and target code segments corresponding to the uncovered code paths, generating natural language descriptions. It then calculates S similarity scores based on four dimensions: input constraints, processing logic, output mapping, and boundary behavior. These scores are then weighted and summed to obtain the target similarity score, determining the code comparison result and achieving deep semantic verification of the uncovered code paths. Specifically, through these steps, the generation system overcomes the limitation of traditional regression testing techniques, which can only verify code paths reachable by test cases. Utilizing the semantic understanding capabilities of the AI ​​large model, it transforms code logic into natural language for item-by-item comparison. Through weighted similarity scores across multiple dimensions (input, logic, output, and boundary), it can comprehensively and quantitatively evaluate the consistency of code logic before and after refactoring, effectively identifying potential logical deviations that test cases cannot reach.

[0083] Optionally, through the above steps, the generation system achieves the technical effect of compensating for the insufficient coverage of traditional regression tests and improving the accuracy of refactoring verification. By introducing an AI logic comparison mechanism, the generation system can discover code paths that have not been covered due to missing test cases but have actually undergone logical changes. It is particularly sensitive to subtle logic optimizations or boundary condition changes. Based on the code comparison results determined by the target similarity score, it can accurately distinguish between completely semantically consistent, partially semantically different, and significantly semantically different, providing developers with clear risk warnings and remediation suggestions. Thus, while ensuring the stability of the core system, it improves the comprehensiveness and reliability of code refactoring regression testing, thereby solving the technical problem of lacking effective verification methods for uncovered paths in existing technologies.

[0084] In this embodiment, the generation system first determines the risk level and vulnerability remediation suggestions of the target code based on the test results and code comparison results of each test case. Then, the generation system encapsulates the test results, code comparison results, risk level and vulnerability remediation suggestions of each test case to obtain a test report.

[0085] Optionally, the generation system comprehensively determines the risk level and vulnerability remediation suggestions of the target code based on the test results and code comparison results of each test case. The risk level can objectively reflect the degree of potential risks introduced by the refactoring, and the vulnerability remediation suggestions can provide developers with clear directions for improvement. Then, the generation system encapsulates this information to generate a test report, realizing a comprehensive evaluation of the code refactoring quality.

[0086] As described above, this application employs a dual verification method combining production log-driven testing and semantic comparison of uncovered paths. First, it generates M regression test cases using the processing logs of transaction requests from the financial system. After source code refactoring, regression testing is performed on the refactored target code based on these M test cases to obtain the test results for each case. Then, based on the test cases, the target code is inspected to identify uncovered code paths. The original source code segments corresponding to these uncovered paths are directly compared with the refactored target code segments to generate code comparison results. This achieves a comprehensive evaluation of the code refactoring quality, ensuring the correctness of regression testing of routine business logic while compensating for the technical deficiency of traditional testing methods in failing to cover the code paths of the refactored target code. This enables the timely detection of potential deep-seated logical deviations in the code, thus solving the technical problem of low accuracy in testing refactored code based on traditional regression testing techniques.

[0087] Figure 3 This is a flowchart of an optional regression testing method for refactored code according to an embodiment of this application, such as... Figure 3 As shown, the method includes the following steps:

[0088] (1) Intelligent collection of production logs and AI log design: Before code refactoring, log data is collected from the refactored code module by a log collection probe deployed in the production environment to obtain a production log dataset containing request parameters, response results, intermediate states and execution paths. At the same time, the source code of the target refactored module is analyzed using an AI big model. The analysis steps include: parsing the abstract syntax tree of the source code; identifying key nodes in the syntax tree (including but not limited to branch judgment nodes, loop body nodes, exception handling block nodes, database operation nodes, and external service call nodes); and generating log printing strategies for the identified key business logic nodes based on the importance of the nodes and the coverage requirements of the execution path.

[0089] (2) Automatic generation of test cases based on production logs: First, the raw log data in the collected production log dataset is preprocessed. Then, the preprocessed log data is input into the AI ​​big model. The AI ​​big model automatically generates corresponding regression test cases based on each transaction execution trajectory and performs classification and labeling.

[0090] (3) Code refactoring execution and change analysis: First, the code refactoring operation is executed to obtain the original code before refactoring and the target code after refactoring. Then, the AI ​​big model is used to perform code difference analysis and semantic understanding on the original code and the target code to generate a code change impact analysis report.

[0091] (4) Regression test execution based on production log test cases: First, the pre-generated test cases are executed on the refactored target code, the execution results of each test case are collected and it is determined whether they are consistent with the expected output, and the code coverage information is recorded.

[0092] (5) AI logic comparison of uncovered code paths: First, based on code coverage information, identify code paths that are not covered by test cases. For each uncovered code path, use the AI ​​big model to perform semantic-level logical comparison analysis on the corresponding code segment in the original code and the corresponding code segment in the target code, calculate the semantic consistency score and classify them.

[0093] (6) Generation of comprehensive regression test report: The test case execution results and AI logic comparison results obtained through the above steps are used to obtain a comprehensive regression test report.

[0094] Figure 4 This is a flowchart of an optional method for collecting production log data according to an embodiment of this application, such as... Figure 4 As shown, the method includes the following steps:

[0095] (1) Deploy the log collection probe: Deploy the log collection probe in the production environment of the target refactoring module and configure the log collection parameters.

[0096] (2) Collect production log data: The log collection probe continuously collects production log data according to the configuration parameters. The collected content includes: log timestamp, log level, thread identifier, class name, method name, log message content, exception stack information, etc.

[0097] (3) Abstract Syntax Tree Parsing and Key Node Identification: The source code of the target refactoring module is parsed using an AI large model to identify key business logic nodes in the source code. The specific steps include: performing lexical and syntactic analysis on the source code to construct a complete abstract syntax tree; traversing the abstract syntax tree to identify condition judgment nodes, loop nodes, exception handling nodes, database operation nodes, external service call nodes, and state change nodes; and scoring the importance of the identified nodes.

[0098] (4) Log printing strategy generation: The AI ​​big data model generates a log printing strategy for each key node based on the node importance score and business logic characteristics, including: Recommended log printing location: at the entry point, exit point, and exception capture point of the key node; Recommended log level: use INFO level for normal business process paths, WARN level for recoverable exceptions, and ERROR level for unrecoverable errors; Recommended log content template: each log contains structured fields such as transaction serial number, business scenario identifier, method name, key variable value, execution time, return code, and error message; Log desensitization strategy: for fields involving sensitive customer information, the AI ​​big data model automatically identifies and marks the fields that need to be desensitized and recommends the corresponding desensitization rules.

[0099] (5) Log printing logic injection: The log printing strategy generated by the AI ​​large model is presented to the developers in the form of code patches or visual suggestions. After the developers review and confirm, the log printing statements are automatically injected into the corresponding positions in the source code through the code injection tool.

[0100] Figure 5 This is a flowchart of an optional test case generation method according to an embodiment of this application, such as... Figure 5 As shown, the method includes the following steps:

[0101] (1) Log data preprocessing, the specific steps include: log parsing: parsing the original log using the log format template; structured field extraction: using regular expressions and predefined structured field templates to extract transaction serial numbers, request parameters, response results, intermediate state variables, etc. from the log content; log association and aggregation: based on the transaction serial number, sorting multiple log records belonging to the same transaction link according to the timestamp and aggregating them into a complete transaction execution trajectory.

[0102] (2) Transaction trajectory feature extraction: For each transaction execution trajectory, extract transaction type features, normal / abnormal features, boundary features, performance features, etc.

[0103] (3) AI large model generates test cases: Based on the preprocessed transaction execution trajectory data, feature information and prompt word template, prompt words are constructed and input into the AI ​​large model. The prompt word template includes: system instruction part, which describes the role and output format requirements of the AI ​​large model; log context part, which provides complete log data of transaction execution trajectory; and generation constraint part, which constrains the input data of test cases to be truly from the log and the expected output to be consistent with the actual results recorded in the log.

[0104] (4) Test case classification and storage: Each generated test case is automatically classified and labeled using the AI ​​big data model. The classification dimensions include: classification by transaction result, classification by business scenario, and classification by priority. The classified test cases are stored in the test case library and sorted by priority to form a regression test case set.

[0105] Figure 6 This is a flowchart of an optional method for determining code comparison results based on logical semantics according to an embodiment of this application, such as... Figure 6 As shown, the method includes the following steps:

[0106] (1) Identify uncovered code paths: Based on the coverage data obtained by the code coverage tool, identify uncovered code paths, including: lines of code that were not executed, code branches that were not traversed, and paths that did not trigger exceptions. Aggregate and deduplicate the identified uncovered code paths to form a list of uncovered code paths.

[0107] (2) Extracting source code and target code segments: For each code path in the list of uncovered code paths, locate the corresponding code segments in the source code and target code respectively according to the code change impact analysis report.

[0108] (3) Semantic-level code understanding: The extracted original code fragments and target code fragments are input into the AI ​​big model respectively. The AI ​​big model performs semantic-level understanding of the two code fragments. The specific steps include: code semantic parsing, which is used to identify variable definitions, data flow relationships, control flow structures, and function call dependencies; and natural language description generation, which is used to convert the business logic semantics of the code fragments into structured natural language descriptions.

[0109] (4) Logical semantic comparison analysis: The AI ​​big model compares the natural language description of the original logic with the natural language description of the target logic item by item. The comparison dimensions include: input constraint comparison, processing logic comparison, output mapping comparison, and boundary behavior comparison.

[0110] (5) Semantic consistency score calculation: The AI ​​large model calculates the semantic consistency score based on the results of logical semantic comparison analysis. The calculation formula is: Score=α×S_input+β×S_logic+γ×S_output+δ×S_boundary, where S_input is the input constraint consistency score, S_logic is the core processing logic consistency score, S_output is the output mapping consistency score, S_boundary is the boundary behavior consistency score, α, β, γ, and δ are the weight coefficients of each dimension, and α+β+γ+δ=1.

[0111] (6) Classification of uncovered paths: Based on the semantic consistency score, uncovered code paths are classified into three levels. The specific steps include: when Score≥Th (high threshold, preferably 0.95), it is judged as "semantic consistency" level; when Tl≤Score<Th (low threshold, preferably 0.80), it is judged as "requires manual review" level; when Score<Tl, it is judged as "key concern" level, thereby summarizing the code comparison results.

[0112] Example 2

[0113] This application embodiment can also provide a test report generation device for refactored code. It should be noted that the test report generation device for refactored code in this application embodiment can be used to execute the test report generation method for refactored code provided in this application embodiment. The test report generation device for refactored code provided in this application embodiment will be described below.

[0114] According to an embodiment of this application, an apparatus for generating test reports for implementing the above-described method for refactoring code is also provided. Figure 7 This is a schematic diagram of an optional test report generation device for refactored code according to an embodiment of this application, as shown below. Figure 7 As shown, the device includes:

[0115] The test case generation unit 701 is used to generate M test cases based on the log data of the financial system, where M is a positive integer, and the log data is used to represent the processing information of the financial system for transaction requests; the regression testing unit 702 is used to perform regression testing on the reconstructed target code based on the M test cases after reconstructing the source code of the financial system, and obtain the test results of each test case; the path detection unit 703 is used to detect the target code based on the M test cases and obtain the uncovered code paths; the code comparison unit 704 is used to compare the source code segments and target code segments corresponding to the uncovered code paths and obtain the code comparison results; the test report generation unit 705 is used to generate a test report based on the test results of each test case and the code comparison results.

[0116] As described above, this device employs a dual verification method combining production log-driven testing and semantic comparison of uncovered paths. First, it generates M regression test cases using the processing logs of financial system transaction requests. After source code refactoring, regression testing is performed on the refactored target code based on these M test cases to obtain the test results for each case. Then, based on these test cases, the target code is inspected to identify uncovered code paths. The original source code segments corresponding to these uncovered paths are directly compared with the refactored target code segments to generate code comparison results. This achieves a comprehensive evaluation of the code refactoring quality. While ensuring the correctness of regression testing of regular business logic, it compensates for the technical deficiency of traditional testing methods in failing to cover the code paths of the refactored target code. This enables the timely detection of potential deep-seated logical deviations in the code, thus solving the technical problem of low accuracy in testing refactored code based on traditional regression testing techniques.

[0117] Optionally, the test report generation device for refactoring code further includes: a probe deployment unit, used to deploy log collection probes in the production environment of the financial system before generating M test cases based on log data from the financial system; a syntax tree parsing unit, used to parse the abstract syntax tree corresponding to the source code using a preset large model to obtain key nodes in the abstract syntax tree, wherein the source code represented by the key nodes is at least one of the following types: branch judgment, loop body, exception handling block, database operation, external service call; a strategy generation unit, used to generate a log printing strategy based on the key nodes in the abstract syntax tree and the code coverage requirements corresponding to the source code; and a log collection unit, used to collect log data based on the log printing strategy using the log collection probes.

[0118] Optionally, the strategy generation unit includes: a strategy generation subunit, used to generate L sub-strategies based on key nodes and code coverage requirements, where L is a positive integer, and the L sub-strategies include at least one of the following: a print location sub-strategy, used to determine the print location of log data, where the print location includes the entry and exit points of key nodes, exception capture points, and state change points; a log identification sub-strategy, used to identify P log levels, where P is a positive integer; a log output sub-strategy, used to determine the format of the printed log data based on a preset log template; and a strategy determination subunit, used to use the L sub-strategies as log printing strategies.

[0119] Optionally, the test case generation unit 701 includes: a log parsing subunit, used to parse log data to obtain metadata and a log message body, wherein the metadata includes timestamp, log level, thread identifier, class name, and method name, and the log message body is used to represent the log printed text; a field extraction subunit, used to extract key fields from the log message body based on the metadata to obtain Q key fields, where Q is a positive integer, and the Q key fields include transaction serial number, request parameters, response result, and intermediate state; a record classification subunit, used to classify all log records included in the log data based on the transaction serial number in the Q key fields to obtain R record sets, and generate R transaction execution trajectories based on the R record sets, where R is a positive integer, and the log records included in each record set belong to the same transaction link; and a test case generation subunit, used to generate M test cases based on the Q key fields and R transaction execution trajectories using a preset large model.

[0120] Optionally, the test report generation device for refactored code further includes: a difference analysis unit, used to perform difference analysis on the source code and target code using a preset large model after refactoring the source code of the financial system, to obtain a difference list, wherein the difference list is used to record the source code segments and target code segments that differ before and after the code refactoring; a type labeling unit, used to label the source code segments and target code segments in the difference list with change types, to obtain the change types corresponding to the source code segments and target code segments, wherein the change type is one of the following: logical equivalence change, logical optimization change, interface change, data structure change, control flow change; a scope determination unit, used to determine the scope of change impact corresponding to the source code segments and target code segments based on the change type; and a change report generation unit, used to generate a code change impact analysis report based on the scope of impact, change type, and change impact scope, wherein the code change impact analysis report is used to determine the scope of the target code for regression testing.

[0121] Optionally, the code comparison unit 704 includes: a semantic reasoning subunit, used to input the source code segment and target code segment corresponding to the uncovered code path into a preset large model for semantic reasoning to obtain the first logical description text of the source code segment corresponding to the uncovered code path and the second logical description text of the target code segment; a scoring detection subunit, used to detect S similarity scores corresponding to the first logical description text and the second logical description text, where S is a positive integer, and the S similarity scores include input constraint consistency score, processing logic consistency score, output mapping consistency score, and boundary behavior consistency score; and a result determination subunit, used to perform a weighted summation of the S similarity scores to obtain the target similarity score, and determine the code comparison result based on the target similarity score.

[0122] Optionally, the test report generation unit 705 includes: a suggestion determination subunit, used to determine the risk level and vulnerability remediation suggestions of the target code based on the test results and code comparison results of each test case; and a report encapsulation subunit, used to encapsulate the test results, code comparison results, risk level and vulnerability remediation suggestions of each test case to obtain a test report.

[0123] It should be noted that units 701 to 705 correspond to steps S201 to S205 in the method embodiments. The instances and application scenarios implemented by the units and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should be noted that the modules or units may be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The modules may also be part of a device and run in the computer terminal 10 provided in the embodiments.

[0124] Example 3

[0125] Embodiments of this application can also provide an electronic device. Figure 8 This is a structural block diagram of an electronic device according to an embodiment of this application, such as... Figure 8 As shown, the electronic device includes: one or more ( Figure 8 (Only one is shown) processor 802, memory 804, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0126] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and devices in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, to realize the above-mentioned method for generating test reports of refactored code.

[0127] The memory may include high-speed random access memory (RAM), and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, which can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks (LANs), mobile communication networks, and combinations thereof.

[0128] The processor can access information and applications stored in memory via a transmission device to execute the following steps: Generate M test cases based on log data from the financial system, where M is a positive integer, and the log data represents the financial system's processing information for transaction requests; After reconstructing the source code of the financial system, perform regression testing on the reconstructed target code based on the M test cases to obtain the test results for each test case; Detect the target code based on the M test cases to identify uncovered code paths; Compare the source code segments and target code segments corresponding to the uncovered code paths to obtain code comparison results; Generate a test report based on the test results of each test case and the code comparison results.

[0129] The processor can access information and applications stored in memory via a transmission device to execute the following steps: Before generating M test cases based on log data from the financial system, deploy a log collection probe in the production environment of the financial system; parse the abstract syntax tree corresponding to the source code using a pre-defined large model to obtain key nodes in the abstract syntax tree, where each key node represents at least one of the following types of source code: branch judgment, loop body, exception handling block, database operation, or external service call; generate a log printing strategy based on the key nodes in the abstract syntax tree and the corresponding code coverage requirements of the source code; and collect log data based on the log printing strategy using the log collection probe.

[0130] The processor can invoke information and applications stored in memory via a transmission device to perform the following steps: generate L sub-strategies based on critical nodes and code coverage requirements, where L is a positive integer, and the L sub-strategies include at least one of the following: a print location sub-strategy for determining the print location of log data, where the print location includes the entry and exit points of critical nodes, exception capture points, and state change points; a log identification sub-strategy for identifying P log levels, where P is a positive integer; a log output sub-strategy for determining the format of the printed log data based on a preset log template; and use the L sub-strategies as the log printing strategy.

[0131] The processor can access information and applications stored in memory via a transmission device to perform the following steps: Parse the log data to obtain metadata and a log message body. The metadata includes timestamps, log levels, thread identifiers, class names, and method names. The log message body represents the log print text. Extract key fields from the log message body based on the metadata to obtain Q key fields, where Q is a positive integer. The Q key fields include transaction serial number, request parameters, response results, and intermediate states. Classify all log records in the log data based on the transaction serial number in the Q key fields to obtain R record sets. Generate R transaction execution trajectories based on the R record sets, where R is a positive integer, and each record set includes log records belonging to the same transaction chain. Generate M test cases based on the Q key fields and R transaction execution trajectories using a pre-defined large model.

[0132] The processor can access information and applications stored in memory via a transmission device to execute the following steps: After refactoring the source code of the financial system, a difference analysis is performed on the source code and target code using a pre-defined large model to obtain a difference list. This difference list records the source code segments and target code segments that differ before and after the code refactoring. The source code segments and target code segments in the difference list are labeled with change types to obtain the corresponding change types. The change type can be one of the following: logical equivalence change, logical optimization change, interface change, data structure change, or control flow change. The scope of impact of the changes corresponding to the source code segments and target code segments is determined based on the change types. A code change impact analysis report is generated based on the scope of impact, change types, and the scope of impact. This report is used to determine the scope of the target code for regression testing.

[0133] The processor can access information and applications stored in memory via a transmission device to perform the following steps: inputting the source code segment and target code segment corresponding to the uncovered code path into a preset large model for semantic reasoning to obtain the first logical description text of the source code segment corresponding to the uncovered code path and the second logical description text of the target code segment; detecting S similarity scores corresponding to the first and second logical description texts, where S is a positive integer, and the S similarity scores include input constraint consistency score, processing logic consistency score, output mapping consistency score, and boundary behavior consistency score; performing a weighted summation of the S similarity scores to obtain the target similarity score, and determining the code comparison result based on the target similarity score.

[0134] The processor can access information and applications stored in memory via a transmission device to perform the following steps: determine the risk level and vulnerability remediation recommendations for the target code based on the test results and code comparison results of each test case; encapsulate the test results, code comparison results, risk level, and vulnerability remediation recommendations for each test case to obtain a test report.

[0135] This application provides a test report generation scheme for refactored code. The scheme employs a dual verification method combining production log-driven testing and semantic comparison of uncovered paths. First, it generates M regression test cases using the processing logs of financial system transaction requests. After source code refactoring, regression testing is performed on the refactored target code based on these M test cases to obtain the test results for each case. Then, based on the test cases, the target code is inspected to identify uncovered code paths. The original source code segments corresponding to these uncovered paths are directly compared with the refactored target code segments to generate code comparison results. This achieves a comprehensive evaluation of the code refactoring quality, ensuring the correctness of regression testing of regular business logic while compensating for the technical deficiency of traditional testing methods in not being able to cover the code paths of the refactored target code. This enables the timely detection of potential deep-seated logical deviations in the code, thus solving the technical problem of low accuracy in testing refactored code based on traditional regression testing techniques.

[0136] Those skilled in the art will understand that Figure 8 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, PDAs, mobile internet devices, PADs, and other terminal devices. Figure 8 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 8 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 8 The different configurations shown.

[0137] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0138] Example 4

[0139] Embodiments of this application may also provide a storage medium.

[0140] Optionally, in this embodiment of the application, the storage medium can be used to store the program code executed by the test report generation method of the refactored code provided in the above method embodiment.

[0141] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0142] This application also provides a computer program product, which, when executed on a data processing device, is suitable for performing test report generation method steps for refactoring code.

[0143] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0144] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0145] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0146] 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.

[0147] Furthermore, 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0148] If the integrated unit 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 this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. 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 a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0149] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for generating test reports for refactored code, characterized in that, include: M test cases are generated based on the log data of the financial system, where M is a positive integer, and the log data is used to characterize the financial system's processing information for transaction requests. After reconstructing the source code of the financial system, regression testing is performed on the reconstructed target code based on the M test cases to obtain the test results for each test case. The target code is tested based on the M test cases to obtain the uncovered code paths; The source code segment and target code segment corresponding to the uncovered code path are compared to obtain the code comparison results; A test report is generated based on the test results of each test case and the code comparison results.

2. The method for generating test reports for refactored code according to claim 1, characterized in that, Before generating M test cases based on log data from the financial system, the method for generating test reports for the refactored code also includes: Deploy log collection probes in the production environment of the financial system; The abstract syntax tree corresponding to the source code is parsed by a preset large model to obtain the key nodes in the abstract syntax tree. The source code represented by the key nodes is at least one of the following types: branch judgment, loop body, exception handling block, database operation, external service call. A log printing strategy is generated based on the key nodes in the abstract syntax tree and the code coverage requirements corresponding to the source code. The log data is collected by the log collection probe based on the log printing strategy.

3. The method for generating test reports for refactored code according to claim 2, characterized in that, A log printing strategy is generated based on the key nodes in the abstract syntax tree and the code coverage requirements corresponding to the source code, including: Based on the key nodes and the code coverage requirements, L sub-strategies are generated, where L is a positive integer, and the L sub-strategies include at least one of the following: The print location sub-policy is used to determine the print location of log data, wherein the print location includes the entry and exit points of the key node, the point of exception capture, and the point of state change; The log identification sub-policy is used to identify P log levels, where P is a positive integer; The log output sub-policy is used to determine the format of the log data to be printed based on a preset log template; The L sub-policies are used as the log printing policy.

4. The method for generating test reports for refactored code according to claim 1, characterized in that, M test cases are generated based on log data from the financial system, including: The log data is parsed to obtain metadata and a log message body. The metadata includes timestamp, log level, thread identifier, class name, and method name. The log message body is used to represent the log print text. Based on the metadata, key fields are extracted from the log message body to obtain Q key fields, where Q is a positive integer. The Q key fields include transaction serial number, request parameters, response result, and intermediate status. Based on the transaction serial number in the Q key fields, all log records included in the log data are classified to obtain R record sets, and R transaction execution trajectories are generated based on the R record sets, where R is a positive integer, and the log records included in each record set belong to the same transaction link; The M test cases are generated based on the Q key fields and the R transaction execution trajectories using a pre-set large model.

5. The method for generating test reports for refactored code according to claim 1, characterized in that, After refactoring the source code of the financial system, the method for generating a test report for the refactored code further includes: By performing a difference analysis on the source code and the target code using a pre-set large model, a difference list is obtained, wherein the difference list is used to record the source code segments and target code segments that have differences before and after the code refactoring. The source code segments and target code segments in the difference list are labeled with change types to obtain the change types corresponding to the source code segments and the target code segments. The change type is one of the following: logical equivalence change, logical optimization change, interface change, data structure change, and control flow change. Determine the scope of impact of the changes corresponding to the source code segment and the target code segment based on the change type; A code change impact analysis report is generated based on the scope of impact, the type of change, and the scope of impact of the change. The code change impact analysis report is used to determine the scope of the target code for regression testing.

6. The method for generating test reports for refactored code according to claim 1, characterized in that, The source code segment and target code segment corresponding to the uncovered code path are compared to obtain the code comparison results, including: Input the source code segment and target code segment corresponding to the uncovered code path into a preset large model for semantic reasoning to obtain the first logical description text of the source code segment and the second logical description text of the target code segment corresponding to the uncovered code path. Detect S similarity scores corresponding to the first logical description text and the second logical description text, where S is a positive integer, and the S similarity scores include input constraint consistency score, processing logic consistency score, output mapping consistency score, and boundary behavior consistency score; The S similarity scores are weighted and summed to obtain the target similarity score, and the code comparison result is determined based on the target similarity score.

7. The test report generation method for refactored code according to claim 1, characterized in that, A test report is generated based on the test results of each test case and the code comparison results, including: Based on the test results of each test case and the code comparison results, the risk level of the target code and vulnerability remediation recommendations are determined; The test results, code comparison results, risk level, and vulnerability remediation suggestions for each test case are encapsulated to obtain the test report.

8. A test report generation device for refactored code, characterized in that, include: The test case generation unit is used to generate M test cases based on the log data of the financial system, where M is a positive integer, and the log data is used to characterize the processing information of the financial system for transaction requests. The regression testing unit is used to perform regression testing on the reconstructed target code based on the M test cases after the source code of the financial system is reconstructed, and to obtain the test results of each test case. The path detection unit is used to detect the target code based on the M test cases to obtain the uncovered code paths; The code comparison unit is used to compare the source code segment and the target code segment corresponding to the uncovered code path to obtain the code comparison result; The test report generation unit is used to generate a test report based on the test results of each test case and the code comparison results.

9. A computer program product, characterized in that, The computer program product includes a computer program, wherein, when the computer program is executed, it controls the computer program product to perform the test report generation method for the refactored code according to any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the test report generation method for refactored code as described in any one of claims 1 to 7.

Images