CN109062785B

CN109062785B - Interface parameter constraint code positioning method and system

Info

Publication number: CN109062785B
Application number: CN201810738453.2A
Authority: CN
Inventors: 蔡华谦; 黄罡; 张颖; 黄震; 景翔
Original assignee: Peking University
Current assignee: Peking University
Priority date: 2018-07-06
Filing date: 2018-07-06
Publication date: 2021-03-19
Anticipated expiration: 2038-07-06
Also published as: CN109062785A

Abstract

The invention discloses a method and a system for positioning interface parameter constraint codes, wherein in a constraint code entry positioning stage, code coverage data in a system client side under the scene of preset input parameters are collected, selective instrumentation is carried out on the system client side according to the code coverage data to insert a probe, then the instrumented system client side is operated and the scene is demonstrated to trigger reading of interface parameters and execution of the probe, current function call stacks and input control meta-information are printed through the probe, and an entry function of the interface parameter constraint codes is positioned according to the current function call stacks and the input control meta-information. In the key code positioning stage, function call relations starting from the entry functions in a scene are collected in a program instrumentation mode, and key code analysis is performed on each function according to the function call relations so as to position all constraint codes related to the interface parameters. The invention effectively solves the problem of positioning the interface parameter constraint code, thereby helping a developer to screen out the code which is really closely related to the parameter constraint.

Description

Interface parameter constraint code positioning method and system

Technical Field

The invention relates to computer software, in particular to a method and a system for positioning interface parameter constraint codes.

Background

In the big data era, data and functions in an information system are served so as to realize the opening, sharing and fusion of the data, and the method has very important significance. At present, a common form of servitization is to open functions and data of a system through a Web Application Programming Interface (Web API). In order to ensure that the normal operation of the original system is not affected after the service is implemented, necessary parameter constraint must be carried out on the API interface. However, a large number of information systems are developed without considering the need of servitization, original system developers do not perform strict parameter constraint when developing interfaces, constraint check of the server side on parameters is not complete enough, and even the server side does not check at all and only relies on parameter check in the client side. In order to ensure correctness of the servitization, a processing program needs to be written in the Web API to realize parameter constraint of the client. The most straightforward way to write a handler is to locate the interface parameter constraint code in the client of the original system, which is used as a reference.

The location process of the interface parameter constraint code presents two challenges:

1) code entry is difficult to locate:

the binding relationship between the parameter input control and the event processing function is complex, and the event processing process is difficult to track and position, so that a developer is difficult to position the entrance of the constraint code.

2) The key code is difficult to locate:

irrelevant statements and external function calls usually exist in the constraint code fragments, and a developer has difficulty in locating key statements really relevant to parameter constraints.

Disclosure of Invention

The invention mainly aims to provide a method and a system for positioning interface parameter constraint codes, which are used for solving the problem that the interface parameter constraint codes are difficult to position when a processing program is written in the process of serving data and functions in an information system in the prior art.

The invention is realized by the following technical scheme:

an interface parameter constraint code positioning method comprises the following steps:

step A: collecting code coverage data in a system client under the scene of preset input parameters;

and B: selectively instrumenting the system client to insert probes based on the code coverage data;

and C: running the instrumented system client, demonstrating the scene to trigger reading of interface parameters and execution of the probe, and printing out current function call stack and input control meta information by the probe;

step D: according to the function call stack and the input control meta information, positioning an entry function of an interface parameter constraint code;

step E: acquiring a function call relation starting from the entry function in the scene in a program instrumentation mode;

step F: and reading codes of the system client and the function call relation, skipping and browsing among functions according to the codes, and analyzing key codes of each function to locate all constraint codes related to the interface parameters.

Further, the step a includes:

step A1: code coverage data C1 when the scene is not demonstrated and code coverage data C2 when the scene is demonstrated are obtained after the system is initialized;

step A2: the difference between C1 and C2 was calculated and the difference between C1 and C2 was taken as the code coverage data.

Further, in the step B, the range of the selective instrumentation is limited to the code executed in the scene, and the position of the instrumentation is limited to the program operation point where it is possible to read the interface parameters.

Further, in the step C, keywords are set before the scene is demonstrated, and when interface parameters including the keywords are read, the probe prints out the current function call stack and the input control meta information.

Further, in the step E, the code range of the program instrumentation is limited to the code executed in the scene, and the position of the instrumentation is the program operation point of the function call.

An interface parameter constrained code location system comprising:

the code coverage data collection module is used for collecting code coverage data in the system client under the scene of preset input parameters;

an instrumentation module to selectively instrumentation the system client to insert probes based on the code coverage data; when the system client side after pile insertion runs and demonstrates the scene, triggering and reading interface parameters and executing the probe, and printing out the current function call stack and input control meta information by the probe;

the interface parameter constraint code entry function positioning module is used for positioning an entry function of the interface parameter constraint code according to the function call stack and the input control meta information;

the instrumentation module is further used for acquiring a function call relation starting from the entry function in the scene in a program instrumentation mode;

the positioning system further comprises:

and the key code analysis module is used for reading codes of the system client and the function calling relation, skipping and browsing among functions according to the codes, and performing key code analysis on each function so as to locate all constraint codes related to the interface parameters.

Further, the code coverage data collection module is specifically configured to:

code coverage data C1 when the scene is not demonstrated and code coverage data C2 when the scene is demonstrated are obtained after the system is initialized; and

the difference between C1 and C2 was calculated and the difference between C1 and C2 was taken as the code coverage data.

Further, the scope of the selective instrumentation is limited to code executed under the scenario, and the location of the instrumentation is limited to program operating points where it is possible to read interface parameters.

Further, when the interface parameters containing the preset keywords are read, the probe prints out the current function call stack and the input control meta information.

Further, the code range of the program instrumentation is limited to the code executed in the scene, and the position of the instrumentation is the program operation point of the function call.

Compared with the prior art, in the constraint code entry positioning stage, code coverage data in the system client side under the scene of preset input parameters are collected, selective instrumentation is carried out on the system client side according to the code coverage data to insert the probe, then the instrumented system client side is operated and the scene is demonstrated to trigger reading of the interface parameters and execution of the probe, current function call stack and input control meta-information are printed out through the probe, and an entry function of the interface parameter constraint code is positioned according to the current function call stack and input control meta-information. In the key code positioning stage, function call relations starting from the entry functions in a scene are collected in a program instrumentation mode, and key code analysis is performed on each function according to the function call relations so as to position all constraint codes related to the interface parameters. The invention effectively solves the problem that the interface parameter constraint code is difficult to locate when writing the processing program in the process of serving the data and the functions in the information system in the prior art, thereby helping a developer to screen out the code which is really closely related to the parameter constraint.

Drawings

FIG. 1 is a general flow of an interface parameter constraint code location method provided by the present invention;

FIG. 2 is an example of the solution of an intra-function parameter impact data flow equation;

FIG. 3 is an overall framework diagram of a key code analysis tool;

FIG. 4 is a control flow graph example;

FIG. 5 is a schematic diagram of a specific flowchart of a method for locating code constrained by interface parameters according to the present invention;

FIG. 6 is a schematic diagram of the interface parameter constraint code positioning system provided by the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention will be further described in detail with reference to the following embodiments and the accompanying drawings.

Interpretation of terms:

serving: the data and functions in the information system are provided in the form of services.

Web API: the network access interface provided by information systems is typically based on the HTTP protocol and transmits data via JSON or XML format.

Interface parameters: and the client side in the information system provides parameters when communicating with the server side through the Web API.

And (3) parameter constraint: the information system limits the allowed values of the interface parameters can be divided into type constraints and value range constraints.

Constraint code entry: entry function for constraint checking of parameters in information system client code

Constraint key code: in the information system client code, irrelevant variables and statements are eliminated, and then the code really relevant to parameter constraint is obtained.

The interface parameter constraint code positioning method provided by the invention mainly comprises two stages: a constraint code entry location phase and a key code location phase. The target of the constraint code entry positioning stage is to assist a developer to efficiently and quickly position an entry of a required parameter constraint code from complex codes of a client, and the entry is used as a starting point of the whole code positioning process. The key code positioning stage aims to assist developers to further understand and position the key code which restricts parameters in the original system client.

The general flow of the interface parameter constraint code positioning method provided by the invention is shown in fig. 1, and the steps are described as follows:

step 1, presetting a scene of input parameters

The constraint on the interface parameters can be regarded as a function in the system client, and when the code of the function is positioned, a scene needs to be designed according to actual needs. Taking account registration functions of most systems as an example, when a user registers, various information such as an account, a password, and the like needs to be filled in, and if a code segment for restricting the parameters needs to be located, a scene for inputting account registration information needs to be designed. In order to cover as many program branches as possible, the designed scenario should try to trigger multiple parameter constraints.

Step 2, collecting code coverage data of system client under scene

In the scenario, the constraint code of the interface parameters is executed, and the part of the code is really concerned by the developer. All executed codes in the scene can be analyzed and obtained through a code coverage rate testing tool. While other parts of the code in the system client, such as initialization code executed before the scene, and code of other functions not executed in the scene, will not be recorded.

Step 3, demonstrating the scene again after the original system client is inserted with the pile

Based on the code coverage data collected in step 2, the client of the original system can be selectively instrumented: the scope of instrumentation is limited to code executed in the scene, and the location of the instrumentation is limited to the program operating points where it is possible to read the parameters. After the pile insertion is completed, the system client after pile insertion needs to be operated, and the scene is demonstrated again.

Step 4, positioning interface parameter constraint code entry function

When the scene is presented again, the constraint code of the interface parameters is triggered again. At this time, since the program operation point for reading the parameter is instrumented, the instrumented probe is triggered accordingly, and the probe mainly functions to print out the current function call stack and the meta information of the relevant input control. The entry function of the constraint code can be located by querying the function call stack and the meta-information of the input control. In order to facilitate the positioning process, the pile inserting information can be filtered according to the actual parameter input.

Step 5, collecting the function call relation from the entrance function in the scene

When checking parameter constraints in a scene, it is possible to involve the invocation of several other functions, starting from the entry function of the constraint code. For example, a developer of the original system may invoke some third-party library to perform operations such as calculation, conversion, etc. on the parameters; in addition, in order to realize a better code structure, an original system developer may extract different sub-constraints as independent functions, and then perform parameter constraint check in a function call mode. In order to perform more comprehensive constraint code positioning, it is necessary to collect function call relations starting from an entry function in a scene. Considering that different language platforms may have characteristics of polymorphism, functional programming and the like, it is difficult to obtain the true situation of the function call only by static analysis, so it is necessary to collect this part of information by using program instrumentation. At this time, the code range of program instrumentation is also limited to code executed in the scene, but the location of the instrumentation becomes the program operating point of the function call. The function call information collected at this step will be exported to a database or file for use in subsequent steps.

Step 6, selecting a function for analysis

And starting a server side of the Web-based key code analysis tool, and accessing a front-end page of the key code analysis tool through a browser. And (5) reading the codes of the original system client and the function call relation data collected in the step (5) by the server, and returning the codes to the front-end page, wherein the front-end page displays the source codes in a visual interface. The front end provides two jumping modes based on function calling relation and text search, and the two modes can be used for jumping and browsing between functions. When focusing on a specific function, a variable name can be input, and the key code analysis tool calculates and highlights sentences possibly influenced by the variable in the function according to a static data stream analysis method. Only the highlighted code, particularly the branch statements involved therein, needs to be concerned, so that the key statements related to the parameter constraint can be quickly located.

7. Determining whether all constraint codes are found

Step 6 mainly discusses the code positioning condition in one function, if the constraint of the parameters in the original system relates to a plurality of functions, step 6 needs to be repeated, and the respective key statements are positioned in different functions, so as to obtain the constraint code which is as complete as possible.

Among the above steps, step 1 is a preparation stage, steps 2, 3 and 4 are constraint code entry positioning stages, and steps 5, 6 and 7 are key code positioning stages. According to the general flow of the interface parameter constraint code positioning method, the specific steps of the interface parameter constraint code positioning method of the embodiment of the present invention are proposed, as shown in fig. 5, the positioning method includes:

and B: selectively instrumenting the system client based on the code coverage data to insert probes;

and C: operating the system client after pile insertion, demonstrating a scene to trigger reading of interface parameters and execution of a probe, and printing out current function call stack and input control meta information by the probe;

step D: according to the function call stack and the input control meta information, positioning an entry function of the interface parameter constraint code;

step E: acquiring a function call relation starting from an entry function in a scene in a program instrumentation mode;

step F: and reading codes of a system client and a function call relation, skipping and browsing among functions according to the code and the function call relation, and analyzing key codes of each function to locate all constraint codes related to the interface parameters.

The interface parameter constraint code positioning method essentially comprises an interface parameter constraint code entry positioning method and a key code positioning method. In the above steps, step a, step B, step C and step D together form an interface parameter constraint code entry positioning method, and step E and step F together form a key code positioning method.

The steps are explained in detail below.

A preparation stage: the stage mainly comprises the steps of presetting a scene of input parameters, and entering a constraint code entry positioning stage after the scene of the input parameters is set.

Constraint code entry positioning phase:

step A: and collecting code coverage data in the system client under the scene of preset input parameters. In order to reduce the overhead of program instrumentation, it is preferable to only instrumentation code executed in a scene, and this goal can be achieved by collecting code coverage data in a scene. Code coverage data under the scenario may be collected by a code coverage testing tool. Currently, most code coverage testing tools are used in a process of using an instrumentation tool to instrumentation a code, then demonstrating a functional scene (or automatically running a testing script) to obtain code coverage data in the scene, and finally showing the final data in a form of a certain function or a certain statement execution total number. The data collected in this way includes all code coverage data in the system initialization and target function scenarios, and normally, the amount of code executed in a single function is much less than the amount of code for the whole system initialization. Therefore, in order to obtain code data executed in a scene more accurately, step a includes:

step A2: the difference between C1 and C2 was calculated and the difference between C1 and C2 was taken as code coverage data. Two pieces of code coverage data are collected, one is data C1 which do not demonstrate scenes after the system is initialized, the other is data C2 which directly demonstrate scenes after the system is initialized, then the difference set is obtained for the two pieces of data, and the result is code data which are executed only in scenes. Some code coverage rate testing tools support real-time statistics, only the testing tools need to be started after system initialization is completed, then scenes are demonstrated, the testing tools are stopped after the demonstration is completed, and at the moment, code coverage data in the scenes are collected by the testing tools.

And B: the system client is selectively instrumented to insert probes based on the code coverage data. The main attention of this step is the selection of the instrumentation range and the instrumentation point, the selective instrumentation range of this step is limited to the code executed in the scene, and the location of the instrumentation is limited to the program operating point where it is possible to read the interface parameters.

And C: and operating the system client after the pile insertion, demonstrating a scene to trigger reading of interface parameters and execution of a probe, and printing out the current function call stack and input control meta information by the probe. In any architecture, the input parameters of the user are generally obtained through the input control, and the first step in constraint checking on the parameters is to read the parameters from the input control. Therefore, by performing instrumentation on the program operation point of 'reading parameters from the input control', when the instrumentation probe is triggered, runtime information related to parameter constraints can be effectively collected, and the corresponding input control is determined and finally displayed in the form of a function call stack and input control meta-information. The design examples of some pile inserting points in the A/S system, the B/S system and the C/S system are respectively shown in the table 1, the table 2 and the table 3.

Table 1 shows common input controls and related information in the android system. In the android system, the acquisition mode of the parameter is realized by calling a method of a specific object, so that an instrumentation point of the android system is a program operation point of method call. To avoid unnecessary overhead, the method call stack and control meta information will be printed only if the call object and the call method are both matched.

Table 1: design example of inserting pile point in A/S system (android system is taken as an example)

Table 2 illustrates common input controls and related information in a B/S system. In the B/S system, the acquisition mode of the parameters is realized by accessing the attributes of the HTML elements, so that the instrumentation point of the B/S is the program operation point for acquiring the object attributes. To avoid unnecessary overhead, the method call stack and control meta-information are printed only if the object at the time of acquiring the property and the acquired property name match.

Table 2: design example of pile inserting point in B/S system

Table 3 shows some input controls and related information in the C # client. In the C # client, the parameter acquisition mode is realized by accessing a specific attribute of the input control, and therefore, the instrumentation point for C # is a program operation point for acquiring the object attribute. To avoid unnecessary overhead, the method call stack and control meta-information are printed only if the object at the time of acquiring the property and the acquired property name match.

Table 3: pile point design example in C/S system (take C # client as example)

Step D: and positioning an entry function of the interface parameter constraint code according to the function call stack and the input control meta information. When locating the entry of the constraint code, the invention uses two types of information, one is the function call stack information, and the other is the meta information of the input control. The method for positioning the entrance based on the two types of information comprises the following steps:

1. function call stack based entry positioning:

in the case of not using the third-party library, the original system developer firstly reads parameters from the input control explicitly when performing constraint check on the input parameters. At this point the instrumented probe is triggered and the printed function call stack structure is shown in table 4.

TABLE 4

At the lowest level of the stack, there are typically some system library functions, such as those used to implement event looping, messaging mechanisms. On top of the system library function is an event callback function, such as a callback function of a click event, a content change event, a loss of focus event, etc. On top of the event callback function is a parameter constraint entry function, sometimes the event callback function and the parameter constraint entry function are actually the same function. On top of the entry function, there may be an application layer function and a third-party library function, where the application layer function refers to a function written by an original system developer, and the third-party library function may be a function for acquiring parameters and performing related processing (such as encryption, conversion, etc.). Regardless of whether these two types of functions exist, at least one function triggers an operation to read parameters at the entry function and the call stack above it. At this time, the instrumented probe is triggered, and a function call stack in operation is printed out. By backtracking and analyzing the call stack, specific entry functions can be located.

2. Entry positioning based on control meta-information:

when a third-party framework is used to implement constraint on a parameter, an operation of reading the parameter is usually initiated by the framework, and after the reading is completed, the framework is responsible for transferring the value of the parameter to a parameter constraint entry function defined by a developer. The function call stack at this time is similar to that in table 4, but lacks the most important entry function, so the constraint entry cannot be located by the function call stack. In order to deal with the situation, the invention adopts a mode of printing control meta information to assist positioning. When the parameter reading probe is triggered, the printing parameters belong to input control element information, and the input control element information comprises a bound event monitoring function, the properties of the control and the like. Since third party library frameworks typically use this meta-information for function binding, developers can locate the entry function to the constraint code through this meta-information.

It should be noted that some redundancy may occur if the information is printed only by relying on the conditions in tables 1, 2, 3 in the previous subsection. Taking the B/S system as an example, assuming that a form in an HTML web page has a plurality of text input boxes, when the form is completed, constraint checking of each input box is triggered successively, and at this time, information of different input boxes is printed together, and a developer may pay attention to a constraint condition of only one input box. In order to reduce redundant information, keywords can be set before a demonstration scene, and only when interface parameters containing the set keywords are read, a probe prints out the current function call stack and input control meta information.

And after the constraint code entry function is positioned, entering a key code positioning stage. The key code location phase still needs to execute the scenario once again in order to collect the function call relations at runtime.

And key code positioning stage:

step E: and acquiring a function call relation starting from an entry function in a scene in a program instrumentation mode. In order to collect real function call information, program instrumentation is still performed at this stage, the instrumented code range is limited to the code executed in the scene, but the instrumented position becomes the program operation point of the function call. The information collected at each function call occurrence is shown in table 5.

Table 5:

type of information	Description of the invention
		caller	Function caller including function name and function location information
callee	Function callee including function name and function location information
		callSite	The location in the caller where this function call occurred

Considering that the developer only cares about the function call relationship starting from the entry function, only this part of the data should be finally presented to the developer. To achieve this result, there are two approaches: 1. collecting full function call information, and then screening; 2. in the process of collecting information, only the function call relations starting from the entry function are collected. The second approach is used herein because the first approach not only greatly increases the operating overhead of the post-instrumentation program, but also introduces additional screening processes.

The programming languages used by the clients of different information systems are various, and the adopted memory models are different. In general, the memory models they use can be divided into two main categories: a Single Threading Model (Single Threading Model) and a Multithreading Model (Multithreading Model). For the two models, the problems to be considered when collecting function call information are different, which are as follows:

single-thread model:

one representation of the single threaded model is JavaScript in the B/S system. The JavaScript adopts a single-threaded model based on Event Loop (Event Loop), and can only execute one function at a time. In the process of executing the function, if an asynchronous method is encountered, the function returns immediately after the execution is finished, and if a synchronous method is encountered, the function returns after the execution is finished. The operation in the asynchronous method adds an event in the event queue, and when the current function is executed after the JavaScript runtime is finished and the function call stack is empty, the JavaScript runtime takes out an event from the event queue and executes the call-back function of the event. For a single-thread model client represented by JavaScript, only the function call relation in a single thread needs to be collected.

Multithreading model:

the multithreading model is a more common model in a client system, and languages such as C/C + +/Java/C # adopt a multithreading memory model. However, in most client implementations, the UI-related operations are performed in the Main Thread (Main Thread), and the Thread that triggers the event callback and calls the entry function is also the Main Thread. Although there may be a case that a method of calling another thread performs parameter constraint check during the operation of the entry function (for example, the dynamic request server determines whether the parameter is legal), a synchronous waiting manner is usually adopted to obtain the result. Therefore, it is feasible to collect the function call relations on the main thread starting from the entry function.

In summary, in either a multi-threaded model or a single-threaded model, it is reasonable to consider only function call scenarios within a single thread. After all the function call relation information starting from the entry function is collected, the instrumentation tool saves the information in the form of a file or a database. When a function Call point (Call Site) is clicked in the key code analysis tool, the analysis tool can find the actually called function according to the stored information, and then display the function in the front-end page.

Step F: and reading codes of a system client and a function call relation, skipping and browsing among functions according to the code and the function call relation, and analyzing key codes of each function to locate all constraint codes related to the interface parameters. The method mainly comprises data flow analysis and key code analysis for calculating the influence of variables in the function.

1. Data flow analysis to calculate the effect of variables within a function:

after jumping to a specific function through a key code analysis tool, the name of a variable in the function can be input, and then statements which are possibly influenced by the variable in the function are observed. Consider first a simple case: the variables of interest to the developer are just the parameters of the function. For convenience of description hereinafter, assuming that the variable designated by the user at the beginning is x, then "In" is taken to mean a set of variables related to x before entering a basic block b, and In particular, the "In" is taken to mean the set of In of the first basic block In the function; out _ b refers to a set of variables associated with x after passing through a basic block b; gen (Gen) and b (x) are variables newly generated in the basic block and related to x; all Kill, b refer to the newly generated x-independent variables in the basic block; "Use" is a set of variables used in the basic block; and finally "" Highlight "". b is the variable to be highlighted in the basic block b. By definition, Gen _ b is actually the set of variables v associated with x that have been assigned the last time in the basic block, and Kill _ b is actually the set of variables v that have been assigned the last time in the basic block and are independent of x. From the [ (Gen) _ b and [ (Kill) _ b ], and from the [ (In) _ b ], we can calculate Out [ (Out) _ b ] for each basic block. This is actually a problem of forward data flow analysis, where the computation of data flow information in each block depends on the basic block in front of it.

The basic idea of solving the algorithm is to iteratively calculate the In set and the Out set of each basic block continuously until the Out sets of all basic blocks are not changed any more. Fig. 2 is a simple example of solving using the algorithm described above. Assuming that the parameter x is selected, the Out set of Entry is { x }. Since Entry is the only predecessor node of s1, the In set of s1 is equal to Out _ Entry. In s1, a is assigned and the assignment statement is related to x, so s1 has the Gen set as { a } and the Kill set as an empty set, thereby calculating the Out set as { a, x }. s2 is also an assignment statement, but the assignment of b is independent of x, so b is dropped by Kill and the Out set of s2 is still { a, x }. s3 is not an assignment statement, both the Gen set and the Kill set are empty sets, and { a, x } is passed on to subsequent nodes as is. Finally, s4 and s5, both of which have assigned a value of b, but the value in s4 is related to x (because a has already been affected by x) and the value in s5 is not related to x (because b has not been affected by x), so the final computed Out sets for these two statements are not the same.

The above algorithm takes into account that the specified variables are exactly the parameters of the function. In practical scenarios, it is often necessary to consider another situation where the variables of interest to the developer are not parameters of the function itself. For example, a certain function F performing constraint check on interface parameters does not receive any parameters, but reads parameters input by a user in some way after entering a function body, stores the parameters in a variable x, and performs constraint check on the variable. At this point the developer is concerned about which statements within the function body the variable x will affect, and x itself is not a parameter of the function F. The data flow equation and the solving algorithm thereof under the condition are the same as those of the method, and the key difference is that whether each statement in the function is the first assignment of x or not needs to be recorded at the moment. If a certain statement s is the first assignment to x, then x should be counted in the Gen set of s instead of the Kill set, regardless of whether the right value of the assignment statement is related to x. For example, assuming that the first statement of the function F is x ═ 1, if x is a parameter of F, this statement will kill the variable x, since x is assigned and is independent of its original value; if x is not a parameter of F, then x is included in the Gen set of the sentence, and the final calculated Out set will also include x.

After solving the data flow equation, the In set of each basic block can be calculated, and then the used variable In the basic block is intersected with the In set to obtain the variable influenced by the variable x In the basic block. Highlighting the statements to which these variables relate helps the developer to better understand the statements related to x. When x is selected as a parameter of the interface, it is the key code for constraint checking of the parameter that is highlighted.

2. Key code analysis:

the invention utilizes a key code analysis tool to perform key code analysis. The key code analysis tool has the function of providing a friendly code browsing environment for developers, facilitating jumping among functions and analyzing a single function, and the overall framework of the key code analysis tool is shown in FIG. 3. The key code analysis tool is based on Web implementation and mainly comprises a front end (Frontend) and a back end (Backend). The back end comprises a data server, a data reading module and a data flow analysis module. The data server is used for receiving the HTTP request sent by the front end and returning a result, the data reading module is used for reading the local file, and the data flow analysis module is used for performing data flow analysis. The front end comprises a navigation bar, a text search module, a variable input box, a code viewer, a function viewer and the like. The navigation bar is used for displaying browsing history of functions, the text searching module is used for searching texts, the variable input box is used for receiving input variables, the code viewer is used for browsing codes of the system client, and the function viewer is used for displaying the selected single function. In addition, the key code analysis tool also needs the source code of the original system client and the function call records collected in the previous steps.

And a navigation bar is arranged above a front-end Web page of the key code analysis tool and is used for displaying the browsing history of the function. Two text input boxes and two buttons are arranged at the upper right of the page and are respectively used for triggering a text search function and a data stream analysis function. The lower half of the page is divided into two panels whose size can be adjusted by dragging the dividing strip between the panels. The left panel is a code viewer and is used for displaying the source codes of a single file in the original system client; the right panel is a function viewer that shows a selected single function in the left panel. Both the code viewer and the function viewer support the functionality of syntax highlighting and code segment highlighting.

The code of the original system client can be browsed through the code viewer, when a function call point containing target function information is clicked, the corresponding function can be skipped to, and the navigation bar is automatically updated. In addition, any function can be searched and positioned in a text search mode. When a specific function is focused, the code in the function viewer is updated, at this time, a variable name can be input in the variable input box, the related data can be transmitted to the back end, and after the back end performs data flow analysis, the function viewer at the front end is informed to highlight the statement possibly influenced by the variable. It should be noted that, depending on the platform, the data stream analysis module may also be placed at the front end. For example, the B/S system needs to perform data flow analysis on JavaScript, and this process may be performed by using Java or other languages in the backend or by using JavaScript language in the frontend.

In the overall flow of the method herein, three tools are used: code overlay data collection tools, program selective instrumentation tools, and key code analysis tools. The subsection is oriented to a B/S system, and provides design examples of tools required by the positioning method, including design of a JavaScript code coverage data collection tool, a JavaScript selective instrumentation tool and a JavaScript key code analysis tool.

1. The JavaScript code covers the design of the data collection tool:

the JavaScript code overlay data collection tool designed herein, JS-cover, is a Chrome Extensions (Chrome Extensions) that collects code overlay information via Chrome developer tool Protocol (Chrome DevTools Protocol). The Chrome browser is a web browser developed by Google, has the characteristics of simplicity and quickness, and provides a browser extension frame, so that developers can develop various extension programs based on the API of the Chrome to add additional functions to the browser. Chrome also provides a powerful developer console (Chrome DevTools) that communicates with the Chrome kernel via the Chrome developer tool protocol to implement the functions of operating, checking, DEBUG, analyzing, etc. the browser. In the Chrome extension program, some high-level functions, such as the code overlay data collection function mentioned herein, can also be implemented by the Chrome developer tool protocol.

The overall architecture of JS-Coverage is as follows:

there is a JC typeface button in the upper right corner of Chrome browser, and after clicking, it will pop up the tool menu, and the menu is implemented by using an HTML page (popup. HTML), and includes three buttons: connect, Start, and Stop, which are used to send messages to the background of the extension. After the background receives the message, the current page in the browser is controlled through the API of the Chrome extension program, the code coverage information of JavaScript in the page is collected, and finally, a text file in a JSON format is exported for the use of the subsequent flow. The whole process uses the API in the partial Chrome developer protocol. It should be noted that the profiler. takeprecisencode method resets the code after obtaining the information of the number of times of calling, so that it actually returns the count data of the client JavaScript code called between two takeprecisencode method calls.

The developer uses the JS-Coverage extension program as follows:

1) accessing a target information system by using a Chrome browser, entering a parameter input page, clicking a Connect button, and automatically reloading the page at the moment;

2) clicking a Start button to Start demonstrating a scene;

3) when a scene is demonstrated, inputting parameters to be checked, and triggering related JavaScript codes;

4) clicking a Stop button to Stop demonstrating the scene, and saving code coverage data in the scene as a JSON file.

The whole JSON file corresponds to a JSON Object, key in the Object is the URL of the JavaScript file, and value is corresponding code coverage rate information which is expressed in an array form. The element in the array is an Object that contains an end attribute, which represents the Character Offset (Character Offset) in the source file, and a count attribute (optional) that counts the number of times the code has been called. Specifically, assuming that the name of the array is array and the ith element in the array is array [ i ], the code with the character offset between array [ i ] end and array [ i +1] end in the source file is executed for array [ i +1]. count times.

2. Designing a JavaScript selective pile-inserting tool:

the JavaScript selective instrumentation tool can perform selective instrumentation on JavaScript codes in the B/S system based on code coverage data in a browser proxy mode, and the instrumentation selection body is in two aspects of instrumentation code range and program instrumentation points. The working process of the JavaScript selective instrumentation tool is as follows:

1) the browser forwards the HTTP request to proxy software, mitmproxy;

2) the mitmprroxy requests a corresponding resource from the original system, and if the resource is a JavaScript file or an HTML document, the resource is processed by an expanded Jalangi2 instrumentation frame after downloading;

3) the extended Jalangi2 selectively posts JavaScript code based on the collected code coverage data;

4) and returning the HTML and JavaScript files after the pile insertion to the Web browser by the mitmprroxy, and directly returning other types of resources without pile insertion.

The instrumentation module (instrumentation) of Jalangi2 works by parsing an Abstract Syntax Tree (AST) of a JavaScript code, then converting the parsed AST according to a series of rules, and finally generating a new JavaScript code from the converted AST. The instrumentation module is matched with an agent tool such as mitmprroxy, so that JavaScript codes in a webpage can be instrumented in real time, and dynamic analysis of the B/S system can be realized.

The scope of code instrumentation in the client should be limited to code executed in the scene, and to achieve this, the instrumentation module of Jalangi2 needs to be extended. The overall concept of the expansion is to determine whether a source code corresponding to an AST has been executed in a scene when the AST is converted. Specifically, Jalangi2 uses acorn library to parse JavaScript codes, and each AST node after parsing has two attributes, namely start and end, and the start and end positions of the node in the source code file are respectively represented in the form of character offsets. The JSON file that is finally exported also takes the form of a character offset when recording code overlay data. By comparing the character offset intervals, it is possible to determine whether or not an AST node should be instrumented. Therefore, the expanded Jalangi2 instrumentation module can determine the specific instrumentation range through the information in the JSON file, and selective code instrumentation is realized.

Consider next the problem of stake insertion points. After the JavaScript and HTML files are instrumented by the instrumentation module of Jalangi2, the JavaScript and HTML files are rewritten into codes with instrumented probes but unchanged functions, and the probes can be executed while recording dynamic information in the original code execution process by combining with the runtime environment of Jalangi 2. The instrumentation probe provided by Jalangi2 is in the form of a JavaScript callback function, the iid parameter of which is used to mark the location of each program operation point. When corresponding operation occurs, the Jalangi2 runtime environment prepares relevant parameters, calls an analysis function written by a developer, and can operate, store and analyze the data as required.

The operation of reading parameters in the B/S system is completed by reading the attributes of the DOM object, so that only a getField probe is needed in the entry code locating phase. Base in getField callback is exactly the object of the read attribute, and val is the content read. Therefore, whether the current reading operation is performed on a specific DOM object can be judged according to the base, and a keyword filtering function can be realized according to the val. In the key code positioning stage, information of function calls needs to be collected, and the instrumentation probes used in the key code positioning stage are invokeFunPre and invokeFun. Jalangi2 saves the source code before instrumentation in a data structure named smap, and exports the data for use by subsequent key code analysis tools.

3. Designing a JavaScript key code analysis tool:

the whole architecture of the key code analysis tool is shown in fig. 3, in the JavaScript key code analysis tool designed herein, the source code in the drawing is a smap file exported by Jalangi2, and the source code includes source codes such as JavaScript scripts and HTML documents; the function call record is the data information collected by Jalangi2 in the previous subsection, and is stored in a text in JSON format; most of the modules at both the front and back end use open source components. The following mainly describes the dataflow analysis module espropagation in the JavaScript key code analysis tool, which is different from the design in fig. 3, and the module actually works in the front end. espropagation is a tool for solving variable impact dataflow equations on a JavaScript syntax tree. espropagation takes the working of solving the equations of a data stream on the abstract syntax tree of ES 5. On top of the abstract syntax tree of ES5, espropagation uses the open-source library espraph to construct a control flow graph for a program. FIG. 4 is an example of a control flow graph of an espraph construct. In the control flow graph generated by the espraph, each flow graph node (flowNode) has three attributes of astNode, prev and next. The astNode is an abstract syntax tree node corresponding to the flow graph node, and is either a Statement (Statement) or an Expression (Expression); prev and next are both arrays of flow graph nodes, holding predecessor and successor nodes, respectively. After the control flow graph is constructed, espropagation solves a data flow equation influenced by variables in the function. The key to the solution process is to calculate the Gen set and Kill set of a basic block or a sentence, and the Gen set and Kill set are calculated according to whether the value of a variable is related to the In set. In order to determine whether the assignment or initialization statement of a variable is related to the In set, it is calculated whether the right value In the statement uses the variable In the In set, and therefore, the Use set of the statement is calculated first. Assuming that the node of the Use set to be calculated is astNode, the method for calculating the Use set on the nodes of the abstract syntax trees of different types is shown in table 6:

table 6: example of Use set calculation method of ES5 abstract syntax tree node

After calculating the Use set of the assignment statement/variable initialization statement, taking intersection with the In set of the statement, if the result is an empty set, indicating that the left value In the statement is irrelevant to the In set, and incorporating the assigned variable into the Kill set; conversely, if the result is not an empty set, indicating that the left value In the statement is associated with the In set, the assigned variable should be included In the Gen set. The above is considered the case when the developer-specified variable happens to be a function parameter, and the construction differs for the Gen set and the Kill set when the developer-specified variable is not a function parameter.

The espropagation tool solves the final state of each syntax tree node through an iterative algorithm, binds information such as an In set, an Out set, a Gen set, a Kill set and the like of each node to corresponding nodes, finally, extracts an intersection from the In set and the Use set of each syntax tree node, if the In set and the Use set are not empty sets, the statement is influenced by variables appointed by a developer, and when the variables appointed by the developer are parameters of an original system, the statement is one of key codes for carrying Out constraint check on the parameters.

Based on the above method for locating an interface parameter constraint code, another embodiment of the present invention further provides an interface parameter constraint code locating system, as shown in fig. 6, where the locating system includes:

the code coverage data collection module 1 is used for collecting code coverage data in a system client under a scene of preset input parameters;

the instrumentation module 2 is used for selectively instrumenting the system client based on the code coverage data so as to insert the probe; when a system client after pile insertion runs and a scene is demonstrated, triggering and reading interface parameters and executing a probe, and printing current function call stacks and input control meta information by the probe;

the interface parameter constraint code entry function positioning module 3 is used for positioning an entry function of the interface parameter constraint code according to the function call stack and the input control meta information;

the instrumentation module 2 is also used for acquiring a function call relation starting from an entry function in a scene in a program instrumentation mode;

the positioning system further comprises:

and the key code analysis module 4 is used for reading codes of the system client and function call relations, skipping and browsing among functions according to the codes, and performing key code analysis on each function so as to locate all constraint codes related to the interface parameters.

The positioning system essentially comprises two parts, namely an interface parameter constraint code entry positioning system and a key code positioning system. In the modules, the code coverage data collection module 1, the instrumentation module 2 and the interface parameter constraint code entry function positioning module 3 jointly form an interface parameter constraint code entry positioning system, and the instrumentation module 2 and the key code analysis module 4 jointly form a key code positioning system. It is noted that the instrumentation module 2 performs actions in the interface parameter constraint code entry positioning system that are distinct from actions performed in the key code positioning system. The instrumentation module 2 executes actions in the interface parameter constraint code entry positioning system, namely selectively instrumentation the system client based on the code coverage data to insert the probe; when the system client after pile insertion is operated and a scene is demonstrated, interface parameters are triggered and read and a probe is executed, and the probe prints out the current function call stack and the input control meta information. The action executed by the instrumentation module 2 in the key code positioning system is to collect the function call relation from the entry function in the scene by means of program instrumentation.

The code coverage data collection module 1 is specifically configured to:

the difference between C1 and C2 was calculated and the difference between C1 and C2 was taken as code coverage data.

The scope of selective instrumentation is limited to code executed in the scene, and the location of the instrumentation is limited to program operating points where it is possible to read interface parameters.

The function call stack comprises a system library function positioned at the bottom layer, an event callback function positioned above the system library function and a parameter constraint entry function positioned above the event callback function;

the input control meta information comprises an event monitoring function and the property of the control.

And when the interface parameters containing the preset keywords are read, the probe prints out the current function call stack and the input control meta information.

The code range of program instrumentation is limited to code executed in the scene, and the position of the instrumentation is the program operating point of the function call.

When the system client is a single-thread model, the instrumentation module 2 acquires the function call relation in a single thread, and when the system client is a multi-thread model, the instrumentation module 2 acquires the function call relation starting from the entry function on the main thread.

The key code analysis module 4 is based on Web, as shown in fig. 3, and includes a front end and a back end, where:

the front end includes:

the navigation bar is used for displaying the browsing history of the function;

the text search module is used for searching texts;

a variable input box for receiving an input variable;

the code viewer is used for browsing codes of the system client;

the function viewer is used for displaying the selected single function;

the rear end includes:

the data server is used for receiving the HTTP request sent by the front end and returning a result;

the data reading module is used for reading a local file;

and the data flow analysis module is used for carrying out data flow analysis.

For the device embodiment, since it is basically similar to the method embodiment, the description is simple, and for the relevant points, refer to the partial description of the method embodiment. The positioning system corresponds to the positioning method and is used for executing the positioning method. The specific working principle of each module in the positioning system can be obtained by referring to the description of the corresponding flow in the positioning method.

The above-described embodiments are merely preferred embodiments, which are not intended to limit the scope of the present invention, and any modifications, equivalents, improvements, etc. made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims

1. An interface parameter constraint code positioning method is characterized by comprising the following steps:

step D: according to the function call stack and the input control meta information, positioning an entry function of an interface parameter constraint code, comprising:

when the third-party library is not used, an entry function of the interface parameter constraint code is positioned by backtracking and analyzing the function call stack;

when a third-party framework is used for realizing the constraint of the parameters, an entry function of an interface parameter constraint code is positioned according to the function binding relationship between the input control meta-information and the third-party library framework;

2. The interface parameter constrained code location method of claim 1, wherein said step a comprises:

3. The method according to claim 2, wherein in step B, the range of selective instrumentation is limited to the code executed in the scene, and the position of instrumentation is limited to the program operating points where it is possible to read the interface parameters.

4. The method as claimed in claim 1, wherein in step C, keywords are set before the scene is presented, and when interface parameters containing the keywords are read, the probe prints out the current function call stack and input control meta information.

5. The method according to claim 1, wherein in step E, the code range of program instrumentation is limited to the code executed in the scene, and the position of the instrumentation is the program operation point of the function call.

6. An interface parameter constrained code positioning system, comprising:

the interface parameter constraint code entry function positioning module is used for positioning an entry function of an interface parameter constraint code according to the function call stack and the input control meta information, and comprises the following steps:

the positioning system further comprises:

7. The interface parameter constrained code location system of claim 6, wherein the code overlay data collection module is specifically configured to:

8. The interface parameter constrained code location system of claim 7, wherein the range of selective instrumentation is limited to code executed under the scene and the location of instrumentation is limited to program operating points where interface parameters are likely to be read.

9. The interface parameter constraint code location system of claim 6, wherein the probe prints out current function call stack and input control meta-information when an interface parameter containing a preset keyword is read.

10. The interface parameter constrained code location system of claim 6, wherein the code range of the program instrumentation is limited to code executed in the scene and the location of the instrumentation is the program operating point of the function call.