CN115705289A

CN115705289A - Test method, mock frame, user equipment, service equipment and storage medium

Info

Publication number: CN115705289A
Application number: CN202110912544.5A
Authority: CN
Inventors: 孔彬
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Hangzhou Information Technology Co Ltd
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Hangzhou Information Technology Co Ltd
Priority date: 2021-08-10
Filing date: 2021-08-10
Publication date: 2023-02-17

Abstract

The embodiment of the application provides a test method, a Mock frame, user equipment, service equipment and a storage medium, which are applied to the user equipment, wherein the method comprises the following steps: sending an authentication request containing a user parameter and a uniform address locator (URL) parameter to service equipment, wherein the user parameter and the URL parameter both contain target characters; receiving authentication parameters returned by the service equipment based on the URL parameters; and comparing the consistency of the URL parameter and the authentication parameter according to the target character to determine a test result. Therefore, in the asynchronous callback interface test, the URL parameter and the authentication parameter are compared in consistency, whether the test is successful or not can be quickly determined, and the test efficiency is improved.

Description

Test method, mock frame, user equipment, service equipment and storage medium

Technical Field

The application relates to the technical field of behavioral software testing, in particular to a testing method, a Mock framework, user equipment, service equipment and a storage medium.

Background

In the testing process provided by the related technology, a testing request is firstly sent to the tested object, then the tested object is waited to process the testing request and then returns a processing result, and consistency comparison is carried out according to the returned processing result, so that whether the tested object can meet the service requirement is determined. However, the processing steps of the related art are complicated when performing the consistency comparison, which reduces the overall efficiency of the testing process.

Disclosure of Invention

The application provides a test method, a Mock frame, user equipment, service equipment and a storage medium, which can quickly realize consistency comparison in the test process, thereby improving the test efficiency.

The technical scheme of the application is realized as follows:

in a first aspect, an embodiment of the present application provides a testing method, which is applied to a user equipment, and the method includes:

sending an authentication request containing a user parameter and a uniform address locator (URL) parameter to service equipment, wherein the user parameter and the URL parameter both contain target characters;

receiving an authentication parameter returned by the service equipment based on the URL parameter;

and comparing the consistency of the URL parameter and the authentication parameter according to the target character to determine a test result.

In a second aspect, an embodiment of the present application provides a testing method, which is applied to a service device, and the method includes:

receiving an authentication request which is sent by user equipment and contains user parameters and URL parameters, wherein the user parameters and the URL parameters both contain target characters;

acquiring an authentication parameter based on a target character in the user parameter;

based on the URL parameter, sending an authentication parameter to the user equipment to enable the user equipment to determine a test result.

In a third aspect, an embodiment of the present application provides a Mock framework, where the Mock framework is used to deploy virtual devices, and the Mock framework includes an interface manager and a class loader; wherein, the first and the second end of the pipe are connected with each other,

the interface manager is used for receiving the interface increment instruction and generating an interface increment code according to the interface increment instruction;

and the class loader is also used for loading the interface increment code so as to realize the interface increment processing of the virtual equipment.

In a fourth aspect, an embodiment of the present application provides a user equipment, where the user equipment includes a first sending unit, a first connection unit, and a comparison unit; wherein, the first and the second end of the pipe are connected with each other,

the device comprises a first sending unit, a second sending unit and a third sending unit, wherein the first sending unit is configured to send an authentication request containing a user parameter and a uniform address locator (URL) parameter to service equipment, and the user parameter and the URL parameter both contain target characters;

the first receiving unit is configured to receive the authentication parameters returned by the service equipment based on the URL parameters;

and the comparison unit is configured to compare the URL parameter with the authentication parameter according to the target character to determine a test result.

In a fifth aspect, an embodiment of the present application provides a user equipment, where the user equipment includes a first memory and a first processor; wherein the content of the first and second substances,

a first memory for storing a computer program operable on the processor;

a first processor for performing the steps of the method according to the first aspect when running the computer program.

In a sixth aspect, an embodiment of the present application provides a service device, where the service device includes a second receiving unit, an obtaining unit, and a second sending unit; wherein the content of the first and second substances,

the second receiving unit is configured to receive an authentication request which is sent by user equipment and contains user parameters and URL parameters, and the user parameters and the URL parameters both contain target characters;

the acquisition unit is configured to acquire an authentication parameter based on a target character in the user parameter;

and 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.

In a seventh aspect, an embodiment of the present application provides a service device, where the service device includes a second memory and a second processor; wherein, the first and the second end of the pipe are connected with each other,

a second memory for storing a computer program operable on the processor;

a second processor for performing the steps of the method according to the second aspect when running the computer program.

In an eighth aspect, the present application provides a computer storage medium storing a computer program, which when executed by a first processor implements the steps of the method according to the first aspect, or when executed by a second processor implements the steps of the method according to the second aspect.

The embodiment of the application provides a test method, a Mock frame, user equipment, service equipment and a storage medium, wherein an authentication request containing a user parameter and a uniform address locator (URL) parameter is sent to the service equipment on the side of the user equipment, and both the user parameter and the URL parameter contain target characters; receiving an authentication parameter returned by the service equipment based on the URL parameter; and comparing the consistency of the URL parameter and the authentication parameter according to the target character to determine a test result. Receiving an authentication request which is sent by user equipment and contains user parameters and URL parameters at a service equipment side, wherein the user parameters and the URL parameters both contain target characters; acquiring an authentication parameter based on a target character in the user parameter; based on the URL parameter, sending an authentication parameter to the user equipment to enable the user equipment to determine a test result. Therefore, in the asynchronous callback interface test, the URL parameter and the authentication parameter are compared in consistency, and whether the test is successful or not can be quickly determined, so that the test efficiency is improved. In addition, for the Mock framework, the Mock framework is used for deploying virtual equipment and comprises an interface manager and a class loader; the interface manager is used for receiving the interface increment instruction and generating an interface increment code according to the interface increment instruction; and the class loader is also used for loading the interface increment code so as to realize the interface increment processing of the virtual equipment. Therefore, when the Mock framework is used for deploying the virtual equipment, the interface in the virtual equipment can be conveniently subjected to incremental modification through the interface manager, and the workload of the incremental modification of the interface is reduced.

Drawings

Fig. 1 is a schematic flowchart of a testing method according to an embodiment of the present disclosure;

FIG. 2 is a schematic flow chart of another testing method provided in the embodiments of the present application;

fig. 3 is a schematic view illustrating an interaction process of a test system according to an embodiment of the present disclosure;

FIG. 4 is a schematic flowchart of another testing method provided in the embodiments of the present application;

FIG. 5 is a schematic structural diagram of a Mock frame according to an embodiment of the present application;

FIG. 6 is a schematic structural diagram of another Mock frame according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a user equipment according to an embodiment of the present application;

fig. 8 is a schematic hardware structure diagram of a user equipment according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of a service device according to an embodiment of the present application;

fig. 10 is a schematic hardware structure diagram of a service device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant application and are not limiting of the application. It should be further noted that, for the convenience of description, only the portions relevant to the related applications are shown in the drawings.

Unless defined otherwise, 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 the present application only and is not intended to be limiting of the application.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but 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.

It should be noted that the terms "first \ second \ third" are used merely to distinguish similar objects and do not denote a particular ordering, and it should be understood that "first \ second \ third" may be interchanged under appropriate circumstances in order to enable the embodiments of the present application described herein to be implemented in other sequences than those illustrated or described herein.

Before further detailed description of the embodiments of the present application, terms and expressions referred to in the embodiments of the present application will be described, and the terms and expressions referred to in the embodiments of the present application shall be construed as follows:

java: a computer programming language.

Jar: a software package file format is typically used to aggregate large numbers of Java class files, associated metadata and resource (text, pictures, etc.) files into one file in order to develop Java platform applications or libraries.

Freemarker: a template engine: i.e. a generic tool that is used to generate output text based on templates and data to be changed, developers can embed components of the products they develop using freemaker.

Mock: a simulation data generator creates a Mock object to simulate the behavior of objects for some objects that are not easily constructed/obtained.

Spring cloud: a cloud application development tool can be used for developing Mock.

Servlet: is a program running on a server and provides a uniform specification of a webpage application for the Java program.

Tomcat: a Servlet container.

Lib (Library): a data warehouse.

Restful specification: a specification for an internet software architecture.

Restful Class Loader: class loaders that conform to the Restful specification.

URL (Uniform Resource Locator): and the uniform resource locator is used for designating the representation method of the information position.

back Url: the address is jumped back.

token: the token, i.e. the authentication parameters in the embodiments of the present application.

total: indicating the count value of the counter.

Assertion: in programming, an assertion is a first-order logic placed in a program for the purpose of marking and verifying the results intended by the program developer.

It will be appreciated that many software programs may choose to perform tasks in an asynchronous call in order to improve processing efficiency. In the asynchronous call, after a first thread calls a second thread through an interface, the first thread does not need to wait for a result returned by the second thread, but can directly process other tasks, and when the second thread finishes processing and needs to return a processing result to the first thread, the interface of the first thread is called back again, and the interface is also called as an asynchronous call-back interface (or an asynchronous call interface, an asynchronous interface and the like).

The test of the asynchronous callback interface is an important test. In a related technology, when an asynchronous interface test case is involved, a test thread can be blocked by a thread blocking object to wait for the test and assertion of an asynchronous interface; in another related technology, an automated scheme is disclosed, which divides a use case in a test process into a test case and an assertion case, stops the test case after the test case is executed, establishes a corresponding assertion case execution condition after the test case is stopped, and executes the corresponding assertion case when the condition is satisfied, thereby determining the state of a tested object.

However, the above test methods do not provide a specific judgment method for the consistency of the information after asynchronous processing, which causes that the test method of the asynchronous call interface still has disadvantages.

Based on this, the embodiment of the present application provides a test method, and the basic idea of the method is: sending an authentication request containing a user parameter and a uniform address locator (URL) parameter to service equipment, wherein the user parameter and the URL parameter both contain target characters; receiving authentication parameters returned by the service equipment based on the URL parameters; and comparing the consistency of the URL parameter and the authentication parameter according to the target character to determine a test result. Receiving an authentication request containing user parameters and URL parameters sent by user equipment at a service equipment side, wherein the user parameters and the URL parameters both contain target characters; acquiring an authentication parameter based on a target character in the user parameter; based on the URL parameter, sending an authentication parameter to the user equipment to enable the user equipment to determine a test result. Therefore, in the asynchronous callback interface test, the URL parameter and the authentication parameter are compared in consistency, and whether the test is successful or not can be quickly determined, so that the test efficiency is improved.

In addition, during the debugging and testing process of the program, it is often necessary to virtualize some devices (for example, servers, databases, or systems that have not been designed yet) and their interfaces by using the Mock technology, so as to complete the testing process by using the interfaces of the virtual devices. However, in the related art, if the interface of the virtual device is desired to be modified, the entire virtual device needs to be modified, which is labor-intensive and complicated.

Based on this, the embodiment of the present application further provides a Mock framework, and the basic idea of the method is: the Mock frame is used for deploying virtual equipment and comprises an interface manager and a class loader; the interface manager is used for receiving the interface increment instruction and generating an interface increment code according to the interface increment instruction; and the class loader is also used for loading the interface increment code so as to realize the interface increment processing of the virtual equipment. Therefore, when the Mock framework is used for deploying the virtual equipment, the interface in the virtual equipment can be conveniently modified in an incremental mode through the interface manager, and the workload of modifying the interface is reduced.

Embodiments of the present application will be described in detail below with reference to the accompanying drawings.

In an embodiment of the present application, referring to fig. 1, a flowchart of a testing method provided in an embodiment of the present application is shown. As shown in fig. 1, the method may include:

s101: and 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 target characters.

It should be noted that the test method provided in the embodiment of the present application is applied to a user equipment, and the user equipment may be various Terminal equipment, such as a Personal Digital Assistant (PDA), a Wireless Communication Terminal (Wireless Communication Terminal), a Smart Phone (Smart Phone), an audio device, a television, a projector, a Smart home device, a Portable Multimedia Player (PMP), and the like, and the embodiment of the present application is not limited at all.

In addition, the embodiment of the application also relates to a service device, wherein the service device is a device capable of processing the authentication request of the user device. For example, the user device may be a client installed with a certain application, and the service device may be a server installed with a certain application.

In this embodiment, the user equipment may send an authentication request to the service equipment, so as to obtain authentication parameters of different users. Specifically, the authentication request includes a user parameter and a URL parameter, the user parameter is used to specify which user's authentication parameter is required by the user device, and the URL parameter is used to inform the service device of an address when the authentication parameter is returned.

It should be further noted that, in the embodiment of the present application, both the user parameter and the URL parameter include a target character. Here, the meaning of the target character includes, but is not limited to, the following possibilities:

(1) A specific character combination, wherein the two parameters are considered to contain the same characteristic character as long as the specific character combination appears in the two parameters;

(2) A specific character combination and the specific character combination must appear in a specific parameter position, for example, a character combination formed by the last N-bit character must be the specific character combination, and a character combination formed by the middle N-bit character must be the specific character combination; that is, two parameters are considered to contain the same target character only if they each have a particular character combination at the specified parameter location.

Thus, in the test method, the service equipment can determine corresponding authentication parameters according to the user parameters in the authentication request; and returning the authentication parameters to the user equipment according to the URL parameters in the authentication request, and determining whether the authentication request is successfully executed by the user equipment according to the authentication parameters.

S102: and receiving the authentication parameters returned by the service equipment based on the URL parameters.

It should be noted that, in the actual business process, the mapping relationship between the authentication parameter and the user parameter may be pre-stored or generated according to a certain business rule. However, the mapping relationship between the authentication parameters and the user parameters does not need to be strictly observed in the testing process. Therefore, in the embodiment of the present application, in order to facilitate the determination of the test result, an authentication parameter generation rule is designed: and generating an authentication parameter according to the user parameter, wherein the generated authentication parameter and the user parameter have the same characteristic character. That is, under the premise of normal operation, the URL parameter, the user parameter and the authentication parameter all have the same target character.

It should be noted that the service device needs a certain time to complete the authentication request, so the authentication request can be designed as an asynchronous processing procedure. Thus, in some implementations, the URL parameter is used to indicate the first asynchronous call interface; the method may further include, based on the URL parameter, receiving an authentication parameter sent by the service device:

and receiving the authentication parameters sent by the service equipment through the first asynchronous calling interface when the first asynchronous calling interface is detected to be called.

It should be noted that, after the user equipment sends the first authentication request to the service equipment, the user equipment may perform other tasks; after the service equipment acquires the authentication parameters corresponding to the authentication request, the first asynchronous call interface of the user equipment is called back according to the URL parameters, and therefore the authentication parameters are returned to the user equipment.

S103: and comparing the consistency of the URL parameter and the authentication parameter according to the target character to determine a test result.

It should be noted that, on the premise that all devices operate normally, since the URL parameters and the user parameters both include the target characters, and the authentication parameters and the user parameters include the target characters as well, the URL parameters and the user parameters theoretically also include the target characters.

Therefore, for the user equipment, after receiving the authentication parameters, consistency comparison can be realized only by performing consistency comparison on the URL parameters and the authentication parameters, so that a test result can be determined quickly. Therefore, in some embodiments, the performing the consistency comparison between the URL parameter and the authentication parameter to determine the test result may include:

if the target characters in the URL parameter and the authentication parameter are consistent, determining that the test result is successful;

and if the URL parameter is not consistent with the target character in the authentication parameter, determining that the test result is test failure.

It should be noted that, since the test method needs to consider some extreme scenarios, the functional stability is tested. Therefore, in some embodiments, the number of the authentication requests may be plural, and when the number of the authentication requests is plural, a plurality of the authentication requests are in a concurrent state and a plurality of the authentication requests are in a concurrent state; the comparing the URL parameters and the authentication parameters to determine the test result may include:

comparing the URL parameter and the authentication parameter in each authentication request in the plurality of authentication requests in a consistent manner, and determining the error times;

if the error times are less than or equal to a preset threshold value, determining that the test result is successful;

and if the error times are larger than a preset threshold value, determining that the test result is test failure.

It should be noted that the number of errors is the number of authentication requests that have not been successfully executed, that is, the URL parameter and the target character in the received authentication parameter are not consistent.

If the error times are higher than the preset threshold value, the test fails, and the service equipment cannot cope with a scene with a large number of concurrent authentication requirements. Here, the preset threshold may be defined according to an actual application scenario.

Further, in some embodiments, the performing consistency comparison on the URL parameter and the authentication parameter in each of the plurality of authentication requests to determine the number of errors may include:

setting the initial count value of a preset counter to be 0;

in a plurality of authentication requests, comparing the URL parameter of one authentication request with the authentication parameter in a consistent manner;

if the URL parameter of one authentication request is not consistent with the target character in the authentication parameter, controlling a counter to add one;

after the URL parameter and the authentication parameter of each authentication request in a plurality of authentication requests are compared in a consistent mode, the current count value of a counter is obtained;

the current count value of the counter is determined as the number of errors.

It should be noted that, in the same authentication request, the URL parameter and the authentication parameter include the same target character; whereas in different authentication requests the target character is different. Therefore, whether the authentication request is successfully processed or not can be quickly determined by comparing the consistency of the URL and the authentication parameters.

Therefore, by introducing the counter, the error times can be automatically and quickly counted, so that the test result in a concurrent scene can be determined.

Particularly, the embodiment of the application can be applied to asynchronous callback interface testing, namely, the embodiment of the application provides a testing method for verifying whether callback information is consistent during concurrent processing and automatically asserting; of course, the embodiments of the present application can be applied to other test scenarios, which are not listed here.

The embodiment of the application provides a test method, which is applied to user equipment and used for sending an authentication request containing user parameters and uniform address locator (URL) parameters to service equipment, wherein the user parameters and the URL parameters both contain target characters; receiving authentication parameters returned by the service equipment based on the URL parameters; and comparing the consistency of the URL parameter and the authentication parameter according to the target character to determine a test result. Therefore, in the asynchronous callback interface test, the URL parameter and the authentication parameter are compared in consistency, whether the test is successful or not can be quickly determined, and the test efficiency is improved.

In another embodiment of the present application, refer to fig. 2, which shows a schematic flowchart of another testing method provided in the embodiment of the present application. As shown in fig. 2, the method may include:

s201: and receiving an authentication request which is sent by user equipment and contains user parameters and URL parameters, wherein the user parameters and the URL parameters both contain target characters.

It should be noted that the test method provided in the embodiment of the present application is applied to a service device, and the service device may be a variety of electronic devices, such as a server, a personal computer, a notebook computer, and the like.

In addition, the embodiment of the application also relates to user equipment, and the service equipment can process the authentication request of the user equipment. For example, the user device may be installed with a certain application client, and the service device may be installed with a certain application server.

In the embodiment of the present application, the service device receives an authentication request sent by the user device, and returns a corresponding authentication parameter to the user device. Specifically, the authentication request includes a user parameter and a URL parameter, the user parameter is used to specify which user's authentication parameter is required, and the URL parameter is used to inform the service device of an address when the authentication parameter is returned.

S202: and acquiring the authentication parameters based on the target characters in the user parameters.

It should be noted that there are many methods for acquiring the authentication parameters, for example, the service device stores a mapping relationship between the user parameter and a preset authentication parameter, or the service device can directly generate the authentication parameter according to the user parameter, or the service device can call another device to obtain the authentication parameter.

The scenario that the service device invokes another device (e.g., a database, another server) to obtain the authentication parameter is specifically described as an example, but this does not constitute a limitation of the embodiment of the present application.

In a common scenario, in receiving the authentication request, the service device needs to first obtain the user's own consent, and then obtain the authentication parameters from other devices. Therefore, in the embodiment of the present application, the user confirmation step and the parameter acquisition step are simulated by the first Mock server and the second Mock server, respectively.

Thus, 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 further comprise:

based on the user parameters, sending a user confirmation request to the first Mock server;

when detecting that the second asynchronous calling interface is called, receiving user confirmation information returned by the first Mock server;

and executing the step of acquiring the authentication parameters based on the target characters in the user parameters based on the user confirmation information.

Here, the first Mock server is used for simulation in a user confirmation step, the processing time of which is not determined, so that the interaction between the first Mock server and the service device can be designed as an asynchronous process.

Therefore, for the simulated parameter obtaining step of the second Mock server, in some embodiments, the obtaining the authentication parameter based on the target character in the user parameter includes:

based on the user parameters, sending a parameter acquisition request to a second Mock server so that the second Mock server generates authentication parameters based on target characters in the user parameters;

and receiving the authentication parameters returned by the second Mock server.

In order to facilitate the determination of the test result, the authentication parameter may be generated by using a target character, that is, the target character may be included in the authentication parameter. That is, under the premise of normal operation, the URL parameter, the user parameter and the authentication parameter all have the same target character.

Here, the interaction between the second Mock server and the service device may be an asynchronous call or a synchronous call. It should be understood that the manner of invocation between the service device and the first and second Mock servers should be determined based on the actual work process being tested.

S203: based on the URL parameter, sending an authentication parameter to the user equipment to enable the user equipment to determine a test result.

Here, the test result is obtained by comparing the URL parameter and the authentication parameter in accordance with the target character.

It should be noted that, on the premise that the program normally runs, since the URL parameter, the user parameter, and the authentication parameter all should include the target character, the test result can be quickly determined by performing consistency comparison on the URL parameter and the authentication parameter received by the URL.

Further, the interaction between the user device and the service device may be performed by means of an asynchronous process, and thus, in some embodiments, the URL parameter is used to indicate the first asynchronous call interface in the user device; the sending, to the user equipment, the authentication parameter based on the URL parameter may include:

calling a first asynchronous calling interface based on the URL parameter;

and sending the authentication parameters to the user equipment through the first asynchronous calling interface.

It should be noted that, in order to test whether the service device can normally process the authentication request in a concurrent state. Therefore, the user equipment can send a plurality of authentication requests simultaneously, the service equipment determines authentication parameters according to the user parameters in each authentication request, and returns the authentication parameters to the user equipment correspondingly according to the URL parameters in each authentication request.

In addition, in the above embodiment, the number of authentication requests is plural, and the plural authentication requests are in a concurrent state. In particular, in the same authentication request, the URL parameter and the user parameter have the same target character; the target character is different in different authentication requests.

The embodiment of the application provides a test method, which is applied to service equipment and used for receiving an authentication request which is sent by user equipment and contains user parameters and URL parameters, wherein the user parameters and the URL parameters both contain target characters; acquiring an authentication parameter based on a target character in the user parameter; based on the URL parameter, sending an authentication parameter to the user equipment to enable the user equipment to determine a test result. Therefore, in the asynchronous callback interface test, the URL parameter and the authentication parameter are compared in consistency, whether the test is successful or not can be quickly determined, and the test efficiency is improved.

In another embodiment of the present application, refer to fig. 3, which shows an interaction process schematic diagram of a test system provided in the embodiment of the present application. As shown in fig. 3, the test system includes a client (corresponding to the aforementioned user equipment), a system under test (corresponding to the aforementioned service equipment), a Mock1 (corresponding to the aforementioned first Mock server), and a Mock2 (corresponding to the aforementioned second Mock server).

Here, the client, the system under test, mock1 and Mock2 may all exist in the form of virtual machines, and in this case, the client, the system under test, mock1 and Mock2 may be mounted on the same physical device.

As shown in fig. 3, the interactive process of the test system may include the following steps:

s301: and the client sends an authentication request comprising the mobile phone number and the backsUrl to the tested system.

Here, the mobile phone number is equivalent to the user information, and the back URL is equivalent to the URL parameter;

s302: and the tested system sends a user confirmation request to Mock 1.

It should be noted that Mock1 simulates the main device corresponding to the mobile phone number in the actual scene, and therefore, the tested system actually sends the user confirmation request based on the mobile phone number.

S303: mock1 responds to the system under test.

It should be noted that Mock1 responds after receiving the confirmation request to simulate the process in the actual scene.

S304: and Mock1 returns the user confirmation information in an asynchronous callback mode.

It should be noted that, since the interaction between the system under test and Mock1 simulates the process of confirming the owner of the machine in the actual working process, the process involves the operation of the owner, and the time consumption cannot be predetermined, so that the process is generally executed in an asynchronous processing mode.

S305: and the tested system sends a parameter acquisition request to Mock 2.

It should be noted that the authentication request carries a mobile phone number, so that Mock2 generates an authentication parameter.

S306: and Mock2 returns the authentication parameters to the tested system.

It should be noted that Mock2 generates the authentication parameter according to the mobile phone number, and the generated authentication parameter is the same as the last three digits of the mobile phone number.

S307: and the tested system returns the authentication parameters to the client in an asynchronous callback mode.

That is, for the system under test, the system under test concurrently processes the client request (see step S301), requests and waits for the user confirmation information (see step S304), and further determines whether to acquire the authentication parameter (see step S305), and after the acquisition, the correct authentication parameter is finally transferred to the correct back url (see step S307).

For processing scenarios involving asynchronous calls, an important test point needs to be completed in addition to the conventional test: under a multi-concurrency scene, whether the tested system can transmit correct authentication information to correct back Url or not can be determined. In the related art, although a manual test can be adopted to complete the concurrent call of one or two users, in order to ensure the stability of the system under test, a test under a persistent and highly concurrent environment is required, so the embodiment of the application provides an automatic scheme with an automatically measurable result.

For the test system, the client compares the back Url with the received authentication parameters, so that whether the tested system feeds back correct authentication parameters can be quickly determined, and meanwhile, the test system can be provided with a counter to automatically count the error times of the high concurrency state. Specifically, as shown in fig. 4, the test flow of the test system includes the following steps:

s401: and configuring the test system.

It should be noted that, firstly, the test preparation is performed on the test system, which includes the following aspects: the method comprises the following steps that (1) the tested system configures addresses of Mock1 and Mock 2; (2) The client deploys 300 (the number can be modified according to the requirement) services of backUrl and the service of requesting the tested system; (3) client, mock1 and Mock2 are available. In addition, the client, the Mock1 and the Mock2 can be added into the system through the management platform after being modified and compiled.

S402: the reset counter is 0.

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

S403: the client side initiates 100 concurrent authentication requests, and each authentication request comprises backsUrl and a mobile phone number.

Here, in each authentication request, the suffix of the backhaul and the suffix of the mobile phone number are the same, and the suffixes of the mobile phone numbers are different between different authentication requests.

S404: after receiving the confirmation request of the tested system, the Mock1 returns 'agreement'.

S405: and after receiving the parameter acquisition request of the tested system, the Mock2 returns the authentication parameter, and the authentication parameter is the same as the suffix behind the mobile phone in the parameter acquisition request.

If the suffix of the mobile phone number in the parameter acquisition request is 001, token1 information (corresponding to authentication information) with a suffix of 1 is returned.

S406: after each backUrl of the client receives the authentication parameter, if the suffix of the authentication parameter is the same as that of the backUrl, the passing is carried out, otherwise, the counter is increased by 1.

S407: the value of the counter is obtained, if 0, the test passes, otherwise not,

it should be noted that if the value of the counter is 0, it indicates that the system under test correctly processes all the authentication requests, and the test is successful; otherwise, the system under test fails to process all the authentication requests correctly.

In a specific embodiment, the client, mock1 and Mock2 are all obtained from Mock service simulation, and are described below primarily around Mock service of three subsystems closely related to the system under test.

The client side is responsible for simulating the concurrent requests of the mobile phone numbers carried by a plurality of users and the backsurl, and simulating different backsurls to receive and analyze the correctness of the user authentication information. The concurrent number set when the client sends the request is less than or equal to the total number of the backUrl, and the mobile phone number is the same as the numeric suffix of the backUrl (the integer represented by three digits behind the mobile phone number and the integer represented by one to three digits behind the backUrl).

The Java function for consistency comparison between the backsUrl and the token is generated based on a Freemarker template, wherein the Freemarker template is shown as a code segment I, and the generated Java code segment for consistency comparison between the backsUrl and the authentication parameter is shown as a code segment II.

Code segment one:

code segment two:

according to the second code segment, when the token received by the back Url1 is the token1, the suffixes are the same, the authentication parameters received by the back Url are correct, otherwise, the number of times of errors is counted by the global variable total. And the value of total can be obtained through the interface, if total is 0, the test is passed, otherwise the test is failed. A reset (reset to 0) may also be performed through the interface.

The Mock1 is responsible for simulating user behavior information and realizing a user confirmation process.

Mock2 is responsible for simulating receiving a user authentication information request, generating and returning authentication information, and when generating the authentication information, the principle that an authentication parameter and a mobile phone number are identical to a suffix is required to be followed, for example: the mobile phone number is 1 × × 001, and the authentication information is token1.

The embodiment of the application provides a test system, and the specific implementation method of the embodiment is elaborated through the embodiment, so that it can be seen that, in the asynchronous callback interface test, through consistency comparison of the URL parameter and the authentication parameter, whether the test is successful or not can be quickly determined, and thus, the test efficiency is improved.

In yet another embodiment of the present application, refer to fig. 5, which shows a schematic flow chart of a Mock frame 50 provided by the embodiment of the present application. As shown in fig. 5, the Mock framework 10 is used to deploy virtual appliances; and the Mock framework 10 comprises an interface manager 501 and a class loader 502; wherein, the first and the second end of the pipe are connected with each other,

the interface manager 501 is configured to receive an interface increment instruction, and generate an interface increment code according to the interface increment instruction;

the class loader 502 is configured to load interface increment codes to implement interface increment processing on the virtual device.

It should be noted that, in the testing process, it is often necessary to simulate some devices and their interfaces that cannot be called directly by using the Mock framework. For example, it is necessary to test whether the service end of the service system can normally provide authentication information to the user end of the service system, but the client end of the service system may not be developed, and at this time, the Mock frame may be used to simulate the client end and its interface, so as to complete the test of the service end.

The Mock framework is a software framework used to develop analog devices. In the related art, codes are written according to devices to be simulated and interfaces thereof, and then virtual devices are obtained by deployment. However, if the interface of the virtual device needs to be incrementally modified, the code needs to be modified again, and the virtual device needs to be reloaded by using the class loader, which is very inconvenient.

Referring to fig. 5, the embodiment of the present application provides a Mock framework 10, which includes an interface manager 501 and a class loader 502, and after a virtual device is loaded through the Mock framework 10, an interface increment code may be generated by using the interface manager 501, and the interface increment code is loaded by the class loader 502, so that interface increment processing on the virtual device may be completed.

Here, the interface increment processing includes at least one of: interface adding processing, interface deleting processing, interface inquiring processing and interface modifying processing.

In other words, the interface manager 501 can complete the processing of adding, deleting, modifying, querying, etc. to the interfaces in the virtual device without modifying the virtual device in full.

It should be noted that in the foregoing embodiment, the user equipment, the first Mock server and the second Mock server may be deployed by using the Mock framework 10.

That is to say, the embodiment of the application separates the Mock and the class loader, and realizes incremental deployment. As shown in FIG. 6, the Mock framework may include sections such as a Serchelet component (e.g., a SpringCloud SercletBuan Register), a class loader (e.g., a Restful ClassLoader), an interface manager (Console), and an interface set.

In one particular embodiment, a SpringCloud SercletBean Register is used to provide a Server layer for interacting with other devices; the Restful ClassLoader is used for loading class codes so as to generate an interface of the virtual equipment or realize other functions of the virtual equipment; console, for incrementally modifying (such as adding, deleting, modifying, querying, etc.) the interface set; an interface set may be understood as a part of a virtual device that relates to an interface.

That is to say, in the embodiment of the present application, springCloud is used as a development framework, an incremental function interface is implemented according to Restful specifications, an originally centralized function interface is split, and is made manageable and describable, an interface manager Console is used to manage the function interface, so that manageability of codes is enhanced, the interface can be added, deleted, modified and queried, and the interface is changed and then loaded by Restful ClassLoader to be effective. On the premise of not replacing the whole engineering package, the changed interface or the newly added interface can be uploaded to the server, and the Restful ClassLoader loads the changed interface or the newly added interface to take effect.

Specifically. And (4) packaging the interface set of each group of Mock into a Jar package, and uploading a plurality of different jars into a warehouse. In the embodiment of the application, the Jar packages in the warehouse can be respectively analyzed, the interfaces contained in the Jar packages are validated, and the loaded classes are placed in the Tomcat configured by the SpringCloud. Therefore, the Mock service can be conveniently and incrementally expanded.

In addition, in the practice of the present application, the following conditions should be satisfied: (1) The Jar Package must be packaged (Package) according to a specified mode, so that a loader determines a file path of a Class file (Class) to load the Class file (Class); (2) The Java file must satisfy Jersey's Restful format; (3) And packaging is not required to contain the dependent packages, and all the dependent packages are put into the Lib library.

In summary, the embodiment of the application provides a Mock framework, so that when the Mock is expanded or modified, the whole project package is uploaded without being packed in full, and the Mock interface can be deployed in an incremental mode.

The embodiment of the application provides a Mock frame, wherein the Mock frame is used for deploying virtual equipment and comprises an interface manager and a class loader; the interface manager is used for receiving the interface increment instruction and generating an interface increment code according to the interface increment instruction; and the class loader is also used for loading the interface increment code so as to realize the interface increment processing of the virtual equipment. Therefore, when the Mock framework is used for deploying the virtual equipment, the interface in the virtual equipment can be conveniently subjected to incremental modification through the interface manager, and the workload of the incremental modification of the interface is reduced.

In a further embodiment of the present application, refer to fig. 7, which illustrates a schematic structural diagram of a user equipment 60 provided in an embodiment of the present application. As shown in fig. 7, the user equipment 60 includes a first sending unit 601, a first receiving unit 602, and a comparing unit 603; wherein, the first and the second end of the pipe are connected with each other,

a first sending unit 601, configured to send an authentication request including a user parameter and a URL parameter to a service device, where the user parameter and the URL parameter both include a target character;

a first receiving unit 602 configured to receive an authentication parameter returned by the service device based on the URL parameter;

the comparing unit 603 is configured to perform consistency comparison on the URL parameters and the authentication parameters according to the target characters, and determine a test result.

In some embodiments, the URL parameter is used to indicate a first asynchronous call interface in the user device; accordingly, the first receiving unit 602 is further configured to receive, through the first asynchronous call interface, the authentication parameter sent by the service device when detecting that the first asynchronous call interface is called.

In some embodiments, the comparing unit 603 is further configured to determine that the test result is a successful test if the target characters in the URL parameter and the authentication parameter are consistent; and if the URL parameters are not consistent with the target characters in the authentication parameters, determining that the test result is test failure.

In some embodiments, when the number of the authentication requests is plural, and the plural authentication requests are in a concurrent state; a comparing unit 603, further configured to perform consistency comparison on the URL parameter and the authentication parameter in each of the plurality of authentication requests, and determine the number of errors; if the error times are less than or equal to a preset threshold value, determining that the test result is successful; and if the error times are greater than a preset threshold value, determining that the test result is test failure.

In some embodiments, the comparing unit 603 is further configured to set an initial count value of the preset counter to 0; in a plurality of authentication requests, comparing the URL parameter of one authentication request with the authentication parameter in a consistent manner; if the URL parameter of one of the authentication requests is inconsistent with the target character in the authentication parameters, controlling a counter to add one; after the URL parameter and the authentication parameter of each authentication request in a plurality of authentication requests are compared in a consistent mode, the current count value of a counter is obtained; the current count value of the counter is determined as the number of errors.

In some embodiments, the characteristic character comprises a character combination formed by the last N bits in the parameter to be processed; wherein N is a positive integer.

It is to be understood that, in this embodiment, a "unit" may be a part of a circuit, a part of a first processor, a part of a program or software, etc., and may also be a module, and may also be non-modular. Moreover, each component in the embodiment may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware or a form of a software functional module.

Based on the understanding that the technical solution of the present embodiment essentially or a part contributing to the prior art, or all or part of the technical solution, may be embodied in the form of a software product stored in a storage medium, and include several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (first processor) to execute all or part of the steps of the method of the present embodiment. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, an optical disk, or other various media capable of storing program codes.

Accordingly, the present embodiment provides a computer storage medium storing a computer program which, when executed by a plurality of first processors, implements the steps of the method of any one of the preceding embodiments.

Based on the composition of the user equipment 60 and the computer storage medium, refer to fig. 8, which shows a schematic diagram of a hardware structure of the user equipment 60 according to an embodiment of the present application. As shown in fig. 8, the 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 by a first bus system 704. It is understood that the first bus system 704 is used to enable connection communications between these components. The first bus system 704 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, the various buses are labeled as first bus system 704 in fig. 8. The first communication interface 701 is configured to receive and send signals in a process of receiving and sending information with other external network elements;

a first memory 702 for storing a computer program capable of running on the first processor 703;

a first processor 703, configured to execute, when running the computer program:

receiving authentication parameters returned by the service equipment based on the URL parameters;

It will be appreciated that the first memory 702 in embodiments of the subject application can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. The non-volatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable PROM (EEPROM), or a flash Memory. Volatile Memory can be Random Access Memory (RAM), which acts as external cache Memory. By way of example, and not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), synchronous Dynamic Random Access Memory (SDRAM), double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), enhanced Synchronous SDRAM (ESDRAM), synchronous Link Dynamic Random Access Memory (SLDRAM), and Direct Rambus RAM (DRRAM). The first memory 702 of the apparatus and methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

The first processor 703 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the method may be implemented by integrated logic circuits of hardware or instructions in the form of software in the first processor 703. 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 device, discrete Gate or transistor logic device, or discrete hardware components. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in the first memory 702, and the first processor 703 reads the information in the first memory 702 and completes the steps of the method in combination with its hardware.

It is to be understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For a hardware implementation, the Processing units may be implemented within 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, micro-controllers, microprocessors, other electronic units configured to perform the functions of the present Application, or a combination thereof.

For a software implementation, the techniques of this application may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions of the present application. The software codes may be stored in a first memory and executed by a first processor. The first memory may be implemented in the first processor or external to the first processor.

Optionally, as another embodiment, the first processor 703 is further configured to, when running the computer program, perform the steps of the method of any of the previous embodiments.

The embodiment of the application provides user equipment which comprises a first sending unit, a first connecting unit and a comparing unit, wherein in the asynchronous callback interface test, the URL parameter and the authentication parameter are compared in consistency, so that whether the test is successful or not can be rapidly determined, and the test efficiency is further improved.

In a further embodiment of the present application, refer to fig. 9, which shows a schematic structural diagram of a service device 80 provided in an embodiment of the present application. As shown in fig. 9, the service apparatus 80 includes a second receiving unit 801, an obtaining unit 802, and a second sending unit 803, wherein,

a second receiving unit 801, configured to receive an authentication request sent by a user device, where the authentication request includes a user parameter and a URL parameter, and both the user parameter and the URL parameter include a target character;

an obtaining unit 802 configured to obtain an authentication parameter based on a target character in the user parameter;

a second sending unit 803 configured to send the authentication parameter to the user equipment based on the URL parameter, so that the user equipment determines the test result.

In some embodiments, the user confirmation request includes a callback address parameter indicating a second asynchronous call interface in the service device, and the obtaining unit 802 is further configured to send the user confirmation request to the first Mock server based on the user parameter; and receiving user confirmation information returned by the first Mock server when detecting that the second asynchronous calling interface is called.

In some embodiments, the obtaining unit 802 is further configured to send a parameter obtaining request to the second Mock server based on the user parameter, so that the second Mock server generates the authentication parameter based on the target character in the user parameter; and receiving the authentication parameters returned by the second Mock server.

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

In some embodiments, the number of authentication requests is multiple, and the multiple authentication requests are in a concurrent state.

It is understood that in this embodiment, a "unit" may be a part of a circuit, a part of a processor, a part of a program or software, etc., and may also be a module, or may also be non-modular. Moreover, each component in the embodiment may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a hardware mode, and can also be realized in a software functional module mode.

Based on the composition of the service device 80 and the computer storage medium, referring to fig. 10, which shows a specific hardware structure example of the service device 80 provided in the embodiment of the present application, as shown in fig. 10, 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 by a second bus system 904. It is understood that the second bus system 904 is used to enable connected communication between these components. The second bus system 904 includes a power bus, a control bus, and a status signal bus in addition to the data bus. But for clarity of illustration the various buses are labeled as the second bus system 904 in figure 10. Wherein, the first and the second end of the pipe are connected with each other,

a second communication interface 901, configured to receive and send signals in a process of sending and receiving information to and from other external network elements;

a second memory 902 for storing a computer program capable of running on the second processor 903;

a second processor 903 for performing, when running the computer program, the following:

and sending the authentication parameters to the user equipment based on the URL parameters so that the user equipment determines the test result.

Optionally, as another embodiment, the second processor 903 is further configured to execute the method of any one of the foregoing embodiments when running the computer program.

It is to be understood that the second memory 902 has hardware functionality similar to that of the first memory 702, and the second processor 903 has hardware functionality similar to that of the first processor 703; and will not be described in detail herein.

The embodiment of the application provides a service device, which comprises a second receiving unit, an obtaining unit and a second sending unit, wherein in the asynchronous callback interface test, the URL parameter and the authentication parameter are compared in consistency, so that whether the test is successful or not can be quickly determined, and the test efficiency is improved.

In a further embodiment of the present application, a test system is further provided, where the test system may include at least the user equipment 60 in any one of the foregoing embodiments and the service equipment 80 in any one of the foregoing embodiments.

In the embodiment of the present application, since the test system at least includes the user equipment 60 and the service equipment 80 in any one of the foregoing embodiments, in the asynchronous callback interface test, by performing consistency comparison on the URL parameter and the authentication parameter, it can be quickly determined whether the test is successful, so as to improve the test efficiency.

The above description is only a preferred embodiment of the present application, and is not intended to limit the scope of the present application.

It should be noted that, in the present application, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrases "comprising a component of' 8230; \8230;" does not exclude the presence of another like element in a process, method, article, or apparatus that comprises the element.

The above-mentioned serial numbers of the embodiments of the present application are merely for description, and do not represent the advantages and disadvantages of the embodiments.

The methods disclosed in the several method embodiments provided in the present application may be combined arbitrarily without conflict to obtain new method embodiments.

Features disclosed in several of the product embodiments provided in the present application may be combined in any combination to yield new product embodiments without conflict.

The features disclosed in the several method or apparatus embodiments provided in the present application may be combined arbitrarily, without conflict, to arrive at new method embodiments or apparatus embodiments.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A testing method applied to User Equipment (UE), the method comprising:

and comparing the URL parameters with the authentication parameters according to the target characters to determine a test result.

2. The test method of claim 1, wherein the URL parameter is used to indicate a first asynchronous call interface in the user equipment; the receiving of the authentication parameters returned by the service device based on the URL parameters includes:

and when detecting that the first asynchronous calling interface is called, receiving the authentication parameters sent by the service equipment through the first asynchronous calling interface.

3. The method according to claim 1, wherein the comparing the URL parameter and the authentication parameter according to the target character to determine a test result comprises:

if the URL parameter is consistent with the target character in the authentication parameter, determining that the test result is successful;

and if the URL parameter is inconsistent with the target character in the authentication parameter, determining that the test result is test failure.

4. The test method according to claim 1, wherein when the number of the authentication requests is plural, plural authentication requests are in a concurrent state; the consistency comparison of the URL parameter and the authentication parameter according to the target character to determine a test result comprises the following steps:

comparing the URL parameter and the authentication parameter of each authentication request in the plurality of authentication requests in a consistent manner, and determining the error times;

5. The method according to claim 4, wherein the comparing the URL parameter and the authentication parameter of each of the plurality of authentication requests for consistency to determine the number of errors comprises:

setting the initial count value of a preset counter to be 0;

if the URL parameter of one of the authentication requests is not consistent with the target character in the authentication parameters, controlling the counter to add one;

after the URL parameter and the authentication parameter of each authentication request in the plurality of authentication requests are subjected to consistency comparison, the current count value of the counter is obtained;

determining a current count value of the counter as the number of errors.

6. The test method according to any one of claims 1 to 5, wherein the characteristic character comprises a character combination formed by the last N bits in the parameter to be processed;

wherein, 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.

7. A testing method is applied to a service device, and the method comprises the following steps:

acquiring an authentication parameter based on the target character in the user parameter;

based on the URL parameter, sending the authentication parameter to the user equipment so that the user equipment determines a test result.

8. The method of claim 7, wherein the user confirmation request includes a callback address parameter, and wherein the callback address parameter indicates a second asynchronous call interface in the service device, the method further comprising:

sending a user confirmation request to the first Mock server based on the user parameters;

and executing the step of obtaining authentication parameters based on the user confirmation information.

9. The testing method according to claim 7 or 8, wherein the obtaining authentication parameters based on the target character in the user parameters comprises:

sending a parameter acquisition request to a second Mock server based on the user parameters, so that the second Mock server generates the authentication parameters based on the target characters in the user parameters;

and receiving the authentication parameters returned by the second Mock server.

10. The test method of claim 7, wherein the URL parameter is used to indicate a first asynchronous call interface in the user equipment; the sending the authentication parameters to the user equipment based on the URL parameters comprises:

calling the first asynchronous calling interface based on the URL parameter;

and sending the authentication parameters to the user equipment through the first asynchronous call interface.

11. A Mock framework is characterized in that the Mock framework is used for deploying virtual equipment and comprises an interface manager and a class loader; wherein the content of the first and second substances,

the interface manager is used for receiving an interface increment instruction and generating an interface increment code according to the interface increment instruction;

the class loader is used for loading the interface increment code so as to realize interface increment processing of the virtual equipment.

12. The Mock frame according to claim 11, wherein said interface delta processing comprises at least one of: interface adding processing, interface deleting processing, interface inquiring processing and interface modifying processing.

13. The Mock frame according to claim 11 or 12, wherein said virtual appliance comprises at least one of: the system comprises user equipment, a first Mock server and a second Mock server.

14. User equipment, characterized in that the user equipment comprises a first sending unit, a first receiving unit and a comparing unit; wherein the content of the first and second substances,

the first sending unit is configured to send an authentication request containing a user parameter and a uniform address locator (URL) parameter to service equipment, and the user parameter and the URL parameter both contain target characters;

the first receiving unit is configured to receive an authentication parameter returned by the service device based on the URL parameter;

the comparison unit is configured to perform consistency comparison on the URL parameter and the authentication parameter based on the target character, and determine a test result.

15. A user device, wherein the user device comprises a first memory and a first processor; wherein the content of the first and second substances,

the first memory for storing a computer program operable on the processor;

the first processor, when running the computer program, is configured to perform the steps of the method of any one of claims 1 to 6.

16. A service device, characterized in that the service device comprises a second receiving unit, an obtaining unit and a second sending unit; wherein, the first and the second end of the pipe are connected with each other,

the obtaining unit is configured to obtain an authentication parameter based on the user parameter;

the second sending unit is configured to send the authentication parameter to the user equipment based on the URL parameter, so that the user equipment determines a test result; and the test result is obtained by the user equipment after the URL parameter and the authentication parameter are subjected to consistency comparison based on the target character.

17. A service device, characterized in that the service device comprises a second memory and a second processor; wherein the content of the first and second substances,

the second memory for storing a computer program operable on the processor;

the second processor, when running the computer program, is configured to perform the steps of the method according to any of claims 7-10.

18. A computer storage medium, characterized in that it stores a computer program which, when executed by a first processor, implements the steps of the method according to any one of claims 1 to 6, or which, when executed by a second processor, implements the steps of the method according to any one of claims 7 to 10.