Sub-method retry method and device and readable storage medium
By configuring and executing sub-method retry strategies during the testing process of complex business interfaces, the interface test failure, high cost and inefficiency caused by factor method execution exceptions are solved, and higher test efficiency and success rate are achieved.
Patent Information
- Application Number
- CN202510096746.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-21
- Publication Date
- 2025-05-23
AI Technical Summary
During the testing of complex business interfaces, factor method execution exceptions lead to interface execution failure, high testing cost and low testing efficiency.
Provide a sub-method retry method. By configuring the retry policy information of the target sub-method that needs to enable the retry mechanism during execution of the interface under test, and retry according to the retry policy information when an exception is thrown after the target sub-method is executed or the return content does not meet expectations.
Without re-preparing the test data, the sub-method can automatically retry according to the retry strategy when executing an exception, which reduces the test cost, increases the execution success rate of the interface being tested, and thus improves the testing efficiency of the interface.
Smart Images
Figure CN120029913A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of software testing, and in particular to a sub-method retry method, device and readable storage medium. Background Art
[0002] In a complex application system with a microservice architecture, a business interface usually calls multiple sub-methods during execution. These sub-methods usually handle complex business logic and even cross-service requests. Figure 1 As shown, interface A is the interface under test. During its execution, sub-methods B and C will be called. The business logic of these two sub-methods is also relatively complex, and calls to services B, C, and even D will occur respectively.
[0003] In the test environment, testing such a complex business interface is not an easy task. First, in order for the interface to start executing correctly, test data needs to be prepared first. The more complex the business logic of the interface is, the more difficult it is to prepare the test data. Secondly, during the interface execution process, as long as there is an exception in the execution of a sub-method, the interface execution will fail. When the interface fails, the test data usually changes and cannot be reused the next time it is executed. That is to say, the next time the interface is executed, the test data must be prepared again. In addition, there are many unstable factors in the test environment, such as data that is easy to be changed at will, service exceptions, random releases, insufficient resources, etc., which will cause sub-method execution exceptions and make the success rate of sub-method execution low. Therefore, for the test of complex business interfaces, the cost of each test in the test environment is relatively high, and the execution success rate is relatively low, so the test efficiency of the interface is usually low. Summary of the invention
[0004] The technical problem to be solved by the present invention is to provide a sub-method retry method, device and readable storage medium in response to the above-mentioned deficiencies in the prior art, so as to solve the problem in the prior art that when testing complex business interfaces, factor method execution exceptions easily lead to interface execution failure, high testing cost and low testing efficiency.
[0005] In a first aspect, the present invention provides a sub-method retry method, the method comprising:
[0006] Configure the retry policy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface;
[0007] During the execution of the interface under test, in response to the called target sub-method throwing an exception after execution or the returned content not meeting expectations, a retry is performed according to the retry strategy information.
[0008] Furthermore, before configuring the retry strategy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface, the method also includes:
[0009] Receive interface configuration information of the tested interface input by a user, wherein the interface configuration information includes an application identifier of an application to which the tested interface belongs, a name of a class to which the tested interface belongs, and an interface method name mapped to the tested interface;
[0010] Add the interface configuration information according to the user's new instruction, and add the interface configuration information to the interface configuration list;
[0011] In response to receiving a user's start operation on the interface configuration information of the interface under test based on the interface configuration list, according to the start operation, the application is mounted and listened to through a remote command, and after the application is mounted and listened, the interface method under test is listened to, and the interface method name is saved in a preset thread variable.
[0012] Furthermore, before configuring the retry strategy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface, the method also includes:
[0013] Receive the submethod configuration information of the target submethod for which a retry mechanism needs to be enabled, which is added by the user for the interface under test. The submethod configuration information includes the class name of the class corresponding to the target submethod and the method name of the target submethod.
[0014] Furthermore, the configuration of the retry strategy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface specifically includes:
[0015] Receiving retry policy information input by a user in a retry policy editing page of the target sub-method, the retry policy information including the number of retries, interval time and assertion;
[0016] In response to a determination instruction triggered by a user based on the retry policy editing page, the retry policy information of the target sub-method for which a retry mechanism needs to be enabled during execution of the tested interface is configured according to the number of retries, interval time and assertion.
[0017] Furthermore, after configuring the retry strategy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface, the method further includes:
[0018] Create a new method in the class corresponding to the target sub-method, and complete the steps of replacing the target sub-method;
[0019] A new method that replaces the target sub-method is rewritten, and the rewritten code is used to implement, during the execution of the interface under test, in response to an exception thrown after the call of the target sub-method is executed or the returned content does not meet expectations, a retry is performed according to the retry strategy information.
[0020] Furthermore, the step of creating a new method in the class corresponding to the target sub-method and completing the step of replacing the target sub-method specifically includes:
[0021] Get the class corresponding to the target submethod;
[0022] In the class corresponding to the target sub-method, the name of the target sub-method is changed to another method name;
[0023] A new method is created in the class corresponding to the target submethod by copying the original target submethod, wherein the name of the new method is consistent with the name of the target submethod before modification.
[0024] Furthermore, the logic of the rewritten code includes:
[0025] Try to get a value from said thread variable;
[0026] In response to being able to obtain a value from the thread variable, and the value is the interface method name, executing a loop according to the number of retries, in each loop, executing the original target sub-method and determining whether an exception is thrown after the execution, if no exception is thrown and the content returned after the execution contains the asserted content, then ending the loop and returning the returned content to the caller, if an exception is thrown or the returned content does not contain the asserted content, then continuing to execute the next loop according to the interval time until the loop reaches the number of retries;
[0027] In response to a value being obtained from the thread variable but the value is not the interface method name, or in response to a value being unable to be obtained from the thread variable, the original target submethod is directly executed.
[0028] In a second aspect, the present invention provides a sub-method retry device, the device comprising:
[0029] The retry strategy configuration module is used to configure the retry strategy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface;
[0030] The sub-method retry module is connected to the retry strategy configuration module and is used to retry according to the retry strategy information in response to an exception thrown after the execution of the called target sub-method or the returned content does not meet expectations during the execution of the tested interface.
[0031] In a third aspect, the present invention provides a sub-method retry device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to implement the sub-method retry method described in the first aspect above.
[0032] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the sub-method retry method described in the first aspect is implemented.
[0033] The present invention provides a sub-method retry method, device and readable storage medium. First, configure the retry policy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface; then, during the execution of the tested interface, in response to the target sub-method being called and throwing an exception after execution or the returned content not meeting expectations, retry according to the retry policy information. The present invention enables the sub-method to automatically retry according to the retry policy when an exception is thrown or the returned content does not meet expectations during execution, without the need to re-prepare test data, thereby reducing the test cost, improving the execution success rate of the tested interface, and further improving the test efficiency of the interface. It solves the problem in the prior art that when testing complex business interfaces, abnormal execution of factor methods easily leads to interface execution failure, high test costs and low test efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0034] Figure 1 It is an execution diagram of the existing business interface;
[0035] Figure 2 This is a flowchart of a retry method of a sub-method of Embodiment 1 of the present invention;
[0036] Figure 3 A schematic diagram of a new page for interface configuration information according to an embodiment of the present invention;
[0037] Figure 4 This is a schematic diagram of an interface configuration list display page according to an embodiment of the present invention;
[0038] Figure 5 This is a schematic diagram of a sub-method configuration information list page for which a retry mechanism needs to be enabled according to an embodiment of the present invention;
[0039] Figure 6 A schematic diagram of a new page for sub-method configuration information in an embodiment of the present invention;
[0040] Figure 7 This is a schematic diagram of a sub-method retry strategy editing page in an embodiment of the present invention;
[0041] Figure 8 This is a schematic diagram of the structure of a retry device of a sub-method of Embodiment 2 of the present invention;
[0042] Fig. 9 This is a schematic diagram of the structure of a retry device of a sub-method of Example 3 of the present invention. DETAILED DESCRIPTION
[0043] In order to enable those skilled in the art to better understand the technical solution of the present invention, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.
[0044] 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.
[0045] It can be understood that, in the absence of conflict, the various embodiments of the present invention and the various features in the embodiments can be combined with each other.
[0046] It can be understood that, for the convenience of description, the drawings of the present invention only show the parts related to the present invention, while the parts irrelevant to the present invention are not shown in the drawings.
[0047] 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.
[0048] It can be understood that the terms "first", "second", etc. in the embodiments of the present invention are used to distinguish different objects, or to distinguish different processing of the same object, rather than to describe a specific order of objects.
[0049] It can 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.
[0050] 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 the 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 by a hardware-based system that implements the specified functions, or may be implemented by a combination of hardware and computer instructions.
[0051] It can be understood that the units and modules involved in the embodiments of the present invention can be implemented by software or hardware. For example, the units and modules can be located in a processor.
[0052] Embodiment 1:
[0053] This embodiment provides a sub-method retry method, such as Figure 2 As shown, the method includes:
[0054] Step S101: configuring the retry policy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface.
[0055] In this embodiment, the target sub-method is any sub-method that will be called during the execution of the interface under test. The retry policy information includes the number of retries, the interval time, and the assertion. The number of retries is used to indicate the maximum number of times the target sub-method is continuously looped when the execution is abnormal or does not meet expectations; the interval time is the waiting time set between each retry, which is used to provide a buffer between consecutive retry attempts to avoid problems caused by too frequent interface calls; the assertion is used to verify whether the returned content meets expectations.
[0056] Optionally, before configuring the retry strategy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface, the method further includes:
[0057] Receive interface configuration information of the tested interface input by a user, wherein the interface configuration information includes an application identifier of an application to which the tested interface belongs, a name of a class to which the tested interface belongs, and an interface method name mapped to the tested interface;
[0058] Add the interface configuration information according to the user's new instruction, and add the interface configuration information to the interface configuration list;
[0059] In response to receiving a user's start operation on the interface configuration information of the interface under test based on the interface configuration list, according to the start operation, the application is mounted and listened to through a remote command, and after the application is mounted and listened, the interface method under test is listened to, and the interface method name is saved in a preset thread variable.
[0060] In this embodiment, a user (such as a tester) can fill in the interface configuration information of the tested interface on the interface configuration information new page. The schematic diagram of the interface configuration information new page can be as follows: Figure 3 As shown, application: refers to the application to which the tested interface belongs, such as kcard-xxx; class name: refers to the name of the class to which the tested interface method belongs, such as com.kcard.controller.UserController, where com.kcard.controller indicates the package name to which the class belongs, and UserController is the class name; interface method: refers to the method mapped by the tested interface; when the tested interface is requested to be called, the method mapped by the interface is actually executed, such as order(). When the user clicks the "Add" button, you can enter Figure 4The interface configuration list display page shown is used to display the interface configuration list. For the newly added tested interface configuration information, the status value is not enabled; users can click Figure 4 Click the "Enable" button in the pop-up window to change the status to Enable.
[0061] In this embodiment, when the user clicks the "Open" button, the system receives the opening operation and executes the following logic:
[0062] Through remote commands, such as: . / sandbox.sh -p 3 -d 'service-monitor / interfaceMonit? class = com.kcard.controller.UserController&method = order', execute the mount monitoring of the application. Among them, 3 is the process of the application, which is obtained by executing the command ps-ef | grep -i kcard-xxx | awk '{print$2}' (for example, the target application is kcard-xxx); class = com.kcard.controller.UserController&method = order are two parameters passed to the command. Figure 4 The trigger request is carried over when the open button is clicked on the page; sandbox.sh is the mount monitoring execution script of the jvm-sandbox installed in advance on the server where the application is located; jvm-sandbox is a process monitoring tool based on the jvm environment, which can monitor the java process (i.e., the application process) in the jvm. Similar tools include trace, arthas, etc. Therefore, if jvm-sandbox is not used, other monitoring tools can also be used to achieve the purpose; service-monitor / interfaceMonit is the name of the monitoring logic implementation package provided by the present invention. When the application is mounted and monitored, the logic of the package will be executed; the implementation logic of the package is as follows:
[0063] (1) Monitor the specified interface method, which is specified according to the values of the two parameters class and method passed in the command. For example, class=com.kcard.controller.UserController&method=order means to monitor the interface method order under the class com.kcard.controller.UserController; when the interface method is called, before it is executed, the logic of (2) is executed first;
[0064] (2) Save the interface method name (such as order) to the thread variable threadLocal (the code is threadLocal.set("order")). Here, threadLocal is a global static variable of type ThreadLocal, which is used to save some data during the thread execution process (such as order here). The saved data can be read at any time during the subsequent running 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).
[0065] Optionally, before configuring the retry strategy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface, the method further includes:
[0066] Receive the submethod configuration information of the target submethod for which a retry mechanism needs to be enabled, which is added by the user for the interface under test. The submethod configuration information includes the class name of the class corresponding to the target submethod and the method name of the target submethod.
[0067] In this embodiment, the user can add sub-method configuration information of all sub-methods that need to enable the retry mechanism for the tested interface. For example, when the user clicks Figure 4 When you click the "Edit" button in Figure 5 The sub-method configuration information list page for which the retry mechanism needs to be enabled is shown. Taking the target sub-method as infoQuery as an example, users can click Figure 5 Click the "Add" button in the upper right corner to pop up Figure 6 In the new sub-method configuration information page shown, fill in the class name and method name of the target sub-method for which the retry mechanism needs to be enabled and add it.
[0068] Optionally, the retry strategy information of the target sub-method for configuring the tested interface to enable a retry mechanism during execution specifically includes:
[0069] Receiving retry policy information input by a user in a retry policy editing page of the target sub-method;
[0070] In response to a determination instruction triggered by a user based on the retry policy editing page, the retry policy information of the target sub-method for which a retry mechanism needs to be enabled during execution of the tested interface is configured according to the number of retries, interval time and assertion.
[0071] In this embodiment, the retry policy editing page can be as follows Figure 7As shown, for example, the number of retries is configured as 5 times, the interval time is configured as 10s, and the assertion is configured as "code": "0000", which is the retry strategy information of the target sub-method infoQuery.
[0072] Optionally, after configuring the retry strategy information of the target sub-method for which the tested interface needs to enable a retry mechanism during execution, the method further includes:
[0073] Create a new method in the class corresponding to the target sub-method, and complete the steps of replacing the target sub-method;
[0074] A new method that replaces the target sub-method is rewritten, and the rewritten code is used to implement, during the execution of the interface under test, in response to an exception thrown after the call of the target sub-method is executed or the returned content does not meet expectations, a retry is performed according to the retry strategy information.
[0075] In this embodiment, when Figure 7 After clicking the "OK" button on the page, the rewrite operation of the target sub-method will be executed through remote commands, that is, first a new method is created in the class corresponding to the target sub-method (such as the com.kcard.common.utils class), and it is used to replace the specified target sub-method, and then the code of the new method is rewritten to finally achieve that during the execution of the interface under test, in response to the call of the target sub-method, an exception is thrown after execution or the returned content does not meet expectations, and a retry is performed according to the retry strategy information.
[0076] Optionally, the step of creating a new method in the class corresponding to the target sub-method and completing the step of replacing the target sub-method specifically includes:
[0077] Get the class corresponding to the target submethod;
[0078] In the class corresponding to the target sub-method, the name of the target sub-method is changed to another method name;
[0079] A new method is created in the class corresponding to the target submethod by copying the original target submethod, wherein the name of the new method is consistent with the name of the target submethod before modification.
[0080] In this embodiment, taking the target sub-method as infoQuery as an example, the corresponding replacement steps include:
[0081] (1) Create a ClassPool object: ClassPool pool =
[0082] ClassPool.getDefault();
[0083] (2) Get the class object of the specified class: CtClass theClass =
[0084] pool.get("com.kcard.common.utils");
[0085] (3) Get the method object of the specified submethod: CtMethod theMethod = theClass.getDeclaredMethod("infoQuery");
[0086] (4) Change the specified sub-method to another method name (change infoQuery to temp_infoQuery): theMethod.setName("temp_"+"infoQuery");
[0087] (5) Create a new method in the same class (the method name of the new method is the method name of the original specified sub-method, such as infoQuery), and the method copies the original specified sub-method: CtMethod newMethod = CtNewMethod.copy(theMethod,"infoQuery",theClass,null). Here, the new method uses the method name infoQuery of the original specified sub-method, and the method name of the original specified sub-method becomes temp_infoQuery, thus completing the method replacement.
[0088] Optionally, the logic of the rewritten code includes:
[0089] Try to get a value from said thread variable;
[0090] In response to being able to obtain a value from the thread variable, and the value is the interface method name, executing a loop according to the number of retries, in each loop, executing the original target sub-method and determining whether an exception is thrown after the execution, if no exception is thrown and the content returned after the execution contains the asserted content, then ending the loop and returning the returned content to the caller, if an exception is thrown or the returned content does not contain the asserted content, then continuing to execute the next loop according to the interval time until the loop reaches the number of retries;
[0091] In response to a value being obtained from the thread variable but the value is not the interface method name, or in response to a value being unable to be obtained from the thread variable, the original target submethod is directly executed.
[0092] In this embodiment, an attempt is made to obtain a value from the thread variable. If a value can be obtained and the value is the method name of the interface method under test corresponding to the target sub-method (such as order), the logic of the loop is executed. If a value cannot be obtained from the thread variable or the value is not the corresponding interface method under test, it means that the target sub-method is not called due to the execution of the interface method under test. At this time, no intervention is required, and it can be executed and returned normally as before, that is, the original specified sub-method (here refers to the renamed specified sub-method, namely temp_infoQuery) is directly executed without going through the subsequent loop.
[0093] In this embodiment, the loop logic specifically includes: executing a while loop, the number of loops is Figure 7 The number of retries configured in the page, in each cycle, directly execute the original specified sub-method (here refers to the renamed specified sub-method, that is, temp_infoQuery); after execution, if no exception is thrown, determine whether the return content of the sub-method contains Figure 7 If the assertion content configured in the page is included, the while loop ends and the return content is returned to the caller; if an exception is thrown or it is not included, after a certain interval (the interval is Figure 7 The while loop continues to execute. If the number of retries is exceeded, the loop ends and the return content is returned to the caller; (in this case, the interface under test will definitely fail to execute).
[0094] Step S102: During the execution of the interface under test, in response to the called target sub-method throwing an exception after execution or the returned content not meeting expectations, a retry is performed according to the retry strategy information.
[0095] In this embodiment, during the execution of the tested interface, as long as the target sub-method throws an exception or the returned content does not meet the assertion after execution, it will automatically start retrying according to the retry strategy, thereby improving the execution success rate of the tested interface.
[0096] In a specific embodiment, the sub-method retry method may include the following steps:
[0097] Step 1: Testers Figure 3 Fill in the interface configuration information of the interface to be tested on the interface configuration information adding page shown, including application, class name, interface method, and then click the "Add" button;
[0098] Among them, application: refers to the application to which the tested interface belongs, such as kcard-xxx;
[0099] Class name: refers to the name of the class to which the interface method being tested belongs, such as com.kcard.controller.UserController, where com.kcard.controller represents the package name to which the class belongs, and UserController is the class name;
[0100] Interface method: refers to the method mapped by the interface under test; when the interface under test is requested to be called, the method mapped by the interface is actually executed, such as order();
[0101] After clicking the "Add" button, the page will trigger a request to service Z (the service provided by the present invention), and service Z will save the interface configuration information of the newly added tested interface to redis for subsequent use; among them, the value of the status will be assigned by default to not enabled.
[0102] Step 2, then jump to Figure 4 The interface configuration list display page shown in the figure displays the interface configuration information of all tested interfaces. For the newly added tested interface configuration information, the status value is not enabled. The tester can click the "Enable" button to change the status to enabled. After enabling, the edit button will appear, and the tester can click the "Edit" button for further configuration.
[0103] Specifically, jump to Figure 4 After the page is opened, the page will request service Z to query all the tested interface configuration information and display it; when the tester clicks the start button, it will trigger a request to service Z. After receiving the request, service Z executes the following logic:
[0104] Through remote commands, such as: . / sandbox.sh -p 3 -d 'service-monitor / interfaceMonit? class = com.kcard.controller.UserController&method = order', execute the mount monitoring of the application. Among them, 3 is the process of the application, which is obtained by executing the command ps-ef | grep -i kcard-xxx | awk '{print$2}' (for example, the target application is kcard-xxx); class = com.kcard.controller.UserController&method = order are two parameters passed to the command. Figure 4The trigger request is carried over when the open button is clicked on the page; sandbox.sh is the mount monitoring execution script of the jvm-sandbox installed in advance on the server where the application is located; jvm-sandbox is a process monitoring tool based on the jvm environment, which can monitor the java process (i.e., the application process) in the jvm. Similar tools include trace, arthas, etc. Therefore, if jvm-sandbox is not used, other monitoring tools can also be used to achieve the purpose; service-monitor / interfaceMonit is the name of the monitoring logic implementation package provided by the present invention. When the application is mounted and monitored, the logic of the package will be executed; the implementation logic of the package is as follows:
[0105] (1) Monitor the specified interface method, which is specified according to the values of the two parameters class and method passed in the command. For example, class=com.kcard.controller.UserController&method=order means to monitor the interface method order under the class com.kcard.controller.UserController; when the interface method is called, before it is executed, the logic of (2) is executed first;
[0106] (2) Save the interface method name (such as order) to the thread variable threadLocal (the code is threadLocal.set("order")). Here, threadLocal is a global static variable of type ThreadLocal, which is used to save some data during the thread execution process (such as order here). The saved data can be read at any time during the subsequent running 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).
[0107] Step 3. After clicking the "Edit" button, a pop-up window will pop up. Figure 5 The sub-method configuration information list page that needs to enable the retry mechanism is shown. This page will display the configuration information of all sub-methods that need to enable the retry mechanism when the tested interface is executed; click the "Add" button, and a pop-up Figure 6 In the sub-method configuration information adding page shown, after filling in the class name and sub-method, click the "OK" button to add a sub-method configuration information; for the newly added sub-method configuration information, the status value is invalid. You need to click the "Edit" button and make further configurations before the status becomes valid.
[0108] Specifically, the first entry Figure 5When the sub-method configuration information list is empty, the tester clicks the "Add" button (a pop-up Figure 6 page), to add a sub-method configuration information; it should be noted that the sub-method configuration information added here must be called during the execution of the interface method under test, otherwise the configuration is useless.
[0109] Step 4: Figure 5 After clicking the "Edit" button of a row on the page, a pop-up window will appear. Figure 7 The sub-method retry policy editing page shown in the figure, fill in the sub-method retry policy information in the page, including the number of retries, interval time, assertion, and then click the "OK" button to complete the activation of the sub-method retry mechanism. Figure 5 The status of the sub-method configuration information in this row on the page becomes valid.
[0110] Specifically, when Figure 7 After clicking the "OK" button on the page, a request will be triggered to service Z. After receiving the request, service Z executes the following logic:
[0111] 1. Use remote commands to rewrite the sub-method. The command is: . / sandbox.sh -p 3 -d 'method-change / execute? class=com.kcard.common.utils&method=info Query', where 3 is the application process (for example, it is still the process of kcard-xxx), and class=com.kcard.common.utils&method=infoQuery is from Figure 7 The parameter passed after clicking the "OK" button indicates the submethod infoQuery under the class com.kcard.common.utils (which belongs to the same application as the interface method under test, such as kcard-xxx); method-change / execute is the name of the operation logic package to be executed, and its implementation logic is as follows:
[0112] (1) Create a new method in the specified class (such as the com.kcard.common.utils class) and use it to replace the specified submethod. The specified class and submethod here are obtained from the passed class and method parameters. The specific implementation code is:
[0113] (1-1) Create a ClassPool object: ClassPool pool = ClassPool.getDefault();
[0114] (1-2) Get the class object of the specified class: CtClass theClass = pool.get("com.kcard.common.utils");
[0115] (1-3) Get the method object of the specified submethod: CtMethod theMethod = theClass.getDeclaredMethod("infoQuery");
[0116] (1-4) Change the specified sub-method to another method name (change infoQuery to temp_infoQuery): theMethod.setName("temp_"+"infoQuery");
[0117] (1-5) Create a new method in the same class (the method name of the new method is the method name of the original specified sub-method, such as infoQuery), and the method copies the original specified sub-method: CtMethod newMethod = CtNewMethod.copy(theMethod,"infoQuery",theClass,null). Here, the new method uses the method name infoQuery of the original specified sub-method, and the method name of the original specified sub-method becomes temp_infoQuery, thus completing the method replacement;
[0118] (1-6) Rewrite the code of the new method (i.e. rewrite infoQuery), specifically:
[0119] (1-6-1) Save the rewritten code in the StringBuffer body variable. The content of the code is:
[0120] (1-6-1-1) Try to get the value from the thread variable threadLocal (the code is threadLocal.get()). If the value can be obtained and the value is Figure 5 If the method name of the interface method under test corresponding to the specified sub-method in the page (i.e. order) is found, the logic of (1-6-1-2) is executed; otherwise, the original specified sub-method is executed directly (here refers to the specified sub-method after the name is changed, i.e. temp_infoQuery), and the subsequent loop is not executed; it should be noted that if no value can be obtained from the thread variable threadLocal or the value is not the corresponding interface method under test, it means that the current sub-method is not called due to the execution of the interface method under test, and there is no need to intervene, and it can be executed and returned normally as before.
[0121] (1-6-1-2) executes a while loop, the number of loops is Figure 7 The number of retries configured in the page, in each loop, directly executes the original specified sub-method (here refers to the renamed specified sub-method, i.e., temp_infoQuery); after execution, if no exception is thrown, determine whether the return content of the sub-method contains Figure 7 If the assertion content configured in the page is included, the while loop ends and the return content is returned to the caller; if an exception is thrown or it is not included, after a certain interval (the interval is Figure 7 The interval time configured in the page) continues to execute the while loop;
[0122] (1-6-1-3) If the number of retries exceeds the limit, the loop ends and the return content is returned to the caller; (If this happens, the interface under test will definitely fail to execute).
[0123] (1-6-2) Set body to the method body code of the new method: newMethod.setBody(body.toString());
[0124] (1-7) Add a new method to the specified class:
[0125] theClass.addMethod(newMethod);
[0126] (1-8) Reload the modified specified class: theClass.toClass().
[0127] 2. After successfully rewriting and reloading the specified class, Figure 5 The status of the sub-method configuration information is changed to valid. In this way, the tester can know that this sub-method will go through the retry mechanism after being called.
[0128] Step 5. After the above configuration is completed, the retry mechanism of the relevant sub-method calls that occur during the execution of the tested interface is enabled. At this time, as long as the execution result of a sub-method does not meet the assertion, it will automatically start to retry, thereby improving the execution success rate of the tested interface.
[0129] The sub-method retry method provided in the embodiment of the present invention first configures the retry policy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface; then, during the execution of the tested interface, in response to the called target sub-method throwing an exception after execution or the returned content not meeting expectations, retry is performed according to the retry policy information. The present invention enables the sub-method to automatically retry according to the retry policy when an exception is thrown or the returned content does not meet expectations during execution, without the need to re-prepare test data, thereby reducing the test cost, improving the execution success rate of the tested interface, and further improving the test efficiency of the interface. It solves the problem in the prior art that when testing complex business interfaces, the abnormal execution of the factor method easily leads to interface execution failure, high test cost, and low test efficiency.
[0130] Embodiment 2:
[0131] like Figure 8 As shown, this embodiment provides a sub-method retry device, which is used to execute the above sub-method retry method, including:
[0132] The retry strategy configuration module 11 is used to configure the retry strategy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface;
[0133] The sub-method retry module 12 is connected to the retry strategy configuration module 11 and is used to retry according to the retry strategy information in response to an exception thrown after the execution of the called target sub-method or the returned content does not meet expectations during the execution of the interface under test.
[0134] Optionally, the device further comprises:
[0135] A first receiving module, configured to receive interface configuration information of the tested interface input by a user, wherein the interface configuration information includes an application identifier of an application to which the tested interface belongs, a name of a class to which the tested interface belongs, and an interface method name mapped to the tested interface;
[0136] An interface configuration adding module, used to add the interface configuration information according to the user's new instruction, and add the interface configuration information to the interface configuration list;
[0137] The mounting monitoring module is used to respond to receiving a user's start-up operation on the interface configuration information of the tested interface based on the interface configuration list, and according to the start-up operation, monitor the application through a remote command, and after the application is mounted and monitored, monitor the tested interface method and save the interface method name to a preset thread variable.
[0138] Optionally, the device further comprises:
[0139] The second receiving module is used to receive the sub-method configuration information of the target sub-method added by the user for the tested interface that needs to enable the retry mechanism, and the sub-method configuration information includes the class name of the class corresponding to the target sub-method and the method name of the target sub-method.
[0140] Optionally, the retry strategy configuration module 11 includes:
[0141] A retry strategy receiving unit, configured to receive retry strategy information input by a user in a retry strategy editing page of the target sub-method, wherein the retry strategy information includes a number of retries, an interval time, and an assertion;
[0142] A retry strategy configuration unit is used to respond to a determination instruction triggered by a user based on the retry strategy editing page, and configure the retry strategy information of the target sub-method of the tested interface that needs to enable the retry mechanism during execution according to the number of retries, interval time and assertion.
[0143] Optionally, the device further comprises:
[0144] A method replacement module, used to create a new method in the class corresponding to the target sub-method and complete the steps of replacing the target sub-method;
[0145] A code rewriting module is used to rewrite a new method that replaces the target sub-method. The rewritten code is used to implement, during the execution of the interface under test, in response to an exception thrown after the call of the target sub-method is executed or the returned content does not meet expectations, a retry is performed according to the retry strategy information.
[0146] Optionally, the method replaces the module comprising:
[0147] A class acquisition unit, used to acquire the class corresponding to the target sub-method;
[0148] A method name modification unit, used to modify the name of the target sub-method to another method name in the class corresponding to the target sub-method;
[0149] The method copying unit is used to create a new method in the class corresponding to the target sub-method by copying the original target sub-method, wherein the name of the new method is consistent with the name of the target sub-method before modification.
[0150] Optionally, the logic of the rewritten code includes:
[0151] Try to get a value from said thread variable;
[0152] In response to being able to obtain a value from the thread variable, and the value is the interface method name, executing a loop according to the number of retries, in each loop, executing the original target sub-method and determining whether an exception is thrown after the execution, if no exception is thrown and the content returned after the execution contains the asserted content, then ending the loop and returning the returned content to the caller, if an exception is thrown or the returned content does not contain the asserted content, then continuing to execute the next loop according to the interval time until the loop reaches the number of retries;
[0153] In response to a value being obtained from the thread variable but the value is not the interface method name, or in response to a value being unable to be obtained from the thread variable, the original target submethod is directly executed.
[0154] Embodiment 3:
[0155] refer to Fig. 9 This embodiment provides a sub-method retry device, including a memory 21 and a processor 22, wherein the memory 21 stores a computer program, and the processor 22 is configured to run the computer program to execute the sub-method retry method in Example 1.
[0156] The memory 21 is connected to the processor 22. The memory 21 may be a flash memory, a read-only memory or other memory. The processor 22 may be a central processing unit or a single-chip microcomputer.
[0157] Embodiment 4:
[0158] This embodiment provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the sub-method retry method in the above-mentioned embodiment 1 is implemented.
[0159] The computer-readable storage medium includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program modules or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable read only memory), flash memory or other memory technology, CD-ROM (Compact Disc Read-Only Memory), digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer.
[0160] In summary, the sub-method retry method, device and readable storage medium provided in the embodiments of the present invention first configure the retry policy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface; then, during the execution of the tested interface, in response to the called target sub-method throwing an exception after execution or the returned content not meeting expectations, retry according to the retry policy information. The present invention enables the sub-method to automatically retry according to the retry policy when an exception is thrown or the returned content does not meet expectations during execution, without the need to re-prepare test data, thereby reducing the test cost, improving the execution success rate of the tested interface, and further improving the test efficiency of the interface. It solves the problem in the prior art that when testing complex business interfaces, the abnormal execution of the factor method easily leads to interface execution failure, high test cost and low test efficiency.
[0161] It is to be understood that the above embodiments are merely exemplary embodiments used to illustrate the principles of the present invention, but the present invention is not limited thereto. For those of ordinary skill in the art, various modifications and improvements can be made without departing from the spirit and essence of the present invention, and these modifications and improvements are also considered to be within the scope of protection of the present invention.
Claims
1. A sub-method retry method, characterized in that, The method comprises: Configure the retry policy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface; During the execution of the interface under test, in response to the called target sub-method throwing an exception after execution or the returned content not meeting expectations, a retry is performed according to the retry strategy information.
2. The method according to claim 1, characterized in that Before configuring the retry strategy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface, the method further includes: Receive interface configuration information of the tested interface input by a user, wherein the interface configuration information includes an application identifier of an application to which the tested interface belongs, a name of a class to which the tested interface belongs, and an interface method name mapped to the tested interface; Add the interface configuration information according to the user's new instruction, and add the interface configuration information to the interface configuration list; In response to receiving a user's start operation on the interface configuration information of the interface under test based on the interface configuration list, according to the start operation, the application is mounted and listened to through a remote command, and after the application is mounted and listened, the interface method under test is listened to, and the interface method name is saved in a preset thread variable.
3. The method according to claim 2, characterized in that Before configuring the retry strategy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface, the method further includes: Receive the submethod configuration information of the target submethod for which a retry mechanism needs to be enabled, which is added by the user for the interface under test. The submethod configuration information includes the class name of the class corresponding to the target submethod and the method name of the target submethod.
4. The method according to claim 2, characterized in that: The configuration of the retry strategy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface specifically includes: Receiving retry policy information input by a user in a retry policy editing page of the target sub-method, the retry policy information including the number of retries, interval time and assertion; In response to a determination instruction triggered by a user based on the retry policy editing page, the retry policy information of the target sub-method for which a retry mechanism needs to be enabled during execution of the tested interface is configured according to the number of retries, interval time and assertion.
5. The method according to claim 4, characterized in that After configuring the retry strategy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface, the method further includes: Create a new method in the class corresponding to the target sub-method, and complete the steps of replacing the target sub-method; A new method that replaces the target sub-method is rewritten, and the rewritten code is used to implement, during the execution of the interface under test, in response to an exception thrown after the call of the target sub-method is executed or the returned content does not meet expectations, a retry is performed according to the retry strategy information.
6. The method according to claim 5, characterized in that The step of creating a new method in the class corresponding to the target sub-method and completing the step of replacing the target sub-method specifically includes: Get the class corresponding to the target submethod; In the class corresponding to the target sub-method, the name of the target sub-method is changed to another method name; A new method is created in the class corresponding to the target submethod by copying the original target submethod, wherein the name of the new method is consistent with the name of the target submethod before modification.
7. The method according to claim 6, characterized in that The logic of the rewritten code includes: Try to get a value from said thread variable; In response to being able to obtain a value from the thread variable, and the value is the interface method name, executing a loop according to the number of retries, in each loop, executing the original target sub-method and determining whether an exception is thrown after the execution, if no exception is thrown and the content returned after the execution contains the asserted content, then ending the loop and returning the returned content to the caller, if an exception is thrown or the returned content does not contain the asserted content, then continuing to execute the next loop according to the interval time until the loop reaches the number of retries; In response to a value being obtained from the thread variable but the value is not the interface method name, or in response to a value being unable to be obtained from the thread variable, the original target submethod is directly executed.
8. A sub-method retry device, characterized in that, The device comprises: The retry strategy configuration module is used to configure the retry strategy information of the target sub-method that needs to enable the retry mechanism during the execution of the tested interface; The sub-method retry module is connected to the retry strategy configuration module and is used to retry according to the retry strategy information in response to an exception thrown after the execution of the called target sub-method or the returned content does not meet expectations during the execution of the tested interface.
9. A sub-method retry device, characterized in that, The method comprises a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to implement the sub-method retry method according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the sub-method retry method according to any one of claims 1 to 7 is implemented.