CN113032255A - Response noise recognition method, model, electronic device, and computer storage medium - Google Patents
Response noise recognition method, model, electronic device, and computer storage medium Download PDFInfo
- Publication number
- CN113032255A CN113032255A CN202110296412.4A CN202110296412A CN113032255A CN 113032255 A CN113032255 A CN 113032255A CN 202110296412 A CN202110296412 A CN 202110296412A CN 113032255 A CN113032255 A CN 113032255A
- Authority
- CN
- China
- Prior art keywords
- request packet
- sending
- packet
- input
- response
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 59
- 230000004044 response Effects 0.000 title claims description 262
- 238000012360 testing method Methods 0.000 claims abstract description 230
- 238000012545 processing Methods 0.000 claims description 36
- 230000005540 biological transmission Effects 0.000 claims description 28
- 238000004088 simulation Methods 0.000 claims description 21
- 238000011160 research Methods 0.000 abstract description 4
- 230000008569 process Effects 0.000 description 17
- 238000010586 diagram Methods 0.000 description 10
- 238000012544 monitoring process Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 5
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 238000002372 labelling Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000036962 time dependent 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/3688—Test management for test execution, e.g. scheduling of test suites
-
- 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/3692—Test management for test results analysis
Abstract
The identification method can be applied to test version application with states and storage, can also be applied to a large-scale multi-service network architecture and an off-line scene of a mainstream internet company, greatly reduces interference caused by noise in automatic test, improves the efficiency and the accuracy of the automatic test, and simultaneously can provide data support for advanced research and test schemes such as script-free regression test, full link pressure test and the like.
Description
Technical Field
The present invention relates to the field of information processing technologies, and in particular, to a method for identifying response noise, an electronic device, and a computer-readable storage medium.
Background
In mature internet application, the priority for ensuring the stable operation of the system is often higher than the development of new functions, software testers need to frequently perform regression testing on the old functions of the system in order to avoid the influence of the new function development on the old function logic, and the traditional manual testing wastes a large amount of labor cost, so that various automatic testing schemes come into force.
In practical application, even if the software is in the same version, the same input may generate different outputs for many times, which is mainly caused by the influence of the software operating environment and the random algorithm inside the software, and this uncontrollable difference (noise) may be mixed with the difference generated by bug, which makes it difficult for the tester to distinguish whether the software itself is really problematic, thereby affecting the efficiency and accuracy of the automated testing.
For the identification of the response noise, the currently adopted solution is as follows: the first scheme is as follows: the platform provides response comparison result display of multiple times of playback, and testers manually mark noises; scheme II: and running three software instances of the software, namely a stable version, a copy of the stable version and a test version, and simultaneously running an agent program to send test data to the three software instances at the same time. And finally finding out the contrast difference after the noise is removed by analyzing the response difference between the stable version and the copy of the stable version to discriminate the noise and applying the noise identification result to the difference between the stable version and the test version.
In the first scheme, when a large number of interfaces of the tested software contain noise, for example: the calling chain id with the random character string in the response result, the signature depending on time encryption and the like need to consume a large amount of manpower to label noise, and the method is not ideal in both labor cost and accuracy. The second scheme is difficult to be applied to a mainstream large internet application architecture, that is, the application scenario of the second scheme is generally limited to some small-scale tool-type applications running offline, stateless and without storage.
Disclosure of Invention
The technical problem mainly solved by the application is to provide a response noise identification method, electronic equipment and a computer storage medium, and solve the problems that the existing scheme cannot be applied to stateful and stored tested software, and cannot be deployed on large-scale multi-service network architecture and tested software which needs to be operated online.
In order to solve the technical problem, the application adopts a technical scheme that: there is provided a method of identifying response noise, the method comprising: acquiring test data and inputting the test data into a stable version application; capturing a first input request packet generated by processing the test data by the stable version application, a first input response packet corresponding to the first input request packet, a first sending request packet and a first sending response packet corresponding to the first sending request packet; storing the first input request packet and the first input response packet to a playback background, and storing the first sending request packet and the first sending response packet to a virtual background; inputting the first input request packet to a test version application; acquiring a second sending request packet generated by processing the first input request packet by the test version application; selecting a first sending request packet closest to the second sending request packet from the virtual background, and acquiring a first sending response packet corresponding to the closest first sending request packet; inputting a first sending response packet corresponding to the closest first sending request packet into the test version application; capturing a second input response packet generated by the first sending response packet corresponding to the first input request packet and the closest first sending request packet corresponding to the test version application; determining a response noise for the test version application based on the first input response packet and the second input response packet.
In order to solve the above problem, a second aspect of the present application provides a response noise recognition model, including: the stable version packet capturing module is used for acquiring test data and inputting the test data into a stable version application; the stable version packet capturing module is further configured to capture a first input request packet generated by processing the test data by the stable version application, a first input response packet corresponding to the first input request packet, a first sending request packet, and a first sending response packet corresponding to the first sending request packet; the stable version packet capturing module is further configured to store the first input request packet and the first input response packet to a playback background, and store the first sending request packet and the first sending response packet to a virtual background; a simulation playback module for inputting the first input request packet to a test version application; the simulation playback module is also used for collecting a second sending request packet generated by processing the first input request packet by the test version application; the simulation playback module is further configured to select, from the virtual background, a first sending request packet that is closest to the second sending request packet, and acquire a first sending response packet corresponding to the closest first sending request packet; the simulation playback module is further used for inputting the corresponding first sending response packet into the test version application; the simulation playback module is further used for capturing a second input response packet generated by the corresponding first sending response packet and the first input request packet corresponding to the test version application; a response noise identification module to determine a response noise for the test version application based on the first input response packet and the second input response packet.
In order to solve the above problem, a third aspect of the present application provides an electronic device, which includes a memory and a processor coupled to each other, and the processor is configured to execute program instructions stored in the memory to implement the identification method of the first aspect.
In order to solve the above problem, a fourth aspect of the present application provides a computer-readable storage medium having stored thereon program instructions that, when executed by a processor, implement the identification method of the first aspect described above.
The beneficial effect of this application is: different from the situation of the prior art, the method and the device have the advantages that the test data are obtained and input into the stable version application; capturing a first input request packet generated by processing test data by using a stable version application, a first input response packet corresponding to the first input request packet, a first sending request packet and a first sending response packet corresponding to the first sending request packet; storing the first input request packet and the first input response packet to a playback background, and storing the first sending request packet and the first sending response packet to a virtual background; inputting the first input request packet into a test version application; acquiring a second sending request packet generated by processing the first input request packet by the test version application; selecting a first sending request packet closest to the second sending request packet from the virtual background, and acquiring a first sending response packet corresponding to the closest first sending request packet; inputting a first sending response packet corresponding to the closest first sending request packet into the test version application; capturing a second input response packet generated by a first sending response packet corresponding to the first sending request packet and the closest first sending request packet corresponding to the test version application; the response noise of the test version application is determined based on the first input response packet and the second input response packet. The identification method can be applied to the application of test versions with states and storage, can also be applied to a large-scale multi-service network architecture and an off-line scene of a mainstream internet company, greatly reduces the interference caused by noise in the automatic test, improves the efficiency and the accuracy of the automatic test, and simultaneously can provide data support for advanced research and test schemes such as script-free regression test, full link pressure test and the like.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.
FIG. 1 is a schematic flow chart diagram illustrating a first embodiment of a method for identifying response noise according to the present application;
FIG. 2 is a flowchart illustrating specific steps of step S102;
FIG. 3 is a schematic data flow diagram of the noise response identification method of FIG. 1;
FIG. 4 is a schematic flow chart diagram illustrating a second embodiment of the method for identifying response noise according to the present application;
FIG. 5 is a block diagram of an embodiment of a response noise identification model of the present application;
FIG. 6 is a schematic structural diagram of an embodiment of an electronic device of the present application;
FIG. 7 is a schematic structural diagram of an embodiment of a computer-readable storage medium of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. 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.
Referring to fig. 1, fig. 1 is a schematic flow chart of a first embodiment of a response noise identification method provided in the present application. Specifically, the method may include the steps of:
and S101, acquiring test data and inputting the test data into the stable version application.
In the automatic testing process of the software, a tester needs to give specific test data as the input of the software, take the execution result of the test data as the output, and compare the difference of the output results of the tested software under different versions, so as to analyze whether the BUG exists. For a closed software engineering system, theoretically the same input will correspond to the same output, i.e. the same request packet will correspond to the same response packet, but in practical cases, due to the influence of the software running environment and the random algorithm inside the software, even if the same content exists, the response of multiple identical requests will have irreproducible content, for example: time dependent fields, random authentication codes, etc., and the content of these irreproducible responses is referred to as response noise. These uncontrollable response noises can be mixed with the differences generated by the BUG, so that the tester can hardly distinguish whether the software is really problematic, thereby influencing the efficiency and the precision of the automatic test.
In this embodiment, after the software of the stable version is started, and after the stable version acquires the test data, when the stable version application processes the test data, a first input response packet, a first sending request packet, and a first sending response packet corresponding to the first input request packet and the first sending request packet are generated. The test data comprises input data or/and online flow data, the input data is formed by a tester by taking specific test data as input, the online flow data is real online flow data acquired by the tester through a packet capturing program, and the online flow data is more real and accurate than the input data.
Step S102: the method comprises the steps of capturing a first input request packet generated by processing test data by a stable version application, a first input response packet corresponding to the first input request packet, a first sending request packet and a first sending response packet corresponding to the first sending request packet.
In this embodiment, before the stable version application is started, the packet capture program is started, and then test data is input. After the stable version application acquires the test data, processing the test data generates a first input request packet, a first transmission request packet corresponding to the first input request packet, and a first transmission response packet corresponding to the first transmission request packet. The packet capturing program captures all the first input request packets, the first input response packets corresponding to the first input request packets, the first sending request packets and the first sending response packets corresponding to the first sending request packets, wherein the first input request packets, the first sending request packets and the first sending response packets are generated by processing the test data through the application of the stable version.
Referring to fig. 2, fig. 2 is a flowchart illustrating the specific step of step S102.
Step S201: and acquiring a first sending request packet, and sending the first sending request packet to the client.
In this embodiment, when the stable version application processes the first input request packet generated by the test data, the first input request packet is processed to obtain a first sending request packet, and the first sending request packet is sent to the client. After receiving the first sending request packet, the client performs corresponding processing to generate a first sending response packet.
Step S202: and receiving a first sending response packet generated by the client corresponding to the first sending request packet.
In this embodiment, after generating the first sending request packet, the client returns the first sending request packet to the stable version application, and the stable version application receives the first sending response.
Step S203: the first send response packet is input into the stable version application.
In this embodiment, after receiving the first sending response packet, the stable version application inputs the first sending response packet into the stable version application, that is, at this time, the stable version application inputs the first input request packet and the first sending response packet.
Step S204: and capturing a first input response packet generated by the stable version application corresponding to the first input request packet and the first sending response packet.
In this embodiment, after the first sending response packet is input into the stable version application, the stable version should generate the first input response packet corresponding to the first input request packet and the first sending request packet, and the packet capturing program captures the first input response packet.
Step S103: and storing the first input request packet and the first input response packet to a playback background, and storing the first sending request packet and the first sending response packet to a virtual background.
In this embodiment, after all the first input request packet, the first input response packet corresponding to the first input request packet, the first sending request packet, and the first sending response packet corresponding to the first sending request packet are completely captured, the packet capture program further stores the first input request packet and the first input response packet in the playback background, and stores the first sending request packet and the first sending response packet in the virtual background. The first input request packet and the first sending response packet captured by the packet capturing program can be simulated and forged in the test version application running process, so that the software state can be better reproduced, and the interference of the software state to the automatic test is reduced.
Step S104: the first input request packet is input to the test version application.
In this embodiment, the first input request packet stored in the playback background is sent to the test version application as an input, and at this time, the first input request packet sent to the test version application is the same as the first input request packet input by the stable version, so that response noise generated by different inputs of the test version application is avoided.
Step S105: and acquiring a second sending request packet generated by processing the first input request packet by the test version application.
In this embodiment, after obtaining the first input request packet, the test version application performs corresponding processing according to the first input request packet to obtain a second sending request packet, and sends the second sending request packet to the virtual background for storage. In order to avoid interference caused by an online environment, the test version is applied to the servers in the independent network segments, a virtual agent is also deployed before the test version application is deployed, all second sending request packets generated by processing the first input request packet by the test version application are collected by the virtual agent and are forwarded to the virtual background for storage.
And in the process of sending the second sending request packet to the virtual background by the test version application, deploying a virtual agent between the test version application and the virtual background, and intercepting all the second sending request packets sent to the virtual background by the test version application through the virtual agent. The second sending request packet is initiated by the test version application, information such as an access address, a port and the like in the second sending request packet is determined in the test version application, all the second sending request packets of one test version application may be sent to a plurality of addresses, and in order to avoid resource overhead of a plurality of virtual backgrounds, all the second sending request packets are forwarded to the virtual backgrounds for processing.
In order to realize the flow of uniform forwarding, the default running network-related dynamic library is modified when the test version application is started, that is, the intercepted network-related dynamic library of the second sending request packet is realized based on the C voice network library. In order to reduce the influence on the performance of the application of the test version, the network-related dynamic library simply transfers the second sending request packet to the virtual agent, the virtual agent modifies the address information in the network layer of the second sending request packet and uniformly forwards the modified second sending request packet to the virtual background, and the virtual background uniformly analyzes and matches the messages of the transmission layer and the application layer of the second sending request packet.
Step S106: and selecting a first sending request packet closest to the second sending request packet from the virtual background, and acquiring a first sending response packet corresponding to the closest first sending request packet.
In this embodiment, after receiving the second transmission request packet, the virtual background stores the second transmission request packet in the virtual background. At this time, the virtual background stores a first sending request packet, a first sending response packet and a second sending request packet, and the virtual background obtains a second client response packet according to the first sending request packet and the second sending request packet.
Specifically, after receiving the second sending request packet, the virtual background compares the second sending request packet with the first sending request packet, selects a first sending request packet closest to the second sending request packet from the first sending request packet, and obtains a first sending response packet corresponding to the closest first sending request packet.
Step S107: and inputting the first sending response packet corresponding to the closest first sending request packet into the test version application.
In this embodiment, the first transmission response packet corresponding to the closest first transmission request packet is input to the test version application, the test version application receives the first transmission response packet corresponding to the closest first transmission request packet, that is, the input of the test version application includes the first input request packet and the first sending response packet corresponding to the closest first sending request packet, the test version application processes the first input request packet and the first sending response packet corresponding to the closest first sending request packet to obtain the second input response packet, at this time, the first input request packet and the first sending response packet input to the test version application and the first input request packet and the first sending response packet of the stable version application correspond to and are the same as the first sending response packet corresponding to the closest first sending request packet, thereby avoiding the difference in output due to the difference in input between the test version application and the stable version application.
Step S108: and capturing a second input response packet generated by the first sending response packet corresponding to the first sending request packet and the closest first sending request packet by the test version application.
In this embodiment, after the test version applies the second input response packet generated by the first transmission response packet corresponding to the first input request packet and the closest first transmission request packet, the second input response packet is captured and transmitted to the playback background and stored. At this time, the response noise of the test version application is the response noise generated by uncontrollable calling of the server system, so that different influences caused by different input of the test version application and the stable version application are avoided, and the obtained response noise is more accurate.
Step S109: the response noise of the test version application is determined based on the first input response packet and the second input response packet.
In this embodiment, the first input response packet and the second input response packet are both stored in the playback background, and the first input response packet and the second input response packet stored in the playback background are subjected to difference comparison and analyzed to obtain the response noise. Specifically, the response noise of the test version application is determined based on the first input response packet and the second input response packet, and at this time, the response noise of the test version application is the response noise generated uncontrollably by the server system calling itself, so that different influences caused by different input of the test version application and the stable version application are avoided, and the obtained response noise is more accurate. Meanwhile, the simulated first input request packet and the forged first sending response packet corresponding to the closest first sending request packet are used as input, namely the software state is reproduced by simulating the input content and the sequence of the software, so that the interference of the software state to the automatic test is reduced, and the efficiency and the accuracy of the automatic test are improved.
The first input response packet and the second input response packet have one or more message formats, such as json, html, xml, and other message formats, and the comparison algorithm and the noise labeling mode may be adjusted correspondingly according to the different message formats, and the specific adjustment mode is not limited herein.
Referring further to fig. 3, fig. 3 is a schematic diagram illustrating a data flow in the method for identifying the response noise of fig. 1.
In this embodiment, a packet capturing program is started first, when a stable version application 301 is started, a tester inputs test data, the stable version application 301 receives a first input request packet after a test case is input, and processes the first input request packet to obtain a first sending request packet, in the process, the packet capturing program captures the first input request packet input to the stable version application and the first sending request packet sent by the stable version application 301 to a client, the packet capturing program stores the first input request packet to a playback background 302, and stores the first sending request packet to a virtual background 303; meanwhile, after receiving the first sending request packet, the client processes the first sending request packet to obtain a first sending response packet, and sends the first sending response packet to the stable version application 301, and when the stable version application 301 receives the first sending response packet, the packet capturing program captures the first sending response packet and stores the first sending response packet in the virtual background 303; after receiving the first sending response packet, the stable version application 301 processes the first input request packet and the first sending response packet to obtain a first input response packet, and the packet capture program captures the first input response packet and stores the first input response packet in the playback background 302.
Starting a test version application 304, inputting a first input request packet stored in a playback background 301 into the test version application 304, processing the first input request packet by the test version application 304 to obtain a second sending request packet, and sending the second sending request packet to a virtual background 303 for storage; in the virtual background 303, the second sending request packet stored in the virtual background 303 is processed, specifically, the second sending request packet is compared with the first sending request packet, so that when a first sending request packet closest to the second sending request packet is selected, a first sending response packet corresponding to the closest first sending request packet is extracted from the virtual background 303 as an input and sent to the test version application 304, the test version application 304 receives the first sending response packet corresponding to the most received first sending request packet, and processes the first sending response packet according to the first input request packet and the first sending response packet corresponding to the most received first sending request packet to obtain a second input response packet, and sends the second sending response packet to the playback background 302 for storage.
In the above process, the first input request packet and the first transmission response packet input to the stable version application 304, the first send response packets corresponding to the first input request packet and the most received first send request packet input to the test version application 304 are effectively the same, i.e. the requests input to the stable version application 301 and the test version application 304 are identical, whereas the first and second input response packets returned by the same input are theoretically identical, however, under the actual request, due to the operating environment of the stable version application 301 and the test version application 304 and the influence of the internal algorithm of the software, the returned first input response packet and the returned second input response packet returned by the same input actually carry irreproducible contents, i.e., response noise, is identified by analyzing the first input response packet and the second input response packet. The identified response noise can be in the automatic test process, and testers can quickly and accurately distinguish the response noise from the difference generated by the BUG through the response noise identified by the identification method, so that the difference generated by the BUG is found, and the efficiency and the precision of the automatic test are further improved.
The method can be applied to test version application with states and storage, can also be applied to large-scale multi-service network architecture and offline scenes of mainstream internet companies, greatly reduces interference caused by noise in automatic testing, improves the efficiency and the accuracy of the automatic testing, and simultaneously can provide data support for advanced research and test schemes such as script-free regression testing, full link pressure testing and the like.
Referring to fig. 4, fig. 4 is a schematic flowchart illustrating a second embodiment of the identification method for response noise according to the present application, where the identification method of the present embodiment includes:
step S401: the stable version application is started.
In this embodiment, a stable version application is started, and the stable version application sends a first sending request packet to the outside during the starting period, where the first sending request packet is usually a request for various pull configurations.
Step S402: and capturing a first sending request packet generated by starting the stable version application and a first sending response packet corresponding to the first sending request packet.
In this embodiment, before the stable version application is started, a packet capturing program is started first, and a first sending request packet generated by starting the stable version application and a first sending response packet corresponding to the first sending request packet can be captured by the packet capturing program.
Step S403: and storing the first sending request packet and the first sending response packet generated by starting the stable version application to the virtual background.
In this embodiment, after the packet capturing program captures the first sending request packet and the first sending response packet during the starting period of the stable version application, the first sending request packet and the first sending response packet generated by starting the stable version application are stored in the virtual background, so that loss of part of data is avoided, and the accuracy of the test is improved.
Step S404: and acquiring test data and inputting the test data into the stable version application.
Step S404 is the same as step S101, and is not described herein again.
Step S405: the method comprises the steps of capturing a first input request packet generated by processing test data by a stable version application, a first input response packet corresponding to the first input request packet, a first sending request packet and a first sending response packet corresponding to the first sending request packet.
Step S405 is the same as step S102, and is not described herein again.
Step S406: and storing the first input request packet and the first input response packet to a playback background, and storing the first sending request packet and the first sending response packet to a virtual background.
Step S406 is the same as step S103, and is not described herein again.
Step S407: the first input request packet is input to the test version application.
In this embodiment, the first input request packet stored in the playback background is sent to the test version application as an input, and at this time, the first input request packet sent to the test version application is the same as the first input request packet input by the stable version, so that response noise generated by different inputs of the test version application is avoided.
Wherein, the step of inputting the first input request packet into the test version application further comprises: and inputting the first input request packet to the test version application in response to the test version application being normally started.
Specifically, during the automatic test, how long the simulation playback recording takes time, the playback time also needs a corresponding time length, but when the test data comes from the actual production environment, the recording lasts for a long time to improve the functional coverage rate of the test data, and at this time, if the playback consumes the same time length every time, the efficiency of the whole automatic test will be reduced. Therefore, in order to improve the efficiency of the automated testing, the starting state of the test version application needs to be monitored during the simulation playback process.
In the simulation playback process, the test version application needs to wait for normal start, and the start time of the test version application cannot be adjusted, so that whether the first input request packet stored in the playback background can be sent to the test version application is further judged by monitoring whether all the first sending request packets are stored in the virtual background. Specifically, when the stable version acquires the test data, it is monitored whether all first transmission request packets are stored in the virtual background before the first input request packet is transmitted to the test version application, and when the first input request packet is transmitted to the test version application and all the first transmission request packets are stored in the virtual background, the test version application is started.
And before the first input request packet is input into the test version application, responding to the fact that all second sending request packets generated by the stable version application are sent, starting the test version application, and inputting the first input request packet into the test version application from a playback background.
Meanwhile, in order to enable the system to more accurately judge whether the test version application is started, whether the test version application is normally started is determined through a preset mode, wherein the preset mode comprises the step of judging whether the test version application is normally started through heartbeat monitoring or other modes of sending a second request packet triggered by a timing task. Furthermore, the second sending request packet does not necessarily reappear completely during simulation, and monitoring can be performed according to parameters such as the starting time of the test version application, the capturing percentage of the second sending request packet, and the like, so as to adjust the starting monitoring effect of different test version applications. Optionally, a custom start judgment plug-in can be added, and different monitoring parameters are set by the custom start judgment plug-in, so that the system can judge whether the test version application is started more accurately.
After the test version application is determined to be started, multiple playback modes such as multiple playback, sequential playback and step-by-step playback can be realized by using methods of common playback tools such as tcpdump, and testers can select appropriate playback modes in different scenes, so that the efficiency and the accuracy are improved.
Step S408: and acquiring a second sending request packet generated by processing the first input request packet by the test version application.
Step S408 is the same as step S105, and is not described herein again.
Step S409: and selecting a first sending request packet closest to the second sending request packet from the virtual background, and acquiring a first sending response packet corresponding to the closest first sending request packet.
Step S409 is the same as step S106, and is not described herein again.
Step S410: and inputting the first sending response packet corresponding to the closest first sending request packet into the test version application.
Step S410 is the same as step S107, and is not described herein again.
Step S411: and capturing a second input response packet generated by the first sending response packet corresponding to the first sending request packet and the closest first sending request packet by the test version application.
Step S411 is the same as step S108, and is not described herein again.
Step S412: the response noise of the test version application is determined based on the first input response packet and the second input response packet.
Step S412 is the same as step S109, and will not be described herein.
The method can be applied to test version application with states and storage, can also be applied to large-scale multi-service network architecture and offline scenes of mainstream internet companies, greatly reduces interference caused by noise in automatic testing, improves the efficiency and the accuracy of the automatic testing, and simultaneously can provide data support for advanced research and test schemes such as script-free regression testing, full link pressure testing and the like.
Referring to fig. 5, fig. 5 is a block diagram of an embodiment of a response noise identification model according to the present application. The response noise recognition model 50 includes: the stable version packet capturing module 501, wherein the stable version packet capturing module 501 is used for acquiring test data and inputting the test data into a stable version application; the stable version packet capturing module 501 is further configured to capture a first input request packet generated by processing test data by using a stable version application, a first input response packet corresponding to the first input request packet, a first sending request packet, and a first sending response packet corresponding to the first sending request packet; the stable version packet capturing module 501 is further configured to store the first input request packet and the first input response packet in the playback background, and store the first sending request packet and the first sending response packet in the virtual background; the simulation playback module 502, the simulation playback module 502 is used for inputting the first input request packet to the test version application; the simulation playback module 502 is further configured to collect a second sending request packet generated by processing the first input request packet by the test version application; the analog playback module 502 is further configured to select, from the virtual background, a first sending request packet that is closest to the second sending request packet, and obtain a first sending response packet corresponding to the closest first sending request packet; the simulation playback module 502 is further configured to input the corresponding first transmission response packet into the test version application; the simulation playback module 502 is further configured to capture a second input response packet generated by a first transmission response packet corresponding to the first input request packet of the test version application; a response noise identification module 503, the response noise identification module 503 configured to determine a response noise of the test version application based on the first input response packet and the second input response packet.
The stable packet capturing module 501 is specifically configured to capture a first input request packet, a first input response packet corresponding to the first input request packet, a first sending request packet, and a first sending response packet corresponding to the first sending request packet, where the first input request packet, the first sending request packet, and the first sending response packet are generated by processing test data by using a stable version application after a packet capturing program is started. After the first input request packet, the first input response packet corresponding to the first input request packet, the first sending request packet and the first sending response packet corresponding to the first sending request packet are captured, the first input request packet and the first input response packet are stored in a playback background, and the first sending request packet and the first sending response packet are stored in a virtual background. Therefore, the first input request packet and the first sending response packet captured by the stable packet capturing module 501 can be simulated and forged in the running process of the test version application, so that the software state can be better reproduced, and the interference of the software state to the automatic test is reduced.
The analog playback module 502 is specifically configured to send a first input request packet stored in the playback background by the stable packet capturing module 501 to the test version application as an input, where after the test version application obtains the first input request packet, the test version application performs corresponding processing according to the first input request packet to obtain a second sending request packet, and at the same time, sends the second sending request packet to the virtual background for storage. And when the test version application sends the second sending request packet to the virtual background, acquiring the second sending request packet generated by processing the first input request packet by the test version application through the virtual agent.
After the virtual background receives and stores the second sending request packet, the virtual background stores the first sending request packet, the first sending response packet and the second sending request packet, and the virtual background obtains a second client response packet according to the first sending request packet and the second sending request packet. The analog playback module 502 compares the second transmission request packet with the first transmission request packet, selects a first transmission request packet closest to the second transmission request packet from the first transmission request packet, and acquires a first transmission response packet corresponding to the closest first transmission request packet.
The analog playback module 502 inputs the first sending response packet corresponding to the closest first sending request packet to the test version application, where the input of the test version application includes the first input request packet and the first sending response packet corresponding to the closest first sending request packet, the test version application processes the first input request packet and the first sending response packet corresponding to the closest first sending request packet to obtain a second input response packet, and at this time, the first input request packet and the first sending response packet input to the test version application correspond to and are the same as the first input request packet and the first sending response packet corresponding to the stable version application, so as to avoid the difference in output due to the difference in input between the test version application and the stable version application.
The simulation playback module 502 captures a second input response packet generated by the first sending response packet corresponding to the first sending request packet and the first input request packet corresponding to the closest first sending request packet, and sends the second input response packet to the playback background for storage.
The analog playback module 502 is further configured to input the first input request packet to the test version application in response to the test version application having been normally started. Specifically, before the first input request packet is input to the test version application, the analog playback module 502 starts the test version application in response to the completion of sending all the second send request packets generated by the stable version application, and inputs the first input request packet to each test version application from the playback background.
The analog playback module 502 is also used to determine whether the test version application has been normally started in a preset manner. And the preset mode comprises the step of judging whether the test version application is normally started or not by a heartbeat monitoring mode or other modes of sending a second request packet triggered by a timing task. Optionally, the analog playback module 502 may also perform monitoring according to parameters such as the start time of the test version application, the capture percentage of the second transmission request packet, and the like, so as to adjust the start monitoring effect of different test version applications. The simulation playback module 502 can also add a custom start judgment plug-in, and set different monitoring parameters by the custom start judgment plug-in, so that the system can more accurately judge whether the test version application is started.
The response noise identification module 503 is specifically configured to determine the response noise of the test version application based on the first input response packet and the second input response packet, where the response noise of the test version application is the response noise generated uncontrollably by the server system call itself, so that different influences caused by different inputs of the test version application and the stable version application are avoided, and the obtained response noise is more accurate. Meanwhile, the simulated first input request packet and the forged first sending response packet corresponding to the closest first sending request packet are used as input, namely the software state is reproduced by simulating the input content and the sequence of the software, so that the interference of the software state to the automatic test is reduced, and the efficiency and the accuracy of the automatic test are improved.
Referring to fig. 6, fig. 6 is a schematic frame diagram of an embodiment of an electronic device according to the present application. The electronic device 60 comprises a memory 601 and a processor 602 coupled to each other, the processor 602 being configured to execute program instructions stored in the memory 601 to implement the steps of any of the above-described embodiments of the identification method. In one particular implementation scenario, electronic device 60 may include, but is not limited to: microcomputer, server.
In particular, the processor 602 is configured to control itself and the memory 601 to implement the steps of any of the above-described embodiments of the identification method. Processor 602 may also be referred to as a CPU (Central Processing Unit). The processor 602 may be an integrated circuit chip having signal processing capabilities. The Processor 602 may also be a general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. In addition, the processor 602 may be commonly implemented by integrated circuit chips.
According to the scheme, the processor 602 acquires the test data and inputs the test data into the stable version application; capturing a first input request packet generated by processing test data by using a stable version application, a first input response packet corresponding to the first input request packet, a first sending request packet and a first sending response packet corresponding to the first sending request packet; storing the first input request packet and the first input response packet to a playback background, and storing the first sending request packet and the first sending response packet to a virtual background; inputting the first input request packet into a test version application; acquiring a second sending request packet generated by processing the first input request packet by the test version application; selecting a first sending request packet closest to the second sending request packet from the virtual background, and acquiring a first sending response packet corresponding to the closest first sending request packet; inputting a first sending response packet corresponding to the closest first sending request packet into the test version application; capturing a second input response packet generated by a first sending response packet corresponding to the first sending request packet and the closest first sending request packet corresponding to the test version application; the response noise of the test version application is determined based on the first input response packet and the second input response packet.
Referring to fig. 7, fig. 7 is a block diagram illustrating an embodiment of a computer-readable storage medium according to the present application. The computer readable storage medium 70 stores program instructions 700 executable by the processor, the program instructions 700 for implementing the steps of any of the above-identified method embodiments.
In the embodiments provided in the present application, it should be understood that the disclosed method, model, and apparatus may be implemented in other ways. For example, the above-described model embodiments are merely illustrative, and for example, a module or a unit may be divided into only one logical function, and an actual implementation may have another division, for example, a unit or a component may be combined or integrated with another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection of devices or units through some interfaces, and may be in an electrical, mechanical or other form.
Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on network elements. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, a network device, or the like) or a processor (processor) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
Claims (11)
1. A method for identifying response noise, the method comprising:
acquiring test data and inputting the test data into a stable version application;
capturing a first input request packet generated by processing the test data by the stable version application, a first input response packet corresponding to the first input request packet, a first sending request packet and a first sending response packet corresponding to the first sending request packet;
storing the first input request packet and the first input response packet to a playback background, and storing the first sending request packet and the first sending response packet to a virtual background;
inputting the first input request packet to a test version application;
acquiring a second sending request packet generated by processing the first input request packet by the test version application;
selecting a first sending request packet closest to the second sending request packet from the virtual background, and acquiring a first sending response packet corresponding to the closest first sending request packet;
inputting a first sending response packet corresponding to the closest first sending request packet into the test version application;
capturing a second input response packet generated by the first sending response packet corresponding to the first input request packet and the closest first sending request packet corresponding to the test version application;
determining a response noise for the test version application based on the first input response packet and the second input response packet.
2. The method of claim 1, wherein said step of collecting a second transmission request packet generated by processing said test data with said test version comprises:
and acquiring a second sending request packet generated by processing the first input request packet by the test version through a virtual agent, and storing the second sending request packet to the virtual background.
3. The method of claim 2, wherein the step of collecting a second transmission request packet generated by processing the first input request packet with the test version by the virtual agent and storing the second transmission request packet in the virtual background comprises:
and modifying the address information in the network layer of the second sending request packet through the virtual agent, and storing the modified second sending request packet to the virtual background.
4. The method of claim 1, wherein the step of capturing the first input request packet, the first input response packet corresponding to the first input request packet, the first sending request packet, and the first sending response packet corresponding to the first sending request packet generated by processing the test data with the stable version application comprises:
acquiring the first sending request packet, and sending the first sending request packet to a client;
receiving the first sending response packet generated by the client corresponding to the first sending request packet;
inputting the first send response packet into the stable version application;
and capturing a first input response packet generated by the stable version application corresponding to the first input request packet and the first sending response packet.
5. The method of any one of claims 1-4, wherein said step of inputting said first input request packet to a test version application comprises:
and inputting the first input request packet to the test version application in response to the test version application being normally started.
6. The method of claim 4, wherein the step of inputting the first input request packet to the test version application in response to the test version application having been normally started comprises:
and responding to the fact that all second sending request packets generated by the stable version application are sent, starting the version application to be tested, and inputting the first input request packet to the test version application.
7. The method of claim 1, wherein the step of capturing the first input request packet, the first input response packet corresponding to the first input request packet, the first sending request packet, and the first sending response packet corresponding to the first sending request packet generated by processing the test data by the stable version application comprises:
and capturing the first input request packet, a first input response packet corresponding to the first input request packet, a first sending request packet and a first sending response packet corresponding to the first sending request packet by using a packet capturing program.
8. The method of claim 1, wherein said step of acquiring test data and inputting said test data into a stable version of an application is preceded by the step of:
starting the stable version application;
capturing a first sending request packet generated by starting the stable version application and a first sending response packet corresponding to the first sending request packet;
storing the first sending request packet and the first sending response packet generated by starting the stable version application to the virtual background.
9. A response noise recognition model, comprising:
the stable version packet capturing module is used for acquiring test data and inputting the test data into a stable version application;
the stable version packet capturing module is further configured to capture a first input request packet generated by processing the test data by the stable version application, a first input response packet corresponding to the first input request packet, a first sending request packet, and a first sending response packet corresponding to the first sending request packet;
the stable version packet capturing module is further configured to store the first input request packet and the first input response packet to a playback background, and store the first sending request packet and the first sending response packet to a virtual background;
a simulation playback module for inputting the first input request packet to a test version application;
the simulation playback module is also used for collecting a second sending request packet generated by processing the first input request packet by the test version application;
the simulation playback module is further configured to select, from the virtual background, a first sending request packet that is closest to the second sending request packet, and acquire a first sending response packet corresponding to the closest first sending request packet;
the simulation playback module is further used for inputting the corresponding first sending response packet into the test version application;
the simulation playback module is further used for capturing a second input response packet generated by the corresponding first sending response packet and the first input request packet corresponding to the test version application;
a response noise identification module to determine a response noise for the test version application based on the first input response packet and the second input response packet.
10. An electronic device comprising a memory and a processor coupled to each other, the processor being configured to execute program instructions stored in the memory to implement the steps of the identification method of any one of claims 1 to 8.
11. A computer-readable storage medium, having stored thereon program instructions executable to implement the steps of the identification method according to any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110296412.4A CN113032255B (en) | 2021-03-19 | 2021-03-19 | Response noise identification method, model, electronic device and computer storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110296412.4A CN113032255B (en) | 2021-03-19 | 2021-03-19 | Response noise identification method, model, electronic device and computer storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113032255A true CN113032255A (en) | 2021-06-25 |
| CN113032255B CN113032255B (en) | 2024-03-01 |
Family
ID=76471829
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110296412.4A Active CN113032255B (en) | 2021-03-19 | 2021-03-19 | Response noise identification method, model, electronic device and computer storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113032255B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113590497A (en) * | 2021-09-27 | 2021-11-02 | 腾讯科技（深圳）有限公司 | Business service test method and device, electronic equipment and storage medium |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103324566A (en) * | 2012-03-20 | 2013-09-25 | 阿里巴巴集团控股有限公司 | Multi-version test method and device for web page product |
| US20140208190A1 (en) * | 2013-01-24 | 2014-07-24 | Melexis Technologies Nv | Method for processing transmission errors, in particular noise, during a contactless communication between a card and a reader |
| CN111124861A (en) * | 2019-12-19 | 2020-05-08 | 广州品唯软件有限公司 | Recording method of webpage data, recording device of webpage data and readable storage medium |
| CN111611590A (en) * | 2020-05-22 | 2020-09-01 | 支付宝(杭州)信息技术有限公司 | Method and device for data security related to application program |
| CN111988200A (en) * | 2020-08-18 | 2020-11-24 | 湖南快乐阳光互动娱乐传媒有限公司 | Automatic regression testing method and device based on real flow |
-
2021
- 2021-03-19 CN CN202110296412.4A patent/CN113032255B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103324566A (en) * | 2012-03-20 | 2013-09-25 | 阿里巴巴集团控股有限公司 | Multi-version test method and device for web page product |
| US20140208190A1 (en) * | 2013-01-24 | 2014-07-24 | Melexis Technologies Nv | Method for processing transmission errors, in particular noise, during a contactless communication between a card and a reader |
| CN111124861A (en) * | 2019-12-19 | 2020-05-08 | 广州品唯软件有限公司 | Recording method of webpage data, recording device of webpage data and readable storage medium |
| CN111611590A (en) * | 2020-05-22 | 2020-09-01 | 支付宝(杭州)信息技术有限公司 | Method and device for data security related to application program |
| CN111988200A (en) * | 2020-08-18 | 2020-11-24 | 湖南快乐阳光互动娱乐传媒有限公司 | Automatic regression testing method and device based on real flow |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113590497A (en) * | 2021-09-27 | 2021-11-02 | 腾讯科技（深圳）有限公司 | Business service test method and device, electronic equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113032255B (en) | 2024-03-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111045952B (en) | Software testing method, flow playback device, terminal equipment and readable storage medium | |
| CN106484611B (en) | Fuzzy test method and device based on automatic protocol adaptation | |
| CN105787364B (en) | Automatic testing method, device and system for tasks | |
| US20090156314A1 (en) | System and method for re-generating packet load for load test | |
| US20070097872A1 (en) | Network connection apparatus testing method | |
| CN112714047A (en) | Industrial control protocol flow based test method, device, equipment and storage medium | |
| CN108459850B (en) | Method, device and system for generating test script | |
| CN110784486A (en) | Industrial vulnerability scanning method and system | |
| CN106972983B (en) | Automatic testing device and method for network interface | |
| CN107168844A (en) | A kind of method and device of performance monitoring | |
| US20160105810A1 (en) | Technique for testing wireless network load produced by mobile app-carrying devices | |
| CN105117340A (en) | URL (Uniform Resource Locator) detection method and device used for quality evaluation of iOS browser application | |
| CN115150377A (en) | Method and device for calling and processing simulation interface | |
| CN113032255A (en) | Response noise recognition method, model, electronic device, and computer storage medium | |
| CN109471763B (en) | Method, device, equipment and system for grabbing trace of NVME (network video management entity) hard disk | |
| CN113238935A (en) | Application testing method, system, device, medium, and computer program product | |
| CN105068926A (en) | Program test method and device thereof | |
| CN109412893B (en) | Message playback method and device | |
| CN116166536A (en) | Test method, test device, electronic equipment and storage medium | |
| CN114500348B (en) | CDN gateway testing method and system | |
| CN111736893B (en) | Software package version verification method and related device | |
| CN112838938B (en) | Test system of Internet of things platform | |
| JP3942070B2 (en) | Test method and test generator for telecommunication equipment | |
| CN112199229A (en) | Data processing method, device, equipment and storage medium | |
| CN113868116A (en) | Test dependent data generation method and device, server and 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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |