Test method, device and equipment

Abstract

The embodiment of the invention discloses a test method, device and equipment. According to the scheme, the method comprises the steps that after a test case used for testing a program for achieving a service link is obtained, a flow recording rule corresponding to the test case is obtained, the flow recording rule is used for representing a rule for recording flow data generated when the service link runs, and then the flow data are recorded according to the flow recording rule. Recording first traffic data generated when the test case is executed in the first environment and second traffic data generated when the test case is executed in the second environment; wherein a first version program for realizing a service link is deployed in the first environment, a second version program for realizing the service link is deployed in the second environment, and the generation time of the second version program is later than the generation time of the first version program; and finally, based on the first flow data and the second flow data, determining a test result of the second version program.

Description

Technical Field

[0001] The present application relates to the field of software testing technology, and in particular to a testing method, apparatus and equipment. Background Art

[0002] Testing is a process used to assess quality, comparing actual output with expected output. In software testing, new software versions often require test cases to verify their performance stability. A test case typically describes the testing tasks for a specific business scenario.

[0003] In a full-link testing scenario, a large number of upstream and downstream applications may be involved, with many relationships and complex systems. The fields involved in the entire link are usually tens of thousands. The existing method of manually writing test verification fields requires a lot of human resources, has a small verification scope, and has excessively high maintenance costs.

[0004] In view of this, it is necessary to provide a testing solution with low labor cost and wide verification range. Summary of the Invention

[0005] In view of this, embodiments of the present application provide a testing method, apparatus, and equipment to provide a testing solution with low labor cost and a wide calibration range.

[0006] To solve the above technical problems, the embodiments of this specification provide a testing method, including:

[0007] Obtain test cases for testing programs that implement business links;

[0008] Obtaining a traffic recording rule corresponding to the test case; the traffic recording rule is used to represent a rule for recording traffic data generated when the service link is running;

[0009] Recording, according to the traffic recording rule, first traffic data generated by executing the test case in a first environment; a first version of a program for implementing the service link is deployed in the first environment;

[0010] Recording, according to the traffic recording rule, second traffic data generated by executing the test case in a second environment; a second version of a program for implementing the service link is deployed in the second environment; and a generation time of the second version of the program is later than a generation time of the first version of the program;

[0011] A test result of the second version of the program is determined based on the first traffic data and the second traffic data.

[0012] The present invention also provides a testing device, including:

[0013] A first acquisition module is used to acquire a test case for testing a program that implements a business link;

[0014] A second acquisition module is used to obtain a traffic recording rule corresponding to the test case; the traffic recording rule is used to represent a rule for recording traffic data generated when the service link is running;

[0015] A first recording module is configured to record, according to the traffic recording rule, first traffic data generated by executing the test case in a first environment; a first version of a program for implementing the service link is deployed in the first environment;

[0016] A second recording module is configured to record, according to the traffic recording rule, second traffic data generated by executing the test case in a second environment; a second version of a program for implementing the service link is deployed in the second environment; and the second version of the program is generated later than the first version of the program.

[0017] A testing module is used to determine a test result of the second version program based on the first traffic data and the second traffic data.

[0018] The present invention also provides a test device, including:

[0019] at least one processor; and,

[0020] a memory communicatively connected to the at least one processor; wherein,

[0021] The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

[0022] Obtain test cases for testing programs that implement business links;

[0023] Obtaining a traffic recording rule corresponding to the test case; the traffic recording rule is used to represent a rule for recording traffic data generated when the service link is running;

[0024] Recording, according to the traffic recording rule, first traffic data generated by executing the test case in a first environment; a first version of a program for implementing the service link is deployed in the first environment;

[0025] Recording, according to the traffic recording rule, second traffic data generated by executing the test case in a second environment; a second version of a program for implementing the service link is deployed in the second environment; and a generation time of the second version of the program is later than a generation time of the first version of the program;

[0026] A test result of the second version of the program is determined based on the first traffic data and the second traffic data.

[0027] At least one embodiment provided in this specification can achieve the following beneficial effects:

[0028] In an embodiment of the present specification, after obtaining a test case for testing a program that implements a service link, a traffic recording rule corresponding to the test case can be further obtained, wherein the traffic recording rule represents a rule for recording traffic data generated during the operation of the service link. Furthermore, according to the traffic recording rule, first traffic data generated by executing the test case in a first environment and second traffic data generated by executing the test case in a second environment can be recorded. A first version of the program for implementing the service link is deployed in the first environment, and a second version of the program for implementing the service link is deployed in the second environment, where the second version of the program was generated later than the first version. Finally, based on the first traffic data and the second traffic data, a test result for the second version of the program is determined. Thus, when testing the second version of the program, which was generated later, there is no need to manually write verification fields one by one. Instead, the test result for the second version of the program is determined by comparing traffic data recorded in two environments corresponding to the two versions, thereby reducing human resource consumption and labor costs. Furthermore, by comparing data in multiple environments, all field data can be verified, breaking the limitations of manually selecting the verification range and effectively expanding the verification range. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0030] Figure 1 A schematic diagram of an application scenario of a testing method provided in an embodiment of this specification;

[0031] Figure 2 A flow chart of a testing method provided in an embodiment of this specification;

[0032] Figure 3 A schematic diagram of platform interaction for a testing method provided in an embodiment of this specification;

[0033] Figure 4A schematic diagram of data comparison in a test method provided in an embodiment of this specification;

[0034] Figure 5 A schematic diagram of a traffic recording rule setting interface in a test method provided in an embodiment of this specification;

[0035] Figure 6 A schematic diagram of a traffic ignore configuration page in a test method provided in an embodiment of this specification;

[0036] Figure 7 A swim lane diagram of a test method provided in an embodiment of this specification;

[0037] Figure 8 The embodiments of this specification provide corresponding Figure 2 A schematic structural diagram of a testing device;

[0038] Figure 9 The embodiments of this specification provide corresponding Figure 2 A structural diagram of a test device. DETAILED DESCRIPTION

[0039] The following description sets forth many specific details to facilitate a thorough understanding of the present application. However, the present application can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the scope of the present application. Therefore, the present application is not limited to the specific implementations disclosed below.

[0040] The terms used in one or more embodiments of the present application are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of the present application. The singular forms "a", "the" and "the" used in one or more embodiments of the present application and the appended claims are also intended to include plural forms, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in one or more embodiments of the present application refers to and includes any or all possible combinations of one or more associated listed items.

[0041] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of the present application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of one or more embodiments of the present application, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0042] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0043] In the related art, there are usually two ways to perform software testing and verification. The first is to manually write the verification points and verification rules that need to be verified. However, this method covers a small verification range, and it is difficult to manually write all the verification points. In addition, each verification point requires manual maintenance, which has high maintenance costs and wastes human resources. The second is to perform data analysis based on multiple traffic samples, generate a verification baseline, and use the verification baseline for verification. However, the generation of the verification baseline depends on multiple traffic samples, and the baseline needs to be maintained after each change, resulting in high generation and maintenance costs of the verification baseline; and the generation of the verification baseline depends on stable traffic data. If the traffic data continues to change, the baseline will be very noisy, and the user noise reduction cost will be high. The above two methods are also unable to verify fields that change frequently.

[0044] In order to solve the defects in the related art, this solution provides the following embodiments.

[0045] Figure 1 A schematic diagram of an application scenario of a testing method provided in an embodiment of this specification.

[0046] like Figure 1 As shown, after the test platform 101 obtains the test case for testing the program for implementing the business link, it can further obtain the traffic recording rules corresponding to the test case from the verification platform 102. Then, the test platform 101 can record the first traffic data generated by the execution of the test case in the first environment and the second traffic data generated by the execution in the second environment according to the traffic recording rules obtained from the verification platform 102; wherein, a first version of the program for implementing the business link is deployed in the first environment, and a second version of the program for implementing the business link is deployed in the second environment, and the generation time of the second version of the program is later than the generation time of the first version of the program.

[0047] After recording the first and second traffic data, the test platform 101 may store the first and second traffic data in the log management platform 103 and send verification task information for the test case to the verification platform 102. After receiving the verification task information, the verification platform 102 may retrieve the first and second traffic data from the log management platform 103 based on the verification task information, and compare the first and second traffic data to obtain a test result for the second version of the program.

[0048] The traffic recording rules at verification platform 102 may be generated by verification platform 102 in response to a user's rule configuration operation for a test case after receiving the rule configuration operation. In practical applications, a user may also directly configure rules for a test case at test platform 101, and test platform 101 may also generate traffic recording rules in response to the user's rule configuration operation. Specifically, the traffic recording rules may be generated locally by test platform 101 based on the user's rule configuration operation, or may be directly obtained from verification platform 102, without specific limitation.

[0049] In actual applications, the test cases used to test the programs that implement the business links can be written by the user at the test platform 101, or written by the user at the verification platform 102, or written by the user at other platforms, without specific limitation.

[0050] Specifically, the test platform 101, the verification platform 102 and the log management platform 103 can all be in hardware form, or can all be in software form, or can have some platforms in hardware form and some platforms in software form. Figure 1The server or server cluster shown. Specifically, the test platform 101, the verification platform 102 and the log management platform 103 can be an independent physical server, or a server cluster or distributed file system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (Content Delivery Network, CDN), and big data and artificial intelligence platforms. When the test platform 101, the verification platform 102 and the log management platform 103 are in the form of software, they can be installed in the servers or server clusters listed above. It can be implemented as multiple software or software modules (for example, software or software modules for providing distributed services), or it can be implemented as a single software or software module, which is not specifically limited.

[0051] In actual applications, data can be transmitted between the test platform 101 and the verification platform 102, between the test platform 101 and the log management platform 103, and between the verification platform 102 and the log management platform 103 through a local area network connection, a wide area network connection, an Internet connection, or other types of data network connections, or through other means, without specific limitation.

[0052] In addition, despite Figure 1 In at least some of the embodiments of this specification shown, the test method provided in the embodiments of this specification involves three platforms: a test platform 101, a verification platform 102, and a log management platform 103. However, in other optional embodiments, the functions of two of the platforms can be integrated into one platform, and the two platforms can be used to complete the overall test process. Alternatively, the functions of the three platforms, namely, the test platform 101, the verification platform 102, and the log management platform 103, can be integrated into one platform, so that the overall test process can be completed using one platform, which is more convenient.

[0053] Figure 1In the method, after obtaining a test case for testing a program that implements a service link, the test platform can further obtain a traffic recording rule corresponding to the test case, wherein the traffic recording rule represents a rule for recording traffic data generated during the operation of the service link. Furthermore, according to the traffic recording rule, first traffic data generated by executing the test case in a first environment and second traffic data generated by executing the test case in a second environment can be recorded. A first version of the program for implementing the service link is deployed in the first environment, and a second version of the program for implementing the service link is deployed in the second environment, and the second version of the program was generated later than the first version. Finally, based on the first traffic data and the second traffic data, the test result for the second version of the program is determined. Consequently, when testing the second version of the program, which was generated later, there is no need to manually write verification fields one by one. Instead, the test result for the second version of the program is determined by comparing traffic data recorded in two environments corresponding to the two versions, thereby reducing human resource consumption and labor costs. Furthermore, through the multi-environment data comparison, all field data can be verified, which overcomes the limitations of manually selecting the verification range and effectively expands the verification range.

[0054] Figure 2 This is a flow chart of a test method provided in an embodiment of this specification. From a hardware perspective, the execution subject of this process can be a platform server. From a program perspective, the execution subject of this process can be an application installed on the platform server. Figure 2 As shown, the process may include the following steps:

[0055] Step 202: Obtain a test case for testing a program that implements a service link.

[0056] In the examples of this specification, a business process chain (BPC) may refer to a complete collaborative network formed by connecting multiple related process links, resource nodes, and participating roles to achieve specific business goals. In practical applications, business processes may include, but are not limited to, payment processes, refund processes, fund purchase processes, fund redemption processes, fund conversion processes, insurance subscription processes, and insurance surrender processes.

[0057] In the embodiments of this specification, a test case may refer to a set of execution conditions, input data, operating steps and detailed description of expected results designed to verify a specific function or requirement. A test case is the smallest executable unit of a test and is used to determine whether the system or program under test works as expected. The expected result after the test case is executed is written in the test case. By comparing the actual result after the test case is executed by the program with the expected result, the program can be tested. Since the test case is used to test the program that implements the business link, it can be determined whether the program can normally implement the business link corresponding to the test case based on the comparison result between the test result and the expected result.

[0058] In actual applications, the test cases used to test the programs that implement business links can be written and configured by the user (test configuration personnel) at the test platform, or written and configured by the user at the verification platform, or written and configured by the user at other platforms, without specific limitation.

[0059] In actual applications, different business links can be tested using different test cases. It's also possible to write one or more test cases to test the same business link. For example, a user could write test case A to test the program that implements the payment link, and test case B to test the program that implements the refund link. Another example is a user could write two different test cases, test case C and test case D, to test the program for the fund purchase link from different angles.

[0060] Step 204: Obtain a traffic recording rule corresponding to the test case; the traffic recording rule is used to represent a rule for recording traffic data generated when the service link is running.

[0061] In the embodiments of this specification, traffic can refer to the sum of all input, output and internally processed data flows of the system during operation, which can be used to reflect the actual behavior and load status of the system. Specifically, traffic can be divided into the following types according to its technical form and flow direction: (1) External user traffic. For example: Hypertext Transfer Protocol (HTTP) request traffic, mobile application programming interface (API) call traffic, etc. (2) Internal service traffic. For example: Remote Procedure Call (RPC) traffic, microservice communication traffic, etc. (3) Message traffic. For example: producer message sending traffic, consumer message subscription traffic, etc. (4) Data layer traffic. For example: database operation traffic, file storage traffic, etc. (5) Asynchronous event traffic. For example: log reporting traffic, buried data traffic, scheduled task triggering traffic, etc. (6) Third-party traffic. For example: payment gateway call traffic, SMS service traffic, map application interface traffic, etc. In practical applications, the traffic types that need to be recorded in this application may mainly include remote procedure call (RPC) traffic, database operation traffic, and message traffic.

[0062] In the embodiments of this specification, traffic recording rules can be used to represent rules for recording traffic data generated during the operation of a service link. The traffic recording rules can specify which types of traffic to record, which traffic points to record, and which fields of traffic points to record during the operation of the service link. Among them, a traffic point can represent at least one data transmission point for the transmission of traffic data generated during the operation of the service link; a traffic field can represent the parameters used during the transmission of traffic data generated during the operation of the service link.

[0063] In actual applications, traffic recording rules can be traffic recording rules generated by the platform based on the user's rule configuration operations for test cases. When configuring traffic recording rules, users can specify traffic types to be ignored during recording or specify traffic types for traffic recording. They can also specify traffic points to be ignored during recording or specify traffic points to be recorded. They can also specify traffic fields to be ignored during recording or specify traffic fields to be recorded. Among them, specifying content to be recorded is the whitelist mode, and specifying content to be ignored during recording is the blacklist mode. The specific mode to be used needs to be set and adjusted according to actual needs and is not specifically limited.

[0064] In practice, the platform generates traffic recording rules based on user-configured rules for test cases. It then associates the test case ID with the corresponding traffic recording rule and stores it in a database. Therefore, when retrieving the traffic recording rule corresponding to a test case, the platform can search and retrieve the corresponding traffic recording rule from the database based on the test case ID.

[0065] Step 206: Record first traffic data generated by executing the test case in a first environment according to the traffic recording rule; a first version of a program for implementing the business link is deployed in the first environment.

[0066] In the embodiments of this specification, traffic recording refers to the process of capturing, storing, and analyzing data from interactions between systems or between users and systems. It is primarily used in areas such as testing, monitoring, security auditing, and troubleshooting. The core goal of traffic recording is to realistically recreate business scenarios for subsequent playback, stress testing, or analysis. Traffic recording allows for the cost-effective creation of realistic testing environments, which improves system stability and security.

[0067] In practical applications, traffic recording and playback technology can be used for traffic recording and playback analysis. Traffic recording and playback technology can quickly record interface traffic generated during application execution according to specific filtering rules. The recording includes interface request and response messages. Messages stored during the recording process can be replayed at any time in a specified environment. Traffic recording and playback scenarios can be applied during software functional testing for regression verification and during software version verification for automated transaction regression. Traffic recording and playback technology is crucial for simplifying test case development, improving test efficiency, and enhancing test scenario coverage. In actual implementation, other technologies can also be used to record traffic, and this is not a specific limitation.

[0068] In the embodiments of this specification, a first version of a program for implementing a service chain is deployed in the first environment. This first version of the program may correspond to a stable version of the program capable of stably operating the service chain. Consequently, when test cases related to the service chain are executed in the first environment, the results generally match the expected results.

[0069] Step 208: According to the traffic recording rules, record the second traffic data generated by the execution of the test case in the second environment; a second version program for implementing the business link is deployed in the second environment; the generation time of the second version program is later than the generation time of the first version program.

[0070] In the embodiments of this specification, a second version of a program for implementing a service chain is deployed in the second environment. The second version of the program is generated later than the first version. The first version of the program can be considered the main program that is currently running stably after testing, while the second version of the program can be considered the updated version to be tested. Because at least part of the program code in the second version of the program has been modified, the second version of the program needs to be tested.

[0071] In actual applications, during the execution of test cases used to test programs that implement business links, the test platform can record the first traffic data generated by the execution of the test case in the first environment and the second traffic data generated by the execution of the test case in the second environment according to the traffic recording rules, and store the recorded results in the log management platform or database, so that the first traffic data and the second traffic data can be extracted from the log management platform or database for comparison and analysis later.

[0072] Step 210: Determine a test result of the second version of the program based on the first traffic data and the second traffic data.

[0073] In practical applications, the test result of the second version of the program can be determined based on the comparison results of the first and second traffic data. If there is no difference between the first and second traffic data, or if the difference is determined by the user to be negligible, then the test of the second version of the program can be determined to have passed. If there is a difference between the first and second traffic data that the user has determined cannot be ignored, then the test of the second version of the program can be determined to have failed.

[0074] In actual applications, users can set the traffic points or traffic fields that can be ignored in advance on the platform, or the platform can display the traffic points or traffic fields with differences to the user after comparing the first traffic data and the second traffic data, and then the user can further configure the traffic points or traffic fields that can be ignored. There is no specific limitation on this.

[0075] Figure 2In the method, after obtaining a test case for testing a program that implements a business link, the platform can further obtain a traffic recording rule corresponding to the test case, wherein the traffic recording rule represents a rule for recording traffic data generated during the operation of the business link. Furthermore, according to the traffic recording rule, first traffic data generated by executing the test case in a first environment and second traffic data generated by executing the test case in a second environment can be recorded. A first version of the program for implementing the business link is deployed in the first environment, and a second version of the program for implementing the business link is deployed in the second environment, and the second version of the program was generated later than the first version. Finally, based on the first traffic data and the second traffic data, the test result for the second version of the program is determined. Thus, when testing the second version of the program, which was generated later, there is no need to manually write verification fields one by one. Instead, the test result for the second version of the program is determined by comparing traffic data recorded in two environments corresponding to the two versions, which helps reduce human resource consumption and labor costs. Furthermore, through the multi-environment data comparison, all field data can be verified, which overcomes the limitations of manually selecting the verification range and effectively expands the verification range.

[0076] based on Figure 2 The method in this specification also provides some specific implementation plans of the method, which are described below.

[0077] Optional, Figure 2 The method in the test method can be applied to a test platform; after recording the first traffic data generated by executing the test case in the first environment according to the traffic recording rule, the method can also include:

[0078] Associating the first traffic data with the use case identifier of the test case and a first execution identifier for identifying the first traffic data and storing the resultant data in a log management platform;

[0079] Correspondingly, after recording the second traffic data generated by executing the test case in the second environment according to the traffic recording rule, the method may further include:

[0080] Associating the second traffic data with the use case identifier of the test case and a second execution identifier for identifying the second traffic data and storing the resultant data in the log management platform;

[0081] Correspondingly, determining the test result of the second version of the program based on the first traffic data and the second traffic data may specifically include:

[0082] Sending verification task information for the test case to the verification platform; the verification task information carries the case identifier, the first execution identifier, and the second execution identifier; the traffic recording rule is configured by the user in the verification platform;

[0083] The verification platform retrieves the first traffic data from the log management platform according to the use case identifier and the first execution identifier;

[0084] Retrieving the second traffic data from the log management platform according to the use case identifier and the second execution identifier;

[0085] The second traffic data is compared with the first traffic data to obtain a test result corresponding to the traffic recording rule.

[0086] In the embodiments of this specification, a test case may correspond to a use case identifier for uniquely identifying the test case. The specific use case identifier may be the ID number of the use case or other identification forms, and there is no specific limitation on this. Each time a test case is executed, there will be a corresponding unique execution identifier. When the same test case is executed in different environments, the execution identifier is also different. Thus, when the test case is executed in the first environment, it corresponds to the first execution identifier, generating first traffic data. The first execution identifier has an associated relationship with the first traffic data, and the first execution identifier can be used to identify the first traffic data; when the test case is executed in the second environment, it corresponds to the second execution identifier, generating second traffic data. The second execution identifier has an associated relationship with the second traffic data, and the second execution identifier can be used to identify the second traffic data.

[0087] In the embodiments of this specification, a log management platform may refer to an integrated tool for centrally collecting, storing, analyzing, and visualizing system or application logs, designed to help operations, development, and business teams quickly locate problems, monitor system status, and meet audit requirements. This application utilizes the data storage capabilities of the log management platform to reduce database operational pressure.

[0088] In actual applications, after the test platform records the first flow data and the second flow data, it can associate the first flow data with the use case identifier of the test case and the first execution identifier for identifying the first flow data and then store it on the log management platform, and associate the second flow data with the use case identifier of the test case and the second execution identifier for identifying the second flow data and then store it on the log management platform. When the verification platform needs to obtain the first flow data and the second flow data for data comparison, it can retrieve the first flow data and the second flow data from the log management platform based on the use case identifier and the execution identifier.

[0089] In actual applications, after the test platform records the first and second flow data, it can also first store the data in the log management platform. Later, when there is a verification task, the verification platform can retrieve the data from the log management platform and store it in the database. In actual applications, since data is continuously generated during the execution of test cases, and when the amount of data generated is large, considering that the high frequency of database data updates may cause huge pressure on the database, the data can be temporarily stored in the log management platform first. When there is a verification task, the first and second flow data in the log management platform can be stored in the database, which helps to reduce the pressure on the database.

[0090] In actual applications, after the test platform records the first flow data and the second flow data, it can immediately send the verification task information for the test case to the verification platform, or it can send the verification task information for the test case to the verification platform after a preset time period, or it can send the verification task information for the test case to the verification platform in response to the user's operation. The specific trigger mechanism can be set and adjusted according to actual needs, and there is no specific limitation on this.

[0091] In an embodiment of this specification, the verification task information sent by the testing platform to the verification platform may include a test case identifier, a first execution identifier for identifying the first flow data, and a second execution identifier for identifying the second flow data. Thus, upon receiving the verification task information, the verification platform can retrieve the first flow data from the log management platform based on the test case identifier and the first execution identifier, and retrieve the second flow data from the log management platform based on the test case identifier and the second execution identifier.

[0092] In actual applications, after obtaining the first and second traffic data, the verification platform can compare each traffic point in the two types of traffic data, as well as the traffic fields recorded at each traffic point, and display the comparison results to the user. If there are no discrepancies between the first and second traffic data, or if the discrepancies exist and are determined by the user to be negligible, the test of the second version of the program can be determined to have passed. If there are discrepancies between the first and second traffic data and are determined by the user to be non-negligible, the test of the second version of the program can be determined to have failed.

[0093] Figure 3 This is a platform interaction diagram of a test method provided in the embodiment of this specification. Figure 3As shown, both the first environment and the second environment in the test platform include a traffic recording center. The traffic recording center can intercept and record the traffic generated by the test case in the first environment in a targeted manner based on the traffic recording rules set by the user to obtain the first traffic data; and intercept and record the traffic generated by the test case in the second environment in a targeted manner to obtain the second traffic data. The test platform can store the first traffic data and the second traffic data in the log management platform, and send the verification task information to the verification platform. After receiving the verification task information, the verification platform can retrieve the first traffic data and the second traffic data from the log management platform based on the verification task information. After the verification platform obtains the first traffic data and the second traffic data, it can perform data comparison and display the comparison results to the user. The verification platform also includes a rule management center. Users can configure traffic recording rules at the rule management center, and can also configure traffic points and traffic fields that need to be ignored during verification at the rule management center.

[0094] In real-world applications, a single test case often calls numerous applications during execution. In practice, it's usually not necessary to record traffic for all applications. Instead, you can set traffic recording rules for the applications of interest and then record traffic. This allows for more targeted traffic recording, improving recording efficiency and, in turn, verification efficiency based on the recorded traffic.

[0095] Based on this, Figure 2 In the method, the traffic recording rule may include an application identifier of a target application that is called when executing the test case and requires traffic recording.

[0096] In the embodiments of this specification, the application identifier of the target application may be the ID of the target application, the application code of the target application, or other identification information that can uniquely identify the target application, which is not specifically limited.

[0097] In the examples of this specification, an application is a complete, independently deployable software system or service module, typically comprising multiple functional components (such as a front-end, back-end, and database) to achieve specific business objectives. For example, the fund trading core system (fundtranscore) is a back-end application responsible for handling business logic such as fund subscriptions and redemptions. Each application can correspond to a specific business domain (such as fund trading, order management, etc.) and can be deployed and run independently.

[0098] In practice, a traffic recording rule is used to test a target application within a test case. The target application is the application that needs to be called within the service chain corresponding to the test case and is also the application that needs to be called when the test case is executed. For a given test case, n applications can be tested, requiring n corresponding traffic recording rules. Each traffic recording rule can specify the traffic type, traffic point information, and traffic field information to be recorded for the current application.

[0099] Optional, Figure 2 In the method, the traffic recording rule may further include traffic recording range information for the target application; the traffic recording range information is determined based on at least one of a traffic type, a traffic point, or a traffic field;

[0100] The traffic type includes at least one of an RPC call type, a database operation type, and a message type;

[0101] The traffic point represents at least one data transmission point for performing data transmission with the target application;

[0102] The traffic field indicates parameters used when performing data transmission with the target application.

[0103] In the embodiments of this specification, RPC (Remote Procedure Call) call types can include RPC_IN and RPC_OUT. RPC_IN represents an incoming request, which is the traffic from an upstream application calling an interface provided by the current application; RPC_OUT represents an outgoing request, which is the traffic from the current application calling an interface provided by a downstream application. When setting the traffic recording range, users can set the RPC_IN traffic to be ignored or the RPC_OUT traffic to be ignored based on actual needs, so as to focus on analyzing the traffic type of interest and ignore noise traffic. Both RPC_IN and RPC_OUT can include input parameters REQ (Request) and output parameters RES (Response). When performing data comparison, data comparison can usually be performed by comparing the input parameters REQ (Request) and the output parameters RES (Response), wherein the input parameter REQ refers to the parameter set passed by the client when sending a request to the server. In the scenario of the embodiment of the present application, for example, it can be the input parameter carried in the traffic of the upstream application calling the interface provided by the present application, or it can be the input parameter carried in the traffic of the present application calling the interface provided by the downstream application; and the output parameter RES refers to the result data returned to the client after the server processes the request. In the scenario of the embodiment of the present application, for example, it can be the output parameter carried in the traffic returned by the present application in response to the call of the upstream application, or it can be the output parameter carried in the traffic returned by the downstream application in response to the call of the present application. For example: when setting the traffic recording range information, the user sets it to ignore RPC_OUT traffic, that is, only focus on the RPC_IN traffic of the upstream application calling the interface provided by this application; after executing the test case and obtaining the first traffic data generated by the execution of the test case in the first environment and the second traffic data generated by the execution of the test case in the second environment, when comparing the first traffic data and the second traffic data, you can compare them separately based on the traffic type. When comparing the traffic of the RPC call type, you can compare whether the RPC_REQ in the RPC_IN traffic in the recorded first traffic data is consistent with the RPC_REQ in the corresponding RPC_IN traffic in the second traffic data, and compare whether the RPC_RES in the RPC_IN traffic in the recorded first traffic data is consistent with the RPC_RES in the corresponding RPC_IN traffic in the second traffic data.

[0104] In the embodiments of this specification, the message (MSG) type may include MSG_IN and MSG_OUT, where MSG_IN represents the traffic of messages received by this application from other applications; MSG_OUT represents the traffic of messages sent by this application to other applications. When setting the traffic recording range information, the user can set the traffic for MSG_IN and the traffic for MSG_OUT to be ignored according to actual needs, so as to focus on analyzing the traffic type of interest and ignore the noise traffic. MSG_IN and MSG_OUT include the input parameter REQ but not the output parameter, so that when performing data comparison, data comparison can usually be performed by comparing the input parameter REQ (Request). For example, when setting the traffic recording range information, the user sets it to ignore MSG_OUT traffic, that is, only focusing on the traffic of messages received by this application from other applications; after executing the test case and obtaining the first traffic data generated by the execution of the test case in the first environment and the second traffic data generated by the execution of the test case in the second environment, when comparing the first traffic data and the second traffic data, you can compare them separately based on the traffic type. When comparing the traffic of the message type, you can compare whether the MSG_REQ in the MSG_IN traffic in the recorded first traffic data is consistent with the MSG_REQ in the corresponding MSG_IN traffic in the second traffic data.

[0105] In the embodiments of this specification, database (Database, DB) operation types may include DB_INSERT and DB_UPDATE, wherein DB_INSERT represents a database insert request, which is used to add new data records to a database table; DB_UPDATE represents a database update request, which is used to modify existing records in a database table. When setting the traffic recording range information, the user can set the traffic for DB_INSERT and the traffic for DB_UPDATE to be ignored according to actual needs, so as to focus on analyzing the traffic type of interest and ignore noise traffic. DB_INSERT and DB_UPDATE include input parameters REQ but do not include output parameters, so that when performing data comparison, data comparison can usually be performed by comparing the input parameters REQ (Request). For example: when setting the traffic recording range information, the user sets it to ignore DB_UPDATE traffic, that is, only focus on the DB_INSERT traffic of newly added data in the database; after executing the test case, obtaining the first traffic data generated by the execution of the test case in the first environment and the second traffic data generated by the execution of the test case in the second environment, when comparing the first traffic data and the second traffic data, you can compare them separately based on the traffic type. When comparing the traffic of the database operation type, you can compare whether the DB_REQ in the DB_INSERT traffic in the recorded first traffic data is consistent with the DB_REQ in the corresponding DB_INSERT traffic in the second traffic data.

[0106] Figure 4 This is a data comparison diagram for a test method provided in the embodiment of this specification. Figure 4 As shown, Environment A can represent the first environment for executing the test case, which generates first traffic data after executing the test case; Environment B can represent the second environment for executing the test case, which generates second traffic data after executing the test case; when comparing the first traffic data and the second traffic data, the four traffic data sets of RPC_REQ A and RPC_REQ B, RPC_RES A and RPC_RES B, MSG_REQ A and MSG_REQ B, and DB_REQ A and DB_REQ B can be compared separately. Among them, A represents data in the first traffic data, and B represents data in the second traffic data. The meanings of other parameters have been explained in detail above and will not be repeated here.

[0107] In the embodiments of this specification, a traffic point may represent at least one data transmission point for data transmission with a target application. Specifically, a data transmission point may refer to a unified data transmission endpoint. In a distributed system, a unified data transmission endpoint is a logical or physical interface in the system for receiving, sending or persisting data, including the following forms: 1. Call endpoint, used for synchronous data interaction based on a service interface, such as an RPC call endpoint. 2. Message endpoint, used for asynchronous data transmission based on a message protocol, such as a production endpoint and a consumption endpoint of a message queue. 3. Storage endpoint, used for reading and writing data based on storage, such as a database write endpoint.

[0108] An interface is a functional contract within an application or between applications that defines how to interact with a service or component (e.g., method name, parameters, return value, etc.). For example, FinRedeemiFacade is an interface provided by the fundtranscore application for handling fund redemption operations. Applications provide external services through interfaces, and interfaces depend on the actual implementation of the application. An interface is a subset of the functionality provided by an application to the outside world. For example, fundtranscore (application) contains FinRedeemiFacade (interface), which defines confirm (method). An application can provide multiple interfaces (e.g., payment interface, reconciliation interface, etc.).

[0109] In actual applications, for a test case, there may be a large number of traffic points that transmit data with the target application. When setting traffic recording rules, users can choose to ignore traffic points of no interest (blacklist mechanism) based on actual needs, or they can choose to set traffic points that need to be recorded (whitelist mechanism). There is no specific restriction on this.

[0110] In actual applications, users can also choose to ignore unimportant traffic fields when setting traffic recording rules according to actual needs. This avoids recording unimportant traffic fields during the traffic recording process, which may cause a large amount of noise data. This is beneficial to improving traffic recording efficiency and subsequent verification efficiency.

[0111] Based on this, the traffic recording range information is used to indicate the traffic range that needs to be ignored during configuration.

[0112] In practice, the traffic recording scope can include any range excluding at least one of the specified traffic types, traffic points, or traffic fields. By default, all traffic points and fields for RPC calls, database operations, and message traffic are recorded. During configuration, users can configure which traffic types, traffic points, and traffic fields to ignore for improved efficiency.

[0113] Figure 5 This is a schematic diagram of the traffic recording rule setting interface in a test method provided in an embodiment of this specification. Figure 5 As shown, the traffic recording rule setting interface includes configuration content related to the test case, configuration content related to the target application, and configuration content related to the traffic recording range information.

[0114] The configuration content related to the test case includes the use case type, use case ID, use case name and use case environment, wherein the use case environment refers to whether the test case is in the first environment or the second environment when it is executed.

[0115] The configuration content related to the target application includes the target application and application general configuration. After the user clicks the corresponding control of the application general configuration, they can enter the application general configuration interface. In the application general configuration interface, they can make general configurations for traffic types, traffic points, and traffic fields. After the configuration is completed, it can be applied to all test cases that use the target application, eliminating the need to configure them one by one, which helps improve the convenience and efficiency of configuration.

[0116] Traffic recording range configurations include traffic type, traffic point, and traffic field configurations. Users can configure traffic types to be ignored in the traffic type configuration (the figure includes six types: RPC_IN, RPC_OUT, MSG_IN, MSG_OUT, DB_INSERT, and DB_UPDATE). Users can configure traffic points to be ignored in the traffic point configuration (blacklist mechanism), or they can configure traffic points of interest (traffic points for which traffic collection is required) (whitelist mechanism). Users can configure traffic fields to be ignored in the traffic field configuration to avoid recording irrelevant noise traffic, which helps improve traffic recording and verification efficiency.

[0117] Optional, Figure 2 The method in the embodiment of the present invention, wherein the test result may include verification failure information for the target application; the verification failure information is used to indicate that the second flow data is inconsistent with the first flow data;

[0118] Correspondingly, Figure 2The method, step 210: after determining the test result of the second version program based on the first traffic data and the second traffic data, may further include:

[0119] Displaying the verification failure information and an information processing control corresponding to the verification failure information to the user;

[0120] In response to a user's control operation on the information processing control, the traffic recording rule is updated; the control operation is used to indicate that the data traffic corresponding to the verification failure information is ignored.

[0121] In the embodiments of this specification, after comparing the first and second traffic data, any inconsistencies between the two traffic data can be displayed in the test results as verification failure information. The platform can display these verification failure messages and the corresponding information processing controls to the user. Each verification failure message can correspond to one or more information processing controls.

[0122] In actual applications, in response to a user trigger, a traffic ignore configuration page for ignoring the data traffic corresponding to the verification failure information can be displayed. In the traffic ignore configuration page, one or more information processing controls corresponding to the verification failure information can be displayed. By operating different information processing controls, the user can configure the traffic to be ignored based on the application dimension, the rule dimension, or the traffic point and traffic field perspectives. Since the subsequent embodiments of this specification will explain in detail the content of configuration based on application, rule, traffic point, and traffic field, they will not be repeated here.

[0123] In practice, when configuring traffic to be ignored on the Traffic Ignore configuration page, users can choose to temporarily ignore that traffic. This temporary ignore setting means that the difference between the first and second traffic data will be ignored during the current verification comparison, while the difference will continue to be compared during subsequent verifications. Alternatively, the full ignore setting means that the difference between the first and second traffic data will be ignored for both the current and subsequent verification comparisons. This allows users to flexibly adjust settings based on their actual needs, helping to reduce verification noise and improve verification efficiency. For example, if a user sets the ignore setting on the Traffic Ignore configuration page for traffic corresponding to a verification failure message, subsequent tests will not record that portion of traffic, improving the efficiency of traffic recording and verification. Another example is if a user sets the temporary ignore setting on the Traffic Ignore configuration page for traffic corresponding to a verification failure message, the difference will be ignored during the current verification, while the difference will still need to be recorded and verified in subsequent tests.

[0124] Optionally, the information processing control may include a rule dimension control; and updating the traffic recording rule in response to a user's control operation on the information processing control may specifically include:

[0125] In response to a user's control operation on the rule dimension control, a target recording rule for the target application in the traffic recording rule is modified to ignore data traffic corresponding to the verification failure information.

[0126] In the embodiments of this specification, a rule dimension control may be a general term for a group of controls, specifically including a field ignore control and a traffic point ignore control. User control operations on a rule dimension control may include, but are not limited to, selecting a field ignore control belonging to a rule dimension control, selecting a traffic point ignore control belonging to a rule dimension control, and the like. Field ignore controls may also include temporary field ignore controls and long-term field ignore controls, and traffic point ignore controls may also include temporary traffic point ignore controls and long-term traffic point ignore controls.

[0127] In practice, users can ignore traffic points or traffic fields that need to be ignored for a rule by controlling the rule dimension controls. For example, if a user selects the Ignore Traffic Points control within a rule dimension control, the user can ignore traffic points corresponding to verification failures under that rule. Another example is if a user selects the Ignore Fields control within a rule dimension control, the user can ignore traffic fields corresponding to verification failures under that rule during this verification.

[0128] In actual applications, the target recording rule can be a rule for the target application within the traffic recording rules corresponding to the current test case. In response to a user's control operation on the rule dimension control on the traffic ignore configuration page, the target recording rule can be modified to ignore the data traffic corresponding to the verification failure information. Specifically, this can be temporarily or permanently ignored, and can be ignored at the traffic point granularity or the field granularity. This can be set and adjusted based on actual needs and is not specifically limited to this.

[0129] Optionally, the information processing control may further include an application dimension control; and updating the traffic recording rule in response to a user's control operation on the information processing control may specifically include:

[0130] In response to the user's control operation on the application dimension control, at least one traffic recording rule corresponding to the target application is modified to ignore the data traffic corresponding to the verification failure information; different rules in the at least one traffic recording rule correspond to different test cases.

[0131] In the embodiments of this specification, an application dimension control may be a general term for a group of controls, specifically including a field ignore control and a traffic point ignore control. User control operations on application dimension controls may include, but are not limited to, selecting a field ignore control belonging to an application dimension control, selecting a traffic point ignore control belonging to an application dimension control, and the like.

[0132] In actual applications, users can complete the ignore settings for traffic points or traffic fields that need to be ignored for the traffic recording rules corresponding to this application by controlling the application dimension controls. For example: after the user selects the ignore control for traffic points belonging to the application dimension control, the traffic points corresponding to the verification failure information in one or more traffic recording rules corresponding to the application can be ignored. For another example: after the user selects the ignore control for fields belonging to the application dimension control, the traffic fields corresponding to the verification failure information in one or more traffic recording rules corresponding to the application can be ignored.

[0133] In an embodiment of the present specification, at least one traffic recording rule corresponding to the target application may include a target recording rule. The target recording rule is a traffic recording rule for the current test case and records the traffic of the target application. In actual applications, the target application may correspond to multiple traffic recording rules. Since one target application and one test case correspond to one traffic recording rule, when the target application corresponds to multiple traffic recording rules, the test cases corresponding to each traffic recording rule are different. Thus, the user can achieve unified configuration of multiple test cases corresponding to the target application and multiple traffic recording rules corresponding to the target application through control operations on the application dimension controls, without having to perform multiple identical configuration operations on the target application in different traffic recording rules, which is conducive to reducing user operations and improving configuration efficiency.

[0134] Optionally, the verification failure information may include a failed traffic point where verification failed; the information processing control may include a traffic point ignore control; and updating the traffic recording rule in response to a user's control operation on the information processing control may specifically include:

[0135] In response to the user's control operation on the traffic point ignore control, the specified recording rule is modified to ignore the data traffic corresponding to the specified traffic point that generates the verification failure information; wherein, the specified recording rule includes the target recording rule for the target application in the traffic recording rule, or at least one traffic recording rule corresponding to the target application; different rules in the at least one traffic recording rule correspond to different test cases.

[0136] In actual applications, traffic point ignore controls can include traffic point long-term ignore controls and traffic point temporary ignore controls. After the user triggers the traffic point long-term ignore control, the data traffic corresponding to the specified traffic point can be ignored for a long time in the application dimension or rule dimension; after the user triggers the traffic point temporary ignore control, the data traffic corresponding to the specified traffic point can be temporarily ignored in the application dimension or rule dimension. Temporary ignore can mean ignore during this verification, and not ignore in other test verifications; long-term ignore is the opposite of temporary ignore, and can mean not limited to ignore during this verification, but also ignore in other test verifications.

[0137] In actual applications, if the user configures to ignore traffic points in the application dimension, the designated recording rule can be at least one traffic recording rule corresponding to the target application; different rules in the at least one traffic recording rule correspond to different test cases. Accordingly, if the user configures to ignore traffic points in the rule dimension, the designated recording rule can be the target recording rule for the target application in the traffic recording rule corresponding to the current test case.

[0138] In actual applications, for traffic points that are not of concern, such as traffic points related to tool heartbeat detection and traffic points used to record time, users can ignore the specified traffic points by controlling the traffic point ignore controls. This helps reduce the amount of data for traffic recording and traffic verification, and improves test efficiency.

[0139] Optionally, the verification failure information may include a failed traffic field for the verification failure; the information processing control may include a field ignore control; and updating the traffic recording rule in response to a user's control operation on the information processing control may specifically include:

[0140] In response to the user's control operation on the field ignore control, the specified recording rule is modified to ignore the data traffic corresponding to the specified traffic field that generates the verification failure information; wherein, the specified recording rule includes the target recording rule for the target application in the traffic recording rule, or at least one traffic recording rule corresponding to the target application; different rules in the at least one traffic recording rule correspond to different test cases.

[0141] In actual applications, field ignore controls can include long-term ignore controls for traffic fields and temporary ignore controls for traffic fields. After the user triggers the long-term ignore control for traffic fields, the data traffic corresponding to the specified traffic field can be ignored for a long time in the application dimension or rule dimension; after the user triggers the temporary ignore control for traffic fields, the data traffic corresponding to the specified traffic point can be temporarily ignored in the application dimension or rule dimension.

[0142] In actual applications, if the user configures the traffic field to be ignored in the application dimension, the designated recording rule can be at least one traffic recording rule corresponding to the target application; different rules in the at least one traffic recording rule correspond to different test cases. Accordingly, if the user configures the traffic field to be ignored in the rule dimension, the designated recording rule can be the target recording rule for the target application in the traffic recording rule corresponding to the current test case.

[0143] In actual applications, for traffic fields that are not of interest, such as the order number field, time point field, and random number field, users can configure the field to be ignored by controlling the field ignore control. This helps reduce the amount of data required for traffic recording and traffic verification, and improves test efficiency.

[0144] In practical applications, the information processing control may include a temporary control; after displaying the verification failure information and the information processing control corresponding to the verification failure information to the user, the following may also be included:

[0145] In response to the user's control operation on the temporary control, the verification failure information is not presented in the test report for the second version of the program.

[0146] In the embodiments of this specification, the above-mentioned traffic field temporary ignoring control and traffic point temporary ignoring control may both be temporary controls. After the user performs control operations on these temporary controls, the verification failure information corresponding to the traffic point or traffic field selected by the user may not be presented in the test report for the second version of the program, so as to reduce information that the user does not pay attention to, reduce the impact of noise, and help improve verification efficiency.

[0147] Figure 6 This is a schematic diagram of a flow ignoring configuration page in a test method provided in an embodiment of this specification. Figure 6 As shown, all controls on this traffic ignore configuration page belong to information processing controls. The eight information processing controls shown in the figure can be divided into application- and rule-dimensional controls based on the business dimension, and into field ignore controls and traffic point ignore controls based on granularity. Field ignore controls include "Temporarily ignore this field" and "Ignore this field." "Temporarily ignore this field" corresponds to the temporary ignore control for traffic fields described above; "Ignore this field" corresponds to the long-term ignore control for traffic fields described above. Traffic point ignore controls include "Temporarily ignore this traffic" and "Ignore this traffic." "Temporarily ignore this traffic" corresponds to the temporary ignore control for traffic points described above; "Ignore this traffic" corresponds to the long-term ignore control for traffic points described above. The four information processing controls shown in the first row of the figure belong to the application-dimensional controls, while the four shown in the second row belong to the rule-dimensional controls. For example, the "Ignore this field" control in the first row of the figure belongs to the field ignore control in terms of granularity and to the application-dimensional control in terms of business dimension.

[0148] In actual applications, the first flow data and the second flow data can be compared to determine whether the first flow data and the second flow data meet the preset target conditions. If so, the verification passes; otherwise, the verification fails.

[0149] Based on this, Figure 2 In the method, step 210: determining a test result of the second version of the program based on the first traffic data and the second traffic data may specifically include:

[0150] determining whether the first flow data and the second flow data meet a target condition, and obtaining a determination result; wherein the target condition includes at least one of a first determination condition, a second determination condition, and a third determination condition;

[0151] The first judgment condition is that the target flow point included in the first of the first flow data and the second flow data exists in the second of the first flow data and the second flow data; the second judgment condition is that the first target field included in the first of the first flow data and the second flow data exists in the second of the first flow data and the second flow data; the third judgment condition is that the second data value corresponding to the second target field included in the second flow data is the same as the first data value corresponding to the second target field included in the first flow data;

[0152] If the judgment result is no, the second version program fails the verification.

[0153] In the embodiments of this specification, the first judgment condition may refer to the correspondence between the traffic point in the first traffic data and the traffic point in the second traffic data. The second judgment condition may refer to the correspondence between the traffic field in the first traffic data and the traffic field in the second traffic data. The third judgment condition may refer to the consistency between the value corresponding to the traffic field in the first traffic data and the value corresponding to the same traffic field in the second traffic data. Generally, the first judgment condition, the second judgment condition and the third judgment condition can be combined into a target condition, or two of the three judgment conditions can be combined to obtain the target condition, or one of the three judgment conditions can be used as the target condition, and there is no specific limitation on this.

[0154] In actual applications, the following situations may occur when the second version of the program fails to pass the verification: (1) There are traffic points in the second traffic data that are not in the first traffic data. This may be because new services or new functions are added when the second version of the program is updated. In this case, it can be manually confirmed whether it is caused by the newly added services or functions, and the traffic ignore setting can be performed based on the confirmation result. (2) There are traffic points in the first traffic data that are not in the second traffic data. This may be because old services or old functions are deleted when the second version of the program is updated. In this case, it can be manually confirmed whether it is caused by the deleted services or functions, and the traffic ignore setting can be performed based on the confirmation result. (3) There are traffic fields in the second traffic data that are not in the first traffic data. In this case, it can be manually confirmed whether it is a field that is expected to be added during version iteration, and the traffic ignore setting can be performed based on the confirmation result. (4) There are traffic fields in the first traffic data that are not in the second traffic data. In this case, it can be manually confirmed whether it is a field that is expected to be deleted during version iteration, and the traffic ignore setting can be performed based on the confirmation result. (5) The same field in the first traffic data and the second traffic data has different corresponding data values. In this case, you can manually confirm whether the field value is expected to be changed during version iteration, and set traffic ignore based on the confirmation result.

[0155] Optionally, before obtaining the traffic recording rule corresponding to the test case, the following method may be further included:

[0156] receiving a rule configuration operation from a user for the test case;

[0157] In response to the rule configuration operation, the traffic recording rule is generated.

[0158] In actual applications, users can perform rule configuration operations for test cases in the traffic recording rule setting interface provided by the platform. Specifically, it can include configuration content related to test cases, configuration content related to target applications, and configuration content related to traffic recording range information. Among them, the configuration content related to test cases includes the use case type, use case ID, use case name, and use case environment, among others. The use case environment refers to whether the test case is in the first environment or the second environment when it is executed. The configuration content related to the target application includes the target application. The user can enter the application ID of the target application and other application identifiers to specify the target application. The configuration content related to traffic recording range information can include traffic type configuration, traffic point configuration, and traffic field configuration. The user can configure the traffic type to be ignored in the traffic type configuration. The user can configure the traffic points to be ignored in the traffic point configuration (blacklist mechanism), or can also configure the traffic points of interest (traffic points that need to be collected) (whitelist mechanism). The user can configure the traffic fields to be ignored in the traffic field configuration to avoid recording noise traffic that is not of concern, which is conducive to improving traffic recording efficiency and verification efficiency.

[0159] In practice, users configure rules for test cases in the platform's traffic recording rule settings interface. The platform then generates corresponding traffic recording rules based on the user's configuration information. After generating a traffic recording rule, users can also edit it on the platform. Users can update the configuration in the traffic recording rule to obtain the updated traffic recording rule.

[0160] Optionally, the rule configuration operation may further include a general rule configuration operation for a target application that is called when executing the test case; after receiving the user's rule configuration operation for the test case, the following may also be included:

[0161] At least one traffic recording rule corresponding to the target application is updated; different rules in the at least one traffic recording rule correspond to different test cases.

[0162] In actual applications, users can perform general rule configuration operations for the target application called during the test case. Specifically, in the traffic recording rule setting interface provided by the platform, the configuration content related to the target application can also include application general configuration. After the user clicks the application general configuration control of the target application, they can enter the application general configuration interface of the target application. In the application general configuration interface, general configuration can be performed for traffic type, traffic point and traffic field. After the configuration is completed, it can be applied to multiple traffic recording rules corresponding to the target application. There is no need to configure the target application one by one in the multiple traffic recording rules corresponding to the target application, which is conducive to improving the convenience and efficiency of configuration.

[0163] In actual applications, if the traffic recording rule configured in the traffic recording rule settings interface conflicts with the general configuration of the target application, you can set the priority of the current traffic recording rule configuration to a higher level to avoid traffic recording failures caused by configuration conflicts.

[0164] Figure 7 A lane diagram of a test method provided in an embodiment of this specification.

[0165] like Figure 7 As shown, the execution entities involved in the process of the test method may include a verification platform, a log management platform and a test platform. Figure 7 The method flow may include a rule acquisition phase, a test execution phase, and a verification phase, which may specifically include the following steps:

[0166] In the rule acquisition phase, an optional implementation method can be as follows Figure 7 As shown in steps 702 to 710 in .

[0167] Step 702: The verification platform receives the user's rule configuration operation for the test case.

[0168] Step 704: The verification platform generates traffic recording rules in response to the rule configuration operation.

[0169] Step 706: The verification platform sends the traffic recording rules to the test platform.

[0170] Step 708: The test platform obtains a test case for testing the program that implements the service link.

[0171] Step 710: The test platform obtains traffic recording rules corresponding to the test case.

[0172] In actual applications, the step of obtaining a test case for testing a program that implements a business link by the test platform in step 708 may also be performed after or during the above step 710, and there is no specific limitation on this.

[0173] During the test execution phase, an optional implementation can be as follows Figure 7 As shown in steps 712 to 718 in .

[0174] Step 712: The test platform records the first traffic data generated by the execution of the test case in the first environment according to the traffic recording rules; wherein the first version of the program for implementing the business link is deployed in the first environment.

[0175] Step 714: The test platform associates the first traffic data with the test case identifier and the first execution identifier used to identify the first traffic data and stores them in the log management platform.

[0176] Step 716: The test platform records the second traffic data generated by the execution of the test case in the second environment according to the traffic recording rules; wherein, a second version program for implementing the business link is deployed in the second environment, and the generation time of the second version program is later than the generation time of the first version program.

[0177] Step 718: The test platform associates the second traffic data with the test case identifier and the second execution identifier used to identify the second traffic data and stores them in the log management platform.

[0178] In actual applications, in step 716, the test platform records the second traffic data generated by the test case executing in the second environment according to the traffic recording rules, which can also be performed before the above step 712 or the two steps can be performed simultaneously, and there is no specific limitation on this.

[0179] During the verification phase, an optional implementation can be as follows Figure 7 As shown in steps 720 to 732 in .

[0180] Step 720: The test platform sends verification task information for the test case to the verification platform.

[0181] Step 722: The verification platform obtains verification task information.

[0182] Step 724: The verification platform retrieves the first flow data from the log management platform based on the use case identifier and the first execution identifier in the verification task information.

[0183] Step 726: The verification platform retrieves the second traffic data from the log management platform based on the use case identifier and the second execution identifier in the verification task information.

[0184] Step 728: The verification platform compares the second flow data with the first flow data to obtain the test result of the second version of the program.

[0185] Step 730: The verification platform displays verification failure information and information processing controls corresponding to the verification failure information to the user.

[0186] Step 732: The verification platform updates the traffic recording rules in response to the user's control operation on the information processing control.

[0187] In actual applications, in step 726, the verification platform may retrieve the second traffic data from the log management platform based on the use case identifier and the second execution identifier in the verification task information before the above step 724, or the two steps may be performed simultaneously, without specific limitation.

[0188] Based on the same idea, the embodiments of this specification also provide a device corresponding to the above method. Figure 8 The embodiments of this specification provide corresponding Figure 2 A schematic diagram of the structure of a test device. Figure 8 As shown, the device may include:

[0189] The first acquisition module 802 is used to acquire a test case for testing a program that implements a service link.

[0190] The second acquisition module 804 is used to acquire the traffic recording rule corresponding to the test case; the traffic recording rule is used to represent the rule for recording the traffic data generated when the service link is running.

[0191] The first recording module 806 is used to record the first traffic data generated by the execution of the test case in the first environment according to the traffic recording rule; the first version of the program for implementing the business link is deployed in the first environment.

[0192] The second recording module 808 is used to record the second traffic data generated by the execution of the test case in the second environment according to the traffic recording rules; a second version program for implementing the business link is deployed in the second environment; the generation time of the second version program is later than the generation time of the first version program.

[0193] The testing module 810 is configured to determine a test result of the second version of the program based on the first traffic data and the second traffic data.

[0194] based on Figure 8 The present specification also provides some specific implementation plans of the device, which are described below.

[0195] Optionally, the traffic recording rule includes an application identifier of a target application that is called when executing the test case and for which traffic recording is required.

[0196] Optionally, the traffic recording rule also includes traffic recording range information for the target application; the traffic recording range information is determined based on at least one of a traffic type, a traffic point or a traffic field; wherein the traffic type includes at least one of an RPC call type, a database operation type and a message type; the traffic point represents at least one data transmission point for data transmission with the target application; the traffic field represents parameters used when transmitting data with the target application.

[0197] Optionally, the traffic recording range information is used to indicate a traffic range that needs to be ignored during configuration.

[0198] Optionally, the test result includes verification failure information for the target application; the verification failure information is used to indicate information that is inconsistent between the second flow data and the first flow data.

[0199] Correspondingly, the device may further include:

[0200] The display module is used to display the verification failure information and the information processing control corresponding to the verification failure information to the user.

[0201] A rule updating module is used to update the traffic recording rule in response to a user's control operation on the information processing control; the control operation is used to indicate that the data traffic corresponding to the verification failure information is ignored.

[0202] Optionally, the information processing control may include a rule dimension control; the rule updating module may specifically include:

[0203] The first rule updating unit is configured to modify the target recording rule for the target application in the traffic recording rule to ignore the data traffic corresponding to the verification failure information in response to a user's control operation on the rule dimension control.

[0204] Optionally, the information processing control may include an application dimension control; the rule updating module may specifically include:

[0205] The second rule updating unit is used to modify at least one traffic recording rule corresponding to the target application to ignore the data traffic corresponding to the verification failure information in response to the user's control operation on the application dimension control; different rules in the at least one traffic recording rule correspond to different test cases.

[0206] Optionally, the verification failure information includes a failed traffic point where verification failed; the information processing control includes a traffic point ignore control; and the rule updating module may specifically include:

[0207] The third rule updating unit is used to modify the specified recording rule to ignore the data traffic corresponding to the specified traffic point that generates the verification failure information in response to the user's control operation on the traffic point ignore control; wherein, the specified recording rule includes the target recording rule for the target application in the traffic recording rule, or at least one traffic recording rule corresponding to the target application; different rules in the at least one traffic recording rule correspond to different test cases.

[0208] Optionally, the verification failure information includes a failed traffic field where verification failed; the information processing control includes a field ignore control; and the rule updating module may specifically include:

[0209] A fourth rule updating unit is used to modify the specified recording rule to ignore the data traffic corresponding to the specified traffic field that generates the verification failure information in response to the user's control operation on the field ignore control; wherein, the specified recording rule includes the target recording rule for the target application in the traffic recording rule, or at least one traffic recording rule corresponding to the target application; different rules in the at least one traffic recording rule correspond to different test cases.

[0210] Optionally, the testing module 810 may specifically include:

[0211] The judgment unit is configured to judge whether the first flow data and the second flow data meet a target condition and obtain a judgment result; the target condition includes at least one of a first judgment condition, a second judgment condition, and a third judgment condition. The first judgment condition is that a target flow point included in the first of the first flow data and the second flow data exists in the second of the first flow data and the second flow data; the second judgment condition is that a first target field included in the first of the first flow data and the second flow data exists in the second of the first flow data and the second flow data; and the third judgment condition is that a second data value corresponding to the second target field included in the second flow data is the same as a first data value corresponding to the second target field included in the first flow data.

[0212] The verification result unit is used to determine that the second version program fails the verification if the judgment result is no.

[0213] Optionally, the device may further include:

[0214] The rule configuration operation receiving module is used to receive the user's rule configuration operation for the test case.

[0215] The traffic recording rule generation module is used to generate the traffic recording rule in response to the rule configuration operation.

[0216] Optionally, the rule configuration operation may include a general rule configuration operation for a target application called when executing the test case; correspondingly, the apparatus may further include:

[0217] The traffic recording rule updating module is used to update at least one traffic recording rule corresponding to the target application; different rules in the at least one traffic recording rule correspond to different test cases.

[0218] Optionally, the testing method may be applied to a testing platform; the apparatus may further include:

[0219] The first storage module is used to associate the first traffic data with the use case identifier of the test case and the first execution identifier used to identify the first traffic data and then store them in a log management platform.

[0220] The second storage module is used to associate the second traffic data with the use case identifier of the test case and the second execution identifier used to identify the second traffic data and then store them in the log management platform.

[0221] Correspondingly, the testing module 810 may specifically include:

[0222] A verification task information sending unit is used to send verification task information for the test case to the verification platform; the verification task information carries the case identifier, the first execution identifier and the second execution identifier; the traffic recording rule is configured by the user in the verification platform.

[0223] Among them, the verification platform retrieves the first traffic data from the log management platform according to the use case identifier and the first execution identifier; retrieves the second traffic data from the log management platform according to the use case identifier and the second execution identifier; compares the second traffic data with the first traffic data to obtain a test result corresponding to the traffic recording rule.

[0224] It is understood that the above modules refer to computer programs or program segments for performing one or more specific functions. In addition, the distinction between the above modules does not mean that the actual program codes must also be separated.

[0225] Based on the same idea, the embodiments of this specification also provide devices corresponding to the above methods.

[0226] Figure 9 The embodiments of this specification provide corresponding Figure 2A structural diagram of a test device. Figure 9 As shown, the device 900 may include: at least one processor 910; and a memory 930 communicatively connected to the at least one processor; wherein the memory 930 stores instructions 920 executable by the at least one processor 910, and the instructions are executed by the at least one processor 910 to enable the at least one processor 910 to:

[0227] Obtain test cases for testing programs that implement business links.

[0228] Obtain a traffic recording rule corresponding to the test case; the traffic recording rule is used to represent a rule for recording traffic data generated when the service link is running.

[0229] According to the traffic recording rule, first traffic data generated by executing the test case in a first environment is recorded; a first version of a program for implementing the business link is deployed in the first environment.

[0230] According to the traffic recording rules, the second traffic data generated by the execution of the test case in the second environment is recorded; a second version program for implementing the business link is deployed in the second environment; the generation time of the second version program is later than the generation time of the first version program.

[0231] A test result of the second version of the program is determined based on the first traffic data and the second traffic data.

[0232] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments. Figure 9 As for the device shown, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0233] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0234] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures such as diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to hire a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0235] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0236] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0237] For the convenience of description, the above devices are described as being divided into various units according to their functions. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0238] It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0239] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0240] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0241] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0242] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0243] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0244] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0245] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0246] This specification may be described in the general context of computer-executable instructions, such as program modules, executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media, including storage devices.

[0247] The foregoing is merely an example of the present invention and is not intended to limit the present invention. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention are intended to be included within the scope of the claims of the present invention.

Claims

1. A testing method comprising: Obtain test cases for testing programs that implement business links; Obtaining traffic recording rules corresponding to the test case; The traffic recording rule is used to represent a rule for recording traffic data generated when the service link is running; Recording first traffic data generated by executing the test case in the first environment according to the traffic recording rule; A first version of a program for implementing the service link is deployed in the first environment; Recording, according to the traffic recording rule, second traffic data generated by executing the test case in a second environment; a second version of a program for implementing the service link is deployed in the second environment; and a generation time of the second version of the program is later than a generation time of the first version of the program; A test result of the second version of the program is determined based on the first traffic data and the second traffic data.

2. According to the method of claim 1, the traffic recording rule includes an application identifier of a target application that is called when executing the test case and for which traffic recording is required.

3. The method according to claim 2, wherein the traffic recording rule further includes traffic recording range information for the target application; the traffic recording range information is determined based on at least one of a traffic type, a traffic point, or a traffic field; in, The traffic type includes at least one of an RPC call type, a database operation type, and a message type; The traffic point represents at least one data transmission point for performing data transmission with the target application; The traffic field indicates parameters used when performing data transmission with the target application.

4. The method as claimed in claim 3, wherein the traffic recording range information is used to indicate a traffic range that needs to be ignored during configuration.

5. The method according to claim 2, wherein: The test result includes verification failure information for the target application; The verification failure information is used to indicate information that the second flow data is inconsistent with the first flow data; After determining the test result of the second version of the program based on the first traffic data and the second traffic data, the method further includes: Displaying the verification failure information and an information processing control corresponding to the verification failure information to the user; In response to a user's control operation on the information processing control, the traffic recording rule is updated; the control operation is used to indicate that the data traffic corresponding to the verification failure information is ignored.

6. The method according to claim 5, wherein: The information processing control includes a rule dimension control; and updating the traffic recording rule in response to a user's control operation on the information processing control specifically includes: In response to a user's control operation on the rule dimension control, a target recording rule for the target application in the traffic recording rule is modified to ignore data traffic corresponding to the verification failure information.

7. The method according to claim 5, wherein: The information processing control includes an application dimension control; and updating the traffic recording rule in response to a user's control operation on the information processing control specifically includes: In response to the user's control operation on the application dimension control, at least one traffic recording rule corresponding to the target application is modified to ignore the data traffic corresponding to the verification failure information; different rules in the at least one traffic recording rule correspond to different test cases.

8. The method of claim 5, wherein: The verification failure information includes the failed traffic point where the verification failed; the information processing control includes a traffic point ignore control; The updating of the traffic recording rule in response to the user's control operation on the information processing control specifically includes: In response to the user's control operation on the traffic point ignore control, the specified recording rule is modified to ignore the data traffic corresponding to the specified traffic point that generates the verification failure information; wherein, the specified recording rule includes the target recording rule for the target application in the traffic recording rule, or at least one traffic recording rule corresponding to the target application; different rules in the at least one traffic recording rule correspond to different test cases.

9. The method of claim 5, wherein: The verification failure information includes a failed traffic field where verification failed; the information processing control includes a field ignore control; and the updating of the traffic recording rule in response to a user's control operation on the information processing control specifically includes: In response to the user's control operation on the field ignore control, the specified recording rule is modified to ignore the data traffic corresponding to the specified traffic field that generates the verification failure information; wherein, the specified recording rule includes the target recording rule for the target application in the traffic recording rule, or at least one traffic recording rule corresponding to the target application; different rules in the at least one traffic recording rule correspond to different test cases.

10. The method according to claim 1, wherein determining a test result of the second version of the program based on the first traffic data and the second traffic data comprises: determining whether the first flow data and the second flow data meet a target condition, and obtaining a determination result; The target condition includes at least one of a first judgment condition, a second judgment condition, and a third judgment condition; The first judgment condition is that the target flow point included in the first one of the first flow data and the second flow data exists in the second one of the first flow data and the second flow data; The second judgment condition is that the first target field included in the first one of the first flow data and the second flow data exists in the second one of the first flow data and the second flow data; The third judgment condition is that the second data value corresponding to the second target field included in the second traffic data is the same as the first data value corresponding to the second target field included in the first traffic data; If the judgment result is no, the second version program fails the verification.

11. The method according to claim 1, before obtaining the traffic recording rule corresponding to the test case, further comprising: receiving a rule configuration operation from a user for the test case; In response to the rule configuration operation, the traffic recording rule is generated.

12. The method according to claim 11, wherein the rule configuration operation comprises a general rule configuration operation for a target application invoked when executing the test case; and after receiving the user's rule configuration operation for the test case, further comprising: Updating at least one traffic recording rule corresponding to the target application; Different rules in the at least one traffic recording rule correspond to different test cases.

13. The method according to claim 1, wherein the testing method is applied to a test platform; After recording the first traffic data generated by executing the test case in the first environment according to the traffic recording rule, the method further includes: Associating the first traffic data with the use case identifier of the test case and a first execution identifier for identifying the first traffic data and storing the resultant data in a log management platform; After recording the second traffic data generated by executing the test case in the second environment according to the traffic recording rule, the method further includes: Associating the second traffic data with the use case identifier of the test case and a second execution identifier for identifying the second traffic data and storing the resultant data in the log management platform; Determining a test result of the second version of the program based on the first traffic data and the second traffic data specifically includes: Sending verification task information for the test case to the verification platform; the verification task information carries the case identifier, the first execution identifier, and the second execution identifier; the traffic recording rule is configured by the user in the verification platform; The verification platform retrieves the first traffic data from the log management platform according to the use case identifier and the first execution identifier; Retrieving the second traffic data from the log management platform according to the use case identifier and the second execution identifier; The second traffic data is compared with the first traffic data to obtain a test result corresponding to the traffic recording rule.

14. A testing device comprising: A first acquisition module is used to acquire a test case for testing a program that implements a business link; A second acquisition module is used to obtain a traffic recording rule corresponding to the test case; The traffic recording rule is used to represent a rule for recording traffic data generated when the service link is running; A first recording module is configured to record first traffic data generated by executing the test case in the first environment according to the traffic recording rule; A first version of a program for implementing the service link is deployed in the first environment; A second recording module is configured to record, according to the traffic recording rule, second traffic data generated by executing the test case in a second environment; a second version of a program for implementing the service link is deployed in the second environment; and the second version of the program is generated later than the first version of the program. A testing module is used to determine a test result of the second version program based on the first traffic data and the second traffic data.

15. A testing device comprising: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to: Obtain test cases for testing programs that implement business links; Obtaining a traffic recording rule corresponding to the test case; the traffic recording rule is used to represent a rule for recording traffic data generated when the service link is running; Recording, according to the traffic recording rule, first traffic data generated by executing the test case in a first environment; a first version of a program for implementing the service link is deployed in the first environment; Recording, according to the traffic recording rule, second traffic data generated by executing the test case in a second environment; a second version of a program for implementing the service link is deployed in the second environment; and a generation time of the second version of the program is later than a generation time of the first version of the program; A test result of the second version of the program is determined based on the first traffic data and the second traffic data.

Images