Interface calling test method and system, computer equipment and readable storage medium

Abstract

The invention discloses an interface calling test method and system, computer equipment and a readable storage medium, and relates to the technical field of interface calling test. The method comprises: determining whether a target application satisfies a first preset condition; the target application is an application to which the tested interface belongs. And in response to the condition that the target application meets the first preset condition, determining whether the called method in the target application is interrupted or not. And in response to the situation that the called method in the target application is not interrupted, monitoring the calling condition of each sub-method in the execution process of the called method in the target application. And in response to any sub-method calling abnormity in the execution process of the called method in the target application, obtaining a local variable before executing the code line number causing the abnormity in the sub-method with the calling abnormity, and persistently storing the local variable in the abnormal sub-method before the abnormal code line number is executed in the server, so as to retain the test progress at the position where the abnormal code line number is located.

Description

Technical Field

[0001] The present invention relates to the technical field of interface call testing, and in particular to a method for testing interface call, a system for testing interface call, a computer device and a readable storage medium. Background Art

[0002] In daily testing work, it is often necessary to test interfaces. During the execution of a complex business interface, multiple sub-method calls or calls to other services usually occur. For example, Figure 1 As shown in the figure, during the execution of business interface A, sub-methods B and C will be called. During the execution of sub-method B, interface B of service B will be called. During the execution of sub-method C, interface C of service C will be called. Interfaces B and C will each call service D during their execution.

[0003] In complex business and microservice architecture application systems, sub-method calls or calls to other services during the execution of complex business interfaces are often more frequent than Figure 1 The example shown is much more complex, which makes the testing of complex business interfaces very difficult. Taking the above example again, when the tester is testing interface A, suppose an exception occurs in interface D2, which causes an exception in interface C, which in turn causes sub-method C to return an exception, and ultimately causes interface A to terminate due to the exception when calling sub-method C, resulting in the failure of interface A; after various efforts, the tester finally resolves the exception in interface D2 and re-initiates the test of interface A, but unfortunately, this time an exception occurs in interface D1, which causes an exception in interface B, which in turn causes interface A to terminate abnormally when calling sub-method B. As a result, the second test fails without even executing sub-method C.

[0004] In actual testing of complex business interfaces, the situation can be even worse than the above example. Due to the instability of the test environment (due to unstable services, easily tampered data, random version releases, and other factors), it is easy for Interface A to fail during execution (i.e., when calling other interfaces or services), preventing the test from completing according to the expected logic. The cause and location of the failure may vary with each re-run of the test. Furthermore, the test data must be re-prepared before each re-run, which is also a considerable amount of work. Summary of the Invention

[0005] The technical problem to be solved by the present invention is: in the current related technologies, the instability of the test environment will cause abnormalities in the execution process of complex interfaces (i.e., the process of calling other interfaces or services), and the test cannot be completed according to the expected logic.

[0006] In view of the above-mentioned deficiencies in the existing technology, the following solutions are provided:

[0007] In a first aspect, the present invention provides a test method for interface calls. The method includes: determining whether the target application meets a first preset condition. The target application is the application to which the interface under test belongs. In response to the target application meeting the first preset condition, determining whether the called method in the target application has been interrupted. In response to the method called in the target application not being interrupted, monitoring each sub-method call of the called method in the target application during the execution process. And, in response to any sub-method call exception during the execution of the method called in the target application, obtaining the local variables in the sub-method that calls the exception before the code line number that causes the exception, and persisting the local variables in the sub-method that calls the exception before the code line number that causes the exception to the server, so as to retain the test progress at the location of the code line number where the exception is located. Among them, the first preset condition includes any method in the target application being called, and the called method in the target application is one of the preset methods to be tested.

[0008] Optionally, determining whether the target application satisfies a first preset condition includes: in response to receiving a first request message for testing the interface under test, performing a mount listener on the target application to determine whether a method in the target application has been called, and adjusting the test state of the called method in the target application to a first state. The first request message is triggered by a user initiating a test of a method whose test state is an initial state or a third state. A method whose test state is an initial state is a newly added interface mapping method, and a method whose test state is a third state is a method that has completed at least one test.

[0009] Optionally, obtaining local variables before the line of code causing the exception is executed in the sub-method that calls the exception, including: creating a virtual machine instance connected to the current execution environment of the target application. Starting a new thread in the virtual machine instance. And, creating a new breakpoint event at the line of code where the exception occurs in the sub-method that calls the exception and sending the newly created breakpoint event to the event queue. The new thread includes: obtaining the event queue, cyclically reading events in the event queue, and in response to the read event being a breakpoint event, obtaining the thread frame to which the read event belongs, and obtaining all local variables before the line of code causing the exception is executed in the sub-method that calls the exception through the thread frame to which the read event belongs.

[0010] Optionally, determining whether the called method in the target application has been interrupted includes: in response to not reading a code line number from a variable of the new thread, determining that the called method in the target application has not been interrupted; and in response to reading a code line number from the thread variable, determining that the called method in the target application has been interrupted, and the code line number that caused the exception is the code line number read from the thread variable.

[0011] Optionally, the interface call test method further includes: in response to any sub-method call exception during the execution of the called method in the target application, obtaining and saving the method name of the sub-method calling the exception and the code line number in the sub-method calling the exception that caused the exception.

[0012] Optionally, the test method for interface call also includes: in response to receiving request information for a newly added interface under test, obtaining the application to which the newly added interface under test belongs, the class name to which the newly added interface under test belongs, and the method mapped by the newly added interface under test, and setting the test status of the method mapped by the newly added interface under test to the initial state.

[0013] Optionally, the test method of the interface call further includes: in response to a sub-method call exception occurring during the execution of the called method in the target application, adjusting the test state of the called method in the target application to a second state.

[0014] Optionally, the interface call testing method further includes determining whether the target application satisfies a first preset condition, including: in response to receiving a second request message for testing the interface under test, adjusting the test state of the called method in the target application from the second state to the first state, and triggering the re-invocation of the method in the target application via a reflection mechanism. The second request message is triggered by a user re-enabling testing of the method in the second test state.

[0015] Optionally, the interface call testing method further includes: in response to the called method in the target application being interrupted, obtaining the line number of the current code during the execution of the called method in the target application and the line number of the abnormal code in the target application. In response to the line number of the current code during the execution of the called method in the target application being less than the line number of the abnormal code in the target application, skipping the current code. And, in response to the line number of the current code during the execution of the called method in the target application being equal to the line number of the abnormal code in the target application, obtaining local variables saved when the called method in the target application was interrupted, reloading the local variables saved when the called method in the target application was interrupted, and executing the current code.

[0016] Optionally, the test method of the interface call further includes: in response to the test of the called method in the target application being completed, adjusting the test state of the called method in the target application to a third state.

[0017] In a second aspect, the present invention provides an interface call testing system comprising a first preset condition determination module, an interruption determination module, a call monitoring module, and a local variable acquisition module. The first preset condition determination module is configured to determine whether a target application satisfies a first preset condition. The target application is the application to which the interface under test belongs. The first preset condition includes any method being called in the target application, where the called method in the target application is one of the preset methods to be tested. The interruption determination module is configured to, in response to the target application satisfying the first preset condition, determine whether the called method in the target application has been interrupted. The call monitoring module is configured to, in response to the target application not being interrupted, monitor each sub-method call in the called method in the target application during execution. The local variable acquisition module is configured to, in response to any sub-method call exception in the target application during execution, obtain local variables in the sub-method that executed the exception before the line of code that caused the exception, and persistently save the local variables in the sub-method that executed the exception before the line of code that caused the exception to a server, thereby retaining the test progress at the line of code where the exception occurred.

[0018] In a third aspect, the present invention provides a computer device comprising a memory and a processor, wherein a computer program is stored in the memory. When the processor runs the computer program stored in the memory, the processor executes the above-mentioned test method for interface calling.

[0019] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the processor executes the test method for the above-mentioned interface call.

[0020] The interface call testing method, system, computer device and readable storage medium provided by the present invention can automatically retain the execution progress at the abnormal code line position when the interface under test executes abnormally due to an abnormal method call. After the tester resolves the exception (even after restarting the application), the interface test can be manually continued from the abnormal code line position without re-calling the interface or re-preparing test data, thereby improving the success rate and efficiency of the interface test. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 This is a diagram of a complex interface calling method;

[0022] Figure 2 This is a flow chart of a method for testing an interface call in an embodiment of the present invention;

[0023] Figure 3 This is a schematic diagram of a configuration information chart in an embodiment of the present invention;

[0024] Figure 4 This is a flowchart of another interface call testing method according to an embodiment of the present invention;

[0025] Figure 5 This is a schematic diagram of an abnormal information interface in an embodiment of the present invention;

[0026] Figure 6A This is a schematic diagram of a newly added interface in an embodiment of the present invention;

[0027] Figure 6B This is a schematic diagram of a test success information interface in an embodiment of the present invention;

[0028] Figure 7 This is a flowchart of another interface call testing method according to an embodiment of the present invention;

[0029] Figure 8 A structural diagram of a test system for interface calling in an embodiment of the present invention;

[0030] Figure 9 A structural diagram of another interface call test system in an embodiment of the present invention;

[0031] Figure 10 A structural diagram of another interface call test system according to an embodiment of the present invention;

[0032] Figure 11 A structural diagram of another interface call test system according to an embodiment of the present invention;

[0033] Figure 12 A structural diagram of another interface call test system according to an embodiment of the present invention;

[0034] Figure 13 This is a structural diagram of a computer device in an embodiment of the present invention. DETAILED DESCRIPTION

[0035] In order to enable those skilled in the art to better understand the technical solutions of the present invention, the embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

[0036] It should be understood that the specific embodiments and drawings described herein are only used to explain the present invention rather than to limit the present invention.

[0037] It is understood that, in the absence of conflict, the various embodiments of the present invention and the various features in the embodiments may be combined with each other.

[0038] It can be understood that, for the convenience of description, the drawings of the present invention only show parts related to the present invention, while parts unrelated to the present invention are not shown in the drawings.

[0039] It can be understood that each unit and module involved in the embodiments of the present invention may correspond to only one physical structure, or may be composed of multiple physical structures, or multiple units and modules may be integrated into one physical structure.

[0040] It will be understood that, without conflict, the functions and steps marked in the flowcharts and block diagrams of the present invention may occur in an order different from that marked in the drawings.

[0041] It is understood that the flowcharts and block diagrams of the present invention illustrate the possible architectures, functions, and operations of the systems, devices, equipment, and methods according to various embodiments of the present invention. Each box in the flowchart or block diagram may represent a unit, module, program segment, or code, which contains executable instructions for implementing the specified functions. Moreover, each box or combination of boxes in the block diagram and flowchart may be implemented using a hardware-based system that implements the specified functions, or may be implemented using a combination of hardware and computer instructions.

[0042] It is understandable that the units and modules involved in the embodiments of the present invention may be implemented by software or hardware. For example, the units and modules may be located in a processor.

[0043] The embodiment of the present invention provides a test method for interface calling, such as Figure 2 As shown, the method includes steps 201 to 204.

[0044] Step 201: Determine whether the target application meets a first preset condition.

[0045] In step 201, the target application is the application to which the interface under test belongs. The first preset condition includes that any method in the target application is called, and the called method in the target application is one of the preset methods to be tested.

[0046] It is understandable that the preset test method can be preset by the user, for example Figure 3 As shown, users can organize and save the relevant information of each interface to be tested (such as the application to which each interface to be tested belongs, the class name to which each interface to be tested belongs, the method mapped to each interface to be tested, and the test status of the method mapped to each interface to be tested). The preset methods to be tested include: Figure 3 The information in the "Method" column of the chart shown in the figure can be used to Figure 3 The diagram shown in FIG. 1 determines whether the called method in the target application is one of the preset methods to be tested.

[0047] Understandably, if Figure 3 As shown, users can set the test status of the methods mapped to each interface to be tested ( Figure 3 For example, if a user adds a new interface that needs to be tested, the test status of the method mapped to the newly added interface can be set to the initial state to indicate that the interface is new and has not been tested yet. The first state represents an interface that is being tested or is about to be tested. The second state indicates that the test has been completed and an exception has occurred. The third state indicates that the test is successful (regardless of whether any exceptions occurred during the test, if the test is successful, the test status is the third state).

[0048] For example, Figure 3 As shown, “not enabled” can be used to represent the initial state, “enabled” can be used to represent the first state, “interrupted” can be used to represent the second state, and “executed successfully” can be used to represent the third state.

[0049] In some embodiments, the implementation method of step 201 includes: in response to receiving a first request message for testing the interface under test, performing a mount listener on the target application to determine whether a method in the target application has been called, and adjusting the test state of the called method in the target application to a first state. The first request message is triggered by a user initiating a test of a method whose test state is an initial state or a third state. A method whose test state is an initial state is a newly added interface mapping method, and a method whose test state is a third state is a method that has completed at least one test.

[0050] It is understandable that operation buttons can be set on the interface to facilitate users to view and operate. Figure 3 As shown, buttons such as "Open", "Close", "Continue", "View", and "Delete" can be set. An "Open" button is set for an interface whose test status is the initial state or the third state. The user clicks "Open" to start the test of the interface. At this time, the interface is the interface under test, that is, the "Open" button can trigger the first request information for testing the interface under test. A "Delete" button is set for an interface whose test status is the initial state or the third state. The user clicks "Delete" to delete the interface. A "View" button is set for an interface whose test status is the third state. The user clicks the "View" button to view information such as whether the test process of the interface is abnormal. A "Close" button is set for an interface whose test status is the first state. The user clicks the "Close" button to stop the test process of the interface. A "Continue" button is set for an interface whose test status is the second state. The user clicks the "Continue" button to continue the test process of the interface.

[0051] For example, Figure 3 As shown, the first request information is triggered when the user clicks the "Open" button.

[0052] For example, the command to mount and monitor the target application is: . / sandbox.sh -p 3 -d 'method-monitor / open'. 3 represents the application process, obtained by executing the command ps -ef | grep -ikcard-xxx | awk '{print$2}' (for example, if the target application is kcard-xxx). Sandbox.sh is the mount and monitor execution script for JVM-sandbox, pre-installed on the server where the target application resides. JVM-sandbox is a JVM-based process monitoring tool that can monitor Java processes (i.e., application processes) within the JVM. Similar tools include trace and arthas. Therefore, if JVM-sandbox is not used, other monitoring tools can also be used to implement mount and monitor.

[0053] Step 202: In response to the target application satisfying a first preset condition, determine whether the called method in the target application has been interrupted.

[0054] Step 203: In response to the called method in the target application not being interrupted, monitor each sub-method call during the execution of the called method in the target application.

[0055] Step 204: In response to any sub-method call exception during the execution of the called method in the target application, obtain the local variables executed before the line of code causing the exception in the sub-method that called the exception, and persist the local variables executed before the line of code causing the exception in the sub-method that called the exception to the server, so as to retain the test progress at the location of the line of code where the exception occurs.

[0056] It is understandable that before the exception occurs, the local variables are normal. After the exception is interrupted, the user can intervene to adjust and restart the test process. The restarted test process can restore the local variables before the exception occurs, so as to restart the test from the line of code where the exception occurs. In this way, there is no need to re-prepare test data, and it can also avoid new interruptions caused by code exceptions before the line of code where the exception occurs, so that the interface under test can complete the test according to the expected logic.

[0057] In some embodiments, as Figure 4 As shown, the implementation method of step 204 includes steps 401 to 403.

[0058] Step 401: Create a virtual machine instance connected to the current execution environment of the target application.

[0059] For example, if the current application execution environment is a JVM environment, step 401 can be implemented by the code VirtualMachinevm=sac.attach(arguments), where sac is a connector object of the SocketAttachingConnector type, and arguments is a Map<T><String,Connector.Argument> The Map object of type contains the local connection address (127.0.0.1) and the connection port (5555). It can be understood that the created vm object can be used to subsequently obtain the status and data of the target application process when it is running in the jvm virtual machine. Here, it can connect to the target application, provided that the target application opens the debug port (5555) when it is started, that is, the runjdwp parameter is added when loading the jar package, such as java -Xrunjdwp:transport=dt_socket,suspend=n,server=y,address=55555-jar kcard-xxx.jar, which means that the debug port 5555 is opened when starting kcard-xxx.

[0060] Step 402: Start a new thread in the virtual machine instance.

[0061] In step 402, the new thread includes: obtaining an event queue, cyclically reading events in the event queue, and in response to the read event being a breakpoint event, obtaining a thread frame to which the read event belongs, and obtaining all local variables before the line of code that causes the exception in the sub-method that calls the exception through the thread frame to which the read event belongs.

[0062] For example, obtaining the event queue can refer to obtaining the event queue in the jvm, and the code is EventQueueeventQueue=vm.eventQueue(). The events in the event queue are read continuously in a loop. When an event is a breakpoint event (BreakpointEvent), the thread frame to which the read event belongs is obtained, and the code is StackFramestackFrame=breakpointEvent.thread().frame(0). Local variables can be obtained later through the thread frame. The list of local variables existing in the thread is obtained, that is, all local variables before the line number of the code that causes the exception is executed in the sub-method that calls the exception. The code is List <localvariable>localVariables = stackFrame.visibleVariables(). Create a txt file to save the variables later. The code is BufferedWriter writer = new BufferedWriter(new FileWriter("order\verify.txt", true)). Verify is the method name of the sub-method that currently returns an exception. It is obtained by the jvm-sandbox when it monitors the sub-method exception. Order is the name of the interface method under test. It is used as the directory name here to distinguish it from other interfaces under test. After obtaining the variable list, iterate over each variable in the list, executing the following logic for each iteration:

[0063] (1) If the variable is a reference type object, convert the object to a JSON string and then write the JSON string to a file. The code is objectMapper.writeValue(new File("order\com.kcard.pojo.Person.person.json"),person). Here, it is assumed that the object is person and its class is com.kcard.pojo.Person. Then the saved file is named com.kcard.pojo.Person.person.json.

[0064] (2) If the variable is a basic data type, then the variable is appended (not overwritten) to the file. The code is writer.write("Type:"+type+",Name:"+name+,"Value:"+value); where type is the type of the variable (such as integer type int), name is the variable name (such as age), and value is the value of the variable (such as 18).

[0065] Step 403: Create a new breakpoint event at the code line where the exception occurs in the sub-method that calls the exception, and send the new breakpoint event to the event queue.

[0066] It is understandable that the breakpoint event newly created in step 403 will be processed by the new thread in step 402.

[0067] Exemplarily, the implementation method of step 403 may include the following steps:

[0068] (1) Get the ClassType object of the class to which the current method belongs. The code is ClassType clazz = (ClassType)vm.classesByName("com.kcard.util.Verify").get(0). com.kcard.util.Verify is the class to which the submethod where the exception occurred belongs. It is obtained by the jvm-sandbox when it monitors the submethod exception.

[0069] (2) Get the Location object representing the current code line. The code is Location location = clazz.locationsOfLine(31).get(0). Where 31 is the current code (i.e., the exception code line), which is obtained by the jvm-sandbox when it monitors the sub-method exception.

[0070] (3) Get the event manager EventRequestManager object used to create the event. The code is EventRequestManager eventRequestManager=vm.eventRequestManager().

[0071] (4) Create a breakpoint event. The code is BreakpointRequest breakpointRequest = eventRequestManager.createBreakpointRequest (location).

[0072] (5) Send a breakpoint event to the event queue. The code is breakpointRequest.enable().

[0073] In this case, in some embodiments, step 202 may be implemented by: in response to not reading the code line number from the variable of the new thread, determining that the called method in the target application has not been interrupted; and in response to reading the code line number from the thread variable, determining that the called method in the target application has been interrupted, and that the code line number that caused the exception is the code line number read from the thread variable.

[0074] It can be understood that when the called method in the target application is interrupted, the code line number that caused the exception can be saved in the variable of the new thread. Therefore, if the code line number cannot be read from the variable of the new thread, it means that the called method has not been interrupted. If the code line number is read from the variable of the new thread, it means that the called method has been interrupted.

[0075] In some embodiments, the test method for interface calls also includes: in response to any sub-method call exception during the execution of the called method in the target application, obtaining and saving the method name of the sub-method that called the exception and the code line number that caused the exception in the sub-method that called the exception.

[0076] For example, when an exception occurs, the line number of the code causing the exception in the sub-method that calls the exception can be saved in a thread variable, so the code causing the exception in the sub-method that calls the exception can be obtained from the thread variable.

[0077] For example, the interrupt code line number (such as 31) can be saved to the thread variable threadLocal (the code is threadLocal.set(31)). Here, threadLocal is a global static variable of type ThreadLocal, which is used to save some data (such as 31 here) during the thread execution process. During the subsequent running of the thread, the saved data can be read at any time and can only be read by the program executed under the thread. It cannot be read by other threads (other threads read the thread variable data saved by other threads themselves).

[0078] For example, the method name of the sub-method that calls the exception and the line number of the code that causes the exception in the sub-method that calls the exception can also be saved in redis for users to view, such as Figure 5 shown.

[0079] In some embodiments, the test method for interface call also includes: in response to receiving request information for a newly added interface under test, obtaining the application to which the newly added interface under test belongs, the class name to which the newly added interface under test belongs, and the method mapped by the newly added interface under test, and setting the test status of the method mapped by the newly added interface under test to the initial state.

[0080] For example, Figure 6A As shown, the user clicks the "Add" button to trigger the request information of adding a new tested interface. After that, the user can fill in the application to which the newly added tested interface belongs, the class name to which the newly added tested interface belongs, and the method mapped by the newly added tested interface in the interface. After the user fills in the above information, the test status of the method mapped by the newly added tested interface can be set to the initial state and saved in the following file: Figure 3 shown in the chart.

[0081] In some embodiments, the test method for interface calling further includes: in response to a sub-method call exception occurring during the execution of the called method in the target application, adjusting the test state of the called method in the target application to a second state.

[0082] It can be understood that if a sub-method call exception occurs during the execution of the method called in the target application, the test can be interrupted. After debugging by a staff member, the test can be restarted. At this time, the test status of the method called in the target application is adjusted to the second status, so that the test status of the method called in the target application does not remain in the second status, that is, the target application cannot meet the first preset condition. In other words, the system can be prevented from automatically restarting the test of the target application where the sub-method call exception occurs.

[0083] In this case, in some embodiments, determining whether the target application meets the first preset condition in step 201 includes: in response to receiving a second request message for testing the interface under test, adjusting the test state of the called method in the target application from the second state to the first state, and triggering the re-calling of the method in the target application through a reflection mechanism. The second request message is triggered by the user re-enabling the test of the method in the second state.

[0084] For example, Figure 3 As shown, when a sub-method call exception occurs during the execution of the method called in the target application, the test status of the method called in the target application will be adjusted to the second status, which means that the method whose test status is the second status (i.e., "interrupted") is because the corresponding method has a method call exception during the execution. After manual debugging, the user can click the "Continue" button to reopen the test of the method whose test status is the second status, so that the second request information can be triggered after the user clicks the "Continue" button. In order to make the target application meet the first preset condition, the test status of the method called in the target application needs to be adjusted from the second status to the first status, and the re-call of the method in the target application needs to be re-triggered (for example, the re-call of the method in the target application needs to be triggered through the reflection mechanism), so that the test of the target application can be restarted according to steps 202 to 204.

[0085] Exemplarily, the reflection mechanism triggers the re-call of a method in a target application, which may include the following steps:

[0086] (1) Get the Class object of the target class. The code is Class<?>clazz=Class.forName("com.kcard.contorller.Order");

[0087] (2) Create an instance of the target class. The code is Object orderInstance = clazz.getDeclaredConstructor().newInstance();

[0088] (3) Get the Method object of the interface method under test. The code is Method orderMethod = clazz.getMethod("order", Person.class, Long.class);

[0089] (4) Determine whether the parameter variables need to be loaded, specifically:

[0090] (4-1) If the method under test in the configuration has parameters (such as order(com.kcard.pojo.Personperson,Long productId) has two parameters), execute (4-2);

[0091] (4-2) Read the value of the corresponding parameter variable from the variable file previously saved on the server and assign it to the parameter, specifically:

[0092] (4-2-1) If the parameter type is a reference type (such as com.kcard.pojo.Person person), read the value of the variable from the reference type variable file, such as reading the value of the variable in the com.kcard.pojo.Person.person.json file; after reading the value, convert the value to a reference type and assign it to the parameter variable, such as Person person = objectMapper.readValue(newFile("order\com.kcard.pojo.Person.person.json"), Person.class);

[0093] (4-2-2) If the type of the parameter is a basic data type (such as long productId), the value of the corresponding variable is read from the txt file, such as BufferedReader reader = new BufferedReader (new FileReader ("order\verify.txt")); where order is the name of the interface method to be tested, and verify is the name of the sub-method that has previously recorded an exception. During the reading process, the txt file is read line by line, and it is determined whether the variable name of the line is productId. If it is, the assignment operation is performed, such as long productId = Long.parseLong (reader.readLine().split (":") [2]); It should be noted here that when the local variables are saved before, the parameters of the interface method to be tested are also saved. In other words, the parameters of the interface method to be tested also belong to the local variables in the method, so the value of the parameter can be read here and reassigned.

[0094] (5) The method for executing the tested interface mapping is as follows: Object result = orderMethod.invoke(orderInstance, name, productId). Here is an additional explanation: the execution of the tested interface method triggered here will also be processed by the logic in the method-monitor / open monitoring logic package described above.

[0095] In this case, in some embodiments, such as Figure 7 As shown, the test method for interface calling further includes: step 701 to step 703.

[0096] Step 701: In response to a method being called in a target application being interrupted, obtain the line number of the current code during the execution of the method being called in the target application and the line number of the abnormal code in the target application.

[0097] Understandably, after restarting the test of the target application, the method called in the target test will be executed starting from line 0 of the code.

[0098] Step 702: In response to the line number of the current code being smaller than the line number of the abnormal code in the target application during the execution of the called method in the target application, skip the current code.

[0099] It can be understood that skipping the code with a line number smaller than the line number of the code that caused the exception, that is, not executing the code with a line number smaller than the line number of the code that caused the exception, can avoid the occurrence of exceptions in the code before the line number of the code that caused the exception when restarting the test, thereby avoiding repeated interruptions and repeated debugging.

[0100] Step 703: In response to the line number of the current code being equal to the line number of the abnormal code in the target application during the execution of the called method in the target application, obtain the local variables saved when the called method in the target application is interrupted, reload the local variables saved when the called method in the target application is interrupted, and execute the current code.

[0101] It can be understood that the local variables saved when the called method in the target application is interrupted are the local variables saved by the method in step 204. Before the exception occurs, the local variables are normal. After restarting the test process of the target application, by restoring the local variables before the exception occurs, the test can be restarted from the line of code where the exception occurs.

[0102] In some embodiments, the test method of the interface call further includes: in response to the completion of the test of the called method in the target application, adjusting the test state of the called method in the target application to a third state.

[0103] It can be understood that no matter whether the method called in the target application has a sub-method call exception, as long as the method called in the target application completes the test, for example, there is no interruption during the test of the method called in the target application, or there is an interruption during the test of the method called in the target application but no interruption occurs after restart, the test status of the method called in the target application can be adjusted to the third status (such as Figure 3 In the "Execution Successful" section, the user can view the result. In addition, if the user clicks Figure 3 Click the "View" button corresponding to the method whose test status is "Executed Successfully" and the interface can display the following Figure 6B The interface shown is convenient for users to understand detailed information.

[0104] The following is an illustrative example of an interface call testing method provided by an embodiment of the present invention.

[0105] The implementation steps for this example are as follows:

[0106] Step 1: Tester (ie user) Figure 6A Fill in the relevant information of the tested interface on the page shown, and click the Add button;

[0107] Step 2: After adding the tested interface, the interface will jump to Figure 3 The page shown, Figure 3 The page shown will display the configuration information of all tested interfaces. For newly added information, the status field (i.e., the test status field) is "Not Enabled" (i.e., the initial state). At this time, the tester can click the Enable button to enable it (triggering the first request information);

[0108] Step 3: After the test interface is enabled, the status field value of the tested interface configuration information changes to "enabled" (i.e., the first state), indicating that the tested interface has enabled the execution progress retention function. When the tested interface executes a sub-method exception, the execution progress of the tested interface is retained at the abnormal code line position;

[0109] Step 4. When the interface under test is interrupted due to an exception, the status field value changes to "interrupted" (i.e., the second state). At this time, the tester should first investigate and resolve the exception. After resolving the exception, you can click the Continue button (triggering the second request information) to trigger the interface under test to continue executing from the original abnormal position; the tester can also click the View button to view the relevant information of the current interruption position, such as Figure 5 As shown;

[0110] Step 5. After clicking the Continue button, the Status field value will change back to "On", indicating that the execution progress retention function is turned on again during the execution of the tested interface. When the tested interface is successfully executed (that is, no exceptions occur until the last line of code), the Status field value will change to "Execution Successful" (the third state). At this time, you can click the View button to view the interface return content, such as Figure 4 As shown;

[0111] Step 6. For the status field with the status of "Execution Successful", if the tester needs to initiate a second test, he can click the Start button again (triggering the first request information) to start the test of the tested interface again. After starting, the status will change to "Start".

[0112] The description and implementation principles of each of the above 6 steps are as follows:

[0113] For step 1:

[0114] Application: refers to the application to which the tested interface belongs, such as kcard-xxx;

[0115] Class name: refers to the class to which the interface under test belongs, such as com.kcard.contorller.Order;

[0116] Method: refers to the method mapped by the tested interface. When the tested interface is called, the interface method mapped by the interface is actually executed.

[0117] After clicking the Add button, the first request information will be triggered, and the added configuration information will be saved to Redis for subsequent use. The default value of the Status field is "Not Enabled".

[0118] For step 2:

[0119] When the interface jumps, the configuration information saved in redis can be returned to the page, and the page will display the configuration information saved in redis as a list, such as Figure 3 There are four states of configuration information:

[0120] Not enabled: This means that the execution progress retention function is not enabled. For newly added configuration information, it is disabled by default.

[0121] Enabled: means that the execution progress retention function has been enabled.

[0122] Interruption: refers to when the execution progress retention function is enabled and the interface under test is interrupted due to an abnormal execution;

[0123] Successful execution: This refers to the state where the execution progress retention function is enabled and no exceptions occur in the tested interface, indicating successful execution.

[0124] Clicking the start button will trigger the first request information, and then execute the remote command to mount the monitor on the target application (that is, the application to which the method under test belongs). The command is: . / sandbox.sh-p 3-d'method-monitor / open', where 3 is the application process, which is obtained by executing the command ps-ef|grep-i kcard-xxx|awk'{print$2}' (for example, the target application is kcard-xxx); sandbox.sh is the mount monitor execution script of the jvm-sandbox installed in advance on the server where the target application is located; jvm-sandbox is a jvm-based process monitoring tool that can monitor the java process (that is, the application process) in the jvm. Similar tools include trace, arthas, etc. Therefore, if you do not use jvm-sandbox, you can also use other monitoring tools to achieve the purpose of this example; method-monitor / open is the name of the monitoring logic implementation package provided in this example, and the implementation logic is as follows:

[0125] (E1) monitors each method of the target application. When a method is called, the logic of (E2) is executed before the method is executed.

[0126] (E2) Determine whether this method belongs to Figure 3 If a method in the list is found, the following logic (E3) is executed;

[0127] (E3) Determine whether the status of the configuration information of the method is "on". If so, try to read the value of the interrupt code line number from the thread variable threadLocal. If it cannot be read, it means that there has never been an interruption. This call is the first call of the interface method under test. Then execute the logic of (E4). If it can be read, it means that there has been an interruption. This call is triggered by the tester clicking the Continue button. Then execute (E8) first and then execute (E4).

[0128] (E4) monitors each sub-method call during the execution of the method. When a sub-method call returns an exception (i.e., an Exception is thrown), the logic from (E5) to (E7) is executed before the exception is returned to the caller.

[0129] (E5) All local variables generated up to the time the current line of code is executed are retrieved and persisted to the server. The specific implementation steps are:

[0130] (E5-1) Create a virtual machine instance connected to the current application execution environment (jvm environment). The code is VirtualMachine vm = sac.attach(arguments), where sac is a connector object of type SocketAttachingConnector and arguments is a Map<T><String,Connector.Argument> The Map object of type contains the local connection address (127.0.0.1) and the connection port (5555). Here is an explanation: the created vm object can be used to subsequently obtain the status and data of the target application process when it is running in the JVM virtual machine. Here, you can connect to the target application, provided that the target application opens the debug port (5555) when it is started, that is, the runjdwp parameter is added when the jar package is loaded. For example, java -Xrunjdwp:transport=dt_socket,suspend=n,server=y,address=55555-jarkcard-xxx.jar means that the debug port 5555 is opened when starting kcard-xxx.

[0131] (E5-2) Start a new thread (after the new thread is started, the code of the current thread will not be blocked, and the current thread will continue to execute, that is, it will continue to execute (E5-3)). Execute the following logic in the new thread:

[0132] (E5-2-1) Get the event queue in the JVM. The code is EventQueue eventQueue = vm.eventQueue();

[0133] (E5-2-2) Continuously read events from the event queue. When an event is a breakpoint event (BreakpointEvent), execute the logic of (E5-2-3). Otherwise, continue to read in a loop.

[0134] (E5-2-3) Get the thread frame of the thread to which the breakpoint event belongs. The code is StackFrame stackFrame = breakpointEvent.thread().frame(0); local variables can be obtained through the thread frame. After obtaining the thread frame, the logic of (E5-2-4) is executed.

[0135] (E5-2-4) Get the list of local variables in the thread. The code is List <localvariable>localVariables = stackFrame.visibleVariables(); Create a file for saving variables later using the code BufferedWriter writer = new BufferedWriter(new FileWriter("order\verify.txt", true)); where verify is the method name of the submethod that currently returns an exception, obtained by the jvm-sandbox when it detects a submethod exception; order is the name of the interface method under test, and is used as the directory name here to distinguish it from other interfaces under test; After obtaining the variable list, iterate over each variable in the list, executing the following logic for each iteration:

[0136] (E5-2-4-1) If the variable is a reference object, convert the object to a JSON string and then write the JSON string to a file. The code is objectMapper.writeValue(newFile("order\com.kcard.pojo.Person.person.json"), person); assuming the object is person and its class is com.kcard.pojo.Person, the saved file is named com.kcard.pojo.Person.person.json.

[0137] (E5-2-4-2) If the variable is a basic data type, append (note that it is appending, not overwriting) the variable to the file. The code is writer.write("Type:"+type+",Name:"+name+,"Value:"+value); where type is the variable type (such as integer type int), name is the variable name (such as age), and value is the variable value (such as 18).

[0138] (E5-3) Create a breakpoint event at the line of code where the exception currently occurs (the breakpoint event created here will be processed by the loop in the new thread above). Specifically:

[0139] (E5-3-1) Get the ClassType object of the class to which the current method belongs. The code is ClassType clazz = (ClassType)vm.classesByName("com.kcard.util.Verify").get(0); where com.kcard.util.Verify is the class to which the submethod where the exception occurred belongs, and is obtained by the jvm-sandbox when it detects the submethod exception.

[0140] (E5-3-2) Get the Location object representing the current code line. The code is Location location = clazz.locationsOfLine(31).get(0); where 31 is the current code line, which is obtained by the jvm-sandbox when it monitors the sub-method exception;

[0141] (E5-3-3) Get the event manager EventRequestManager object used to create the event. The code is EventRequestManager eventRequestManager = vm.eventRequestManager();

[0142] (E5-3-4) Create a breakpoint event. The code is BreakpointRequest breakpointRequest = eventRequestManager.createBreakpointRequest(location);

[0143] (E5-3-5) Send breakpoint event, the code is breakpointRequest.enable();

[0144] (E6) Save the method name, class, and line number of the interrupt code (the line number in the tested interface) of the sub-method that currently returns an exception to redis for later use. Figure 5 Read the display when the page is viewed;

[0145] (E7) Change the Status field value in the configuration information to "Interrupted." To explain this, if a sub-method returns an exception, the method under test will fail due to the exception, and the line of code where the failure occurred is the line of code that called the sub-method. When the execution is subsequently triggered to continue, execution will resume from this line of code.

[0146] (E8) monitors each line of code during the execution of this method, and executes the logic of (E9) before each line of code is executed;

[0147] (E9) Compare the current code line number with the previously saved code line number where the exception occurred during the interruption. If the current code line number is less than the previously saved code line number where the exception occurred during the interruption, skip the current line of code (do not execute the current line of code); if the current code line number is equal to the previously saved code line number where the exception occurred during the interruption, execute the logic from (E10) to (E11);

[0148] (E10) Reload the local variables saved during the previous interruption into the JVM. Specifically:

[0149] (E10-1) Load all JSON files into objects, for example, Person person = objectMapper.readValue(newFile("order\com.kcard.pojo.Person.person.json"), Person.class), which means reloading the person object saved in the com.kcard.pojo.Person.person.json file into the JVM;

[0150] (E10-2) Read the variables saved in the txt file and reload them into the JVM, for example, BufferedReaderreader = new BufferedReader(new FileReader("order\verify.txt")); int age = Integer.parseInt(reader.readLine().split(":")[2]); means redefining and assigning a value to the age variable;

[0151] (E11) Execute this line of code normally. Note that this line of code must be the line of code in the sub-method where the exception occurred before the call. After this line of code is executed normally, since the subsequent line numbers are all greater than the line number of the code where the exception occurred during the interruption, the subsequent lines of code will be executed normally (and will not be hit by the judgment of (E9)).

[0152] Step 2. After the monitor is successfully mounted, change the status field value in the configuration information to "Enabled".

[0153] The principle of step 3 is detailed in step 1 and will not be repeated here.

[0154] For step 4:

[0155] After clicking the "Continue" button, the second request information will be triggered and the following logic will be executed:

[0156] 1. Change the status field value in the configuration information to "on";

[0157] 2. Execute a remote command on the target application (e.g., kcard-xxx) server to trigger the re-execution of the interface method under test. The command is . / sandbox.sh -p 3 -d 'method-monitor / excute? class=com.kcard.controller.Order&method=order(com.kcard.pojo.Person person,Long productId)', where 3 is the process ID of the target application, method=order(com.kcard.pojo.Personperson,Long productId) indicates that the interface method under test is order(com.kcard.pojo.Person person,Long productId), and class=com.kcard.controller.Order indicates that the class to which the interface method under test belongs is com.kcard.controller.Order; both method and class are taken from the configuration line where the Continue button is clicked; method-monitor / excute is the logic processing package provided by the present invention for triggering the re-execution of the interface method under test, and its implementation logic is as follows:

[0158] (F1) Save the interrupt code line number (such as 31) to the thread variable threadLocal (the code is threadLocal.set(31)). Here, threadLocal is a global static variable of type ThreadLocal, which is used to store some data (such as 31 here) during the thread execution process. The saved data can be read at any time during the subsequent execution of the thread, and can only be read by the program executed under the thread, and cannot be read by other threads (other threads read the thread variable data saved by themselves);

[0159] (F2) Execute the interface method under test through reflection. Specifically:

[0160] (F2-1) Get the Class object of the target class. The code is Class<?>clazz=Class.forName("com.kcard.contorller.Order");

[0161] (F2-2) Create an instance of the target class. The code is Object orderInstance = clazz.getDeclaredConstructor().newInstance();

[0162] (F2-3) Get the Method object of the interface method under test. The code is Method orderMethod = clazz.getMethod("order", Person.class, Long.class);

[0163] (F2-4) Determine whether the parameter variables need to be loaded, specifically:

[0164] (F2-4-1) If the method under test in the configuration has parameters (such as order(com.kcard.pojo.Personperson,Long productId) has two parameters), execute (F2-4-2);

[0165] (F2-4-2) Read the value of the corresponding parameter variable from the variable file previously saved on the server and assign it to the parameter. Specifically:

[0166] (F2-4-2-1) If the parameter type is a reference type (such as com.kcard.pojo.Person person), read the value of the variable from the reference type variable file, such as reading the value of the variable in the com.kcard.pojo.Person.person.json file; after reading the value, convert it to a reference type and assign it to the parameter variable, such as Person person = objectMapper.readValue(newFile("order\com.kcard.pojo.Person.person.json"), Person.class);

[0167] (F2-4-2-2) If the type of the parameter is a basic data type (such as long productId), the value of the corresponding variable is read from the txt file, such as BufferedReader reader = new BufferedReader (newFileReader ("order\verify.txt")); where order is the name of the interface method to be tested, and verify is the name of the sub-method that has previously recorded an exception. During the reading process, the txt file is read line by line, and it is determined whether the variable name of the line is productId. If it is, the assignment operation is performed, such as long productId = Long.parseLong (reader.readLine().split (":") [2]); It should be noted here that when the local variables are saved before, the parameters of the interface method to be tested are also saved. In other words, the parameters of the interface method to be tested also belong to the local variables in the method. Therefore, the value of the parameter can be read here and reassigned.

[0168] (F2-5) Execute the method. The code is Object result = orderMethod.invoke(orderInstance, name, productId). Note: The execution of the tested interface method triggered here will also be processed by the logic in the method-monitor / open monitoring logic package described above.

[0169] (F3) If no abnormal interruption occurs again in the previous step, the result value will be obtained, which represents the return value after the tested interface method is successfully executed. At this time, the result value will be saved in redis for subsequent viewing (such as Figure 6B shown);

[0170] (F4) Change the value of the Status field in the configuration information to "Executed successfully".

[0171] The principles of steps 5 and 6 are detailed in steps 1 and 4 and will not be repeated here.

[0172] The embodiment of the present invention provides a test system for interface calling, such as Figure 8 As shown, the interface call test system 800 includes a first preset condition determination module 801 , an interruption determination module 802 , a call monitoring module 803 and a local variable acquisition module 804 .

[0173] The first preset condition determination module 801 is configured to determine whether a target application satisfies a first preset condition. The target application is the application to which the interface under test belongs. The first preset condition includes a method being called in the target application, where the called method in the target application is one of the preset methods to be tested.

[0174] In some embodiments, the first preset condition determination module 801 is configured to: in response to receiving a first request message for testing the interface under test, perform a mount listener on the target application to determine whether a method in the target application has been called, and adjust the test state of the called method in the target application to the first state. The first request message is triggered by a user starting a test of a method whose test state is the initial state or the third state. A method whose test state is the initial state is a newly added interface mapping method, and a method whose test state is the third state is a method that has completed at least one test.

[0175] The interruption determination module 802 is configured to: in response to the target application satisfying a first preset condition, determine whether a called method in the target application has been interrupted.

[0176] The call monitoring module 803 is configured to: in response to the method being called in the target application not being interrupted, monitor each sub-method call during the execution of the method being called in the target application.

[0177] The local variable acquisition module 804 is configured to: in response to any sub-method call exception during the execution of the called method in the target application, obtain the local variables executed before the code line number that caused the exception in the sub-method that called the exception, and persist the local variables executed before the code line number that caused the exception in the sub-method that called the exception to the server, so as to keep the test progress at the location of the code line number where the exception occurred.

[0178] In some embodiments, as Figure 9 As shown, the local variable acquisition module 804 includes: a virtual machine instance creation unit 901, a new thread startup unit 902 and a breakpoint event creation unit 903.

[0179] The virtual machine instance creation unit 901 is configured to create a virtual machine instance connected to the current execution environment of the target application.

[0180] The new thread starting unit 902 is configured to start a new thread in the virtual machine instance. The new thread includes: obtaining an event queue, cyclically reading events in the event queue, and in response to the read event being a breakpoint event, obtaining a thread frame to which the read event belongs, and obtaining all local variables in the sub-method that calls the exception before the line of code that causes the exception is executed through the thread frame to which the read event belongs.

[0181] The breakpoint event creating unit 903 is configured to create a breakpoint event at the code line location where the exception occurs in the sub-method that calls the exception and send the newly created breakpoint event to the event queue.

[0182] In some embodiments, the interruption determination module 802 is configured to: in response to not reading a line number from the variable of the new thread, determine that the called method in the target application has not been interrupted; and in response to reading a line number from the thread variable, determine that the called method in the target application has been interrupted, and the line number of the code that caused the exception is the line number read from the thread variable.

[0183] In some embodiments, the local variable acquisition module 804 is further configured to: in response to any sub-method call exception during the execution of the method called in the target application, obtain and save the method name of the sub-method that called the exception and the code line number that caused the exception in the sub-method that called the exception.

[0184] In some embodiments, as Figure 10 As shown, the interface call test system 800 further includes an interface adding module 805. The interface adding module 805 is configured to: in response to receiving a request for adding a new interface to be tested, obtain the application to which the new interface to be tested belongs, the class name to which the new interface to be tested belongs, and the method mapped to the new interface to be tested, and set the test state of the method mapped to the new interface to be tested to an initial state.

[0185] In some embodiments, as Figure 11 As shown, the interface call test system 800 further includes a test state adjustment module 806. The test state adjustment module 806 is configured to adjust the test state of the called method in the target application to the second state in response to a sub-method call exception occurring during execution of the called method in the target application.

[0186] In some embodiments, when the interface call testing system 800 includes a test state adjustment module 806, the first preset condition determination module 801 is configured to, in response to receiving a second request message for testing the interface under test, adjust the test state of the called method in the target application from the second state to the first state, and trigger the re-call of the method in the target application through a reflection mechanism. The second request message is triggered by a user re-starting the test of the method in the second state.

[0187] In some embodiments, as Figure 12 As shown, the interface call test system 800 further includes a current line number acquisition module 807 , a current code skipping module 808 and a current code executing module 809 .

[0188] The current code line number acquisition module 807 is configured to: in response to a called method in the target application being interrupted, acquire the line number of the current code during the execution of the called method in the target application and the line number of the abnormal code in the target application.

[0189] The current code skipping module 808 is configured to skip the current code in response to the line number of the current code being less than the line number of the abnormal code in the target application during the execution of the called method in the target application.

[0190] The current code execution module 809 is configured to: in response to the line number of the current code being equal to the line number of the abnormal code in the target application during the execution of the called method in the target application, obtain the local variables saved when the called method in the target application is interrupted, reload the local variables saved when the called method in the target application is interrupted, and execute the current code.

[0191] In some embodiments, the test status adjustment module 806 is further configured to: in response to the test of the called method in the target application being completed, adjust the test status of the called method in the target application to a third status.

[0192] The specific scheme and beneficial effects of the interface call testing system provided by the embodiment of the present invention can refer to the relevant description of the interface call testing method provided by the embodiment of the present invention, and will not be repeated here.

[0193] Some embodiments of the present invention provide a computer device, such as Figure 13 As shown, the computer device 1300 includes a memory 1301 and a processor 1302. The memory 1301 stores a computer program. When the processor 1302 runs the computer program stored in the memory 1301, the processor 1302 executes the above-mentioned network performance optimization method.

[0194] The specific solutions and beneficial effects of a computer device provided by some embodiments of the present invention can be referred to the relevant description of a network performance optimization cloud platform provided by some embodiments of the present invention, which will not be repeated here.

[0195] Some embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the processor executes the above-mentioned network performance optimization method.

[0196] The specific solutions and beneficial effects of a computer-readable storage medium provided by some embodiments of the present invention can be referred to the relevant description of a network performance optimization cloud platform provided by some embodiments of the present invention, which will not be repeated here.

[0197] It will be understood that the above embodiments are merely exemplary embodiments for illustrating the principles of the present invention, and the present invention is not limited thereto. Those skilled in the art will appreciate that various modifications and improvements can be made without departing from the spirit and substance of the present invention, and such modifications and improvements are also considered to be within the scope of protection of the present invention.< / localvariable> < / localvariable>

Claims

1. A test method for interface call, characterized in that: include: Determining whether the target application meets a first preset condition; The target application is the application to which the interface under test belongs; The first preset condition includes that any method in the target application is called, and the called method in the target application is one of the preset methods to be tested; In response to the target application satisfying a first preset condition, determining whether a called method in the target application has been interrupted; In response to the method called in the target application not being interrupted, monitoring each sub-method call during the execution of the method called in the target application; as well as In response to any sub-method call exception during the execution of the called method in the target application, local variables before the line of code that caused the exception in the sub-method that called the exception are obtained, and the local variables before the line of code that caused the exception in the sub-method that called the exception are persistently saved in the server to retain the test progress at the location of the line of code where the exception occurred.

2. The interface call testing method according to claim 1, characterized in that: The determining whether the target application satisfies the first preset condition includes: In response to receiving a first request information for testing the interface under test, the target application is mounted and monitored to determine whether a method in the target application is called, and the test status of the called method in the target application is adjusted to the first status; the first request information is triggered by the user starting a test of a method with an initial test status or a third test status; the method with an initial test status is a newly added interface mapping method, and the method with a third test status is a method that has completed at least one test.

3. The interface call testing method according to claim 1, characterized in that: The local variables obtained before the line of code causing the exception in the sub-method that calls the exception are executed include: Creating a virtual machine instance connected to the current execution environment of the target application; Starting a new thread in the virtual machine instance; starting the new thread includes: obtaining an event queue, cyclically reading events in the event queue, and in response to the read event being a breakpoint event, obtaining a thread frame to which the read event belongs, and obtaining all local variables in the sub-method that calls the exception before the code line number that causes the exception is executed through the thread frame to which the read event belongs; and A new breakpoint event is created at the code line where the exception occurs in the sub-method that calls the exception, and the new breakpoint event is sent to the event queue.

4. The interface call testing method according to claim 3, characterized in that: Determining whether the called method in the target application has been interrupted includes: In response to not being able to read the code line number from the variable of the new thread, determining that the called method in the target application has not been interrupted; and In response to reading a code line number from the thread variable, it is determined that the called method in the target application has been interrupted, and the code line number causing the exception is the code line number read from the thread variable.

5. The interface call testing method according to claim 1, characterized in that: Also includes: In response to any sub-method call exception during the execution of the called method in the target application, the method name of the sub-method call exception and the code line number causing the exception in the sub-method call exception are obtained and saved.

6. The interface call testing method according to claim 1, characterized in that: Also includes: In response to receiving the request information of the newly added interface under test, the application to which the newly added interface under test belongs, the class name to which the newly added interface under test belongs, and the method mapped by the newly added interface under test are obtained, and the test status of the method mapped by the newly added interface under test is set to the initial status.

7. The interface call testing method according to claim 2, characterized in that: Also includes: In response to a sub-method call exception occurring during the execution of the called method in the target application, the test state of the called method in the target application is adjusted to a second state.

8. The interface call testing method according to claim 7, characterized in that: Also includes: The determining whether the target application satisfies the first preset condition includes: In response to receiving a second request information for testing the interface under test, the test state of the called method in the target application is adjusted from the second state to the first state, and the re-call of the method in the target application is triggered through the reflection mechanism; the second request information is triggered by the user reopening the test of the method with the test state in the second state.

9. The interface call testing method according to claim 8, characterized in that: Also includes: In response to a method called in the target application being interrupted, obtaining a line number of a current code in the execution of the method called in the target application and a line number of an abnormal code in the target application; In response to a line number of a current code during execution of a called method in the target application being smaller than a line number of an abnormal code in the target application, skipping the current code; as well as In response to a line number of a current code being equal to a line number of an exception code in the target application during execution of a called method in the target application, obtaining local variables saved when the called method in the target application was interrupted, reloading the local variables saved when the called method in the target application was interrupted, and executing the current code.

10. The interface call testing method according to claim 1, characterized in that: Also includes: In response to the called method in the target application completing the test, the test state of the called method in the target application is adjusted to a third state.

11. A test system for interface calling, characterized in that: include: A first preset condition determination module is configured to: determine whether the target application meets a first preset condition; The target application is the application to which the interface under test belongs; The first preset condition includes that any method in the target application is called, and the called method in the target application is one of the preset methods to be tested; an interruption determination module configured to: in response to a target application satisfying a first preset condition, determine whether a method called in the target application has been interrupted; A call monitoring module is configured to: in response to the method called in the target application not being interrupted, monitor each sub-method call during the execution of the method called in the target application; and The local variable acquisition module is configured to: in response to any sub-method call exception during the execution of the called method in the target application, obtain the local variables in the sub-method that calls the exception before the code line number that causes the exception, and persist the local variables in the sub-method that calls the exception before the code line number that causes the exception to the server, so as to retain the test progress at the location of the exception code line number.

12. A computer device, characterized in that: The method comprises a memory and a processor, wherein a computer program is stored in the memory, and when the processor runs the computer program stored in the memory, the processor executes the test method for interface calling according to any one of claims 1 to 10.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the processor executes the test method for interface call according to any one of claims 1 to 10.

Images