Test methods, mock frameworks, user devices, service devices, and storage media

Abstract

Embodiments of the present application provide a test method, a Mock framework, a user equipment, a service equipment and a storage medium, and are applied to the user equipment. The method comprises the following steps: sending an authentication request containing a user parameter and a uniform address locator (URL) parameter to the service equipment, wherein the user parameter and the URL parameter both contain a target character; receiving an authentication parameter returned by the service equipment based on the URL parameter; and performing consistency comparison on the URL parameter and the authentication parameter according to the target character, and determining a test result. In this way, in asynchronous callback interface testing, the consistency comparison on the URL parameter and the authentication parameter can quickly determine whether the current test is successful, thereby improving the test efficiency.

Description

Technical Field

[0001] This application relates to the field of behavioral software testing technology, and in particular to a testing method, a mock framework, a user device, a service device, and a storage medium. Background Technology

[0002] The testing process provided by related technologies first involves sending a test request to the object under test (AUT), then waiting for the AUT to process the request and return a result. A consistency comparison is then performed based on the returned result to determine whether the AUT meets business requirements. However, the consistency comparison process in these technologies is quite complex, reducing the overall efficiency of the testing process. Summary of the Invention

[0003] This application provides a testing method, a mock framework, a user device, a service device, and a storage medium that can quickly achieve consistency comparisons during the testing process, thereby improving testing efficiency.

[0004] The technical solution of this application is implemented as follows:

[0005] In a first aspect, embodiments of this application provide a testing method applied to a user equipment, the method comprising:

[0006] Send an authentication request containing user parameters and a Uniform Address Locator (URL) parameter to the service device, where both the user parameters and the URL parameter contain the target character;

[0007] Based on the URL parameters, receive the authentication parameters returned by the service device;

[0008] The test result is determined by comparing the URL parameters and authentication parameters based on the target characters.

[0009] Secondly, embodiments of this application provide a testing method applied to a service device, the method comprising:

[0010] Receive authentication requests sent by user equipment containing user parameters and URL parameters, where both user parameters and URL parameters contain target characters;

[0011] Based on the target character in the user parameters, obtain the authentication parameters;

[0012] Based on the URL parameters, authentication parameters are sent to the user device so that the user device can determine the test result.

[0013] Thirdly, embodiments of this application provide a Mock framework for deploying virtual devices, and the Mock framework includes an interface manager and a class loader; wherein,

[0014] The interface manager is used to receive interface increment instructions and generate interface increment code based on the interface increment instructions.

[0015] The class loader is also used to load incremental interface code to enable incremental processing of the virtual device interface.

[0016] Fourthly, embodiments of this application provide a user equipment, which includes a first transmitting unit, a first connecting unit, and a comparison unit; wherein,

[0017] The first sending unit is configured to send an authentication request containing user parameters and a Uniform Address Locator (URL) parameter to the service device, wherein both the user parameters and the URL parameter contain target characters.

[0018] The first receiving unit is configured to receive authentication parameters returned by the service device based on URL parameters;

[0019] The comparison unit is configured to perform a consistency comparison between URL parameters and authentication parameters based on the target characters to determine the test result.

[0020] Fifthly, embodiments of this application provide a user equipment, which includes a first memory and a first processor; wherein,

[0021] The first memory is used to store computer programs that can run on the processor;

[0022] A first processor is configured to perform the steps of the method as described in the first aspect when running a computer program.

[0023] Sixthly, embodiments of this application provide a service device, which includes a second receiving unit, an acquiring unit, and a second transmitting unit; wherein,

[0024] The second receiving unit is configured to receive an authentication request sent by a user equipment containing user parameters and URL parameters, wherein both the user parameters and the URL parameters contain target characters.

[0025] The acquisition unit is configured to retrieve authentication parameters based on the target characters in the user parameters.

[0026] The second sending unit is configured to send authentication parameters to the user equipment based on URL parameters, so that the user equipment can determine the test result.

[0027] In a seventh aspect, embodiments of this application provide a service device, which includes a second memory and a second processor; wherein,

[0028] The second memory is used to store computer programs that can run on the processor;

[0029] A second processor is configured to perform the steps of the method as described in the second aspect when running a computer program.

[0030] Eighthly, embodiments of this application provide a computer storage medium storing a computer program that, when executed by a first processor, implements the steps of the method described in the first aspect, or when executed by a second processor, implements the steps of the method described in the second aspect.

[0031] This application provides a testing method, a mock framework, a user device, a service device, and a storage medium. On the user device side, an authentication request containing user parameters and a Uniform Address Locator (URL) parameter is sent to the service device, where both user parameters and URL parameters contain target characters. Based on the URL parameter, the authentication parameters returned by the service device are received. A consistency comparison is performed between the URL parameter and the authentication parameter based on the target characters to determine the test result. On the service device side, an authentication request containing user parameters and URL parameters is received from the user device, where both user parameters and URL parameters contain target characters. Authentication parameters are obtained based on the target characters in the user parameters. Authentication parameters are sent to the user device based on the URL parameter, enabling the user device to determine the test result. Thus, in asynchronous callback interface testing, a consistency comparison between the URL parameter and the authentication parameter allows for rapid determination of test success, thereby improving testing efficiency. Furthermore, the mock framework is used to deploy virtual devices and includes an interface manager and a class loader. The interface manager receives interface increment instructions and generates interface increment code based on these instructions. The class loader loads the interface increment code to implement incremental interface processing for the virtual device. In this way, when deploying virtual devices using the Mock framework, the interface manager can be used to easily make incremental modifications to the interfaces in the virtual device, reducing the workload of incremental interface modifications. Attached Figure Description

[0032] Figure 1 A flowchart illustrating a testing method provided in an embodiment of this application;

[0033] Figure 2 A flowchart illustrating another testing method provided in an embodiment of this application;

[0034] Figure 3 This application provides an embodiment of a test system with an interactive process diagram.

[0035] Figure 4 A flowchart illustrating another testing method provided in an embodiment of this application;

[0036] Figure 5A schematic diagram illustrating the composition of a Mock framework provided in an embodiment of this application;

[0037] Figure 6 A schematic diagram illustrating the composition of another Mock framework provided in an embodiment of this application;

[0038] Figure 7 This is a schematic diagram of the composition structure of a user equipment provided in an embodiment of this application;

[0039] Figure 8 This is a schematic diagram of the hardware structure of a user equipment provided in an embodiment of this application;

[0040] Figure 9 This is a schematic diagram of the composition structure of a service device provided in an embodiment of this application;

[0041] Figure 10 This is a schematic diagram of the hardware structure of a service device provided in an embodiment of this application. Detailed Implementation

[0042] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It is understood that the specific embodiments described herein are merely for explaining the relevant application and not for limiting the application. Furthermore, it should be noted that, for ease of description, only the parts relevant to the application are shown in the accompanying drawings.

[0043] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0044] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0045] It should be noted that the terms "first, second, and third" used in the embodiments of this application are only used to distinguish similar objects and do not represent a specific order of objects. It is understood that "first, second, and third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0046] Before providing a further detailed description of the embodiments of this application, the nouns and terms used in the embodiments of this application will be explained. The nouns and terms used in the embodiments of this application shall be interpreted as follows:

[0047] Java: A computer programming language.

[0048] Jar: A software package file format typically used to aggregate a large number of Java class files, related metadata, and resource files (text, images, etc.) into a single file for developing Java platform applications or libraries.

[0049] FreeMarker: A template engine: a general-purpose tool that uses templates and data to be modified to generate output text. Developers can use FreeMarker to embed components of the products they develop.

[0050] Mock: A mock data generator that creates a mock object to simulate the behavior of objects that are not easy to construct or obtain.

[0051] Spring Cloud: A cloud application development tool that can be used to develop mock applications.

[0052] Servlet: A program that runs on a server and provides a unified specification for web applications for Java programs.

[0053] Tomcat: A Servlet container.

[0054] Lib (Library): Data warehouse.

[0055] RESTful specification: a specification for internet software architecture.

[0056] Restful Class Loader: A class loader that conforms to the Restful specification.

[0057] URL (Uniform Resource Locator): A Uniform Resource Locator used to specify a representation of the location of information.

[0058] backUrl: The URL to jump back to.

[0059] token: The token is the authentication parameter in the embodiments of this application.

[0060] total: Used to indicate the count value of the counter.

[0061] Assertions: In programming, assertions are a type of first-order logic placed in a program to indicate and verify the results expected by the program developer.

[0062] It's understandable that many software programs choose asynchronous calls to execute tasks in order to improve processing efficiency. In asynchronous calls, after the first thread calls the second thread through an interface, the first thread does not need to wait for the second thread to return the result, but can directly process other tasks. When the second thread finishes processing and needs to return the processing result to the first thread, it will call back the interface of the first thread again. This interface is also called the asynchronous callback interface (or asynchronous call interface, asynchronous interface, etc.).

[0063] Among these, testing asynchronous callback interfaces is a crucial aspect. One related technology involves blocking the test thread using a thread blocking object when testing asynchronous interfaces, waiting for the asynchronous interface to be tested and asserted. Another related technology discloses an automated solution that divides test cases into test cases and assertion cases. After a test case completes execution, it is stopped. Following the stop of the test case, corresponding assertion case execution conditions are established. When these conditions are met, the corresponding assertion case is executed, thereby determining the state of the object under test.

[0064] However, none of the above testing methods provide a specific way to judge the consistency of information after asynchronous processing, which makes the testing methods for asynchronous API calls still insufficient.

[0065] Based on this, this application provides a testing method. The basic idea of ​​this method is as follows: An authentication request containing user parameters and a Uniform Address Locator (URL) parameter is sent to a service device, where both the user parameters and the URL parameter contain target characters. Based on the URL parameter, the authentication parameters returned by the service device are received. A consistency comparison is performed between the URL parameter and the authentication parameter based on the target characters to determine the test result. On the service device side, an authentication request containing user parameters and a URL parameter is received from a user device, where both the user parameters and the URL parameter contain target characters. Authentication parameters are obtained based on the target characters in the user parameters. The authentication parameters are then sent to the user device based on the URL parameter, enabling the user device to determine the test result. In this way, in asynchronous callback interface testing, by performing a consistency comparison between the URL parameter and the authentication parameter, the success of the test can be quickly determined, thereby improving testing efficiency.

[0066] In addition, during program debugging and testing, it is often necessary to use mock technology to simulate some devices (such as servers, databases, or systems that are not yet designed) and their interfaces, so as to complete the testing process using the interfaces of the virtual devices. However, in related technologies, if it is desired to modify the interface of the virtual device, the entire virtual device needs to be modified, which is a large workload and a complex process.

[0067] Based on this, this application also provides a Mock framework. The basic idea of ​​this method is that the Mock framework is used to deploy virtual devices, and the Mock framework includes an interface manager and a class loader. The interface manager is used to receive interface increment instructions and generate interface increment code based on these instructions. The class loader is also used to load the interface increment code to implement incremental interface processing for the virtual device. Thus, when deploying a virtual device using the Mock framework, the interfaces in the virtual device can be easily modified incrementally through the interface manager, reducing the workload of interface modification.

[0068] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0069] In one embodiment of this application, see Figure 1 The diagram illustrates a flowchart of a testing method provided in an embodiment of this application. Figure 1 As shown, the method may include:

[0070] S101: Send an authentication request to the service device containing user parameters and a Uniform Address Locator (URL) parameter, wherein both the user parameters and the URL parameter contain the target character.

[0071] It should be noted that the testing method provided in this application embodiment is applied to user equipment, which can be various terminal devices, such as personal digital assistant (PDA), wireless communication terminal, smartphone, audio equipment, television, projector, smart home device, portable multimedia player (PMP), etc. This application embodiment does not impose any limitations.

[0072] Furthermore, embodiments of this application also relate to a service device, which is a device capable of processing authentication requests from user devices. For example, a user device may be a client application with a certain application installed, and a service device may be a server application with a certain application installed.

[0073] In this embodiment, the user equipment can send an authentication request to the service equipment to obtain authentication parameters for different users. Specifically, the authentication request includes user parameters and URL parameters. The user parameters specify which user's authentication parameters the user equipment needs, while the URL parameters inform the service equipment of the address where the authentication parameters will be returned.

[0074] It should also be noted that in this embodiment, both user parameters and URL parameters contain target characters. Here, the meaning of the target characters includes, but is not limited to, the following possibilities:

[0075] (1) A specific character combination: if the specific character combination appears in both parameters, then the two parameters are considered to contain the same characteristic character.

[0076] (2) A specific character combination must appear in a specific parameter position. For example, the character combination consisting of the last N characters must be a specific character combination, and the character combination consisting of the middle N characters must be a specific character combination. In other words, only when the two parameters each have a specific character combination in the specified parameter position will the two parameters be considered to contain the same target character.

[0077] In this testing method, the service device can determine the corresponding authentication parameters based on the user parameters in the authentication request; then, based on the URL parameters in the authentication request, it returns the authentication parameters to the user device, and the user device determines whether the authentication request was successfully executed based on the authentication parameters.

[0078] S102: Receive authentication parameters returned by the service device based on URL parameters.

[0079] It should be noted that in actual business operations, the mapping relationship between authentication parameters and user parameters may be pre-stored or generated according to a certain business rule. However, during testing, it is not necessary to strictly adhere to the mapping relationship between authentication parameters and user parameters. Therefore, in this embodiment of the application, to facilitate the determination of test results, the following authentication parameter generation rule is designed: authentication parameters are generated based on user parameters, and the generated authentication parameters have the same characteristic characters as the user parameters. That is to say, under normal working conditions, URL parameters, user parameters, and authentication parameters all have the same target characters.

[0080] It should also be noted that the service device needs a certain amount of time to complete the authentication request, so the authentication request can be designed as an asynchronous process. Therefore, in some implementations, the URL parameter is used to indicate the first asynchronous call interface; the method of receiving authentication parameters sent by the service device based on the URL parameter may further include:

[0081] When the first asynchronous call interface is detected to be invoked, the authentication parameters sent by the service device are received through the first asynchronous call interface.

[0082] It should be noted that after the user equipment sends the first authentication request to the service equipment, the user equipment can perform other tasks; after the service equipment obtains the authentication parameters corresponding to the authentication request, it calls back the user equipment's first asynchronous API based on the URL parameters, thereby returning the authentication parameters to the user equipment.

[0083] S103: Compare the URL parameters and authentication parameters for consistency based on the target characters to determine the test result.

[0084] It should be noted that, assuming all devices are operating normally, since both URL parameters and user parameters include target characters, and authentication parameters also include target characters like user parameters, URL parameters and user parameters theoretically also include target characters.

[0085] Therefore, for the user equipment, after receiving the authentication parameters, it only needs to perform a consistency comparison between the URL parameters and the authentication parameters to achieve a consistency comparison, thereby quickly determining the test result. Therefore, in some embodiments, the process of comparing the URL parameters and authentication parameters to determine the test result may include:

[0086] If the target characters in the URL parameters and authentication parameters match, the test result is considered successful.

[0087] If the target characters in the URL parameters and authentication parameters are inconsistent, the test result is determined to be a test failure.

[0088] It should also be noted that, because the testing method needs to consider some extreme scenarios to test functional stability, in some embodiments, the number of authentication requests can be multiple, and when the number of authentication requests is multiple, the multiple authentication requests are in a concurrent state; the consistency comparison of URL parameters and authentication parameters to determine the test result may include:

[0089] A consistency comparison is performed on the URL parameters and authentication parameters of each of the multiple authentication requests to determine the number of errors;

[0090] If the number of errors is less than or equal to a preset threshold, the test result is determined to be a successful test.

[0091] If the number of errors exceeds a preset threshold, the test result is determined to be a test failure.

[0092] It should be noted that the number of errors refers to the number of authentication requests that failed to execute successfully, meaning that the target characters in the URL parameters and the received authentication parameters are inconsistent.

[0093] If the number of errors exceeds the preset threshold, the test fails, indicating that the service device cannot handle a large number of concurrent authentication requests. The preset threshold can be set according to the actual application scenario.

[0094] Furthermore, in some embodiments, the step of performing a consistency comparison of the URL parameters and authentication parameters in each of the plurality of authentication requests to determine the number of errors may include:

[0095] Set the initial count value of the preset counter to 0;

[0096] In multiple authentication requests, the URL parameters and authentication parameters of one of the authentication requests are compared for consistency.

[0097] If the URL parameter of one of the authentication requests does not match the target character in the authentication parameters, the control counter is incremented by one.

[0098] After performing a consistency comparison of the URL parameters and authentication parameters of each authentication request in multiple authentication requests, the current count value of the counter is obtained;

[0099] The current count value of the counter is determined as the number of errors.

[0100] It's important to note that within the same authentication request, both the URL parameters and the authentication parameters include the same target characters; however, the target characters differ across different authentication requests. Therefore, by comparing the consistency between the URL and the authentication parameters, it's possible to quickly determine whether the authentication request was successfully processed.

[0101] In this way, by introducing a counter, the number of errors can be counted automatically and quickly, thereby determining the test results in concurrent scenarios.

[0102] In particular, the embodiments of this application can be applied to asynchronous callback interface testing. That is, the embodiments of this application provide a test method to verify whether callback information is consistent during concurrent processing and can automatically assert. Of course, the embodiments of this application can be applied to other test scenarios, which are not listed here.

[0103] This application provides a testing method applied to a user device. The method involves sending an authentication request containing user parameters and a Uniform Address Sequence (URL) parameter to a service device, where both the user parameters and the URL parameter contain target characters. Based on the URL parameter, the method receives authentication parameters returned by the service device. A consistency comparison is performed between the URL parameter and the authentication parameter based on the target characters to determine the test result. In asynchronous callback interface testing, this consistency comparison between the URL parameter and the authentication parameter allows for rapid determination of test success, thereby improving testing efficiency.

[0104] In another embodiment of this application, see Figure 2 This illustrates a flowchart of another testing method provided in an embodiment of this application. Figure 2 As shown, the method may include:

[0105] S201: Receive an authentication request sent by a user equipment containing user parameters and URL parameters, wherein both user parameters and URL parameters contain target characters.

[0106] It should be noted that the testing method provided in this application embodiment is applied to service equipment, which can be various electronic devices, such as servers, personal computers, laptops, etc., and this application embodiment does not impose any limitations.

[0107] Furthermore, this application embodiment also involves user equipment, and the service equipment is capable of processing authentication requests from the user equipment. For example, the user equipment may have an application client installed, and the service equipment may have an application server installed.

[0108] In this embodiment, the service device receives an authentication request sent by the user equipment and returns corresponding authentication parameters to the user equipment. Specifically, the authentication request includes user parameters and URL parameters. The user parameters specify which user's authentication parameters are required, while the URL parameters inform the service device of the address where the authentication parameters will be returned.

[0109] S202: Obtain authentication parameters based on the target character in the target character in the user parameters.

[0110] It should also be noted that there are many ways to obtain authentication parameters. For example, the service device may store a mapping relationship between user parameters and preset authentication parameters, or the service device may be able to directly generate authentication parameters based on user parameters, or the service device may be able to call other devices to obtain authentication parameters.

[0111] The following is a specific example of a scenario where a service device calls other devices (such as databases or other servers) to obtain authentication parameters, but this does not constitute a limitation of the embodiments of this application.

[0112] In a common scenario, upon receiving an authentication request, the service device needs to obtain the user's consent first, and then obtain authentication parameters from other devices. Therefore, in this embodiment, a first Mock server and a second Mock server are used to simulate the user confirmation step and the parameter acquisition step, respectively.

[0113] Therefore, for the user confirmation step simulated by the first Mock server, in some embodiments, the user confirmation request includes a callback address parameter, and the callback address parameter is used to indicate a second asynchronous call interface in the service device. The method may also include:

[0114] Based on the user parameters, send a user confirmation request to the first Mock server;

[0115] When the second asynchronous call interface is detected to be invoked, the user confirmation information returned by the first Mock server is received;

[0116] Based on the user confirmation information, the step of obtaining authentication parameters based on the target character in the user parameters is executed.

[0117] Here, the first Mock server is used to simulate the user confirmation step. The processing time of this step is uncertain, so the interaction between the first Mock server and the service device can be designed as an asynchronous process.

[0118] Therefore, regarding the parameter acquisition steps simulated by the second Mock server, in some embodiments, the step of acquiring authentication parameters based on target characters in user parameters includes:

[0119] Based on the user parameters, a parameter retrieval request is sent to the second Mock server so that the second Mock server can generate authentication parameters based on the target characters in the user parameters;

[0120] Receive authentication parameters returned by the second Mock server.

[0121] It should be noted that, to facilitate the determination of test results, the target character can be used to generate authentication parameters, meaning that the authentication parameters also include this target character. In other words, under normal working conditions, URL parameters, user parameters, and authentication parameters all have the same target character.

[0122] Here, the interaction between the second mock server and the service device can be either asynchronous or synchronous. It should be understood that the calling method between the service device and the first and second mock servers should be determined based on the actual working process being tested.

[0123] S203: Based on URL parameters, send authentication parameters to the user equipment so that the user equipment can determine the test result.

[0124] Here, the test results are obtained by comparing the URL parameters and authentication parameters based on the target characters.

[0125] It should be noted that, assuming the program is running normally, since the URL parameters, user parameters, and authentication parameters should all contain the target characters, the test result can be quickly determined by comparing the consistency between the URL parameters and the authentication parameters received by that URL.

[0126] Furthermore, the interaction between the user equipment and the service equipment can be performed asynchronously. Therefore, in some embodiments, the URL parameter is used to indicate the first asynchronous call interface in the user equipment; sending authentication parameters to the user equipment based on the URL parameter may include:

[0127] Based on the URL parameters, the first asynchronous API call is invoked;

[0128] The authentication parameters are sent to the user device through the first asynchronous call interface.

[0129] It should also be noted that, in order to test whether the service device can process authentication requests normally under concurrent conditions, the user device can send multiple authentication requests concurrently. The service device determines the authentication parameters according to the user parameters in each authentication request and returns the corresponding authentication parameters to the user device according to the URL parameters in each authentication request.

[0130] Furthermore, in the above embodiments, there are multiple authentication requests, and these multiple authentication requests are concurrent. Specifically, in the same authentication request, the URL parameters and user parameters have the same target characters; in different authentication requests, the target characters are different.

[0131] This application provides a testing method applied to a service device. It receives an authentication request from a user device containing user parameters and URL parameters, both of which contain target characters. Based on the target characters in the user parameters, authentication parameters are obtained. Based on the URL parameters, the authentication parameters are sent to the user device, enabling the user device to determine the test result. Thus, in asynchronous callback interface testing, by comparing the consistency of the URL parameters and authentication parameters, the success of the test can be quickly determined, thereby improving testing efficiency.

[0132] In another embodiment of this application, see [link to application]. Figure 3 This illustrates a schematic diagram of the interaction process of a testing system provided in an embodiment of this application. Figure 3 As shown, the test system includes a client (equivalent to the aforementioned user equipment), a system under test (equivalent to the aforementioned service equipment), Mock1 (equivalent to the aforementioned first Mock server), and Mock2 (equivalent to the aforementioned second Mock server).

[0133] Here, the client, the system under test, Mock1, and Mock2 can all exist as virtual machines, and the client, the system under test, Mock1, and Mock2 can be mounted on the same physical device.

[0134] like Figure 3 As shown, the interaction process of this test system may include the following steps:

[0135] S301: The client sends an authentication request to the system under test, including the mobile phone number and backUrl.

[0136] Here, the phone number is equivalent to the aforementioned user information, and backUrl is equivalent to the aforementioned URL parameter;

[0137] S302: The system under test sends a user confirmation request to Mock1.

[0138] It should be noted that Mock1 simulates the owner device corresponding to the phone number in a real-world scenario. Therefore, the system under test actually sends user confirmation requests based on the phone number.

[0139] S303: Mock1 response to the system under test.

[0140] It should be noted that Mock1 will respond after receiving a confirmation request to simulate the process in a real-world scenario.

[0141] S304: Mock1 returns user confirmation information via asynchronous callback.

[0142] It should be noted that the interaction between the tested system and Mock1 simulates the owner's confirmation process in actual work. Since this process involves the owner's own operation, the time consumed cannot be determined in advance, so it is generally executed in an asynchronous manner.

[0143] S305: The system under test sends a parameter retrieval request to Mock2.

[0144] It should be noted that the authentication request includes a mobile phone number so that Mock2 can generate authentication parameters.

[0145] S306: Mock2 returns authentication parameters to the system under test.

[0146] It should be noted that Mock2 generates authentication parameters based on the mobile phone number, and the generated authentication parameters are the same as the last three digits of the mobile phone number.

[0147] S307: The system under test returns authentication parameters to the client via asynchronous callback.

[0148] In other words, for the system under test, the system concurrently processes client requests (see step S301), requests and waits for user confirmation information (see step S304), and then decides whether to obtain authentication parameters (see step S305). After obtaining them, the system finally passes the correct authentication parameters to the correct backUrl (see step S307).

[0149] For scenarios involving asynchronous calls, in addition to regular testing, an important test point needs to be completed: in a multi-concurrency scenario, can the system under test pass the correct authentication information to the correct backUrl? In related technologies, although manual testing can be used to complete concurrent calls from one or two users, to ensure the stability of the system under test, persistent testing under high concurrency environments is required. Therefore, this application provides an automatic solution with automatically measurable results.

[0150] For this testing system, the client can quickly determine whether the system under test has returned the correct authentication parameters by comparing the backUrl with the received authentication parameters. The testing system can also be equipped with a counter to automatically count the number of errors in high-concurrency states. Specifically, such as... Figure 4 As shown, the testing process of the testing system includes the following steps:

[0151] S401: Configure the test system.

[0152] It should be noted that, firstly, the test system needs to be prepared for testing, including the following aspects: (1) Configure the addresses of Mock1 and Mock2 on the system under test; (2) Deploy 300 (this number can be modified according to needs) backUrl services and request services from the system under test on the client; (3) The client, Mock1, and Mock2 are available. In addition, the client, Mock1, and Mock2 can be modified, compiled, and added to the system through the management platform.

[0153] S402: Reset counter is 0.

[0154] Here, the total count value of the reset counter is reset to 0.

[0155] S403: The client initiates 100 concurrent authentication requests, each including the backUrl and the phone number.

[0156] Here, within each authentication request, the backUrl and the suffix of the phone number are the same, but the suffix of the phone number is different between different authentication requests.

[0157] S404: After receiving the confirmation request from the system under test, Mock1 returns "Agree".

[0158] S405: After receiving the parameter retrieval request from the system under test, Mock2 returns authentication parameters, and the suffix after the mobile phone number in the authentication parameters is the same as that in the parameter retrieval request.

[0159] It should be noted that if the phone number in the request for this parameter ends with 001, then token1 information (equivalent to authentication information) with a suffix of 1 will be returned.

[0160] S406: After each backUrl of the client receives the authentication parameters, if the suffix of the authentication parameters is the same as the suffix of the backUrl, the authentication is successful; otherwise, the counter is incremented by 1.

[0161] S407: Get the value of the counter. If it is 0, the test passes; otherwise, it fails.

[0162] It should be noted that if the counter value is 0, it means that the system under test has correctly processed all authentication requests, and the test is successful; otherwise, it means that the system under test has not correctly processed all authentication requests, and the test fails.

[0163] In one specific embodiment, the client, Mock1, and Mock2 are all simulated by the Mock service. The following mainly focuses on the Mock service of the three subsystems that are closely related to the system under test.

[0164] The client is responsible for simulating multiple users sending concurrent requests with their phone numbers and backUrls, as well as simulating the correctness of different backUrls receiving and analyzing user authentication information. The number of concurrent requests set by the client is less than or equal to the total number of backUrls, and the phone numbers and backUrls have the same numeric suffix (the last three digits of the phone number represent an integer, and the last one to three digits of the backUrl represent an integer).

[0165] The Java function that compares the consistency between backUrl and token is generated based on the FreeMarker template, as shown in code snippet 1. The Java code snippet that compares the consistency between the generated backUrl and authentication parameters is shown in code snippet 2.

[0166] Code snippet 1:

[0167]

[0168] Code snippet 2:

[0169]

[0170] According to code snippet two, when `backUrl1` receives `token1`, it indicates that the suffix is ​​the same and the authentication parameters received by `backUrl` are correct; otherwise, an error occurs. The global variable `total` counts the number of errors. The value of `total` can be obtained through an interface. If `total` is 0, the test passed; otherwise, the test failed. It can also be reset (reset to 0) through an interface.

[0171] Mock1 is responsible for simulating user behavior information to implement the user confirmation process.

[0172] Mock2 is responsible for simulating receiving user authentication information requests, generating and returning authentication information. When generating authentication information, it is necessary to follow the principle that the authentication parameters and the mobile phone number have the same suffix. For example, if the mobile phone number is 1********001, then the authentication information is token1.

[0173] This application provides a testing system. This embodiment elaborates on the specific implementation method of the aforementioned embodiments. It can be seen that in asynchronous callback interface testing, by comparing the consistency of URL parameters and authentication parameters, it is possible to quickly determine whether the test is successful, thereby improving testing efficiency.

[0174] In another embodiment of this application, see [link to application]. Figure 5 This illustrates a flowchart of a Mock framework 50 provided in an embodiment of this application. Figure 5 As shown, the Mock framework 10 is used to deploy virtual devices; and the Mock framework 10 includes an interface manager 501 and a class loader 502; wherein,

[0175] Interface Manager 501 is used to receive interface increment instructions and generate interface increment codes based on the interface increment instructions;

[0176] Class loader 502 is used to load incremental interface code to enable incremental processing of the virtual device interface.

[0177] It's important to note that during testing, it's often necessary to use a mock framework to simulate devices and their interfaces that cannot be directly accessed. For example, you might need to test whether the server of a business system can correctly provide authentication information to the client, but the client application might not be fully developed. In this case, a mock framework can be used to simulate the client and its interfaces to complete the server-side testing.

[0178] Mock frameworks are software frameworks used to develop simulated devices. In related technologies, code is written based on the device to be simulated and its interfaces, and then deployed to obtain a virtual device. However, if incremental modifications to the virtual device's interface are needed, the code must be modified again, and the virtual device must be reloaded using a class loader, which is very inconvenient.

[0179] Please see Figure 5 This application provides a Mock framework 10, which includes an interface manager 501 and a class loader 502. After a virtual device is loaded through the Mock framework 10, the interface manager 501 can be used to generate incremental interface code, and the class loader 502 can load the incremental interface code to complete the incremental interface processing of the virtual device.

[0180] Here, incremental interface processing includes at least one of the following: interface addition processing, interface deletion processing, interface query processing, and interface modification processing.

[0181] In other words, without making a full modification to the virtual device, the Interface Manager 501 can handle adding, deleting, modifying, and querying interfaces in the virtual device.

[0182] It should be noted that in the aforementioned embodiments, the user equipment, the first Mock server, and the second Mock server can all be deployed using the Mock framework 10.

[0183] In other words, this embodiment of the application separates the Mock and the class loader, enabling incremental deployment. For example... Figure 6 As shown, a Mock framework can include Serclet components (such as Spring Cloud SercletBean Register), class loaders (such as Restful ClassLoader), interface managers (Console), and interface sets.

[0184] In one specific implementation, Spring Cloud ServicBean Register is used to provide the Servler layer for interaction with other devices; Restful ClassLoader is used to load class code to generate the virtual device's interface or implement other functions of the virtual device; Console is used to make incremental modifications to the interface set (such as adding, deleting, modifying, and querying); the interface set can be understood as the part of the virtual device related to interfaces.

[0185] In other words, this application uses Spring Cloud as the development framework and implements incremental functional interfaces according to the RESTful specification. The originally centralized functional interfaces are broken down into manageable and describable parts. An interface manager (Console) is used to manage these interfaces, enhancing code manageability. Interfaces can be added, deleted, modified, and queried. After an interface change, it is loaded and made effective using a RESTful ClassLoader. Without replacing the entire project package, the changed or newly added interfaces can be uploaded to the server and loaded and made effective by the RESTful ClassLoader.

[0186] Specifically, each set of mock interfaces is packaged into a JAR file, and multiple different JAR files are uploaded to a repository. In this embodiment, the JAR files in the repository can be parsed individually, and the interfaces contained in the JAR files can be activated. The loaded classes are then placed into the Tomcat instance configured with Spring Cloud. In this way, the mock service can be easily and incrementally expanded.

[0187] In addition, the following conditions should be met when implementing this application: (1) The Jar package must be packaged in the specified way so that the loader can determine the file path of the class file and load the class; (2) The Java file must meet the Jersey (software framework) RESTful format; (3) No dependency packages need to be included when packaging, and all dependency packages are placed in the Lib library.

[0188] In summary, this application provides a Mock framework, which eliminates the need to fully package and upload the entire project when extending or modifying the Mock, meaning that the Mock interface can be deployed incrementally.

[0189] This application provides a mock framework for deploying virtual devices. The mock framework includes an interface manager and a class loader. The interface manager receives interface increment instructions and generates interface increment code based on these instructions. The class loader loads the interface increment code to implement incremental interface processing for the virtual device. Thus, when deploying a virtual device using the mock framework, the interface manager allows for convenient incremental modification of interfaces within the virtual device, reducing the workload associated with incremental interface modifications.

[0190] In another embodiment of this application, see [link to application]. Figure 7 This illustrates a schematic diagram of the composition structure of a user equipment 60 provided in an embodiment of this application. For example... Figure 7 As shown, the user equipment 60 includes a first transmitting unit 601, a first receiving unit 602, and a comparison unit 603; wherein,

[0191] The first sending unit 601 is configured to send an authentication request containing user parameters and a Uniform Address Locator (URL) parameter to the service device, wherein both the user parameters and the URL parameter contain target characters.

[0192] The first receiving unit 602 is configured to receive authentication parameters returned by the service device based on URL parameters;

[0193] Comparison unit 603 is configured to perform a consistency comparison between URL parameters and authentication parameters based on the target characters to determine the test result.

[0194] In some embodiments, the URL parameter is used to indicate a first asynchronous call interface in the user equipment; correspondingly, the first receiving unit 602 is also configured to receive authentication parameters sent by the service device through the first asynchronous call interface when the first asynchronous call interface is detected to be called.

[0195] In some embodiments, the comparison unit 603 is further configured to determine the test result as successful if the target characters in the URL parameters and authentication parameters are consistent; and to determine the test result as failed if the target characters in the URL parameters and authentication parameters are inconsistent.

[0196] In some embodiments, when there are multiple authentication requests and the multiple authentication requests are in a concurrent state, the comparison unit 603 is further configured to perform a consistency comparison of the URL parameters and authentication parameters in each of the multiple authentication requests to determine the number of errors; if the number of errors is less than or equal to a preset threshold, the test result is determined to be a successful test; if the number of errors is greater than the preset threshold, the test result is determined to be a failed test.

[0197] In some embodiments, the comparison unit 603 is further configured to set the initial count value of a preset counter to 0; in multiple authentication requests, perform a consistency comparison between the URL parameter and authentication parameter of one of the authentication requests; if the target character in the URL parameter and authentication parameter of one of the authentication requests is inconsistent, control the counter to increment by one; after performing a consistency comparison between the URL parameter and authentication parameter of each of the multiple authentication requests, obtain the current count value of the counter; and determine the current count value of the counter as the number of errors.

[0198] In some embodiments, the feature character includes a combination of characters formed by the last N digits of the parameter to be processed; where N is a positive integer.

[0199] Understandably, in this embodiment, a "unit" can be a portion of a circuit, a portion of a first processor, a portion of a program or software, etc., and can also be a module or a non-modular one. Furthermore, the components in this embodiment can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional module.

[0200] If the integrated unit is implemented as a software functional module and is not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment, in essence, 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. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor (first processor) to execute all or part of the steps of the method of this embodiment. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0201] Therefore, this embodiment provides a computer storage medium storing a computer program that, when executed by a plurality of first processors, implements the steps of any of the methods in the foregoing embodiments.

[0202] Based on the composition of user equipment 60 and the computer storage media, see [reference needed]. Figure 8 This illustrates a schematic diagram of the hardware structure of a user equipment 60 provided in an embodiment of this application. Figure 8 As shown, user equipment 60 may include: a first communication interface 701, a first memory 702, and a first processor 703; the various components are coupled together through a first bus system 704. It is understood that the first bus system 704 is used to implement communication between these components. In addition to a data bus, the first bus system 704 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 8 All buses are designated as the first bus system 704. The first communication interface 701 is used for receiving and transmitting signals during information exchange with other external network elements.

[0203] The first memory 702 is used to store computer programs that can run on the first processor 703;

[0204] The first processor 703 is used to execute the following when running computer programs:

[0205] Send an authentication request containing user parameters and a Uniform Address Locator (URL) parameter to the service device, where both the user parameters and the URL parameter contain the target character;

[0206] Based on the URL parameters, receive the authentication parameters returned by the service device;

[0207] The test result is determined by comparing the URL parameters and authentication parameters based on the target characters.

[0208] It is understood that the first memory 702 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The first memory 702 of the apparatus and method described in this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0209] The first processor 703 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the first processor 703 or by instructions in software form. The first processor 703 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in the first memory 702. The first processor 703 reads the information in the first memory 702 and completes the steps of the above method in conjunction with its hardware.

[0210] It is understood that the embodiments described in this application can be implemented using hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions of this application, or combinations thereof.

[0211] For software implementation, the technology of this application can be implemented through modules (e.g., procedures, functions, etc.) that execute the functions of this application. The software code can be stored in a first memory and executed by a first processor. The first memory can be implemented in the first processor or external to the first processor.

[0212] Alternatively, as another embodiment, the first processor 703 is further configured to perform the steps of any of the methods in the foregoing embodiments when running a computer program.

[0213] This application provides a user equipment including a first sending unit, a first connection unit, and a comparison unit. In asynchronous callback interface testing, by comparing the consistency of URL parameters and authentication parameters, it is possible to quickly determine whether the test is successful, thereby improving testing efficiency.

[0214] In another embodiment of this application, see [link to application]. Figure 9 This illustrates a schematic diagram of the structural composition of a service device 80 provided in an embodiment of this application. For example... Figure 9 As shown, the service device 80 includes a second receiving unit 801, an acquisition unit 802, and a second sending unit 803, wherein...

[0215] The second receiving unit 801 is configured to receive an authentication request sent by a user equipment containing user parameters and URL parameters, wherein both the user parameters and the URL parameters contain target characters.

[0216] Unit 802 is configured to retrieve authentication parameters based on the target character in the user parameters.

[0217] The second sending unit 803 is configured to send authentication parameters to the user equipment based on URL parameters, so that the user equipment can determine the test result.

[0218] In some embodiments, the user confirmation request includes a callback address parameter, and the callback address parameter indicates a second asynchronous call interface in the service device. The acquisition unit 802 is further configured to send a user confirmation request to a first Mock server based on the user parameter; and to receive user confirmation information returned by the first Mock server when the second asynchronous call interface is detected to be invoked.

[0219] In some embodiments, the acquisition unit 802 is further configured to send a parameter acquisition request to the second Mock server based on user parameters, so that the second Mock server generates authentication parameters based on the target characters in the user parameters; and receive the authentication parameters returned by the second Mock server.

[0220] In some embodiments, the URL parameter is used to indicate a first asynchronous call interface in the user equipment; the second sending unit 803 is further configured to call the first asynchronous call interface based on the URL parameter; and send authentication parameters to the user equipment through the first asynchronous call interface.

[0221] In some embodiments, there are multiple authentication requests, and these multiple authentication requests are concurrent.

[0222] Understandably, in this embodiment, a "unit" can be a portion of a circuit, a portion of a processor, a portion of a program or software, etc., and can also be a module or a non-modular component. Furthermore, the components in this embodiment can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional module.

[0223] If the integrated unit is implemented as a software functional module and is not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment, in essence, 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. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor (first processor) to execute all or part of the steps of the method of this embodiment. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0224] Therefore, this embodiment provides a computer storage medium storing a computer program that, when executed by a plurality of first processors, implements the steps of any of the methods in the foregoing embodiments.

[0225] Based on the composition of service device 80 and computer storage media, see [link / reference]. Figure 10 It illustrates a specific hardware structure example of the service device 80 provided in the embodiments of this application, such as... Figure 10 As shown, the service device 80 may include: a second communication interface 901, a second memory 902, and a second processor 903; the various components are coupled together via a second bus system 904. It is understood that the second bus system 904 is used to implement communication between these components. In addition to a data bus, the second bus system 904 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 10 The general designated all buses as the second bus system 904. Among them,

[0226] The second communication interface 901 is used for receiving and sending signals during the process of sending and receiving information with other external network elements;

[0227] The second memory 902 is used to store computer programs that can run on the second processor 903;

[0228] The second processor 903 is used to execute the following when running computer programs:

[0229] Receive authentication requests sent by user equipment containing user parameters and URL parameters, where both user parameters and URL parameters contain target characters;

[0230] Based on the target character in the user parameters, obtain the authentication parameters;

[0231] Based on the URL parameters, authentication parameters are sent to the user device so that the user device can determine the test result.

[0232] Alternatively, as another embodiment, the second processor 903 is also configured to execute any of the methods in the foregoing embodiments when running a computer program.

[0233] It is understood that the second memory 902 has similar hardware functions to the first memory 702, and the second processor 903 has similar hardware functions to the first processor 703; these will not be described in detail here.

[0234] This application provides a service device, which includes a second receiving unit, an acquisition unit, and a second sending unit. In asynchronous callback interface testing, by comparing the consistency of URL parameters and authentication parameters, it is possible to quickly determine whether the test is successful, thereby improving testing efficiency.

[0235] In another embodiment of this application, a testing system is also provided, which may include at least the user equipment 60 of any of the foregoing embodiments and the service equipment 80 of any of the foregoing embodiments.

[0236] In this embodiment of the application, since the test system includes at least the user device 60 and the service device 80 of any of the foregoing embodiments, in the asynchronous callback interface test, by comparing the consistency of the URL parameters and the authentication parameters, it is possible to quickly determine whether the test is successful, thereby improving the test efficiency.

[0237] The above are merely preferred embodiments of this application and are not intended to limit the scope of protection of this application.

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

[0239] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0240] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0241] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0242] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0243] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A testing method, characterized in that, Applied to user equipment, the method includes: Send an authentication request containing user parameters and a Uniform Address Locator (URL) parameter to the service device, wherein both the user parameters and the URL parameter contain the target character; Based on the URL parameters, receive the authentication parameters returned by the service device; The URL parameters and authentication parameters are compared for consistency based on the target characters to determine the test result. The step of comparing the URL parameters and the authentication parameters for consistency based on the target characters to determine the test result includes: If the target characters in the URL parameters and the authentication parameters are consistent, then the test result is determined to be a successful test. If the target characters in the URL parameters and the authentication parameters are inconsistent, the test result is determined to be a test failure.

2. The test method according to claim 1, characterized in that, The URL parameter is used to indicate the first asynchronous call interface in the user equipment; The step of receiving authentication parameters returned by the service device based on the URL parameters includes: When the first asynchronous call interface is detected to be invoked, the authentication parameters sent by the service device are received through the first asynchronous call interface.

3. The test method according to claim 1, characterized in that, When there are multiple authentication requests, these requests are concurrent; the step of comparing the URL parameters and authentication parameters based on the target character to determine the test result includes: A consistency comparison is performed on the URL parameters and authentication parameters of each of the multiple authentication requests to determine the number of errors; If the number of errors is less than or equal to a preset threshold, the test result is determined to be a successful test. If the number of errors exceeds a preset threshold, the test result is determined to be a test failure.

4. The test method according to claim 3, characterized in that, The step of performing a consistency comparison of the URL parameters and authentication parameters of each of the multiple authentication requests to determine the number of errors includes: Set the initial count value of the preset counter to 0; In the multiple authentication requests, the URL parameters and authentication parameters of one of the authentication requests are compared for consistency. If the URL parameter of one of the authentication requests is inconsistent with the target character in the authentication parameters, then the counter is incremented by one. After performing a consistency comparison on the URL parameters and authentication parameters of each of the multiple authentication requests, the current count value of the counter is obtained; The current count value of the counter is determined as the number of errors.

5. The test method according to any one of claims 1 to 4, characterized in that, The target character includes the character combination formed by the last N characters in the parameters to be processed; Where N is a positive integer, and the parameter to be processed is any one of the user parameter, the URL parameter, and the authentication parameter.

6. A testing method, characterized in that, Applied to service equipment, the method includes: Receive an authentication request sent by a user equipment containing user parameters and URL parameters, wherein both the user parameters and URL parameters contain target characters; Based on the target character in the user parameters, obtain the authentication parameters; Based on the URL parameters, the authentication parameters are sent to the user equipment so that the user equipment can determine the test result; wherein, the test result is obtained by the user equipment after performing a consistency comparison between the URL parameters and the authentication parameters based on the target characters.

7. The test method according to claim 6, characterized in that, The method further includes: Based on the user parameters, a user confirmation request is sent to the first Mock server; the user confirmation request includes a callback address parameter, and the callback address parameter is used to indicate the second asynchronous call interface in the service device; When the second asynchronous call interface is detected to be invoked, the user confirmation information returned by the first Mock server is received; Based on the user confirmation information, the step of obtaining authentication parameters based on the user parameters is executed.

8. The test method according to claim 6 or 7, characterized in that, The step of obtaining authentication parameters based on the target character in the user parameters includes: Based on the user parameters, a parameter retrieval request is sent to the second Mock server, so that the second Mock server generates the authentication parameters based on the target characters in the user parameters; Receive the authentication parameters returned by the second Mock server.

9. The test method according to claim 6, characterized in that, The URL parameter is used to indicate the first asynchronous call interface in the user equipment; sending the authentication parameter to the user equipment based on the URL parameter includes: Based on the URL parameters, the first asynchronous call interface is invoked; The authentication parameters are sent to the user equipment through the first asynchronous call interface.

10. A user equipment, characterized in that, The user equipment includes a first transmitting unit, a first receiving unit, and a comparison unit; wherein... The first sending unit is configured to send an authentication request containing user parameters and a Uniform Address Locator (URL) parameter to the service device, wherein both the user parameters and the URL parameter contain target characters. The first receiving unit is configured to receive authentication parameters returned by the service device based on the URL parameters; The comparison unit is configured to perform a consistency comparison between the URL parameter and the authentication parameter based on the target character to determine the test result, specifically including: If the target characters in the URL parameters and the authentication parameters are consistent, then the test result is determined to be a successful test. If the target characters in the URL parameters and the authentication parameters are inconsistent, the test result is determined to be a test failure.

11. A user equipment, characterized in that, The user equipment includes a first memory and a first processor; wherein... The first memory is used to store computer programs that can run on the processor; The first processor is configured to perform the steps of the method as described in any one of claims 1 to 5 when running the computer program.

12. A service device, characterized in that, The service device includes a second receiving unit, an acquisition unit, and a second sending unit; wherein... The second receiving unit is configured to receive an authentication request sent by a user equipment, which includes user parameters and URL parameters, wherein both the user parameters and the URL parameters contain target characters; The acquisition unit is configured to acquire authentication parameters based on the target character in the user parameters; The second sending unit is configured to send the authentication parameters to the user equipment based on the URL parameters, so that the user equipment can determine the test result; wherein the test result is obtained by the user equipment after performing a consistency comparison between the URL parameters and the authentication parameters based on the target characters.

13. A service device, characterized in that, The service device includes a second memory and a second processor; wherein... The second memory is used to store computer programs that can run on the processor; The second processor is configured to perform the steps of the method as described in any one of claims 6-9 when running the computer program.

14. A computer storage medium, characterized in that, The computer storage medium stores a computer program that, when executed by a first processor, implements the steps of the method as described in any one of claims 1 to 5, or when executed by a second processor, implements the steps of the method as described in any one of claims 6 to 9.

Images