Test interface determination and function call chain generation method, apparatus, device, and medium

Abstract

Embodiments of the present application provide a test interface determination and function call chain generation method, device, equipment and medium. In the embodiments of the present application, the function call chain is obtained by parsing the static intermediate code file and the configuration file, therefore, the function call chain obtained by the embodiments of the present application is a static function call chain, in the process of generating the static function call chain, the updated source code of the software under test does not need to be executed, the time-consuming of executing the updated source code of the software under test can be saved, which helps to accelerate the generation speed of the function call chain, improve the generation efficiency of the function call chain, and further helps to improve the efficiency of determining the test interface of the changed function based on the function call chain.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to a method, apparatus, device and medium for determining test interfaces and generating function call chains. Background Technology

[0002] In software development, when software code is updated, testers need to test the updated code. Recommending test interfaces to testers can reduce workload and improve efficiency. However, current methods for recommending test interfaces are labor-intensive, resulting in low efficiency in determining the appropriate interfaces. Summary of the Invention

[0003] This application provides a method, apparatus, device, and medium for determining test interfaces and generating function call chains, thereby improving the efficiency of determining test interfaces.

[0004] This application provides a method for determining a test interface, including:

[0005] Obtain the configuration file and multiple intermediate code files of the updated first source code of the software under test; parse the multiple intermediate code files to obtain the function node list of the first source code;

[0006] The configuration file is parsed to obtain the interface list of the first source code;

[0007] Based on the interface list and the function node list, generate the function call chain of the interface in the interface list;

[0008] Based on the first source code and the second source code of the software under test before the update, determine the modified functions of the software under test;

[0009] Based on the function call chain corresponding to the interface in the interface list, the interface corresponding to the change function is determined to be the test interface of the software under test.

[0010] This application also provides a method for generating function call chains, including:

[0011] Obtain the intermediate code files and configuration files of the target code;

[0012] The intermediate code file is parsed to obtain a list of function nodes for the target code;

[0013] The configuration file is parsed to obtain the interface list of the target code;

[0014] Based on the interface list and the function node list, generate the function call chain of the interfaces in the interface list.

[0015] This application embodiment also provides a test interface determination device, including:

[0016] The acquisition module is used to acquire the configuration file and multiple intermediate code files of the first source code of the software under test after the update;

[0017] The parsing module is used to parse the plurality of intermediate code files to obtain a list of function nodes of the first source code; and to parse the configuration file to obtain a list of interfaces of the first source code.

[0018] The generation module is used to generate the function call chain of the interfaces in the interface list based on the interface list and the function node list;

[0019] The determination module is used to determine the modified functions of the software under test based on the first source code and the second source code before the software under test is updated; and to determine the interface corresponding to the modified function as the test interface of the software under test from the interface list based on the function call chain corresponding to the interface in the interface list.

[0020] This application also provides a function call chain generation apparatus, including:

[0021] The acquisition module is used to acquire intermediate code files and configuration files of the target code;

[0022] The parsing module is used to parse the intermediate code file to obtain a list of function nodes of the target code; and to parse the configuration file to obtain a list of interfaces of the target code.

[0023] The generation module is used to generate the function call chain of the interfaces in the interface list based on the interface list and the function node list.

[0024] This application embodiment also provides a computing device, including: a memory and a processor; wherein, the memory is used to store computer programs;

[0025] The processor is coupled to the memory and is used to execute the computer program to perform the steps in the above-described test interface determination method and / or function call chain generation method.

[0026] This application also provides a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps in the above-described test interface determination method and / or function call chain generation method.

[0027] In this embodiment, the updated source code of the software under test can be parsed to obtain an interface list and a function node list. Based on these lists, a function call chain is generated for each interface. Subsequently, the interface corresponding to the changed function in the interface list is determined as the test interface based on the function call chain. Since the function call chain is obtained by parsing static intermediate code and configuration files, the resulting function call chain is static. This static chain eliminates the need to execute the updated source code, saving time and accelerating the generation of the function call chain. This, in turn, improves the efficiency of determining the test interface for the changed function based on the function call chain. Attached Figure Description

[0028] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0029] Figure 1 A flowchart illustrating the test interface determination method provided in this application embodiment;

[0030] Figure 2 Mind map for determining function nodes provided in embodiments of this application;

[0031] Figure 3 A flowchart illustrating the method for determining the interface list of the updated source code of the software under test, as provided in this embodiment of the application.

[0032] Figure 4 A flowchart illustrating the method for determining the function call chain of the interface provided in this application embodiment;

[0033] Figure 5 A flowchart illustrating the method for determining the change function of the software under test provided in this application embodiment;

[0034] Figure 6 A flowchart illustrating the process of determining the test interface provided in an embodiment of this application;

[0035] Figure 7 A flowchart illustrating the function call chain generation method provided in this application embodiment;

[0036] Figure 8 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0037] Figure 9 This is a schematic diagram of the test interface determination device provided in the embodiments of this application;

[0038] Figure 10 This is a schematic diagram of the function call chain generation device provided in an embodiment of this application. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0040] In software development, recommending test interfaces to be executed for testing tasks can reduce testing workload and improve testing efficiency. In some solutions, testers can establish a link between code and test cases by dynamically recording a knowledge base through test case execution. This allows for the recommendation of test cases for interfaces or functions to be executed when code changes. However, recorded knowledge bases have maintenance costs. When there are significant changes to the smallest unit associated with code and test cases (such as functions or customized code blocks), the knowledge base needs to be re-recorded. This work is difficult to complete fully automatically and often requires manual maintenance by testers, resulting in low efficiency in knowledge base recording and consequently, low efficiency in determining test cases.

[0041] In other solutions, a dynamic function call graph can be generated by dynamically collecting actual function call relationships. This allows for the recommendation of test interfaces to be executed when code changes. The function call graph represents the call relationships between functions (functions / methods) in a programming language and can be abstracted as a linked list data structure. A dynamic function call graph is a function call graph assembled by collecting and recording the dynamic call relationships between functions during actual code execution. However, dynamically collecting function call relationships to generate a function call graph requires the system to actually run the code, and this requires re-running the code when it changes. The long execution time of running the code leads to a lengthy process for generating the function call graph, resulting in low efficiency in subsequently determining test interfaces based on the function call graph. This is especially true for collecting function call graphs from large-scale system code, where the high volume of function calls between systems further exacerbates the time required to generate the graph. Furthermore, the process of generating the function call graph is often triggered by sampling at fixed intervals, but if the actual application scenario does not trigger this process, the function call graph will not be collected, making it impossible to guarantee complete recording of the function call graph.

[0042] To address the technical problem of the long generation time of function call chains in the above-mentioned schemes, which leads to low efficiency in determining test interfaces, some embodiments of this application can parse the configuration files and intermediate code files of the updated source code of the software under test to obtain the interface list and function node list of the updated source code of the software under test. Then, based on the interface list and function node list of the updated source code of the software under test, function call chains for the interfaces in the interface list are generated. Subsequently, based on the function call chains corresponding to the interfaces in the interface list, the interface corresponding to the changed function of the software under test is determined from the interface list as the test interface of the software under test. Since the function call chain is obtained by parsing static intermediate code files and configuration files, the function call chain obtained in the embodiments of this application is a static function call chain. During the generation of the static function call chain, it is not necessary to execute the updated source code of the software under test, thus avoiding the time-consuming execution of the updated source code. This helps to speed up the generation of the function call chain, improve the generation efficiency of the function call chain, and consequently improve the efficiency of subsequently determining the test interface of the changed function based on the function call chain.

[0043] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0044] It should be noted that the same reference numerals denote the same object in the following figures and embodiments. Therefore, once an object is defined in one figure or embodiment, it does not need to be discussed further in subsequent figures and embodiments.

[0045] Figure 1 This is a flowchart illustrating the test interface determination method provided in an embodiment of this application. Figure 1 As shown, the method for determining this test interface mainly includes:

[0046] 101. Obtain the configuration file and multiple intermediate code files of the first source code of the software under test after the update.

[0047] 102. Parse multiple intermediate codes to obtain a list of function nodes for the first source code.

[0048] 103. Parse the configuration file to obtain the interface list of the first source code.

[0049] 104. Based on the interface list and function node list, generate the function call chain of the interfaces in the interface list.

[0050] 105. Based on the first source code and the second source code of the software under test before the update, determine the changed functions of the software under test.

[0051] 106. Based on the function call chain corresponding to the interface in the interface list, determine the interface corresponding to the change function as the test interface of the software under test from the interface list.

[0052] In this embodiment, the software under test can be any software system, module, or application (APP). During the development process, the software code may be updated, requiring testers to test the updated code. This embodiment does not limit the code language type of the software under test. The software under test can be developed using any programming language. For example, it can be developed using PHP, Java, C, C++, etc. The software under test can be server-side software in a client / server (C / S) architecture. PHP is a server-side scripting language executed within HTML, commonly used for developing dynamic websites. As a preprocessor, PHP can dynamically generate HTML on the server side.

[0053] To achieve accurate testing of the modified code in the software under test, it is necessary to determine the test interface of the software under test and recommend it to the testers. To determine the test interface, in step 101, the configuration file and multiple intermediate code files of the updated source code of the software under test can be obtained. "Multiple" means two or more. The source code of the software under test is a PHP script. Specifically, each class in the source code corresponds to one intermediate code file. The number of intermediate code files is determined by the number of classes in the updated source code. For PHP scripts, the intermediate code files are PHP intermediate code (Operate Code, OPCODE), also known as opcode. The intermediate code files are executable intermediate code.

[0054] In this embodiment, an interpreter can be used to analyze the source code to obtain multiple intermediate code files corresponding to the source code. Alternatively, the interpreter can be used to analyze the source code before the execution of the process determined by the test interface to obtain and store multiple intermediate code files. Accordingly, when the process determined by the test interface is executed, multiple intermediate code files of the updated source code of the software under test are read from the storage medium.

[0055] The configuration file is mainly used to describe the configuration information of the software under test. The configuration file can be an nginx configuration file, which mainly includes the following four parts: (1) main: global settings module; (2) server module: virtual host settings module, mainly used to specify the virtual machine host domain name, IP address and port, etc.; (3) upstream module: upstream server settings module, used to set a series of backend servers, set reverse proxy and load balancing of backend servers and other related configurations; (4) location: location module, mainly used to set URL matching specific locations.

[0056] In this application, the specific implementation method for obtaining the configuration file of the updated source code of the software under test is not limited. In some embodiments, a configuration file parser, such as an nginx parser plugin, may be installed in the computing device executing the test interface determination method. The configuration file parser can be used to read the configuration file in the software under test.

[0057] The inventors discovered that intermediate code possesses certain language organization rules. By parsing these rules, functions within the source code can be identified. Based on this, in step 102, multiple intermediate code files can be parsed to obtain a list of function nodes in the updated source code of the software under test. The function nodes in the list can include: the name and class of the calling function, and the name and class of the called function. For example, assuming the function call relationship is that function A calls functions B and C, then the calling function is function A, and the called functions are functions B and C. Accordingly, a function node can be represented as:

[0058] Function A; Class of function A; Child nodes {Function B, Class of function B; Function C, Class of function C}.

[0059] In this application, the specific implementation method for parsing multiple intermediate code files is not limited. In some embodiments, multiple intermediate code files can be parsed according to the language organization rules of the intermediate code to obtain a list of function nodes in the updated source code of the software under test. Since the parsing process for each intermediate code file is the same, the following uses any one of the multiple intermediate code files as an example, combined with... Figure 2 The mind map illustrating the method for determining the list of function nodes serves as an example to explain the parsing process of intermediate code files. For ease of description, the example intermediate code file will be defined as the first intermediate code file in the following text. The first intermediate code file can be any one of a plurality of intermediate code files.

[0060] Since each intermediate code file corresponds to a class in the source code, the first intermediate code file can be parsed to determine the functions defined in the classes contained within it; and the class corresponding to the functions defined in the classes contained in the first intermediate code file can be identified. Specifically, the class keyword, such as `class`, can be identified from the first intermediate file; and the class name (i.e., the class name) can be extracted from the first intermediate file based on the class keyword. For example, if the class declaration line is "Class Testclass", then the class name can be determined to be "Testclass". Furthermore, the start and end points of the functions defined in the class can be identified from the first intermediate file. For example, if the function declaration line, such as "function name: XXXX", is identified from the first intermediate file, then the name of the function defined in the class is determined to be "XXXX", and the class of this function is "Testclass".

[0061] After identifying the functions defined in the class contained in the first intermediate file, the function name and class of the called function can be determined according to the language organization rules of the called function in the first intermediate code file. For ease of description and distinction, the function defined in the class contained in the first intermediate file is defined as the first function A; and the function B called by the first function A (i.e., the called function of the first function A) is defined as the second function B.

[0062] Optionally, the function type of the second function B can be determined according to the language organization rules of the functions called in the first intermediate code file. In this embodiment, the function type mainly refers to whether the function is a static function or a regular function. A static function can be modified with the keyword `static`, and its type is limited to use within the same source code file and cannot be called by code files outside of that file. For example, in PHP intermediate code, a static function can be represented as `INIT_STATIC_METHOD_CALL`. Regular functions, as opposed to static functions, do not have the `static` keyword. A static function is a function that can be called by other code files. For example, a static function can be represented as `INIT_METHOD_CALL` in PHP intermediate code.

[0063] For intermediate code, different function types have different language organization rules. Therefore, the class and name of the second function can be determined based on the language organization rules corresponding to the function type of the second function in the first intermediate code file. For intermediate code files, functions of the same function type may have different numbers of operands, and the language organization rules for these functions will also differ. The number of operands refers to the number of operands in an instruction line, which can be either two operands or one operand. Instruction lines with two operands have two operands; instruction lines with one operand have one operand. Based on this, the number of operands in the second function can be obtained from the first intermediate code file; and the function name and class of the second function can be determined based on the language organization rules corresponding to the number of operands under the function type of the second function in the first intermediate code file.

[0064] The following is combined Figure 2 The mind map shown illustrates how to determine the list of function nodes, and provides an exemplary description of the specific implementation method for determining the function name and class of the second function.

[0065] like Figure 2As shown, for the case where the second function is a static function, i.e., "INIT_STATIC_METHOD_CALL", and has two operands, the second operand can be determined as the function name of the second function. Furthermore, the class of the second function can be determined based on the format of the first operand. For example, if the second function is "INIT_STATIC_METHOD_CALL 'Testclass', 'staticDoSomething'", then the second operand "staticDoSomething" is determined as the function name of the second function.

[0066] Optionally, determining the class of the second function based on the format of the first operand of the two operands can be implemented as follows: if the format of the first operand of the two operands is not a specified format, the first operand is determined to be the class of the second function. The specified format varies depending on the programming language. In some embodiments, the programming language is PHP. Accordingly, if the intermediate code file is a PHP intermediate code file, the specified format can be "$number". For example, in the above "INIT_STATIC_METHOD_CALL 'Testclass', 'staticDoSomething'", the first operand "Testclass" is determined to be the function name of the second function.

[0067] Accordingly, if the format of the first operand in a double operand is specified, the class of the second function can be determined based on the class type defined in the line preceding the double operand. For example, consider the following intermediate PHP code example:

[0068] FET_CLASS self 513$2

[0069] INIT_STATIC_METHOD_CALL$2,'getArr'

[0070] Since the format of the first operand of a static function with two operands is "$2", which is "$number", the class of the second function can be determined based on the class type defined in the line preceding the line containing the two operands, "FET_CLASS self 513$2".

[0071] The implementation of determining the class of the second function differs depending on the type of the class defined in the preceding line of code containing the two operands. In some embodiments, if the type of the class defined in the preceding line of code containing the two operands is a first specified type, the class of the second function is determined to be the current class corresponding to the first intermediate code file; that is, the class corresponding to the first intermediate code file is also the class of the first function. Conversely, if the format of the preceding line of code containing the two operands is a second specified type, the class of the second function is determined to be the parent class of the current class, that is, the parent class of the class corresponding to the first intermediate code file. Further, the line of code declaring the parent class can be determined in the first intermediate code file based on the keyword "parent"; and the parent class of the class corresponding to the first intermediate code file can be obtained from the line of code declaring the parent class.

[0072] For example, in PHP intermediate code, the class defined in the line preceding the line containing the two operands can be of type `self`, `static`, or `parent`. Accordingly, if the class defined in the line preceding the two operands is of type `self` or `static`, the class of the second function is determined to be the current class corresponding to the first intermediate code file; that is, the class corresponding to the first intermediate code file is also the class of the first function. Similarly, if the format of the line preceding the two operands is `parent`, the class of the second function is determined to be the parent class of the current class, which is the parent class of the class corresponding to the first intermediate code file. Furthermore, the line of code declaring the parent class can be determined in the first intermediate code file based on the keyword "parent," and the parent class of the class corresponding to the first intermediate code file can be obtained from the line of code declaring the parent class.

[0073] In other embodiments, such as Figure 2 As shown, the second function is a static function with a single operand. Accordingly, based on the language organization rules governing the number of operands under the function type of the second function in the first intermediate code file, the function name and class of the second function are determined. This can be achieved by: determining the function name of the second function as a constructor, i.e., the "_construct" function; and determining the class of the second function based on the format of the single operand name.

[0074] Optionally, if the operand name of the single operand is not in the specified format, the operand name is used to determine the class of the second function. If the operand name is in the specified format, the class of the second function can be determined based on the type of the class defined in the line preceding the single operand. For PHP intermediate code files, the specified format can be "$number".

[0075] Specifically, if the class type defined in the line preceding the single operand is a first specified type, the class of the second function is determined to be the current class corresponding to the first intermediate code file; if the format of the line preceding the single operand is a second specified type, the class of the second function is determined to be the parent class of the current class. For PHP intermediate code files, the first specified type can be either `self` or `static`; the second specified type can be `parent`. The method for determining the parent class of the current class corresponding to the first intermediate code file can be found in the relevant content of the above embodiments, and will not be repeated here.

[0076] In some embodiments, such as Figure 2 As shown, the second function is a regular function; the second function has two operands. Accordingly, based on the language organization rules corresponding to the number of operands under the function type of the second function in the first intermediate code file, the function name and class of the second function are determined. This can be achieved by determining the function name and class of the second function based on the operation type of the code line preceding the line containing the two operands.

[0077] Specifically, if the operation type of the code line preceding the line containing the two operands is a variable assignment operation, such as the FETCH_OBJ_R operation, then the name of the second operand in the two operands is determined to be the function name of the second function. For example, as shown in the following code line:

[0078] FETCH_OBJ_R$12'ps'

[0079] INIT_METHOD_CALL$12,'invoke'

[0080] The second operand name "ps" in the variable assignment (FETCH_OBJ_R) operation is the function name of the second function.

[0081] After determining the function name of the second function, the variable declaration line corresponding to the variable name in the first intermediate code file can be found by using the variable assignment operation. In the PHP intermediate code file, the operation name of the variable declaration line is "ASSIGN_OBJ". For example, consider the following intermediate code line:

[0082] NEW$4'xxxxx'

[0083] ...

[0084] ASSIGN! 3, $4

[0085] EXT_STMT

[0086] ASSIGN_OBJ'ps'

[0087] The second operand of the above FETCH_OBJ_R is the variable name "ps". The variable declaration operation "ASSIGN_OBJ'ps'" that declares "ps" can be found in the first intermediate code file.

[0088] After identifying the variable declaration line that declares the variable name, the line of internal variable assignment in the first function can be located based on this line. For example, the line of internal variable assignment in the first intermediate code file can be located based on the position of the variable declaration line. In this case, the internal variable assignment operation name in the PHP intermediate code file is "ASSIGN". Accordingly, based on the position of the ASSIGN_OBJ operation line in the first intermediate code file, the line of internal variable assignment in the first function can be defined as the ASSIGN operation line closest to the ASSIGN_OBJ operation line, such as "ASSIGN!3,$4" in the code line example above.

[0089] Furthermore, by querying the internal variable name corresponding to the internal variable declaration operation line, the initialization code line for the internal variable name can be found in the first intermediate code file; and the operand name of the initialization code line can be determined to be the class name of the second function. In the PHP intermediate code, the initialization operation can be implemented as a NEW operation, and correspondingly, the initialization code line is implemented as a NEW operation line. For example, combining the above code line example, by querying the internal variable name "$4" of the internal variable declaration operation line "ASSIGN!3,$4" in the first intermediate code file, the initialization code line for the internal variable name can be obtained as "NEW$4'xxxxx'"; furthermore, the operand name "xxxxx" of the initialization code line can be determined as the class name of the second function.

[0090] The above embodiments exemplify that the function type of the second function is a regular function; when the number of operands of the second function is two operands, and the operation type of the code line preceding the code line containing the two operands is a variable assignment operation, the function name of the second function and the specific implementation of the class of the second function are determined. In other embodiments, the function type of the second function is a regular function; when the number of operands of the second function is two operands, the operation type of the code line preceding the code line containing the two operands may not be a variable assignment operation, then the name of the second operand of the two operands can be determined as the function name of the second function. For example, for the following PHP intermediate code:

[0091] EXT_STMT

[0092] INIT_METHOD_CALL! 3,'setEx'

[0093] Based on the above intermediate code example, it can be determined that the name of the second operand, "setEx", of the two operands corresponding to the ordinary function is the name of the second function.

[0094] You can also look for internal variable assignment operations, such as the ASSIGN operation, in the first intermediate code file. For example, the ASSIGN operation could be: ASSIGN! 3, $8. Furthermore, you can look up the first initialization operation that initializes the internal variable name in the first intermediate code file by using the internal variable name corresponding to the internal variable declaration operation line; based on the query results for the first initialization operation, you can determine the class of the second function. For PHP intermediate code files, the first initialization operation could be the DO_FCALL operation.

[0095] Optionally, if the query result finds a first initialization operation that initializes internal variable names, the factory function that performs the initialization operation is called; and the class declared by the factory function is determined to be the class of the second function. For example, an object explicitly declared by the factory function can be called; and the class of the object explicitly declared by the factory function is determined to be the class of the second function. As another example, an object implicitly declared by the factory function can be called; and the class of the object explicitly declared by the factory function is determined to be the class of the second function.

[0096] Accordingly, if the query result indicates that no first initialization operation for initializing the internal variable name was found, then the internal variable name is used to search for a second initialization operation for initializing the internal variable name in the first intermediate code file; and the operand name of the second initialization operation is determined to be the class name of the second function. In the PHP intermediate code file, the second initialization operation can be the NEW operation.

[0097] The above embodiments exemplify the specific implementation of determining the function name and class of the second function when the second function has two operands and its function type is a regular function. In other embodiments, the second function may have a regular function type and may also have a single operand. For example... Figure 2 As shown, for the case where the function type of the second function is a regular function and the number of operands of the second function may also be a single operand, the function name and class of the second function are determined according to the language organization rules corresponding to the number of operands under the function type of the second function in the first intermediate code file. This can be achieved as follows: the operand name of the single operand is determined to be the function name of the second function; and the class of the second function is determined to be the current class corresponding to the first intermediate code file.

[0098] The above embodiments exemplify how to determine the function name and class name of the calling function (first function) contained in the first intermediate code file, and the function name and class name of the called function (second function) of the calling function contained in the first intermediate code file. After determining the function name and class name of the calling function and the called function contained in the first intermediate file, a function node corresponding to the first intermediate code file can be generated based on the function name and class name of the first function and the function name and class name of the second function. The implementation of the function node can be found in the relevant content of the above embodiments, and will not be repeated here. The second function (called function) in the function node corresponding to each intermediate code file is the function directly called by the first function (calling function). There is one first function in a function node. There can be one or more second functions. "Multiple" refers to two or more.

[0099] The above example uses only the first intermediate code file among multiple intermediate code files to illustrate the parsing process. The parsing process for each intermediate code file is the same as that for the first intermediate code file, and will not be repeated here.

[0100] After obtaining the function nodes of each intermediate code file, a function node list can be constructed based on the function nodes corresponding to the multiple intermediate code files in the updated source code of the software under test. The function node list includes the function nodes corresponding to the multiple intermediate code files.

[0101] In this embodiment, to determine the test interfaces of the software under test, in addition to determining the list of function nodes in the updated source code, it is also necessary to determine the interfaces contained in the updated source code. Based on this, in step 103, the configuration file of the updated source code of the software under test can be parsed to obtain the interface list of the updated source code. In this embodiment, the interface can be an HTTP type interface, that is, the interface name provided by the backend service to the client for calling in a client / server (C / S) architecture or browser / server (B / S) architecture network, such as a URL.

[0102] Based on the description of the contents of the configuration file above, it can be seen that the virtual host settings (server) module is mainly used to specify the virtual machine host domain name, IP address, and port. For the interface URL, the virtual machine host domain name is a major component of the URL. Furthermore, the IF statement in the virtual host settings module sets the request path for the interface. Therefore, to determine the interface of the updated source code of the software under test, the virtual host settings (server) module in the configuration file can be obtained. Optionally, the findall method can be used to obtain the virtual host settings module in the configuration file.

[0103] Furthermore, the virtual machine host domain name in the virtual host settings module can be obtained; further, the virtual host settings module can be parsed to obtain the request path of the interface in the first source code; then, the virtual machine host domain name and the request path can be concatenated to obtain the interface in the interface list of the first source code.

[0104] In this application embodiment, the specific implementation of the request path of the interface for obtaining the first source code is not limited. In some embodiments, an IF statement in the virtual host settings module can be obtained; if the IF statement contains a target IF statement with a $request_uri variable, the request path of the interface is determined according to the path parameter recorded in the condition record of the target IF statement and the $request_uri variable. This is mainly because if the IF statement contains a $request_uri variable, it indicates that there is an interface request path rewriting, that is, the request path of the interface URL does not directly correspond to the file path where the service is located. Therefore, it is necessary to determine the interface request path according to the path parameter recorded in the condition record of the target IF statement and the $request_uri variable.

[0105] In this embodiment, the configuration file further includes a mapping module. The mapping module records the correspondence between path parameters and parameter values ​​of the interface's request path. Based on this, the mapping module can also be obtained from the configuration file. Optionally, the `findall` method can be used to obtain the mapping module in the configuration file. Based on the mapping module in the configuration file, the above-mentioned determination of the interface's request path based on the path parameters recorded in the target IF statement's condition and the `$request_uri` variable can be implemented as follows: Based on the path parameters recorded in the target IF statement's condition, query the mapping module to determine the parameter values ​​corresponding to the path parameters recorded in the target IF statement's condition. Wherein, the parameter value corresponding to the path parameter recorded in the target IF statement is the next path parameter in the interface's request path located in the path parameter recorded in the target IF statement's condition. Therefore, further, using the parameter value corresponding to the path parameter recorded in the target IF statement's condition, query the mapping module to determine the parameter value of the next path parameter; wherein, the parameter value of the next path parameter is the parameter value corresponding to the `$request_uri` variable. Furthermore, if a subfile exists under the `$request_uri` variable, the parameter value corresponding to the path parameter of the target IF statement's condition record, the parameter value corresponding to the `$request_uri` variable, and the subfile's filename can be concatenated to obtain the API's request path. Further, the virtual host domain name and the API's request path can be concatenated to obtain the API URL. The API URL can be implemented as: virtual host domain name / parameter value corresponding to the path parameter of the target IF statement's condition record / parameter value corresponding to the `$request_uri` variable / subfile's filename.

[0106] Accordingly, if no subfile exists under the `$request_uri` variable, the parameter value corresponding to the path parameter of the condition record in the target IF statement and the parameter value corresponding to the `$request_uri` variable can be concatenated to obtain the request path of the interface. Furthermore, the virtual host domain name and the interface request path can be concatenated to obtain the interface URL. The interface URL can be implemented as: virtual host domain name / parameter value corresponding to the path parameter of the condition record in the target IF statement / parameter value corresponding to the `$request_uri` variable.

[0107] If the IF statement in the virtual host settings module does not contain a target IF statement with the $request_uri variable, the root path in the virtual host settings module can be obtained; and the filename under the root path can be obtained from the virtual host settings module as the request path of the interface. Furthermore, the virtual host domain name and the filename under the root path can be concatenated to obtain the interface URL. The interface URL can be implemented as: virtual host domain name / filename under the root path.

[0108] The following is combined Figure 3 The specific embodiments shown provide a detailed explanation of how to determine the interface list for the updated source code of the software under test. For example... Figure 3 As shown, this method mainly includes the following steps:

[0109] S11. Use the nginx parser plugin to read the nginx configuration file in the software under test.

[0110] S12. Use the findall method to retrieve the mapping modules in the configuration file.

[0111] S13. Use the findall method to retrieve the server module from the configuration file.

[0112] S14. Determine whether all server modules have been traversed. If the result is yes, proceed to step S116; if the result is no, proceed to step S15.

[0113] S15. From the server modules that have not yet been traversed, randomly select the target server module.

[0114] S16. Use the findParam method to obtain the virtual machine domain name and root path in the target server module.

[0115] S17. Obtain the IF statement of the target server module.

[0116] S18. Check if there is a target IF statement containing the $request_uri variable in the IF statement; if the result is yes, proceed to step S19; if the result is no, proceed to step S114.

[0117] S19. Based on the path parameters of the target IF statement condition record, query the mapping module to determine the parameter values ​​corresponding to the path parameters of the target IF statement condition record.

[0118] S110. Using the parameter value corresponding to the path parameter of the target IF statement's condition record as the next path parameter, query the mapping module to determine the parameter value of the next path parameter; where the parameter value of the next path parameter is the parameter value corresponding to the $request_uri variable.

[0119] S111. Determine if a subfile exists under the $request_uri variable. If the result is yes, proceed to step S112; if the result is no, proceed to step S113.

[0120] S112: Concatenate the virtual machine domain name in the target server module, the parameter value corresponding to the path parameter of the condition record in the target IF statement, the parameter value corresponding to the $request_uri variable, and the filename of the subfile to obtain the URL of the interface. Return to step S14.

[0121] S113. Concatenate the virtual machine domain name in the target server module, the parameter value corresponding to the path parameter of the condition record in the target IF statement, and the parameter value corresponding to the $request_uri variable to obtain the URL of the interface. Return to step S14.

[0122] S114. Obtain the filename under the root path from the target server module.

[0123] S115. Concatenate the virtual machine domain name and the filename under the root path in the target server module to obtain the URL of the interface. Return to step S14.

[0124] S116. Use all the concatenated interface URLs to form an interface list and output it.

[0125] The above embodiments exemplify how to determine the function node list and interface list of the updated source code of the software under test. After obtaining the updated function node list and interface list of the source code, in step 104, the function call chain of the interfaces in the interface list can be generated based on the updated function node list and interface list of the source code.

[0126] Specifically, the entry class corresponding to an interface in the interface list can be determined. In this embodiment, the specific implementation of determining the entry class corresponding to an interface is not limited. In some embodiments, the entry class corresponding to an interface in the interface list can be determined based on the request path of the interface in the first source code of the software under test after the update. Specifically, if the request path of the interface in the first source code is determined based on the path parameter recorded in the condition record of the target IF statement and the $request_uri variable, then the root path in the virtual host settings module and the parameter value corresponding to the $request_uri variable are concatenated as the entry class corresponding to that interface. Correspondingly, if the request path of the interface in the first source code is a filename under the root path in the virtual host settings module, the filename under the root path is determined as the entry class corresponding to the interface.

[0127] Based on the entry class corresponding to the interface in the interface list, the methods contained in the entry class can be determined according to the function node list; and the entry function of the interface can be determined according to the methods contained in the entry class. Optionally, if the entry class contains a `run` method, the `run` method is determined to be the entry function of the interface. If the entry class does not contain a `run` method, the parent class of the entry class corresponding to the interface is determined to be the target entry class of the interface; further, the `run` method in the target entry class can be determined to be the entry function of the interface. The parent class of the entry class corresponding to the interface can be determined as follows: based on the keyword "parent", the line of code declaring the parent class is determined in the intermediate code file corresponding to the entry class; and the parent class of the entry class corresponding to the intermediate code file is obtained from the line of code declaring the parent class, which is the parent class of the entry class corresponding to the interface.

[0128] After determining the entry function of the interface, a function call chain for the interface can be generated based on the entry function and function nodes. Specifically, the entry function can be used as the initial traversal function to obtain the first function node with the currently traversed function as the calling function. If there is a called function in the first function node, the called function in the first function node is recursively added to the assembled function call chain as the called function of the currently traversed function. The called function of the currently traversed function is used as the new calling function, and the operation of obtaining the first function node with the currently traversed function as the calling function is returned, until there is no called function in the first function node, thus obtaining the function call chain of the interface.

[0129] Optionally, before recursively adding the called function in the first function node as the called function of the currently traversed function to the assembled function call chain, it can be determined whether the called function in the first function node exists in the assembled function call chain; if the determination result is no, then the called function in the first function node is recursively added to the assembled function call chain of the interface as the called function of the currently traversed function.

[0130] Optionally, the called function in the first function node can also be queried in the function node list. If a second function node with the called function in the first function node as its calling function is found in the function node list, the called function in the first function node will be recursively added to the assembled function call chain as the called function of the currently traversed function. Correspondingly, if the target function node is not found in the function node list, the called function in the first function node is used to search for functions contained in the parent class of the currently traversed function. If the called function in the first function node is found in the functions contained in the parent class of the currently traversed function, the called function in the first function node will be recursively added to the assembled function call chain as the called function of the currently traversed function. Correspondingly, if the called function in the first function node is not found in the functions contained in the parent class of the currently traversed function, the called function in the first function node will be recursively added to the assembled function call chain as the called function of the currently traversed function, and the loop ends, resulting in the function call chain of the interface.

[0131] To facilitate understanding of the specific implementation process of the function call chain for determining the interface, the following will combine... Figure 4 The specific embodiments shown are illustrated by way of example. Figure 4 As shown. The main methods for determining the function call chain of an interface include:

[0132] S21. Determine the entry class corresponding to the interface in the interface list.

[0133] S22. Determine if the entry class contains a `run` method. If the result is yes, proceed to step S23; if the result is no, proceed to step S24.

[0134] S23. Determine the entry point as the `run` method. Then proceed to step S26.

[0135] S24. Determine that the parent class of the entry class corresponding to the interface is the target entry class of the interface; and then execute step S25.

[0136] S25. Determine the run method in the target entry class as the entry function. Then proceed to step S26.

[0137] S26. Using the entry function as the initial traversal function, traverse the function node list sequentially.

[0138] S27. For the currently traversed function, retrieve the first function node from the function node list that is the calling function of the currently traversed function.

[0139] S28. Determine whether the called function of the first function node is empty. If the result is no, proceed to step S29; if the result is yes, proceed to step S218.

[0140] S29. Get the called function in the first function node.

[0141] S210. Determine whether the called function in the first function node exists in the assembled function call chain. If it does not exist, proceed to step S211; if it does exist, the called function of the first function node is not added to the function call chain, and proceed to step S214.

[0142] S211. Use the called function in the first function node to search the function node list.

[0143] S212. Determine if the function node list contains a second function node whose calling function is the called function in the first function node. If the result is yes, proceed to step S213; if the result is no, proceed to step S215.

[0144] S213. Add the called function in the first function node as the called function of the currently traversed function to the assembled function call chain recursively. Then execute step S214.

[0145] S214. Take the called function in the first function node as the new currently traversed function, and return to execute step S27.

[0146] S215. Use the called function in the first function node to search for functions contained in the parent class of the currently traversed function.

[0147] S216. Determine if the parent class of the currently traversed function contains a function that is called in the first function node. If the result is yes, proceed to step S213. If the result is no, proceed to step S217.

[0148] S217. Add the called function in the first function node as the called function of the currently traversed function, and recursively add it to the assembled function call chain. Then return to step S218.

[0149] S218. End the function call chain assembly and output the function call chain of the interface.

[0150] Since the function call chain of the above interface is obtained by parsing static intermediate code files and configuration files, the function call chain obtained in the embodiments of the present application is a static function call chain. A static function call chain refers to a function call chain assembled by parsing static source code or static intermediate code. Therefore, in the embodiments of the present application, during the process of generating the static function call chain, it is not necessary to execute the updated source code of the software to be tested, which can eliminate the time consumption of executing the updated source code of the software to be tested, help accelerate the generation speed of the function call chain, improve the generation efficiency of the function call chain, and further help improve the efficiency of subsequently determining the test interface of the changed function based on the function call chain.

[0151] In actual testing, for the software to be tested, only the changed functions can be tested. Therefore, to achieve accurate testing, the test interface may be the interface corresponding to the changed function. Based on this, in step 105 of the embodiments of the present application, the changed function of the software to be tested can be determined according to the source code of the software to be tested before and after the update. In the embodiments of the present application, for convenience of description and distinction, the updated source code and the pre-update source code of the software to be tested are defined as first source code and second source code respectively.

[0152] Optionally, as Figure 5 shown, the first source code and the second source code may be parsed in a multi-threaded manner respectively, so as to obtain a first Abstract Syntax Tree (AST) corresponding to the first source code and a second Abstract Syntax Tree (AST) corresponding to the second source code. It should be noted that, in Figure 5 , Diff files 1-n are source code files corresponding to the first source code and the second source code. Both the first source code and the second source code may correspond to multiple Diff files. Multiple refers to 2 or more than 2. In the embodiments of the present application, the specific number of source code files respectively corresponding to the first source code and the second source code is not limited. For example, the source code files corresponding to the first source code may be Diff file 1 to Diff file (n-x); the source code files corresponding to the second source code may be Diff file (n-x+1) to Diff file n, where 0<x<(n-1), and both n and x are integers. Accordingly, the above parsing of the first source code and the second source code in a multi-threaded manner respectively means that the multiple source code files (Diff files) corresponding to the first source code can be parsed in parallel in a multi-threaded manner to obtain multiple abstract syntax trees, that is, the first abstract syntax tree; and the multiple source code files (Diff files) corresponding to the second source code can be parsed in parallel in a multi-threaded manner to obtain multiple abstract syntax trees, that is, the second abstract syntax tree.

[0153] Furthermore, the first abstract syntax tree and the second abstract syntax tree can be compared to determine the change functions of the software under test. These change functions include: add functions, delete functions, and update functions.

[0154] After identifying the modified function of the software under test, in step 106, the interface corresponding to the modified function can be determined as the test interface of the software under test based on the function call chain corresponding to the interface in the interface list. Specifically, the modified function can be queried in the function call chain corresponding to the interface to determine the target function call chain containing the modified function; further, the interface corresponding to the target function call chain is determined as the interface corresponding to the modified function, i.e., the test interface.

[0155] The modified functions include: added functions, deleted functions, and updated functions. For deleted functions, although they are removed from the updated software under test, they may affect the operation of other functions, and the interface corresponding to the function call chain of the deleted function still exists. Therefore, when testing the software under test, testing can also be performed based on the test interface corresponding to the deleted function. In this embodiment, a corresponding test plan can be associated with each software test interface. A plan identifier (ID) can be set for each test plan to uniquely identify it, and the plan identifier, the software interface call function chain, and the modified functions of the software are stored. Based on this, when determining the test interface of the software under test, such as... Figure 6 As shown, the identifiers of the test plan (such as...) can be used. Figure 6 The plan ID is queried in the stored data (i.e., Figure 6 The query shows whether data exists based on the plan ID; if the call function chain and modification function of the interface corresponding to the test plan's identifier are found (i.e., ... Figure 6 (The data shown exists). The modified function can be used to query the function call chain corresponding to the interface to determine the target function call chain containing the modified function. Specifically, the function name and class name of the modified function can be matched in the function call chain corresponding to the interface to determine the function call chain containing both the modified function's name and class name as the target function call chain. Further, the interface corresponding to the target function call chain is determined to be the interface corresponding to the modified function; further, the interface corresponding to the modified function of the software under test can be stored, i.e., the test interface of the software under test. Optionally, the interface recommendation status of the software under test can also be set to a successful status, such as setting the recommendation status to 1. In this embodiment, during the process of determining the test interface of the software under test, the interface recommendation status of the software under test can be set to "Interface Recommendation in Progress," such as setting the interface recommendation status to 0. Of course, if the determination of the test interface of the software under test fails, the interface recommendation status can be set to "Interface Recommendation Failed," such as setting the interface recommendation status to 2 or 3, etc.

[0156] in, Figure 6 The parameter validation in this context mainly refers to verifying whether information such as the name of the software under test, the source code of the software under test (both before and after the update), the list of interfaces of the software under test, and the identifier of the test plan are empty. If all the parameter validation parameters are not empty, the parameter validation is considered successful.

[0157] In this embodiment, since the function call chain is obtained by parsing static intermediate code files and configuration files, the function call chain obtained in this embodiment is a static function call chain. A static function call chain refers to a function call chain assembled by parsing static source code or static intermediate code. Therefore, in the process of generating a static function call chain in this embodiment, it is not necessary to execute the updated source code of the software under test, thus avoiding the time-consuming process of executing the updated source code. This helps to accelerate the generation speed of the function call chain, improve the generation efficiency, and consequently improve the efficiency of subsequently determining the test interface of the changed functions based on the function call chain.

[0158] In this embodiment, after determining the test interface of the software under test, test cases can be determined based on the test interface. For example, the test interface can be matched against a predefined correspondence between test interfaces and test cases to obtain the corresponding test cases. Furthermore, the test cases can be run to test the modified functions, thereby achieving automated testing of the modified functions of the software under test.

[0159] In other embodiments, a test interface may also be output, allowing testers to select test cases based on the interface. For example, test cases may be displayed on a screen. Furthermore, in response to the execution of test cases, the test cases can be run to test the changed functions, enabling testers to independently select test cases.

[0160] In addition to the test interface determination method provided in the above embodiments, this application also provides a function call chain generation method, such as... Figure 7 As shown, the function call chain generation method provided in this application mainly includes:

[0161] 701. Obtain the intermediate code files and configuration files of the target code.

[0162] 702. Parse multiple intermediate code files to obtain a list of function nodes in the target code.

[0163] 703. Parse the configuration file to obtain the interface list of the target code.

[0164] 704. Based on the interface list and function node list, generate the function call chain of the interfaces in the interface list.

[0165] In this embodiment, the target code can be script code in any programming language. For example, the target code can be any PHP script code that requires determining the function call chain. In this embodiment, the interface list and function node list of the target code can be obtained by parsing the configuration file and intermediate code file of the target code; and the function call chain of the interface in the interface list can be generated based on the interface list and function node list of the target code. Since the function call chain is obtained by parsing the static intermediate code file and configuration file, the function call chain obtained in this embodiment is a static function call chain. When generating a static function call chain, it is not necessary to execute the updated source code of the software under test, which saves the time spent executing the updated source code of the software under test, helps to speed up the generation of the function call chain, and improves the generation efficiency of the function call chain.

[0166] For details on the specific implementation of steps 701-704, please refer to the relevant content of steps 101-104 above, which will not be repeated here.

[0167] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 101 and 102 can be device A; or the execution subject of step 101 can be device A, and the execution subject of step 102 can be device B; and so on.

[0168] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 102, 103, etc., are merely used to distinguish different operations and do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0169] Accordingly, embodiments of this application also provide a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause one or more processors to perform the steps in the above-described test interface determination method and / or function call chain generation method.

[0170] Figure 8 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Figure 8 As shown, the computing device includes: a memory 80a and a processor 80b; wherein the memory 80a is used to store computer programs.

[0171] The processor 80b is coupled to the memory 80a and is used to execute a computer program for: acquiring a configuration file and multiple intermediate code files of the updated first source code of the software under test; parsing the multiple intermediate code files to obtain a function node list of the first source code; and parsing the configuration file to obtain an interface list of the first source code; generating a function call chain of the interfaces in the interface list based on the interface list and the function node list; determining the changed functions of the software under test based on the first source code and the second source code of the software under test before the update; and determining the interface corresponding to the changed function as the test interface of the software under test based on the function call chain corresponding to the interface in the interface list.

[0172] In some embodiments, when parsing multiple intermediate code files, the processor 80b specifically performs the following steps: for each intermediate code file in the multiple intermediate code files, parses the intermediate code file to determine the first function defined in the intermediate code file; determines the function name and class of the second function called by the first function according to the language organization rules of the called function in the intermediate code file; generates the function node corresponding to the intermediate code file according to the function name, class, and class of the second function; and constructs a function node list using the function nodes corresponding to the multiple intermediate code files.

[0173] Optionally, when determining the function name and class of the second function called by the first function, the processor 80b specifically performs the following steps: determining the function type of the second function according to the language organization rules of the called function in the intermediate code file; and determining the function name and class of the second function according to the language organization rules corresponding to the function type of the second function in the intermediate code file.

[0174] In some embodiments, when determining the function name and class of the second function, the processor 80b specifically performs the following steps: obtaining the number of operands contained in the second function from the intermediate code file; and determining the function name and class of the second function according to the language organization rules corresponding to the number of operands under the function type of the second function in the intermediate code file.

[0175] In some embodiments, the function type of the second function is a static function; the number of operands of the second function is two operands. Accordingly, when determining the function name and class of the second function, the processor 80b is specifically configured to: determine that the second operand of the two operands is the function name of the second function; and determine the class of the second function according to the format of the first operand of the two operands.

[0176] Furthermore, when determining the class of the second function, the processor 80b specifically performs the following: if the format of the first operand of the double operand is a specified format, it determines the class of the second function based on the type of the class defined in the code line preceding the code line containing the double operand; if the format of the first operand of the double operand is not a specified format, it determines the first operand as the class of the second function.

[0177] Optionally, when determining the class of the second function based on the format of the code line preceding the code line containing the two operands, the processor 80b specifically performs the following: if the type of the class defined in the code line preceding the code line containing the two operands is a first specified type, the processor determines that the class of the second function is the current class corresponding to the intermediate code file; if the format of the code line preceding the code line containing the two operands is a second specified type, the processor determines that the class of the second function is the parent class of the current class.

[0178] In other embodiments, the function type of the second function is a static function; the number of operands of the second function is a single operand. When determining the function name and class of the second function, the processor 80b specifically performs the following: determining that the function name of the second function is a constructor; and determining the class of the second function based on the format of the single operand name.

[0179] Furthermore, when determining the class of the second function based on the format of the operand name of the single operand, the processor 80b specifically performs the following: if the format of the operand name of the single operand is a specified format, it determines the class of the second function based on the type of the class defined in the code line preceding the code line where the single operand is located; if the format of the operand name of the single operand is not a specified format, it determines the operand name of the single operand as the class of the second function.

[0180] Optionally, when determining the class of the second function based on the type of the class defined in the preceding line of code where the single operand is located, the processor 80b specifically performs the following: if the type of the class defined in the preceding line of code where the single operand is located is a first specified type, the processor determines that the class of the second function is the current class corresponding to the intermediate code file; if the format of the preceding line of code where the single operand is located is a second specified type, the processor determines that the class of the second function is the parent class of the current class.

[0181] In some other embodiments, the function type of the second function is a regular function; the number of operands in the second function is two operands. Accordingly, when determining the function name and class of the second function, the processor 80b specifically performs the following: determining the function name and class of the second function based on the operation type of the code line preceding the code line containing the two operands.

[0182] Furthermore, when determining the function name and class of the second function, the processor 80b specifically performs the following steps: if the operation type of the code line preceding the code line containing the two operands is a variable assignment operation, then the second operand name of the two operands is determined to be the function name of the second function; the variable declaration operation line that declares the variable name is found in the intermediate code file through the variable name corresponding to the variable assignment operation; the internal variable assignment operation line of the first function is located based on the variable declaration operation line; the initialization code line of the internal variable name is found in the intermediate code file through the internal variable name corresponding to the internal variable assignment operation line; and the operand name of the initialization code line is determined to be the class name of the second function.

[0183] Optionally, when processor 80b determines the function name and class of the second function based on the operation type of the code line preceding the code line containing the two operands, it specifically performs the following: if the operation type of the code line preceding the code line containing the two operands is not a variable assignment operation, it determines that the second operand name of the two operands is the function name of the second function; it searches for the line of internal variable assignment operation in the intermediate code file; it searches for the first initialization operation that initializes the internal variable name in the intermediate code file based on the internal variable name corresponding to the line of internal variable assignment operation; and it determines the class of the second function based on the query result of the first initialization operation.

[0184] Optionally, when determining the class of the second function based on the query result of the initialization code line for querying the internal variable name, the processor 80b specifically performs the following: if a first initialization operation is found, it calls the factory function that performs the initialization operation; and determines that the class declared by the factory function is the class of the second function. Correspondingly, if a first initialization operation is not found, it uses the internal variable name to search for a second initialization operation that initializes the internal variable name in the intermediate code file; and determines that the operand name of the second initialization operation is the class name of the second function.

[0185] In some other embodiments, the function type of the second function is a regular function; the number of operands of the second function is a single operand. Accordingly, when determining the function name and class of the second function, the processor 80b specifically performs the following: determining that the operand name of the single operand is the function name of the second function; and determining that the class of the second function is the current class corresponding to the intermediate code file.

[0186] In some embodiments of this application, when the processor 80b parses the configuration file, it is specifically used to: obtain the virtual host settings module in the configuration file; obtain the virtual machine host domain name in the virtual host settings module; parse the virtual host settings module to obtain the request path of the interface of the first source code; and concatenate the virtual machine host domain name and the request path to obtain the interface in the interface list of the first source code.

[0187] Optionally, when parsing the virtual host settings module, the processor 80b is specifically used to: obtain the IF statement in the virtual host settings module; and if there is a target IF statement containing the $request_uri variable in the IF statement, determine the request path of the interface based on the path parameter recorded in the condition record of the target IF statement and the $request_uri variable.

[0188] In some embodiments, the processor 80b is further configured to: obtain a mapping module from a configuration file; the mapping module records the correspondence between path parameters and parameter values ​​of the request path of the interface. When determining the request path of the interface based on the path parameters recorded in the condition record of the target IF statement and the $request_uri variable, the processor 80b specifically configures itself to: query the mapping module based on the path parameters recorded in the condition record of the target IF statement to determine the parameter values ​​corresponding to the path parameters recorded in the condition record of the target IF statement; wherein, the parameter values ​​corresponding to the path parameters recorded in the condition record of the target IF statement are the next path parameter in the request path of the interface located in the path path of the path parameters recorded in the condition record of the target IF statement; using the parameter values ​​corresponding to the path parameters recorded in the condition record of the target IF statement, query the mapping module to determine the parameter values ​​of the next path parameters; wherein, the parameter values ​​of the next path parameters are the parameter values ​​corresponding to the $request_uri variable; if there are subfiles under the $request_uri variable, concatenate the parameter values ​​corresponding to the path parameters recorded in the condition record of the target IF statement, the parameter values ​​corresponding to the $request_uri variable, and the filenames of the subfiles to obtain the request path of the interface. Accordingly, if no subfile exists under the $request_uri variable, the parameter value corresponding to the path parameter of the condition record of the target IF statement and the parameter value corresponding to the $request_uri variable are concatenated to obtain the request path of the interface.

[0189] Optionally, when parsing the virtual host settings module, the processor 80b is also used to: obtain the root path in the virtual host settings module if there is no target IF statement containing the $request_uri variable in the IF statement; and obtain the filename under the root path from the virtual host settings module as the request path of the interface.

[0190] In this embodiment, the processor 80b is further configured to: determine the entry class corresponding to the interface in the interface list based on the request path of the interface in the first source code. When generating the function call chain of the interface based on the interface list and the function node list, the processor 80b is specifically configured to: determine the methods contained in the entry class corresponding to the interface based on the function node list; determine the entry function of the interface based on the methods contained in the entry class; and generate the function call chain of the interface based on the entry function and the function node list.

[0191] Optionally, when determining the entry function of an interface based on the methods contained in the entry class, the processor 80b specifically performs the following: if the methods contained in the entry class have an entry run method, determine the entry run method as the entry function. Correspondingly, if the methods contained in the entry class do not have an entry run method, determine that the parent class of the corresponding entry class of the interface is the target entry class of the interface; and determine that the run method in the target entry class is the entry function.

[0192] Optionally, when the processor 80b generates the function call chain of the interface based on the entry function and the function node list, it specifically performs the following steps: using the entry function as the initial traversal function, it retrieves the first function node from the function node list, with the currently traversed function as the calling function; if the first function node contains a called function, it recursively adds the called function in the first function node as the called function of the currently traversed function to the assembled function call chain of the interface; it then uses the called function of the currently traversed function as the new calling function and returns to execute the operation of retrieving the first function node of the calling function, until the first function node has no called function, thus obtaining the function call chain of the interface.

[0193] Optionally, the processor 80b is further configured to: determine whether the called function in the first function node exists in the assembled function call chain of the interface before recursively adding the called function in the first function node as the called function of the currently traversed function to the assembled function call chain; if the determination result is no, then recursively add the called function in the first function node as the called function of the currently traversed function to the assembled function call chain of the interface.

[0194] Optionally, when processor 80b recursively adds the called function in the first function node as the called function of the currently traversed function to the assembled function call chain of the interface, it specifically performs the following: using the called function in the first function node to search in the function node list; if a second function node with the called function in the first function node as the calling function is found in the function node list, the called function in the first function node is recursively added to the assembled function call chain of the interface as the called function of the currently traversed function.

[0195] Optionally, the processor 80b is further configured to: if the second function node is not found in the function node list, use the called function in the first function node to search for functions contained in the parent class of the currently traversed function; if the called function in the first function node is found in the functions contained in the parent class of the currently traversed function, recursively add the called function in the first function node as the called function of the currently traversed function to the assembled function call chain of the interface. Correspondingly, if the called function in the first function node is not found in the functions contained in the parent class of the currently traversed function, recursively add the called function in the first function node as the called function of the currently traversed function to the assembled function call chain of the interface, and then terminate the loop.

[0196] In some embodiments of this application, when determining the change function of the software under test, the processor 80b is specifically configured to: parse the first source code and the second source code in a multi-threaded manner to obtain a first abstract syntax tree corresponding to the first source code and a second abstract syntax tree corresponding to the second source code; and compare the first abstract syntax tree and the second abstract syntax tree to determine the change function of the software under test.

[0197] Optionally, when the processor 80b determines that the interface corresponding to the modified function is the test interface of the software under test, it specifically performs the following: using the modified function to query the function call chain corresponding to the interface to determine the target function call chain containing the modified function; and determining that the interface corresponding to the target function call chain is the interface corresponding to the modified function.

[0198] Furthermore, the processor 80b is also used to: determine test cases based on the test interface; run test cases to test the changed function; or, output the test interface for testers to select test cases based on the test interface; and run test cases to test the changed function in response to the execution operation of the test cases.

[0199] Optionally, when outputting the test interface, the processor 80b may specifically be used to: display the test interface through the display component 80c; or send the test interface to the client through the communication component 80d, etc.

[0200] In this embodiment of the application, the processor 80b can also be used to: obtain intermediate code files and configuration files of the target code; parse the intermediate code files to obtain a list of function nodes of the target code; parse the configuration files to obtain a list of interfaces of the target code; and generate a function call chain of the interfaces in the interface list based on the interface list and the list of function nodes.

[0201] In some alternative implementations, such as Figure 8 As shown, the computing device may also include components such as a power supply component 80e and an audio component 80f. Figure 8The diagram only shows some components and does not mean that the computing device must contain them. Figure 8 The inclusion of all components does not imply that a computing device can only include... Figure 8 The components shown.

[0202] The computing device provided in this embodiment can parse the configuration file and intermediate code file of the updated source code of the software under test to obtain the interface list and function node list of the updated source code of the software under test. Based on the interface list and function node list of the updated source code of the software under test, it generates function call chains for the interfaces in the interface list. Subsequently, based on the function call chains corresponding to the interfaces, it determines the interface corresponding to the changed function of the software under test as the test interface of the software under test. Since the function call chain is obtained by parsing static intermediate code files and configuration files, the function call chain obtained in this embodiment is a static function call chain. During the generation of the static function call chain, it is not necessary to execute the updated source code of the software under test, thus saving the time spent executing the updated source code and helping to speed up the generation of the function call chain, improve the generation efficiency of the function call chain, and further improve the efficiency of subsequently determining the test interface of the changed function based on the function call chain.

[0203] In this embodiment, the memory is used to store computer programs and can be configured to store various other data to support operation on its host device. The processor can execute the computer programs stored in the memory to implement corresponding control logic. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0204] In the embodiments of this application, the processor can be any hardware processing device capable of executing the above-described method logic. Optionally, the processor can be a central processing unit (CPU), a graphics processing unit (GPU), or a microcontroller unit (MCU); it can also be a field-programmable gate array (FPGA), a programmable array logic (PAL), a general array logic (GAL), a complex programmable logic device (CPLD), or other programmable devices; or it can be an advanced reduced instruction set (RISC) processor (ARM) or a system on chip (SOC), etc., but is not limited thereto.

[0205] In this embodiment, the communication component is configured to facilitate wired or wireless communication between its host device and other devices. The device housing the communication component can access wireless networks based on communication standards, such as WiFi, 2G or 3G, 4G, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In another exemplary embodiment, the communication component may also be implemented based on Near Field Communication (NFC), Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wideband (UWB), Bluetooth (BT), or other technologies.

[0206] In embodiments of this application, the display component may include a liquid crystal display (LCD) and a touch panel (TP). If the display component includes a touch panel, the display component may be implemented as a touchscreen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may not only sense the boundaries of touch or swipe actions but also detect the duration and pressure associated with the touch or swipe operation.

[0207] In this embodiment, a power supply component is configured to provide power to various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component resides.

[0208] In embodiments of this application, the audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC), which is configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals. For example, in devices with voice interaction capabilities, voice interaction with the user can be achieved through the audio component.

[0209] Figure 9 This is a schematic diagram of the test interface determination device provided in an embodiment of this application. Figure 9 As shown, the test interface determination device includes:

[0210] The acquisition module 90a is used to acquire the configuration file and multiple intermediate code files of the first source code of the software under test after the update;

[0211] The parsing module 90b is used to parse the plurality of intermediate code files to obtain a list of function nodes of the first source code; and to parse the configuration file to obtain a list of interfaces of the first source code.

[0212] The generation module 90c is used to generate the function call chain of the interface in the interface list based on the interface list and the function node list;

[0213] The determination module 90d is used to determine the changed function of the software under test based on the first source code and the second source code of the software under test before the update; and to determine the interface corresponding to the changed function as the test interface of the software under test from the interface list based on the function call chain corresponding to the interface in the interface list.

[0214] In some embodiments, when parsing multiple intermediate code files, the parsing module 90b is specifically used to: parse each intermediate code file to determine the first function defined in the class contained in the intermediate code file; determine the function name and class of the second function called by the first function according to the language organization rules of the called function in the intermediate code file; generate the function node corresponding to the intermediate code file based on the function name, class, and class of the first and second functions; and construct a function node list using the function nodes corresponding to the multiple intermediate code files.

[0215] Optionally, when determining the function name and class of the second function called by the first function, the parsing module 90b is specifically used to: determine the function type of the second function according to the language organization rules of the called function in the intermediate code file; and determine the function name and class of the second function according to the language organization rules corresponding to the function type of the second function in the intermediate code file.

[0216] In some embodiments, when determining the function name and class of the second function, the parsing module 90b is specifically used to: obtain the number of operands contained in the second function from the intermediate code file; and determine the function name and class of the second function according to the language organization rules corresponding to the number of operands under the function type of the second function in the intermediate code file.

[0217] In some embodiments, the function type of the second function is a static function; the number of operands of the second function is two operands. Accordingly, when determining the function name and class of the second function, the parsing module 90b is specifically used to: determine that the second operand of the two operands is the function name of the second function; and determine the class of the second function according to the format of the first operand of the two operands.

[0218] Furthermore, when determining the class of the second function, the parsing module 90b is specifically used to: if the format of the first operand of the two operands is a specified format, determine the class of the second function according to the type of the class defined in the code line preceding the code line where the two operands are located; if the format of the first operand of the two operands is not a specified format, determine the first operand as the class of the second function.

[0219] Optionally, when the parsing module 90b determines the class of the second function based on the format of the code line preceding the code line containing the two operands, it specifically performs the following: if the type of the class defined in the code line preceding the code line containing the two operands is a first specified type, it determines that the class of the second function is the current class corresponding to the intermediate code file; if the format of the code line preceding the code line containing the two operands is a second specified type, it determines that the class of the second function is the parent class of the current class.

[0220] In other embodiments, the function type of the second function is a static function; the number of operands of the second function is a single operand. When determining the function name and class of the second function, the parsing module 90b is specifically used to: determine that the function name of the second function is a constructor; and determine the class of the second function based on the format of the single operand name.

[0221] Furthermore, when determining the class of the second function based on the format of the operand name of the single operand, the parsing module 90b is specifically used as follows: if the format of the operand name of the single operand is the specified format, the class of the second function is determined according to the type of the class defined in the code line preceding the code line where the single operand is located; if the format of the operand name of the single operand is not the specified format, the operand name of the single operand is determined to be the class of the second function.

[0222] Optionally, when the parsing module 90b determines the class of the second function based on the type of the class defined in the code line preceding the code line containing the single operand, it specifically performs the following: if the type of the class defined in the code line preceding the code line containing the single operand is a first specified type, it determines that the class of the second function is the current class corresponding to the intermediate code file; if the format of the code line preceding the code line containing the single operand is a second specified type, it determines that the class of the second function is the parent class of the current class.

[0223] In some other embodiments, the function type of the second function is a regular function; the number of operands in the second function is two operands. Accordingly, when determining the function name and class of the second function, the parsing module 90b is specifically used to: determine the function name and class of the second function based on the operation type of the code line preceding the code line containing the two operands.

[0224] Furthermore, when determining the function name and class of the second function, the parsing module 90b specifically performs the following: if the operation type of the code line preceding the code line containing the two operands is a variable assignment operation, then the name of the second operand of the two operands is determined to be the function name of the second function; the variable declaration operation line that declares the variable name is found in the intermediate code file through the variable name corresponding to the variable assignment operation; the internal variable assignment operation line of the first function is located based on the variable declaration operation line; the initialization code line of the internal variable name is found in the intermediate code file through the internal variable name corresponding to the internal variable assignment operation line; and the operand name of the initialization code line is determined to be the class name of the second function.

[0225] Optionally, when the parsing module 90b determines the function name and class of the second function based on the operation type of the code line preceding the code line containing the two operands, it specifically performs the following: if the operation type of the code line preceding the code line containing the two operands is not a variable assignment operation, it determines that the second operand name of the two operands is the function name of the second function; it searches for the line of internal variable assignment operation in the intermediate code file; it searches for the first initialization operation that initializes the internal variable name in the intermediate code file based on the internal variable name corresponding to the line of internal variable assignment operation; and it determines the class of the second function based on the query result of the first initialization operation.

[0226] Optionally, when the parsing module 90b determines the class of the second function based on the query results of the initialization code line for the internal variable name, it specifically performs the following: if a first initialization operation is found, it calls the factory function that performs the initialization operation; and determines that the class declared by the factory function is the class of the second function. Correspondingly, if a first initialization operation is not found, it uses the internal variable name to search for a second initialization operation in the intermediate code file that initializes the internal variable name; and determines that the operand name of the second initialization operation is the class name of the second function.

[0227] In some embodiments, the function type of the second function is a regular function; the number of operands of the second function is a single operand. Accordingly, when determining the function name and class of the second function, the parsing module 90b is specifically used to: determine that the operand name of the single operand is the function name of the second function; and determine that the class of the second function is the current class corresponding to the intermediate code file.

[0228] In some embodiments of this application, when parsing the configuration file, the parsing module 90b is specifically used to: obtain the virtual host settings module in the configuration file; obtain the virtual machine host domain name in the virtual host settings module; parse the virtual host settings module to obtain the request path of the interface of the first source code; and concatenate the virtual machine host domain name and the request path to obtain the interface in the interface list of the first source code.

[0229] Optionally, when parsing the virtual host settings module, the parsing module 90b is specifically used to: obtain the IF statement in the virtual host settings module; and, if there is a target IF statement containing the $request_uri variable in the IF statement, determine the request path of the interface based on the path parameter recorded in the condition record of the target IF statement and the $request_uri variable.

[0230] In some embodiments, the parsing module 90b is further configured to: obtain a mapping module from a configuration file; the mapping module records the correspondence between path parameters and parameter values ​​of the request path of the interface. When determining the request path of the interface based on the path parameters recorded in the condition record of the target IF statement and the $request_uri variable, the parsing module 90b specifically configures itself to: query the mapping module based on the path parameters recorded in the condition record of the target IF statement to determine the parameter values ​​corresponding to the path parameters recorded in the condition record of the target IF statement; wherein, the parameter values ​​corresponding to the path parameters recorded in the condition record of the target IF statement are the next path parameters in the request path of the interface located in the path path of the path parameters recorded in the condition record of the target IF statement; using the parameter values ​​corresponding to the path parameters recorded in the condition record of the target IF statement, query the mapping module to determine the parameter values ​​of the next path parameters; wherein, the parameter values ​​of the next path parameters are the parameter values ​​corresponding to the $request_uri variable; if a subfile exists under the $request_uri variable, concatenate the parameter values ​​corresponding to the path parameters recorded in the condition record of the target IF statement, the parameter values ​​corresponding to the $request_uri variable, and the filename of the subfile to obtain the request path of the interface. Accordingly, if no subfile exists under the $request_uri variable, the parameter value corresponding to the path parameter of the condition record of the target IF statement and the parameter value corresponding to the $request_uri variable are concatenated to obtain the request path of the interface.

[0231] Optionally, when parsing the virtual host settings module, the parsing module 90b is also used to: obtain the root path in the virtual host settings module if there is no target IF statement containing the $request_uri variable in the IF statement; and obtain the file name under the root path from the virtual host settings module as the request path of the interface.

[0232] In this embodiment, the determining module 90d is further configured to: determine the entry class corresponding to the interface in the interface list based on the request path of the interface. When generating the function call chain of the interface based on the interface list and the function node list, the generating module 90c is specifically configured to: determine the methods contained in the entry class corresponding to the interface based on the function node list; determine the entry function of the interface based on the methods contained in the entry class; and generate the function call chain of the interface based on the entry function and the function node list.

[0233] Optionally, when determining the entry function of an interface based on the methods contained in the entry class, the generation module 90c specifically performs the following: if the methods contained in the entry class have an entry run method, determine the entry run method as the entry function. Correspondingly, if the methods contained in the entry class do not have an entry run method, determine that the parent class of the corresponding entry class of the interface is the target entry class of the interface; and determine that the run method in the target entry class is the entry function.

[0234] Optionally, when generating the function call chain of the interface based on the entry function and the function node list, the generation module 90c specifically performs the following steps: using the entry function as the initial traversal function, it retrieves the first function node from the function node list, with the currently traversed function as the calling function; if the first function node contains a called function, it recursively adds the called function in the first function node to the assembled function call chain as the called function of the currently traversed function; it then uses the called function of the currently traversed function as the new calling function and returns to execute the operation of retrieving the first function node of the calling function, until the first function node has no called function, thus obtaining the function call chain of the interface.

[0235] Optionally, the generation module 90c is further configured to: determine whether the called function in the first function node exists in the assembled function call chain before recursively adding the called function in the first function node as the called function of the currently traversed function to the assembled function call chain; if the determination result is no, then recursively add the called function in the first function node as the called function of the currently traversed function to the assembled function call chain of the interface.

[0236] Optionally, when the generation module 90c recursively adds the called function in the first function node as the called function of the currently traversed function to the assembled function call chain, it specifically performs the following: using the called function in the first function node to search in the function node list; if a second function node with the called function in the first function node as the calling function is found in the function node list, the called function in the first function node is recursively added to the assembled function call chain of the interface as the called function of the currently traversed function.

[0237] Optionally, the generation module 90c is further configured to: if the second function node is not found in the function node list, use the called function in the first function node to search for functions contained in the parent class of the currently traversed function; if the called function in the first function node is found in the functions contained in the parent class of the currently traversed function, recursively add the called function in the first function node as the called function of the currently traversed function to the assembled function call chain. Correspondingly, if the called function in the first function node is not found in the functions contained in the parent class of the currently traversed function, recursively add the called function in the first function node as the called function of the currently traversed function to the assembled function call chain of the interface, and then end the loop.

[0238] In some embodiments of this application, when determining the change function of the software under test, the determining module 90d is specifically used to: parse the first source code and the second source code in a multi-threaded manner to obtain the first abstract syntax tree corresponding to the first source code and the second abstract syntax tree corresponding to the second source code; compare the first abstract syntax tree and the second abstract syntax tree to determine the change function of the software under test.

[0239] Optionally, when determining that the interface corresponding to the changed function is the test interface of the software under test, the determining module 90d is specifically used to: use the changed function to query the function call chain corresponding to the interface to determine the target function call chain containing the changed function; and determine that the interface corresponding to the target function call chain is the interface corresponding to the changed function.

[0240] Furthermore, the determining module 90d is also used to: determine test cases based on the test interface. In some embodiments, the test interface determining apparatus further includes: a running module 90e and / or an output module 90f. The running module 90e is used to run test cases to test the changed function. The output module 90f is used to output the test interface for testers to select test cases based on the test interface. Accordingly, the running module 90e runs the test cases in response to the execution operation of the test cases to test the changed function.

[0241] Optionally, when outputting the test interface, the output module 90f is specifically used to: display the test interface through a display component; or send the test interface to the client through a communication component, etc.

[0242] The test interface determination device provided in this embodiment can parse the configuration file and intermediate code file of the updated source code of the software under test to obtain the interface list and function node list of the updated source code of the software under test; and generate the function call chain of the interface in the interface list based on the interface list and function node list of the updated source code of the software under test; subsequently, based on the function call chain corresponding to the interface, determine the interface corresponding to the changed function of the software under test as the test interface of the software under test. Since the function call chain is obtained by parsing the static intermediate code file and configuration file, the function call chain obtained in this embodiment is a static function call chain. In the process of generating the static function call chain, it is not necessary to execute the updated source code of the software under test, which can save the time spent executing the updated source code of the software under test, help to speed up the generation speed of the function call chain, improve the generation efficiency of the function call chain, and thus help to improve the efficiency of subsequently determining the test interface of the changed function based on the function call chain.

[0243] Figure 10 This application provides a function call chain generation apparatus as an embodiment. For example... Figure 10 As shown, the function call chain generation device includes:

[0244] Module 100a is used to obtain intermediate code files and configuration files of the target code;

[0245] The parsing module 100b is used to parse the intermediate code file to obtain a list of function nodes of the target code; and to parse the configuration file to obtain a list of interfaces of the target code.

[0246] The generation module 100c is used to generate the function call chain of the interface in the interface list based on the interface list and the function node list.

[0247] For details on the specific implementation of the parsing module 100b in parsing the intermediate code file, please refer to the above. Figure 9 The details of the parsing of intermediate code files by the parsing module 90b are not elaborated here. For the specific implementation of the function call chains of the interfaces in the interface list generated by the generation module 100c, please refer to the relevant content regarding the generation of function call chains of the interfaces in the interface list by the generation module 90c mentioned above; these details will not be repeated here.

[0248] The function call chain generation device provided in this embodiment can obtain the interface list and function node list of the target code by parsing the configuration file and intermediate code file of the target code; and generate the function call chain of the interface in the interface list based on the interface list and function node list of the target code. Since the function call chain is obtained by parsing the static intermediate code file and configuration file, the function call chain obtained in this embodiment is a static function call chain. When generating a static function call chain, it is not necessary to execute the updated source code of the software under test, which can save the time spent executing the updated source code of the software under test, thus helping to speed up the generation of the function call chain and improve the generation efficiency of the function call chain.

[0249] It should be noted that the terms "first" and "second" in this article are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0250] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0251] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0252] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0253] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0254] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0255] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0256] Computer storage media are readable storage media, also known as removable media. Removable and non-removable media can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media do not include transient media, such as modulated data signals and carrier waves.

[0257] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0258] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for determining a test interface, characterized in that, include: Obtain the configuration file and multiple intermediate code files of the first source code of the software under test after the update; The multiple intermediate code files are parsed to obtain a list of function nodes for the first source code; The configuration file is parsed to obtain the interface list of the first source code; Based on the interface list and the function node list, generate the function call chain of the interface in the interface list; Based on the first source code and the second source code of the software under test before the update, determine the modified functions of the software under test; Based on the function call chain corresponding to the interface in the interface list, determine the interface corresponding to the change function as the test interface of the software under test from the interface list; The step of generating the function call chain of the interfaces in the interface list based on the interface list and the function node list includes: Based on the list of function nodes, determine the methods contained in the entry class corresponding to the interface in the interface list; Based on the methods contained in the entry class, determine the entry function of the interface; Based on the entry function and the list of function nodes, the function call chain of the interface is generated.

2. The method according to claim 1, characterized in that, The step of parsing the plurality of intermediate code files to obtain a list of function nodes for the first source code includes: For each of the plurality of intermediate code files, the intermediate code file is parsed to determine the first function of the class definition corresponding to the intermediate code file; Based on the language organization rules of the called functions in the intermediate code file, determine the function name of the second function called by the first function and the class of the second function; Based on the function name of the first function, the class of the first function, the function name of the second function, and the class of the second function, generate the function node corresponding to the intermediate code file; The function node list is constructed using the function nodes corresponding to the multiple intermediate code files.

3. The method according to claim 2, characterized in that, The step of determining the function name and class of the second function called by the first function according to the language organization rules of the called function in the intermediate code file includes: The function type of the second function is determined based on the language organization rules of the functions called in the intermediate code file; Based on the language organization rules corresponding to the function type of the second function in the intermediate code file, determine the function name and class of the second function.

4. The method according to claim 3, characterized in that, The step of determining the function name and class of the second function based on the language organization rules corresponding to the function type of the second function in the intermediate code file includes: Obtain the number of operands contained in the second function from the intermediate code file; Based on the language organization rules corresponding to the number of operands under the function type of the second function in the intermediate code file, determine the function name and class of the second function.

5. The method according to claim 4, characterized in that, The second function is a static function; the second function has two operands; determining the function name and class of the second function according to the language organization rules corresponding to the number of operands under the function type of the second function in the intermediate code file includes: The second operand of the two operands is determined to be the function name of the second function; The class of the second function is determined based on the format of the first operand of the two operands.

6. The method according to claim 5, characterized in that, Determining the class of the second function based on the format of the first operand of the two operands includes: If the format of the first operand of the two operands is a specified format, the class of the second function is determined according to the type of the class defined in the code line preceding the code line where the two operands are located; If the format of the first operand of the two operands is not the specified format, the first operand is determined to be the class of the second function.

7. The method according to claim 6, characterized in that, Determining the class of the second function based on the class type defined in the line preceding the line containing the two operands includes: If the type of the class defined in the line preceding the line containing the two operands is a first specified type, then the class of the second function is determined to be the current class corresponding to the intermediate code file; If the type of the class defined in the code line preceding the line containing the two operands is a second specified type, then the class of the second function is determined to be the parent class of the current class.

8. The method according to claim 4, characterized in that, The second function is a static function; the second function has a single operand count; determining the function name and class of the second function according to the language organization rules corresponding to the operand count under the function type of the second function in the intermediate code file includes: Determine that the function name of the second function is the constructor function; The class of the second function is determined based on the format of the operand name of the single operand.

9. The method according to claim 8, characterized in that, Determining the class of the second function based on the format of the operand name of the single operand includes: If the operand name of the single operand is in a specified format, the class of the second function is determined according to the type of the class defined in the code line preceding the code line where the single operand is located; If the format of the operand name of the single operand is not the specified format, the operand name of the single operand is determined to be the class of the second function.

10. The method according to claim 9, characterized in that, Determining the class of the second function based on the class type defined in the line preceding the line containing the single operand includes: If the class type defined in the line preceding the line containing the single operand is a first specified type, then the class of the second function is determined to be the current class corresponding to the intermediate code file; If the class defined in the line preceding the line containing the single operand is of the second specified type, then the class of the second function is determined to be the parent class of the current class.

11. The method according to claim 4, characterized in that, The second function is of type ordinary function; the second function has two operands; determining the function name and class of the second function according to the language organization rules corresponding to the number of operands under the function type of the second function in the intermediate code file includes: The function name and class of the second function are determined based on the operation type of the code line preceding the code line containing the two operands.

12. The method according to claim 11, characterized in that, The step of determining the function name and class of the second function based on the operation type of the code line preceding the code line containing the two operands includes: If the operation type of the code line preceding the line containing the two operands is a variable assignment operation, then the name of the second operand of the two operands is determined to be the function name of the second function; Using the variable name corresponding to the variable assignment operation, find the variable declaration operation line that declares the variable name in the intermediate code file; Based on the variable declaration line, locate the internal variable assignment line of the first function; By using the internal variable name corresponding to the internal variable assignment operation line, the initialization code line of the internal variable name is queried in the intermediate code file; The operand name of the initialization line is determined to be the class name of the second function.

13. The method according to claim 11, characterized in that, The step of determining the function name and class of the second function based on the operation type of the code line preceding the code line containing the two operands includes: If the operation type of the code line preceding the line containing the two operands is not a variable assignment operation, the name of the second operand of the two operands is determined to be the function name of the second function; Locate the line containing the internal variable assignment operation in the intermediate code file; Using the internal variable name corresponding to the internal variable assignment operation line, the first initialization operation that initializes the internal variable name is queried in the intermediate code file; Based on the query results of the first initialization operation, determine the class of the second function.

14. The method according to claim 13, characterized in that, The step of determining the class of the second function based on the query result of the first initialization operation includes: If the first initialization operation is found, the factory function that performs the initialization operation is called, and the class declared by the factory function is determined to be the class of the second function; If the first initialization operation is not found, the second initialization operation that initializes the internal variable name is found in the intermediate code file using the internal variable name, and the operand name of the second initialization operation is determined to be the class name of the second function.

15. The method according to claim 4, characterized in that, The second function is of type ordinary function; the second function has a single operand count; determining the function name and class of the second function according to the language organization rules corresponding to the operand count under the function type of the second function in the intermediate code file includes: The operand name of the single operand is determined to be the function name of the second function; The current class corresponding to the intermediate code file is determined to be the class of the second function.

16. The method according to claim 1, characterized in that, The step of parsing the configuration file to obtain the interface list of the first source code includes: Retrieve the virtual host settings module from the configuration file; Obtain the virtual machine host domain name from the virtual host settings module; The virtual host settings module is parsed to obtain the request path of the interface of the first source code; The virtual machine host domain name and the request path are concatenated to obtain the interfaces in the interface list of the first source code.

17. The method according to claim 16, characterized in that, The step of parsing the virtual host settings module to obtain the request path of the interface of the first source code includes: Retrieve the IF statement from the virtual host settings module; If the IF statement contains a target IF statement that includes the $request_uri variable, the request path of the interface is determined based on the path parameter recorded in the condition record of the target IF statement and the $request_uri variable. If there is no target IF statement containing the $request_uri variable in the IF statement, the root path in the virtual host settings module is obtained, and the file name under the root path is obtained from the virtual host settings module as the request path of the interface.

18. The method according to claim 17, characterized in that, Also includes: Obtain the mapping module from the configuration file; the mapping module records the correspondence between the path parameters and parameter values ​​of the request path of the interface; Determining the request path of the interface based on the path parameters recorded in the condition record of the target IF statement and the $request_uri variable includes: Based on the path parameters of the condition record of the target IF statement, the mapping module is queried to determine the parameter value corresponding to the path parameters of the condition record of the target IF statement; wherein, the parameter value corresponding to the path parameters of the condition record of the target IF statement is the next path parameter in the request path of the interface that is located in the path parameter of the condition record of the target IF statement. Using the parameter values ​​corresponding to the path parameters recorded in the condition record of the target IF statement, the mapping module is queried to determine the parameter value of the next path parameter; the parameter value of the next path parameter is the parameter value corresponding to the $request_uri variable; If a subfile exists under the $request_uri variable, the request path of the interface is obtained by concatenating the parameter value corresponding to the path parameter of the condition record of the target IF statement, the parameter value corresponding to the $request_uri variable, and the filename of the subfile. If no subfile exists under the $request_uri variable, the parameter value corresponding to the path parameter of the condition record of the target IF statement and the parameter value corresponding to the $request_uri variable are concatenated to obtain the request path of the interface.

19. The method according to claim 16, characterized in that, Also includes: Based on the request path of the interface in the first source code, determine the entry class corresponding to the interface in the interface list.

20. The method according to claim 19, characterized in that, The step of determining the entry function of the interface based on the methods contained in the entry class includes: If the entry class contains an entry run method, then the entry run method is determined to be the entry function; If the entry class does not contain an entry run method, the parent class of the entry class corresponding to the interface is determined to be the target entry class of the interface, and the run method in the target entry class is determined to be the entry function.

21. The method according to claim 19, characterized in that, The step of generating the function call chain of the interface based on the entry function and the function node list includes: Using the entry function as the initial traversal function, obtain the first function node from the function node list, with the currently traversed function as the calling function; if the first function node has a called function, use the called function in the first function node as the called function of the currently traversed function, and recursively add it to the assembled function call chain of the interface. The function call chain of the interface is obtained by taking the called function of the currently traversed function as the new calling function and returning to execute the operation of obtaining the first function node of the calling function until the first function node has no called function.

22. The method according to claim 21, characterized in that, The step of recursively adding the called function in the first function node as the called function of the currently traversed function to the assembled function call chain of the interface includes: The called function in the first function node is used to search the function node list; If a second function node is found in the function node list with the called function in the first function node as the calling function, the called function in the first function node is used as the called function of the currently traversed function and recursively added to the assembled function call chain of the interface.

23. The method according to claim 22, characterized in that, Also includes: If the second function node is not found in the function node list, the function called in the first function node is used to search for functions contained in the parent class of the currently traversed function; If the called function in the first function node is found in the functions contained in the parent class of the currently traversed function, the called function in the first function node is recursively added to the assembled function call chain of the interface as the called function of the currently traversed function; If the called function in the first function node is not found in the functions contained in the parent class of the currently traversed function, the called function in the first function node is taken as the called function of the currently traversed function, and recursively added to the assembled function call chain of the interface, and the loop ends.

24. A method for generating function call chains, characterized in that, include: Obtain the intermediate code files and configuration files of the target code; The intermediate code file is parsed to obtain a list of function nodes for the target code; The configuration file is parsed to obtain the interface list of the target code; Based on the interface list and the function node list, generate the function call chain of the interface in the interface list; The step of generating the function call chain of the interfaces in the interface list based on the interface list and the function node list includes: Based on the list of function nodes, determine the methods contained in the entry class corresponding to the interface in the interface list; Based on the methods contained in the entry class, determine the entry function of the interface; Based on the entry function and the list of function nodes, the function call chain of the interface is generated.

25. A test interface determination device, characterized in that, include: The acquisition module is used to acquire the configuration file and multiple intermediate code files of the first source code of the software under test after the update; A parsing module is used to parse the plurality of intermediate code files to obtain a list of function nodes of the first source code; In addition, the configuration file is parsed to obtain the interface list of the first source code; The generation module is used to generate the function call chain of the interfaces in the interface list based on the interface list and the function node list; The determination module is used to determine the changed function of the software under test based on the first source code and the second source code before the software under test is updated; and to determine the interface corresponding to the changed function as the test interface of the software under test from the interface list based on the function call chain corresponding to the interface in the interface list. The generation module, when generating the function call chain of the interfaces in the interface list based on the interface list and the function node list, is used to: Based on the list of function nodes, determine the methods contained in the entry class corresponding to the interface in the interface list; Based on the methods contained in the entry class, determine the entry function of the interface; Based on the entry function and the list of function nodes, the function call chain of the interface is generated.

26. A function call chain generation device, characterized in that, include: The acquisition module is used to acquire intermediate code files and configuration files of the target code; The parsing module is used to parse the intermediate code file to obtain a list of function nodes of the target code; In addition, the configuration file is parsed to obtain the interface list of the target code; The generation module is used to generate the function call chain of the interfaces in the interface list based on the interface list and the function node list; The generation module, when generating the function call chain of the interfaces in the interface list based on the interface list and the function node list, is used to: Based on the list of function nodes, determine the methods contained in the entry class corresponding to the interface in the interface list; Based on the methods contained in the entry class, determine the entry function of the interface; Based on the entry function and the list of function nodes, the function call chain of the interface is generated.

27. A computing device, characterized in that, include: A memory and a processor; wherein the memory is used to store computer programs; The processor is coupled to the memory for executing the computer program to perform the steps of the method according to any one of claims 1-24.

28. A computer-readable storage medium storing computer instructions, characterized in that, When the computer instructions are executed by one or more processors, the one or more processors are caused to perform the steps of the method according to any one of claims 1-24.

Images