A test method and device for reconstructing code, an electronic device, and a storage medium

Abstract

This invention provides a testing method, apparatus, electronic device, and storage medium for refactored code, belonging to the field of software engineering technology. The method includes: performing full-link testing on target code based on a first test case to obtain reference data characterizing the behavioral features of the target code; refactoring the target code to obtain refactored code; injecting a coloring identifier into the data traffic of the first test case to generate a second test case, the coloring identifier being used to control the target traffic corresponding to the second test case during the testing process; performing full-link testing on the refactored code based on the second test case to obtain comparison data characterizing the behavioral features of the refactored code; and generating test results for the refactored code based on the reference data and the comparison data. Using this invention can improve the delivery quality and efficiency of refactored code testing.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, and in particular to a method, apparatus, electronic device, and storage medium for testing refactored code. Background Technology

[0002] In software development, code refactoring is an important means of improving software quality and optimizing software performance. However, code refactoring is often accompanied by a large amount of regression testing to ensure that the refactored code is functionally correct and performs stably.

[0003] Traditional testing methods often rely on a large number of test cases and automated testing tools. However, in actual testing work, although some automated testing tools can generate test cases, traditional automated testing techniques often test on a module-by-module basis, lacking comprehensive coverage of the entire process chain. This may lead to the omission of some cross-module interaction issues during the testing process. Due to frequent changes in requirements and the complexity of interactions between modules in different processes, the code before refactoring often has a lot of special historical logic. Test cases and automated tests designed based on the refactored code are prone to inconsistencies between upstream and downstream interactions, database writes, and historical logic.

[0004] Therefore, how to prepare these tests within a limited time and improve the delivery quality and efficiency of refactored code tests is an urgent problem to be solved in the field of software testing. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a method, apparatus, electronic device, and storage medium for testing refactored code, which can improve the delivery quality and efficiency of refactored code testing.

[0006] According to one aspect of the present invention, a testing method for refactored code is provided, the method comprising: Based on the first test case, perform full-link testing on the target code to obtain reference data characterizing the behavioral features of the target code; After refactoring the target code, the refactored code is obtained; A coloring identifier is injected into the data traffic of the first test case to generate a second test case. The coloring identifier is used to control the target traffic corresponding to the second test case during the test. Based on the second test case, perform full-link testing on the refactored code to obtain reference data characterizing the behavioral features of the refactored code; Based on the reference data and the comparison data, test results for the refactored code are generated.

[0007] According to another aspect of the present invention, a testing apparatus for refactoring code is provided, the apparatus comprising: The reference data acquisition unit is used to perform full-link testing on the target code based on the first test case and acquire reference data characterizing the behavioral features of the target code. The refactoring unit is used to refactor the target code and obtain the refactored code. A test case generation unit is used to inject a coloring identifier into the data traffic of the first test case to generate a second test case. The coloring identifier is used to control the target traffic corresponding to the second test case during the test process. The reference data acquisition unit is used to perform full-link testing on the refactored code based on the second test case and acquire reference data characterizing the behavioral features of the refactored code. The result generation unit is used to generate test results for the reconstructed code based on the reference data and the comparison data.

[0008] According to another aspect of the present invention, an electronic device is provided, comprising: Processor; and Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the test method for the refactored code.

[0009] According to another aspect of the present invention, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to execute the test method of the refactored code.

[0010] In this invention, a full-link test is performed on the target code based on a first test case to obtain reference data characterizing the behavioral features of the target code. After obtaining the refactored code, a coloring identifier is injected into the data traffic of the first test case to generate a second test case. A full-link test is then performed on the refactored code based on the second test case to obtain control data characterizing the behavioral features of the refactored code. By comparing the reference data and the control data, test results for the refactored code can be generated. Because the full-link test is performed based on test cases—meaning the test cases are fully automated—and both the reference and control data are at the behavioral level, the generation of test cases comprehensively covers the entire process chain, and the control test delves into the code behavior. This allows for efficient and accurate identification of potential problems in the refactored code, ensuring the quality of the refactored code. Attached Figure Description

[0011] Further details, features, and advantages of the invention are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1A flowchart of a test method for refactored code provided according to an exemplary embodiment of the present invention is shown; Figure 2 A schematic block diagram of a testing apparatus for refactoring code provided according to an exemplary embodiment of the present invention is shown; Figure 3 A structural block diagram of an exemplary electronic device that can be used to implement embodiments of the present invention is shown. Detailed Implementation

[0012] Embodiments of the present invention will now be described in more detail with reference to the accompanying drawings. While some embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the invention. It should be understood that the accompanying drawings and embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the invention.

[0013] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0014] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this invention are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0015] It should be noted that the terms "one" and "more" used in this invention are illustrative rather than restrictive. Those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0016] The names of the messages or information exchanged between the multiple devices in the embodiments of the present invention are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0017] This invention provides a testing method for refactored code, which can be performed by a terminal, server, and / or other devices with processing capabilities. The method provided in this invention can be performed by any of the aforementioned devices, or by multiple devices working together; this invention does not limit this.

[0018] The following will refer to Figure 1 The flowchart illustrating the testing method for the refactored code is shown below, and the method is described. The method includes the following steps 101-105.

[0019] Step 101: Perform full-link testing on the target code based on the first test case to obtain reference data characterizing the behavioral features of the target code.

[0020] In one possible implementation, full-link testing can be performed on the target code (i.e., the original code before refactoring) based on a pre-built first test case. The first test case is a fully automated test case that comprehensively covers the target code's business logic, execution path, data processing flow, and interface interaction behavior. A fully automated test case refers to an automated test case that uses the software business layer as the entry point and connects to a complete business process executed by a user within the software.

[0021] During end-to-end testing, information on the runtime behavior of the target code when processing test requests is collected, including but not limited to: API call chain, parameter passing content, data processing logic, execution branch selection, database read and write operations, intermediate processing results, and final output results.

[0022] Based on the collected runtime behavior information, reference data is generated to characterize the behavior features of the target code during normal operation, serving as benchmark data for subsequent code consistency verification during refactoring.

[0023] Optionally, before performing full-link testing on the target code based on the first test case, the process of generating the first test case can be as follows: whenever the target code is tested, the first test case is generated based on the test case generation strategy.

[0024] In one possible implementation, whenever full-link testing of the target code is required, a first test case covering the target code's business logic, execution path, and interface interaction is automatically generated according to a preset test case generation strategy. This ensures that the test cases can meet the requirements for collecting behavioral characteristics of the target code, achieving comprehensive coverage of the target code and the refactored code.

[0025] Step 102: After refactoring the target code, obtain the refactored code.

[0026] In one possible implementation, developers may refactor the target code to improve software quality and optimize performance. The code refactoring process can be used to optimize the internal structure, execution logic, or runtime performance of the target code, including but not limited to code structure adjustments, logic simplification, redundant code cleanup, modular decomposition, and underlying implementation optimization. Furthermore, the refactoring process does not change the business functions, interface definitions, data processing rules, or overall behavioral logic provided by the target code, ensuring that the refactored code maintains functional consistency, behavioral consistency, and result consistency with the target code.

[0027] To ensure the refactored code is functionally correct and performs stably, the refactored code is obtained for testing.

[0028] Step 103: Inject a coloring identifier into the data traffic of the first test case to generate the second test case.

[0029] Among them, the coloring identifier is used to control the target traffic corresponding to the second test case during the testing process.

[0030] In one possible implementation, a preset coloring identifier is injected into the data traffic corresponding to the first test case to generate a second test case for testing the refactored code. The coloring identifier can be used to uniquely identify the data traffic corresponding to the second test case and is carried throughout the entire data traffic transmission process to enable tracking, routing, and scheduling of the data traffic.

[0031] By adding coloring markers to the traffic of the original test cases, a second test case corresponding to the first test case can be obtained without changing the business logic, input parameters, execution flow and expected results of the test cases.

[0032] Optionally, before injecting the coloring identifier into the data traffic of the first test case, corresponding traffic coloring rules can be set based on the business requirements and traffic protocols of the refactored code. Correspondingly, based on the traffic coloring rules, the coloring identifier can be injected into the data traffic of the first test case to generate the second test case.

[0033] In one possible implementation, before injecting coloring tags into the data traffic of the first test case, corresponding traffic coloring rules can be pre-set based on the actual business requirements of the refactored code and the protocol specifications followed by the data traffic. The traffic coloring rules must be adapted to the business scenario of the refactored code (such as coloring distinctions between core and non-core business links) and match the traffic protocol format (such as protocol field lengths, the location of injectable tags, and tag transmission rules). The generation format, injection location, transmission method, and identification standard of the coloring tags must be clearly defined to ensure that the coloring tags can be stably transmitted and accurately identified throughout the entire refactored code testing process, without affecting the normal transmission and data processing of the test traffic.

[0034] Correspondingly, when generating the second test case, the pre-defined traffic coloring rules are strictly followed. Coloring identifiers that conform to the rules are precisely injected into the data traffic corresponding fields of the first test case to complete the conversion from the first test case to the second test case. This ensures that the second test case retains the test coverage of the first test case on the target code and is also traceable, which can meet the needs of traffic monitoring and behavior feature collection in the full-link test of refactored code.

[0035] Step 104: Perform full-link testing on the refactored code based on the second test case to obtain reference data that characterizes the behavioral features of the refactored code.

[0036] In one possible implementation, a second test case corresponding to the first test case is used to perform full-link testing on the refactored code. The data traffic of the second test case carries a pre-injected color identifier, which can be passed between the processing nodes of the refactored code along with the test traffic. This color identifier is used to uniquely distinguish and track the test traffic, avoid interference with other business traffic in the system, and ensure the independence of the testing process and the accuracy of the data.

[0037] During the execution of the end-to-end test, the runtime behavior information generated by the refactored code when processing the test traffic is collected. Based on the collected runtime behavior information, reference data is generated to characterize the actual runtime behavior of the refactored code, so as to compare the consistency with the reference data obtained in step 101.

[0038] Optionally, control data for the control test can be generated by monitoring the changes in the data flow of the injected staining marker during the transmission process. The corresponding processing can be as follows: The refactored code is subjected to full-link testing based on the second test case. During the test, the changes of the second test case in the traffic transmission process are monitored based on the coloring identifier, and the comparison data characterizing the behavior of the refactored code are obtained based on the monitoring results.

[0039] In one possible implementation, the refactored code undergoes end-to-end testing based on a second test case. During the test, the coloring identifier carried by the second test case serves as a tracking identifier. The data traffic corresponding to that test case is monitored throughout the end-to-end transmission of the refactored code, and the transmission status, flow path, and change information of the data traffic in each processing stage, calling node, and module interaction process are acquired in real time. Based on the monitoring results of the coloring identifier and the corresponding traffic, behavioral information of the refactored code during the test process is collected, thereby generating reference data to characterize the actual behavioral features of the refactored code.

[0040] Step 105: Based on the reference data and comparison data, generate test results for the refactored code.

[0041] In one possible implementation, reference data characterizing the behavior of the code before refactoring is compared with control data characterizing the behavior of the code after refactoring. Based on the consistency or difference in the running behavior of the two, it is determined whether the refactored code maintains the same behavioral logic as the target code, and test results are generated to determine whether the refactored code meets the expectations.

[0042] Optionally, the specific processing in step 105 above may include: By comparing the reference data with the control data, the differences between the refactored code and the target code in terms of traffic transmission, data processing, and execution chain are determined. Based on the difference information, the behavioral consistency between the refactored code and the target code is evaluated, and the test results of the refactored code are obtained.

[0043] In one possible implementation, a difference comparison operation (diff operation) is performed between the reference data and the control data. The two sets of data are compared and matched item by item in multiple dimensions such as traffic transmission path, data processing process, execution link structure, intermediate processing results and final output results. The inconsistent content between the two is identified and extracted to obtain the corresponding difference information.

[0044] Based on this difference information, it can be determined whether the refactored code maintains the same business logic and running behavior as the target code, verify whether the refactoring optimizes the internal structure of the code without changing the external functions and processing rules, and finally evaluate the results of behavioral consistency.

[0045] Furthermore, this discrepancy information can pinpoint the specific module, processing node, or execution stage in the refactored code where behavioral deviations occur, clarifying the location and cause of the discrepancy.

[0046] Furthermore, based on the aforementioned behavioral consistency assessment results and problem location results, test results containing consistency conclusions, difference details, and problem location information can be generated.

[0047] Therefore, it is evident that through refined, link-level diff operations, not only can the differences between the refactored code and the target code be identified, but the source of these differences can also be precisely traced. This allows the test results to both verify behavioral consistency and guide the fixing of issues in the refactored code. Thus, it solves the problem that traditional testing methods primarily focus on whether the code's functional output is correct, failing to pinpoint the root cause of exceptions.

[0048] Further optionally, test results can be fed back in real time, and based on the behavioral information of inconsistencies between the refactored code and the target code included in the test results, the problems in the refactored code can be located and optimized.

[0049] In one possible implementation, after completing the difference comparison and problem localization, the test results, including behavioral consistency conclusions, difference information, and problem localization information, can be fed back to the user in real time. Based on the behavioral information recorded in the feedback results regarding inconsistencies between the refactored code and the target code, the user can quickly locate the specific module, processing node, or execution stage in the refactored code that exhibits anomalies. Accordingly, the user can make targeted corrections and optimizations to the refactored code, ensuring that the refactored code ultimately maintains consistent operational behavior and business logic with the target code.

[0050] Alternatively, after generating the test results for the refactored code, the test case generation strategy can be adjusted based on the test results to adapt the adjusted test case generation strategy to the scenarios and requirements of the refactored code.

[0051] In one possible implementation, after generating test results for the refactored code, the test case generation strategy can be adaptively adjusted based on the test results, so that the adjusted test case generation strategy can better fit the running scenario and testing requirements of the refactored code, thereby improving the test coverage and verification accuracy when testing the refactored code in the future.

[0052] Alternatively, after generating test results for the refactored code, the traffic coloring rules can be adjusted based on the test results to improve the accuracy of the injected coloring identifiers.

[0053] In one possible implementation, after generating the test results for the refactored code, the existing traffic coloring rules can be adaptively adjusted based on the behavioral consistency conclusions, discrepancy information, and problem localization obtained from this test. By updating the generation format, injection location, identification method, or transmission logic of the coloring identifiers, the adjusted traffic coloring rules can be made more suitable for the business scenarios, traffic protocols, and link structures of the refactored code, thereby improving the accuracy and reliability of subsequent traffic tracking, monitoring, and behavioral data collection.

[0054] This embodiment can achieve the following beneficial effects: (1) Perform full-link testing on the target code based on the first test case to obtain reference data characterizing the behavioral features of the target code. After obtaining the refactored code, inject coloring markers into the data traffic of the first test case to generate the second test case. Perform full-link testing on the refactored code based on the second test case to obtain comparison data characterizing the behavioral features of the refactored code. By comparing the reference data and the comparison data, the test results of the refactored code can be generated. Since the full-link testing is performed based on the test cases, that is, the test cases are full-link automated test cases, and both the reference data and the comparison data are at the behavioral level, the generation of test cases fully covers the process link and the comparison test delves into the code behavior, which can efficiently and accurately identify potential problems in the refactored code and ensure the quality of the refactored code.

[0055] (2) Provide real-time feedback of test results to developers to help them adjust and optimize the code in a timely manner, thereby reducing development costs and risks.

[0056] (3) Adapt to different refactoring scenarios and needs, and achieve flexible testing of different refactored code by adjusting the test case generation strategy and traffic coloring rules.

[0057] This invention provides a testing apparatus for refactored code, which is used to implement the aforementioned testing method for refactored code, such as... Figure 2 As shown, the testing device 200 for the refactored code includes: a reference data acquisition unit 201, a refactoring unit 202, a test case generation unit 203, a comparison data acquisition unit 204, and a result generation unit 205.

[0058] The reference data acquisition unit 201 is used to perform full-link testing on the target code based on the first test case and acquire reference data characterizing the behavioral features of the target code. Reconstruction unit 202 is used to reconstruct the target code and then obtain the reconstructed code; The test case generation unit 203 is used to inject a coloring identifier into the data traffic of the first test case to generate a second test case. The coloring identifier is used to control the target traffic corresponding to the second test case during the test process. The reference data acquisition unit 204 is used to perform full-link testing on the refactored code based on the second test case and acquire reference data characterizing the behavioral features of the refactored code. The result generation unit 205 is used to generate test results for the reconstructed code based on the reference data and the comparison data.

[0059] Optionally, the comparison data acquisition unit 204 is used for: The refactored code is subjected to full-link testing based on the second test case. During the test, the changes of the second test case in the traffic transmission process are monitored based on the coloring identifier, and the comparison data characterizing the behavior features of the refactored code are obtained based on the monitoring results.

[0060] Optionally, the result generation unit 205 is used for: The reference data is compared with the comparison data to determine the differences between the reconstructed code and the target code in traffic transmission, data processing, and execution chain. Based on the difference information, the behavioral consistency between the refactored code and the target code is evaluated, and the test results of the refactored code are obtained.

[0061] Optionally, the result generation unit 205 is further configured to: The test results are fed back in real time, and based on the behavioral information of inconsistencies between the refactored code and the target code included in the test results, the problems of the refactored code are located and optimized.

[0062] Optionally, the reference data acquisition unit 201 is further configured to: generate a first test case based on a test case generation strategy whenever the target code is tested; The device further includes a strategy adjustment unit, which is used to: adjust the test case generation strategy based on the test results, so that the adjusted test case generation strategy adapts to the scenario and requirements of the refactored code.

[0063] Optionally, the test case generation unit 203 is further configured to: set corresponding traffic coloring rules based on the business requirements and traffic protocols of the refactored code; The test case generation unit 203 is used to: inject a coloring identifier into the data traffic of the first test case based on the traffic coloring rule, and generate a second test case; The device further includes a rule adjustment unit, which is used to adjust the traffic coloring rules based on the test results to improve the accuracy of the injected coloring identifiers.

[0064] This embodiment can achieve the following beneficial effects: Based on the first test case, end-to-end testing is performed on the target code to obtain reference data characterizing its behavior. After obtaining the refactored code, coloring markers are injected into the data traffic of the first test case to generate a second test case. Based on the second test case, end-to-end testing is performed on the refactored code to obtain control data characterizing its behavior. By comparing the reference data and the control data, the test results for the refactored code can be generated. Because end-to-end testing is performed based on test cases—meaning the test cases are fully automated—and both the reference and control data are at the behavioral level, the generation of test cases comprehensively covers the entire process chain, and the control testing delves into the code behavior. This allows for efficient and accurate identification of potential problems in the refactored code, ensuring its quality.

[0065] An exemplary embodiment of the present invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the electronic device to perform a method according to an embodiment of the present invention.

[0066] An exemplary embodiment of the present invention also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of the present invention.

[0067] An exemplary embodiment of the present invention also provides a computer program product, including a computer program, wherein, when executed by a computer's processor, the computer program is used to cause the computer to perform a method according to an embodiment of the present invention.

[0068] refer to Figure 3 The present invention will now be described in the form of a structural block diagram of an electronic device 300 that can serve as a server or client of the present invention, which is an example of a hardware device that can be applied to various aspects of the present invention. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0069] like Figure 3As shown, the electronic device 300 includes a computing unit 301, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 302 or a computer program loaded from a storage unit 308 into a random access memory (RAM) 303. The RAM 303 may also store various programs and data required for the operation of the device 300. The computing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0070] Multiple components in electronic device 300 are connected to I / O interface 305, including: input unit 306, output unit 307, storage unit 308, and communication unit 309. Input unit 306 can be any type of device capable of inputting information to electronic device 300. Input unit 306 can receive input digital or text information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 307 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 308 may include, but is not limited to, disk and optical disk. Communication unit 309 allows electronic device 300 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth devices, Wi-Fi devices, WiMax devices, cellular communication devices, and / or the like.

[0071] The computing unit 301 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 301 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 301 performs the various methods and processes described above. For example, in some embodiments, the above-described method for testing the refactored code can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 308. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 300 via ROM 302 and / or communication unit 309. In some embodiments, the computing unit 301 can be configured to perform the above-described method for testing the refactored code by any other suitable means (e.g., by means of firmware).

[0072] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0073] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0074] As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0075] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0076] The systems and technologies described herein can be implemented in computing systems that include back-end components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0077] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

Claims

1. A testing method for refactored code, characterized in that, The method includes: Based on the first test case, perform full-link testing on the target code to obtain reference data characterizing the behavioral features of the target code; After refactoring the target code, the refactored code is obtained; A coloring identifier is injected into the data traffic of the first test case to generate a second test case. The coloring identifier is used to control the target traffic corresponding to the second test case during the test. Based on the second test case, perform full-link testing on the refactored code to obtain reference data characterizing the behavioral features of the refactored code; Based on the reference data and the comparison data, test results for the refactored code are generated.

2. The method according to claim 1, characterized in that, The step of performing full-link testing on the refactored code based on the second test case to obtain reference data characterizing the behavioral features of the refactored code includes: The refactored code is subjected to full-link testing based on the second test case. During the test, the changes of the second test case in the traffic transmission process are monitored based on the coloring identifier, and the comparison data characterizing the behavior features of the refactored code are obtained based on the monitoring results.

3. The method according to claim 1, characterized in that, The step of generating test results for the refactored code based on the reference data and the comparison data includes: The reference data is compared with the comparison data to determine the differences between the reconstructed code and the target code in traffic transmission, data processing, and execution chain. Based on the difference information, the behavioral consistency between the refactored code and the target code is evaluated, and the test results of the refactored code are obtained.

4. The method according to claim 3, characterized in that, The method further includes: The test results are fed back in real time, and based on the behavioral information of inconsistencies between the refactored code and the target code included in the test results, the problems of the refactored code are located and optimized.

5. The method according to claim 1, characterized in that, Before performing full-link testing on the target code based on the first test case, the method further includes: generating the first test case based on the test case generation strategy whenever the target code is tested; After generating the test results for the refactored code, the method further includes: adjusting the test case generation strategy based on the test results so that the adjusted test case generation strategy adapts to the scenario and requirements of the refactored code.

6. The method according to claim 1, characterized in that, Before injecting the coloring identifier into the data traffic of the first test case, the method further includes: setting corresponding traffic coloring rules based on the business requirements and traffic protocols of the refactored code; The step of injecting a coloring identifier into the data traffic of the first test case to generate a second test case includes: injecting a coloring identifier into the data traffic of the first test case based on the traffic coloring rule to generate a second test case; After generating the test results of the refactored code, the method further includes: adjusting the traffic coloring rules based on the test results to improve the accuracy of the injected coloring identifiers.

7. A testing apparatus for refactoring code, characterized in that, The device includes: The reference data acquisition unit is used to perform full-link testing on the target code based on the first test case and acquire reference data characterizing the behavioral features of the target code. The refactoring unit is used to refactor the target code and obtain the refactored code. The test case generation unit is used to inject a coloring identifier into the data traffic of the first test case to generate a second test case. The coloring identifier is used to control the target traffic corresponding to the second test case during the test process. The reference data acquisition unit is used to perform full-link testing on the refactored code based on the second test case and acquire reference data characterizing the behavioral features of the refactored code. The result generation unit is used to generate test results for the reconstructed code based on the reference data and the comparison data.

8. The apparatus according to claim 7, characterized in that, The result generation unit is used for: The reference data is compared with the comparison data to determine the differences between the reconstructed code and the target code in traffic transmission, data processing, and execution chain. Based on the difference information, the behavioral consistency between the refactored code and the target code is evaluated, and the test results of the refactored code are obtained.

9. An electronic device, comprising: processor; as well as Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 1-6.

10. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-6.

Images