CN113032255B - Response noise identification method, model, electronic device and computer storage medium - Google Patents
Response noise identification method, model, electronic device and computer storage medium Download PDFInfo
- Publication number
- CN113032255B CN113032255B CN202110296412.4A CN202110296412A CN113032255B CN 113032255 B CN113032255 B CN 113032255B CN 202110296412 A CN202110296412 A CN 202110296412A CN 113032255 B CN113032255 B CN 113032255B
- Authority
- CN
- China
- Prior art keywords
- request packet
- packet
- input
- transmission
- 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.)
- Active
Links
- 230000004044 response Effects 0.000 title claims abstract description 267
- 238000000034 method Methods 0.000 title claims abstract description 58
- 238000012360 testing method Methods 0.000 claims abstract description 232
- 230000005540 biological transmission Effects 0.000 claims description 303
- 238000012545 processing Methods 0.000 claims description 32
- 238000004088 simulation Methods 0.000 claims description 7
- 238000011160 research Methods 0.000 abstract description 4
- 238000010586 diagram Methods 0.000 description 8
- 238000012544 monitoring process Methods 0.000 description 8
- 230000006870 function Effects 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000011161 development Methods 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
- 230000001105 regulatory effect Effects 0.000 description 1
- 230000036962 time dependent Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
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
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)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The application discloses a response noise identification method, a model, an electronic device and a computer readable storage medium, wherein the response noise identification method can be applied to stateful and stored test version application, can also be applied to a large multi-service network architecture of a mainstream Internet company and an offline scene, greatly reduces interference caused by noise in an automatic test, improves efficiency and accuracy of the automatic test, and can also 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 of ensuring the stable operation of the system is always higher than that of the development of new functions, in order to avoid the influence of the development of the new functions on the logic of the old functions, software testers need to frequently carry out the regression test of the old functions on the system, and the traditional manual test wastes a great deal of labor cost, so various automatic test schemes are generated.
In practical application, even the same version of software can generate different outputs through multiple times of the same inputs, which is mainly caused by the influence of software running environment and random algorithm in the software, and the uncontrollable difference (noise) can be mixed with the difference generated by bug, so that a tester can hardly distinguish whether the software is really problematic or not, thereby influencing the efficiency and the precision of automatic test.
For the recognition of response noise, the following schemes are currently adopted: scheme one: the platform provides response comparison result display of repeated playback, and the noise is marked manually by a tester; scheme II: and running three software instances, namely a stable version, a copy of the stable version and a test version, and simultaneously running an agent program to simultaneously send test data to the three software instances. And the noise is screened by analyzing the response difference of the stable version and the copy of the stable version, then the noise identification result is applied to the difference between the stable version and the test version, and finally the contrast difference after the noise is removed is found out.
In the first scheme, when a large number of interfaces exist in the tested software, the interface contains noise, for example: the calling chain id with random character string in the response result, the signature depending on time encryption and the like need to consume a great deal of manpower to label noise, and are not ideal in terms of manpower cost and accuracy. Scheme II is difficult to apply to mainstream large-scale Internet application architecture, namely, the application scene of scheme II is generally limited to some tool applications with small scale, off-line operation, no state and no storage.
Disclosure of Invention
The technical problem that the present application mainly solves is to provide a method for identifying response noise, electronic equipment and computer storage medium, which solves the problem that the existing scheme cannot be applied to the tested software which is in a state and stored, and cannot be deployed on the tested software which is in a large-scale multi-service network architecture and needs to run on line.
In order to solve the technical problems, one technical scheme adopted by the application is as follows: 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 transmission request packet and a first transmission response packet corresponding to the first transmission request packet; storing the first input request packet and the first input response packet to a playback background, and storing the first transmission request packet and the first transmission response packet to a virtual background; inputting the first input request packet to a test version application; collecting a second transmission request packet generated by the test version application processing the first input request packet; selecting a first transmission request packet closest to the second transmission request packet from the virtual background, and acquiring a first transmission response packet corresponding to the closest first transmission request packet; inputting a first transmission response packet corresponding to the nearest first transmission request packet into the test version application; capturing a second input response packet generated by a first transmission response packet corresponding to the first input request packet and the nearest first transmission request packet corresponding to the test version application; response noise of the test version application is determined based on the first input response packet and the second input response packet.
In order to solve the above-mentioned 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 the stable version application; the stable version packet grabbing module is further configured to grab a first input request packet generated by the stable version application processing the test data, a first input response packet corresponding to the first input request packet, a first transmission request packet, and a first transmission response packet corresponding to the first transmission request packet; the stable version packet grabbing 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 transmission request packet and the first transmission response packet to a virtual background; the analog playback module is used for inputting the first input request packet to a test version application; the simulation playback module is also used for collecting a second transmission request packet generated by the test version application processing the first input request packet; the simulation playback module is further used for selecting a first transmission request packet closest to the second transmission request packet from the virtual background, and acquiring a first transmission response packet corresponding to the closest first transmission request packet; the analog playback module is further configured to input the corresponding first transmission response packet to the test version application; the simulation playback module is further used for capturing a second input response packet generated by the first transmission response packet corresponding to the first input request packet and the test version application; and the response noise identification module is used for determining the response noise of the test version application based on the first input response packet and the second input response packet.
In order to solve the above-mentioned problem, a third aspect of the present application provides an electronic device, including a memory and a processor coupled to each other, where the processor is configured to execute program instructions stored in the memory, so as to implement the identification method of the first aspect.
In order to solve the above-mentioned problems, a fourth aspect of the present application provides a computer-readable storage medium having stored thereon program instructions which, when executed by a processor, implement the identification method of the first aspect described above.
The beneficial effects of this application are: different from the prior art, the method and the device acquire test data and input the test data into the stable version application; grabbing a first input request packet generated by processing test data by the stable version application, a first input response packet corresponding to the first input request packet, a first transmission request packet and a first transmission response packet corresponding to the first transmission request packet; storing the first input request packet and the first input response packet to a playback background, and storing the first transmission request packet and the first transmission response packet to a virtual background; inputting a first input request packet to a test version application; collecting a second transmission request packet generated by the test version application processing the first input request packet; selecting a first transmission request packet closest to the second transmission request packet from the virtual background, and acquiring a first transmission response packet corresponding to the closest first transmission request packet; inputting a first transmission response packet corresponding to the nearest first transmission request packet into the test version application; capturing a second input response packet generated by a first transmission response packet corresponding to the first input request packet and the nearest first transmission request packet by the test version application; 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 a stateful and stored test version, can be applied to a large-scale multi-service network architecture of a mainstream Internet company and an offline scene, greatly reduces interference caused by noise in an automatic test, improves efficiency and accuracy of the automatic test, and can also 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 that are needed 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 that other drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a flow chart of a first embodiment of a method for identifying response noise in the present application;
fig. 2 is a flowchart illustrating specific steps of step S102;
FIG. 3 is a schematic diagram of a data flow in the method of identifying response noise of FIG. 1;
FIG. 4 is a flow chart of a second embodiment of a method of identifying response noise of the present application;
FIG. 5 is a schematic diagram of a framework of an embodiment of the present application responsive to a noise recognition model;
FIG. 6 is a schematic structural diagram of an embodiment of an electronic device of the present application;
FIG. 7 is a schematic diagram of an embodiment of a computer-readable storage medium of the present application.
Detailed Description
The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.
Referring to fig. 1, fig. 1 is a flowchart of a first embodiment of a method for identifying response noise provided in the present application. Specifically, the method may include the steps of:
step S101, test data are acquired and input into the stable version application.
In the automatic testing process of the software, a tester is required to input specific test data as the software, the execution result of the test data is used as the output, and the difference of the output results of different versions of the tested software is compared, so that whether the BUG exists or not is analyzed. For a closed software engineering system, theoretically, the same input corresponds to the same output, that is, the same request packet corresponds to the same response packet, but in practical situations, due to the influence of the software running environment and the random algorithm inside the software, even the same content, the responses of multiple identical requests have irreproducible content, for example: time-dependent fields, random verification codes, etc., and these non-reproducible response contents are referred to as response noise. These uncontrolled response noise can mix with the differences due to the BUGs, making it difficult for the tester to distinguish whether the software itself is truly problematic, thereby affecting the efficiency and accuracy of the automated test.
In this embodiment, after the software of the stable version is started, after the test data is acquired by the stable version, when the test data is processed by the application of the stable version, a first input response packet, a first transmission request packet and a first transmission response packet corresponding to the first transmission request packet are generated. The test data comprise input data or/and on-line flow data, the input data are formed by taking specific test data as input by a tester, the on-line flow data are real on-line flow data acquired by the tester through a packet capturing program, and the on-line flow data are 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 transmission request packet and a first transmission response packet corresponding to the first transmission request packet.
In this embodiment, before the stable version application is started, the packet-grabbing program is started, and then test data is input. After the stable version application obtains the test data, the test data is processed to generate a first input request packet, a first input response packet corresponding to the first input request packet, a first transmission request packet and a first transmission response packet corresponding to the first transmission request packet. The packet grabbing program grabs the stable version application processing test data to generate all first input request packets, first input response packets corresponding to the first input request packets, first transmission request packets and first transmission response packets corresponding to the first transmission request packets.
Referring to fig. 2, fig. 2 is a flowchart illustrating steps of step S102.
Step S201: the method comprises the steps of obtaining a first sending request packet and sending the first sending request packet to a 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 transmission request packet, and the first transmission request packet is transmitted to the client. After receiving the first transmission request packet, the client performs corresponding processing to generate a first transmission response packet.
Step S202: and receiving a first transmission response packet generated by the client corresponding to the first transmission request packet.
In this embodiment, after the client generates the first transmission request packet, the client returns the first transmission request packet to the stable version application, and the stable version application receives the first transmission response.
Step S203: the first send response packet is input into the stable version application.
In this embodiment, after the stable version application receives the first transmission response packet, the first transmission response packet is input into the stable version application, that is, at this time, the stable version application has the first input request packet and the first transmission response packet input.
Step S204: the stable version application is grabbed to correspond to the first input request packet and the first input response packet generated by the first sending response packet.
In this embodiment, after the first transmission 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 transmission request packet, and the packet grabbing program grabs the first input response packet.
Step S103: storing the first input request packet and the first input response packet to a playback background, and storing the first transmission request packet and the first transmission 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 transmission request packet, and the first transmission response packet corresponding to the first transmission request packet are grabbed, the packet grabbing program further stores the first input request packet and the first input response packet in the playback background, and stores the first transmission request packet and the first transmission response packet in the virtual background. The first input request packet and the first sending response packet grabbed by the packet grabbing program 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 on 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 as an input to the test version application, 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 of the test version application due to the difference of inputs is avoided.
Step S105: the acquisition test version application processes a second transmission request packet generated by the first input request packet.
In this embodiment, 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 transmission request packet, and at the same time, sends the second transmission request packet to the virtual background for storage. In order to avoid interference caused by an online environment, the test version is applied to a server of an independent network segment, a virtual agent is required to be deployed before the test version application is deployed, and all second sending request packets generated by the first input request packet processed by the test version application are collected through the virtual agent and forwarded to a virtual background for storage.
And in the process that the test version application sends the second sending request packet to the virtual background, a virtual agent is deployed between the test version application and the virtual background, and the second sending request packet sent to the virtual background by all the test version applications is intercepted by the virtual agent. The second sending request packet is initiated by the test version application, the information such as the access address and the port 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 send to a plurality of addresses, and in order to avoid the resource cost of building a plurality of virtual background, all the second sending request packets are forwarded to the virtual background for processing.
In order to realize the unified forwarding flow, the default running network-related dynamic library is modified when the test version application is started, namely the intercepted network-related dynamic library for realizing the second sending request packet based on the C voice network library. In order to reduce the influence on the performance of the test version application, the network-related dynamic library simply transfers the second transmission request packet to the virtual proxy, and the virtual proxy uniformly forwards the modified second transmission request packet to the virtual background by modifying the address information in the network layer of the second transmission request packet, so that the virtual background uniformly analyzes and matches the second transmission request packet transmission layer and application layer messages.
Step S106: and selecting a first transmission request packet closest to the second transmission request packet from the virtual background, and acquiring a first transmission response packet corresponding to the closest first transmission request packet.
In this embodiment, after the virtual background receives 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 transmission request packet, a first transmission response packet and a second transmission request packet, and obtains a second client response packet according to the first transmission request packet and the second transmission request packet.
Specifically, after receiving the second transmission request packet, the virtual background 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 packets, and acquires a first transmission response packet corresponding to the closest first transmission request packet.
Step S107: and inputting a first transmission response packet corresponding to the closest first transmission request packet into the test version application.
In this embodiment, a first transmission response packet corresponding to a first transmission request packet closest to the test version application is input, the test version application receives the first transmission response packet corresponding to the first transmission request packet closest to the test version application, that is, the input of the test version application includes the first input request packet and the first transmission response packet corresponding to the first transmission request packet closest to the test version application, and the test version application processes the first transmission response packet corresponding to the first input request packet and the first transmission response packet closest to the first transmission request packet to obtain a second input response packet, and at this time, the first input request packet input to the test version application and the first transmission response packet corresponding to the first input request packet of the test version application and the first transmission response packet corresponding to the first transmission request packet closest to the first transmission request packet of the stable version application are in one-to-one correspondence and the same, so that output differences caused by different inputs of the test version application and the stable version application are avoided.
Step S108: the capture test version application corresponds to the first input request packet and the second input response packet generated by the first transmission response packet corresponding to the nearest first transmission request packet.
In this embodiment, after the test version application corresponds to the first input request packet and the second input response packet generated by the first transmission response packet corresponding to the closest first transmission request packet, the second input response packet is grabbed and transmitted to the playback background for storage. At this time, the response noise of the test version application is generated due to uncontrollable response noise of the server system call, so that different influences caused by different inputs of the test version application and the stable version application are avoided, and the response noise is more accurate.
Step S109: 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 are analyzed to obtain 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 by uncontrollability of the server system call, 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 first transmission response packet corresponding to the forged nearest first transmission request packet are used as inputs, namely, the software state is reproduced through the input content and the sequence of the simulation software, so that the interference of the software state on the automatic test is reduced, and the efficiency and the accuracy of the automatic test are improved.
The message formats of the first input response packet and the second input response packet have one or more message formats, for example, json, html, xml, and the comparison algorithm and the noise labeling mode can be correspondingly adjusted 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 of a data flow in the method for identifying response noise in fig. 1.
In this embodiment, a packet grabbing program is started first, and after a stable version application 301 is started, test data is input by a tester, the stable version application 301 receives a first input request packet after the test case is input, and processes the first input request packet to obtain a first transmission request packet, in this process, the packet grabbing program grabs the first input request packet input to the stable version application and the first transmission request packet sent to a client by the stable version application 301, and the packet grabbing program stores the first input request packet to a playback background 302 and stores the first transmission request packet to a virtual background 303; meanwhile, after receiving the first transmission request packet, the client processes the first transmission request packet to obtain a first transmission response packet, and sends the first transmission response packet to the stable version application 301, and when the stable version application 301 receives the first transmission response packet, the packet grabbing program grabs the first transmission response packet and stores the first transmission response packet in the virtual background 303; after receiving the first transmission response packet, the stable version application 301 processes the first input request packet and the first transmission response packet to obtain a first input response packet, and the packet grabbing program grabs 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 to the test version application 304, processing the first input request packet received by the test version application 304 to obtain a second transmission request packet, and transmitting the second transmission request packet to a virtual background 303 for storage; in the virtual background 303, the second transmission request packet stored in the virtual background 303 is processed, specifically, the second transmission request packet is compared with the first transmission request packet, so that when a first transmission request packet closest to the second transmission request packet is selected, a first transmission response packet corresponding to the closest first transmission request packet is extracted from the virtual background 303 as input and sent to the test version application 304, the test version application 304 receives the first transmission response packet corresponding to the first transmission request packet received most, processes the first transmission response packet corresponding to the first input request packet and the first transmission response packet received most, obtains a second input response packet, and sends the second transmission 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 are virtually identical to the first input request packet input to the test version application 304 and the first transmission response packet most received, that is, the requests input to the stable version application 301 and the test version application 304 are identical, while the first input response packet and the second input response packet returned by the same input are theoretically identical, but the first input response packet and the second input response packet returned by the same input actually have nonrecoverable contents, that is, response noise, due to the influence of the running environments of the stable version application 301 and the test version application 304 and the software internal algorithm under the actual request, and the response noise can be recognized and analyzed by the first input response packet and the second input response packet. The identified response noise can be rapidly and accurately distinguished from the difference generated by the BUG through the response noise identified by the identification method in the automatic test process, so that the difference generated by the BUG is found, and the efficiency and the accuracy of the automatic test are further improved.
Compared with the prior art, the method for identifying response noise is provided, can be applied to a test version with states and storage, can be applied to a large multi-service network architecture of a mainstream Internet company and an offline scene, greatly reduces interference caused by noise in an automatic test, improves efficiency and accuracy of the automatic test, and can also provide data support for advanced research schemes such as script-free regression test, full-link pressure test and the like.
Referring to fig. 4, fig. 4 is a flowchart illustrating a second example of the method for identifying response noise provided in the present application, where the method for identifying response noise includes:
step S401: a stable version application is started.
In this embodiment, a stable version application is started, and the stable version application itself will send out a first transmission request packet during the startup period, where the first transmission request packet is generally a request for various pull configurations.
Step S402: and grabbing a first transmission request packet generated by starting the stable version application and a first transmission response packet corresponding to the first transmission request packet.
In this embodiment, before the stable version application is started, a packet grabbing program is started, and a first transmission request packet generated by starting the stable version application and a first transmission response packet corresponding to the first transmission request packet can be grabbed by the packet grabbing program.
Step S403: and storing the first transmission request packet and the first transmission response packet generated by starting the stable version application into the virtual background.
In this embodiment, after the packet grabbing program grabs the first transmission request packet and the first transmission response packet during the start of the stable version application, the first transmission request packet and the first transmission 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 provided.
Step S404: test data is obtained and input into a stable version application.
Step S404 is the same as step S101, and will not be described here 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 transmission request packet and a first transmission response packet corresponding to the first transmission request packet.
Step S405 is the same as step S102 described above, and will not be described again here.
Step S406: storing the first input request packet and the first input response packet to a playback background, and storing the first transmission request packet and the first transmission response packet to a virtual background.
Step S406 is the same as step S103 described above, and will not be described again here.
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 as an input to the test version application, 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 of the test version application due to the difference of inputs is avoided.
Wherein the step of inputting the first input request packet to the test version application further comprises: in response to the test version application having been normally launched, a first input request packet is input to the test version application.
In particular, when the test is automated, the analog playback takes longer to record, and the playback takes longer to record, but when the test data comes from an 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 same time is consumed for each playback, the efficiency of the whole automated test is reduced. Therefore, in order to improve the automation test efficiency, it is necessary to monitor the start state of the test version application during the analog playback.
In the process of simulating playback, the test version application needs to be waited for normal starting, and the starting time of the test version application cannot be regulated, 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 transmission request packets are stored in the virtual background. Specifically, when the stable version acquires the test data, monitoring 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 all first transmission request packets are stored in the virtual background before the first input request packet is transmitted to the test version application, starting the test version application.
Before the first input request packet is input into the test version application, the test version application is started in response to the fact that the second transmission request packet generated by the stable version application is completely transmitted, and the first input request packet is input into the test version application from the playback background.
Meanwhile, in order to enable the system to more accurately judge whether the test version application is started or not, whether the test version application is started normally is determined through a preset mode, wherein the preset mode comprises the mode of monitoring through heartbeat or other second request packet sending triggered by a timing task, and whether the test version application is started normally is judged. Further, the second transmission request packet may not be completely reproduced during simulation, and may be monitored according to parameters such as the start time of the test version application and the capture percentage of the second transmission request packet, so as to adjust the start monitoring effect of different test version applications. Optionally, a custom starting judgment plug-in can be added, and different monitoring parameters are set through the custom starting judgment plug-in, so that a system can more accurately judge whether the test version application is started or not.
After the test version application is determined to be started, multiple playback, sequential playback, gradual playback and other playback modes can be realized by using a method of a common playback tool such as tcpdump, and the like, and a tester can select a proper playback mode under different scenes, so that the efficiency and the accuracy are improved.
Step S408: the acquisition test version application processes a second transmission request packet generated by the first input request packet.
Step S408 is the same as step S105 described above, and will not be described again here.
Step S409: and selecting a first transmission request packet closest to the second transmission request packet from the virtual background, and acquiring a first transmission response packet corresponding to the closest first transmission request packet.
Step S409 is the same as step S106 described above, and will not be described again here.
Step S410: and inputting a first transmission response packet corresponding to the closest first transmission request packet into the test version application.
Step S410 is the same as step S107 described above, and will not be described again here.
Step S411: the capture test version application corresponds to the first input request packet and the second input response packet generated by the first transmission response packet corresponding to the nearest first transmission request packet.
Step S411 is the same as step S108 described above, and will not be described again here.
Step S412: 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 described above, and will not be described again here.
Compared with the prior art, the method for identifying response noise is provided, can be applied to a test version with states and storage, can be applied to a large multi-service network architecture of a mainstream Internet company and an offline scene, greatly reduces interference caused by noise in an automatic test, improves efficiency and accuracy of the automatic test, and can also provide data support for advanced research schemes such as script-free regression test, full-link pressure test and the like.
Referring to fig. 5, fig. 5 is a schematic diagram of an embodiment of a response noise recognition model of the present application. The response noise identification model 50 includes: the stable version package grabbing module 501 is used for acquiring test data and inputting the test data into the stable version application; the stable version grabbing module 501 is further configured to grab a first input request packet generated by processing test data by the stable version application, a first input response packet corresponding to the first input request packet, a first transmission request packet, and a first transmission response packet corresponding to the first transmission request packet; the stable version packet capturing module 501 is further configured to store a first input request packet and a first input response packet to the playback background, and store a first transmission request packet and a first transmission response packet to the virtual background; the analog playback module 502, the analog playback module 502 is configured to input a first input request packet to the test version application; the analog playback module 502 is further configured to collect a second transmission request packet generated by the test version application processing the first input request packet; the analog playback module 502 is further configured to select a first transmission request packet closest to the second transmission request packet from the virtual background, and obtain a first transmission response packet corresponding to the closest first transmission request packet; the analog playback module 502 is further configured to input a corresponding first transmission response packet to the test version application; the analog playback module 502 is further configured to capture a second input response packet generated by the test version application corresponding to the first input request packet and the corresponding first transmission response packet; the response noise identification module 503, the response noise identification module 503 is configured to determine response noise of the test version application based on the first input response packet and the second input response packet.
The stable packet grabbing module 501 is specifically configured to grab a first input request packet generated by processing test data by a stable version application after a packet grabbing program is started, a first input response packet corresponding to the first input request packet, a first transmission request packet, and a first transmission response packet corresponding to the first transmission request packet. After the first input request packet, the first input response packet corresponding to the first input request packet, the first transmission request packet and the first transmission response packet corresponding to the first transmission request packet are captured, the first input request packet and the first input response packet are stored in a playback background, and the first transmission request packet and the first transmission response packet are stored in a virtual background. Therefore, the first input request packet and the first sending response packet grabbed by the stable grabbing 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 on 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 grabbing module 501 as input to the test version application, and 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 transmission request packet, and meanwhile, sends the second transmission request packet to the virtual background for storage. And when the test version application transmits a second transmission request packet to the virtual background, the virtual proxy collects the second transmission request packet generated by the test version application processing the first input request packet.
After receiving and storing the second transmission request packet, the virtual background stores the first transmission request packet, the first transmission response packet and the second transmission request packet, and obtains a second client response packet according to the first transmission request packet and the second transmission request packet. The analog playback module 502 performs packet comparison between the second transmission request packet and the first transmission request packet, selects a first transmission request packet closest to the second transmission request packet from the first transmission request packets, and obtains a first transmission response packet corresponding to the closest first transmission request packet.
The analog playback module 502 inputs the first transmission response packet corresponding to the nearest first transmission request packet to the test version application, at this time, the input of the test version application includes the first input request packet and the first transmission response packet corresponding to the nearest first transmission request packet, the test version application processes the first transmission response packet corresponding to the first input request packet and the nearest first transmission request packet to obtain the second input response packet, at this time, the first input request packet and the first transmission response packet input to the test version application are in one-to-one correspondence with and the same as the first transmission response packet corresponding to the nearest first transmission request packet, so that the output difference caused by the difference of inputs of the test version application and the stable version application is avoided.
The analog playback module 502 captures a second input response packet generated by the first input request packet corresponding to the test version application and the first transmission response packet corresponding to the closest first transmission request packet, and transmits the second input response packet to the playback background for storage.
The analog playback module 502 is further configured to input a first input request packet to the test version application in response to the test version application having been normally launched. 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 all the transmission of the second transmission request packet generated by the stable version application, and inputs the first input request packet into the test version application from the playback background.
The analog playback module 502 is further configured to determine whether the test version application has been started normally in a preset manner. The preset mode comprises judging whether the test version application is normally started or not through heartbeat monitoring or other modes of sending a request packet by a second time triggered by the timing task. Optionally, the analog playback module 502 may further monitor 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 analog playback module 502 may further add a custom startup determination plug-in, and set different monitoring parameters through the custom startup determination plug-in, so that the system can more accurately determine whether the test version application is started.
The response noise identifying module 503 is specifically configured to determine, based on the first input response packet and the second input response packet, response noise of the test version application, where the response noise of the test version application is response noise generated by uncontrollably calling the server system, so that different effects 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 first transmission response packet corresponding to the forged nearest first transmission request packet are used as inputs, namely, the software state is reproduced through the input content and the sequence of the simulation software, so that the interference of the software state on 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 diagram of a frame of an embodiment of the electronic device of the present application. The electronic device 60 comprises a memory 601 and a processor 602 coupled to each other, the processor 602 being adapted to execute program instructions stored in the memory 601 to implement the steps of any of the above-described identification method embodiments. 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 identification method embodiments described above. The 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 (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a Field programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic device, 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 an integrated circuit chip.
In the above-described scheme, the processor 602 acquires the test data and inputs the test data into the stable version application; grabbing a first input request packet generated by processing test data by the stable version application, a first input response packet corresponding to the first input request packet, a first transmission request packet and a first transmission response packet corresponding to the first transmission request packet; storing the first input request packet and the first input response packet to a playback background, and storing the first transmission request packet and the first transmission response packet to a virtual background; inputting a first input request packet to a test version application; collecting a second transmission request packet generated by the test version application processing the first input request packet; selecting a first transmission request packet closest to the second transmission request packet from the virtual background, and acquiring a first transmission response packet corresponding to the closest first transmission request packet; inputting a first transmission response packet corresponding to the nearest first transmission request packet into the test version application; capturing a second input response packet generated by a first transmission response packet corresponding to the first input request packet and the nearest first transmission request packet by the test version application; 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 schematic diagram illustrating an embodiment of a computer readable storage medium of the present application. The computer readable storage medium 70 stores program instructions 700 that can be executed by a processor, the program instructions 700 being configured to implement the steps of any of the identification method embodiments described above.
In the several embodiments provided in the present application, it should be understood that the disclosed methods, models, and apparatuses may be implemented in other manners. For example, the model embodiments described above are merely illustrative, e.g., the division of modules or units is merely a logical functional division, and there may be additional divisions of actual implementation, e.g., units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical, or other forms.
The elements illustrated as separate elements may or may not be physically separate, and elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over network elements. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiment.
In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in part or all or part of the technical solution contributing to the prior art or in the form of a software product stored in a storage medium, including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (processor) to perform all or part of the steps of the methods of 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, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
Claims (9)
1. 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 transmission request packet and a first transmission response packet corresponding to the first transmission request packet;
storing the first input request packet and the first input response packet to a playback background, and storing the first transmission request packet and the first transmission response packet to a virtual background;
inputting the first input request packet to a test version application;
collecting a second transmission request packet generated by the test version application processing the first input request packet;
selecting a first transmission request packet closest to the second transmission request packet from the virtual background, and acquiring a first transmission response packet corresponding to the closest first transmission request packet;
inputting a first transmission response packet corresponding to the nearest first transmission request packet into the test version application;
capturing a second input response packet generated by a first transmission response packet corresponding to the first input request packet and the nearest first transmission request packet corresponding to the test version application;
Determining a response noise of the test version application based on the first input response packet and the second input response packet;
the step of collecting the second transmission request packet generated by processing the test data by the test version includes:
collecting a second transmission request packet generated by processing the first input request packet through the virtual proxy, and storing the second transmission request packet to the virtual background;
the step of collecting, by the virtual agent, a second transmission request packet generated by the test version processing the first input request packet, and storing the second transmission request packet in the virtual background includes:
and modifying address information in a network layer of the second transmission request packet through the virtual agent, and storing the modified second transmission request packet to the virtual background.
2. The method of claim 1, wherein the step of capturing the first input request packet generated by the stable version application processing the test data, the first input response packet corresponding to the first input request packet, the first transmission request packet, and the first transmission response packet corresponding to the first transmission request packet comprises:
Acquiring the first transmission request packet, and transmitting the first transmission request packet to a client;
receiving the first transmission response packet generated by the client corresponding to the first transmission request packet;
inputting the first send response packet into the stable version application;
and grabbing a first input response packet generated by the stable version application corresponding to the first input request packet and the first sending response packet.
3. The method of claim 1-2, wherein the step of inputting the first input request packet to a test version application comprises:
and in response to the test version application having been normally started, inputting the first input request packet to the test version application.
4. The method of claim 2, 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 completion of the transmission of the second transmission request packet generated by the stable version application, starting the test version application, and inputting the first input request packet to the test version application.
5. The method of claim 1, wherein the step of capturing the first input request packet generated by the stable version application processing the test data, the first input response packet corresponding to the first input request packet, the first transmission request packet, and the first transmission response packet corresponding to the first transmission request packet comprises:
and grabbing the first input request packet, the first input response packet corresponding to the first input request packet, the first transmission request packet and the first transmission response packet corresponding to the first transmission request packet by using a packet grabbing program.
6. The method of claim 1, wherein the step of obtaining test data and inputting the test data into a stationary version application is preceded by the steps of:
starting the stable version application;
capturing a first transmission request packet generated by starting the stable version application and a first transmission response packet corresponding to the first transmission request packet;
and storing the first transmission request packet and the first transmission response packet generated by starting the stable version application into the virtual background.
7. A response noise recognition model, comprising:
the stable version packet capturing module is used for acquiring test data and inputting the test data into the stable version application;
the stable version packet grabbing module is further configured to grab a first input request packet generated by the stable version application processing the test data, a first input response packet corresponding to the first input request packet, a first transmission request packet, and a first transmission response packet corresponding to the first transmission request packet;
the stable version packet grabbing 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 transmission request packet and the first transmission response packet to a virtual background;
the analog playback module is used for inputting the first input request packet to a test version application;
the simulation playback module is also used for collecting a second transmission request packet generated by the test version application processing the first input request packet;
the simulation playback module is further used for selecting a first transmission request packet closest to the second transmission request packet from the virtual background, and acquiring a first transmission response packet corresponding to the closest first transmission request packet;
The analog playback module is further configured to input the corresponding first transmission response packet to the test version application;
the simulation playback module is further used for capturing a second input response packet generated by the first transmission response packet corresponding to the first input request packet and the test version application;
and the response noise identification module is used for determining the response noise of the test version application based on the first input response packet and the second input response packet.
8. 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 6.
9. A computer readable storage medium having stored thereon program instructions executable to perform the steps of the identification method according to any of claims 1-6.
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 CN113032255A (en) | 2021-06-25 |
| CN113032255B true 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) |
Families Citing this family (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 (4)
| 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 |
| 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 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3001309B1 (en) * | 2013-01-24 | 2015-01-09 | St Microelectronics Rousset | METHOD OF PROCESSING TRANSMISSION ERRORS, IN PARTICULAR THOSE RESULTING FROM NOISE, IN CONTACTLESS COMMUNICATION BETWEEN A CARD AND A READER. |
-
2021
- 2021-03-19 CN CN202110296412.4A patent/CN113032255B/en active Active
Patent Citations (4)
| 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 |
| 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 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113032255A (en) | 2021-06-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111045952B (en) | Software testing method, flow playback device, terminal equipment and readable storage medium | |
| CN109361562B (en) | Automatic testing method based on associated network equipment access | |
| US20070097872A1 (en) | Network connection apparatus testing method | |
| US20080168425A1 (en) | Software testing techniques for stack-based environments | |
| CN112714047A (en) | Industrial control protocol flow based test method, device, equipment and storage medium | |
| CN107229566B (en) | Method and system for maintaining functional consistency of SOA service conversion language | |
| CN109739711B (en) | Interface test method, device, equipment and storage medium | |
| CN109284227A (en) | A kind of automation method for testing pressure and device calculate equipment and storage medium | |
| CN113067738A (en) | Network topology visualization function equipment compatibility testing method and system | |
| CN113032255B (en) | Response noise identification method, model, electronic device and computer storage medium | |
| CN114844811A (en) | Vehicle-mounted terminal testing method and system | |
| CN114338347A (en) | Ampere platform-based fault information out-of-band acquisition method and device | |
| Xue et al. | Is what you measure what you expect? factors affecting smartphone-based mobile network measurement | |
| CN112867024A (en) | Test method, system and communication equipment | |
| CN116166536A (en) | Test method, test device, electronic equipment and storage medium | |
| CN115904388A (en) | Application program protocol analysis method, device, equipment and storage medium | |
| CN113934642B (en) | Software compatibility testing method based on dynamic and static combination | |
| CN114666257A (en) | Network protocol fuzzy test method and framework | |
| CN113535273A (en) | System-level recording method and system of industrial networked intelligent equipment and storage medium | |
| CN115391127A (en) | Dial testing method and device, storage medium and chip | |
| CN106354626A (en) | Application test and method, system and device realizing application test in multiple terminals | |
| CN111193639A (en) | Network quality detection processing method and system | |
| EP3029573A1 (en) | System and method for testing the performance of a computing infrastructure | |
| CN113903368B (en) | Automatic test method, device and equipment for disc and storage medium | |
| CN116112413A (en) | Network equipment testing method, system, device, storage medium and electronic equipment |
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 |