Test method and device based on flow playback, electronic equipment and test plug-in

Abstract

The invention discloses a test method based on flow playback, a test device based on flow playback, electronic equipment and a test plug-in based on flow playback. Research finds that the test method in the related technology affects the performance and stability of the old service because the test method has strong invasion to the old service. Based on this, the test plug-in for traffic playback is installed on the electronic device corresponding to the old service, and intrusion to the old service is avoided through the test plug-in, so that the test is completed on the premise of ensuring the performance and stability of the old service. Specifically, a test plug-in can obtain first request data of an old service and first response data corresponding to the first request data; sending second request data obtained by copying the first request data to the new service to obtain second response data of the new service for the second request data; and after the first request data, the first response data and the second response data are obtained, performing analysis to obtain a test result.

Description

Technical Field

[0001] The present application belongs to the field of computer technology, and in particular, relates to a test method based on traffic playback, a test device based on traffic playback, an electronic device, and a test plug-in based on traffic playback. Background Art

[0002] In order to verify and evaluate the performance of new services or reconstructed service interfaces in a real production environment and ensure that their functions and performance are consistent with old services or meet expected standards, traffic replay is usually used for software testing in related technologies.

[0003] However, research has found that the current software testing method of traffic playback can easily affect the stability and performance of old services. In order to ensure the stability and performance of old services, a new testing method is urgently needed. Summary of the invention

[0004] The present application provides a test method based on traffic playback, a test device based on traffic playback, an electronic device and a test plug-in based on traffic playback, which do not require intrusion into old services and can complete the test under the premise of ensuring the performance and stability of old services.

[0005] In a first aspect, the present application provides a test method based on traffic playback, the test method is applied to a test plug-in for traffic playback installed on an electronic device corresponding to an old service, and the test method includes:

[0006] Obtain the first request data of the old service and the first response data corresponding to the first request data;

[0007] Sending the second request data obtained by copying the first request data to the new service;

[0008] Obtain second response data of the new service for the second request data;

[0009] A test result is determined based on the first request data, the first response data, and the second response data.

[0010] In a second aspect, the present application provides a test device based on traffic playback, which is applied to a test plug-in for traffic playback installed on an electronic device corresponding to an old service, including:

[0011] A first acquisition module, used to acquire first request data of an old service and first response data corresponding to the first request data;

[0012] A test module, used for sending second request data obtained by copying the first request data to the new service;

[0013] A second acquisition module, used to acquire second response data of the new service to the second request data;

[0014] The first determining module is used to determine a test result based on the first request data, the first response data and the second response data.

[0015] In a third aspect, the present application provides an electronic device comprising a memory, a processor, and a traffic playback-based test plug-in stored in the memory and executable on the processor, wherein the processor implements the steps of the method of the first aspect when executing the test plug-in.

[0016] In a fourth aspect, the present application provides a computer-readable storage medium, which contains a test plug-in based on traffic playback, and when the test plug-in is executed by a processor, the steps of the method of the first aspect are implemented.

[0017] In a fifth aspect, the present application provides a test plug-in based on traffic playback, which implements the steps of the method in the first aspect when executed by one or more processors.

[0018] Compared with the prior art, the present application has the following beneficial effects: by installing a test plug-in on the electronic device where the old service is located, direct intrusion into the old service can be avoided, thereby completing the test under the premise of ensuring the performance and stability of the old service. Specifically, the test plug-in can capture the first request data of the old service and its corresponding first response data; then, the test plug-in copies the first request data and sends it to the new service to obtain the second response data of the new service to the data; finally, the test result is obtained by analyzing the first request data, the first response data, and the second response data. This method can complete software testing without intruding into the old service, effectively ensuring the performance and stability of the old service.

[0019] It can be understood that the beneficial effects of the second to fifth aspects can be found in the relevant description of the first aspect and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0021] Figure 1 It is a flow chart of a test method based on traffic playback provided in an embodiment of the present application;

[0022] Figure 2 It is a structural schematic diagram of a test device based on traffic playback provided in an embodiment of the present application;

[0023] Figure 3It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0024] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0025] In related technologies, traffic replay is usually used for software testing in order to verify and evaluate the performance of new services or reconstructed service interfaces in real production environments and ensure that their functions and performance are consistent with old services or meet expected standards. However, research has found that the current software testing method of traffic replay is likely to affect the stability and performance of old services.

[0026] In order to solve this problem, the present application first conducts an in-depth exploration of the software testing methods that affect the stability and performance of the old service in the related art, and finds that the reason why this testing method affects the performance and stability of the old service is that this testing method has a strong intrusion on the old service. Based on this, the present application proposes a testing method based on traffic playback, which can avoid direct intrusion on the old service, thereby completing the test under the premise of ensuring the performance and stability of the old service. The control method proposed in the present application will be described below through specific embodiments.

[0027] The test method based on traffic playback provided in the embodiment of the present application can be applied to the test plug-in for traffic playback installed on the electronic device corresponding to the old service. The electronic device can be a mobile phone, a tablet computer, a vehicle-mounted device, an augmented reality (AR) / virtual reality (VR) device, a laptop computer, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), etc. The embodiment of the present application does not impose any restrictions on the specific type of the electronic device.

[0028] In order to illustrate the technical solution proposed in this application, each embodiment will be described below using the test plug-in as the execution subject.

[0029] Figure 1 A schematic flow chart of a test method based on traffic playback provided by the present application is shown, and the test method based on traffic playback includes:

[0030] Step 110: The test plug-in obtains the first request data of the old service and the first response data corresponding to the first request data.

[0031] The related technology is to add traffic replication code to the old service to implement the test method, which increases the invasiveness of the old service, increases the complexity and resource consumption to varying degrees, and thus affects the stability and performance of the old service. In order to ensure the stability and performance of the old service, the software testing function of traffic playback is implemented by developing corresponding test plug-ins. The test plug-in can still copy the traffic to implement the test without invading the old service code. The test plug-in has the characteristics of high development efficiency, flexible use and easy maintenance, which provides a new path for the test method based on traffic playback.

[0032] The test plug-in can be used after being installed on the electronic device of the old service. When a test is required, the test plug-in can be started through a shell command. After being started, the test plug-in can monitor the port of the old service to obtain the first request data of the old service and the first response data fed back by the old service based on the first request data.

[0033] Step 120: The test plug-in sends the second request data obtained by copying the first request data to the new service.

[0034] Step 130: The test plug-in obtains second response data of the new service for the second request data.

[0035] To verify the performance of the new service, you can control the variables, that is, let the new and old services process the same request data at the same time, and get two response data respectively. Then, confirm whether the new service has passed the test based on the response results.

[0036] Based on this test principle, the test plug-in first copies the first request data to obtain the second request data, which is a copy of the first request data; then sends the second request data to the new service to obtain the second response data fed back by the new service based on the second request data.

[0037] Step 140: The test plug-in determines a test result based on the first request data, the first response data, and the second response data.

[0038] After the above steps, the test plug-in can complete the corresponding traffic playback test. The test data obtained by the test can be analyzed together with the corresponding request data to determine whether the new service is qualified and obtain the test result.

[0039] The embodiment of the present application implements new service testing based on traffic playback by installing a traffic playback test plug-in on the electronic device where the old service is located, which can avoid direct intrusion into the old service, thereby determining whether the new service passes the test while ensuring the performance and stability of the old service.

[0040] In some embodiments, in order to obtain the first request data and the first response data, the aforementioned step 110 specifically includes:

[0041] Step A1: Within a preset time period, the test plug-in captures at least one request data packet and at least one response data packet of the old service through the data packet capture interface.

[0042] As can be seen from the foregoing, there is a corresponding relationship between the first request data and the first response data. In order to accurately obtain the first request data and the first response data from the old service, the test plug-in can monitor at least one request data packet received by the interface of the old service within a period of time, and at least one response data packet output by the response processing for at least one request data.

[0043] For example, if two request packets are received within 5 seconds, it can be understood that they correspond to two request data. Accordingly, if there is no packet loss or delayed processing, it is highly likely that the old service can respond based on these two packets and output two response packets, which correspond to two response data. There is a one-to-one correspondence between the request packet and the response packet.

[0044] Among them, the capture of the two types of data packets can be obtained through the Packet Capturing API. Specifically, the test plug-in adds a bypass process through the Packet Capturing API at the data link layer of the old service. As a result, the Packet Capturing API can filter and buffer the request data packet and the response data packet based on the Linux kernel, and finally pass them to the test plug-in. It can be understood that the same is true for the new service. Given that the first request data and the second request data are equivalent, the difference in the capture process of the data packet between the new / old services is that the new service can only capture the second response data, thereby shortening the time required for data capture.

[0045] Step A2: The test plug-in parses the request data packet and the response data packet to obtain at least one request data and at least one response data.

[0046] As an upper-layer application, the test plug-in can further process the data passed by the Packet Capturing API. In order to verify which request data corresponds to which response data, the test plug-in can parse the two data packets. Each request data packet can be parsed to obtain a request data, and each response data packet can be parsed to obtain a response data.

[0047] Step A3: The test plug-in determines the request data and response data with the same identifier as the first request data and the first response data.

[0048] In the process of network communication, in order to establish the correspondence between request data and response data, a specific identifier can generally be set through the protocol, such as the "stream ID" in the HTTP protocol, the identifier and sequence number in the Ping request and response (ICMP Echo Request and Echo Reply) in ICMP (Ping). Based on this, the test plug-in can determine the first request data and the first response data that have a corresponding relationship from each request data and each response data according to the identifier.

[0049] It can be understood that if there are multiple response data and multiple request data, each response data can be matched with each request data according to the identifier. Among them, a matched response data and a corresponding request data are the first request data and the first response data. For the convenience of description, a group of first request data and first response data is recorded as a group of associated data. If multiple groups of associated data are determined, in order to improve the accuracy of the traffic replay test, a traffic replay test can be performed based on each group of associated data.

[0050] Among them, the steps of the traffic playback test for each group of associated data are shown in the aforementioned steps 110 to 130. Accordingly, if there are multiple associated data, the final test results will be comprehensively evaluated based on each group of traffic playback test data, for example, by assigning a value to each group of test results, and calculating the total score by weighting, and comparing the total score with the corresponding threshold to obtain a clear test result. Obviously, compared with the method based on testing only a single group of associated data, this method can improve the reliability of the test results.

[0051] In this embodiment, the test plug-in implements data packet interception processing through the Packet Capturing API to further obtain the basic data required for the traffic playback test. In order to ensure the accuracy of the data, the parsed response data and request data are also matched during the processing process to obtain at least one set of related data, so as to test the new service more fully and comprehensively, thereby improving the accuracy of the new service test results.

[0052] In some embodiments, after obtaining the result corresponding to the traffic playback test, the following steps may be performed:

[0053] Step B1: The test plug-in merges and structures the first request data, the first response data, and the second response data to obtain basic data.

[0054] Step B2: The test plug-in determines the test result based on the basic data.

[0055] The test plug-in can extract valid information from the first request data, the first response data, and the second response data, and combine the valid information into a higher-level, structured form to facilitate analysis, storage, and processing of each set of test data. Each set of data after merging and structuring is the basic data for analyzing the test results of the new service. Therefore, after obtaining the basic data, the test plug-in can analyze it based on the basic data to obtain the final test results.

[0056] For example, to facilitate analysis, the test plug-in may send basic data to Elasticsearch, so that the analysis process can rely on its distributed search and analysis capabilities to obtain test results more efficiently.

[0057] In some embodiments, the aforementioned step B1 specifically includes:

[0058] Step B11: The test plug-in fills a preset data structure based on the first request data, the first response data, and the second response data to obtain merged data.

[0059] For each set of test data (first request data, first response data and second response data), it corresponds to the same identifier. Therefore, the identifier can be used as a unique mark for data merging to ensure the consistency between the response data output by the new / old services for the same request data.

[0060] In order to effectively combine different data in the entire test data, the test plug-in can design a corresponding preset data structure based on the first request data, the first response data and the second response data, and complete the data merging by filling in the preset data result to obtain the merged data.

[0061] Specifically, the request data and the two response data are reorganized into a whole data object. This process can extract valid fields (such as URL, request parameters, response time, response content, etc.) from each data packet, and then merge these fields into a unified data structure.

[0062] In addition, a timestamp may be added to the data packet to record the time sequence between the request and each response. The data request timestamp corresponding to the second response data may record the timestamp when the new service receives the second request data, which helps to determine the performance difference of the new / old service in processing the same request data based on the request response time.

[0063] Step B12: The test plug-in standardizes the fields of the merged data and adds specified metadata to obtain initial basic data.

[0064] The test plug-in can first standardize the fields in the merged data, and then define clear labels and mapping relationships for the standardized fields, such as mapping the request URL, parameters, request header, response status code, response body, etc. to the corresponding fields in the merged data to obtain the initial basic data. The initial basic data is convenient for Elasticsearch to store and index.

[0065] Step B13: The test plug-in formats the initial basic data based on the specified format to obtain basic data.

[0066] In order to make the final data easier to retrieve by Elasticsearch, the test plug-in can also format the initial basic data into a specified format, such as XML or JSON.

[0067] In this embodiment, Elasticsearch is relied upon to achieve efficient data analysis to obtain test results. Therefore, for each set of related data, preprocessing is performed around Elasticsearch, that is, merging and structuring, so that the valid data corresponding to each set of related data can be stored in Elasticsearch, and it is convenient for Elasticsearch to perform index retrieval, thereby laying the foundation for subsequent data analysis.

[0068] In some embodiments, based on the basic data, the test plug-in can determine whether the new service is qualified by the following steps:

[0069] Step C1: If the interface status code of the old service in the basic data is consistent with the interface status code of the new service; and / or if the business data name of the old service in the basic data is consistent with the business data name in the new service, the test result is determined to be qualified.

[0070] Step C2: If the interface status code of the old service in the basic data is inconsistent with the interface status code of the new service; and / or if the business data name of the old service in the basic data is inconsistent with the business data name of the new service, the test result is determined to be unqualified.

[0071] Generally, the interface status and / or business data name of a qualified new service are consistent with those of the old service. Whether these two judgment conditions are met at the same time or only one condition is met can be determined according to the actual situation. Based on this, whether the new service is qualified can be determined based on whether the interface status code of the old service in the basic data is consistent with the interface status code of the new service, and / or whether the business data name of the old service in the basic data is consistent with the business data name in the new service.

[0072] For example, if the interface status and business data name of a qualified new service are required to be consistent with those of the old service, then when responseA.code==responseB.code in the basic data (indicating that the new / old interface status codes are consistent), and responseA.code==responseB.code and responseA.data.name==responseB.data.name (indicating that the names of the new / old service business data are equal), the test result of the new service is determined to be qualified.

[0073] In this embodiment, the analysis rules of the test data may be set according to the characteristics of the qualified new service, so as to efficiently and accurately determine whether the new service is qualified.

[0074] In some embodiments, if the processing logics of the new and old services are different, even if the new and old services implement the same functions, the required input data may be different. In this case, the new and old services may output different response data for the same request data, resulting in the new service failing the test. However, it is clear that the real reason for the new service failing the test is not that the new service cannot be consistent with the old service, but that some key parameters are missing.

[0075] Exemplarily, both the old service and the new service of the e-commerce platform are responsible for processing the user's commodity purchase request.

[0076] Logic of the old service: When the old service processes request a, if the user does not provide an optional parameter (such as "coupon code"), the old service will automatically select the best coupon for the user and apply it to the order.

[0077] Logic of the new service: When processing the same request a, the new service requires the user to explicitly provide the "coupon code" parameter, otherwise no discount will be applied to the user.

[0078] Suppose we send a request a in our test, but no "coupon code" parameter is provided in that request.

[0079] When the old service processes this request, it automatically applies a coupon and outputs a discounted order price (response r1).

[0080] When the new service processes the same request, since there is no "coupon code" parameter in request a, the new service outputs the order price according to the original price (response r2).

[0081] Obviously, the responses r1 and r2 of the new / old services are inconsistent. This inconsistency is not because there is a problem with the processing logic of the new service, but because request a lacks the "coupon code" parameter required by the new service. If the completeness and accuracy of request a is not verified during testing, it may be mistakenly believed that there is a problem with the processing logic of the new service.

[0082] In order to avoid the above situation causing the test data to obtain erroneous test results in the subsequent analysis process, before step B2, the following steps are also included:

[0083] Step D1, the test plug-in verifies the first request data.

[0084] The test plug-in can set the verification rules for the first request data according to the differences between the new / old services actually tested. For example, based on the above example, the test plug-in can verify whether the first request data contains the parameters required for the new service; since the request data may be modified, truncated, or lose information during the copying and transmission process, in order to deal with these situations, the test plug-in can verify the first request data in combination with the second request data. Of course, in addition to the above two situations where the first request data needs to be verified, there may be other situations, which are not listed here, and this application does not limit the situations where the first request data needs to be verified.

[0085] Step D2: When the first request data verification succeeds, the test plug-in determines the test result based on the basic data.

[0086] In order to ensure the accuracy of the test results, the test plug-in determines the test results based on the basic data only after the first request data verification succeeds. It is understandable that after the first request data verification fails, the test plug-in can add the verification results to the basic data and use the verification results to correct the test results, thereby obtaining a more accurate test result.

[0087] In this embodiment, the test plug-in can improve the accuracy and reliability of the test result by verifying the request data.

[0088] In some embodiments, when the test result fails, there are many reasons, such as the new service cannot be run, or the running logic of the new service has problems, resulting in the test failure. In order to automatically locate the first situation, when determining that the test result fails, it also includes:

[0089] Step E1: The test plug-in searches the local log for target basic data corresponding to the test result.

[0090] If the test result is unqualified, the tester can find the target basic data corresponding to the test result from the local log, so as to trace the source through the target basic data and determine the real reason for the failure.

[0091] Step E2: If the data corresponding to the second response data in the target basic data is empty, the test plug-in determines that the new service is not running.

[0092] If the data in the field corresponding to the second response data in the target basic data is empty, it means that the new service is not running based on the second request data. At this time, the test plug-in can directly use the reason for the test failure as the new service not running as part of the test result, so that the R&D personnel can track, repair or debug the new service based on the test results.

[0093] In this embodiment, if the new service test fails due to the reason that the new service cannot run, the test plug-in can directly write the reason into the test result, which helps R&D personnel to identify the problems with the new service and then efficiently debug or repair the new service for retesting.

[0094] It should be understood that the size of the serial numbers of the steps in the embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0095] Corresponding to the test method based on traffic playback in the above embodiment, Figure 2 The structural block diagram of the test device 2 based on traffic playback provided in the embodiment of the present application is shown, which is applied to the test plug-in of traffic playback installed on the electronic device corresponding to the old service. For the convenience of explanation, only the part related to the embodiment of the present application is shown.

[0096] Reference Figure 2 , the test device 2 based on traffic playback includes:

[0097] A first acquisition module, used to acquire first request data of an old service and first response data corresponding to the first request data;

[0098] A test module, used for sending second request data obtained by copying the first request data to the new service;

[0099] A second acquisition module, used to acquire second response data of the new service to the second request data;

[0100] The first determining module is used to determine a test result based on the first request data, the first response data and the second response data.

[0101] Optionally, the first acquisition module is specifically used for:

[0102] capturing at least one request data packet and at least one response data packet of the old service through a data packet capture interface within a preset time period;

[0103] Parsing the request data packet and the response data packet to obtain at least one request data and at least one response data;

[0104] The request data and the response data having the same identifier are determined as the first request data and the first response data.

[0105] Optionally, the first determining module may include:

[0106] A preprocessing unit, configured to merge and structure the first request data, the first response data, and the second response data to obtain basic data;

[0107] A determination unit is used to determine a test result based on basic data.

[0108] Optionally, the preprocessing unit is specifically used for:

[0109] Filling a preset data structure based on the first request data, the first response data, and the second response data to obtain merged data;

[0110] Standardize the fields of the merged data and add specified metadata to obtain the initial basic data;

[0111] The initial basic data is formatted based on the specified format to obtain the basic data.

[0112] Optionally, the determining unit is specifically configured to:

[0113] If the interface status code of the old service in the basic data is consistent with the interface status code of the new service; and / or if the business data name of the old service in the basic data is consistent with the business data name of the new service, the test result is determined to be qualified;

[0114] If the interface status code of the old service in the basic data is inconsistent with the interface status code of the new service; and / or if the business data name of the old service in the basic data is inconsistent with the business data name in the new service, the test result is determined to be unqualified.

[0115] Optionally, the testing device 2 may further include:

[0116] A verification module, configured to verify the first request data before determining the test result based on the basic data;

[0117] The determining unit determines a test result based on the basic data when the first request data is verified successfully.

[0118] Optionally, the testing device 2 may further include:

[0119] A search module is used to search the target basic data corresponding to the test result from the local log after determining that the test result is unqualified;

[0120] The second determination module is used to determine that the new service is not running if the data corresponding to the second response data in the target basic data is empty.

[0121] It should be noted that the information interaction and execution process between devices / units are based on the same concept as the method embodiment of the present application. Their specific functions and technical effects can be found in the method embodiment section and will not be repeated here.

[0122] Figure 3 This is a schematic diagram of the physical structure of an electronic device provided by an embodiment of the present application. Figure 3 As shown, the electronic device 3 of this embodiment includes: at least one processor 30 ( Figure 3 Only one processor is shown in the figure), a memory 31, and a traffic playback-based test plug-in 32 stored in the memory 31 and executable on at least one processor 30. When the processor 30 executes the test plug-in 32, any steps in the embodiment of the traffic playback-based test method are implemented, such as Figure 1 Steps 110-140 are shown.

[0123] The processor 30 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0124] In some embodiments, the memory 31 may be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. In other embodiments, the memory 31 may also be an external storage device of the electronic device 3, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the electronic device 3.

[0125] Furthermore, the memory 31 may also include both an internal storage unit of the electronic device 3 and an external storage device. The memory 31 is used to store operating devices, applications, boot loaders, data, and other programs, such as program codes of test plug-ins, etc. The memory 31 may also be used to temporarily store data that has been output or is to be output.

[0126] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of each functional unit and module is used as an example. In actual application, the function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit, and the integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of each functional unit and module are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0127] An embodiment of the present application further provides a test plug-in based on traffic playback, wherein the test plug-in based on traffic playback stores a computer program, and when the computer program is executed by a processor, the steps in each method embodiment can be implemented.

[0128] An embodiment of the present application provides a test plug-in based on traffic playback. When the computing test plug-in is run on an electronic device, the electronic device can implement the steps in various method embodiments when executing.

[0129] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable test plug-in. Based on this understanding, the present application implements all or part of the process in the embodiment method, which can be completed by instructing the relevant hardware through a computer program, and the test plug-in can be stored in a computer-readable storage medium, and the test plug-in can implement the steps of each method embodiment when executed by the processor. Among them, the computer program includes computer program code, and the test plug-in code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may at least include: any entity or device capable of carrying the test plug-in code to the camera device / electronic device, a recording medium, a computer memory, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), an electric carrier signal, a telecommunication signal, and a software distribution medium. For example, a USB flash drive, a mobile hard disk, a disk or an optical disk.

[0130] In the embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0131] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0132] In the embodiments provided in the present application, it should be understood that the disclosed devices / network equipment and methods can be implemented in other ways. For example, the device / network equipment embodiments described above are only schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0133] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0134] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A test method based on traffic playback, characterized in that: The test method is applied to a test plug-in for traffic playback installed on an electronic device corresponding to the old service, and the test method includes: Obtaining first request data of the old service and first response data corresponding to the first request data; Sending second request data obtained by copying the first request data to the new service; Obtain second response data of the new service for the second request data; A test result is determined based on the first request data, the first response data, and the second response data.

2. The testing method according to claim 1, characterized in that: The obtaining of the first request data of the old service and the first response data corresponding to the first request data includes: Within a preset time period, capturing at least one request data packet and at least one response data packet of the old service through a data packet capture interface; Parsing the request data packet and the response data packet to obtain at least one request data and at least one response data; The request data and the response data having the same identifier are determined as the first request data and the first response data.

3. The testing method according to claim 1, characterized in that: The determining a test result based on the first request data, the first response data, and the second response data includes: Merging and structuring the first request data, the first response data, and the second response data to obtain basic data; The test result is determined based on the basic data.

4. The testing method according to claim 3, characterized in that: The step of merging and structuring the first request data, the first response data, and the second response data to obtain basic data includes: Fill a preset data structure based on the first request data, the first response data, and the second response data to obtain merged data; Standardizing the fields of the merged data and adding specified metadata to obtain initial basic data; The initial basic data is formatted based on a specified format to obtain the basic data.

5. The testing method according to claim 3, characterized in that: The determining the test result based on the basic data comprises: If the interface status code of the old service in the basic data is consistent with the interface status code of the new service; and / or if the business data name of the old service in the basic data is consistent with the business data name in the new service, then the test result is determined to be qualified; If the interface status code of the old service in the basic data is inconsistent with the interface status code of the new service; and / or if the business data name of the old service in the basic data is inconsistent with the business data name in the new service, the test result is determined to be unqualified.

6. The testing method according to any one of claims 1 to 5, characterized in that: Before determining the test result based on the basic data, the method further includes: verifying the first request data; In the case where the first request data is verified successfully, the test result is determined based on the basic data.

7. The testing method according to claim 5, characterized in that: After determining that the test result is unqualified, the method further includes: Searching the local log for target basic data corresponding to the test result; If the data corresponding to the second response data in the target basic data is empty, it is determined that the new service is not running.

8. A test device based on traffic playback, characterized in that: A test plug-in for traffic playback installed on electronic devices corresponding to the old service, including: A first acquisition module, used to acquire first request data of the old service and first response data corresponding to the first request data; A test module, configured to send second request data obtained by copying the first request data to a new service; A second acquisition module, used to acquire second response data of the new service to the second request data; The first determining module is used to determine a test result based on the first request data, the first response data and the second response data.

9. An electronic device, comprising a memory, a processor, and a test plug-in with traffic playback stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the traffic playback-based testing method as described in any one of claims 1 to 7 is implemented.

10. A test plug-in based on traffic playback, characterized in that: When the test plug-in is executed by one or more processors, the traffic playback-based test method as described in any one of claims 1 to 7 is implemented.

Images