Regression testing method, computer equipment and storage medium

Abstract

The invention provides a regression test method, computer equipment and a storage medium, and the method comprises the steps: monitoring a flow message on an online processing link, and analyzing production data from the flow message; creating a test case for the production data, wherein the test case is used for simulating a scene in which the online processing link responds to the flow message; constructing test data for the test case, wherein the test data is data obtained after the production data is shifted; creating a simulation task for executing the test case on a to-be-tested processing link so as to simulate a response task executed on the online processing link in a scene of responding to the traffic message; and comparing an execution result of the simulation task with an execution result of the response task to determine a test result of the to-be-tested processing link.

Description

Technical Field

[0001] The present disclosure relates to the field of software testing, and in particular, to a method for regression testing, a computer device, and a storage medium. Background Art

[0002] Regression testing refers to, after modifying a software system (such as fixing defects, adding new functions, optimizing performance, etc.), re-running the previous test cases to ensure that the modification does not introduce new defects, and the original functions still work properly, the changes made work as expected and do not damage the existing functions of the software; and checking whether the modification has an unexpected impact on other parts of the software.

[0003] Large-scale architecture upgrades are a complex process involving multiple aspects of testing. Through comprehensive regression testing, it is necessary to ensure that after the architecture upgrade, the functions, performance, compatibility, security, and user experience of the system are all within an acceptable range, and new errors or defects are avoided. For the regression testing of architecture upgrades, testers currently face the problems of complex scenario construction and difficulty in reproducing in the online environment. Summary of the Invention

[0004] In view of this, the present disclosure provides a method for regression testing, a computer device, and a storage medium to solve the deficiencies in the related art.

[0005] According to the first aspect of the embodiments of the present invention, a method for regression testing is provided, including the steps of: Listening to traffic messages on the processed link that has been put on the line, and parsing production data from the traffic messages; Creating test cases for the production data, where the test cases are used to imitate the scenario in which the processed link that has been put on the line responds to the traffic messages; Constructing test data for the test cases, where the test data is the data after offsetting the production data; Creating a simulation task for executing the test cases on the processed link to be tested, to imitate the response task executed in the scenario where the processed link that has been put on the line responds to the traffic messages; Comparing the execution result of the simulation task with the execution result of the response task to determine the test result of the processed link to be tested.

[0006] Optionally, the traffic messages are collected multiple times, and the method further includes: Filtering the traffic messages for which simulation tasks have been executed; Updating / creating the test data and the simulation tasks for the production data of the unfiltered traffic messages; Filtering the executed simulation tasks for the updated / created test data.

[0007] Optionally, the step of filtering out traffic messages that have executed simulation tasks includes: Parse the process data and result data of the traffic message, where the process data represents the intermediate states experienced in generating the result data; When the test case created for the result data already exists, determine whether the simulation task for executing the test case has been executed based on the process data.

[0008] Optionally, the test data is stored in a shadow table.

[0009] Optionally, the traffic message includes a request body, and the step of creating the test case includes: Create the simulation request body, which is used to imitate the request body of the traffic message; Optionally, the step of constructing test data includes: Restore the full amount of data associated with the simulation request body from the production data parsed from the traffic message, and offset the full amount of data to be used as the test data.

[0010] Optionally, when the scenario imitated by the test case is a reverse operation scenario, the full amount of data includes the production data of the forward operation targeted by the reverse operation.

[0011] Optionally, the step of comparing the execution result of the simulation task with the execution result of the response task includes: Determine the interference data in the execution result, and compare the execution result of the simulation task with the non-interference data in the execution result of the response task.

[0012] In a second aspect of the embodiments of the present invention, a computer device is provided, including a processor and a machine-readable storage medium. The machine-readable storage medium stores machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to execute the methods described in the various embodiments of the first aspect above.

[0013] In a third aspect of the embodiments of the present invention, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the methods described in the various embodiments of the first aspect above are implemented.

[0014] It is easily understandable that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present disclosure.

[0015] The present disclosure collects real-time production data on the online processing link, constructs the real-time production data into test data, and after performing a simulation task that emulates the real environment in the test environment, compares the processing results of the online real environment and the test environment in real time. Since the production data in the online real environment can be considered as a full-scale data set, that is, it contains production data triggered under all possible service scenarios, the constructed test data is also a full-scale data set in the test environment, and the simulation task is to imitate the process of the response task in the real environment, which means that each service scenario experienced in the real environment is reproduced and executed in the test environment, so the test scenarios can also achieve full coverage. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings herein are incorporated into the specification and form a part of this disclosure, showing embodiments consistent with this specification, and are used together with the specification to explain the principles of this disclosure.

[0017] Figure 1 is a partial flowchart of a regression testing method shown according to an embodiment of this specification; Figure 2 is a UI schematic diagram showing test results shown according to an embodiment of this specification; Figure 3 is a schematic diagram of a statistical and supplementary test scenario shown according to an embodiment of this specification; Figures 4 - 6 is a schematic diagram of an application example shown according to an embodiment of this specification; Figure 7 is a schematic diagram of the hardware structure of a computer device shown according to an embodiment of this specification. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0018] Here, the exemplary embodiments will be described in detail, and the examples are shown in the accompanying drawings. When the following description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. On the contrary, they are only examples of devices and methods consistent with some aspects of this specification as detailed in the appended claims.

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

[0020] It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, 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 this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "while" or "in response to a determination".

[0021] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this disclosure are all information and data that have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or reject.

[0022] In the process of software development and maintenance, it is necessary to ensure the quality and stability of software products through testing. Regression testing is to retest the software that has been tested to ensure that after the software is modified, updated, or optimized, the original functions and performance still remain normal and no new errors or defects are introduced.

[0023] When designing test cases for regression testing, testers need to analyze the possible associated scenarios for the changed software functions and determine the test cases for each scenario accordingly. For example, a software that can implement the takeout function adds a function of "allowing users to select the pick-up time". To ensure that this function is normal and does not affect other existing functions, before this new function is launched, regression testing is required. In addition to analyzing the test cases for the scenarios related to this function, testers also need to test the original functions to verify whether the new function has an impact on the existing functions. Test cases for the existing functions are as follows: Normal order placement process Test scenario: The user completes the normal order placement process without selecting the pick-up time.

[0024] Expected result: The order is successfully created, the order status shows "awaiting pick-up", and the pick-up time is defaulted to the current time.

[0025] Cancel the order Test scenario: The user cancels the order after placing the order.

[0026] Expected result: The order status shows "cancelled", and the pick-up time no longer reminds the user.

[0027] Order Inquiry Test Scenario: After a user places an order, they inquire about the order details.

[0028] Expected Result: The pick-up time shown in the order details is the same as the time selected by the user.

[0029] Thus, whether the test scenarios are comprehensive is an important factor in ensuring the test effectiveness of regression testing. Additionally, the greater the number and combination methods of the test scenarios involved, the more complex the scenario construction will become. Especially in the case of software system architecture upgrades, it is very difficult for testers to quickly and comprehensively design all the scenarios for regression testing.

[0030] Architecture upgrades may involve major changes to the core structure and design of the system, which have an impact on the system's functionality, performance, compatibility, and security. For example, in order to achieve rapid deployment and elastic scalability of the system, a large e-commerce platform upgrades from a monolithic architecture to a microservices architecture. To ensure that the upgraded system can operate normally and no new errors or defects are introduced, usually a full-scale regression test is performed on the upgraded e-commerce platform, that is, all functions and performance of the software are tested to ensure that all functions and performance work properly. However, due to the characteristics of architecture upgrades, such as an increase in the number of services, the dependencies between services in the new architecture and with external systems becoming more intricate, and the need to re-design and optimize service processes to adapt to the new architecture, it poses a huge challenge to the scenario construction of regression testing for architecture upgrades. For example, when changing from a monolithic architecture to a microservices architecture, the originally centralized functions are dispersed into multiple independent services, resulting in an increase in the number of services. Each service has its own service logic and interfaces, which makes the interaction combinations between services to be tested increase exponentially. Taking the upgrade of an e-commerce system from a monolithic architecture to a microservices architecture as an example, it involves multiple microservices such as user services, product services, and order services, and the call relationships between them are complex and diverse. It is very difficult to cover all possible interaction scenarios. Another example is that a simple service process may involve the collaborative work of multiple services, and these services may also depend on different third-party systems (such as payment gateways, logistics interfaces, etc.). Any change in a dependent link may affect the correctness of the entire process. It is difficult to consider all test scenarios under different dependency combinations. For large-scale architecture upgrades, since large systems usually process a large amount of service data, the storage, processing, and transmission methods of data may change after the architecture upgrade. The test scenarios need to consider the impact of different scales and types of data on the system, including performance testing under large data volumes and data consistency verification. It is not easy to prepare a comprehensive and representative test data set to cover all possible situations, and as the data volume increases, the time and resource requirements for test execution will also increase significantly.

[0031] The present disclosure provides a solution to the problems of difficult construction of test data and incomplete scenario coverage in regression testing.

[0032] In the present disclosure, a processing chain refers to the entire process path in a software system that starts from input data entering the system and goes through a series of ordered processing steps to finally generate an output result. A processing chain will include several processing nodes, and each node completes a specific function or task. For example, in an e-commerce order processing system, the processing nodes may include order creation verification, inventory check, price calculation, payment processing, logistics allocation, etc. Production data refers to the data generated and used in an online software environment. For example, in an online e-commerce software, user behaviors such as login, browsing products, adding items to the shopping cart, and placing an order for payment will generate production data that is recorded.

[0033] The present disclosure collects real-time production data on an online processing chain, constructs the real-time production data into test data, and after performing a simulation task of a response task in a test environment, compares the processing results of the online real environment and the test environment in real time. Since the production data in the online real environment can be considered as a full-scale data set, that is, it includes production data triggered under all possible service scenarios, the constructed test data is also a full-scale data set in the test environment, and the simulation task mimics the process of the real response task, which means that each service scenario experienced in the real environment is reproduced and executed in the test environment, so the test scenarios can also achieve full coverage.

[0034] Figure 1 Some implementation steps of the embodiments of the present disclosure are described: S101, monitor traffic messages on an online processing chain, and parse production data from the traffic messages; S102, create test cases for the production data, and the created test cases are used to mimic the scenario of an online processing chain responding to traffic messages; for example, if the traffic message is a traffic message of "order placed successfully" by a user on a certain e-commerce platform, the created test case will mimic the scenario of the e-commerce platform executing the response process after receiving the traffic message of "order placed successfully".

[0035] S103 constructs test data for the test cases, and the test data is the data obtained by offsetting the production data; S104, create a simulation task for executing the test case on the processing chain to be tested, to mimic the response task executed in the scenario of an online processing chain responding to the traffic message; S105, compare the execution result of the simulation task with the execution result of the response task to determine the test result of the processing chain to be tested.

[0036] The production data contained in the monitored traffic messages reflects the real situation of the system during actual operation. Performing data offset on it can create a dataset suitable for use in the test environment without changing the overall statistical characteristics of the data. This can make the test results more persuasive and closer to the system performance in the real scenario. In S102, for the production data that needs to be offset, data offset processing is performed according to specified rules, and the rules for data offset are selected and determined based on the nature of the data, test requirements, and requirements of relevant regulations. For example, in S101, a user generates a traffic message of "account registration successful" on a certain platform, and the parsed production data contains the following fields: id (user ID), name (username), age (age), email (email address), credit_card_number (credit card number), etc. For numerical fields, such as age, data offset can be performed by adding or subtracting a fixed value. For string fields, such as name and email, data offset can be performed by replacing some characters or adding random characters. For sensitive information fields, such as credit_card_number, data offset can be performed by encrypting or replacing with fictional data.

[0037] In the embodiments of the present disclosure, the constructed test data is stored in a shadow table. The shadow table is a table with the same or highly similar structure to the production data table, storing and managing test-related data to ensure that the test process will not affect the production data, while being able to simulate a real data environment to verify the functions and behaviors of the system. As an example, it can be achieved by copying the structure of the production data table. For example, in MySQL, the CREATE TABLE LIKE statement can be used to create a shadow table with the same structure as the production data table.

[0038] In some examples, a component within the traffic message can be the request body, which carries various data information required for the operations that the message sender hopes the recipient to perform. The request body is mainly used to carry data related to specific service operations, and based on this data, it can be determined which corresponding logic needs to be executed, such as creating, updating, or deleting resources, etc. Different interfaces or services will specify the supported request body formats according to their own requirements. In these examples, the offset of the production data can be considered as the offset of the request body. In the HTTP protocol, when a client (such as a browser, mobile application) sends a request to the server, depending on the request method and specific service requirements, some requests will carry a request body. For example, on the user registration page of a website, after the user fills in the information (such as username, password, email, etc.) and clicks the registration button, the browser will encapsulate this data in the request body of the HTTP request in the application / x-www-form-urlencoded or multipart / form-data format and send it to the server. The data in the request body can be parsed according to the Content-Type field specified in the request header and converted into an internal processable data structure for subsequent operations.

[0039] In the traffic message, usually multiple types of information are carried to inform the recipient of what processing logic needs to be executed. These information can be reflected from different parts such as the message header and message body. For example, the general category of the message can be clarified through the message type identifier (Message Type ID) carried in the message header. Different message types correspond to different processing logics. Taking an e-commerce system as an example, there may be different message types such as "order creation message", "order payment success message", "inventory update message", etc., and each type has a dedicated processing flow. If the traffic message contains a request body, then the request body can carry various data information required for the operations that the recipient is expected to perform. Therefore, by parsing the traffic message, the processing logic to be executed for the traffic message can be obtained, and thus in S103, test cases corresponding to this processing logic can be created.

[0040] When creating a test case, if the traffic message contains a request body, the process of creating the test case can be to create a simulated request body that can simulate the request body of the traffic message. For example, for the traffic message of "order creation", the request body contains data for describing various attributes and details of the new order, such as user ID (user_id), user nickname (user_nickname), list of product IDs (product_ids), list of product quantities (product_quantities), product details (product_details), etc. Therefore, the simulated request body created by the test case will also contain these fields. And the test data created is the data generated after offsetting these fields in the request body.

[0041] In some embodiments, in order to execute the created test case, it may be necessary to restore the full amount of data associated with the simulated request body using production data. In the present disclosure, the full amount of data includes not only the production data parsed from the traffic message, but also the test data set constructed for executing the test case although it is not carried in the traffic message, and the data that needs to be obtained by accessing the database storing the production data or accessing the log file, etc. The full amount of data refers to the production data obtained by parsing the traffic message and other production data necessary for executing the test case restored using the traffic message.

[0042] As a typical example, the traffic message is a reverse operation request. In order to execute the response logic of the reverse operation request, it is necessary to first restore the production data that generated the reverse operation request. Therefore, the full amount of data includes the production data of the forward operation targeted by the reverse operation request. After the full amount of data is offset processed, it is stored as test data in the shadow table.

[0043] Reverse operation means that in some cases, due to various reasons (such as errors, exceptions, or requirement changes), it is necessary to reverse the operations that have been executed to restore to the previous state or undo the impact of the operations. For example, in an order processing system, reverse operation usually refers to canceling or revoking an already generated order. For example, for the reverse operation request of "customer cancels order", it can be that after placing an order, the customer requests to cancel the order due to some reasons (such as changing mind, placing the wrong order, etc.). For the reverse operation request of "return goods", it can be that after receiving the goods, the customer requests to return the goods due to reasons such as product quality problems or dissatisfaction. For the reverse operation request of "refund", it can be that after the customer pays for the order, a refund is required due to reasons such as order cancellation or return of goods. After parsing the traffic message and obtaining relevant data such as user ID, order ID, and refund reason from the parsed production data, a simulation request body of the same reverse operation request is constructed as a test case. In order to respond to the processing logic of this test case, that is, to execute the processing logic of canceling the order for this order, it is first necessary to restore the production data for generating the order. Therefore, in this example, the full amount of data is the production data parsed from the reverse operation requests such as "customer cancels order", "refund", "return goods" for this order and the production data for generating this order.

[0044] After completing the construction of test data and test cases through the above-mentioned embodiments, in S104, a simulation task is created on the processing link to be tested, that is, the response process of the online processing link to the traffic message is simulated on the unlaunched processing link, and then the simulation results in the test environment are compared with the real results in the online environment. As an example, when creating a simulation task, a service plugin can be customized for the test case to handle specific service logics. The service plugin is called during the execution of the simulation task, performs corresponding service operations, and returns results. For example, after creating a simulation task for responding to the "request refund" of a certain order, it is necessary to customize the corresponding service plugin to implement operations such as "agree to refund" and "refuse to refund" for this simulation task. The simulation task calls the specific operations in the service plugin according to the test data, thereby completing the execution process of the simulation task.

[0045] Regarding step S105, as an example, the result data generated after executing the online response task in the online environment can be collected and stored in an offline table, and the execution results of the simulation task are stored in another offline table. The test results of the processing link to be tested are determined by comparing the data in the two tables. A UI interface can be provided to display the test results, and components can be customized to display the details of the differences between the test results and the real results. A reference example of the UI interface can be as Figure 2 shown.

[0046] It should be noted that the interference data in the execution result can be determined first, and the non-interference data in the execution result of the simulation task is compared with the execution result of the response task. The interference data refers to the special fields in the result data, which belong to the foreseeable differences, such as the offset data, the random numbers generated by the system, the modification points on the processing link to be tested, and so on.

[0047] As a further improvement to the embodiments of the present disclosure, in order to enable the test cases to cover more comprehensive test scenarios, the coverage rate of the already tested test scenarios is statistically analyzed. First, the previously simulated test scenarios are analyzed from the monitored traffic messages, and then the already simulated traffic messages are filtered. Next, test cases are generated for the traffic messages that have not been simulated, and finally, the result of full scenario coverage is achieved. This process can be implemented through the following steps: S201, filter the traffic messages for which the simulation tasks have been executed; S202, update or create test data for the production data of the unfiltered traffic messages; and update or create simulation tasks; S203, filter the executed simulation tasks for the updated or created test data.

[0048] In some examples, when executing S201, it may be necessary to analyze using the process data of the traffic messages. The process data refers to the intermediate state data generated in the traffic-related service processes on the processing line. These data reflect the execution situations and relevant information of each stage of the service process from the start to the end, and can characterize the intermediate states experienced in generating the result data. The result data refers to the production data parsed from the traffic messages. The process data in the present disclosure can be obtained from the logs. Therefore, it can be seen that the full amount of data can include, in addition to the result data and other data constituting the test data set read from the database based on the result data, the process data.

[0049] Through the analysis of the process data, the executed simulation tasks can be analyzed. For example, when a reverse operation request message of "refund successful" is monitored, considering that there are likely to be various situations in the intermediate states experienced by this reverse operation request message, it is necessary to analyze the process experienced in generating this reverse operation request message, such as whether this "refund successful" message is generated under the process of the user first canceling and then applying for a refund again after applying for a refund, or under the processing process of applying for arbitration after being rejected by the system after applying for a refund, etc. Through the analyzed process data, combinations of multiple simulation tasks under the same test case can be designed, and it can also be determined whether the simulation tasks have been executed. Restoring the intermediate states experienced by the simulation result data according to the process data can achieve a more realistic simulation effect.

[0050] The implementation process of step S201 is illustrated here. For a traffic message of "refund successful", the test data recorded in the shadow table for this traffic message is the pre-sale refund process where the user cancels the order before shipment. When this traffic message is received again, by analyzing the process data, the traffic messages of the covered "pre-sale refund" process can be filtered out first, and the traffic messages such as "post-sale refund" where the user is dissatisfied after receiving the goods and not covered can be collected. In this way, if the scenarios targeted by the filtered traffic messages are high-proportion scenarios, the requirements for device performance caused by a large number of message listeners will be greatly reduced. Similarly, in S202, when a "refund successful" traffic message has been executed by a simulation task and then a "refund successful" traffic message is received again, if it is determined based on the process data that the intermediate state experienced by the historical simulation task is "pre-sale refund" while the intermediate state of the real response task of this traffic message is "post-sale refund", a simulation task for "post-sale refund" needs to be created according to the process data.

[0051] The production data in the shadow table is usually stored in the form of key-value structured data. It should be noted that if reverse operations with multiple different intermediate states are monitored for the same key-value, the existing test data in the shadow table needs to be updated using the process data instead of creating a new record to avoid record conflicts. For example, when a user purchases several items of product A and creates an order X, and then initiates a partial refund request for some of the items of product A in order X, and within a period of time after the refund, it is found that there is a quality problem with product A, so a full refund request is initiated again. After parsing the second refund request message, it can be determined that the two requests are for the same order, that is, the order numbers are the same. To avoid insertion errors when storing new test data in the shadow table, the production data parsed from the second refund request message needs to be used to update the test data of the refund request already stored in the shadow table.

[0052] Figure 3 It is the process of supplementing the test scenario coverage rate using process data in an example.

[0053] S301, obtain the monitored traffic message using a filtering script; S302, parse the result data of the traffic message; S303, determine whether a test case already exists for the result data. If not, create a test case (S304); if it already exists, proceed to S305; S305, obtain the process data corresponding to the result data from the log file, and the process data corresponding to the result data targeted by the existing test case; S306, compare whether the two types of process data are consistent to determine whether the simulation task already exists; S307, if it exists, filter the traffic message; if not, execute S308; S308, determine whether the value of the key in the process data is the same as the value of the key of the test data of the existing test cases in the shadow table; if the same, execute S309, if different, execute S310; S309, use the process data to update the record of the test data with the same key in the shadow table; S310, use the process data to create new test data; S311, use the process data to create a simulation task.

[0054] The following is an application example of the present disclosure. As Figure 4 shown, Application A is an application that has been launched and runs in the production environment. The tasks on Application A are executed by several launched processing links. The production data is stored in the production data table of database DB_A, and the execution results of the response tasks for the traffic messages are stored in the offline database table odps1. Application B is an application that has not been launched and runs in the test environment. Application B is injected with a test script to be responsible for the regression test of Application B. The test data is stored in the shadow table of database DB_B, and the execution results of the simulation tasks are stored in the offline database table odps2. The simulation tasks created by Application B for the tasks of Application A are executed by several unlaunched processing links to be tested. Use the metaq message body to listen for traffic messages (those skilled in the art can implement it in other ways according to actual needs), and use the groovy script as the filtering script (those skilled in the art can replace it with scripts in other languages according to design requirements). The test process is divided into two stages: The first stage: construct test cases and test simulations.

[0055] The user inputs several data in Application A. After the task is executed by Application A, Application A sends the traffic message generated after executing the task. This traffic message is sent to the server to execute the response task on the one hand, and is monitored by the metaq message body on the other hand. The execution result returned by the server after executing the response task is stored in the offline database table odps1. The message monitored by the metaq message body is parsed by the test script to obtain the production data. The test script constructs a simulation request body that is the same as the traffic message and constructs the test data required for the simulation request body. The constructed test data is stored in the shadow table, and the simulation request body is constructed into a simulation message and sent to Application B. Application B executes the simulation task on the unlaunched processing link. The simulation result is obtained by the test script and stored in the offline database table odps2. Compare the execution result of Application A recorded in odps1 and the execution result of Application B in odps2 to judge the regression test result of Application B.

[0056] The second stage: Statistical test coverage and supplementary test scenarios.

[0057] Taking T as the test cycle, after completing the test simulation tasks in the first stage within the T cycle, at time T+1, the test scenarios with a statistical quantity of 0 for the test scenarios within the T cycle are counted. In the second stage, the groovy script is injected into the test script. According to the results counted at time T+1, filtering rules are written in the groovy script to preferentially filter the traffic messages corresponding to the un-covered test scenarios. When new traffic messages are monitored again, the groovy script parses the newly monitored traffic messages and determines whether the simulation tasks or test cases responding to the new traffic messages have been covered. If not, the traffic messages are collected, new test data and new simulation tasks are constructed based on the production data, and the simulation results after being executed by Application B are saved in the offline data table odps2. Compare the execution results of Application A recorded in odps1 and the execution results of Application B in odps2 to determine the regression test results of Application B.

[0058] Taking the traffic message of partial refund as an example, reference can be made to Figures 5 - 6 Understand the test process.

[0059] After User X successfully placed an order by selecting several products on Application A, the traffic message a for canceling some products was triggered. Therefore, the traffic message a is a reverse operation request for User X to apply for partial refund. The following is the test process for the traffic message a in the test environment.

[0060] After the traffic message a is monitored, it enters the process of creating a test case. From the request body of the traffic message a, it can be known that this traffic message is a reverse operation. Therefore, after constructing the simulated reverse message body, it is necessary to restore all the data required for this reverse operation scenario from the production data of the traffic message a.

[0061] In the data construction stage, according to the order ID in the production data, the key in the production data table is queried to obtain the relevant production data for generating this order ID. The result data parsed from the traffic message a and the production data for generating the order ID are used as all the data, and a request body offset is performed. The offset data is saved as test data in the shadow table.

[0062] After the test case and test data are successfully constructed, a simulation task is created on Application B to imitate the response operation of Application A to the traffic message a for canceling some products. When the simulation task is executed, the test data and test cases are passed to the processing link of Application B, and the processing process is executed through the service plug-in customized for this simulation task, and the simulation execution result is output.

[0063] Compare the simulation execution result and the real execution result, and output the comparison result.

[0064] User X triggered traffic message b for requesting partial refund on Application A, which is the second reverse operation request for the same order.

[0065] After traffic message b is monitored and the process data of traffic message b is analyzed, it is determined that the reverse operation targeted by this traffic message b is covered by the same test case as the reverse operation of the first partial return, but does not belong to the same simulation task. Therefore, a new test case does not need to be created for this test, and the status of the test case is modified to represent the status that the test case is still being executed. Similarly, all the data required for this reverse operation scenario needs to be restored from the production data of traffic message a.

[0066] In the data construction stage, according to the order ID in the production data, query the key in the production data table to obtain the relevant production data of other order IDs related to the process data. Use the result data parsed from traffic message a, the process data obtained from the query log, and the queried production data as all the data, perform a request body offset, and use the offset data as test data to overwrite the records with the same order ID already existing in the shadow table.

[0067] After the test data is successfully constructed, create a simulation task on Application B to imitate the response operation of Application A to traffic message b. When the simulation task is executed, the test data and the test case will be passed to the processing link of Application B. Different from the first time when the reverse operation request was received, since it belongs to the same test case, the executed simulation tasks can be filtered first during this execution, and then the processing process can be executed through the service plugin customized for this simulation task to output the simulation execution result.

[0068] Figure 7 FIG. is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present specification. The computer device may include a processor 601 and a machine-readable storage medium 602 storing machine-executable instructions. The processor 601 and the machine-readable storage medium 602 may communicate via a system bus 603. And by reading and executing the machine-executable instructions corresponding to the supply and demand prediction logic in the machine-readable storage medium 602, the processor 601 may execute the supply and demand prediction method described above.

[0069] The machine-readable storage medium 602 mentioned in this document can be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and so on. For example, the machine-readable storage medium 602 can include at least one of the following storage media: volatile memory, non-volatile memory, and other types of storage media. Among them, the volatile memory can be RAM (Random Access Memory), and the non-volatile memory can be flash memory, a storage drive (such as a hard disk drive), a solid-state drive, a storage disk (such as an optical disk, a DVD, etc.).

[0070] Based on the method described in any of the above embodiments, the embodiments of this specification also provide a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it can be used to execute a supply and demand prediction method described in any of the above embodiments.

[0071] The above description of specific embodiments of this specification has been made. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be executed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0072] The step division of the above various methods is only for clear description. When implemented, they can be combined into one step or some steps can be split into multiple steps. As long as the same logical relationship is included, it is within the protection scope of this application; adding insignificant modifications or introducing insignificant designs to the algorithm or process, but not changing the core design of its algorithm and process, is within the protection scope of this application.

[0073] Among them, the description of "specific examples", or "some examples", etc. means that the specific features, structures, materials, or characteristics described in connection with the embodiments or examples are included in at least one embodiment or example of this specification. In this specification, the schematic expression of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples.

[0074] Those skilled in the art will readily conceive of other embodiments of the present specification after considering the specification and practicing the invention claimed herein. This specification is intended to cover any variations, uses, or adaptations of the present specification, which follow the general principles of the present specification and include known common general knowledge or conventional technical means in the technical field not claimed in the present specification. The specification and examples are only regarded as exemplary, and the true scope and spirit of the present specification are pointed out by the following claims.

[0075] It should be understood that the present specification is not limited to the exact structures already described and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of the present specification is only limited by the appended claims.

[0076] The above are only the preferred embodiments of the present specification, and are not intended to limit the present specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present specification shall be included within the scope of protection of the present specification.

Claims

1. A method for regression testing, characterized in that, Including the steps of: Monitoring traffic messages on the processed link that has been launched, and parsing production data from the traffic messages; Creating test cases for the production data, where the test cases are used to simulate the scenario of the processed link that has been launched responding to the traffic messages; Constructing test data for the test cases, where the test data is the data obtained by offsetting the production data; Creating a simulation task for executing the test cases on the processed link to be tested, so as to simulate the response task executed in the scenario of the processed link that has been launched responding to the traffic messages; Comparing the execution result of the simulation task with the execution result of the response task to determine the test result of the processed link to be tested.

2. The method according to claim 1, wherein The traffic messages are collected multiple times, and the method further includes: Filtering the traffic messages for which the simulation tasks have been executed; Updating / creating the test data and the simulation tasks for the production data of the unfiltered traffic messages; Filtering the executed simulation tasks for the updated / created test data.

3. The method according to claim 2, wherein The step of filtering out the traffic messages for which the simulation tasks have been executed includes: Parsing the process data and result data of the traffic messages, where the process data represents the intermediate states experienced in generating the result data; When the test case created for the result data already exists, determining whether the simulation task for executing the test case has been executed based on the process data.

4. The method according to claim 1, wherein The test data is stored in a shadow table.

5. The method according to claim 1, wherein The traffic messages include a request body, and the step of creating the test cases includes: Creating a simulation request body, where the simulation request body is used to simulate the request body of the traffic messages.

6. The method according to claim 5, wherein The step of constructing the test data includes: Restoring the full amount of data associated with the simulation request body from the production data parsed from the traffic messages, and offsetting the full amount of data to be used as the test data.

7. The method according to claim 6, wherein When the scenario simulated by the test case is a reverse operation scenario, the full amount of data includes the production data of the forward operation targeted by the reverse operation.

8. The method according to claim 1, characterized in that, The step of comparing the execution result of the simulation task with the execution result of the response task includes: Determining the interference data in the execution result, and comparing the execution result of the simulation task with the non-interference data in the execution result of the response task.

9. A computer device, characterized in that, Including a processor and a machine-readable storage medium, where the machine-readable storage medium stores machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to execute the method according to any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, A computer program is stored thereon, and when the computer program is executed by a processor, it implements the method according to any one of claims 1 to 8.

Images