Reverse backtracking accurate test method and system

Abstract

The invention discloses a reverse backtracking accurate test method and system, and the method comprises the steps: S1, starting a test task, selecting a test submission development branch according to the test task, and triggering the construction of a test task project according to a preset continuous integration tool; s2, obtaining a code difference between the development branch and the main branch; s3, acquiring an interface influenced by the test task; s4, respectively obtaining a dynamic call chain and a static call chain; and S5, generating a calling report. Based on the combination of static code scanning and request logs, the complete influence range of the application can be obtained, the test comprehensiveness is ensured, the regression test cost in the release period is greatly reduced, transformation and adaptation are all carried out based on due infrastructures in the original application, and the related cost is greatly reduced.

Description

Technical Field

[0001] The present invention relates to the field of marketing automation and big data technology in the car rental industry, and in particular to a reverse backtracking precision testing method and system. Background Art

[0002] Reverse backtracking refers to solving the problem of what QA (Quality Assurance, test engineers) actually want to test, avoiding full regression of QA, realizing the evaluation of code changes, making QA regression more targeted, and avoiding the waste of resources of full regression.

[0003] At present, the existing technology uses an observable analysis platform and an application management system to automatically collect the required indicators through probes online in real time for distributed tracking. Through these call chain data, after the application is tested, the corresponding interface of the changed code is matched with the call chain data to obtain the corresponding range. The supporting facilities cost of this method is huge. Under the microservice architecture, each user request may generate a large amount of call chain data, and the call chain data usually needs to be retained for a long time to facilitate fault diagnosis, performance analysis, etc. Even if data compression and aggregation strategies are adopted, a large amount of data retained for a long time will cause the storage cost to continue to increase. The JAVA project itself is invasive. As an external agent, the operation of the observable analysis platform may affect the business logic of the application. If the behavior of the agent is uncontrollable or there are vulnerabilities, it may bring hidden dangers to the security and stability of the application. Summary of the invention

[0004] The purpose of the present invention is to provide a reverse backtracking precision testing method and system. The present invention aims to solve the problem that in the existing reverse backtracking testing method, a large amount of call chain data is generated under the microservice architecture, and the business logic of the application is affected, resulting in huge supporting facility costs and bringing hidden dangers to the security and stability of the application.

[0005] To achieve the above object, the present invention is implemented through the following technical solutions: In one aspect, the present invention provides a reverse backtracking precision testing method for code change testing of a computer program, the method comprising: Step S1: Start a test task, select a development branch for testing according to the test task, and trigger the construction of the test task project according to a predetermined continuous integration tool; Step S2: Compare the code of the development branch with the code of the main branch of the computer program to obtain the code difference between the development branch and the main branch; Step S3: acquiring the interface affected by the test task according to the code difference; Step S4: acquiring a dynamic call chain and a static call chain respectively according to the affected interface; Step S5: According to the dynamic call chain and the static call chain, corresponding upstream and downstream interface links are obtained, and a call report is generated.

[0006] Preferably, the obtaining of the dynamic call chain comprises: obtaining an online interface call chain of the computer program according to the affected interface.

[0007] Preferably, the dynamic call chain is obtained from a request log library of the computer program.

[0008] Preferably, the log data structure of the request log library is designed for use in constructing a dynamic call chain, and the design of the log data structure in the request log library includes: defining a structured log data object, wherein the log data object includes predetermined information.

[0009] Preferably, the predetermined information includes: a globally unique request identifier, a request identifier of the current service, an identifier of a node on the call chain, a current service name, a current host name, a called method name, method input parameters, a method return value, and a log record timestamp.

[0010] Preferably, the obtaining of the static call chain includes: using an automated tool to scan and analyze the code file of the test task to obtain the changed interface calls in the code file.

[0011] Preferably, an automated tool is used to scan and analyze the code file of the test task to obtain the changed interface calls in the code file, which specifically includes: Scanning the code files in the test task project based on the calling class library of the calling interface; Analyze the services called in the code file to obtain analysis results; According to the analysis result, a static call chain is constructed; The constructed static call chain is stored in a database or a file system.

[0012] Preferably, the constructing of the static call chain includes: assembling the analysis results into a directed graph data structure; Each node on the directed graph data structure represents a service, and each edge on the directed graph data structure represents a call relationship between different services; Each node on the directed graph data structure includes: a service name, an interface name and a method signature.

[0013] Preferably, a Git tool and an abstract syntax tree parser are used to dynamically analyze code changes in the computer program, obtain a static call chain after the test task is submitted, and compare it with the static call chain before the test task is submitted to identify the impact of the code file of the test task on the static call chain.

[0014] On the other hand, the present invention also provides a reverse backtracking precision testing system, which is used to implement the above-mentioned reverse backtracking precision testing method.

[0015] Compared with the prior art, the present invention has the following beneficial effects: The reverse backtracking precision testing method and system provided by the present invention, in which static code analysis can scan the entire changed code and identify the interfaces and downstream dependencies affected by the change in all versions; dynamic call chain monitoring can ensure the capture of the call chain of online applications; the combination of the two processing methods can obtain the complete impact range of the application and ensure the comprehensiveness of the test. The cost of regression testing in the release cycle is greatly reduced. The present invention is entirely based on the transformation and adaptation of the infrastructure that should be in the original application, which greatly reduces the relevant costs and increases the possibility of accurate testing in small and medium-sized companies. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solution of the present invention, the following briefly introduces the drawings required for the description. Obviously, the drawings described below are an embodiment of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative work: Figure 1 A flow chart of a reverse backtracking precision testing method provided by one embodiment of the present invention. DETAILED DESCRIPTION

[0017] The following is combined with Figure 1The reverse backtracking precise testing method and system based on static code scanning and request log combined with the specific implementation mode of the present invention are further described in detail. According to the following description, the advantages and features of the present invention will be clearer. It should be noted that the drawings are in a very simplified form and use non-precise proportions, which are only used to conveniently and clearly assist in explaining the purpose of the implementation mode of the present invention. In order to make the purposes, features and advantages of the present invention more obvious and easy to understand, please refer to the drawings. It should be noted that the structure, proportion, size, etc. illustrated in the drawings of this specification are only used to match the contents disclosed in the specification for people familiar with this technology to understand and read, and are not used to limit the limiting conditions for the implementation of the present invention, so they have no technical substantive significance. Any modification of the structure, change of the proportional relationship or adjustment of the size, without affecting the effects that the present invention can produce and the purposes that can be achieved, should still fall within the scope of the technical content disclosed in the present invention.

[0018] On the one hand, reference Figure 1 As shown, this embodiment provides a reverse backtracking precision testing method, which is based on the combination of static code scanning and request logs and is used for code change testing of computer programs. The method includes: Step S1: Start a test task, select a development branch for testing according to the test task, and trigger the construction of the test task project according to a predetermined continuous integration tool.

[0019] Step S2: Compare the code of the development branch with the code of the main branch of the computer program to obtain the code difference between the development branch and the main branch.

[0020] Step S3: According to the code difference, the interface affected by the test task is obtained.

[0021] Step S4: According to the affected interface, a dynamic call chain and a static call chain are obtained respectively.

[0022] About obtaining dynamic call chains: The method of obtaining the dynamic call chain includes: obtaining the online interface call chain of the computer program according to the affected interface. The dynamic call chain is obtained in the request log library of the computer program. This method is applicable to various request log libraries, and has no requirements for technical hardware or supporting frameworks, and can be implemented in the request log library transformation of any small or medium-sized technical team; but the log library needs to have the following content to ensure the construction of a basic call chain. The log data structure of the request log library is designed for building a dynamic call chain. The design of the log data structure in the request log library includes: defining a structured log data object, and the log data object includes predetermined information.

[0023] 1) Log data structure design, define a structured log data object to ensure that it records key information. The required fields are as follows. The predetermined information includes: globally unique request identifier traceId, request identifier requestId of the current service, identifier parentId of a node on the call chain, current service name serviceName, current host name hostName, called method name methodName, method input parameters, method return value returnValue and log record timestamp. Use JSON format to store log data for subsequent analysis and query.

[0024] 2) The logging part can be implemented in many ways, such as AOP (Aspect-Oriented Programming), interceptor or decorator mode, but it is guaranteed that the request sent can be connected into a complete call chain through traceId, requestId and parentId.

[0025] 3) It supports searching and restoring the entire call chain from the log data based on the request URL, request method, traceId, or requestId, etc., and displays the key information of each interface on the call chain, such as method name, time consumption, input parameters, return value, etc.

[0026] 4) There are no special requirements for log storage, either traditional MySQL database or Elasticsearch can be used.

[0027] The design of most request log libraries in the existing technology is not much different from that of this article, and the functions are basically similar. Therefore, the adoption of this method has very great universality. Basically, any slightly complete software system will have the function of recording request logs, which is convenient for querying online problems. Therefore, there is no additional technical cost, operation and maintenance cost, and storage cost, which saves huge expenses compared with the teams on the market that use observable platforms such as skywalking.

[0028] About obtaining static call chains: In this embodiment, the technology stack is JAVA, and the class library of the calling interface used is openFeign of springboot. All called services have corresponding fixed serviceName to refer to the URL of the corresponding service to ensure the consistency of everyone's writing. If you want to use other interface calling class libraries when you land, you only need to ensure that the writing is consistent and that the same service has a fixed identifier. Based on the above premise, perform the following operations: The acquisition of the static call chain includes: using an automated tool to scan and analyze the code file of the test task to obtain the changed interface calls in the code file. Specifically, it includes: based on the calling class library of the calling interface, scanning the code file in the test task project; analyzing the services called in the code file to obtain the analysis results; and constructing the static call chain according to the analysis results.

[0029] The construction of the static call chain includes: assembling the analysis results into a directed graph data structure; each node on the directed graph data structure represents a service, and each edge on the directed graph data structure represents the call relationship between different services; each node on the directed graph data structure includes: service name, interface name and method signature.

[0030] The constructed static call chain is stored in a database or file system, and query and analysis are supported based on conditions such as service name and interface name.

[0031] Using Git tools and abstract syntax tree parsers, dynamically analyze the code changes in the computer program, obtain the static call chain after the test task is submitted, and compare it with the static call chain before the test task is submitted to identify the impact of the code file of the test task on the static call chain. This solves the problem that the interface added and changed by the user in the version iteration will also have an online call chain that cannot be queried, avoiding omissions in the test scope assessment. In this embodiment, it specifically includes:

[0032] Using the git tool used for code submission, as well as java ast technology and open source java-callgraph and other related technologies, after given the git commitId of this submission and the current online commitId, perform the following operations: Get Git repository information Use the Git API or Git command-line tool to get the repository's commit log and file changes; record the Java file changes involved in each commit.

[0033] Parse the Java file structure and use the Java AST (Abstract Syntax Tree) parser to parse the changed Java files and extract the structural information such as classes, methods, variables, etc. in each Java file.

[0034] Build a static call chain and use the Java-Callgraph library to build a method call relationship graph based on the structural information of the Java file. Focus on the interface annotated with @FeignClient and analyze its call chain.

[0035] Analyze the impact scope, compare the call relationship graphs before and after each submission, identify the affected Controller interfaces and @FeignClient calls, and output the affected Controller interfaces and @FeignClient calls for each changed Java file.

[0036] Step S5: According to the dynamic call chain and the static call chain, corresponding upstream and downstream interface links are obtained, and a call report is generated.

[0037] The following is an introduction to the above method using a specific example: Suppose there is a microservice application that recently needs to modify one of its core interfaces. Use the above method to help the QA team analyze the impact of this interface change. The steps are as follows:

[0038] 1. Code change submission: The developer modified the implementation logic of the core interface and submitted the code change.

[0039] 2. After the packaging tool triggers static code analysis and the developer submits the test package, the packaging tool automatically triggers static code analysis. The static analysis tool scans the changed Java files, uses JavaFileParser to parse the abstract syntax tree, and uses CallGraphAnalyzer to build the call graph of the entire application. Finally, the call graph is analyzed to identify the Controller interface and @FeignClient calls affected by the change.

[0040] 3. Pull the dynamic call chain. According to the affected Controller interface and @FeignClient call, use the dynamic call chain library to further pull the corresponding online interface call chain to obtain the upstream and downstream change interfaces of the corresponding core interface.

[0041] 4. Collect and summarize the corresponding complete change reports and push them to the corresponding QA (test engineer) for analysis and evaluation of the test impact scope, and trigger the corresponding interface automation use cases.

[0042] The entire process described above can realize the reverse tracing process of the entire precision test at a relatively low cost. At the same time, the entire process does not require the introduction of any class library, and there is no additional maintenance cost for the project.

[0043] On the other hand, this embodiment also provides a reverse backtracking precision testing system, which is used to implement the above-mentioned reverse backtracking precision testing method.

[0044] In summary, this embodiment is based on a reverse backtracking precision testing method and system that combines static code scanning and request logs. Static code analysis can scan the entire changed code and identify the interfaces and downstream dependencies affected by the change in all versions. Dynamic call chain monitoring can ensure that the call chain of online applications is captured. The combination of the two methods can obtain the complete impact range of the application and ensure the comprehensiveness of the test. The steps of static analysis and dynamic analysis are automated and integrated into the CI / CD (Continuous Integration / Continuous Delivery / Continuous Deployment) process, and analysis can be triggered immediately every time the code changes. Obtain a detailed impact analysis report before release for the QA team to conduct targeted testing, greatly reducing the cost of regression testing in the release cycle. For small and medium-sized enterprises, the cost of database and request log library is unavoidable regardless of whether precise testing is required. However, for such technical teams, the number of operation and maintenance personnel is relatively small. In the prior art, a complete online monitoring system is built for online applications, and the application image needs to be modified and integrated into the online jvm environment. The maintenance cost is huge, which consumes online application memory and increases online instability. At the same time, the relevant data of massive requests is limited by the requirements of such monitoring frameworks and needs to be completely stored in the specified storage medium, and such storage medium itself also requires additional operating costs. The method introduced in the above embodiment is all based on the transformation and adaptation of the infrastructure that should be in the original application, which greatly reduces the relevant costs and increases the possibility of precise testing in small and medium-sized companies.

[0045] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0046] It should be noted that the devices and methods disclosed in the embodiments of this article can also be implemented in other ways. The device implementation described above is only schematic. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to multiple embodiments of this article. In this regard, each box in the flowchart or block diagram can represent a part of a module, program or code, and the module, program segment or part of the code contains one or more executable instructions for implementing the specified logical function, and the module, program segment or part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart can be implemented by a dedicated hardware-based system for performing a specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0047] Although the content of the present invention has been described in detail through the above preferred embodiments, it should be appreciated that the above description should not be considered as a limitation of the present invention. After reading the above content, it will be apparent to those skilled in the art that various modifications and substitutions of the present invention will occur. Therefore, the protection scope of the present invention should be limited by the appended claims.

Claims

1. A reverse backtracking precision testing method, characterized in that: It is used for code change testing of computer programs, and the method comprises: Step S1: Start a test task, select a development branch for testing according to the test task, and trigger the construction of the test task project according to a predetermined continuous integration tool; Step S2: Compare the code of the development branch with the code of the main branch of the computer program to obtain the code difference between the development branch and the main branch; Step S3: acquiring the interface affected by the test task according to the code difference; Step S4: acquiring a dynamic call chain and a static call chain respectively according to the affected interface; Step S5: According to the dynamic call chain and the static call chain, corresponding upstream and downstream interface links are obtained, and a call report is generated.

2. The reverse backtracking precision testing method according to claim 1, characterized in that: The obtaining of the dynamic call chain includes: obtaining an online interface call chain of the computer program according to the affected interface.

3. The reverse backtracking precision testing method according to claim 2, characterized in that: The dynamic call chain is obtained from a request log library of the computer program.

4. The reverse backtracking precision testing method according to claim 3, characterized in that: The log data structure of the request log library is designed to be used for building a dynamic call chain. The design of the log data structure includes: defining a structured log data object, and the log data object includes predetermined information.

5. The reverse backtracking precision testing method according to claim 4, characterized in that: The predetermined information includes: a globally unique request identifier, a request identifier of the current service, an identifier of a node on the call chain, the current service name, the current host name, the name of the called method, method input parameters, method return value and log record timestamp.

6. The reverse backtracking precision testing method according to claim 5, characterized in that: The obtaining of the static call chain includes: using an automated tool to scan and analyze the code file of the test task, and obtaining the changed interface calls in the code file.

7. The reverse backtracking precision testing method according to claim 1, characterized in that: Using automated tools to scan and analyze the code files of the test tasks and obtain the changed interface calls in the code files, which specifically includes: Scanning the code files in the test task project based on the calling class library of the calling interface; Analyze the services called in the code file to obtain analysis results; According to the analysis result, a static call chain is constructed; The constructed static call chain is stored in a database or a file system.

8. The reverse backtracking precision testing method according to claim 7, characterized in that: The constructing of the static call chain includes: assembling the analysis results into a directed graph data structure; Each node on the directed graph data structure represents a service, and each edge on the directed graph data structure represents a call relationship between different services; Each node on the directed graph data structure includes: a service name, an interface name and a method signature.

9. The reverse backtracking precision testing method according to claim 7, characterized in that: Using Git tools and abstract syntax tree parsers, the code changes in the computer program are dynamically analyzed to obtain the static call chain after the test task is submitted, and the static call chain is compared with the static call chain before the test task is submitted to identify the impact of the code file of the test task on the static call chain.

10. A reverse tracing precision testing system, characterized in that: It is used to implement the reverse tracing precision testing method described in any one of claims 1-9.

Images