Test analysis method, device, computer device and storage medium

Abstract

Embodiments of the present application provide a test analysis method and device, computer equipment and a storage medium, relating to the technical field of Internet. The method comprises: obtaining test source code corresponding to a program to be tested, and constructing an abstract syntax tree based on the test source code; analyzing the abstract syntax tree, obtaining an interface function list corresponding to the program to be tested, and configuring test case parameters for each interface function in the interface function list; analyzing the abstract syntax tree, determining at least one function breakpoint corresponding to each reference interface function in a reference interface function set, and configuring test operation parameters for each function breakpoint. The reference interface functions included in the reference interface function set are part or all of the interface functions in the interface function list. The test case parameters and the test operation parameters are used to test the program to be tested. Through the present application, test case parameters and test operation parameters can be configured, thereby improving test efficiency.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a test and analysis method, apparatus, computer equipment, and storage medium. Background Technology

[0002] With the continuous development of internet technology, various applications have emerged for computer devices. For these applications, program testing is a crucial part of software development.

[0003] Current technology for program testing often relies on unit testing of code using testing frameworks, or combines mock testing to shield external dependencies and supplement unit testing. Existing solutions primarily focus on writing test cases, generating mock test code, and mock operations. Users need to repeat these steps multiple times based on the problem's behavior to successfully complete a full program test. This testing method is cumbersome and inefficient. Summary of the Invention

[0004] This application provides a test analysis method, apparatus, computer equipment, and storage medium that can improve test efficiency.

[0005] One embodiment of this application provides a test analysis method, the method comprising:

[0006] Obtain the test source code corresponding to the program to be tested, and construct an abstract syntax tree based on the test source code;

[0007] The abstract syntax tree is analyzed to obtain the list of interface functions corresponding to the program to be tested, and test case parameters are configured for each interface function in the list of interface functions.

[0008] The abstract syntax tree is analyzed to determine at least one function breakpoint corresponding to each reference interface function in the reference interface function set, and test operation parameters are configured for each function breakpoint. The reference interface functions included in the reference interface function set are some or all of the interface functions in the interface function list.

[0009] The test case parameters and test operation parameters are used to test the program to be tested.

[0010] One embodiment of this application provides a test and analysis apparatus, the apparatus comprising:

[0011] The acquisition unit is used to acquire the test source code corresponding to the program to be tested.

[0012] Construction unit, used to construct an abstract syntax tree based on the test source code;

[0013] The analysis unit is used to analyze the abstract syntax tree and obtain the list of interface functions corresponding to the program to be tested;

[0014] The configuration unit is used to configure test case parameters for each interface function in the interface function list;

[0015] The analysis unit is used to analyze the abstract syntax tree and determine at least one function breakpoint corresponding to each reference interface function in the reference interface function set.

[0016] The configuration unit is also used to configure test operation parameters for each function breakpoint. The reference interface function set includes some or all of the interface functions in the interface function list. The test case parameters and test operation parameters are used to test the program to be tested.

[0017] One aspect of this application provides a computer device, including a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, the processor performs the methods described in the above embodiments.

[0018] One aspect of this application provides a computer storage medium storing a computer program, which includes program instructions. When the program instructions are executed by a processor, they perform the methods described in the above embodiments.

[0019] One aspect of this application provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. When the computer instructions are executed by the processor of a terminal device, the methods described in the above embodiments are performed.

[0020] The test analysis method of this application embodiment firstly involves a computer device acquiring the test source code corresponding to the program to be tested and constructing an abstract syntax tree (AST) based on the test source code. Then, the computer device analyzes the AST to obtain a list of interface functions corresponding to the program to be tested and configures test case parameters for each interface function in the list. Furthermore, the computer device analyzes the AST to determine at least one function breakpoint corresponding to each reference interface function in the reference interface function set and configures test operation parameters for each function breakpoint. The reference interface functions included in the reference interface function set are some or all of the interface functions in the interface function list. Finally, the computer device uses the test case parameters and test operation parameters to test the program to be tested. Since the method of this application aims to configure test case parameters and test operation parameters to test the program under test according to the test case parameters and test operation parameters, compared with writing test functions for each program under test, the method provided by this application allows users to focus on maintaining test cases (including test case parameters and test operation parameters). For different programs under test, only the test case parameters and test operation parameters need to be modified, which reduces the operation steps of testing and makes the operation required by users simpler, thus improving testing efficiency. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram of the structure of a program testing system provided in an embodiment of this application;

[0023] Figure 2a This is a schematic diagram of the interface of an integrated development environment provided in an embodiment of this application;

[0024] Figure 2b This is a schematic diagram of an interface for testing a program to be tested, provided in an embodiment of this application.

[0025] Figure 2c This is a schematic diagram of a first interactive interface provided in an embodiment of this application;

[0026] Figure 2d This is a schematic diagram of a second interactive interface provided in an embodiment of this application;

[0027] Figure 3 This is a flowchart illustrating a test and analysis method provided in an embodiment of this application;

[0028] Figure 4 This is a flowchart illustrating the configuration of test case parameters provided in an embodiment of this application;

[0029] Figure 5 This is a schematic diagram of a process for configuring test operation parameters provided in an embodiment of this application;

[0030] Figure 6 This is a schematic diagram of the structure of a test and analysis device provided in an embodiment of this application;

[0031] Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0032] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0033] It should be noted that, in this document, 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 limitations, 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 that element. Furthermore, components, features, and elements with the same names in different embodiments of this application may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

[0034] It should be understood that although the terms first, second, third, etc., may be used in this document to describe various types of information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this document, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein can be interpreted as "when," "when," or "in response to determination."

[0035] To better understand the embodiments of this application, the following is a description of the technical terms used in the embodiments of this application:

[0036] Unit testing is a common method in software testing, primarily used to verify the functional correctness of individual units / components of software. Specifically, unit testing refers to checking and verifying the smallest testable unit in software. The meaning of "unit" in unit testing generally depends on the specific context; for example, in C, a unit refers to a function, in Java, a class, and in graphical software, it could refer to a window or a menu. In general, a unit is the smallest functional module defined by the programmer and subject to testing. Unit testing is a crucial method for ensuring software quality. Different programming languages ​​have corresponding unit testing frameworks; for example, Go uses the built-in `gotest` for testing.

[0037] Mock Testing: Mock testing is an important auxiliary tool for unit testing. Specifically, during the testing process, mock testing involves creating a virtual object (mock object) to test complex objects that are difficult to construct (e.g., HttpServletRequest must be constructed within the Servlet container) or obtain (e.g., the ResultSet object in JDBC). Code often involves numerous interactions with external systems, such as RPC requests, access to MySQL, Redis, etc. When unit testing involves these dependencies in the test path, mock operations are used to facilitate verification of the code logic and simulation of various external problem scenarios. Simply put, mocking replaces the default operations in the code logic with carefully designed operations to simulate different problem scenarios. Go can use tools like mockgen and gomonkey to assist in mock testing.

[0038] R&D efficiency: R&D efficiency focuses not only on the user's R&D efficiency but also on the quality of R&D. In agile development models, users especially need to pay attention to the quality of unit tests. In the rapid iteration of internet products, balancing R&D efficiency and quality places extremely demanding requirements on users, necessitating more convenient and efficient tools to better address these two issues. In some embodiments, "user" refers to the developers.

[0039] TDD: Test-Driven Development.

[0040] DWARF: Debugging With Attributed Record Formats.

[0041] AST (Abstract Syntax Tree) is a tree-like representation of the abstract syntactic structure of source code. Each node in the tree represents a structure within the source code. It's considered abstract because it doesn't represent every detail of the actual syntax; for example, nested parentheses are implicitly present in the tree structure and not explicitly shown as nodes. The AST doesn't depend on the source language's syntax, meaning it doesn't rely on the context-agnostic grammar used in the parsing phase. This is because grammar writing often involves equivalent transformations (eliminating left recursion, backtracking, ambiguity, etc.), which introduces unnecessary components into parsing, negatively impacting subsequent stages and potentially causing confusion. Therefore, many compilers often construct their own parse trees to establish a clear interface between the front-end and back-end. Furthermore, ASTs have wide applications in many fields, such as browsers, intelligent editors, and compilers.

[0042] A stack frame, also called a procedure activation record, is a data structure used by the compiler to implement procedure / function calls. Essentially, it can be understood as a record unit storing information related to each function call on the user stack (and the kernel stack as well). Specifically, a stack frame represents a program's function call record, and since stack frames are recorded on the stack, it's clear that the stack holds N stack frame entities. Therefore, we can say that stack frames divide the stack into N record blocks. However, the size of these record blocks is not fixed because stack frames not only store information such as function input parameters, output parameters, return address, and the stack bottom pointer of the previous stack frame, but also store automatic variables inside the function (and can even dynamically allocated memory, which can be achieved using the `alloca` function, but not on some systems). Therefore, not all stack frames are the same size.

[0043] Based on the above analysis, the test analysis method provided in this application embodiment can be implemented using tools and can be applied to the following scenarios: For example, the test analysis method provided in this application embodiment can be implemented as a command-line tool or a plugin that integrates with the development environment, both of which are feasible. Subsequently, users only need to use this command-line tool or plugin to complete the testing of the program under test, reducing operation steps, simplifying operation, and improving the testing efficiency of the program under test.

[0044] Please see Figure 1 , Figure 1This is a schematic diagram of a program testing system provided in an embodiment of this application. The program testing system includes a server 140 and a cluster of terminal devices, wherein the cluster of terminal devices may include terminal devices 110, 120, ..., 130, etc. The cluster of terminal devices and the server 140 can be directly or indirectly connected via wired or wireless communication, which is not limited herein.

[0045] Figure 1 The server 140 shown can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0046] Figure 1 The terminal devices 110, 120, and 130 shown can be mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), vehicles, roadside devices, aircraft, wearable devices such as smartwatches, smart bracelets, and pedometers, and other hardware devices with various operating systems; they can also be software configured in the aforementioned hardware devices, such as applications. The operating system can include, but is not limited to, Android and iOS. Android is a free and open-source operating system based on Linux, while iOS is a proprietary mobile operating system developed by Apple for mobile devices.

[0047] in, Figure 1 The terminal devices 110, 120, and 130 shown are equipped with a test execution engine containing the program to be tested and test instructions. It is understood that the test execution engine is compatible with the operating system type of the terminal device. The program to be tested in different terminal devices can be the same or different.

[0048] In one possible implementation, terminal device 110 is used as an example for detailed explanation. Server 140 obtains the program to be tested corresponding to terminal device 110, obtains the test source code corresponding to the program to be tested, and constructs an abstract syntax tree based on the test source code. Server 140 analyzes the abstract syntax tree to obtain a list of interface functions corresponding to the program to be tested, and configures test case parameters for each interface function in the list. Server 140 analyzes the abstract syntax tree to determine at least one function breakpoint corresponding to each reference interface function in the reference interface function set, and configures test operation parameters for each function breakpoint. The reference interface function set includes some or all of the interface functions in the interface function list. The test case parameters and test operation parameters are used to test the program to be tested.

[0049] Furthermore, server 140 sends a test instruction to terminal device 110, wherein the test instruction includes test case parameters and test operation parameters, so that terminal device 110 can test the program under test according to the test case parameters and test operation parameters. Subsequently, terminal device 110 can send the test feedback information generated by testing the program under test according to the test case parameters and test operation parameters to server 140.

[0050] Of course, the operation steps involved in the test analysis method provided in this application embodiment can also be executed by the terminal device 110, or by any terminal device in the terminal device cluster. Specifically, the server 140 sends a test instruction to the terminal device 110, the test instruction including the program identifier of the program to be tested. The terminal device 110 obtains the program to be tested and the corresponding test source code based on the program identifier, and constructs an abstract syntax tree based on the test source code. Then, the terminal device 110 analyzes the abstract syntax tree, obtains the list of interface functions corresponding to the program to be tested, and configures test case parameters for each interface function in the list of interface functions. Then, the terminal device 110 analyzes the abstract syntax tree, determines at least one function breakpoint corresponding to each reference interface function in the reference interface function set, and configures test operation parameters for each function breakpoint. The reference interface functions included in the reference interface function set are some or all of the interface functions in the list of interface functions. Finally, the terminal device 110 tests the program to be tested according to the test case parameters and test operation parameters.

[0051] Furthermore, the test analysis method provided in this application can be provided as a plug-in in the integrated development environment of the terminal device 110. Users only need to click on the plug-in in the terminal device 110 to complete the test of the program to be tested.

[0052] Of course, the specific execution steps of the test analysis method provided in this application can also be integrated into the test execution engine in the terminal device, so that the test operation on the program to be tested can be performed directly through the test execution engine in the terminal device, without the need to introduce a server to perform test operations on the program to be tested in the terminal device.

[0053] It is understood that the system architecture diagrams described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0054] Please see Figure 2a , Figure 2a This is a schematic diagram of the interface of an integrated development environment (IDE) provided in an embodiment of this application. Specifically, the IDE runs on a terminal device, and a testing plugin is installed within the IDE. Figure 2a As shown, the terminal device displays the interface corresponding to the integrated development environment. This interface contains a test plugin, which can be used to perform test operations on the program to be tested.

[0055] In one possible implementation, the test plugin can be installed in the toolbar window of the integrated development environment, and the test plugin and other tools, such as Tool 1 (50), Tool 2 (60), Tool 3 (70), etc., are arranged in parallel. The test plugin includes a "Personal Center" control (10), an "Online Test" control (20), an "Offline Test" control (30), and an "Offline Information View" control (40). Users can click the "Personal Center" control, and after the user clicks the "Personal Center" control, the interface corresponding to the Personal Center can be displayed on the terminal device's interface. Specifically, the interface corresponding to the Personal Center can display the currently logged-in user and the user feedback issues that the currently logged-in user (tester) needs to be responsible for. The interface corresponding to the Personal Center can also display a project bar, in which the developer can select the corresponding product. In addition, the interface corresponding to the Personal Center can display the creation time, feedback ID, feedback content, feedback person, online operation, offline operation, log viewing, etc. For each feedback issue that needs to be processed, the developer can directly initiate online testing, offline testing, or offline information viewing. Among them, online operation corresponds to the "Online Test" control, which testers can trigger to initiate an online test; similarly, offline operation corresponds to the "Offline Test" control, which testers can trigger to initiate an offline test; similarly, log viewing corresponds to the "Log View" control, which testers can trigger to view the test feedback information after the program under test has been tested in the offline test scenario.

[0056] Please see Figure 2b , Figure 2b This is a schematic diagram of an interface for testing a program under test, provided in an embodiment of this application. For example... Figure 2b As shown, after a tester initiates an online test, they can... Figure 2a The interface shown will redirect to Figure 2b The online testing interface is shown. In the online testing interface, testers can set breakpoints for the program under test in the code window. These breakpoints include at least one function breakpoint. Specifically, testers can click the start button to begin the test and issue the test command. After the command is successfully executed, in... Figure 2b The left side of the online testing interface shows the breakpoint stack trace (e.g.) Figure 2b As shown in the stack display area, the right side of the online debugging interface displays information such as function variables corresponding to function breakpoints (e.g., ...). Figure 2b As shown in the results display area, when testers click on the stack on the left side of the online debugging interface, they can also perform simple code jumps for easy viewing, thus making it easier for testers to view the test feedback results of this test process.

[0057] Please see Figure 2c , Figure 2c This is a schematic diagram of a first interactive interface provided in an embodiment of this application. In one possible implementation, when the computer device analyzes the abstract syntax tree to obtain a list of interface functions corresponding to the program to be tested, and configures test case parameters for each interface function in the list, the first interactive interface can be displayed. The first interactive interface includes a list of interface functions, and request parameter configuration items and response parameter configuration items for each interface function in the list. Users can fill in data in the first interactive interface. Specifically, users can configure request parameters for one or more interface functions in the request parameter configuration items of the first interactive interface, and users can configure response parameters for one or more interface functions in the response parameter configuration items of the first interactive interface. Of course, the request parameters and response parameters can serve as test case parameters corresponding to the test cases. Figure 2c As shown, the first interactive interface includes a list of interface functions, such as Interface Function 1, Interface Function 2, Interface Function 3, Interface Function 4, etc., along with corresponding request parameter configuration items and response parameter configuration items for each interface function. Users can enter the required request parameters in the corresponding request parameter configuration items and the required response parameters in the corresponding response parameter configuration items. After configuring the request and response parameter configuration items for all interface functions in the list, users can click the "Test" button in the upper right corner of the first interactive interface to start testing the interface functions. Alternatively, users can start a test for each interface function after configuring its request and response parameters for each individual function.

[0058] Please see Figure 2d , Figure 2d This is a schematic diagram of a second interactive interface provided in an embodiment of this application. In one possible implementation, during the execution of a test program by a computer device, when the program reaches a function breakpoint, the second interactive interface is displayed. The second interactive interface includes function information corresponding to the breakpoint, input value configuration items, and return value configuration items. Users can fill in data in the second interactive interface. Specifically, users can configure function input parameter information for one or more reference interface functions in the input value configuration items of the second interactive interface, and configure function output parameter information for one or more reference interface functions in the return value configuration items of the second interactive interface. Furthermore, the function input parameter information and function output parameter information serve as test operation parameters. Figure 2dAs shown, the first interactive interface includes a target reference interface function, which refers to the interface function currently being tested in the interface function list. The target reference interface function may include function breakpoint 1, function breakpoint 2, function breakpoint 3, function breakpoint 4, etc., as well as input value configuration items and return value configuration items corresponding to each function breakpoint. Users can input the required function input parameter information in the corresponding input value configuration item and the required function output parameter information in the corresponding return value configuration item.

[0059] The test analysis method for the team program provided in this application allows for interactive input of mock data. Specifically, users can input test case parameters in a first interactive interface and test operation parameters in a second interactive interface. Subsequently, test case rewriting can be directly completed interactively, simplifying the testing process and improving efficiency.

[0060] Please see Figure 3 , Figure 3 This is a flowchart illustrating a test and analysis method provided in an embodiment of this application. The method is applied to computer equipment. Figure 3 As shown, the test analysis method may include steps S310 to S330. Wherein:

[0061] Step S310: Obtain the test source code corresponding to the program to be tested, and construct an abstract syntax tree based on the test source code.

[0062] In practice, in order to correctly identify all the functions that need to be mocked, it is necessary to have a sufficient understanding of the source code (test source code). Therefore, after the computer device obtains the test source code corresponding to the program to be tested, the computer device then parses the test source code and constructs an abstract syntax tree (AST).

[0063] In one possible implementation, after constructing an Abstract Syntax Tree (AST), the computer device identifies all RPC calls, database accesses, Redis accesses, and other function call statements, or any function matching user-defined rules, through the AST. The purpose of identifying these functions is to facilitate the addition of "function breakpoints" later, allowing interaction with the user at the breakpoint to obtain the input parameters and expected output parameters of the mocked function.

[0064] Specifically, in code testing, mock testing refers to mocking functions that involve external dependencies, such as accessing the network or database. Unit testing aims to be independent of the external environment; even without an actual database or network deployment, the code still needs to be tested. Therefore, it's necessary to mock (or replace) these functions that access the network and database. Identifying these functions can be done as follows: In companies with well-structured development frameworks, access to the network and database is typically made via RPC calls, such as `rsp, err := dbClientProxy.Select(ctx, req)`. These functions follow predictable patterns. "Source code understanding based on AST" primarily aims to identify these function calls in the code, preparing for subsequent mock testing.

[0065] Using the above methods, data mocking during testing has at least the following benefits: (1) It can be used to remove the test object's dependence on external services (such as databases, third-party interfaces, etc.), allowing test cases to run independently; (2) It replaces external service calls, improving the running speed of test cases. Any external service call is at least a cross-process level consumption, or even a cross-system or cross-network consumption, while mocking can reduce the consumption to within the process; (3) It improves testing efficiency. Specifically, testing efficiency has two meanings: the first meaning is the number of test cases run per unit time, which is a direct benefit brought about by the improvement in running speed; the second meaning is the number of test cases created by a tester per unit time.

[0066] In one possible implementation, during the user coding phase, it is desirable to test the service. The following description uses Go program service interface testing as an example. First, the computer compiles the program to be tested using the compilation toolchain. It is important to note that debugging information must be included during the compilation process. For example, when compiling a Go program, `gobuild-gcflags="all=-Nl"` is required to ensure that the build includes debugging information generated by the debugger and linker using Attributed Record Formats (DWARF). The absence of this information will result in the loss of debugging support.

[0067] The process of building an executable program from source code involves compilation and linking. During this process, some auxiliary information may be generated, such as the debugging information mentioned here. This debugging information is used to obtain the type information, name, definition location in the source code, etc., of a variable at a memory address. In addition to these, there is other debugging-related information, which are collectively referred to as debugging information.

[0068] Step S320: Analyze the abstract syntax tree to obtain the list of interface functions corresponding to the program to be tested, and configure the test case parameters for each interface function in the list of interface functions.

[0069] For example, a computer device performs AST analysis on the test source code, such as analyzing the entire project using the Go standard library's `parser.ParseDir()`, to determine the interface functions contained in the service. Furthermore, these interface functions always follow a pattern. Taking Google Remote Procedure Call (grpcgRPC) as an example, gRPC service registration is typically achieved by executing the statement `pb.RegisterService(server, serviceImpl)`, where `server` corresponds to a gRPC server. Therefore, `serviceImpl` is an implementation of a service interface, defined in the package `pb`. Through Go AST analysis, the computer device can traverse the abstract syntax tree to find the corresponding statement and further obtain the type information of the parameter `serviceImpl`, including its list of exported methods. The interface functions are contained in this list of exported methods. Further combining this with the service interface methods in package `pb`, functions that are not interfaces can be eliminated.

[0070] For example, development based on the gRPC framework typically includes the following parts: (1) Protocol: A protocol file is written using protobuf, which defines the service interface, request parameters, and response parameters; (2) Automatic code generation: Protoc and protoc-gen-go are used to convert the above protocol file into Go code, including the Service interface definition; (3) User-written service interface implementation code, i.e., serviceImpl. The AST analysis here only needs to analyze the exported methods of the service interface or serviceImpl, and these methods should have corresponding unit test functions.

[0071] Furthermore, for example, suppose we have the following protocol file (pb file):

[0072] Filename: hello.proto

[0073] Package hello;

[0074] Message req{}

[0075] Message rsp{}

[0076] Service hello_service{

[0077] Rpc Hello(req) returns(rsp);

[0078] }

[0079] Protoc–go_out=.Hello.proto

[0080] This will generate a Go file named hello.pb.go.

[0081] There will be an interface definition:

[0082] type HelloService interface{

[0083] Hello(ctx context.Context,req Req)(rsp,error)

[0084] }

[0085] When developers write code, they might implement a type like this:

[0086] Type helloServiceImpl struct{

[0087] }

[0088] func(s*helloServiceImpl)Hello(ctx context.Context,req*pb.Req,rsp*pb.Rsp)error{' ...

[0090] }

[0091] Based on the above pb file, the type was analyzed using AST, and the method func(s*helloServiceImpl)Hello(ctx,req,rsp)error was identified. For this example, this function is the one in the analyzed method list.

[0092] Step S330: Analyze the abstract syntax tree, determine at least one function breakpoint corresponding to each reference interface function in the reference interface function set, and configure test operation parameters for each function breakpoint. The reference interface functions included in the reference interface function set are some or all of the interface functions in the interface function list.

[0093] Specifically, the testing method integrates symbol-level debugging capabilities. For example, it requests the debugger to automatically add a breakpoint at the location of the function to be mocked via a JSON RPC interface exposed by the debugger, and obtains the pause event of the debugged process (the current test service). Then, it interacts with the user in some way, such as by popping up a web form, a native application interface, or a command line, to obtain the return value information of the mocked function. Finally, it requests and sets the return value information of the stack frame of the currently called function in the debugged process via the debugger's JSON RPC interface.

[0094] In one possible implementation, the specific process by which the computer device analyzes the abstract syntax tree and determines at least one function breakpoint corresponding to each reference interface function in the reference interface function set mainly includes: First, the computer device traverses the abstract syntax tree and analyzes it to determine the target reference interface function, wherein the target reference interface function refers to the interface function currently being tested in the interface function list.

[0095] Then, the computer device analyzes the target reference interface function to determine at least one target function statement corresponding to the target reference interface function and the source file location corresponding to each of the target function call statements.

[0096] Finally, based on the source file location corresponding to each target function call statement, the computer device requests the test service module to add function breakpoints in the reference interface function. One function breakpoint is added at each source file location. It should be noted that target function statements refer to all RPC call statements, database access statements, Redis access statements, or function call statements matching user-defined rules. The test service module refers to a module with debuggerserver capabilities.

[0097] For example, let's take accessing a database as an example. Suppose we have an account database, and we want to initialize a corresponding client to access this database. The code would look something like this:

[0098] 1 clientProxy,err:=mysql.NewClientProxy(ctx,"account","user","passwd")

[0099] 2 if err! = nil{

[0100] 3 panic(err)

[0101] 4}

[0102] 5 name,err:=clientProxy.Query(ctx,“select name from user where id=?”,id)

[0103] 6 if err! = nil{

[0104] 7 return err

[0105] 8}

[0106] The code above first initializes a client, and then queries the username with user ID `id` through the client. The statement involving network access is the function call `clientProxy.Query`. Given that the previous AST analysis determined that this function needs to be mocked, a breakpoint can be set at line 5 of the source code.

[0107] Once the program stops at this point, through user interface interaction and AST analysis, we can determine the input variables (such as id), output variables (name, err), and their types (the type indicates the data's storage format in memory). Users can input data; for example, inputting 10000 into the id field would output name = xiaoming and err = nil. Multiple test cases can even be allowed.

[0108] Id=10000,name=xiaoming,err=nil

[0109] Id=20000,name=xiaohong,err=nil

[0110] Id=-1,name="",err=not found

[0111] These test cases will be recorded and later used to set up mock tests.

[0112] Finally, the test case parameters and test operation parameters configured in steps S320 and S330 are used to perform test operations on the program under test.

[0113] In one possible implementation, the computer device analyzes the abstract syntax tree (AST), determines at least one function breakpoint corresponding to each reference interface function in the reference interface function set, and configures test operation parameters for each function breakpoint. This solution requires the automatic generation of test functions, mock test stubs, and mock function setup code after the user inputs test data. Here, setup code mainly refers to mock test settings, such as `gomonkey.ApplyFunc` and `gomonkey.ApplyMethod`. How to generate the code must be based on a thorough understanding of the test source code. Based on this understanding and AST-based code rewriting, it will be possible to modify the existing code. For example, if a test function uses table-driven testing, it can continue to append new test case data input by the user to the table and automatically add the corresponding mock setup code.

[0114] The test analysis method provided in this application allows users to complete all mock test preparation work along the corresponding code execution path in one go by supplementing a test case. This is done through an interactive interface, making it highly intuitive and convenient. It reduces the frequent interruptions to the development and testing process caused by "test failure -> supplementing mock -> test failure -> supplementing mock," allowing users to focus more on their current tasks. Furthermore, users have the genuine willingness and time to carefully maintain valuable test cases, effectively improving service quality rather than simply fulfilling requirements based on test coverage metrics. This not only improves code quality and eliminates code problems but also significantly increases efficiency compared to the past.

[0115] Please see Figure 4 , Figure 4 This is a flowchart illustrating a method for configuring test case parameters according to an embodiment of this application. The method is applied to computer devices. Figure 4 The example is as follows Figure 3 One specific embodiment of step S320 in the examples. For example... Figure 4 As shown, the test analysis method may include steps S410 to S430. Wherein:

[0116] Step S410: Display the first interactive interface, which includes the interface function list and the request parameter configuration items and response parameter configuration items for each interface function in the interface function list.

[0117] In specific implementations, the first interactive interface includes, but is not limited to, web forms, native application interfaces, or command lines. Combined with... Figure 3In this embodiment, the service interface list (exported method list) can be dynamically constructed into an interactive interface (first interactive interface). This interface contains a list of interface functions, as well as a list of request parameters and a list of response parameters for each function. Users can fill in the request parameters and expected response results on this first interactive interface. This data will later serve as the input and output of a test case. After the user inputs the request and response information (which is essentially test case data), clicking the button on the page requests testing the service interface functions. This will then trigger the following operations.

[0118] In one possible implementation, the first interactive interface also includes a test button (such as...). Figure 2c As shown, the computer device receives a trigger operation from the target user on the test button. In response to the trigger operation, the computer device generates a remote procedure call request and requests to send a debug command through the service port. The debug command instructs the test service module to add function breakpoints in each reference interface function. The test service module has debugger server capabilities. The computer device sends the remote procedure call request to the test service module, which requests to run the program under test. The remote procedure call request includes the interface function, and the corresponding request and response parameters for the interface function.

[0119] Step S420: Obtain user input data in the first interactive interface. The user input data includes: request parameters configured for one or more interface functions in the request parameter configuration item, and response parameters configured for one or more interface functions in the response parameter configuration item.

[0120] For specific implementation details, please refer to [link / reference]. Figure 2c The computer device allows users to input request and response parameters in the first interactive interface. Specifically, the first interactive interface includes a list of interface functions, such as Interface Function 1, Interface Function 2, Interface Function 3, Interface Function 4, etc., along with corresponding request and response parameter configuration items for each interface function. Users can input the required request parameters in the corresponding request parameter configuration item and the required response parameters in the corresponding response parameter configuration item. After configuring the request and response parameter configuration items for all interface functions in the interface function list, the user can click the "Test" button in the upper right corner of the first interactive interface to start testing the interface functions. Alternatively, users can start a test for each interface function after configuring its request and response parameters for each individual function.

[0121] In one possible implementation, before the computer device requests to send a debug command through the service port, the process further includes: first, starting and running the test service module in background process mode. Then, starting a debugger, which is used to track the program execution state corresponding to the program under test, to listen on the service port to receive the remote procedure call request, and to perform debugging processing on the program under test. Here, background process mode refers to headless mode.

[0122] For example, for a built program, assuming the program name is "__debug_bin", a debugger server will be started and run in headless mode. Headless mode means running in the background as a daemon, not as a foreground process interacting with the user; this is how the Go debugger DLV works. Using the popular Go debugger go-delve / delve, execute the command `dlv exec path-to / __debug_bin--headless--listen=127.0.0.1:8000`. This command specifically loads the program path-to / __debug_bin, starts a debug process, listens on address 127.0.0.1:8000, and accepts debug requests (such as requests to set breakpoints). The DLV debugger will then start __debug_bin and trace its execution status, while simultaneously listening on port 8000, allowing JSON RPC requests to be received for debugging operations on the tracee__debug_bin. Here, tracee refers to the process being debugged, more precisely, the thread being debugged.

[0123] Next, we will explain in detail the execution status of a program traced by the DLV debugger: Based on the process's execution status, the program's state can be further divided into several states, including ready, running, suspended, exited, etc., one of which is the traced state. The traced state indicates that the process being debugged (technically termed tracee) is being traced by the debugger (technically termed tracer). The debugged process (tracee) is suspended from execution by the kernel, and the tracer can modify the tracee's code and data using kernel system calls (such as Linux ptrace).

[0124] It should be noted that the purpose of referencing debugging tracing technology in this application is as follows: When writing unit tests for a function, the code execution path may involve multiple functions that need to be mocked. Manually confirming which functions need to be mocked is time-consuming and laborious. When the debugger executes the program, the machine automatically executes the instructions. The developer does not need to know in advance which functions need to be mocked along the code execution path. As mentioned earlier, AST technology can be used to analyze the source code locations of functions related to database access, network, etc., and breakpoints can be added based on the debugger. When the debugger reaches the breakpoint, it will naturally stop, and the user will know which function needs to be mocked. They only need to care about the mock data, saving time and effort, thus improving the efficiency of unit testing.

[0125] Step S430: Use the request parameters and the response parameters as the test case parameters.

[0126] In one possible implementation, the service interface method list (interface function list) has already been analyzed in the preceding steps, and now an interface function has been selected and the request and response parameters have been filled in. After clicking the test button, an RPC request will be dynamically constructed using reflection to request the service for processing. In computer science, reflection refers to the ability of a computer program to access, inspect, and modify its own state or behavior at runtime. Metaphorically speaking, reflection is the ability of a program to "observe" and modify its own behavior while running. However, before sending this request, a debug command is sent via a JSON RPC request to port 8000, requesting the debuggerserver (in this application, the test service module) to add a function breakpoint at the definition of the tracee service interface method to facilitate subsequent operations. At this point, the service being tested is in a paused execution state.

[0127] In one possible implementation, the program to be tested, the program before and after testing, and the parameter information (test case parameters, test operation parameters) filled in the first and second interactive interfaces provided in this application embodiment can all be stored in the blockchain. Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer.

[0128] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operational monitoring. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user real identities and blockchain addresses (access management). Furthermore, under authorization, it monitors and audits transactions of certain real identities and provides risk control rule configuration (risk control audit). The basic services module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic services first perform interface adaptation parsing and authentication (interface adaptation), and then encrypt the business information through a consensus algorithm (consensus management). After encryption, the data is transmitted completely and consistently to the shared ledger (network communication) and recorded and stored. The smart contract module is responsible for contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). According to the contract terms, the key or other events are invoked to trigger execution and complete the contract logic. It also provides functions for contract upgrades and cancellations. The operation monitoring module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time status visualization output during product release, such as alarms, monitoring network conditions, and monitoring the health status of node devices.

[0129] The platform's product service layer provides the basic capabilities and implementation frameworks for typical applications. Developers can leverage these basic capabilities, along with the specific characteristics of their business needs, to implement blockchain-based business logic. The application service layer provides blockchain-based application services to business stakeholders.

[0130] In this application, storing test case parameters and test operation parameters in a blockchain enhances data security and prevents data tampering. This further improves the efficiency of testing the program under test using test case parameters and test operation parameters.

[0131] It should be noted that the test analysis method provided by the embodiments of this application is an efficient test method. In actual implementation, it is necessary to develop software that uses the debugging capabilities mentioned above and AST analysis to identify which source code locations need to have function breakpoints added.

[0132] Please see Figure 5 , Figure 5 This is a flowchart illustrating the configuration of test operation parameters provided in an embodiment of this application. Wherein, Figure 5 The example is as follows Figure 3 One specific embodiment of step S330 in the examples. For example... Figure 5As shown, the test analysis method may include steps S510 to S530. Wherein:

[0133] Step S510: During the test run of the program to be tested, when the program reaches a function breakpoint, a second interactive interface is displayed. The second interactive interface includes the function information, input value configuration items, and return value configuration items corresponding to the breakpoint.

[0134] In practice, the source code is analyzed based on the Abstract Syntax Tree (AST). The system iterates through the source code to find the service interface function currently being tested, searches for its function body, and recursively filters out all RPC calls, database access statements, Redis access statements, and function calls matching user-defined rules. Based on the source file locations of these statements, the debugger server is requested to add breakpoints for all of them. Execution then resumes, and the program under test will stop at the first breakpoint on the execution path. Each breakpoint represents a function location expected to be mocked. Of course, when any function breakpoint is reached, a user interface (secondary interactive interface) needs to be displayed. This interface (secondary interactive interface) is as follows: Figure 2d As shown, this is a form used to display the input and output parameter types of functions, allowing users to input mock data.

[0135] The service interface function currently being tested refers to the process tracer used by the debug server (test service module) when it starts the debugger. This tracer uses the system call `exec` followed by a kernel `ptrace` request to `TRACEME`. The process code is not executing; it pauses and waits for the tracer operation. "Resuming execution" means allowing execution to proceed to the next function breakpoint, which is also the location of the function identified by AST analysis as needing to be mocked. Resuming execution allows the test program to pause at the next function that needs mocking, interacting with the user to obtain mock data. The purpose of this is to relieve developers of the burden of deciding "which functions I need to mock."

[0136] Step S520: Obtain simulation operation data in the second interactive interface. The simulation operation data includes: function input parameter information configured for one or more reference interface functions in the input value configuration item, and function output parameter information configured for one or more reference interface functions in the return value configuration item.

[0137] For specific implementation details, please refer to [link / reference]. Figure 2dThe computer device allows users to input function input and output parameters in the second interactive interface. Specifically, the first interactive interface includes a target reference interface function, which refers to the interface function currently being tested in the interface function list. The target reference interface function may include function breakpoints 1, 2, 3, 4, etc., as well as corresponding input and return value configuration items for each breakpoint. Users can input the required function input parameters in the corresponding input value configuration item and the required function output parameters in the corresponding return value configuration item.

[0138] In one possible implementation, the program under test continues execution and encounters the first breakpoint, which is a function expected to be mocked. After stopping, it queries the debugger server (test service module) to obtain the program's paused state change event. Specifically, due to the parent-child relationship between processes, a change in the child process's state notifies the parent process. The process being debugged (tracee, the child process) and the debugger process (tracer, the parent process) also have this relationship. After the tracee's state changes, it notifies the tracer, who then knows that it has reached a function that needs to be mocked and can display the corresponding input / output parameters (second interactive interface) to the user. The second interactive interface displays the function information, function parameter information, and return value information corresponding to that source file location. This information is also based on the AST's understanding of the code. It should be noted that for the function information, function parameter information, and return value information to be easily understood by humans, it needs to utilize the language structure in the AST. The AST is derived from source code analysis, not manually entered.

[0139] Similarly, on the second interactive interface, users fill in the function input and output parameter information. Specifically, they fill in the values ​​of the input and output parameters. Analyzing the AST yields the types, and users fill in the specific parameter values ​​based on each type.

[0140] In one possible implementation, after configuring test operation parameters for each function breakpoint, the computer device further includes: First, entering the function body of the target reference function through the test service module and obtaining the call stack frame information table corresponding to the target reference function through the stack frame description entries. Then, obtaining the return value address information corresponding to the target reference function based on the call stack frame information table. Finally, after the target reference function finishes execution, modifying the return value address information based on the simulated operation data.

[0141] For example, after obtaining the mock data input by the user, the debugger server will be requested to execute the `stepin` instruction to enter the function body. Then, through the call stack information table contained in the Frame Description Entry (FDE) of this stack frame, the return address information can be obtained. The return address can be directly set to the value of the RIP register, and then the `continue` command is executed. At this point, the program under test has exited the function. Next, the return value list information of the current function is obtained through AST analysis, and the return values ​​are assigned one by one according to the mock data input by the user.

[0142] For example, in each unit test, multiple functions may need to be mocked. Suppose there are two functions, f1 and f2, that need mocking. When a user mocks f1, they need to fill in the mock data for f1 (function input and output parameters), and then mock f2 based on this. For the code to execute correctly up to f2, the code execution between function calls to f1 and f2 must be as expected. If the return value of f1 is assigned to a variable, to ensure it meets expectations, the return value of f1 must be the mock return value data (function output parameters) that is correctly assigned to the variable. This is because subsequent logic might follow different branches based on this variable. Therefore, the debugger must perform special processing before and after the function execution. Each function has a stack frame, and FDE can accurately calculate its return address. After the function execution, the return value is modified using the mock data to ensure the correct assignment of the variable.

[0143] In summary, following this process, we repeat the steps: obtain the return value information of the mocked function through the second interactive interface, and then continue to request and set the return value information of the stack frame of the currently called function of the debugged process through the debugger's JSON RPC interface. This continues until the mock data of all functions in the current code execution path of the interface function has been set.

[0144] For example, let's take accessing a database as an example. Suppose we have an account database, and we want to initialize a corresponding client to access this database. The code would look something like this:

[0145] 1 clientProxy,err:=mysql.NewClientProxy(ctx,"account","user","passwd")

[0146] 2 if err! = nil{

[0147] 3 panic(err)

[0148] 4}

[0149] 5 name,err:=clientProxy.Query(ctx,“select name from user where id=?”,id)

[0150] 6 if err! = nil{

[0151] 7 return err

[0152] 8}

[0153] Based on the preceding analysis, after setting a breakpoint at line 5 of the source code, the program will display an interactive interface when it stops there. Using AST analysis, we can identify the input variables (such as `id`), output variables (`name`, `err`), and their types (the type indicates the data's storage format in memory). This allows the user to input data; for example, inputting `10000` in the `id` field would output `name = xiaoming` and `err = nil`. Multiple test cases can even be allowed.

[0154] Id=10000,name=xiaoming,err=nil

[0155] Id=20000,name=xiaohong,err=nil

[0156] Id=-1,name="",err=not found

[0157] These test cases will be recorded and later used to set up mock tests.

[0158] Step S530: Use the function input parameter information and the function output parameter information as the test operation parameters.

[0159] In practical implementation, this solution requires the automatic generation of test functions, mock test stubs, and mock function setup code after the user inputs test data. Specifically, all user-input data can be recorded. The initial interface request and response parameters will be used as test case data in a table-driven test. The request will serve as the input for the interface call, and the response as the output, which will be used for subsequent assertion validation. Data input from other mock functions will serve as the input and output of the mock test code.

[0160] For example, during the execution of a function under test, after collecting mock data (function input parameter information, function output parameter information) for the functions f1, f2, f3, etc., that need to be mocked, the mock data for each function will be recorded. Gomonkey configuration code can be generated based on this mock data. This relates to the previously mentioned example: `name,err := accountClientProxy.Query(ctx, "select name from account where id=?", id)`.

[0161] This can generate setup code like this:

[0162]

[0163] The ultimate goal is to generate this setup code. Furthermore, subsequent additions for cases where `param == 30000` or `40000` would require modifying the generated code's AST and rewriting it back into source code, all of which necessitate AST support. Therefore, by leveraging the AST's understanding of test code, new test functions or table-driven test cases are dynamically added to the AST structure. Finally, a complete rewrite of the AST to source code is achieved, enabling the generation of automated test code and automated mock test code setup.

[0164] In summary, since the test cases, test code, and mock test code have all been consolidated into test source files, users can run the test program as before to verify test coverage, test case pass rate, etc. When they find that the test coverage is low or some paths are not covered, they can repeat the previous steps at any time to complete the task.

[0165] Furthermore, all steps involved in the test analysis method provided in this application embodiment can be implemented using tools. For example, it can be implemented as a command-line tool or a test plugin that integrates with the development environment. This means that users can easily complete all the mock test preparation work required to add a test case by simply executing a command or clicking a test plugin button.

[0166] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a test and analysis device provided in an embodiment of this application. Figure 6 This is a schematic diagram of a test and analysis device provided in an embodiment of this application. This test and analysis device can be applied to... Figures 3-5The computer device in the corresponding method embodiment. The test analysis device can be a computer program (including program code) running on the computer device, for example, the test analysis device is an application software; the device can be used to execute the corresponding steps in the method provided in the embodiments of this application. The test analysis device may include:

[0167] Unit 610 is used to obtain the test source code corresponding to the program to be tested.

[0168] Construction unit 620 is used to construct an abstract syntax tree based on the test source code;

[0169] Analysis unit 630 is used to analyze the abstract syntax tree and obtain the list of interface functions corresponding to the program to be tested;

[0170] Configuration unit 640 is used to configure test case parameters for each interface function in the interface function list;

[0171] The analysis unit 630 is also used to analyze the abstract syntax tree and determine at least one function breakpoint corresponding to each reference interface function in the reference interface function set;

[0172] The configuration unit 640 is also used to configure test operation parameters for each function breakpoint. The reference interface functions included in the reference interface function set are some or all of the interface functions in the interface function list. The test case parameters and test operation parameters are used to test the program to be tested.

[0173] In one possible implementation, the configuration unit 640 configures test case parameters for each interface function in the interface function list, including:

[0174] The first interactive interface is displayed, which includes the list of interface functions, and the request parameter configuration items and response parameter configuration items for each interface function in the list of interface functions.

[0175] In the first interactive interface, user input data is obtained, which includes: request parameters configured for one or more interface functions in the request parameter configuration item, and response parameters configured for one or more interface functions in the response parameter configuration item.

[0176] The request parameters and the response parameters are used as the test case parameters.

[0177] In one possible implementation, the first interactive interface further includes a test button, and the test analysis device provided in this application embodiment further includes a processing unit 650.

[0178] Processing unit 650 is used to perform the following operations:

[0179] Receive the target user's trigger operation on the test button;

[0180] In response to the triggering operation, a remote procedure call request is generated, and a debugging command is requested to be sent through the service port. The debugging command is used to instruct the test service module to add function breakpoints in each reference interface function.

[0181] The remote procedure call request is sent to the test service module. The remote procedure call request is used to request the program to be tested to run. The remote procedure call request includes an interface function, as well as the request parameters and response parameters corresponding to the interface function.

[0182] In one possible implementation, the test analysis apparatus provided in this application embodiment further includes a startup unit 660.

[0183] The startup unit 660 is configured to perform the following operations before the processing unit 650 requests to send debug commands through the service port:

[0184] The test service module is started and run in background process mode;

[0185] The debugger is started. The started debugger is used to track the program execution status corresponding to the program under test, and is used to start listening on the service port to receive the remote procedure call request, and to perform debugging processing on the program under test.

[0186] In one possible implementation, the analysis unit 630 analyzes the abstract syntax tree to determine at least one function breakpoint corresponding to each reference interface function in the reference interface function set, including:

[0187] The abstract syntax tree is traversed and analyzed to determine the target reference interface function, which is the interface function currently being tested in the interface function list.

[0188] The target reference interface function is analyzed to determine at least one target function statement corresponding to the target reference interface function and the source file location corresponding to each target function call statement.

[0189] Based on the source file location corresponding to each target function call statement, the test service module is requested to add function breakpoints in the target reference interface function, wherein one function breakpoint is added at each source file location.

[0190] In one possible implementation, configuration unit 640 configures test operation parameters for each function breakpoint, including:

[0191] During the test run of the program to be tested, when the program reaches a function breakpoint, a second interactive interface is displayed. The second interactive interface includes function information, input value configuration items, and return value configuration items corresponding to the breakpoint.

[0192] In the second interactive interface, simulated operation data is obtained, which includes: function input parameter information configured for one or more reference interface functions in the input value configuration item, and function output parameter information configured for one or more reference interface functions in the return value configuration item.

[0193] The function input parameters and the function output parameters are used as the test operation parameters.

[0194] In one possible implementation, after the configuration unit 640 configures the test operation parameters for each function breakpoint, the processing unit 650 is further configured to perform the following operations:

[0195] The test service module enters the function body of the target reference function and obtains the call stack frame information table corresponding to the target reference function through the stack frame description entries;

[0196] According to the call stack frame information table, obtain the return value address information corresponding to the target reference function;

[0197] After the target reference function finishes running, the return value address information is modified based on the simulated operation data.

[0198] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The above... Figures 3-5 The computer device in the corresponding embodiment can be computer device 700, such as... Figure 7As shown, computer device 700 may include a user interface 702, a processor 704, an encoder 706, and a memory 708. A signal receiver 716 is used to receive or transmit data via a cellular interface 710, a Wi-Fi interface 712, ..., or an NFC interface 714. The encoder 706 encodes the received data into a data format that can be processed by a computer. The memory 708 stores a computer program, and the processor 704 is configured to perform the steps in any of the above method embodiments via the computer program. The memory 708 may include volatile memory (e.g., dynamic random access memory DRAM) and may also include non-volatile memory (e.g., one-time programmable read-only memory OTPROM). In some instances, the memory 708 may further include memory remotely located relative to the processor 1004, which can be connected to the computer device 700 via a network. The user interface 7002 may include a keyboard 718 and a display 720.

[0199] exist Figure 7 In the computer device 700 shown, the processor 704 can be used to call computer programs stored in the memory 708 to achieve:

[0200] Obtain the test source code corresponding to the program to be tested, and construct an abstract syntax tree based on the test source code;

[0201] The abstract syntax tree is analyzed to obtain the list of interface functions corresponding to the program to be tested, and test case parameters are configured for each interface function in the list of interface functions.

[0202] The abstract syntax tree is analyzed to determine at least one function breakpoint corresponding to each reference interface function in the reference interface function set, and test operation parameters are configured for each function breakpoint. The reference interface functions included in the reference interface function set are some or all of the interface functions in the interface function list.

[0203] The test case parameters and test operation parameters are used to test the program to be tested.

[0204] In one possible implementation, the processor 704 configures test case parameters for each interface function in the interface function list, including:

[0205] The first interactive interface is displayed, which includes the list of interface functions, and the request parameter configuration items and response parameter configuration items for each interface function in the list of interface functions.

[0206] In the first interactive interface, user input data is obtained, which includes: request parameters configured for one or more interface functions in the request parameter configuration item, and response parameters configured for one or more interface functions in the response parameter configuration item.

[0207] The request parameters and the response parameters are used as the test case parameters.

[0208] In one possible implementation, the first interactive interface further includes a test button, and the method processor 704 is further configured to perform the following operations:

[0209] Receive the target user's trigger operation on the test button;

[0210] In response to the triggering operation, a remote procedure call request is generated, and a debugging command is requested to be sent through the service port. The debugging command is used to instruct the test service module to add function breakpoints in each reference interface function.

[0211] The remote procedure call request is sent to the test service module. The remote procedure call request is used to request the program to be tested to run. The remote procedure call request includes an interface function, as well as the request parameters and response parameters corresponding to the interface function.

[0212] In one possible implementation, before the processor 704 request sends debug commands through the service port, it is also used to perform the following operations:

[0213] The test service module is started and run in background process mode;

[0214] The debugger is started. The started debugger is used to track the program execution status corresponding to the program under test, and is used to start listening on the service port to receive the remote procedure call request, and to perform debugging processing on the program under test.

[0215] In one possible implementation, the processor 704 analyzes the abstract syntax tree to determine at least one function breakpoint corresponding to each reference interface function in the reference interface function set, including:

[0216] The abstract syntax tree is traversed and analyzed to determine the target reference interface function, which is the interface function currently being tested in the interface function list.

[0217] The target reference interface function is analyzed to determine at least one target function statement corresponding to the target reference interface function and the source file location corresponding to each target function call statement.

[0218] Based on the source file location corresponding to each target function call statement, the test service module is requested to add function breakpoints in the target reference interface function, wherein one function breakpoint is added at each source file location.

[0219] In one possible implementation, the processor 704 configures test operation parameters for each function breakpoint, including:

[0220] During the test run of the program to be tested, when the program reaches a function breakpoint, a second interactive interface is displayed. The second interactive interface includes function information, input value configuration items, and return value configuration items corresponding to the breakpoint.

[0221] In the second interactive interface, simulated operation data is obtained, which includes: function input parameter information configured for one or more reference interface functions in the input value configuration item, and function output parameter information configured for one or more reference interface functions in the return value configuration item.

[0222] The function input parameters and the function output parameters are used as the test operation parameters.

[0223] In one possible implementation, after configuring test operation parameters for each function breakpoint, the processor 704 is also used to perform the following operations:

[0224] The test service module enters the function body of the target reference function and obtains the call stack frame information table corresponding to the target reference function through the stack frame description entries;

[0225] According to the call stack frame information table, obtain the return value address information corresponding to the target reference function;

[0226] After the target reference function finishes running, the return value address information is modified based on the simulated operation data.

[0227] It should be understood that the computer device 700 described in the embodiments of this application can perform the foregoing... Figures 3-5 The description of the test analysis method in the corresponding embodiments can also be performed as described above. Figure 6 The description of the test and analysis apparatus in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0228] In the several embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, and systems can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and other division methods may exist in actual implementation; for example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0229] Furthermore, it should be noted that this application embodiment also provides a computer storage medium, which stores a computer program executed by the aforementioned test and analysis device. This computer program includes program instructions, and when the processor executes these program instructions, it can execute the aforementioned... Figures 3-5 The methods described in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same methods will also not be repeated. For technical details not disclosed in the computer storage medium embodiments related to this application, please refer to the description of the method embodiments of this application. As an example, program instructions can be deployed on a computer device, or executed on multiple computer devices located in one location, or executed on multiple computer devices distributed across multiple locations and interconnected via a communication network. These multiple computer devices distributed across multiple locations and interconnected via a communication network can constitute a blockchain system.

[0230] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned... Figures 3-5 The methods described in the corresponding embodiments are therefore not repeated here.

[0231] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0232] The above-disclosed embodiments are merely some of the embodiments of this application, and should not be construed as limiting the scope of this application. Those skilled in the art can understand that implementing all or part of the above embodiments and making equivalent changes in accordance with the claims of this application still fall within the scope of the invention.

Claims

1. A test and analysis method, characterized in that, The method includes: Obtain the test source code corresponding to the program to be tested, and construct an abstract syntax tree based on the test source code; The abstract syntax tree is analyzed to obtain a list of interface functions corresponding to the program to be tested, and test case parameters are configured for each interface function in the list of interface functions; wherein, request parameters are configured for one or more interface functions in the request parameter configuration item in the first interactive interface, and response parameters are configured for one or more interface functions in the response parameter configuration item in the first interactive interface, and the request parameters and the response parameters serve as the corresponding test case parameters; The abstract syntax tree is traversed and analyzed to determine the target reference interface function, which is the interface function currently being tested in the interface function list. The target reference interface function is analyzed to determine at least one target function call statement corresponding to the target reference interface function and the source file location corresponding to each target function call statement. Based on the source file location corresponding to each target function call statement, request the test service module to add function breakpoints in the target reference interface function, where one function breakpoint is added at each source file location; Configure test operation parameters for each function breakpoint; when executing any function breakpoint, a second interactive interface is displayed, through which simulated operation data is entered to complete the configuration of test operation parameters. The test case parameters and test operation parameters are used to test the program to be tested.

2. The method as described in claim 1, characterized in that, The configuration of test case parameters for each interface function in the interface function list includes: The first interactive interface is displayed, which includes the list of interface functions, and the request parameter configuration items and response parameter configuration items for each interface function in the list of interface functions. In the first interactive interface, user input data is obtained, which includes: request parameters configured for one or more interface functions in the request parameter configuration item, and response parameters configured for one or more interface functions in the response parameter configuration item. The request parameters and the response parameters are used as the test case parameters.

3. The method as described in claim 2, characterized in that, The first interactive interface further includes a test button, and the method further includes: Receive the target user's trigger operation on the test button; In response to the triggering operation, a remote procedure call request is generated, and a debugging command is requested to be sent through the service port. The debugging command is used to instruct the test service module to add function breakpoints in each reference interface function. The remote procedure call request is sent to the test service module. The remote procedure call request is used to request the program to be tested to run. The remote procedure call request includes an interface function, as well as the request parameters and response parameters corresponding to the interface function.

4. The method as described in claim 3, characterized in that, Before the request sends the debug command through the service port, it also includes: The test service module is started and run in background process mode; The debugger is started. The started debugger is used to track the program execution status corresponding to the program under test, and is used to start listening on the service port to receive the remote procedure call request, and to perform debugging processing on the program under test.

5. The method as described in claim 1, characterized in that, The configuration of test operation parameters for each function breakpoint includes: During the test run of the program to be tested, when the program reaches a function breakpoint, a second interactive interface is displayed. The second interactive interface includes function information, input value configuration items, and return value configuration items corresponding to the breakpoint. In the second interactive interface, simulated operation data is obtained, which includes: function input parameter information configured for one or more reference interface functions in the input value configuration item, and function output parameter information configured for one or more reference interface functions in the return value configuration item. The function input parameters and the function output parameters are used as the test operation parameters.

6. The method as described in claim 1, characterized in that, After configuring test operation parameters for each function breakpoint, the process also includes: The test service module enters the function body of the target reference interface function and obtains the call stack frame information table corresponding to the target reference interface function through the stack frame description entries. According to the call stack frame information table, obtain the return value address information corresponding to the target reference interface function; After the target reference interface function finishes running, the return value address information is modified based on the simulated operation data.

7. A testing and analysis apparatus, characterized in that, The device includes: The acquisition unit is used to acquire the test source code corresponding to the program to be tested. Construction unit, used to construct an abstract syntax tree based on the test source code; The analysis unit is used to analyze the abstract syntax tree and obtain the list of interface functions corresponding to the program to be tested; The configuration unit is used to configure test case parameters for each interface function in the interface function list; wherein, request parameters are configured for one or more interface functions in the request parameter configuration item in the first interactive interface, and response parameters are configured for one or more interface functions in the response parameter configuration item in the first interactive interface, and the request parameters and response parameters serve as the corresponding test case parameters; The analysis unit is used to analyze the abstract syntax tree and determine at least one function breakpoint corresponding to each reference interface function in the reference interface function set. The configuration unit is also used to configure test operation parameters for each function breakpoint. When any function breakpoint is executed, a second interactive interface is displayed, and simulated operation data is entered through the second interactive interface to complete the configuration of test operation parameters. The reference interface function set includes some or all of the interface functions in the interface function list. The test case parameters and test operation parameters are used to test the program to be tested. Specifically, the analysis unit is used to traverse the abstract syntax tree and perform analysis to determine the target reference interface function, which refers to the interface function currently being tested in the interface function list. The target reference interface function is analyzed to determine at least one target function call statement corresponding to the target reference interface function and the source file location corresponding to each target function call statement. Based on the source file location corresponding to each target function call statement, request the test service module to add function breakpoints in the target reference interface function, where one function breakpoint is added at each source file location.

8. A computer device, characterized in that, It includes a memory and a processor, wherein the memory stores a set of program code, and the processor calls the program code stored in the memory to execute the method described in any one of 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1 to 6.

10. A computer program product comprising computer instructions, characterized in that, The computer instructions are stored in a computer-readable storage medium, and when executed by the processor of a terminal device, the computer instructions implement the method as described in any one of claims 1 to 6.

Images