Version comparison method, system and equipment of freight rate search system and medium
By generating test requests for different user groups and scenarios in the freight search system, comparing the response data of new and old version systems, the problems of functional stability and user experience during the version update process are solved, and the system's security, stability and user-friendly are achieved Improvement of experience.
Patent Information
- Application Number
- CN202411505435.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-25
- Publication Date
- 2025-02-07
AI Technical Summary
During the rapid version update of the freight search system, how to ensure that the system functions of the new version do not destroy the key old functions, while ensuring the stability and user experience of the system?
By generating test requests that reflect the usage preferences and preset scenario testing requirements of different user groups, compare response data for new and old versions of the system, and determine the operation between the two, so as to optimize and adjust the system.
It ensures the safety and stability of the system, improves the user experience, and helps staff to optimize the system in a timely manner through version comparison results.
Smart Images

Figure CN119396460A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer technology, and in particular to a version comparison method, system, electronic device and storage medium of a freight rate search system. Background Art
[0002] With the development of Internet technology, various websites, apps and other network products have been widely used, providing a variety of services for people's lives. As users' functional demands for network products continue to increase, product development teams need to update each module or the entire network product.
[0003] In the wave of big data, the fare search system in the civil aviation field faces unprecedented challenges. The fare search system needs to process faster, the monthly iteration demand is growing, and the frequency of real-time release of fare data for each flight is also constantly updated to adapt to market changes. In order to keep up with this pace, rapid updates of product versions have become the norm. In order to ensure the user experience, how to ensure that the functions of the new version of the system do not destroy the key old functions and the stability of the system are urgent issues to be solved. Summary of the invention
[0004] To solve the above problems, the present invention provides a version comparison method, system, electronic device and storage medium for a freight rate search system. By generating test requests that reflect the usage preference requirements of different user groups and preset scenario test requirements, the response data of the test requests in the new version of the freight rate search system and the old version of the freight rate search system are compared to determine the operating conditions between the new and old versions of the system, which is convenient for staff to optimize and adjust the system in a timely manner, thereby ensuring the security and stability of the system and improving the user experience.
[0005] In order to solve the above technical problems, the first aspect of the present invention provides a version comparison method of a freight rate search system, the method comprising:
[0006] Processing the source data based on preset user types and / or preset scenarios to generate multiple test requests for reflecting usage preference requirements of different user groups and / or preset scenario testing requirements; and when generating the test requests, adjusting the distribution ratio of the test requests according to the distribution of historical data;
[0007] Input each of the test requests into the new version freight rate search system and the old version freight rate search system respectively, and obtain feedback response data respectively;
[0008] The response data are compared accordingly according to the test request to obtain a version comparison result between the new version freight rate search system and the old version freight rate search system.
[0009] According to a preferred embodiment of the present invention, source data is processed based on preset user types and / or preset scenarios to generate multiple test requests for reflecting usage preference requirements of different user groups and / or preset scenario test requirements, including:
[0010] According to a preset user type and / or preset scenario requirement, adding travel information to a test request template to generate the test request;
[0011] Determine a specific user group according to the preset user type, extract request information corresponding to the specific user group from historical requests, and generate the test request;
[0012] A scenario keyword is determined according to the preset scenario, request information corresponding to the scenario keyword is filtered from historical requests, and the test request is generated.
[0013] According to a preferred embodiment of the present invention, the method further comprises:
[0014] Before generating the test request based on the historical operation data, deduplication of the historical operation data is performed according to the route data in the historical operation data according to the duplication of the route data;
[0015] After the test requests are generated, the validity of each of the test requests is checked according to preset business rules to determine the valid test requests.
[0016] According to a preferred embodiment of the present invention, when generating the test request, adjusting the distribution ratio of the test request according to the distribution of historical data includes:
[0017] Determine the user distribution ratio of each type of historical user group based on historical user data;
[0018] Determine the route distribution ratio of each historical route based on historical route data;
[0019] When generating the test request, the user distribution and route distribution of each of the test requests are made to conform to the user distribution ratio and the route distribution ratio.
[0020] According to a preferred embodiment of the present invention, the step of inputting each of the test requests into the new version freight rate search system and the old version freight rate search system to obtain feedback response data respectively includes:
[0021] Creating multiple processes to input each of the test requests into the new version freight rate search system and the old version freight rate search system respectively;
[0022] Receive response data fed back by the new version freight rate search system and the old version freight rate search system respectively, and store them in corresponding databases respectively.
[0023] According to a preferred embodiment of the present invention, the step of comparing the response data according to the test request to obtain a version comparison result between the new version of the freight rate search system and the old version of the freight rate search system includes:
[0024] Using the response data fed back by the new version freight rate search system as new version response data;
[0025] Using the response data fed back by the old version freight rate search system as the old version response data;
[0026] For each of the test requests, the primary keys of the new version response data and the old version response data corresponding to the same test request are matched; whether the primary keys match is determined, and if not, a mark is added to the new version response data and / or the old version response data; if they match, a difference comparison is performed on the data in the new version response data and the old version response data except the primary keys, and a difference comparison result of the test request is generated; the primary keys are data of a preset category in the new version response data and the old version response data;
[0027] Based on the difference comparison results corresponding to each of the test requests and the number of marks of the new version response data and / or the old version response data, the difference results between the new version freight rate search system and the old version freight rate search system are calculated as the version comparison result.
[0028] According to a preferred embodiment of the present invention, the method further comprises:
[0029] Obtaining the departure date and the sales date of each historical request in the source data;
[0030] Calculating a relative date deviation based on the deviation between the departure date and the sales date of each of the historical requests;
[0031] The departure date of each historical request in the source data is corrected according to the current system date and the relative date deviation.
[0032] In order to solve the above technical problems, the second aspect of the present invention provides a version comparison system of a freight rate search system, the system comprising:
[0033] A test request generation module is used to process source data based on preset user types and / or preset scenarios to generate multiple test requests that reflect usage preference requirements of different user groups and / or preset scenario test requirements; and when generating the test requests, adjust the distribution ratio of the test requests according to the distribution of historical data;
[0034] A request sending module, used to input each of the test requests into the new version freight rate search system and the old version freight rate search system respectively, and obtain feedback response data respectively;
[0035] The version comparison module is used to compare each response data according to the test request to obtain the version comparison result between the new version freight rate search system and the old version freight rate search system.
[0036] In order to solve the above technical problem, the third aspect of the present invention provides an electronic device, comprising:
[0037] Processor; and
[0038] A memory storing computer executable instructions, wherein when the computer executable instructions are executed, the processor executes the method described in any one of the above embodiments.
[0039] In order to solve the above technical problem, the second aspect of the present invention proposes a computer storage medium, wherein the computer storage medium stores one or more programs, and when the one or more programs are executed by a processor, the method described in any one of the above embodiments is implemented.
[0040] Compared with the prior art, the present invention has the following advantages: the present invention generates test requests that reflect the usage preference needs of different user groups and the preset scenario test needs, and adjusts the distribution ratio of the test requests based on the distribution of historical data, so that the distribution ratio of the test requests conforms to the actual situation and ensures the coverage of the test requests. Then, the response data of the test requests in the new version of the freight rate search system and the old version of the freight rate search system are compared to obtain the version comparison result of the new and old versions of the system, so as to determine the operation status between the new and old versions of the system, which is convenient for the staff to optimize and adjust the system in time, which not only ensures the security and stability of the system, but also improves the user experience.
[0041] Other features and advantages of the present disclosure will be described in the following description, and partly become apparent from the description, or be understood by implementing the present disclosure. The purpose and other advantages of the present disclosure can be realized and obtained by the structures pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS
[0042] In order to more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0043] Figure 1A schematic diagram of a method for comparing versions of a freight rate search system according to an embodiment of the present disclosure is shown;
[0044] Figure 2 A first flow chart of a method for comparing versions of a freight rate search system according to an embodiment of the present disclosure is shown;
[0045] Figure 3 A second flow chart of a method for comparing versions of a freight rate search system according to an embodiment of the present disclosure is shown;
[0046] Figure 4 A third flow chart of a method for comparing versions of a freight rate search system according to an embodiment of the present disclosure is shown;
[0047] Figure 5 A fourth flow chart of a method for comparing versions of a freight rate search system according to an embodiment of the present disclosure is shown;
[0048] Figure 6 A block diagram of a version comparison system of a freight rate search system according to an embodiment of the present disclosure is shown;
[0049] Figure 7 A schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION
[0050] In order to make the purpose, technical solution and advantages of the embodiments of the present disclosure clearer, the technical solution in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present disclosure.
[0051] The same reference numerals in the drawings represent the same or similar elements, components or parts, and thus the repeated description of the same or similar elements, components or parts may be omitted below. It should also be understood that although the first, second, third and other attributives representing the numbers may be used herein to describe various devices, elements, components or parts, these devices, elements, components or parts should not be limited by these attributives. In other words, these attributives are only used to distinguish one from another. For example, the first device may also be called the second device, but it does not deviate from the essential technical solution of the present invention. In addition, the terms "and / or" and "and / or" refer to all combinations including any one or more of the listed items.
[0052] See also Figure 1 , Figure 1 FIG. 1 is a flow chart of a version comparison method of a freight rate search system provided by the present invention. Figure 1 As shown, the method includes:
[0053] S11. Process the source data based on preset user types and / or preset scenarios to generate multiple test requests that reflect the usage preference requirements of different user groups and / or preset scenario testing requirements; and when generating test requests, adjust the distribution ratio of the test requests according to the distribution of historical data.
[0054] In this embodiment, the source data mainly comes from users who have not been put into production and users who have been put into production. For users who have not been put into production, the data comes from the test data template. By adding basic information such as city lists, itinerary types, and user preferences, one-way, round-trip, and multi-segment test request templates can be constructed. For fields not added in the template, default values can be assigned to generate self-built test requests. The user preferences in this solution can be obtained based on the usage records of historical users, or different types of users can fill them out independently. For example, some customers are accustomed to taking daytime flights when booking routes, and are accustomed to taking flights after noon for convenience. There are also flights that choose large passenger aircraft for comfort. These are all user preferences. At the same time, since this method is generated based on experience, it can be applied to version comparison solutions with insufficient historical data to achieve rapid generation of test data of a certain scale.
[0055] In this embodiment, for users who have been put into production, their flight records and operation information are recorded in log information or other historical databases. The operations and behaviors of historical users are obtained from the log information to generate corresponding test requests. On the one hand, the richness of test requests is increased, and on the other hand, more real and diverse data is provided. At the same time, as the number of users increases, log information or historical databases will gradually become the main source of test requests.
[0056] In this embodiment, user types can be grouped according to the identity of the user, for example, they can be classified according to students, corporate employees, corporate executives, self-media bloggers, etc., or they can be grouped according to the cabin class of the flight that the user is accustomed to selecting. For example, the most commonly selected cabin classes are first class, business class, and economy class. In this solution, preset user types are set to ensure that key types of users can generate corresponding test requests to ensure the usage experience of different types of users. For example, the number of self-media bloggers is small, but self-media bloggers generally conduct evaluations when taking flights, and self-media bloggers take flights more frequently, and they are more sensitive to changes in the fare search system. Therefore, the preset user types can include self-media bloggers. Similarly, other user types with fewer people and higher demands can be used as preset user types.
[0057] In this embodiment, the usage preference requirements for reflecting different user groups are generated based on user types, including: according to the above-mentioned preset user types, selecting the corresponding user in each preset user type, the user's operations and behaviors in the log information or other historical databases, that is, the user's usage preferences, and then generating test requests based on the operations and behaviors, the test requests for the user group composed of users of the same user type, that is, the test requests that reflect the usage preferences of the user group. In this solution, test requests for usage preference requirements are constructed. On the one hand, the adaptability of different user groups to the new and old versions of the system is tested for version comparison, and on the other hand, the usage experience of different user groups can be ensured.
[0058] In this embodiment, the scenarios include: itinerary type, cabin type, transfer type, price type, time type, geographic location type and other scenarios. Based on the preset scenario, a test request that reflects the preset scenario test requirements is generated. The corresponding test request can be filtered for the created test template by the keywords in the preset scenario, or the test request can be filtered from the log data or historical data. For example, the preset scenario can be economy class, business class, time period 11:00-13:00, number of transfers less than one, price range less than 2,000 yuan, etc. The corresponding keywords are selected by the preset scenario to quickly locate the matching request, and then generate the test request in this solution. In this solution, through the test request corresponding to the scenario, the response results of the new and old versions of the system to different test requests can be quickly determined. On the one hand, the difference between the test requests of the new and old versions of the system for different scenario situations can be determined. On the other hand, it can also facilitate users to quickly determine whether there is a bug in the system and help staff to check the system.
[0059] In this embodiment, the distribution of test requests in this solution is optimized through the distribution of each user type and each route in the historical data, so that the test requests cover different user types and route conditions, improve the comparison of various functional indicators of the system as a whole, and more comprehensively display the possible differences and functional changes between the new and old versions of the system.
[0060] In this embodiment, since the operations and behaviors in the log information or other historical databases used are relatively old, and the older the historical data, the more likely it is to have timeliness and accuracy problems, we use a date deviation calculation method to meet the test requirements. By calculating the deviation between each requested travel date and the sales date in the log, this deviation is used to adjust and correct the date part. Based on the current system date and the calculated date deviation, a new travel date can be generated to ensure the freshness of the data. The adjusted data request is saved and an index is created for subsequent use.
[0061] Specifically, the departure date and sales date of each historical request in the source data are obtained; the relative date deviation is calculated according to the deviation between the departure date and the sales date of each historical request; and the departure date of each historical request in the source data is corrected according to the current system date and the relative date deviation.
[0062] S12. Input each test request into the new version freight rate search system and the old version freight rate search system respectively, and obtain feedback response data respectively.
[0063] In this embodiment, since the greater the number of test requests, the more differences between systems and changes in various system functions can be checked, in this solution, the test requests can be input into the new version of the freight rate search system and the old version of the freight rate search system respectively through a plug-in, creating multiple threads or creating two parallel processes, and the response data fed back by the system is stored in a preset format, for example, by storing data in json format, that is, the response data is stored in a key-value pair manner. Specifically, the key can be a type and the value can be a corresponding numerical value, for example, the take-off time is the key and the specific time is the value; the amount is the key and the specific price is the value, etc. The response data can also be stored in a CSV file, Comma-Separated Values (CSV, sometimes also called character-separated values, because the separator character may not be a comma), and its file stores table data (numbers and text) in plain text.
[0064] Specifically, in the request sending stage, the focus is on efficient request processing and data preservation. We use Python (Python was designed by Guido van Rossum of the Netherlands National Research Center for Mathematics and Computer Science in the early 1990s. Python provides efficient high-level data structures and simple and effective object-oriented programming) multiprocessing module to create multiple processes. Each process can obtain test requests from the queue in parallel. In each process, we use the threading module to create two threads. These two threads can send requests to the new and old versions of the freight rate search system in parallel, which can further improve the parallelism of request processing and speed up the processing. The advantage of doing this is that the computing power of multi-core CPUs can be fully utilized to improve the efficiency of request processing. That is, multiple processes are created through multi-core processors. Each process can obtain test requests from the queue storing test requests in parallel, and each process includes two parallel threads, which send test requests to the new and old versions of the freight rate search system respectively through threads.
[0065] In this embodiment, since the fare search system will have many response results corresponding to a test request, for example, searching for flights within a certain price range and determining the departure and destination, more flight information that meets the requirements will appear; there will be different feedback results in different versions of the system, such as differences in format or arrangement order, and directly comparing the results one by one cannot quickly determine the differences. Therefore, a file in a preset format is generated for each response result, which can facilitate subsequent comparison statistics.
[0066] Specifically, the method also includes: creating multiple processes to input each test request into the new version freight rate search system and the old version freight rate search system respectively; receiving response data fed back by the new version freight rate search system and the old version freight rate search system respectively, and storing them in corresponding databases respectively.
[0067] In this embodiment, since the response data is structured, the fare search result is used as the starting point for expansion and indexing during the processing. For example, a fare search result may contain information about adults and children, and two records will be formed in the final result file. The corresponding fare information and flight information can be found through specific indexes (such as fare index and flight index). After this information is sorted, it will form a row of records in the CSV file, making the information clearer.
[0068] In this embodiment, when a problem occurs in the response data fed back by any version of the freight rate search system, the response data and log records with the problem are stored, and it is subsequently determined whether there is a problem with the test request issued or with the freight rate search system of the fed back response data, so that the staff can quickly handle it.
[0069] S13. Compare each response data accordingly according to the test request to obtain a version comparison result between the new version freight rate search system and the old version freight rate search system.
[0070] In this embodiment, the response data of the same test request in the new version of the fare search system and the response data in the old version of the fare search system are compared, and the differences between each flight in the response data in the new version and the old version are recorded as the comparison result. Specifically, the difference record can be stored as a comparison result file, and each test request will generate a corresponding comparison result file.
[0071] In this embodiment, during the comparison process, the response results of the test request in the two systems can be matched according to the flight number and then compared accordingly. This can avoid confusion caused by inconsistent order. Specifically, the basic air ticket fee, flight information, cabin information, passenger type, airline or agent sales code, issue date, basic air ticket fee, international standard taxes, etc. can be compared, and the values in the old version system, the values in the new version system, whether they are the same, and the size of the difference can be recorded. For each test request, a comparison result file containing the above information is generated for final statistics.
[0072] Specifically, some of the data in the response results can be compared first, and the other part can be compared later. For example, the data directly displayed in the search results can be compared first. Specifically, first, select the matching primary key: select the following matching primary keys from each parsed file: basic airfare, flight information, cabin information, passenger type, airline or agent sales code, and issue date. For unmatched primary keys, use specific identifiers to mark them. For example, the primary key that only exists in the new version system can be marked as "L", and the primary key that only exists in the old version system can be marked as "M". Once there is a difference in these primary keys, it means that the difference between the new version system and the old version system is obvious and needs to be corrected in time to avoid affecting the user experience. Secondly, compare other items: When the primary keys match, further compare other items, such as basic airfare, international standard taxes, etc., and record the values of the old version, the new version, whether they are the same, and the size of the difference. In this way, the comparison of the response data of a test request in the two version systems is completed.
[0073] Finally, each test case will get a corresponding comparison result file. In addition, during the comparison process, if there are errors or inconsistent taxes, these results will be stored separately in a specific directory. This will help the final tester to quickly troubleshoot the problem and deal with it accordingly.
[0074] In this embodiment, various comparison result files are summarized to finally obtain the version comparison result of the new version freight rate search system and the old version freight rate search system. Specifically, the number of matching primary keys and the number of mismatches can be counted, and the average value of the differences can be calculated. Then, the proportion results of other items can be counted in turn, and the difference ratios between the new and old versions can be calculated respectively. This information is summarized into a comparison result corresponding to a test request, which can reduce the data in the comparison result file, which is equivalent to a certain induction of the comparison result file of a test request, and then the comparison results of all test requests are counted into a total file as the version comparison result.
[0075] In this embodiment, after completing the entire test process, the script tool will record the corresponding success or failure log, which helps to understand the problem points in the test process. At the same time, in order to further analyze the test results, we further statistically analyzed the version comparison results, and displayed the average response time of the old version and the new version in the body of the test report, the response time distribution, the ratio of the new version to search for lower prices, the ratio of the new version to faster time, the same fare search results, the basic airfare, fuel costs, international standard taxes, the ratio of the final sales price of the air ticket, etc., which helps us effectively identify the differences between versions from an overall perspective. At the same time, in order to display the version comparison results in a timely, accurate and comprehensive manner and convey them to relevant personnel, we notify the test results in the form of emails. Pushing the massive data comparison version test results to relevant stakeholders allows relevant stakeholders to quickly understand the test results and confirm and troubleshoot the test results.
[0076] In this embodiment, by generating test requests that reflect the usage preference needs of different user groups and the preset scenario testing needs, and adjusting the distribution ratio of the test requests based on the distribution of historical data, the distribution ratio of the test requests is made to conform to the actual situation and the coverage of the test requests is ensured. Then, the response data of the test requests in the new version of the freight rate search system and the old version of the freight rate search system are compared to obtain the version comparison result of the new and old versions of the system, so as to determine the operation status between the new and old versions of the system, and facilitate the staff to optimize and adjust the system in a timely manner, which not only ensures the security and stability of the system, but also improves the user experience.
[0077] See also Figure 2 , Figure 2 FIG. 1 is a flow chart of a version comparison method of a freight rate search system provided by the present invention. Figure 2 As shown, Figure 1 Compared to the embodiment shown, the method includes:
[0078] S21. According to a preset user type and / or preset scenario requirement, add travel information to a test request template to generate a test request.
[0079] In this embodiment, for a preset user type, the usage preference of the preset user type can be obtained according to the historical habits of the preset user type or the questionnaire information collected from the users of the preset user type. For example, a student user prefers to travel in economy class, and at the same time, the price arrangement method selected is mostly arranged from low to high. Enterprise employees will have different travel standards, and corresponding usage preferences can be set for senior employees, middle-level employees and grassroots employees according to the travel standards of employees of the cooperating enterprise. In this solution, the usage preferences of users of the preset user type are used to add itinerary information to the test request template to generate a request for testing.
[0080] In this embodiment, by generating test requests through templates, a part of requests for testing can be generated when the amount of data is small. At the same time, since these requests are generated through templates, a part of types of users can be covered in a targeted manner to ensure that the needs of key users can be tested.
[0081] In this embodiment, the preset scenario requirements are similarly for flights between different cities, different itinerary types, time types or geographical types. For example, multiple tests in different situations are conducted for cities with a large number of flights between them to promptly resolve possible problems in the system to prevent system errors from affecting normal user use.
[0082] S22: Determine a specific user group according to a preset user type, extract request information corresponding to the specific user group from historical requests, and generate a test request.
[0083] In this embodiment, a specific user group is determined based on a preset user type, that is, a user group belonging to the preset user type is selected, request information of the specific user group is selected from historical requests that have been completed, and a test request is generated based on the request information. For example, if only the departure place and the destination are selected in the request information, the request information is directly used as a test request. If multiple non-conflicting conditions are selected in the request information, multiple test requests can be generated by permuting and combining the conditions in the request information.
[0084] S23. Determine a scenario keyword according to a preset scenario, filter request information corresponding to the scenario keyword from historical requests, and generate a test request.
[0085] In this embodiment, as above, a scenario keyword is determined based on a preset scenario, request information corresponding to the scenario keyword is selected from historical completed requests through the scenario keyword, and a test request is generated through the historical request information.
[0086] like Figure 3 As shown, based on this embodiment, the method further includes:
[0087] S31. Before generating a test request based on the historical operation data, deduplicate the historical operation data according to the route data in the historical operation data and the duplication of the route data.
[0088] In this embodiment, historical operation data and historical requests are both data in the user log information, and both historical operation data and historical requests can be used to construct test requests. In this solution, the proportion of routes in the log is counted, which can better understand the route distribution and generate data based on it. At the same time, route deduplication is supported. By configuring relevant parameters, duplicate routes in the log can be filtered out, thereby increasing the richness of route types in limited test cases, helping to dig out more valuable use cases in massive logs and reduce repetitive tests.
[0089] S32: After generating the test request, check the validity of each test request according to preset business rules to determine the valid test request.
[0090] In this embodiment, in this solution, the preset business rules can be determined according to the rationality of the test request. After the test request is obtained, the preset business rules are used to determine whether the test request is reasonable, that is, to determine the validity. For example, the validity of the data is checked using business rules and logic. The preset business rules include: missing values, abnormal values, and duplicate records. For example, the departure date cannot be later than the arrival date, and the departure destination is empty.
[0091] See also Figure 4 , Figure 4 FIG. 1 is a flow chart of a version comparison method of a freight rate search system provided by the present invention. Figure 4 As shown, Figure 1 Compared with the embodiment shown, the comparison method includes:
[0092] S41. Determine the user distribution ratio of each type of historical user group according to the historical user data.
[0093] S42. Determine the route distribution ratio of each historical route based on the historical route data.
[0094] In this embodiment, the user distribution ratio and the route distribution ratio can be used to illustrate the types of users who use flights for travel in historical data, as well as the number of users in different regions who use flights for travel. Determining the number of users of different types and the number of users in different regions can be used to make biased inclinations when generating test requests, thereby avoiding missing out on smaller user groups in the test and ensuring that the functions used by larger user groups are effectively tested.
[0095] S43. When generating a test request, the user distribution and route distribution of each test request are made to conform to the user distribution ratio and route distribution ratio.
[0096] In this embodiment, we counted the proportion of each user in the production log. The purpose of this step is to support covering all users according to the proportion of actual user distribution when generating test requests. In this way, we avoid missing users with smaller traffic and implement full user testing.
[0097] See also Figure 5 , Figure 5 FIG. 1 is a flow chart of a version comparison method of a freight rate search system provided by the present invention. Figure 5 As shown, Figure 1 Compared with the embodiment shown, the comparison method includes:
[0098] S51. Use the response data fed back by the new version freight rate search system as the new version response data.
[0099] S52. Use the response data fed back by the old version freight rate search system as the old version response data.
[0100] In this embodiment, the response data fed back by the new and old versions of the freight rate search systems for the test requests are named respectively, and each test request will have a search result in the new and old versions of the system respectively. This search result is the response data. If the response data of the test request in the new and old versions of the system are significantly different, or completely inconsistent, it means that a problem has occurred at this time, because not all users will use the latest version after the system is updated. Once inconsistency occurs, it will greatly affect the user's trust in the system. Even for users who use the latest version, once there is a large difference in functionality before and after the version update, it will also affect the user's experience.
[0101] S53. For each test request, match the primary keys of the new version response data and the old version response data corresponding to the same test request; determine whether the primary keys match, and if not, add a mark to the new version response data and / or the old version response data; if they match, perform a difference comparison on the data except the primary keys in the new version response data and the old version response data, and generate a difference comparison result for the test request; the primary key is data of a preset category in the new version response data and the old version response data.
[0102] In this embodiment, a part of the data in the new version response data and the old version response data is used as primary key data. The primary key data in the response data is first matched to see if it matches. If it does not match, a mark is added to the response data. If the primary key data matches, further comparison is made to see if there are any differences in the data other than the primary key data, and a difference comparison result is generated.
[0103] In this embodiment, a test request is determined to match and compare two response data of the old and new versions. First, the matching primary key is selected: the following matching primary keys are selected from each parsed file: basic airfare, flight information, cabin information, passenger type, airline or agent sales code, and date of issue. For unmatched primary keys, a specific identifier is used for marking. For example, a primary key that only exists in the new version can be marked as "L", and a primary key that only exists in the old version can be marked as "M". Secondly, other items are compared: when the primary key matches, other items such as basic airfare, international standard taxes, etc. are further compared, and the values of the old version, the new version, whether they are the same, and the size of the difference are recorded. Finally, a Compare file is generated: for each use case, a record of a Compare file is generated based on the above information. Finally, each use case will get a corresponding Compare file. In addition, during the comparison process, if an error or inconsistent taxes occur, these results are stored separately in a specific directory. This will help the final tester to quickly troubleshoot the problem and make corresponding treatments.
[0104] S54. Based on the difference comparison results corresponding to each test request and the number of marks of the new version response data and / or the old version response data, the difference results between the new version freight rate search system and the old version freight rate search system are calculated as the version comparison result.
[0105] In this embodiment, statistics are collected for each compare result, including the number of matching primary keys, the number of mismatches, and the average value of the differences. The ratio results of other items are then counted in turn, and the difference ratios between the new and old versions can be calculated. For each compare result, the above statistical information is organized into a record. Finally, all requested statistical records are output to a Statistics file.
[0106] See also Figure 6 , Figure 6 is a block diagram of a version comparison system of a freight rate search system provided by the present invention, such as Figure 6 As shown, the system includes: a test request generating module 11, a request sending module 12 and a version comparing module 13.
[0107] In this embodiment, the test request generation module 11 is used to process the source data based on preset user types and / or preset scenarios, and generate multiple test requests that reflect the usage preference requirements of different user groups and / or preset scenario testing requirements; and when generating test requests, adjust the distribution ratio of the test requests according to the distribution of historical data.
[0108] In this embodiment, the request sending module 12 is used to input each test request into the new version freight rate search system and the old version freight rate search system respectively, and obtain feedback response data respectively.
[0109] In this embodiment, the version comparison module 13 is used to compare each response data correspondingly according to the test request to obtain the version comparison result between the new version freight rate search system and the old version freight rate search system.
[0110] In this embodiment, the test request generation module 11 is specifically used to add travel information to the test request template to generate a test request according to the preset user type and / or preset scenario requirements; determine a specific user group according to the preset user type, extract request information corresponding to the specific user group from historical requests, and generate a test request; determine scenario keywords according to the preset scenario, filter request information corresponding to the scenario keywords from historical requests, and generate a test request.
[0111] In this embodiment, the test request generation module 11 is also used to deduplicate the historical operation data according to the route data in the historical operation data before generating the test request based on the historical operation data; after generating the test request, check the validity of each test request according to preset business rules to determine the valid test request.
[0112] In this embodiment, the test request generation module 11 is specifically used to determine the user distribution ratio of each type of historical user group based on historical user data; determine the route distribution ratio of each historical route based on historical route data; when generating a test request, make the user distribution and route distribution of each test request conform to the user distribution ratio and route distribution ratio.
[0113] In this embodiment, the request sending module 12 is specifically used to create multiple processes to input each test request into the new version freight rate search system and the old version freight rate search system respectively; receive the response data fed back by the new version freight rate search system and the old version freight rate search system respectively, and store them in the corresponding databases respectively.
[0114] In this embodiment, the version comparison module 13 is specifically used to use the response data fed back by the new version freight rate search system as the new version response data; use the response data fed back by the old version freight rate search system as the old version response data; for each test request, match the primary keys of the new version response data and the old version response data corresponding to the same test request; determine whether the primary keys match, if not, add marks to the new version response data and / or the old version response data; if they match, perform a difference comparison on the data except the primary keys in the new version response data and the old version response data, and generate a difference comparison result of the test request; the primary key is the data of a preset category in the new version response data and the old version response data; based on the difference comparison results corresponding to each test request and the number of marks of the new version response data and / or the old version response data, calculate the difference result between the new version freight rate search system and the old version freight rate search system as the version comparison result.
[0115] In this embodiment, the test request generation module 11 is also used to obtain the departure date and sales date of each historical request in the source data; calculate the relative date deviation based on the deviation between the departure date and the sales date of each historical request; and correct the departure date of each historical request in the source data based on the current system date and the relative date deviation.
[0116] like Figure 7 As shown, an embodiment of the present invention provides an electronic device, including a processor 1110, a communication interface 1120, a memory 1130 and a communication bus 1140, wherein the processor 1110, the communication interface 1120, and the memory 1130 communicate with each other through the communication bus 1140;
[0117] Memory 1130, used for storing computer programs;
[0118] The processor 1110 is used to implement any of the above-mentioned version comparison methods when executing the program stored in the memory 1130.
[0119] In the electronic device provided by the embodiment of the present invention, the processor 1110 obtains user information by executing the program stored in the memory 1130, and processes the source data based on the preset user type and / or the preset scenario to generate multiple test requests for reflecting the usage preference requirements of different user groups and / or the preset scenario test requirements; and when generating the test requests, the distribution ratio of the test requests is adjusted according to the distribution of historical data; each test request is input into the new version freight rate search system and the old version freight rate search system respectively, and the feedback response data is obtained respectively; each response data is compared according to the test request to obtain the version comparison result of the new version freight rate search system and the old version freight rate search system.
[0120] The communication bus 1140 mentioned in the above electronic device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus 1140 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.
[0121] The communication interface 1120 is used for communication between the above electronic device and other devices.
[0122] The memory 1130 may include a random access memory 1130 (RAM), or may include a non-volatile memory 1130 (non-volatile memory), such as at least one disk memory 1130. Optionally, the memory 1130 may also be at least one storage device located away from the processor 1110.
[0123] The above-mentioned processor 1110 can be a general-purpose processor 1110, including a central processing unit 1110 (CPU), a network processor 1110 (NP), etc.; it can also be a digital signal processor 1110 (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components.
[0124] An embodiment of the present invention provides a computer-readable storage medium, which stores one or more programs. The one or more programs can be executed by one or more processors 1110 to implement the version comparison method of any of the above embodiments.
[0125] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or a data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk SolidStateDisk (SSD)), etc.
[0126] Although the present disclosure has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure.
Claims
1. A version comparison method for a freight rate search system, characterized in that: The method comprises: Processing the source data based on preset user types and / or preset scenarios to generate multiple test requests for reflecting usage preference requirements of different user groups and / or preset scenario testing requirements; and when generating the test requests, adjusting the distribution ratio of the test requests according to the distribution of historical data; Input each of the test requests into the new version freight rate search system and the old version freight rate search system respectively, and obtain feedback response data respectively; The response data are compared accordingly according to the test request to obtain a version comparison result between the new version freight rate search system and the old version freight rate search system.
2. The version comparison method according to claim 1, characterized in that: The source data is processed based on preset user types and / or preset scenarios to generate multiple test requests for reflecting the usage preference requirements of different user groups and / or preset scenario testing requirements, including: According to a preset user type and / or preset scenario requirement, adding travel information to a test request template to generate the test request; Determine a specific user group according to the preset user type, extract request information corresponding to the specific user group from historical requests, and generate the test request; A scenario keyword is determined according to the preset scenario, request information corresponding to the scenario keyword is filtered from historical requests, and the test request is generated.
3. The version comparison method according to claim 2, characterized in that: The method further comprises: Before generating the test request based on the historical operation data, deduplication of the historical operation data is performed according to the route data in the historical operation data according to the duplication of the route data; After the test requests are generated, the validity of each of the test requests is checked according to preset business rules to determine the valid test requests.
4. The version comparison method according to claim 1, characterized in that: When generating the test request, adjusting the distribution ratio of the test request according to the distribution of historical data includes: Determine the user distribution ratio of each type of historical user group based on historical user data; Determine the route distribution ratio of each historical route based on historical route data; When generating the test request, the user distribution and route distribution of each of the test requests are made to conform to the user distribution ratio and the route distribution ratio.
5. The version comparison method according to claim 1, characterized in that: The test requests are input into the new version freight rate search system and the old version freight rate search system respectively, and the response data fed back are obtained respectively, including: Creating multiple processes to input each of the test requests into the new version freight rate search system and the old version freight rate search system respectively; Receive response data fed back by the new version freight rate search system and the old version freight rate search system respectively, and store them in corresponding databases respectively.
6. The version comparison method according to claim 1, characterized in that: The step of comparing the response data accordingly according to the test request to obtain a version comparison result between the new version of the freight rate search system and the old version of the freight rate search system includes: Using the response data fed back by the new version freight rate search system as new version response data; Using the response data fed back by the old version freight rate search system as the old version response data; For each of the test requests, the primary keys of the new version response data and the old version response data corresponding to the same test request are matched; whether the primary keys match is determined, and if not, a mark is added to the new version response data and / or the old version response data; if they match, a difference comparison is performed on the data in the new version response data and the old version response data except the primary keys, and a difference comparison result of the test request is generated; the primary keys are data of a preset category in the new version response data and the old version response data; Based on the difference comparison results corresponding to each of the test requests and the number of marks of the new version response data and / or the old version response data, the difference results between the new version freight rate search system and the old version freight rate search system are calculated as the version comparison result.
7. The version comparison method according to any one of claims 1 to 6, characterized in that: The method further comprises: Obtaining the departure date and the sales date of each historical request in the source data; Calculating a relative date deviation based on the deviation between the departure date and the sales date of each of the historical requests; The departure date of each historical request in the source data is corrected according to the current system date and the relative date deviation.
8. A version comparison system for a freight rate search system, characterized in that: The system comprises: A test request generation module is used to process source data based on preset user types and / or preset scenarios to generate multiple test requests that reflect usage preference requirements of different user groups and / or preset scenario test requirements; and when generating the test requests, adjust the distribution ratio of the test requests according to the distribution of historical data; A request sending module, used to input each of the test requests into the new version freight rate search system and the old version freight rate search system respectively, and obtain feedback response data respectively; The version comparison module is used to compare each response data according to the test request to obtain the version comparison result between the new version freight rate search system and the old version freight rate search system.
9. An electronic device, characterized in that: include: processor; as well as A memory storing computer executable instructions which, when executed, cause the processor to perform the method according to any one of claims 1-7.
10. A computer storage medium, characterized in that: in, The computer storage medium stores one or more programs, and when the one or more programs are executed by a processor, the method of any one of claims 1 to 7 is implemented.
Citation Information
Cited By
Multi-process parallel accelerator cluster protocol calculation verification method and device
CN121542116A