CN112416750A - Application program boundary testing method and system - Google Patents
Application program boundary testing method and system Download PDFInfo
- Publication number
- CN112416750A CN112416750A CN202011079029.5A CN202011079029A CN112416750A CN 112416750 A CN112416750 A CN 112416750A CN 202011079029 A CN202011079029 A CN 202011079029A CN 112416750 A CN112416750 A CN 112416750A
- Authority
- CN
- China
- Prior art keywords
- boundary
- test
- tested
- data
- application program
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012360 testing method Methods 0.000 title claims abstract description 328
- 238000004088 simulation Methods 0.000 claims abstract description 36
- 238000000034 method Methods 0.000 claims description 48
- 230000009471 action Effects 0.000 claims description 10
- 238000010998 test method Methods 0.000 claims description 4
- 230000008569 process Effects 0.000 description 23
- 230000006870 function Effects 0.000 description 14
- 238000010586 diagram Methods 0.000 description 9
- 230000002159 abnormal effect Effects 0.000 description 5
- 230000008859 change Effects 0.000 description 4
- 230000000694 effects Effects 0.000 description 3
- 230000010354 integration Effects 0.000 description 3
- 238000009877 rendering Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 230000000763 evoking effect Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000008094 contradictory effect Effects 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application discloses an application program boundary testing method, which comprises the following steps: configuring an automatic test script corresponding to the boundary test of the APP to be tested and a data structure of each interface; when a configuration request of an APP to be tested is received, an automatic test script is sent to the APP to be tested, so that the APP to be tested automatically carries out boundary test according to the automatic test script; when an interface data request of an APP to be tested is received, dynamically generating simulation boundary data corresponding to the interface according to the data structure; and returning the simulation boundary data to the APP to be tested so that the APP to be tested uses the simulation boundary data in the boundary test. The application also discloses an application program boundary testing system, an electronic device and a computer readable storage medium. Therefore, the full boundary data can be dynamically generated, the boundary conditions of a series of page interfaces can be automatically tested, and manual intervention is not needed.
Description
Technical Field
The present disclosure relates to the field of testing technologies, and in particular, to a method, a system, an electronic device, and a computer-readable storage medium for testing application program boundaries.
Background
When performing a boundary test on an APP (Application), various interface data needs to be requested from a server. In the existing test scheme, because interfaces of all current APP pages are https requests, when a client APP requests interface data, the client APP can be realized through agent software, and the agent software requests a server and returns correspondingly configured interface data. For the client electronic device of the android system, a Personal Computer (PC) needs to be connected, proxy software (e.g., Charles) is started in the PC, a host of the PC is configured, interface data is downloaded from a server, and finally, a Uniform Resource Locator (URL) is set to return the interface data downloaded from the server.
However, since a variety of boundary data, i.e. various abnormal situations of each field of the interface data, are generally required in the test process, different fields or modification of the value of a field is often required. The existing test scheme is not integrated in the aspects of host switching, interface data management and the like, and is relatively dispersed. The interface data needs to be modified each time a different field is needed or the value of a field needs to be modified, and the interface is requested again to obtain the data needed by the test. And when the APP to be tested is suddenly withdrawn (the APP to be tested is suddenly withdrawn from the interruption in the running process, the picture is flashed and is withdrawn to the desktop), the APP cannot be called, and the test cannot be automatically continued.
Therefore, the existing test scheme has no capability of dynamically and automatically modifying the boundary data field, and has no platform for providing the automatic test of the dynamic boundary data. The client also has no scheme for non-intrusive integrated dynamic boundary data testing to continuously test various boundary data after acquiring configuration data to check possible abnormal data conditions.
It should be noted that the above-mentioned contents are not intended to limit the scope of protection of the application.
Disclosure of Invention
The present application mainly aims to provide an application boundary testing method, system, electronic device and computer readable storage medium, aiming at solving the problem of how to provide an application boundary testing scheme capable of dynamically and automatically modifying boundary data fields and automatically testing.
In order to achieve the above object, an embodiment of the present application provides an application boundary testing method, where the method includes:
configuring an automatic test script corresponding to the boundary test of the application program to be tested and a data structure of each interface;
when a configuration request of the application program to be tested is received, the automatic test script is sent to the application program to be tested, so that the application program to be tested automatically carries out boundary test according to the automatic test script;
when an interface data request of the application program to be tested is received, dynamically generating simulation boundary data corresponding to the interface according to the configured data structure; and
and returning the simulation boundary data to the application program to be tested so that the application program to be tested can use the simulation boundary data in the boundary test.
Optionally, after returning the simulation boundary data to the application under test, the method further includes:
and when the application program to be tested carries out the boundary test according to the simulated boundary data and is subjected to flash back, delaying to re-call the application program to be tested so as to continue the boundary test.
Optionally, the automated test script includes an action to be executed in the boundary test, a test scenario/step, and a test frequency of each test scenario.
Optionally, when an interface data request of the application program to be tested is received, dynamically generating simulation boundary data corresponding to the interface according to the configured data structure includes:
and matching the data structure of the corresponding interface according to the address identifier in the interface data request, thereby dynamically generating the full amount of simulation boundary data according to the data structure.
Optionally, when receiving an interface data request of the application program to be tested, dynamically generating simulation boundary data corresponding to the interface according to the configured data structure further includes:
and matching the corresponding test times in the automatic test script according to the address identification in the interface data request, and dynamically generating and returning the simulation boundary data according to the times corresponding to the test times.
Optionally, sending, by the application program to be tested, the interface data request and returning, by the application program to be tested, the simulation boundary data are both implemented by an http proxy.
Optionally, when configuring the automated test script corresponding to the boundary test of the application program to be tested and the data structure of each interface, the method further includes:
and binding the device IP of the application program to be tested, the corresponding automatic test script and the configuration of the data structure so as to repeatedly run the boundary test.
Optionally, when the boundary test performed by the application program to be tested according to the simulated boundary data is flashed back, delaying to re-wake up the application program to be tested to continue the boundary test includes:
receiving the flash quit information reported by the application program to be tested;
calling a daemon unit and transmitting the current testing step of the boundary test to the daemon unit;
and the daemon unit re-calls the application program to be tested after a preset time delay, and the boundary test is continued from the test step.
Optionally, after the application program to be tested is re-awakened after the delay, the method further includes:
and collecting the flash quit information and the data when the flash quit is called each time, and finishing to generate a boundary test flash quit report form after the boundary test is finished.
In addition, to achieve the above object, an embodiment of the present application further provides an application boundary testing system, where the system includes:
the configuration module is used for configuring an automatic test script corresponding to the boundary test of the application program to be tested and a data structure of each interface;
the sending module is used for sending the automatic test script to the application program to be tested when receiving the configuration request of the application program to be tested, so that the application program to be tested automatically carries out boundary test according to the automatic test script;
the simulation module is used for dynamically generating simulation boundary data corresponding to the interface according to the configured data structure when receiving an interface data request of the application program to be tested; and
and the return module is used for returning the simulation boundary data to the application program to be tested so that the application program to be tested can use the simulation boundary data in the boundary test.
In order to achieve the above object, an embodiment of the present application further provides an electronic device, including: the system comprises a memory, a processor and an application program boundary test program which is stored on the memory and can run on the processor, wherein when the application program boundary test program is executed by the processor, the application program boundary test program realizes the application program boundary test method.
To achieve the above object, an embodiment of the present application further provides a computer-readable storage medium, on which an application boundary testing program is stored, and the application boundary testing program, when executed by a processor, implements the application boundary testing method as described above.
The application program boundary testing method, the application program boundary testing system, the electronic device and the computer readable storage medium provided by the embodiment of the application program can be used for pre-configuring the data structure of each interface, automatically changing according to the interface data request of the application program to be tested each time and the data structure, and finally dynamically generating the full boundary data. And by configuring the automatic test script aiming at the boundary test of the application program to be tested and the dynamically generated full boundary data, the boundary conditions of a series of page interfaces can be automatically tested, manual intervention is not needed, full automatic test of all the pages and the interfaces to be tested is realized, and the test cost is greatly saved.
Drawings
FIG. 1 is a diagram of an application environment architecture in which various embodiments of the present application may be implemented;
FIG. 2 is a flowchart of an application boundary testing method according to a first embodiment of the present application;
FIG. 3 is a flowchart of an application boundary testing method according to a second embodiment of the present application;
FIG. 4 is a schematic diagram of a boundary test process performed at a client in the present application;
fig. 5 is a schematic hardware architecture diagram of an electronic device according to a third embodiment of the present application;
FIG. 6 is a block diagram of an application boundary testing system according to a fourth embodiment of the present application;
fig. 7 is a block diagram of an application boundary testing system according to a fifth embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
It should be noted that the descriptions relating to "first", "second", etc. in the embodiments of the present application are only for descriptive purposes and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In addition, technical solutions between various embodiments may be combined with each other, but must be realized by a person skilled in the art, and when the technical solutions are contradictory or cannot be realized, such a combination should not be considered to exist, and is not within the protection scope of the present application.
Referring to fig. 1, fig. 1 is a diagram illustrating an application environment architecture for implementing various embodiments of the present application. The Application can be applied to an Application environment including, but not limited to, an APP (Application) 2 to be tested, an agent unit 4, and an Application boundary test system 6.
The application program boundary test system 6 (i.e. Mock platform) is used for configuring an automatic test script and a data structure corresponding to each interface for the boundary test of the to-be-tested APP 2, dynamically generating (simulating) boundary data corresponding to the interface according to the data structure of the interface when an interface data request is sent in the test process of the to-be-tested APP 2, and returning the boundary data to the to-be-tested APP 2 to complete the boundary test.
The APP 2 to be tested is used for performing boundary test according to the automatic test script, sending an interface data request to the application program boundary test system 6 in the test process, and receiving boundary data returned by the application program boundary test system 6.
The agent unit 4 is configured to provide an http agent for the APP 2 to be tested, and transfer each request and returned data between the APP 2 to be tested and the application program boundary test system 6.
For the client device of the iOS system, the APP 2 to be tested, the agent unit 4, and the application boundary test system 6 may all be located in the device. To the client device of Android (Android) system, need to connect PC (Personal Computer) end, APP 2 that awaits measuring is located in the client device, agent unit 4 and application program boundary test system are located in the PC. Between the PC and the client device, various operations (installation and debugging applications) of the client device are performed on the PC by an ADB (Android Debug Bridge) script. In the application, the client device mainly refers to mobile terminals such as mobile phones, tablet computers and wearable devices.
Example one
Fig. 2 is a flowchart of an application boundary testing method according to a first embodiment of the present application. It is to be understood that the flow charts in the embodiments of the present method are not intended to limit the order in which the steps are performed. Some steps in the flowchart may be added or deleted as desired.
The method comprises the following steps:
s200, configuring an automatic test script corresponding to the APP boundary test and a data structure of each interface.
When the boundary test is performed on the APP to be tested, various interface data need to be requested from the server. The existing test scheme cannot dynamically and automatically modify the boundary data fields of each interface, but the embodiment can simulate the full boundary data of each interface required by the test through a Mock platform. In this embodiment, the data structures corresponding to the interfaces may be pre-configured at the back end, so that the boundary data required by the test may be dynamically generated according to the data structures during the subsequent test. That is, the existing interface data structure is stored in the system, and can be automatically changed according to each request during subsequent testing, and finally, the full amount of boundary data is generated.
In addition, aiming at the situation that the existing test scheme cannot perform automatic test on dynamic boundary data, the automatic test script for performing boundary test on the to-be-tested APP is also pre-configured in the embodiment so that the to-be-tested APP can automatically complete the test according to the automatic test script. The automated test script includes, but is not limited to, an action (action) to be executed, a test scenario/step (scheme/step), the number of times each test scenario is to be tested, an operation opportunity, and a description of required parameters.
Through the configuration of the automatic test script and the interface data structure, the full-automatic test of all the pages and interfaces to be tested can be automatically realized after the test is started, and the functions of suspending the test, resuming the test, resetting the test and the like can be provided.
S202, when receiving a configuration request of an APP to be tested, providing the automatic test script for the APP to be tested, and enabling the APP to be tested to automatically perform boundary test according to the automatic test script.
In this embodiment, a Client (Client, i.e. the APP to be tested in this embodiment) connects to the proxy unit and initiates a configuration request (request config interface), which may obtain the preconfigured automation test script. And then the APP to be tested opens a page according to the automatic test script, carries out automatic boundary test, and initiates an interface data request in the page.
It is worth noting that the client starts the normal flow of the APP to be tested after receiving the automatic test script, and performs operations such as rendering a page, and the like, and does not need to modify the code of the relevant normal flow, and the automatic test script code introduced through Debug macro control only takes effect in the test stage, and cannot be brought online, so that non-intrusive integration can be realized, that is, certain functions (boundary test) are added through the code or the script under the condition that the online code is not modified and the existing APP functions are not affected.
And S204, when the interface data request of the APP to be detected is received, dynamically generating boundary data corresponding to the interface according to the configured data structure.
When receiving an interface data request sent by the APP to be tested in the process of performing boundary test, the Mock platform can simulate to return interface data, namely, automatically and dynamically generate (modify) boundary data (various abnormal conditions of each field of the interface data) corresponding to the interface according to the data structure of the interface, and then return the boundary data to the APP to be tested. The address identifier (in this embodiment, a URL) in the interface data request may be matched to a corresponding pre-configured interface data structure, so that the full amount of boundary data is dynamically generated according to the interface data structure. In addition, the corresponding test times in the automatic test script can be matched according to the URL in the interface data request, the times of modifying the boundary data by the Mock platform is guided, and the boundary data with the corresponding times is returned. And accumulating the indexes (index) recorded by the current interface by the Mock platform every time the Mock platform requests for one time, and continuously increasing the indexes until the boundary data of all the conditions corresponding to the test times are generated.
In this embodiment, the Mock platform can simulate different boundary data for different interfaces according to the data structure of each interface, and return different boundary data after receiving an interface data request every time within a limited number of times and a limited range, so as to form a limited boundary data set, thereby realizing the full coverage of the boundary data.
S206, returning the boundary data to the APP to be tested so that the APP to be tested uses the boundary data in the boundary test.
After the boundary data corresponding to the interface is simulated each time, the boundary data is returned to the client through the proxy unit, and the interface data acquired by the client each time is the (simulated) boundary data modified by the Mock platform. Through the total boundary data simulated by the Mock platform, the APP to be tested can realize the total automatic test of various boundary conditions of each page interface. Through the http agent of the agent unit, the interference to the existing code of the APP to be tested can be reduced, and the normal flow and the function of the APP to be tested are not influenced.
Moreover, the Mock platform can reset or set the test scheme/step corresponding to each client device (APP to be tested), bind the client device IP and the corresponding Mock configuration (automated test script, interface data structure, etc.), and thus can run the test repeatedly.
In addition, the Mock platform can record each request of the user side and can display the parameters of each request and the returned data on the webpage in real time.
The application program boundary testing method provided in this embodiment may be configured with the data structure of each interface in advance, and automatically change according to each interface data request of the APP to be tested and the data structure, and finally dynamically generate the full amount of boundary data. And the boundary conditions of a series of page interfaces can be automatically tested by configuring the automatic test script aiming at the boundary test of the APP to be tested and the dynamically generated full boundary data, so that the full automatic test of all the pages and interfaces to be tested is realized without manual intervention, and the test cost is greatly saved.
Example two
Fig. 3 is a flowchart of an application boundary testing method according to a second embodiment of the present application. In the second embodiment, the method for testing application boundaries further includes step S308 based on the first embodiment. It is to be understood that the flow charts in the embodiments of the present method are not intended to limit the order in which the steps are performed. Some steps in the flowchart may be added or deleted as desired.
The method comprises the following steps:
s300, configuring an automatic test script corresponding to the APP boundary test and a data structure of each interface.
When the boundary test is performed on the APP to be tested, various interface data need to be requested from the server. The existing test scheme cannot dynamically and automatically modify the boundary data fields of each interface, but the embodiment can simulate the full boundary data of each interface required by the test through a Mock platform. In this embodiment, the data structures corresponding to the interfaces may be pre-configured at the back end, so that the boundary data required by the test may be dynamically generated according to the data structures during the subsequent test. That is, the existing interface data structure is stored in the system, and can be automatically changed according to each request during subsequent testing, and finally, the full amount of boundary data is generated.
In addition, aiming at the situation that the existing test scheme cannot perform automatic test on dynamic boundary data, the automatic test script for performing boundary test on the to-be-tested APP is also pre-configured in the embodiment so that the to-be-tested APP can automatically complete the test according to the automatic test script. The automated test script includes, but is not limited to, actions to be performed, test scenarios/steps, number of times each test scenario is to be tested, run time, and required parameter descriptions.
Through the configuration of the automatic test script and the interface data structure, the full-automatic test of all the pages and interfaces to be tested can be automatically realized after the test is started, and the functions of suspending the test, resuming the test, resetting the test and the like can be provided.
S302, when a configuration request of an APP to be tested is received, the APP to be tested is provided with the automatic test script, and the APP to be tested is enabled to automatically perform boundary test according to the automatic test script.
In this embodiment, the client (APP to be tested) connects to the proxy unit and initiates a configuration request (request the config interface), so as to obtain the preconfigured automation test script. And then the APP to be tested opens a page according to the automatic test script, carries out automatic boundary test, and initiates an interface data request in the page.
It is worth noting that the client starts the normal flow of the APP to be tested after receiving the automatic test script, and performs operations such as rendering a page, and the like, and does not need to modify the code of the relevant normal flow, and the automatic test script code introduced through Debug macro control only takes effect in the test stage, and cannot be brought online, so that non-intrusive integration can be realized, that is, certain functions (boundary test) are added through the code or the script under the condition that the online code is not modified and the existing APP functions are not affected.
S304, when the interface data request of the APP to be tested is received, dynamically generating boundary data corresponding to the interface according to the configured data structure.
When receiving an interface data request sent by the APP to be tested in the process of performing boundary test, the Mock platform can simulate to return interface data, namely, automatically and dynamically generate (modify) boundary data (various abnormal conditions of each field of the interface data) corresponding to the interface according to the data structure of the interface, and then return the boundary data to the APP to be tested. The address identifier (in this embodiment, a URL) in the interface data request may be matched to a corresponding pre-configured interface data structure, so that the full amount of boundary data is dynamically generated according to the interface data structure. In addition, the corresponding test times in the automatic test script can be matched according to the URL in the interface data request, the times of modifying the boundary data by the Mock platform is guided, and the boundary data with the corresponding times is returned. And accumulating the index recorded by the current interface by the Mock platform every time the Mock platform requests for one time, and continuously increasing the index until the boundary data of all the conditions corresponding to the test times are generated.
In this embodiment, the Mock platform can simulate different boundary data for different interfaces according to the data structure of each interface, and return different boundary data after receiving an interface data request every time within a limited number of times and a limited range, so as to form a limited boundary data set, thereby realizing the full coverage of the boundary data.
S306, returning the boundary data to the APP to be tested so that the APP to be tested uses the boundary data in the boundary test.
After the boundary data corresponding to the interface is simulated each time, the boundary data is returned to the client through the proxy unit, and the interface data acquired by the client each time is the (simulated) boundary data modified by the Mock platform. Through the total boundary data simulated by the Mock platform, the APP to be tested can realize the total automatic test of various boundary conditions of each page interface. Through the http agent of the agent unit, the interference to the existing code of the APP to be tested can be reduced, and the normal flow and the function of the APP to be tested are not influenced.
Moreover, the Mock platform can reset or set the test scheme/step corresponding to each client device (APP to be tested), bind the client device IP and the corresponding Mock configuration (automated test script, interface data structure, etc.), and thus can run the test repeatedly.
In addition, the Mock platform can record each request of the user side and can display the parameters of each request and the returned data on the webpage in real time.
And S308, when the APP to be tested is flashed off, the APP to be tested is called again in a delayed mode so as to continue the boundary test.
The flash quit means that the APP to be tested suddenly quits interruption in the running process, and the picture flashes and returns to the desktop. When the APP to be tested has a problem in the process of testing the page rendered, the situation of flash back may occur. When the flash quit happens, the APP to be tested intercepts corresponding Crash (Crash) information and reports the Crash information to the Mock platform. After receiving the Crash information, the Mock platform calls a guarding unit (in this embodiment, guarding APP), transfers the current testing step to the guarding APP, and the guarding APP calls the to-be-tested APP again after a preset delay, so that the testing step continues the previous testing process until the whole testing process is finished. The daemon APP is used for ensuring that the APP to be tested always runs in the testing process, and when the APP to be tested flashes and retreats, the APP to be tested can be called through a calling instruction.
And the Mock platform can also collect the Crash information during each flash back and related data during subsequent call-out, and finally (for example, after the boundary test is completed) sorts and generates a boundary test flash back report, and records the corresponding data when flash back occurs. In addition, the Mock platform can also inform the tester of the message of the occurrence of the flash back in a preset mode, for example, sending the message to an enterprise WeChat group.
Fig. 4 is a schematic diagram of a boundary test flow executed at a client (APP to be tested) in this embodiment. Wherein:
s400, sending a configuration request to the Mock platform to obtain an automatic test script of the boundary test.
S402, traversing the action list required to be executed in the automatic test script.
S404, executing the action according to the test scheme in the automatic test script, wherein when interface data is required to be requested, an interface data request is sent to the Mock platform, and returned boundary data is received.
S406, judging whether the flash back occurs when the boundary test is carried out according to the boundary data. If the flash back occurs, go to step S408. If no flash back occurs, go to step S410.
And S408, reporting the flashed-off Crash information to a Mock platform.
S410, judging whether the execution times of the test scheme reaches the test times in the automatic test script. And if the test frequency is not reached, returning to the step S404 to carry out the next test. If the test times are reached, returning to step S402 to continue the next action in the action list until the traversal is completed.
The above steps are specifically described with reference to the description of fig. 3, and are not described again here.
The application program boundary testing method provided in this embodiment may be configured with the data structure of each interface in advance, and automatically change according to each interface data request of the APP to be tested and the data structure, and finally dynamically generate the full amount of boundary data. And the boundary conditions of a series of page interfaces can be automatically tested by configuring the automatic test script aiming at the boundary test of the APP to be tested and the dynamically generated full boundary data, so that the full automatic test of all the pages and interfaces to be tested is realized without manual intervention, and the test cost is greatly saved. In addition, when the APP to be tested can be automatically reported and recorded after the flash back, the APP to be tested can be automatically called to continue to complete the test without manual intervention, and all boundary conditions which possibly cause the flash back of the APP are completely and automatically tested, so that the robustness of the APP is enhanced.
EXAMPLE III
As shown in fig. 5, a hardware architecture of an electronic device 20 is provided for a third embodiment of the present application. In the present embodiment, the electronic device 20 may include, but is not limited to, a memory 21, a processor 22, and a network interface 23, which are communicatively connected to each other through a system bus. It is noted that fig. 5 only shows the electronic device 20 with components 21-23, but it is to be understood that not all of the shown components are required to be implemented, and that more or fewer components may be implemented instead. In this embodiment, the electronic device 20 may be the client device (iOS system) or a PC connected to the client device (Android system).
The memory 21 includes at least one type of readable storage medium including a flash memory, a hard disk, a multimedia card, a card type memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a Read Only Memory (ROM), an Electrically Erasable Programmable Read Only Memory (EEPROM), a Programmable Read Only Memory (PROM), a magnetic memory, a magnetic disk, an optical disk, etc. In some embodiments, the storage 21 may be an internal storage unit of the electronic device 20, such as a hard disk or a memory of the electronic device 20. In other embodiments, the memory 21 may also be an external storage device of the electronic apparatus 20, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), or the like, provided on the electronic apparatus 20. Of course, the memory 21 may also include both an internal storage unit and an external storage device of the electronic apparatus 20. In this embodiment, the memory 21 is generally used for storing an operating system and various types of application software installed in the electronic device 20, such as program codes of the application boundary testing system 6. Further, the memory 21 may also be used to temporarily store various types of data that have been output or are to be output.
The processor 22 may be a Central Processing Unit (CPU), controller, microcontroller, microprocessor, or other data Processing chip in some embodiments. The processor 22 is generally used to control the overall operation of the electronic device 20. In this embodiment, the processor 22 is configured to run the program codes stored in the memory 21 or process data, for example, run the application boundary testing system 6.
The network interface 23 may include a wireless network interface or a wired network interface, and the network interface 23 is generally used for establishing a communication connection between the electronic apparatus 20 and other electronic devices.
Example four
Fig. 6 is a block diagram of an application boundary testing system 6 according to a fourth embodiment of the present invention. The application boundary testing system 6 may be partitioned into one or more program modules, which are stored in a storage medium and executed by one or more processors to implement embodiments of the present application. The program modules referred to in the embodiments of the present application refer to a series of computer program instruction segments capable of performing specific functions, and the following description will specifically describe the functions of each program module in the embodiments.
In this embodiment, the application boundary testing system 6 includes:
and a configuration module 600, configured to configure an automated test script corresponding to the APP boundary test and a data structure of each interface.
When the boundary test is performed on the APP to be tested, various interface data need to be requested from the server. The existing test scheme cannot dynamically and automatically modify the boundary data field of each interface, but the present embodiment can simulate the full boundary data of each interface required by the test through the application boundary test system 6. In this embodiment, the data structures corresponding to the interfaces may be pre-configured at the back end, so that the boundary data required by the test may be dynamically generated according to the data structures during the subsequent test. That is, the existing interface data structure is stored in the system, and can be automatically changed according to each request during subsequent testing, and finally, the full amount of boundary data is generated.
In addition, aiming at the situation that the existing test scheme cannot perform automatic test on dynamic boundary data, the automatic test script for performing boundary test on the to-be-tested APP is also pre-configured in the embodiment so that the to-be-tested APP can automatically complete the test according to the automatic test script. The automated test script includes, but is not limited to, actions to be performed, test scenarios/steps, number of times each test scenario is to be tested, run time, and required parameter descriptions.
Through the configuration of the automatic test script and the interface data structure, the full-automatic test of all the pages and interfaces to be tested can be automatically realized after the test is started, and the functions of suspending the test, resuming the test, resetting the test and the like can be provided.
And the sending module 602 is configured to provide the automatic test script for the APP to be tested when receiving a configuration request of the APP to be tested, so that the APP to be tested automatically performs boundary test according to the automatic test script.
In this embodiment, the client (APP to be tested) connects to the proxy unit and initiates a configuration request (request the config interface), so as to obtain the preconfigured automation test script. And then the APP to be tested opens a page according to the automatic test script, carries out automatic boundary test, and initiates an interface data request in the page.
It is worth noting that the client starts the normal flow of the APP to be tested after receiving the automatic test script, and performs operations such as rendering a page, and the like, and does not need to modify the code of the relevant normal flow, and the automatic test script code introduced through Debug macro control only takes effect in the test stage, and cannot be brought online, so that non-intrusive integration can be realized, that is, certain functions (boundary test) are added through the code or the script under the condition that the online code is not modified and the existing APP functions are not affected.
The simulation module 604 is configured to dynamically generate boundary data corresponding to the interface according to the configured data structure when receiving the interface data request of the APP to be tested.
When receiving an interface data request sent by the APP to be tested in the process of performing the boundary test, the simulation module 604 may simulate to return the interface data, that is, automatically dynamically generate (modify) boundary data (various abnormal conditions of each field of the interface data) corresponding to the interface according to the data structure of the interface, and then return the boundary data to the APP to be tested. The address identifier (in this embodiment, a URL) in the interface data request may be matched to a corresponding pre-configured interface data structure, so that the full amount of boundary data is dynamically generated according to the interface data structure. In addition, the URL in the interface data request may also be matched to the corresponding test times in the automated test script, so as to instruct the simulation module 604 to modify the times of the boundary data, and return the boundary data of the corresponding times. Each time a request is made, the simulation module 604 accumulates the index recorded by the current interface, and continuously increases the index until the boundary data of all the cases corresponding to the test times are generated.
In this embodiment, the simulation module 604 may simulate different boundary data for different interfaces according to the data structure of each interface, and return different boundary data after receiving an interface data request each time within a limited number of times and a limited range, so as to form a limited boundary data set, thereby implementing full coverage on the boundary data.
A returning module 606, configured to return the boundary data to the APP to be tested, so that the APP to be tested uses the boundary data in the boundary test.
After the boundary data corresponding to the interface is simulated each time, the boundary data is returned to the client via the proxy unit, and the interface data acquired by the client each time is the (simulated) boundary data modified by the simulation module 604. The full boundary data simulated by the simulation module 604 is returned to the client by the return module 606, and the APP to be tested can realize full automatic test of various boundary conditions of each page interface. Through the http agent of the agent unit, the interference to the existing code of the APP to be tested can be reduced, and the normal flow and the function of the APP to be tested are not influenced.
Moreover, the application boundary test system 6 may also reset or set the test scheme/step corresponding to each client device (APP to be tested), and bind the client device IP and the corresponding Mock configuration (automated test script, interface data structure, etc.), so that the test may be run repeatedly.
In addition, the application boundary test system 6 can record each request of the user side, and can display the parameters of each request and the returned data on the webpage in real time.
The application program boundary test system provided in this embodiment may pre-configure the data structure of each interface, and automatically change according to each interface data request of the APP to be tested and the data structure, so as to finally dynamically generate the full amount of boundary data. And the boundary conditions of a series of page interfaces can be automatically tested by configuring the automatic test script aiming at the boundary test of the APP to be tested and the dynamically generated full boundary data, so that the full automatic test of all the pages and interfaces to be tested is realized without manual intervention, and the test cost is greatly saved.
EXAMPLE five
Fig. 7 is a block diagram of an application boundary testing system 6 according to a fifth embodiment of the present invention. In this embodiment, the application boundary testing system 6 further includes a calling module 608 in addition to the configuration module 600, the sending module 602, the simulation module 604, and the returning module 606 in the fourth embodiment.
The evoking module 608 is configured to, when the APP to be tested is flashed back, delay to evoke the APP to be tested again so as to continue the boundary test.
The flash quit means that the APP to be tested suddenly quits interruption in the running process, and the picture flashes and returns to the desktop. When the APP to be tested has a problem in the process of testing the page rendered, the situation of flash back may occur. When the flash quit occurs, the APP to be tested intercepts the corresponding Crash (Crash) information and reports the Crash information to the application program boundary test system 6. After receiving the Crash information, the evoking module 608 evokes a daemon unit (in this embodiment, a daemon APP), and transmits the current testing step to the daemon APP, and the daemon APP evokes the APP to be tested again after a preset delay, and continues the previous testing process from the testing step until the whole testing process is finished. The daemon APP is used for ensuring that the APP to be tested always runs in the testing process, and when the APP to be tested flashes and retreats, the APP to be tested can be called through a calling instruction.
In addition, the calling module 608 may also collect the blast information during each flash back and related data during subsequent calling, and finally (for example, after the boundary test is completed) sort and generate a boundary test flash back report, and record data corresponding to the flash back. In addition, the call-out module 608 may also notify the tester of the occurrence of the flash back in a preset manner, for example, send the message to a corporate WeChat group.
The application program boundary test system provided in this embodiment may pre-configure the data structure of each interface, and automatically change according to each interface data request of the APP to be tested and the data structure, so as to finally dynamically generate the full amount of boundary data. And the boundary conditions of a series of page interfaces can be automatically tested by configuring the automatic test script aiming at the boundary test of the APP to be tested and the dynamically generated full boundary data, so that the full automatic test of all the pages and interfaces to be tested is realized without manual intervention, and the test cost is greatly saved. In addition, when the APP to be tested can be automatically reported and recorded after the flash back, the APP to be tested can be automatically called to continue to complete the test without manual intervention, and all boundary conditions which possibly cause the flash back of the APP are completely and automatically tested, so that the robustness of the APP is enhanced.
EXAMPLE six
The present application further provides another embodiment, which is to provide a computer readable storage medium storing an application boundary test program, which is executable by at least one processor to cause the at least one processor to perform the steps of the application boundary test method as described above.
It should be noted that, in this document, 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.
The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.
It will be apparent to those skilled in the art that the modules or steps of the embodiments of the present application described above may be implemented by a general purpose computing device, they may be centralized on a single computing device or distributed across a network of multiple computing devices, and alternatively, they may be implemented by program code executable by a computing device, such that they may be stored in a storage device and executed by a computing device, and in some cases, the steps shown or described may be performed in an order different from that described herein, or they may be separately fabricated into individual integrated circuit modules, or multiple ones of them may be fabricated into a single integrated circuit module. Thus, embodiments of the present application are not limited to any specific combination of hardware and software.
The above description is only a preferred embodiment of the present application, and not intended to limit the scope of the present application, and all modifications that can be made by the use of the equivalent structures or equivalent processes in the specification and drawings of the present application or that can be directly or indirectly applied to other related technologies are also included in the scope of the present application.
Claims (12)
1. An application boundary testing method, the method comprising:
configuring an automatic test script corresponding to the boundary test of the application program to be tested and a data structure of each interface;
when a configuration request of the application program to be tested is received, the automatic test script is sent to the application program to be tested, so that the application program to be tested automatically carries out boundary test according to the automatic test script;
when an interface data request of the application program to be tested is received, dynamically generating simulation boundary data corresponding to the interface according to the configured data structure; and
and returning the simulation boundary data to the application program to be tested so that the application program to be tested can use the simulation boundary data in the boundary test.
2. The method of claim 1, wherein after returning the simulated boundary data to the application under test, the method further comprises:
and when the application program to be tested carries out the boundary test according to the simulated boundary data and is subjected to flash back, delaying to re-call the application program to be tested so as to continue the boundary test.
3. The method for testing the boundary of the application program according to claim 1 or 2, wherein the automated test script comprises the actions to be executed in the boundary test, the test schemes/steps, and the test times of each test scheme.
4. The method for testing the boundary of the application program according to claim 3, wherein the step of dynamically generating the simulation boundary data corresponding to the interface according to the configured data structure when receiving the interface data request of the application program to be tested comprises:
and matching the data structure of the corresponding interface according to the address identifier in the interface data request, thereby dynamically generating the full amount of simulation boundary data according to the data structure.
5. The method for testing application boundaries of claim 4, wherein the step of dynamically generating the simulation boundary data corresponding to the interface according to the configured data structure when receiving the interface data request of the application to be tested further comprises:
and matching the corresponding test times in the automatic test script according to the address identification in the interface data request, and dynamically generating and returning the simulation boundary data according to the times corresponding to the test times.
6. The method for testing the application program boundary according to claim 1 or 2, wherein the sending of the interface data request by the application program to be tested and the returning of the simulation boundary data to the application program to be tested are both realized by an http proxy.
7. The method for testing the boundary of the application program according to claim 1 or 2, wherein when configuring the automated test script corresponding to the boundary test of the application program to be tested and the data structure of each interface, the method further comprises:
and binding the device IP of the application program to be tested, the corresponding automatic test script and the configuration of the data structure so as to repeatedly run the boundary test.
8. The method for testing the application boundaries of claim 2, wherein the delaying the re-waking of the application under test to continue the boundary test when the application under test performs the boundary test according to the simulated boundary data and the flashing back occurs comprises:
receiving the flash quit information reported by the application program to be tested;
calling a daemon unit and transmitting the current testing step of the boundary test to the daemon unit;
and the daemon unit re-calls the application program to be tested after a preset time delay, and the boundary test is continued from the test step.
9. The method for testing the application boundaries of claim 2, wherein the method further comprises, after delaying the re-awakening of the application under test:
and collecting the flash quit information and the data when the flash quit is called each time, and finishing to generate a boundary test flash quit report form after the boundary test is finished.
10. An application boundary testing system, the system comprising:
the configuration module is used for configuring an automatic test script corresponding to the boundary test of the application program to be tested and a data structure of each interface;
the sending module is used for sending the automatic test script to the application program to be tested when receiving the configuration request of the application program to be tested, so that the application program to be tested automatically carries out boundary test according to the automatic test script;
the simulation module is used for dynamically generating simulation boundary data corresponding to the interface according to the configured data structure when receiving an interface data request of the application program to be tested; and
and the return module is used for returning the simulation boundary data to the application program to be tested so that the application program to be tested can use the simulation boundary data in the boundary test.
11. An electronic device, comprising: a memory, a processor, and an application boundary test program stored on the memory and executable on the processor, the application boundary test program when executed by the processor implementing the application boundary test method of any of claims 1 to 9.
12. A computer-readable storage medium having stored thereon an application boundary test program which, when executed by a processor, implements an application boundary test method as claimed in any one of claims 1 to 9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011079029.5A CN112416750A (en) | 2020-10-10 | 2020-10-10 | Application program boundary testing method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011079029.5A CN112416750A (en) | 2020-10-10 | 2020-10-10 | Application program boundary testing method and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112416750A true CN112416750A (en) | 2021-02-26 |
Family
ID=74855167
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011079029.5A Pending CN112416750A (en) | 2020-10-10 | 2020-10-10 | Application program boundary testing method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112416750A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113517999A (en) * | 2021-04-29 | 2021-10-19 | 雄狮汽车科技(南京)有限公司 | Working method and system for simulating network data verification application boundary scene |
Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012163997A (en) * | 2011-02-03 | 2012-08-30 | Nec System Technologies Ltd | Failure analysis support system, failure analysis support method, and failure analysis support program |
| US20120260234A1 (en) * | 2010-12-24 | 2012-10-11 | Moksha Suryakant Jivane | Testing system |
| CN104050075A (en) * | 2013-03-11 | 2014-09-17 | 百度国际科技（深圳）有限公司 | Test method and device for Andriod application program |
| CN106528400A (en) * | 2016-09-22 | 2017-03-22 | 深圳峰创智诚科技有限公司 | MOCK testing method and device |
| CN107368405A (en) * | 2016-05-11 | 2017-11-21 | 腾讯科技（北京）有限公司 | Test system, method of testing, mock platforms, blocker and client |
| CN107547312A (en) * | 2017-09-21 | 2018-01-05 | 广州四三九九信息科技有限公司 | Applied program testing method and system |
| CN107704398A (en) * | 2017-11-01 | 2018-02-16 | 网易（杭州）网络有限公司 | Automated testing method and device, storage medium, electronic equipment |
| WO2018036273A1 (en) * | 2016-08-22 | 2018-03-01 | 上海壹账通金融科技有限公司 | Simulation test method, server, device, and computer-readable storage medium |
| CN108647143A (en) * | 2018-05-09 | 2018-10-12 | 平安普惠企业管理有限公司 | MOCK interface test methods, device, computer equipment and storage medium |
| CN109726098A (en) * | 2018-03-16 | 2019-05-07 | 平安科技（深圳）有限公司 | Interface test method, device and computer readable storage medium |
| US20190188119A1 (en) * | 2017-12-14 | 2019-06-20 | Cognizant Technology Solutions India Pvt. Ltd. | System and a method for providing automated performance detection of application programming interfaces |
| CN111061645A (en) * | 2019-12-26 | 2020-04-24 | 中科曙光国际信息产业有限公司 | Automatic interface testing method and device for application program interface |
-
2020
- 2020-10-10 CN CN202011079029.5A patent/CN112416750A/en active Pending
Patent Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120260234A1 (en) * | 2010-12-24 | 2012-10-11 | Moksha Suryakant Jivane | Testing system |
| JP2012163997A (en) * | 2011-02-03 | 2012-08-30 | Nec System Technologies Ltd | Failure analysis support system, failure analysis support method, and failure analysis support program |
| CN104050075A (en) * | 2013-03-11 | 2014-09-17 | 百度国际科技（深圳）有限公司 | Test method and device for Andriod application program |
| CN107368405A (en) * | 2016-05-11 | 2017-11-21 | 腾讯科技（北京）有限公司 | Test system, method of testing, mock platforms, blocker and client |
| WO2018036273A1 (en) * | 2016-08-22 | 2018-03-01 | 上海壹账通金融科技有限公司 | Simulation test method, server, device, and computer-readable storage medium |
| CN106528400A (en) * | 2016-09-22 | 2017-03-22 | 深圳峰创智诚科技有限公司 | MOCK testing method and device |
| CN107547312A (en) * | 2017-09-21 | 2018-01-05 | 广州四三九九信息科技有限公司 | Applied program testing method and system |
| CN107704398A (en) * | 2017-11-01 | 2018-02-16 | 网易（杭州）网络有限公司 | Automated testing method and device, storage medium, electronic equipment |
| US20190188119A1 (en) * | 2017-12-14 | 2019-06-20 | Cognizant Technology Solutions India Pvt. Ltd. | System and a method for providing automated performance detection of application programming interfaces |
| CN109726098A (en) * | 2018-03-16 | 2019-05-07 | 平安科技（深圳）有限公司 | Interface test method, device and computer readable storage medium |
| CN108647143A (en) * | 2018-05-09 | 2018-10-12 | 平安普惠企业管理有限公司 | MOCK interface test methods, device, computer equipment and storage medium |
| CN111061645A (en) * | 2019-12-26 | 2020-04-24 | 中科曙光国际信息产业有限公司 | Automatic interface testing method and device for application program interface |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113517999A (en) * | 2021-04-29 | 2021-10-19 | 雄狮汽车科技(南京)有限公司 | Working method and system for simulating network data verification application boundary scene |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109582556B (en) | Method, device and system for testing running condition of application program in mobile terminal | |
| CN108984389B (en) | Application program testing method and terminal equipment | |
| CN109299015B (en) | Software testing method, device and system | |
| CN108255701B (en) | Scene testing method and mobile terminal | |
| CN109683997B (en) | Method for accessing application program interface through sandbox, sandbox and sandbox equipment | |
| CN109344066B (en) | Method, system and terminal for testing browser page | |
| CN114095567B (en) | Data access request processing method and device, computer equipment and medium | |
| CN111124871A (en) | Interface test method and device | |
| CN112395187A (en) | Test method, test system, computer device and storage medium | |
| CN108427639B (en) | Automated testing method, application server and computer readable storage medium | |
| CN113656107A (en) | Mobile application loading method and device and electronic equipment | |
| CN108427635A (en) | Quickly method, server and the computer readable storage medium of test web page | |
| CN113191114B (en) | Method and apparatus for validating a system | |
| CN112256984B (en) | Method and device for acquiring interface background screenshot corresponding to webpage | |
| CN112416750A (en) | Application program boundary testing method and system | |
| CN113688025A (en) | Interface test method, device, equipment and storage medium | |
| CN112650689A (en) | Test method, test device, electronic equipment and storage medium | |
| CN113282501A (en) | Block chain testing method and device and electronic equipment | |
| CN108647139B (en) | System test method, device, storage medium and electronic device | |
| CN116450165A (en) | Method, system, terminal and storage medium for quickly building environment and deploying program | |
| CN113419952B (en) | Cloud service management scene testing device and method | |
| CN113535580B (en) | CTS test method, CTS test device and test equipment | |
| CN110740134B (en) | URL authentication test method, device, equipment and medium | |
| CN114721969A (en) | Method and device for separating interface automation test data and test codes | |
| CN114385498A (en) | Performance test method, system, computer equipment and readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |