Method, computing device, and computer-readable storage medium for testing interface idempotence

Abstract

The present application provides a method, computing device, and computer-readable storage medium for testing the idempotence of an interface, relating to the field of communication technology. The method includes: a testing device receives a first request, the first request is used to request the idempotence of an interface corresponding to a service provided by a test application, and the first request carries request information for the service; then, a shadow request is generated based on the first request, and the request information for the service carried by the shadow request is the same as the request information for the service carried by the first request; thereafter, a first execution result obtained after executing the service based on the request information carried by the first request and a second execution result obtained after executing the service based on the request information carried by the second request are obtained; based on the first execution result and the second execution result, it is determined whether the interface has idempotence. In this way, there is no need to manually test the idempotence of the interface, and the testing device automatically tests the idempotence of the interface, which can greatly improve the testing efficiency and accuracy.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a method, computing device, and computer-readable storage medium for testing interface idempotence. Background Art

[0002] Applications can provide multiple services, and application programming interfaces (APIs) are increasingly becoming the primary service entry point for applications. With the widespread adoption of APIs, API performance has a significant impact on application operations. To promptly identify API defects, API testing is necessary. API testing, also known as interface testing, aims to verify whether the API meets functional, performance, reliability, and security requirements. One important interface test is interface idempotence testing.

[0003] Interface idempotence means that for the same request, the execution results should remain consistent regardless of how many times it is executed. In other words, if an interface is called multiple times and produces the same results as when called only once, then the interface is considered idempotent. The purpose of interface idempotence testing is to verify whether the interface can maintain data consistency and service reliability when processing repeated requests.

[0004] Traditional interface idempotency testing often relies on manual testing and manual comparison of test results. Specifically, when the application is configured for interface idempotency testing mode, the user manually clicks twice on the service control in the interface of the application being tested. In response to the two clicks, the electronic device calls the interface to generate two requests, then executes the two requests to obtain two execution results. The two execution results are then manually compared to ensure consistency. This method is not only labor-intensive but also prone to errors in the comparison of execution test results due to human errors (such as carelessness and blurred vision). This leads to low interface idempotency testing efficiency and inaccurate interface idempotency test results. Summary of the Invention

[0005] The present application provides a method, computing device, and computer-readable storage medium for testing interface idempotence, which can improve the efficiency and accuracy of interface idempotence testing to a certain extent.

[0006] The present application provides a memory management method, a computing device, and a computer-readable storage medium, which, to a certain extent, can enable applications running in the foreground to have more sufficient memory usage, enable them to run more smoothly, and improve the user experience.

[0007] To achieve the above objectives, this application adopts the following technical solutions:

[0008] In the first aspect, the present application provides a method for testing the idempotence of an interface, which is applied to a testing device, and the method includes: receiving a first request, the first request being used to request the idempotence of an interface corresponding to a service provided by a test application, the first request carrying request information of the service; generating a shadow request based on the first request, the request information of the service carried by the shadow request being the same as the request information of the service carried by the first request; obtaining a first execution result and a second execution result, the first execution result being obtained after executing the service based on the request information carried by the first request, and the second execution result being obtained after executing the service multiple times based on the request information carried by the shadow request; determining whether the interface has idempotence based on the first execution result and the second execution result; wherein, if the first execution result is the same as the second execution result, the interface has idempotence; if the first execution result is different from the second execution result, the interface does not have idempotence.

[0009] In this solution, the testing device can determine the idempotency test result of the interface based on the comparison between the execution result of the request and the execution result of the shadow request. This eliminates the need for manual testing of the interface's idempotency; the testing device automatically tests the interface's idempotency, significantly improving testing efficiency and accuracy.

[0010] In a possible implementation of the first aspect, the first request may further carry indication information of the idempotence of the interface of the test service, so as to trigger the testing device to perform the idempotence test of the interface.

[0011] In a possible implementation manner of the first aspect, the method further includes: sending a test result to the electronic device, where the test result is used to indicate whether the interface has idempotence.

[0012] In a possible implementation of the first aspect, the first execution result includes first status information and first response information of the business after the business is executed based on the first request; the second execution result includes second status information and second response information of the business after the business is executed based on the shadow request; when the first status information and the second status information are the same, and the first response information and the second response information are the same, the first execution result is the same as the second execution result; when the first status information and the second status information are different, and / or the first response information and the second response information are different, the first execution result is different from the second execution result.

[0013] In a possible implementation of the first aspect, obtaining the first execution result and the second execution result includes: sending a first request to a business server and sending shadow requests multiple times; and receiving the first execution result and the second execution result from the business server.

[0014] In a possible implementation of the first aspect, the shadow request is sent twice.

[0015] In the above scheme, the shadow request is sent twice, and the idempotence of the interface is tested with a smaller number of transmissions. On the one hand, the power consumption of the test interface idempotence is reduced, and on the other hand, the efficiency of the test interface idempotence is improved.

[0016] In a possible implementation of the first aspect, a time interval between two adjacent shadow requests is less than a threshold.

[0017] In the above solution, since the time of sending the two shadow requests is close, this can simulate the concurrent call scenario and test the idempotence of the interface in the concurrent scenario.

[0018] In a possible implementation of the first aspect, obtaining the first execution result and the second execution result includes: executing a first request to obtain the first execution result; and executing multiple shadow requests to obtain the second execution result.

[0019] In the above scheme, the shadow request is sent multiple times, corresponding to the multiple executions of the shadow request.

[0020] In a possible implementation of the first aspect, the shadow request is executed twice.

[0021] In the above solution, the shadow request is sent twice, corresponding to two shadow request executions. Testing the idempotence of the interface with a smaller number of shadow request executions not only reduces the power consumption of the test, but also improves the efficiency of the test.

[0022] In the second aspect, the present application provides a method for testing the idempotence of an interface, which is applied to a business server and includes: receiving a first request and multiple shadow requests sent by a test device; the first request is used to request the idempotence of the interface corresponding to the business provided by the test application, the first request carries the request information of the business, the shadow request carries the request information of the business, and the request information of the business carried by the shadow request is the same as the request information of the business carried by the first request; executing the business based on the request information of the business carried by the first request to obtain a first execution result, and executing the business multiple times based on the request information of the business carried by multiple shadow requests, and sending the first execution result and the second execution result to the test device; wherein the first execution result and the second execution result are used to determine whether the interface has idempotence.

[0023] In this solution, the service server sends the first and second execution results to the testing device. This allows the testing device to determine the idempotency test result for the interface based on a comparison between the request execution result and the shadow request execution result. This eliminates the need for manual testing of the interface's idempotency; the testing device automatically tests the interface's idempotency, significantly improving testing efficiency and accuracy.

[0024] In a possible implementation of the second aspect, the first execution result includes first status information and first response information of the business after the business is executed based on the first request; the second execution result includes second status information and second response information of the business after the business is executed based on the shadow request.

[0025] In a possible implementation manner of the second aspect, the first status information is stored in a first data table of the service server, and the second status information is stored in a second data table of the service server.

[0026] In a possible implementation of the second aspect, before receiving the first request, the first data table stores initial status information of the business, and the second data table does not include status information of the business; after receiving the first request and multiple shadow requests sent by the test device, the method also includes: synchronizing the initial status information in the first data table to the second data table; wherein, the first status information is status information after the initial status information of the business stored in the first data table is updated after the business is executed based on the first request; the second status information is status information after the initial status information of the business stored in the second data table is updated after the business is executed multiple times based on multiple shadow requests.

[0027] In the above solution, the business status information stored in the first data table is updated as the first request is executed, and the business status information stored in the second data table is updated as the shadow request is executed multiple times.

[0028] In a possible implementation of the second aspect, obtaining the first execution result and the second execution result includes: sending a first request to a business server and sending shadow requests multiple times; and receiving the first execution result and the second execution result from the business server.

[0029] In a possible implementation of the second aspect, the shadow request is sent twice.

[0030] In the above scheme, the shadow request is sent twice, and the idempotence of the interface is tested with a smaller number of transmissions. On the one hand, the power consumption of the test interface idempotence is reduced, and on the other hand, the efficiency of the test interface idempotence is improved.

[0031] In a possible implementation of the second aspect, a time interval between two consecutive shadow requests is less than a threshold.

[0032] In the above solution, since the time of sending the two shadow requests is close, this can simulate the concurrent call scenario and test the idempotence of the interface in the concurrent scenario.

[0033] In a possible implementation of the second aspect, obtaining the first execution result and the second execution result includes: executing a first request to obtain the first execution result; and executing multiple shadow requests to obtain the second execution result.

[0034] In the above scheme, the shadow request is sent multiple times, corresponding to the multiple executions of the shadow request.

[0035] In a possible implementation of the second aspect, the shadow request is executed twice.

[0036] In the above solution, the shadow request is sent twice, corresponding to two shadow request executions. Testing the idempotence of the interface with a smaller number of shadow request executions not only reduces the power consumption of the test, but also improves the efficiency of the test.

[0037] In a third aspect, the present application provides a method for testing the idempotence of an interface, which is applied to a test system, the test system including a test device and a business server, including: the test device receives a first request, the first request is used to request the idempotence of the interface corresponding to the business provided by the test application, and the first request carries the request information of the business; the test device generates a shadow request based on the first request, and the request information of the business carried by the shadow request is the same as the request information of the business carried by the first request; the test device sends the first request to the business server, and sends the shadow request multiple times; the business server executes the business based on the request information of the business carried by the received first request, obtains a first execution result, and executes the business multiple times based on the request information of the business carried by the received multiple shadow requests, and the business server sends the first execution result and the second execution result to the test device; the test device determines whether the interface has idempotence based on the first execution result and the second execution result; wherein, when the first execution result is the same as the second execution result, the interface has idempotence; when the first execution result is different from the second execution result, the interface does not have idempotence.

[0038] In this solution, the testing device can determine the idempotency test result of the interface based on the comparison between the execution result of the request and the execution result of the shadow request. This eliminates the need for manual testing of the interface's idempotency; the testing device automatically tests the interface's idempotency, significantly improving testing efficiency and accuracy.

[0039] In a fourth aspect, the present application provides a computing device comprising at least a memory and one or more processors. The memory is configured to store computer instructions, and when the one or more processors execute the computer instructions, the computing device performs the method described in any one of the first and second aspects above.

[0040] In a fifth aspect, the present application provides a computer-readable storage medium, which includes computer instructions. When the computer instructions are executed on a computing device, the computing device executes a method as described in any one of the first or second aspects above.

[0041] In a sixth aspect, the present application provides a computer program product, which, when executed on a computing device, enables the computing device to execute a method as described in any one of the first or second aspects above.

[0042] Among them, the technical effects brought about by any design method in the fourth to sixth aspects can refer to the technical effects brought about by different design methods in the first, second and third aspects, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 A schematic diagram of a test system provided in an embodiment of the present application is shown;

[0044] Figure 2 A schematic diagram of the structure of a computer provided in an embodiment of the present application is shown;

[0045] Figure 3 A schematic structural diagram of a testing device provided in an embodiment of the present application is shown;

[0046] Figure 4 This is a flowchart of a method for testing interface idempotence;

[0047] Figure 5 A schematic diagram of a computer interface showing test results of an interface having idempotency;

[0048] Figure 6 A schematic diagram of a computer interface showing a test result showing that the interface does not have idempotency;

[0049] Figure 7 A schematic diagram of a computer interface showing an idempotence verification list is shown;

[0050] Figure 8 A schematic diagram of a details page is shown;

[0051] Figure 9 A schematic diagram showing the structure of a service module of a service gateway and a service server provided in an embodiment of the present application is shown;

[0052] Figure 10 A structural diagram of a service module of a service gateway and a service server provided in another embodiment of the present application is shown. DETAILED DESCRIPTION

[0053] The technical solutions in the embodiments of the present application are described below in conjunction with the accompanying drawings. The terms used in the following embodiments are for the purpose of describing specific embodiments only and are not intended to limit the present application. As used in the specification and appended claims of this application, the singular expressions "a," "the," "the," "the," and "the" are intended to include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, "at least one" and "one or more" refer to one or more (including two). The term "and / or" is used to describe an association relationship between associated objects, indicating that three possible relationships can exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, or B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the associated objects are in an "or" relationship.

[0054] References to "one embodiment" or "some embodiments" etc. described in this specification mean that the specific features, structures or characteristics described in conjunction with the embodiment are included in one or more embodiments of the present application. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. appearing in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in another way. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in another way. The term "connected" includes direct and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated.

[0055] In the embodiments of this application, words such as "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplarily" or "for example" is intended to present the relevant concepts in a concrete manner.

[0056] As described in the previous background technology, traditional interface idempotence testing often relies on manual testing and manual comparison of test results. This method is not only labor-intensive but also prone to errors in the comparison of test results (such as request execution results) due to human errors (such as carelessness and blurred vision). This leads to low interface idempotence testing efficiency and inaccurate interface idempotence test results.

[0057] To address this technical problem, embodiments of the present application propose a method for testing interface idempotence. This method includes the following steps: When the application being tested is configured in idempotence testing mode, upon receiving a user trigger operation on a control for a service, an electronic device installed with the application can invoke an interface implementing the service to generate a request. The electronic device can then send the request to a testing device. Upon receiving a request initiated by a call to an interface of the application being tested, the testing device can automatically generate a shadow request identical to the request. This request and the shadow request are used to trigger the execution of the corresponding service. After the service is executed, a corresponding execution result is generated. The testing device can then obtain the execution result of the request and the shadow request and automatically compare the results. Based on the comparison of the request and shadow request execution results, the testing device can then determine the idempotence test result for the interface. This eliminates the need for manual testing of the interface's idempotence; the testing device automatically tests the interface's idempotence, significantly improving testing efficiency and accuracy.

[0058] The interface idempotency testing method provided in the embodiment of the present application can be applied to a test system for testing the idempotency of an interface. For example, Figure 1 A schematic diagram of a test system provided in an embodiment of the present application is shown as follows: Figure 1 As shown, the test system includes an electronic device 100 and a test device. In some embodiments, as Figure 1 In (a), the test device is illustrated as service gateway 200-1. The test device may also be a module or a combination of modules in service gateway 200-1 for implementing interface idempotence testing, which is not specifically limited in this embodiment of the present application.

[0059] like Figure 1 As shown in (a) of FIG, electronic device 100 has an application under test installed. This application can be a system application or a third-party application. The application under test can be of various types, such as payment applications, shopping applications, enterprise management applications, gaming applications, video applications, etc., but is not limited to these. This embodiment of the present application does not impose any specific restrictions here.

[0060] The application under test may provide one or more services. The services may be services provided by the application under test whose corresponding interfaces need to be tested for idempotence. The interface under test is the interface corresponding to the services.

[0061] The electronic device 100 may be equipped with a browser, and the application being tested may be opened in the browser. Specifically, the user may enter the URL of the application being tested in the browser and perform an opening operation on the URL. The electronic device may respond to the opening operation to open the application being tested.

[0062] If the application being tested is configured for idempotence testing, electronic device 100 can generate a request by invoking the interface corresponding to a service in the application being tested based on a user triggering an action on a control for that service within a certain interface of the application. Electronic device 100 can then send this request to service gateway 200-1, triggering service gateway 200-1 to perform an idempotence test on the interface.

[0063] For example, after receiving the request, the business gateway 200-1 automatically generates a shadow request based on the request. The shadow request is the same as the request, such as the request information of the business carried by the request and the shadow request is the same. Then, the business gateway 200-1 can obtain the execution result of the request and the execution result of the shadow request. For example, the test system may also include a business server 200-2. The business gateway 200-1 and the business server 200-2 may be referred to as a business service system 200. The business gateway 200-1 may send the request and the shadow request to the business server 200-2. The business server 200-2 may execute the request and the shadow request to obtain the execution result of the request and the execution result of the shadow request, and feed it back to the business gateway 200-1. Afterwards, the business gateway 200-1 can obtain the execution result of the request and the execution result of the shadow request.

[0064] After obtaining the execution result of the request and the execution result of the shadow request, service gateway 200-1 can automatically compare the execution results of the request and the shadow request, and determine the idempotence test result of the interface based on the comparison result of the execution results of the request and the shadow request. Service gateway 200-1 can also feedback the idempotence test result of the interface to electronic device 100.

[0065] Specifically, in some embodiments, service gateway 200-1 can generate multiple (e.g., two or more) shadow requests and send them to service server 200-2 for execution. Service gateway 200-1 then compares the execution result of the request with the execution results of the multiple shadow requests to determine the idempotence test result of the interface.

[0066] In this way, there is no need to manually test the idempotence of the interface. The business service system 200 can automatically test the idempotence of the interface, which can improve the efficiency and accuracy of the idempotence test of the interface to a certain extent.

[0067] It is understood that the business server 200-2 may include one or more. Different business servers correspond to different services. For example, the transfer service corresponds to the transfer server, and the payment service corresponds to the payment server. Alternatively, one business server corresponds to different services of an application, for example, the payment service and the transfer service in a payment application correspond to the same business server of the payment application. Different services can be triggered by different requests.

[0068] After receiving the request from electronic device 100, service gateway 200-1 can generate a shadow request and send the request and the shadow request to service server 200-2. For example, service server 200-2 can be the service server corresponding to the service requested in the request. Service server 200-2 corresponding to the service requested in the request then executes the request and the shadow request to obtain the execution results of the request and the shadow request.

[0069] Among them, in other embodiments, such as Figure 1 (b) is illustrated by taking the server 300 as the test device. The test device may also be a module or a combination of modules in the server 300 for implementing interface idempotence testing, which is not specifically limited in this embodiment of the present application.

[0070] like Figure 1 As shown in (b), Figure 1 The electronic device 100 shown in (b) is the same as the above Figure 1 The electronic device shown in (a) is the same as that shown in FIG. 1 and will not be described again here.

[0071] When the application being tested is configured for idempotence testing, electronic device 100 can generate a request by invoking the interface corresponding to a service in the application being tested based on a user's triggering operation on a control for that service in the application's interface. Electronic device 100 can then send this request to server 300, which triggers server 300 to perform an idempotence test on the interface.

[0072] For example, after receiving the request, the server 300 automatically generates a shadow request based on the request. The shadow request is identical to the request, such as carrying the same information as the shadow request. The server 300 can then execute the request and the shadow request to obtain the execution result of the request and the execution result of the shadow request. After the server 300 obtains the execution result of the request and the execution result of the shadow request, it can automatically compare the execution results of the request and the shadow request, and determine the idempotence test result of the interface based on the comparison result of the execution results of the request and the shadow request. The server 300 can also provide feedback on the idempotence test result of the interface to the electronic device 100. Specifically, in some embodiments, the server 300 can generate multiple (e.g., two or more) shadow requests in order to execute these multiple shadow requests. The server 300 then compares the execution result of the request with the execution results of the multiple shadow requests to determine the idempotence test result of the interface.

[0073] That is, the server 300 has both the functions of the business server 200 - 2 and the functions of the business gateway 200 - 1 .

[0074] In this way, there is no need to manually test the idempotence of the interface. The server 300 can automatically test the idempotence of the interface, which can improve the efficiency and accuracy of the idempotence test of the interface to a certain extent.

[0075] The electronic device 100 provided in the embodiments of the present application can be any device that can be installed with an application to be tested. The electronic device 100 provided in the embodiments of the present application can be a computer, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), or other electronic device. The embodiments of the present application do not impose any particular limitations on the specific form of the electronic device 100.

[0076] Take the electronic device 100 as a computer as an example. Figure 2 , which shows a schematic diagram of the structure of a computer provided by an embodiment of the present application. Figure 2 As shown, the computer may include: a processor 110, an internal memory 121, a universal serial bus (USB) interface 130, a display screen 150, an antenna, a communication module 160, an audio module 170, a speaker (i.e., a loudspeaker) 170A, a microphone 170C, an earphone interface 170B, a keyboard 190, and a camera 191, etc.

[0077] It should be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the computer. In other embodiments, the computer may include more or fewer components than shown, or some components may be combined or separated, or arranged differently. The components shown in the illustrations may be implemented in hardware, software, or a combination of software and hardware.

[0078] The processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (AP), a controller, a memory, etc. The different processing units may be independent devices or integrated into one or more processors. In an embodiment of the present application, when the application under test is configured in idempotence test mode, the processor 110 may, based on a user triggering an operation on a control for a service in the interface of the application, call the interface of the application under test corresponding to the service to generate a request, and send the request to another device (e.g., a test device). The request may trigger the test device to perform an idempotence test on the interface.

[0079] The controller is the nerve center and command center of the computer. It can generate operation control signals based on instruction opcodes and timing signals to complete the control of instruction fetching and execution.

[0080] Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly retrieve it from the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

[0081] In some embodiments, the processor 110 may include one or more interfaces, such as a USB interface.

[0082] It is understood that the interface connection relationship between the modules illustrated in this embodiment is merely an illustrative illustration and does not constitute a structural limitation on the computer. In other embodiments, the computer may also adopt a different interface connection method from the above embodiment, or a combination of multiple interface connection methods.

[0083] In some embodiments, the computer's antenna is coupled to the communication module 160, so that the computer can communicate with other devices via wireless communication technology. In this embodiment of the present application, the computer can communicate with the business service system via wireless communication technology.

[0084] The computer can implement a display function through the display screen 150. The display screen 150 is used to display images, videos, etc. In an embodiment of the present application, the display screen 150 can display the interface of an application. The application may include the application being tested. For example, the interface of the application being tested may include controls for various services of the application being tested. When the application is configured in idempotence test mode, the computer can call the interface corresponding to the service to generate a corresponding request in response to a user triggering operation on a control of a certain service, such as a click operation, and then send a request to other devices (such as a test device), wherein the request is used to trigger other devices (such as a test device) to perform an idempotence test on the interface corresponding to the service.

[0085] For example, the application being tested is a shopping app. The interface of a shopping app might include a payment control, such as a payment control, for implementing payment services. When the shopping app is configured in idempotence testing mode, the computer invokes the payment interface to generate a payment request in response to a user clicking the payment control. The payment request is then sent to another device. This payment request triggers the idempotence test of the payment interface on the other device.

[0086] For example, the application under test is a payment application. For example, the payment application's interface may include a control for the payment application's transfer service, such as a transfer control, which is used to implement the transfer service. When the payment application is configured in idempotence testing mode, in response to a user clicking the transfer control, the computer invokes the transfer interface to generate a transfer request and sends the transfer request to another device. This transfer request triggers the other device to perform an idempotence test on the transfer interface.

[0087] Taking the enterprise management application as an example, the interface of the enterprise management application may include a control for saving overtime application information, such as a save control, which is used to implement the overtime application information saving service. When the enterprise management application is configured in idempotency testing mode, in response to a user clicking the save control for overtime application information, the computer may invoke the overtime application information save interface to generate a save request for the overtime application information. This overtime application information save request is also used to trigger other devices to perform idempotency testing of the overtime application information save interface.

[0088] For another example, the interface of an enterprise management application may include a control for applying for overtime work, such as a request control, which is used to implement the overtime application service. When the enterprise management application is configured in idempotency testing mode, in response to a user clicking the overtime application control, the computer invokes the overtime application interface to generate an overtime application request. This overtime application request is used to trigger other devices to perform idempotency testing on the overtime application interface.

[0089] The computer can realize the shooting function through the ISP, the camera 191, the video codec, the GPU, the display 150 and the application processor. The ISP is used to process the data fed back by the camera 191.

[0090] The internal memory 121 can be used to store computer executable program codes, which include instructions. The processor 110 executes the instructions stored in the internal memory 121 to perform various computer functions and data processing.

[0091] The computer can implement audio functions such as music playback and recording through the audio module 170, the speaker 170A, the microphone 170C, the headphone jack 170B, and the application processor.

[0092] The testing apparatus provided in the embodiments of the present application is various devices that can provide an idempotence testing function for an interface.

[0093] Please refer to Figure 3 , which shows a schematic diagram of the structure of a testing device provided in an embodiment of the present application. Figure 3 As shown, the testing device may include one or more processors 240 , a memory 210 , and a communication interface 220 .

[0094] The memory 210, the communication interface 220, and the processor 240 are coupled. For example, the memory 210, the communication interface 220, and the processor 240 can be coupled together via a bus 230. The communication interface 220 is used to transmit data with other devices (e.g., the electronic device 100, or the business server 200-2). Computer program code is stored in the memory 210. The computer program code includes computer instructions. When the computer instructions are executed by the processor 240, the server executes the relevant method steps in the method embodiment of the present application. The processor 240 can be a processor or a controller, such as a central processing unit (CPU).

[0095] In an embodiment of the present application, after the processor 240 receives a request initiated by a call to an interface of the application being tested, a shadow request identical to the request can be automatically generated. The request and the shadow request are used to trigger the execution of the corresponding business. After the business is executed, a corresponding execution result can be generated. Then, the processor 240 can obtain the execution result of the request and the execution result of the shadow request, and automatically compare the execution results. Afterwards, the processor 240 can determine the idempotence test result of the above-mentioned interface based on the comparison result of the execution result of the request and the execution result of the shadow request. In this way, there is no need to manually test the idempotence of the interface. The processor 240 automatically tests the idempotence of the interface, which can greatly improve the test efficiency and accuracy.

[0096] Among them, the structure of the above business server is Figure 3 The results of the test setup shown are similar and will not be described in detail here.

[0097] The following embodiments use the test device as a service gateway as an example to introduce the solution of this application.

[0098] Figure 4 This is a flowchart of a method for testing interface idempotence. Take the electronic device as a computer as an example. Figure 4 As shown, the process includes the following steps:

[0099] 401. In response to a first operation of a user on a control of a service, the computer calls an interface corresponding to the service to generate a first request and sends the first request to a service gateway.

[0100] In some embodiments, an application can be installed on a computer, and the application can be configured to be in idempotence test mode. When the application is configured to be in idempotence test mode, the computer can display the main interface of the application after opening the application in response to a user operation. The computer can display the tested interface of the application in response to the user's operation to open the tested interface of the application. The tested interface of the application can include various controls of the application that allow the tested business. In this way, in response to the user's operation on the control of a certain business, such as the first operation or trigger operation, such as a click operation, the computer calls the interface corresponding to the business to generate a request, such as the first request mentioned above. The first request is used to trigger other devices to perform idempotence testing of the interface corresponding to the business. The first request is also used to trigger other devices to execute the business. See steps 402-408 for details.

[0101] In some embodiments, a browser may be installed on the computer, and the application being tested may also be opened in the browser. Specifically, the user may enter the URL of the application being tested in the browser and perform an operation to open the URL. The computer may respond to the opening operation to open the application being tested. After the electronic device opens the application, the method for opening the application's tested interface and the user's first operation on the service control have been described above and will not be repeated here.

[0102] Taking the payment request above as an example, the computer can send a payment request to the business gateway. Taking the transfer request above as an example, the computer can send a transfer request to the business gateway. Taking the overtime application information save request above as an example, the computer can send a save overtime application information request to the business gateway. Taking the overtime application request above as an example, the computer can send an overtime application request to the business gateway.

[0103] The first request includes service request information. The first request may also include test instruction information of an interface corresponding to the service. The first request may be a Hypertext Transfer Protocol (HTTP) request.

[0104] For example, if the tested application is a shopping application and the first request is a payment request, the service request information carried in the payment request may include information such as the payment amount and payment method. The payment method may include information such as bank card payment or payment by other applications. The test indication information for the interface corresponding to the service may be test indication information for the payment interface corresponding to the payment service.

[0105] For example, if the tested application is a payment application and the first request is a transfer request, the service request information carried in the transfer request may include information such as the transfer amount and information about the account to be transferred. The test indication information for the interface corresponding to the service may be test indication information for the transfer interface corresponding to the transfer service.

[0106] For example, if the tested application is an enterprise management application and the first request is a request to save overtime application information, the service request information carried in the request to save overtime application information may include information such as the overtime time period, the name of the overtime employee, and the content of the overtime work. The test indication information for the interface corresponding to the service may be the test indication information for the interface for saving overtime application information corresponding to the service.

[0107] For example, if the tested application is an enterprise management application and the first request is an overtime application request, the service request information carried by the overtime application request may include information such as the overtime time period, the name of the overtime employee, the content of the overtime work, and the reviewer of the overtime application. The test indication information for the interface corresponding to the service may be the test indication information for the overtime application interface corresponding to the overtime application service.

[0108] 402. Upon receiving the first request, the service gateway copies the first request to obtain a shadow request, wherein the service request information carried in the shadow request is the same as the service request information carried in the first request.

[0109] After receiving the first request, the service gateway can copy it to obtain a shadow request identical to the first request. For example, the shadow request carries the same service request information as the first request. This allows the service gateway to send multiple identical requests to the service server, allowing the service server to execute the same request multiple times, thus testing the idempotence of the interface.

[0110] For example, if the tested application is a shopping application and the first request is a payment request, the service request information carried in the payment request may include information such as the payment amount and payment method. The payment method may include information such as bank card payment or other application payment. Thus, after receiving the payment request, the service gateway can copy the payment request to obtain a corresponding shadow request, such as a shadow payment request. The service request information carried in the shadow payment request is the same as the service request information carried in the payment request. That is, the shadow payment request includes information such as the payment amount and payment method, and the specific values ​​of this information are the same as those in the payment request.

[0111] Since the processing of a request may involve multiple devices (such as service gateways and service servers) and multiple service modules within a device (such as a service server) (see below), Figure 9 and Figure 10 To accurately track and locate issues, a globally unique identifier is required to identify the request. This identifier is passed along as the request moves between multiple devices or multiple service modules within a device. Specifically, the globally unique identifier can be a trace identifier (traceidentity document, traceId). In some embodiments, the service gateway can write the trace identifier into the first request and the shadow request. In this way, both the first request and the shadow request carry the traceId.

[0112] In this embodiment of the present application, traceId ensures that the request can be accurately identified and tracked throughout the entire request processing process, regardless of the number of service nodes (e.g., service gateways, service servers, and service modules within service servers) it passes through. Furthermore, traceId associates the first execution result of the first request with the second execution result of the shadow request, enabling comparison between the first and second execution results. The first and second execution results are described in detail in subsequent step 404.

[0113] 403. The service gateway sends the first request and multiple shadow requests to the service server.

[0114] The shadow request is sent multiple times, such as twice, three times, or more times. In this way, the service gateway can test the idempotence of the interface by sending multiple shadow requests to the service server.

[0115] If the shadow request is sent twice, the service gateway tests the idempotence of the interface with fewer sending times. On the one hand, this reduces the power consumption of the service gateway and the service server in testing the idempotence of the interface, and on the other hand, it improves the efficiency of the service gateway and the service server in testing the idempotence of the interface.

[0116] In some embodiments, the interval between sending multiple shadow requests can be unlimited. For example, taking the example of sending two shadow requests to a service server, the time between sending the shadow requests to the service server, i.e., the interval between the two sending times, can be any time interval.

[0117] In other embodiments, the interval between the sending times of multiple shadow requests is less than a threshold value, for example, the threshold value may be 2 milliseconds, 3 milliseconds, or other values. For example, take sending two shadow requests to the business server with a threshold value of 2 milliseconds as an example. The time between the two shadow requests sent by the business gateway to the business server, that is, the interval between the two sending times, may be less than 2 milliseconds. It is understandable that since the time between the two shadow requests is close, this can simulate a concurrent call scenario and test the idempotence of the interface in a concurrent scenario.

[0118] 404. Upon receiving the first request and multiple shadow requests, the business server executes the first request to obtain a first execution result of the first request, and executes the multiple shadow requests to obtain a second execution result.

[0119] The business server executing multiple shadow requests can also be understood as the business server executing multiple shadow requests. The purpose of executing multiple shadow requests is to verify whether the interface is idempotent. Specifically, if the second execution result after executing multiple shadow requests is consistent with the first execution result of executing the first request once, the interface is determined to be idempotent. If the second execution result after executing multiple shadow requests is inconsistent with the first execution result of executing the first request once, the interface is determined to be non-idempotent.

[0120] In some embodiments, the first execution result includes state information of the service corresponding to the first request stored in a database of the service server, and the state information of the service is referred to as the first state information. The second execution result includes state information of the service corresponding to the shadow request stored in the database of the service server, and the state information of the service is referred to as the second state information.

[0121] The first status information includes completion status information of the business corresponding to the first request, and the second status information includes completion status information of the business corresponding to the shadow request. The completion status information of the business includes whether the business is completed or not completed.

[0122] A key comparison parameter for testing the idempotence of an interface is whether the corresponding business information in the database remains consistent after executing the same request multiple times. To compare whether the corresponding business information in the database changes after executing a request and its corresponding shadow request, two independent data tables can be set up in the database: one data table corresponding to the original request, for example, Data Table 1, and the other data table corresponding to the shadow request, for example, Data Table 2. These two independent data tables (e.g., Data Table 1 and Data Table 2) are pre-configured, that is, they are already set up before executing step 401.

[0123] The data in Data Table 1 can be updated as the business progresses. For details, please refer to the description in the related art and will not be repeated here. Data Table 2 does not store data related to the corresponding business before executing the corresponding business (such as the business corresponding to the shadow request). In this embodiment of the present application, the data in Data Table 1 can be synchronized to Data Table 2 after receiving the first request and the shadow request.

[0124] For example, before the service server receives the first request and the shadow request, the states of Data Table 1 and Data Table 2 can be called the initial state. In the initial state, Data Table 1 stores the initial state information of the service corresponding to the first request. For example, the initial state information of the service corresponding to the first request is: the completion status information of the service corresponding to the first request is: the service is not completed. In the initial state, Data Table 2 does not store any service information.

[0125] Continuing with the example of the tested application being a shopping application and the first request being a payment request, the data table 1 and data table 2 in the initial state can be referred to as shown in Table 1 below. For example, Table 1 shows data table 1 and data table 2 in an initial state.

[0126] Table 1

[0127]

[0128] As shown in Table 1, in the initial state, Data Table 1 includes the information "Order A: Pending Payment," which indicates that the initial status of the payment service corresponding to the payment request (e.g., Order A) is incomplete. Data Table 2 contains no data, meaning that no information about Order A's payment service is stored in Data Table 2.

[0129] After receiving the first request and the shadow request, the service server can synchronize the initial status information of the service corresponding to the first request to Data Table 2 in the following manner: For example, the service server can copy the initial status information of the service corresponding to the first request in Data Table 1 to Data Table 2. The initial status information of the service corresponding to the first request copied to Data Table 2 is referred to as shadow initial status information. The shadow initial status information indicates that the completion status of the service corresponding to the first request (or shadow request) is incomplete. In other words, the shadow initial status information is identical to the initial status information.

[0130] Continuing with the above-mentioned tested application being a shopping application and the first request being a payment request, the data table 1 and the data table 2 after data synchronization are described. For example, Table 2 shows the information in Data Table 1 and Data Table 2 after the information in Data Table 1 is synchronized (or copied).

[0131] Table 2

[0132]

[0133] As shown in Table 2, Data Table 1 includes the information "Order A: Pending Payment." Data Table 2 also includes the information "Order A: Pending Payment," which indicates that the initial status of the payment service (e.g., Order A) corresponding to the payment request (or shadow payment request) is currently uncompleted.

[0134] After completing the synchronization of the data in data table 1 to data table 2, the business server can execute the first request. After completing the execution of the first request, the business server can also update the status information of the business corresponding to the first request recorded in data table 1. For example, the updated business status information is the first status information.

[0135] Continuing with the example of the tested application being a shopping application and the first request being a payment request, after the first request is executed, Data Table 1 and Data Table 2 may be as shown in Table 3. For example, Table 3 shows information of Data Table 1 and Data Table 2 after the first request is executed.

[0136] Table 3

[0137]

[0138] As shown in Table 3, after executing the first request, such as a payment request, Data Table 1 includes the information "Order A: Paid," indicating that the status of the payment service corresponding to the payment request is completed. Data Table 2 includes information that has not been updated, indicating that it still reads "Order A: Pending Payment."

[0139] After executing the first request, the business server can also execute the shadow request multiple times. When the interface corresponding to the business does not have idempotency, the business server will update the status information of the business corresponding to the shadow request recorded in Data Table 2 once after each shadow request is executed. When the interface corresponding to the business has idempotency, the business server will only update the status information of the business corresponding to the shadow request recorded in Data Table 2 once after the first execution of the shadow request, and the business information in Data Table 2 will not be updated for subsequent executions of the shadow request. After executing the shadow request multiple times, the status information of the business saved in Data Table 2 is the above-mentioned second status information.

[0140] Continuing with the example of executing two shadow requests, using the shopping application as the tested application, the first request being a payment request, and the shadow request being a shadow payment request, as an example, if the payment interface is idempotent, after executing the two shadow requests, Data Table 1 and Data Table 2 may be as shown in Table 4. For example, Table 4 shows the information in Data Table 1 and Data Table 2 after executing the two shadow requests.

[0141] Table 4

[0142]

[0143] As shown in Table 4, after executing two shadow requests, such as a shadow payment request, the information included in Data Table 1 is not updated, that is, Order A: Paid is still not available. Data Table 2 includes the information "Order A: Paid", which indicates that the status of the payment transaction corresponding to the shadow payment request is completed.

[0144] It should be noted that the above embodiment illustrates the data update process of database 1 and database 2 by first executing the first request and then executing the shadow request. In other embodiments, the shadow request may be executed first and then the first request, or the first request and the shadow request may be executed simultaneously. This embodiment of the present application does not impose any specific limitations on this.

[0145] After the first request and the shadow request are executed, the service server can obtain, for example, service status information corresponding to the two requests from data table 1 and data table 2, such as the first status information and the second status information.

[0146] In some embodiments, the first execution result also includes response information, which includes the completion status of the business corresponding to the first request. The second execution result also includes response information, which includes the completion status of the business corresponding to the shadow request. In order to distinguish the response information corresponding to the first request and the response information corresponding to the shadow request, the response information corresponding to the first request can be referred to as the first response information, and the response information corresponding to the shadow request can be referred to as the second response information. After the first request and the shadow request are executed, the business server can also generate response information for the two requests, such as the first response information and the second response information mentioned above, and feed it back to the business gateway.

[0147] It is understood that the response information may be a Hypertext Transfer Protocol (HTTP) response message. As an example, an HTTP response message may include a status line, a response header, and a response body. The response header may be followed by a blank line to separate the header (e.g., including the status line and response header) from the response body.

[0148] The Status Line includes the HTTP version, status code (e.g., 200 for success), and status message (e.g., "OK"). For the payment request above, the status code for Order A being paid would be 200.

[0149] Response Headers: Contains metadata about the response, such as content type (Content-Type), content length (Content-Length), business server information (Server), etc.

[0150] Response Body: This is the actual content returned by the business server. This content can be an HTML page, image, video, JSON or XML data, etc. Taking the payment request above as an example, the response body for Order A's payment includes: Payment Status: Success, Payment Amount: ***, Payment Serial Number: ***.

[0151] 405. The service gateway obtains the first execution result and the second execution result from the service server.

[0152] As described above, the first execution result may include first status information. The first execution result may also include first response information. Similarly, the second execution result may include second status information. The second execution result may also include second response information.

[0153] It is understood that when the first request and multiple shadow requests are executed, the service gateway can receive the first response information and the second response information fed back from the service server. After receiving the first response information and the second response information, the service gateway can obtain the first status information and the second status information stored in the data table of the service server from the service server.

[0154] Since the first execution result includes the first status information stored in the database of the business server, and the second execution result includes the second status information stored in the database of the business server, it is convenient for subsequent steps to automatically compare the database data changes caused by the original request and the shadow request to verify whether multiple requests will have additional impact on the database of the business server, that is, to verify whether the corresponding interface has idempotence.

[0155] 406. The service gateway determines whether the interface has idempotence based on the first execution result and the second execution result.

[0156] As you can understand, after the service server executes the first request and obtains Execution Result 1, to ensure that the service is not executed repeatedly, if the service server determines that the service has been completed based on the information in Execution Result 1, it will not execute the service again, nor will it change Execution Result 1. Therefore, if executing the second request does not change the execution result after the first request, it means that the interface corresponding to the service is idempotent.

[0157] After the business server executes the first request, it obtains execution result 1. If the business is executed again for some reason, the execution result 1 will be changed. Therefore, if the execution result of the first request is changed after the second request is executed, it means that the interface corresponding to the business is not idempotent.

[0158] Based on the above principles, the first execution result after the execution of the first request can be used as reference data and compared with the execution results obtained after executing the shadow request multiple times, such as the second execution result, to determine whether the interface corresponding to the business has idempotence. Take the execution of two shadow requests as an example. If the execution of the second shadow request does not change the execution result after the execution of the first shadow request, the execution result after the execution of the second shadow request will be the same as the execution result 1 in the reference data, which means that the interface corresponding to the business has idempotence. If the execution of the second shadow request changes the execution result 1 after the execution of the first shadow request, the execution result after the execution of the second shadow request will be different from the execution result 1 in the reference data, which means that the interface corresponding to the business does not have idempotence.

[0159] Specifically, in some embodiments, taking as an example a case where the first execution result includes status information of a service corresponding to a first request stored in a database, such as first status information, and response information corresponding to the first request, such as first response information; and the second execution result includes status information of a service corresponding to a shadow request stored in a database, such as second status information, and response information corresponding to the shadow request, such as second response information, the service gateway determines that the interface has idempotence when it determines that the first status information and the second status information stored in the database of the service server are the same, and the first response information and the second response information are the same.

[0160] In this way, the business gateway can automatically compare the execution results of multiple requests to see if they are consistent, eliminating the need for manual comparison and significantly improving testing efficiency and accuracy.

[0161] Continuing with the example of the application being tested as a shopping application, the first request being a payment service, such as a payment request for order A, and the interface being a payment interface, how to determine whether an interface has idempotency is explained. If the information on the completion status of order A in data table 1 is the same as the information on the completion status of order A in data table 2, and the content of the response information corresponding to the payment request is the same as the content of the response information corresponding to the shadow payment request, then the payment interface is determined to have idempotency. If the information on the completion status of order A in data table 1 is different from the information on the completion status of order A in data table 2 and / or the content of the response information corresponding to the payment request is different from the content of the response information corresponding to the shadow payment request, then the payment interface is determined to have no idempotency.

[0162] The first execution result and the second execution result may be different in the following cases:

[0163] 1. The second state information stored in the data table of the business server is different from the first state information, and the second response information is the same as the first response information.

[0164] 2. The second state information stored in the data table of the business server is different from the first state information, and the second response information is different from the first response information.

[0165] 3. The second state information stored in the data table of the business server is different from the first state information, and the second response information is different from the first response information.

[0166] When the first execution result is different from the second execution result, it is determined that the interface does not have idempotence.

[0167] In some embodiments, comparing the first response information and the second response information may refer to comparing the status code and / or response body information in the status line of the first response information and the status code and / or response body information in the status line of the second response information.

[0168] 407. The business gateway sends the test result of whether the interface has idempotency to the computer.

[0169] If the service gateway determines that the interface is idempotent, the service gateway sends the test result of the interface being idempotent to the computer. If the service gateway determines that the interface is not idempotent, the service gateway sends the test result of the interface not being idempotent to the computer.

[0170] 408. Test results of whether the computer output interface has idempotency.

[0171] In some embodiments, the computer can display the test results of whether the interface has idempotency in text form on the application interface. For example, Figure 5 A schematic diagram of a computer interface showing test results of an interface with idempotence. Figure 5 As shown, the computer may display on interface 101: Interface idempotency verification is successful, which is used to indicate that the interface corresponding to the tested business has idempotency.

[0172] For example, Figure 6 A schematic diagram of a computer interface showing a test result of an interface not having idempotency. Figure 6 As shown, the computer may display on interface 101: "Interface idempotency verification failed," indicating that the interface corresponding to the tested service does not have idempotency. The computer may also display a prompt message on interface 101: "Please query the database for details." The trace identifier in the trace table is: 8d4e7b2f. The traced value of 8d4e7b2f in the trace table indicates that during the idempotency verification test, the traced value of the request generated by calling the tested interface and the shadow request of that request is 8d4e7b2f. Based on the traced value of 8d4e7b2f, the idempotency test results of the interface corresponding to the traced value can be queried, as well as related execution results, such as response information and service status information.

[0173] In some embodiments, the computer may display an idempotency verification list including idempotency test results of multiple service-corresponding interfaces of the tested application and a search condition option for filtering idempotency test results of interfaces that meet certain conditions.

[0174] Search criteria options include, but are not limited to, idempotency, start and end time options, and traceld / URL options. The idempotency option includes idempotency and non-idempotency. The idempotency option filters test results for idempotent interfaces, while the non-idempotency option filters test results for non-idempotent interfaces. The start and end time options filter test results for idempotency of the tested interfaces between the start and end times entered by the user. The traceld / URL (Uniform Resource Locator) option filters idempotency test results for interfaces that use traceld or URLs, if the user enters a traceld or uniform resource locator.

[0175] After the user selects the search criteria to be searched in the idempotence verification list, the user can query the idempotence test results of the interfaces that meet the search criteria selected by the user, which provides a high user experience.

[0176] For example, Figure 7 FIG. 1 shows a schematic diagram of a computer interface that displays an idempotence verification list. Figure 7 As shown, the computer displays interface 102, which includes an idempotency verification list. The idempotency verification list includes an idempotency option, a start time and end time option, a Traceld / URL option, a search control, a reset control, and idempotency test results of interfaces that meet the aforementioned setting conditions (for example, whether the idempotency option is set to all). The idempotency test results include detailed information on Traceld, request URL, request time, and idempotency.

[0177] The idempotence verification list also includes an operable view details control. In response to a user's operation on the view details control, the computer can expand a details page that includes the execution results of the request and the execution results of the shadow request. It is understood that in some embodiments, the user's operation on the view details control can be, but is not limited to, clicking the view details control.

[0178] For example, Figure 8 A schematic diagram of a details page is shown. Figure 8 As shown, the computer displays an interface 103, which includes the execution result of the request and the execution result of the shadow request. The execution result includes the response information of the request and the business information corresponding to the request stored in the database.

[0179] exist Figure 8In the example, the first response to the first request and the second response to the shadow request are identical. The first "status" indicates the payment service status, i.e., the completion of the payment service. "success" indicates that the payment has been completed, and "orderID" indicates the identifier of the order table. The second "status" indicates the order processing status, which includes at least "processed" and "unprocessed." "completed" indicates that the order has been processed.

[0180] As you can understand, a table is a collection of structured data consisting of rows and columns. In a table, each row represents a record. Each row includes a field name and a field, with the field being the actual data associated with the field name. A primary key is one or more fields in a table whose value uniquely identifies a record.

[0181] Table 1 contains the field names and values ​​for the order table (t-order) and the payment table (t-order-payment). The order table has an id field with a value of 12345. The order table has an order-status field with a value of pending. The payment table has a payment-status field with a value of unpaid.

[0182] Among them, id indicates identification information, Order-status indicates order status, pending indicates unprocessed, payment-status indicates payment status, and unpaid indicates unpaid.

[0183] Table 2 contains the field names and values ​​for the order table (t-order) and the payment table (t-order-payment). The order table has an id field with a value of 12345. The order table has an order-status field with a value of completed. The payment table has a payment-status field with a value of paid.

[0184] Among them, completed means processed, and paid means paid.

[0185] The above example shows that the interface is not idempotent because the order status in data table 1 is not processed and the payment status of the order is unpaid, while the order status in data table 2 is processed and the payment status of the order is paid. The completion status of the payment business in the database is different.

[0186] It can be understood that the above is only an example of the first execution result of the first request and the second execution result of the shadow request, and the forms of the first execution result and the second execution result are not limited thereto.

[0187] In some embodiments, the computer may display the test result of whether the interface has idempotency in text form on the application interface, or may broadcast the test result of whether the interface has idempotency to the user in voice form.

[0188] The following is a detailed introduction to the structure of a service gateway and service server for implementing interface idempotence testing. For example, Figure 9 FIG1 shows a schematic diagram of the structure of a service module of a service gateway and a service server provided by an embodiment of the present application. Figure 9 As shown, the service gateway includes a module 200-11 for copying requests, a module 200-12 for comparing response information, and a module 200-13 for comparing service status information.

[0189] The copy request module 200-11 is used to copy the first request to obtain a shadow request when receiving the first request sent by the electronic device 100. The relevant technology of the shadow request has been described above and will not be repeated here.

[0190] The module 200 - 12 for comparing response information is used to compare the first response information of the first request and the second response information of the shadow request fed back by the business server to determine whether the two pieces of information are consistent.

[0191] The module 200-13 for comparing the status information of the business is used to compare the first status information of the business corresponding to the first request and the second status information of the business corresponding to the shadow request in the database 200-22 to determine whether the two pieces of information are consistent.

[0192] If the service gateway determines that the above two pieces of information are consistent, it determines that the interface is idempotent.

[0193] The server includes a business module 200 - 21 and a database 200 - 22 .

[0194] Among them, the business module 200-21 is used to execute the first request and the shadow request. The database 200-22 includes a data table 1 and a data table 2, and the data table 1 and the data table 2 are independent data tables. Before the business module 200-21 executes the first request and the shadow request, the business server synchronizes the initial state information of the business corresponding to the first request in the data table 1 to the data table 2. After the business module 200-21 executes the first request and the shadow request, the initial state information of the business in the data table 1 and the data table 2 are updated respectively, and the initial state information of the business in the data table 1 is updated to the first state information, and the initial state information of the business in the data table 2 is updated to the second state information. The first state information and the second state information have been described in the previous text and will not be repeated here.

[0195] The following specifically introduces another structure of a service gateway and service server for implementing interface idempotence testing. For example, Figure 10 FIG1 shows a schematic diagram of the structure of a service module of a service gateway and a service server provided by an embodiment of the present application. Figure 10 As shown, in Figure 9 Based on the structure of the service gateway in FIG, the service gateway further includes a tracking identifier generation module 200-14. The tracking identifier generation module 200-14 is configured to generate a tracking identifier upon receiving a first request sent by the electronic device 100, and send the first request and the tracking identifier of the first request to the copy request module 200-11. After copying the first request to obtain a shadow request, the copy request module 200-11 writes the tracking identifier into the first request and the shadow request identifier. The tracking identifier has been introduced above and will not be repeated here.

[0196] like Figure 10 As shown, in Figure 9 Based on the structure of the business server in the example, the business module 200 - 21 includes a filter 200 - 211 , an interceptor 200 - 212 and an information collection module (Context) 200 - 213 .

[0197] Filters 200 - 211 are used to manage the execution and feedback of requests and map the tracking identifiers to the first request and the shadow request to data table 3 .

[0198] Specifically, filters 200-211 are configured to, upon receiving a first request and a shadow request, determine whether to continue processing the first request and the shadow request. For example, if the first request does not comply with certain security rules, filters 200-211 may refuse to process the first request. If the shadow request does not comply with certain security rules, filters 200-211 may refuse to process the shadow request.

[0199] Filters 200-211 are configured to, upon receiving a first response to a first request and a second response to a shadow request, determine whether to feed the first and second responses to the service gateway. For example, if the first response does not comply with certain security rules, filters 200-211 may refuse to feed the first response to the service gateway. If the shadow response does not comply with certain security rules, filters 200-211 may refuse to feed the shadow response to the service gateway.

[0200] Information collection modules 200-213 store information that facilitates sharing and calling between different modules in the service server. For example, information collection modules 200-213 may store whether the service interface corresponding to the first request has been tested for idempotence, as well as the mapping between the first request, the service interface, and the tracking identifier.

[0201] Interceptors 200-212 are used to switch the data table of the current operation (such as query, update, insert, etc.) to the target data table to perform operations on the target data table. For example, the data table of the current operation (such as query, update, insert, etc.) is data table 1. When the preset conditions are met, the target data table becomes data table 2, and data table 1 is switched to data table 2 to perform corresponding operations (such as update, insert, etc.) on data table 2. The preset conditions are: the first request is a shadow first request, and the operation on data table 2 is an update or insert operation. The update operation can refer to the operation of synchronizing the initial status information of the business in data table 1 to data table 2 as mentioned above, or it can refer to the operation of updating the initial status information of the business in data table 1 after executing the first request, and it can refer to the operation of updating the initial status information of the business in data table 2 after executing the first shadow request.

[0202] In the process of executing the first request, the interceptor 200-212 is also used to cache the name of the data table being operated and the unique identifier (Identification, ID) generated by updating the fields in certain (such as one or more) records in the data table in the information collection module 200-213. Herein, the ID is used to distinguish different records. Updating the fields in certain records in the data table refers to updating the status information of the business in the previous text. After executing the first request, the interceptor (Interceptor) 200-212 is used to store the name of the data table being operated and the ID generated by updating the fields in certain records in the data table in the data table 3. For example, after executing the first request, the fields in certain records in the data table are updated, and the first status information is composed of the one or more records.

[0203] Similarly, after executing the shadow request, interceptors 200-212 are configured to store the name of the operated data table and the IDs generated by updating fields in certain records in the data table in data table 3. After executing the shadow request, interceptors 200-212 are further configured to store the name of the operated data table and the IDs generated by updating fields in certain records in the data table in data table 3. For example, after executing the second shadow request, fields in certain records in the data table are updated, and the one or more records constitute the second state information.

[0204] In some embodiments, the interceptors 200-212 may be Mybatis interceptors.

[0205] Since data table 3 stores the ID of the first state information and the ID of the second state information, module 200-13 for comparing the state information of the service can obtain the first state information from data table 1 based on the ID of the first state information, and obtain the second state information from data table 2 based on the ID of the second state information, and then compare whether the first state information and the second state information are equal. The service gateway can obtain the first comparison result of the first response information and the second response information from module 200-12 for comparing the response information, and obtain the second comparison result of the first state information and the second state information from module 200-13 for comparing the state information of the service, and determine whether the service interface is idempotent based on the first comparison result and the second comparison result. The technology for determining whether the service interface is idempotent based on the first comparison result and the second comparison result has been introduced in the previous article and will not be repeated here.

[0206] In the embodiment of the present application, there is no need to manually test the idempotence of the interface. The business service system 200 can automatically test the idempotence of the interface, which can improve the efficiency and accuracy of the interface idempotence test to a certain extent.

[0207] An embodiment of the present application also provides a computer storage medium, which includes computer instructions. When the computer instructions are executed on the above-mentioned electronic device 100 or a computing device such as a test device, the electronic device 100 or a computing device such as a test device executes the above-mentioned corresponding steps.

[0208] An embodiment of the present application further provides a computer program product, which, when executed on a computing device such as the electronic device 100 or a test apparatus, enables the electronic device 100 or a computing device such as a test apparatus to execute the corresponding steps described above.

[0209] It is understandable that the terminal device provided in the embodiment of the present application includes a hardware structure and / or software module for performing each function in order to realize the above functions. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiment disclosed herein, the embodiment of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software driven hardware manner depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the embodiment of the present application.

[0210] The embodiment of the present application can divide the functional modules of the terminal device according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical functional division. In actual implementation, there may be other division methods.

[0211] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0212] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0213] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0214] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0215] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program code.

[0216] The above content is only a specific embodiment of this application, but the scope of protection of this application is not limited to this. Any changes or replacements within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for testing interface idempotence, characterized in that: The method is applied to a testing device and comprises: Receive a first request, where the first request is used to request idempotence of an interface corresponding to a service provided by a test application, and the first request carries request information of the service; generating a shadow request based on the first request, where the request information of the service carried by the shadow request is the same as the request information of the service carried by the first request; Obtain a first execution result and a second execution result, the first execution result being an execution result obtained after executing the business based on the request information carried by the first request, and the second execution result being an execution result obtained after executing the business multiple times based on the request information carried by the shadow request; the first execution result includes first status information of the business after executing the business based on the first request, and the first status information is stored in a first data table of the business server; the first status information is status information after the initial status information of the business stored in the first data table is updated after the business is executed based on the first request; the second execution result includes second status information of the business after executing the business based on the shadow request, and the second status information is stored in a second data table of the business server; the second status information is status information after the initial status information of the business stored in the second data table is updated after the business is executed multiple times based on multiple shadow requests; the second data table does not include status information of the business in the initial state, and the initial status information of the business stored in the second data table is synchronized based on the initial status information in the first data table; Determining whether the interface has idempotence based on the first execution result and the second execution result; In which, when the first execution result is the same as the second execution result, the interface has idempotency; when the first execution result is different from the second execution result, the interface does not have idempotency.

2. The method according to claim 1, characterized in that The first execution result includes first response information; the second execution result includes second response information; When the first state information and the second state information are the same, and the first response information and the second response information are the same, the first execution result and the second execution result are the same; When the first state information and the second state information are different, and / or the first response information and the second response information are different, the first execution result and the second execution result are different.

3. The method according to claim 1 or 2, characterized in that The obtaining of the first execution result and the second execution result includes: Sending the first request to the service server and sending the shadow request multiple times; The first execution result and the second execution result are received from the service server.

4. The method according to claim 3, characterized in that The shadow request is sent twice.

5. The method according to claim 4, characterized in that The time interval between two adjacent sending of the shadow requests is less than a threshold.

6. The method according to claim 1 or 2, characterized in that The obtaining of the first execution result and the second execution result includes: executing the first request to obtain the first execution result; Execute the shadow request multiple times to obtain the second execution result.

7. The method according to claim 6, characterized in that The shadow request is executed twice.

8. A method for testing interface idempotence, characterized in that: The method is applied to a service server, the service server including a first data table and a second data table, the first data table storing initial status information of the service, and the second data table not including status information of the service, including: Receive a first request and multiple shadow requests sent by a test device; the first request is used to request the idempotence of an interface corresponding to a service provided by a test application, the first request carries request information of the service, the shadow requests carry request information of the service, and the request information of the service carried by the shadow requests is the same as the request information of the service carried by the first request; Synchronizing the initial state information in the first data table to the second data table; Execute the business based on the request information of the business carried by the first request to obtain a first execution result, and execute the business multiple times based on the request information of the business carried by the multiple shadow requests to obtain a second execution result; the first execution result includes first status information of the business after executing the business based on the first request, and the first status information is stored in the first data table of the business server; the first status information is status information after the initial status information of the business stored in the first data table is updated after the business is executed based on the first request; the second execution result includes second status information of the business after executing the business based on the shadow request, and the second status information is stored in the second data table of the business server; the second status information is status information after the initial status information of the business stored in the second data table is updated after the business is executed multiple times by the multiple shadow requests; A first execution result and a second execution result are sent to the test device; wherein the first execution result and the second execution result are used to determine whether the interface has idempotence.

9. The method according to claim 8, characterized in that The first execution result includes first response information; the second execution result includes second response information.

10. A method for testing interface idempotence, characterized in that: The method is applied to a test system, the test system including a test device and a service server, the service server including a first data table and a second data table, the first data table storing initial status information of the service, and the second data table not including status information of the service, including: The testing device receives a first request, where the first request is used to request idempotence of an interface corresponding to a service provided by a test application, and the first request carries request information of the service; The testing device generates a shadow request based on the first request, where the request information of the service carried by the shadow request is the same as the request information of the service carried by the first request; The testing device sends the first request to the business server and sends the shadow request multiple times; The business server synchronizes the initial status information in the first data table to the second data table; The business server executes the business based on the received first request carrying the request information of the business, obtains a first execution result, and executes the business multiple times based on the received multiple shadow requests carrying the request information of the business, The service server sends a first execution result and a second execution result to the testing device; The testing device determines whether the interface has idempotence based on the first execution result and the second execution result; Among them, when the first execution result is the same as the second execution result, the interface has idempotence; when the first execution result is different from the second execution result, the interface does not have idempotence; the first execution result includes the first status information of the business after the business is executed based on the first request, and the first status information is stored in the first data table of the business server; the first status information is the status information after the initial status information of the business stored in the first data table is updated after the business is executed based on the first request; the second execution result includes the second status information of the business after the business is executed based on the shadow request, and the second status information is stored in the second data table of the business server; the second status information is the status information after the initial status information of the business stored in the second data table is updated after the business is executed multiple times based on multiple shadow requests.

11. A computing device, characterized in that The computing device includes at least a memory and one or more processors; the memory is used to store computer instructions, and when the one or more processors execute the computer instructions, the computing device executes the method as described in any one of claims 1 to 7, or the computing device executes the method as described in any one of claims 8-10.

12. A computer-readable storage medium, characterized in that The method comprises computer instructions, which, when executed on a computing device, cause the computing device to execute the method according to any one of claims 1 to 7, or cause the computing device to execute the method according to any one of claims 8 to 10.

13. A computer program product, characterized in that When the computer program product is run on a computing device, the computing device is caused to execute the method according to any one of claims 1 to 7, or the computing device is caused to execute the method according to any one of claims 8 to 10.

Images