Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be described in detail and completely with reference to the following specific embodiments of the present application and the accompanying drawings. It should be apparent that the described embodiments are only some of the embodiments of the present application, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step are within the scope of the present application.
An HTML5 (HyperText Markup Language fifth generation standard, HTML5) application (also referred to as H5 application for short) is a web page or web application embedded in a Native App of a mobile phone, an HTML5 application needs to call a function provided by the Native App of the mobile phone, and the Native App loads an HTML5 application through an HTML5 application container, so that the HTML5 application is monitored through the HTML5 application container to complete a specific function and return a required result.
Therefore, when the HTML5 application is developed and tested, development and testing personnel are required to simulate the return result of the HTML5 application container, and the process is called mock. The methods for performing mock in the prior art are various as follows: the mock is realized by a method of directly modifying the service code, so that the service intrusion is large; the mock is carried out in a network agent mode, and network agent configuration is needed during verification, so that the method is very complicated; the content returned by the remote service is called as mock data, the mock data is not flexible enough, the returned content cannot be changed quickly, and the development and test work of the remote service can be influenced once the remote service is hung. In addition, the return result of the HTML5 application container is influenced by various aspects such as software, hardware, system environment, etc., and various returns such as normal and abnormal may be required for development and testing.
Based on this, the embodiments of the present specification provide a mock testing scheme, where a mock script is automatically injected into a client in a development server, so as to intercept a call request of an application to a container interface, and then forward the server. And then, a return result is determined through a mock configuration file local to the server side, so that more convenient test work is realized.
Fig. 1 is a schematic diagram of an architecture according to an embodiment of the present disclosure. In an embodiment of the present disclosure, the mock testing method may adopt a structure as shown in fig. 1, in which the client may be installed on a user terminal, such as a smart phone, a tablet computer, and the server may provide an address (e.g., a Uniform Resource Locator (URL)) for the user terminal to connect to. Since the present solution is generally used in development and testing, the service end is generally a testing service end. In other words, it should be a different server from the online server when the product is online.
The mock testing method provided in the embodiment of the present specification will be described in detail below based on the architecture shown in fig. 1, where the method specifically includes two aspects, namely a client and a server, and specifically includes the following steps for an execution flow in the aspect of the client, as shown in fig. 2, and fig. 2 is a schematic flow diagram of the mock testing method in the aspect of the client provided in the embodiment of the present specification, and includes:
s201, the client side initiates a request for calling the container interface.
As mentioned above, the application to be tested calls the native functions of the handset through the container interface, where the container interface may be one or more according to the service content of the application to be tested. Such call requests may occur frequently during execution of non-native applications. For example, some web applications cannot invoke hardware devices (voice, camera, gravity sensing, etc.) of a cell phone terminal, thereby enabling these hardware devices by invoking the native application container interface of the user terminal. In other words, the request to invoke the container interface may be a functional request or a page access request.
S203, intercepting the request and sending the request to the server so that the server can respond to the request and return a corresponding mock response result or return the request to the container interface.
Interception of the interface call request may be achieved in a number of ways, for example, using a Spring interceptor when the interface is called. After intercepting the call request, the request is directly sent to a server (also called a test server), and the server decides to return by using a mock response result or pass through to a container real interface.
In practical application, a program file (i.e. mock object) for mock can be created according to preset test content, and a corresponding mock response result is generated according to a corresponding request. The Mock object is mainly used for simulating an object which is not easy to construct or complex in application so as to carry out testing.
And testing by inputting a mock object in the server in advance. Then, by determining in advance (which may be implemented by a configuration file or by a logic code), whether a real result (that is, a transparent transmission request to a container interface, the container interface calls a mobile phone native function, and returned real data) or a mock response result (that is, mock data obtained after the request is sent to a mock object) is to be returned in the test, if the content of the test is to be changed to perform different tests, it is only necessary to modify the mock object correspondingly or configure the script.
For example, a certain webpage provides a shopping function at9 points per day, if a real object is adopted, the test can be performed only by waiting for 9 points per day, and if a mock test object is adopted, the test can be performed only by simulating the time to 9 points. If the testing time is modified to be 20 points, the modification can be easily carried out in the mock object, so that the whole testing process is more flexible.
For another example, the mock object A function returns detailed information of the commodity according to the received commodity name; the mock object B has the function of popping up suggestive page information (for example, 20 points and 55 points each day, a pop-up prompt is given, and a certain commodity enters a quick shot at 21 points) at the set system time, so that if a user needs to test, the mock objects A and B can be injected into a local server in advance, and the function A and/or the function B of the test can be determined through a predetermined configuration file. And after the client sends a page request, determining the called object according to the configuration file through intercepting the request, and acquiring a result. The result here includes a return result of the mock object or a container interface that passes through the request to the client so that the container interface performs the calling function locally at the user terminal according to the request. For the same container interface call request, only one of the two (mock response result or transparent transmission request to the container interface) is returned.
And S205, receiving a return result of the server and performing service processing.
As described above, the return result of the server may be a mock response result to the request response, or the server may return the request to the container interface. Under the condition that the server transparently transmits the request to the container interface, the container interface further executes corresponding service processing according to the request, for example, some hardware functions of a local mobile phone are called, or the server requests page access and the like, so that a real corresponding result is obtained.
The result of the application request process is influenced by software, hardware, system environment and other aspects, which is also the purpose of service test. And combining the mock corresponding result and/or the real response result to obtain the final service processing result requested by the client, wherein if the final service processing result is consistent with the expected result, the service code operates normally. If the returned result is not in accordance with the expectation, that is, the test result is abnormal, the debugging is required to be carried out again.
In the scheme, the request of calling the container interface by the application to be tested is intercepted, the server is forwarded, and whether the returned result is a real result or a mock response result is determined through a mock configuration file in the server, so that various service tests are performed. In the test process, the user terminal can directly access the page provided by the development server without configuration, so that other people can conveniently test and verify; the product is on-line after the test is successful, the service code is not changed, and the corresponding configuration file is not required to be modified in the service code, so that the on-line fault caused by forgetting to switch the code when the product is on-line is fundamentally solved.
In a specific embodiment, in the process of performing application development and test, as for a manner of intercepting the request, the following method may be adopted: and intercepting the request and sending the request to a server through a pre-injected mock script.
The pre-injection mode can be that the injection is manually performed to the client by a user; but it is more convenient, or it may be automatically injected to the client through the server, for example, when the client accesses the address provided by the server for the first time, a pre-written mock script is injected to the client to intercept the call request of the container interface.
In this way, the injected mock script disables the capacity of the original container processing interface, the request is still sent out in the container, but because the mock script is injected, the container loses the direct control of the request, the request is intercepted and directly sent to the server, and the server determines to return the mock response result or transmit the mock response result to the real container interface to return the real response result, so that the dynamic change can be realized, and the test is more convenient.
As a specific embodiment, the aforementioned request comprises an HTML5 page request, and the container interface comprises an HTML5 application container interface. In other words, the native applications in the system are tested for the function of loading web pages or web applications through the HTML5 container, which is the most common content to be tested in developing HTML5 applications. In this case, the mock object includes a simulation of the HTML5 application container.
In practical applications, the HTML5 application needs to call the interface provided by the HTML5 container to call the functions provided by the native mobile phone system. The Mock test object also describes the object using an interface through which the object is referenced during the test. In other words, during the test process, the client does not know whether the object accessed this time is the real test object or the mock test object.
The above description is mainly a description of an execution flow in the client side, and the execution flow in the server side specifically includes the following steps, as shown in fig. 3, fig. 3 is a schematic flow diagram of a mock testing method in the server side provided in the embodiment of the present specification, and includes:
s301, a server receives a request of a client for calling a container interface, wherein the request is intercepted by a mock script;
s303, responding to the request, and determining to return a corresponding mock response result or return the request to the container interface;
s305, sending the return result of the request to the client.
As a specific implementation manner, in the implementation process, the server may further automatically inject a mock script for interception into the client, including: and injecting a mock script into the client, wherein the mock script is used for intercepting a request for calling a container interface sent by the client and forwarding the request to the server. The script is automatically injected into the client through the server, so that the test can be conveniently carried out through various different terminal devices during the test without additional setting.
The server may be implemented based on predefined logic code when determining to return a result in response to a request. Further, the logic code may also be displayed in a configuration file, and a response result of the request is determined through the configuration file (including accessing the mock object to obtain a mock response result, or transparently transmitting the request to a container interface of the client, so that the container interface further performs service processing to obtain a real result). Usually, the code corresponding to the part of the logic code or configuration file is isolated from the service code.
In practical applications, a plurality of container interfaces may need to be called for a request, so that in the testing process, it can be determined according to actual needs which contents are tested, whether the request needs to be transparently transmitted or not, and the degree of the transparent transmission. In other words, by setting in the configuration file in advance to determine the result returned this time, it is possible to flexibly configure whether mock data or real data is returned. Specifically, the following three modes can be included:
determining that all returned results of the request are transparent transmission of the request to the container interface, wherein in the mode, all requests of the client side are transparent transmission; or,
determining that all returned results of the request are the mock response results; or,
and determining that the part of the returned result of the request is the mock response result, and the rest part of the returned result is the transparent transmission of the request to the container interface.
In practical application, most of the returned results during testing are the mock response results, and the rest of the returned results are transparent transmission of the request to the container interface (in one test request, multiple interfaces may be called to access multiple objects, and partial real tests are often required). That is, the server performs partial transparent transmission on the request through the configuration file to perform corresponding testing, and in this embodiment, the part of the interface call request which is not transmitted through jumps to the mock object, so that the returned result of the client is the returned result of the real HTML5 container interface in part and the returned result of the mock object in part.
Certainly, in practical application, if the test is successful, the server side should realize complete transparent transmission after the product is on line without problems. After the product is online, the product is deployed in an online server (i.e., not a test server for testing), and the client accesses the online server or accesses an offline package page at this time. Because the entries are different, the client cannot access the above-mentioned test server, so that the aforementioned process of automatically injecting scripts, even no interception process, and obviously the above-mentioned process of jumping to mock test objects are not possible, all requests are directly passed through to the real container interface, and the return results are also the return of the real HTML5 container. As shown in fig. 4, fig. 4 is a schematic diagram of an actual online call after a product is online according to an embodiment of the present disclosure.
In the scheme, the server side flexibly controls whether the returned return is real return or mock return through the configuration file, and the flexibility is strong, so that dynamic change is realized, and self-maintenance and expansion are facilitated. In addition, the server side automatically injects the mock script into the client side, and the user terminal can test by directly accessing the page provided by the local development server without any configuration, so that other people can conveniently test and verify; the product is on-line after the test is successful, the service code is not changed, and the corresponding configuration file is not required to be modified in the service code, so that the problem of on-line fault caused by forgetting to switch the code when the product is on-line is fundamentally solved
In the testing process, the mock script or the configuration file thereof is required to be modified, the service code is not changed, and the corresponding configuration file is not required to be modified in the service code, so that the flexibility is strong, and the self-maintenance and the expansion are convenient.
Different test contents can be realized through different mock scripts. For the same application to be tested, the user can also decide whether to use the interface of the real HTML5 container to return or the mock object to return by modifying the configuration file, so that the test is more flexible and convenient, and the following method can be specifically adopted: receiving an instruction of a user to modify the configuration file; and determining the object accessed this time according to the modified configuration file and the request.
As a specific implementation mode, the client and the server are both located locally, and the local server and the client are adopted for testing, so that modification and configuration can be conveniently carried out, and the condition that the remote service cannot work due to unavailability can be effectively avoided.
In the embodiment of the present specification, whether the server side or the mock script can be implemented in various ways. Js, the mock script is developed through a JavaScript language, and in the development process, codes of a configuration file of the mock script are isolated from service codes and codes of a mock object.
As a particular embodiment, the request comprises an HTML5 page request and the container interface comprises an HTML5 application container interface.
Based on the same idea, the present invention further provides a mock testing device, as shown in fig. 5, where fig. 5 is a schematic structural diagram of the mock testing device in the client side provided in the embodiment of the present specification, and the mock testing device includes:
a request initiating module 501, where a client initiates a request for calling a container interface;
the intercepting module 503 intercepts the request and sends the request to the server, so that the server responds to the request and returns a corresponding mock response result or returns the request to the container interface;
and the receiving module 505 is configured to receive a return result of the server and perform service processing.
Further, if the server returns the request to the container interface, the receiving module 505 obtains a real response result obtained by processing the request returned by the server through the container interface; and performing service processing according to the real response result.
Further, the intercepting module 503 intercepts the request through a pre-injected mock script and sends the request to the server.
Further, the request comprises an HTML5 page request, and the container interface comprises an HTML5 application container interface.
Based on the same idea, the present invention further provides another mock testing device, as shown in fig. 6, where fig. 6 is a schematic structural diagram of a mock testing device in the aspect of a server side provided in the embodiments of the present specification, and the schematic structural diagram includes:
a receiving module 601, where a server receives a request for a client to call a container interface, and the request is intercepted by a mock script;
the determining module 603, configured to determine to return a corresponding mock response result or return the request to the container interface in response to the request;
the sending module 605 sends the returned result of the request to the client.
Further, the apparatus further includes an injection module 607, which is configured to inject a mock script into the client, where the mock script is used to intercept a request sent by the client to call the container interface, and forward the request to the server.
Further, the determining module 603, based on a preset configuration file, determines to return a corresponding mock response result or return the request to the container interface in response to the request
Further, the determining module 603 determines that all returned results of the current request are the mock response result; or, determining that all return results of the request are to return the request to the container interface; or, determining that part of the returned result of the request is the mock response result, and the rest is returning the request to the container interface.
Further, the receiving module 601 is further configured to receive an instruction of a user to modify the configuration file; the determining module 603, responding to the request according to the modified configuration file, determining a return result of the request
Further, the server and the mock script are based on JavaScript.
Further, the client and the server are both located locally
Further, the request comprises an HTML5 page request, and the container interface comprises an HTML5 application container interface.
Correspondingly, the embodiment of the present application further provides a mock test device, where the mock test device includes:
the memory stores a mock test program;
and the processor calls the mock test program in the memory and executes the following steps:
the client initiates a request for calling a container interface;
intercepting the request and sending the request to a server so that the server can respond to the request and return a corresponding mock response result or return the request to the container interface;
and receiving a return result of the server side, and performing service processing.
Correspondingly, an embodiment of the present application further provides another mock test device, where the device includes:
the memory stores a mock test program;
and the processor calls the mock test program in the memory and executes the following steps:
the server receives a request of calling a container interface from the client, wherein the request is intercepted by a mock script;
responding to the request, and determining to return a corresponding mock response result or return the request to the container interface;
and sending a return result of the request to the client.
Based on the same inventive concept, embodiments of the present specification further provide a non-volatile computer storage medium storing computer-executable instructions configured to:
the client initiates a request for calling a container interface;
intercepting the request and sending the request to a server so that the server can respond to the request and return a corresponding mock response result or return the request to the container interface;
and receiving a return result of the server side, and performing service processing.
Based on the same inventive concept, embodiments of the present specification further provide another non-volatile computer storage medium storing computer-executable instructions configured to:
the server receives a request of calling a container interface from the client, wherein the request is intercepted by a mock script;
responding to the request, and determining to return a corresponding mock response result or return the request to the container interface;
and sending a return result of the request to the client.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. Especially, as for the device, apparatus and medium type embodiments, since they are basically similar to the method embodiments, the description is simple, and the related points may refer to part of the description of the method embodiments, which is not repeated here.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps or modules recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.
The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the units may be implemented in the same software and/or hardware or in one or more pieces of software and/or hardware when implementing the embodiments of the present description.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include transitory computer readable media (transient media) such as modulated data signal numbers and carrier waves.
It should also be noted that 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 phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
As will be appreciated by one skilled in the art, one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.
Embodiments of the present description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular transactions or implement particular abstract data types. Embodiments of the present description may also be practiced in distributed computing environments where transactions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The above description is only an example of the present specification, and is not intended to limit the present application. Various modifications and changes may occur to the embodiments described herein, as will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the embodiments of the present specification should be included in the scope of the claims of the present application.