Test method based on code link dynamic tracking

Abstract

The invention discloses a test method based on code link dynamic tracking. The method comprises the steps of obtaining version difference information of a to-be-tested code from a version library and generating a code test submission list; when a tester initiates a test request, performing flow identification injection on the test request through the front-end agent module and forwarding the test request to the tested application service module; the back-end acquisition module monitors all the tested application service modules in a dynamic code instrumentation mode, and extracts code link calling information of the service modules from all the tested application service modules based on the traffic identifiers; and comparing the code coverage rate of the code link calling information with the code test submission list, determining an abnormal code path based on the code coverage rate and the code link calling information, and generating abnormal information. According to the method, the code coverage rate can be calculated in real time in the process of executing the function test by testers, and the situations that the function test cases are missed and developers carry non-demand codes to be online are avoided.

Description

Technical Field

[0001] The present invention relates to the technical field of code anomaly analysis, and in particular to a testing method based on dynamic tracing of code links. Background Art

[0002] At present, the main statistical method for Java code line coverage in the industry is jacoco. Jacoco can only calculate code coverage for unit test cases, and cannot calculate code coverage for functional test cases. Specifically, in large projects, code changes are frequent, and it is difficult to accurately track the code scope of each test using jacoco. In addition, due to the popularity of front-end and back-end separation architecture, how to implement full-link code execution tracking in distributed systems has also become a thorny issue. More importantly, when an exception occurs, how to quickly filter out key clues from massive execution logs and stack information, and associate them with specific demand points and lines of code, not only involves technical implementation, but also requires consideration of how to balance the comprehensiveness and execution efficiency of the test.

[0003] On the other hand, the exception stack information of traditional systems is mainly analyzed by collecting the logs of the application system under test. This technical solution requires writing a set of log parsing algorithms for different systems under test, and the exception stack information read from the log file can only be queried within a time interval. The read data may not be accurate, and frequent reading of log files may also affect the performance of the system under test. Summary of the invention In view of this, the purpose of the present invention is to propose a testing method based on dynamic tracking of code links, which can solve at least one technical problem mentioned in the background technology.

[0004] According to one aspect of the present invention, a test method based on code link dynamic tracing is provided, the method comprising: Obtain the version difference information of the code to be tested from the version library and generate a code test list; When the tester initiates a test request, the front-end proxy module injects a traffic identifier into the test request and forwards it to the application service module under test; The backend acquisition module monitors all the tested application service modules through dynamic code plugging, and extracts the code link call information of the service modules from all the tested application service modules based on the traffic identifier; The code link call information is compared with the code test list to obtain code coverage, and based on the code coverage and the code link call information, an abnormal code path is determined and abnormal information is generated.

[0005] In the above technical solution, in the software testing process, by analyzing the version difference information, it is possible to efficiently identify the code areas to be tested, thereby avoiding redundant testing of unchanged code, significantly improving the testing efficiency and optimizing resource allocation. The generated code testing list clearly defines the testing scope in a structured form, including key elements such as system name, code file name, file path, and specific modified line numbers, ensuring that testers can focus on key code modules and effectively avoid missing requirement points. The version difference information also provides a historical record of code changes, providing a reliable basis for subsequent problem tracing and analysis.

[0006] Through the traffic identifier injection technology, it is possible to completely trace the call chain of requests, ensuring that the path of each request is accurately recorded and analyzed. The front-end proxy module can flexibly adapt to diverse testing scenarios and requirements by dynamically adjusting request forwarding rules. In a distributed system, the traffic identifier can span multiple service nodes, ensuring the integrity and consistency of cross-service link tracing.

[0007] The dynamic code instrumentation technology can monitor the code execution situation in real time during runtime, capture key information such as method calls, parameters, and return values, providing detailed data support for link tracing. This technology does not require modifying the code and can enable or disable the monitoring function at any time, thus flexibly adapting to different testing requirements. The dynamic instrumentation technology can cover the call chains of all service modules under test, ensuring the comprehensiveness and accuracy of testing.

[0008] By comparing the link information with the code testing list, it is possible to quickly calculate the code coverage rate, ensuring that all key modules are covered by testing. Based on the link information, it is possible to quickly locate abnormal code paths (such as methods with excessive time consumption or throwing exceptions), thereby significantly improving the problem location and repair efficiency. The system can automatically generate exception information and coverage reports, providing intuitive test result feedback to testers and developers, and further optimizing the testing process and problem-solving efficiency. This mechanism not only improves the traceability and transparency of testing but also provides standardized technical support for problem location and performance analysis in a distributed environment.

[0009] In some embodiments, obtaining the version difference information of the code to be tested from the version library and generating a code testing list includes: Obtaining the front and back version data of the code to be tested after it is submitted to the version library, determining the modified code content through difference comparison, generating a code testing list including system name, code file name, code file path, and modified code lines according to the modified code content, and transmitting the code testing list to the test management platform for storage through an interface.

[0010] In the above technical solution, in the software testing process, by obtaining the front and back version data of the code to be tested after it is submitted to the version library, the specific scope of code changes can be efficiently determined. Based on the comparative analysis of the version data, the specific modified content in the code can be accurately identified, providing targeted support for the testing process and improving efficiency. Automated difference comparison reduces the complexity and potential error rate of manual comparison, while significantly improving the comparison efficiency and accuracy.

[0011] The code testing list generated according to the modified code content presents the code change information in a structured form, including key elements such as the system name, code file name, file path, and specific modified line numbers. This list provides comprehensive and clear testing basis for testers, ensuring that testers can clearly understand the code parts to be tested, thus avoiding missing key requirement points.

[0012] Transmitting the code testing list to the test management platform for unified storage constructs a centralized storage and sharing mechanism for test information, providing an efficient collaboration environment for team collaboration. All relevant test information is completely recorded and stored in a structured form, providing reliable data support for subsequent test analysis, report generation, and problem tracing.

[0013] In some embodiments, the tester initiates a test request, and the front-end proxy module injects traffic identification into the test request and forwards it to the application service module under test, including: The tester initiates a test request, and the front-end proxy module intercepts the original message of the test request, adds a test case identifier and a user traffic identifier to the original message to generate a request message with traffic identification, and forwards the request message with traffic identification to the application service module under test for processing.

[0014] In the above technical solution, in the testing process, the tester actively triggers a test request according to the test plan, and the front-end proxy module realizes comprehensive control of the request by intercepting the original request message. By embedding the test case identifier and the user traffic identifier in the original message, it provides key information support for the subsequent tracking and analysis of the request. The unique design of the identification information ensures the clear distinction of different test cases and user traffic, providing an accurate basis for problem tracing and positioning.

[0015] The integration mechanism of the identification information ensures the integrity and accuracy of the request message, facilitating the identification and processing of the application service module under test. The front-end proxy module forwards the request message with identification to the application service module under test. Through the penetration effect of the traffic identification, the call link of the request can be completely traced, ensuring that each request path is accurately recorded and analyzed.

[0016] In a distributed system, traffic identification can span multiple service nodes, ensuring the integrity and consistency of cross-service link tracing. The front-end proxy module realizes comprehensive control and tracing of test requests by injecting and forwarding traffic identification for test requests, ensuring the traceability and transparency of the test process. This mechanism not only improves test efficiency but also provides reliable technical support for problem location and performance analysis in a distributed environment.

[0017] In some embodiments, the back-end collection module listens to all application service modules under test through dynamic code instrumentation, and extracts the code link call information of the service modules from all application service modules under test based on the traffic identification, including: Through dynamic instrumentation technology, the application service module under test is monitored in real time, the test request with traffic identification is intercepted and the traffic identification is extracted and stored in the cache. When calling between service modules, the traffic identification is injected into the subsequent request message, and the call link information of the executed code is obtained and transmitted to the test management platform for storage in the database.

[0018] In the above technical solution, through the coordinated application of dynamic code instrumentation technology and traffic identification mechanism, the back-end collection module can realize real-time monitoring of the code execution status and accurately extract complete call link information. The key advantage of dynamic code instrumentation technology is that it can dynamically inject monitoring code at runtime without modifying the source code, thus adapting to diverse test scenarios and requirements. This technology can monitor the code execution in real time, quickly capture key runtime data including method calls, parameter passing, execution time, etc., and provide accurate problem diagnosis support for developers. Through this non-invasive monitoring method, dynamic code instrumentation technology effectively reduces the dependence on the source code and significantly improves the flexibility and adaptability of testing. The traffic identification mechanism ensures the accuracy and traceability of data collection by assigning a unique identifier to each test request. The identification information is efficiently cached in the memory system for subsequent instant retrieval and processing, thus significantly improving the response performance of the system. When calling between service modules, the traffic identification ensures that it can penetrate the entire call link by injecting the subsequent request message, thus supporting the cross-service link tracing ability. The back-end collection module transmits the obtained call link information of the executed code to the test management platform for structured storage, ensuring that key indicators such as method calls, parameter details, and execution time can be completely recorded. This process not only realizes the centralized management of test data but also provides detailed data support for subsequent test result analysis, performance optimization, and problem tracing.

[0019] In some embodiments, comparing the code link call information with the code test list for code coverage, including: Obtain the running code line data in the code link call information, extract the modified code line data in the code test list, calculate the intersection of the running code line data and the modified code line data, and determine the code coverage rate according to the ratio of the intersection to the modified code line data.

[0020] In the above technical solution, by quantitatively analyzing the intersection of the modified code lines and the test-covered code lines, the code parts covered by the test can be accurately identified, thereby ensuring the comprehensiveness of the test activities and the accuracy of the results. This method effectively quantifies the actual coverage effect of the test by comparing the actual execution path of the tested code with the expected coverage range, and provides clear evaluation indicators for testers.

[0021] In some embodiments, the method further includes: When the code to be tested is stored in the library, through the abstract syntax tree technology, automatically parse the method comments of the code, extract the requirement points and associate them with the corresponding code information; When comparing the code coverage rate, if two requirement points are associated with the same line of code, then when any one of the requirement points causes a change in this line of code, perform a regression test on the other requirement point; Identify the requirement points with a common intersection based on the above rules and generate regression test cases.

[0022] In the above technical solution, the traditional way of associating code with requirement points mainly adopts the method that developers manually associate the requirement points with the functional code when submitting for testing. This method has the following disadvantages: ① There may be cases of missed associations in the manual association method. ② When the amount of code is large, developers need to spend a lot of time on the association work. This method uses the abstract syntax tree technology and, based on the standardized method comment specification, automatically parses the method comments of the code when the code is submitted and stored in the library, and associates the requirement point information with the corresponding code information.

[0023] In addition, by analyzing the mapping relationship between requirement points and code lines, when two requirement points are mapped to the same code line, if a change in one requirement point causes a change in that code line, the system will automatically trigger a regression test for the other requirement point. This mechanism can accurately identify the code correlation between different requirement points, ensure that the test activities cover all potentially affected modules, thus guaranteeing the comprehensiveness of the test and the accuracy of the results. Moreover, when a code change in one requirement point may affect other requirement points, the system automatically triggers a regression test through an automated mechanism to ensure that the code change does not introduce new problems or break existing functions. This mechanism identifies the common intersections between requirement points through rules and automatically generates regression test cases based on these intersections, thereby significantly reducing the need for manual intervention and improving the test efficiency and automation level. This rule-based automated test trigger mechanism not only optimizes the allocation of test resources but also provides reliable technical support for the quality assurance of complex systems.

[0024] In some embodiments, determining an abnormal code path and generating abnormal information based on the code coverage rate and the code link call information includes: Analyze the code lines containing abnormal keywords in the code link call information, extract the subsequent executed code line sequence starting from the code lines to generate an abnormal code path, generate abnormal information according to the abnormal code path and associate it with the corresponding test case.

[0025] In the above technical solution, by identifying the lines containing abnormal keywords in the code, the potential abnormal code positions can be effectively located, thus significantly improving the problem troubleshooting efficiency. On this basis, extracting the subsequent code line sequence starting from the abnormal keyword can completely restore the code execution path when the abnormality occurs, providing comprehensive context information for developers and facilitating the in-depth analysis and diagnosis of problems. The generated abnormal code path not only provides a clear traceability clue but also provides a reliable basis for the subsequent analysis and repair of problems. In addition, by associating the abnormal information with the corresponding test case, it can help testers quickly locate the root cause of the problem and significantly improve the pertinence and efficiency of the test.

[0026] According to another aspect of the present invention, there is provided a test platform based on code link dynamic tracing, including: Version comparison module: used to obtain the version difference information of the code to be tested from the version library and generate a code testing list; Front-end proxy module: used to inject traffic identification into the test request through the front-end proxy module and forward it to the application service module to be tested when the tester initiates a test request; Backend collection module: used to monitor all application service modules under test through dynamic code instrumentation, and extract the code link call information of the service modules from all application service modules under test based on the traffic identifier; Analysis engine module: used to compare the code coverage rate of the code link call information with the code test list, determine the abnormal code path based on the code coverage rate and the code link call information, and generate abnormal information; Test management platform, used to collect, store, and send the information generated by each module.

[0027] In the above technical solution, in order to better use the above method, the present application proposes a test device based on dynamic code link tracing. Each module corresponds to each step of the above method, and its specific principle has been described above and will not be elaborated here.

[0028] According to another aspect of the present invention, there is provided a test device based on dynamic code link tracing, including: At least one processor and a memory communicatively connected to the at least one processor; Wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the above method.

[0029] In the above technical solution, in order to better run and process the method, the above method is stored in the memory, and the processor is used to execute the stored method. It should be noted that the principle and effect of each step have been described above and will not be elaborated here.

[0030] According to still another aspect of the present invention, there is provided a computer-readable storage medium storing a computer program, and the computer program implements the above method when executed by a processor.

[0031] In the above technical solution, in order to better run and use the method, the above method is stored in the computer-readable storage medium, and the processor is used to implement the above method. It should be noted that the principle and effect of each step have been described above and will not be elaborated here. Description of the Drawings

[0032] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present invention, and those of ordinary skill in the art can obtain other drawings without creative efforts based on these drawings.

[0033] Figure 1It is a schematic flowchart of an embodiment of a test method based on code link dynamic tracing according to the present invention; Figure 2 It is a schematic structural diagram of an embodiment of a test system based on code link dynamic tracing according to the present invention. Detailed implementation manners

[0034] The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It should be specifically noted that the following embodiments are only used to illustrate the present invention, but do not limit the scope of the present invention. Similarly, the following embodiments are only partial embodiments of the present invention rather than all embodiments. All other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present invention.

[0035] The present invention provides a test method based on code link dynamic tracing, which can solve at least one technical problem mentioned in the background art.

[0036] Embodiment 1 Please refer to Figure 1 , a test method based on code link dynamic tracing, the method includes: S1. Obtain the version difference information of the code to be tested from the version library and generate a code testing list; In this embodiment, S1. Obtain the version difference information of the code to be tested from the version library and generate a code testing list, including: obtaining the front and back version data of the code to be tested after it is submitted to the version library, determining the modified code content through differential comparison, generating a code testing list including the system name, code file name, code file path and modified code lines according to the modified code content, and transmitting the code testing list to the test management platform for storage through an interface. Specifically: After the developer submits the code to be tested into the version library, during the application compilation process, the version comparison program compares the difference content part in the front and back code versions through the diff method to form a standardized code testing list. The content of the testing list includes the system name, code file name, code file path, modified code lines, version number, code branch, associated requirement point name, and online point involved in the code to be tested this time (the association relationship between the code and the requirement point is established through the annotation method of the standardized code method), and finally submits it to the test management platform for warehousing through the restful interface.

[0037] S2. When the tester initiates a test request, inject traffic identification into the test request through the front-end proxy module and forward it to the application service module to be tested; In this embodiment, in S2, the tester initiates a test request. The front-end proxy module injects traffic identification into the test request and forwards it to the application under test service module, including: the tester initiates a test request, the front-end proxy module intercepts the original message of the test request, adds a test case identifier and a user traffic identifier to the original message to generate a request message with traffic identification, and forwards the request message with traffic identification to the application under test service module for processing. Specifically: The front-end proxy module injects traffic identification by intercepting the original http request from the local browser used by the tester to access the application under test service module, adding the test case flag testcaseId and the user traffic flag userId to the http request message header, and finally forwarding the request to the application under test service module. The httpServer server of the client calls the local browser of the user and initializes and configures the proxy interceptor using HttpProxyServer (including the local browser path, proxy port, and user cache data directory). When the tester executes a functional test case, the identification information of the case and the user is cached in the proxy server through the httpServer and added to the request message header during the request interception and processing. At the same time, the model listener ModuleEventWatcher of the collector listens to and processes all received http request events, and judges whether the request message header carries traffic identification before the code is executed. If it exists, it means that the traffic comes from a test request, and the traffic identification is cached in the local ThreadLocal through LocalCache. When a remote call is generated by the remote call listener, the traffic identification in the ThreadLocal is inserted into the subsequent request message header before the code is executed to achieve traffic pass-through.

[0038] In S3, the back-end collection module listens to all application under test service modules through dynamic code instrumentation, and extracts the code link call information of the service module from all application under test service modules based on the traffic identification; In this embodiment, in S3, the back-end collection module listens to all application under test service modules through dynamic code instrumentation, and extracts the code link call information of the service module from all application under test service modules based on the traffic identification, including: performing real-time listening on the application under test service module through dynamic instrumentation technology, intercepting the test request with traffic identification and extracting the traffic identification and storing it in the cache, injecting the traffic identification into the subsequent request message during the call between service modules, obtaining the call link information of the executed code and transmitting it to the test management platform for storage. Specifically: The backend collection module monitors all service modules of the application under test in real time through dynamic code instrumentation. When the proxy request initiated by the browser enters the application service under test through the gateway, the backend collection module intercepts the proxy request of the first application service A called, then obtains the traffic identifier in the proxy request and writes it into the cache for storage. When application service A is about to initiate a request to the next application service B, the backend collection module will synchronously extract the traffic identifier temporarily written into the cache before and add it to the request header of the call to application service B, so as to achieve the purpose of traffic identifier pass-through. Finally, the backend collection module will submit the code link call information (including code file name, code file path, running code line, associated case name, requirement point name, online point) of different service modules of the application under test to the test management platform through the restful interface for storage. The backend collection module uses the jvm-sandbox dynamic instrumentation technology to intercept requests with traffic identifiers in the Trace monitoring event processor, obtain code call link information such as the method class and execution line number of the executed code through the beforeline method of the monitoring processor adviceListener, and send it back to the test management platform for storage through the sendMessage method, providing basic data for subsequent data analysis.

[0039] S4. Compare the code coverage rate of the code link call information with the code test list, and determine the abnormal code path and generate abnormal information based on the code coverage rate and the code link call information.

[0040] In this embodiment, comparing the code coverage rate of the code link call information with the code test list includes: obtaining the running code line data in the code link call information, extracting the modified code line data in the code test list, calculating the intersection of the running code line data and the modified code line data, and determining the code coverage rate according to the ratio of the intersection to the modified code line data. Specifically: Analyze and compare the modified code lines in the test list with the running code lines obtained by the collection end. The intersection is the code lines running during the test case execution process covering the modified code lines. The code coverage of the overall test process is calculated by the number of lines of code intersection / the total number of modified code lines in the test list*100% (where the modified code lines need to exclude irrelevant information such as blank lines, comment lines, annotation lines, package introduction lines, etc.). Code coverage statistics can be used to find the modified code lines that are not covered during the test case execution process, and then analyze the specific reasons to avoid code inclusion or code omission. The test management platform can effectively analyze the code coverage of each functional test case through the collected data (including all service modules and code lines that pass through the system under test during the execution of each functional test case), check whether the code submitted by the developer for testing is completely covered by the functional test case, and ensure the efficiency and pertinence of the test. When an unknown exception occurs in the application, the backend collector will add a callback function to the exception code path, collect the exception stack information in real time and return it to the developer, greatly simplifying the cost of the developer to locate the problem. At the same time, analyze the association between the codes of each module, timely discover the content affected by the code association, and avoid defects.

[0041] In this embodiment, the method further includes: when the code to be tested is stored in the library, the method annotations of the code are automatically parsed through the abstract syntax tree technology, and the demand points are extracted and associated with the corresponding code information; when comparing the code coverage, if two demand points are associated with the same line of code, when any demand point causes the code line to change, the other demand point is regression tested; based on the above rules, demand points with common intersections are identified, and regression test cases are generated. Specifically: During the backend collection service collection process, the code lines have established associations with test cases and demand points. Assuming that demand points A and B are associated with the same line of code x, when the demand of demand point A changes or the test defect associated with the test case under demand point A is fixed, causing the code line x to change, the test case under demand point B needs to undergo necessary regression testing to ensure that demand point B will not cause defects due to the change in demand point A. The analysis engine module will intelligently identify the content with common intersections of code lines based on the above rules and generate regression test cases. This prevents developers from manually analyzing the impact of code associations and causing omissions.

[0042] The traditional way of associating code with requirement points mainly involves developers manually associating requirement points with functional code when submitting for testing. This method has the following drawbacks: ① There may be cases of missed associations in the manual association process. ② When the code volume is large, developers need to spend a lot of time on the association work. This method uses abstract syntax tree technology. Based on the standardized method annotation specification, when the code is submitted and stored in the repository, it automatically parses the method annotations of the code and associates the requirement point information with the corresponding code information.

[0043] In addition, by analyzing the mapping relationship between requirement points and code lines, when two requirement points are mapped to the same code line, if a change in one requirement point causes a change in that code line, the system will automatically trigger a regression test for the other requirement point. This mechanism can accurately identify the code correlation between different requirement points, ensure that the test activities cover all potentially affected modules, thus guaranteeing the comprehensiveness of the test and the accuracy of the results. Moreover, when a code change for a requirement point may affect other requirement points, the system automatically triggers a regression test through an automated mechanism to ensure that the code change does not introduce new problems or break existing functions. This mechanism identifies the common intersections between requirement points through rules and automatically generates regression test cases based on these intersections, thus significantly reducing the need for manual intervention, improving the test efficiency and automation level. This rule-based automated test trigger mechanism not only optimizes the allocation of test resources but also provides reliable technical support for the quality assurance of complex systems.

[0044] In this embodiment, based on the code coverage rate and the code link call information, an abnormal code path is determined and abnormal information is generated, including: analyzing the code lines containing abnormal keywords in the code link call information, extracting the subsequent executed code line sequence from these code lines to generate an abnormal code path, generating abnormal information according to the abnormal code path and associating it with the corresponding test case. Specifically: During the execution of each test case, a set of code line information will be associated. These code line information are arranged in the execution order. When the analysis engine module analyzes that a certain code line in the code associated with the test case involves abnormal keywords such as throws and exception, it will start from this code line and sequentially extract the subsequent code line information as an abnormal code chain and associate it with the defect corresponding to the test case. Developers can quickly locate the position of the error line for the first time through the abnormal code chain information without starting the local environment or checking the system log, and then continue to analyze the cause of the error.

[0045] By identifying the lines of code containing exception keywords, the potential locations of exception code can be effectively located, thus significantly improving the efficiency of problem troubleshooting. On this basis, extracting the subsequent code line sequence starting from the exception keyword can completely restore the code execution path when the exception occurs, providing comprehensive context information for developers and facilitating in-depth analysis and diagnosis of problems. The generated exception code path not only provides a clear traceability clue but also provides a reliable basis for subsequent problem analysis and repair. In addition, by associating the exception information with the corresponding test cases, testers can quickly locate the root cause of the problem, significantly improving the pertinence and efficiency of testing.

[0046] According to the above embodiments, the present application has the following advantages: 1. Code coverage statistics (1) The traditional method of code coverage statistics mainly uses jacoco for calculation, and this method has the following disadvantages: ① It is limited to unit test scenarios and does not support functional test scenarios.

[0047] ② When dealing with dynamically generated Java code (loading classes and methods dynamically through reflection), jacoco is difficult to track the execution of these dynamically generated parts.

[0048] ③ In complex multi-threaded scenarios, jacoco is difficult to accurately count the code coverage details of each thread.

[0049] (2) Technical innovation point: The present application adopts the method of traffic isolation + traffic pass-through + dynamic instrumentation to associate functional test cases with code lines during the functional test process. At the same time, bytecode enhancement + thread pool technology is used to effectively support dynamically generated Java code and multi-threaded scenarios.

[0050] 2. Method of obtaining exception stack information (1) The traditional method of obtaining exception stack information mainly parses by reading the log information of the system under test, and this method has the following disadvantages: ① The log output formats used by different systems under test are not the same, and a set of log parsing algorithms need to be written for different systems.

[0051] ② The exception information read from the log file can only be queried within a certain time interval, and the data read may not be accurate.

[0052] ③ Frequent reading of the log file may affect the performance of the system under test.

[0053] (2) Technical innovation point: The present system adopts dynamic instrumentation technology to directly intercept and collect exception information at the code bottom layer, and the collected data is accurate and the collection method is universal.

[0054] 3. Association between Code and Requirement Points (1) The traditional way of associating code with requirement points mainly involves developers manually associating requirement points with functional code when submitting for testing. This method has the following drawbacks: ① There may be cases of missed associations in the manual association method.

[0055] ② When the code volume is large, developers need to spend a lot of time on the association work.

[0056] (2) Technical innovation point: This system uses abstract syntax tree technology. Based on the standardized method annotation specification, when the code is submitted and stored in the library, it automatically parses the method annotations of the code, extracts the requirement point information, and associates it with the corresponding code information.

[0057] Embodiment Two Please refer to Figure 2 , a test platform based on dynamic code link tracing. Based on the method described in Embodiment One, it includes: Version comparison module: used to obtain the version difference information of the code to be tested from the version library and generate a code submission list for testing; Front-end proxy module: used to inject traffic identification into the test request through the front-end proxy module and forward it to the application service module under test when the tester initiates a test request; Back-end collection module: used to monitor all application service modules under test through dynamic code instrumentation, and extract the code link call information of the service modules based on the traffic identification; Analysis engine module: used to compare the code coverage of the code link call information with the code submission list, determine the abnormal code path based on the code coverage and the code link call information, and generate abnormal information; Test management platform: used to collect, store, and send the information generated by each module.

[0058] In the above technical solution, in order to better use the method described in Embodiment One, this application proposes a test device based on dynamic code link tracing. Each module corresponds to each step of the above method, and its specific principle has been described above and will not be elaborated here.

[0059] Embodiment Three A test device based on dynamic code link tracing includes: At least one processor and a memory communicatively connected to the at least one processor; Wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method according to one of the embodiments.

[0060] In the above technical solution, in order to better run and process the method, the above method is stored in the memory, and the processor is used to execute the stored method. It should be noted that the principle and effect of each step have been described above, and will not be elaborated here.

[0061] Embodiment Four A computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to one of the embodiments is implemented.

[0062] In the above technical solution, in order to better run and use the method according to one of the embodiments, the above method is stored in a computer-readable storage medium, and the processor is used to implement the above method. It should be noted that the principle and effect of each step have been described above, and will not be elaborated here.

[0063] The above are only some embodiments of the present invention, and thus do not limit the protection scope of the present invention. Any equivalent device or equivalent process transformation made by using the specification and drawings of the present invention, or directly or indirectly applied in other related technical fields, shall equally be included in the patent protection scope of the present invention.

Claims

1. A test method based on dynamic tracking of code links, characterized in that: The method includes: Obtain the version difference information of the code to be tested from the version library and generate a code test list; When the tester initiates a test request, the front-end proxy module injects a traffic identifier into the test request and forwards it to the application service module under test; The backend acquisition module monitors all the tested application service modules through dynamic code plugging, and extracts the code link call information of the service modules from all the tested application service modules based on the traffic identifier; The code link call information is compared with the code test list to obtain code coverage, and based on the code coverage and the code link call information, an abnormal code path is determined and abnormal information is generated.

2. A test method based on code link dynamic tracking as claimed in claim 1, characterized in that: Get the version difference information of the code to be tested from the version library and generate a code test list, including: Obtain the version data before and after the code to be tested is submitted to the version library, determine the modified code content through difference comparison, generate a code submission list containing the system name, code file name, code file path and modified code lines according to the modified code content, and transfer the code submission list to the test management platform for storage through the interface.

3. A test method based on code link dynamic tracking as claimed in claim 1, characterized in that: The tester initiates a test request, injects a traffic identifier into the test request through the front-end proxy module and forwards it to the application service module under test, including: The tester initiates a test request, the front-end proxy module intercepts the original message of the test request, adds the test case identifier and the user flow identifier to the original message to generate a request message with a flow identifier, and forwards the request message with the flow identifier to the application service module under test for processing.

4. A test method based on code link dynamic tracking as claimed in claim 1, characterized in that: The backend acquisition module monitors all the application service modules under test by means of dynamic code insertion, and extracts the code link call information of the service modules from all the application service modules under test based on the traffic identifier, including: Through dynamic instrumentation technology, the application service module under test is monitored in real time, the test request with the traffic identifier is intercepted and the traffic identifier is extracted and stored in the cache. When calling between service modules, the traffic identifier is injected into the subsequent request message, and the call link information of the execution code is obtained and transmitted to the test management platform for storage.

5. A test method based on code link dynamic tracking as claimed in claim 1, characterized in that: Compare the code link call information with the code test list to get code coverage, including: Obtain the running code line data in the code link call information, extract the modified code line data in the code test list, calculate the intersection of the running code line data and the modified code line data, and determine the code coverage rate according to the ratio of the intersection to the modified code line data.

6. A test method based on code link dynamic tracking as claimed in claim 5, characterized in that: The method further comprises: When the code to be tested is stored in the database, the method annotations of the code are automatically parsed through the abstract syntax tree technology, and the requirements are extracted and associated with the corresponding code information; When comparing code coverage, if two requirements are associated with the same line of code, when any requirement causes the code line to change, regression testing is performed on the other requirement; Based on the above rules, demand points with common intersections are identified and regression test cases are generated.

7. A test method based on code link dynamic tracking as claimed in claim 1, characterized in that: Based on the code coverage and the code link call information, an abnormal code path is determined and abnormal information is generated, including: Analyze the code line containing the exception keyword in the code link call information, extract the code line sequence for subsequent execution from the code line to generate an exception code path, generate exception information according to the exception code path and associate it with the corresponding test case.

8. A test system based on code link dynamic tracking, characterized in that: Based on the method according to any one of claims 1 to 7, comprising: Version comparison module: used to obtain version difference information of the code to be tested from the version library and generate a code test list; Front-end proxy module: when the tester initiates a test request, the front-end proxy module injects a traffic identifier into the test request and forwards it to the application service module under test; Backend acquisition module: used to monitor all tested application service modules through dynamic code plugging, and extract the code link call information of the service modules from all tested application service modules based on the traffic identifier; Analysis engine module: used to compare the code link call information with the code test list to obtain code coverage, determine the abnormal code path based on the code coverage and the code link call information, and generate abnormal information; The test management platform is used to collect, store and send the information generated by each module.

9. A test device based on code link dynamic tracking, characterized in that: include: at least one processor and a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images