Author: Xianyu technology — Ask Jin
The background,
Interface in the server’s quality assurance testing has dominated the important role, from the beginning of the manual test code, to write the interface to the subsequent interface based on flow recorded playback, the test efficiency was improved continuously, but the risk assessment is still mainly rely on students to develop and test students familiar with the business level, there is no corresponding tools support, There is no focus when regression, usually full regression, to avoid omission. Therefore, appropriate tools and platforms are developed to accurately determine the change scope of the code, effectively evaluate the impact surface and improve the regression efficiency.
Ii. Program Overview
The server mainly provides HTTP and RPC interfaces externally, which can be regarded as an inbound interface. Traffic recording platforms usually obtain HTTP and RPC level traffic. Therefore, the main solutions are as follows:
Step1: obtain code modification information, including modified code line scope, modified class file, etc., by subscriing to Gitlab messages
Step2: analyze the difference of code and determine which methods are modified according to the range of code lines changed
Step3: obtain the calling link of HTTP and RPC interfaces through the capacity of the traffic recording platform itself, establish the mapping relationship between the method and the inlet interface, and then query the corresponding inlet interface according to the modified method
Step4: obtain the corresponding traffic case through the traffic recording platform. The recorded use cases are HTTP and RPC interface traffic
Step5: establish the mapping relationship between change method and flow use case
Here are four main aspects: code differentiation analysis, method call link resolution, traffic recording, use case association.
Figure 1 Process overview
Iii. Code differentiation analysis
After a code change, we want to know the scope and extent of the code change. The scope of influence includes which interfaces are affected and which applications invoke this interface. The degree of influence refers to whether the interface or application is strongly dependent or core. At present, we have achieved the ability to obtain which interfaces are affected, and we plan to implement the rest in the future. Figure 2 is the overall flow chart of code differentiation analysis.
FIG. 2 Flowchart of differentiation analysis
For code differentiation analysis we currently support Java, Objc, and Flutter. Java parsing uses the open source Java parser. Objc and Flutter implement simple method parsers by their own syntax. Among them, the variable code line range data transmitted by Gitlab is used in the analysis, and the retrieval judgment is made through the code line. Objc and Flutter need to be implemented by themselves. Objc is used as an example to illustrate the specific parsing process:
1. Obtain the changed code file path and code line range according to Git diff information, as shown in Figure 3, the changed code line range is [1200,1207].
Figure 3 Git diff information
2. In Step 1, we can obtain the changed code file path and download the corresponding code file as the data source for parsing
If so, record the number of lines of code as the start line of the current method. At the same time, search up by line to determine whether the method contains the end flag. If so, record the number of lines down as the end line of the previous method. We end up with an AST-like data structure for the code file, which records each method name and its start and end lines in method blocks. For example, Figure 4 shows the corresponding data structure.
Figure 4. Method block data structure
4, according to the Git diff in scope of lines of code changes in the above method to retrieve the data structure, if the range is the method of lines of code blocks line range subset, then hit the method that returns the method name, according to figure 3 code range can be found in the data structure as shown in figure 4 match the method name is getName.
Method call link resolution
Method call link for we use flow recording platform’s ability to provide, but because of obtaining method call link module after the loading effect on the response time of the application is bigger, at present only pretest probability in loading the module, so we need to record the flow rate of the pretest pretest probability of flow for the analysis of the method call link only.
Figure 5 traffic recording and method link acquisition
Figure 5 shows the process of recording the pre-sent traffic and obtaining the method link. After obtaining the pre-sent traffic, we call the API of the traffic recording platform to obtain the methods under the whole call chain through the unique identification ID of the traffic, for example, RPC interface: Com. Idle. Test. The openService @ getInfoII, as shown in figure 6 can obtain corresponding invocation chain information, according to the method of field way to resolve the link list, thus established the method getName, GetAdress with RPC interface com. Idle. Test. The mapping relationship between openService @ getInfoII.
Figure 6 method link acquisition
Four, flow recording
In be used actually we use flow record platform for flow, N days prior to calling for flow through interfaces, specific rules can be configured, because of the traffic itself is nonlinear, part of the flow can be quite large, so we through the dispatching platform of latitude from application, for task scheduling regular execution, guarantee the traffic update, cover more small flow interface, The specific flow chart is shown in Figure 5. However, the recorded traffic is online traffic rather than pre-sent traffic, but the overall flow is the same, and the recorded HTTP and RPC interfaces are the same. Recorded flow as cases stored in the database, such as in the online environment. We recorded the RPC interface com idle. Test. The openService @ getInfoII flow, You can build the RPC interface com. Idle. Test. The openService @ getInfoII the mapping relationship between traffic, falls library to the database when flow is flow id to save, or inconvenience to deal with large amount of data.
Use case association
After the code differentiation analysis, we have obtained the name of the changed method. After the analysis of the call link, we have established the mapping relationship between the changed method and HTTP or RPC interface, so how to associate it with the use case? We record online traffic through a traffic recording platform, establish a mapping relationship between HTTP or RPC interfaces and traffic data, and then establish a mapping relationship between changing methods and traffic use cases. Specifically, first of all, we will accumulate the online traffic information of each application HTTP and RPC, establish the relationship between HTTP and RPC interfaces and traffic, and save the method link information of corresponding interfaces in the database after parsing. At this time, the association between the HTTP or RPC entry and the method in the process of interface invocation is established. After the code changes, we can obtain the changed method name. It can be inferred from the above mapping that the corresponding traffic use case can be found according to the method name. When the project is tested, the change method will be obtained according to the application and the application development branch, and then the corresponding HTTP and RPC methods will be queried. Then the traffic data of the server side will be obtained naturally, and the use-case regression can be triggered. In the whole process, the affected interfaces can be clearly seen, and the corresponding use cases can be implemented. The scope of influence can be assessed through the affected interfaces, so as to have a clear idea, rather than relying on the judgment of the developers, so as to have an accurate assessment of the risk of interface change.
Vi. Effect and prospect
Before did not use precise testing service, the service side interface is changed, we adopt the regression method, according to each application submitted n times a day, n the core application of computing in a week time, single regression time is M, M is usually in a few minutes, so the overall use cases MNn7 regression of the time, and do not have precision; Precision analysis through the code after the full amount back to the way, needn’t to be adopted as long as the corresponding regression, a single interface regression time hypothesis for K, K is generally less than a minute, in a week, for dimension calculation, the overall interface regression time: KNn7, then compared with the overall cost before taking precise testing service time is greatly reduced. Precision test is further extension of the server interface test, in addition to the tests applied to the interface itself accumulate large amounts of data, such as code submitted records, change the method, the distribution of the flow, changes in the way to link to subsequent project risk assessment, such as overall quality forecast, business support service monitoring, etc, And can be used as an infrastructure service to support other testing capabilities.