Test case generation method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a test case generation method and device, electronic equipment and a storage medium, and relates to the technical field of data processing, and the specific implementation scheme is as follows: determining a reference request proportion based on an obtained first request proportion; based on the obtained second request proportion, adjusting the proportion of the request quantity of each service in the reference request proportion to obtain an adjusted request proportion; based on the adjustment request proportion and the reference request total amount, obtaining the number of test requests for each service in the transaction platform; predicting the total prediction request amount and the prediction request proportion of the transaction platform in the test time; based on the total predicted request quantity and the predicted request proportion, obtaining the remaining request quantity for each service in the transaction platform; and based on the number of test requests and the number of remaining requests for each service in the transaction platform, generating a test case for performing a pressure test on the transaction platform. By applying the scheme provided by the embodiment of the invention, the accuracy of the generated test case can be improved.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a test case generation method, device, electronic equipment and storage medium. Background Art

[0002] As more and more users use the services provided by the trading platform, the trading platform needs to respond to a large number of requests from users for different services. However, the trading platform responding to a large number of requests will reduce the stability of the trading platform and affect the user experience. Therefore, it is necessary to perform stress testing on the trading platform. During the stress test, requests for different services will be simulated to the trading platform. The performance of the trading platform can be evaluated based on the test results of the stress test, and then the performance of the trading platform can be improved to improve the user experience. Setting the ratio of the number of requests for each service sent to the trading platform during the stress test is very important for the accuracy of the stress test. The more accurate the ratio of the number of requests for each service, the more accurate the test results obtained by the stress test, and the better the performance of the trading platform can be improved based on the test results.

[0003] In the prior art, an empirical estimation method is used to set the ratio of the number of requests for each service sent to the trading platform for simulation, resulting in low accuracy of the test cases used in the stress test. Summary of the invention

[0004] The purpose of the embodiments of the present invention is to provide a test case generation method, device, electronic device and storage medium to improve the accuracy of the generated test cases. The specific technical solution is as follows:

[0005] According to an aspect of an embodiment of the present invention, a test case generation method is provided, the method comprising:

[0006] Obtaining a first request ratio and a second request ratio, wherein the first request ratio is: a ratio of the number of requests for each service in the trading platform in a first historical time period before a test time, and the second request ratio is: a ratio of the number of requests for each service in the trading platform in a second historical time period before the test time, wherein the earliest time point in the second historical time period is later than the earliest time point in the first historical time period, and the second historical time period is shorter than the first historical time period;

[0007] Determining a base request ratio based on the first request ratio;

[0008] Based on the second request ratio, adjusting the ratio of the number of requests for each service in the base request ratio to obtain an adjusted request ratio;

[0009] Based on the adjusted request ratio and the reference total request amount, obtaining the number of test requests for each service in the trading platform, wherein the reference total request amount is the total request amount obtained based on the number of requests for each service in the trading platform in the first historical time period;

[0010] Predicting the total predicted request amount and predicted request ratio of the trading platform during the test time, wherein the predicted request ratio is: the predicted ratio of the number of requests for each service in the trading platform;

[0011] Based on the predicted total number of requests and the predicted request ratio, obtaining the number of surplus requests for each service in the trading platform;

[0012] Based on the number of test requests and the number of margin requests for each service in the trading platform, a test case for stress testing the trading platform is generated.

[0013] In one embodiment of the present invention, obtaining the first request ratio and the second request ratio includes:

[0014] For a test phase to which the trading platform belongs, obtaining a first request ratio and a second request ratio corresponding to the test phase, wherein the test phase is at least one of the following phases: a use phase, a system update phase, and a system online phase;

[0015] The generating of a test case for stress testing the trading platform based on the number of test requests and the number of margin requests for each service in the trading platform comprises:

[0016] Based on the number of test requests and the number of margin requests for each service in the trading platform corresponding to the test phase, a test case for stress testing the trading platform in the test phase is generated.

[0017] In one embodiment of the present invention, adjusting the ratio of the number of requests for each service in the benchmark request ratio based on the second request ratio to obtain the adjusted request ratio includes:

[0018] Based on the second request ratio, determining an adjustment reference ratio;

[0019] For each service, calculate the first difference between the adjustment reference ratio corresponding to the service and the benchmark request ratio, and adjust the ratio value corresponding to the service in the benchmark request ratio according to the first difference and the preset adjustment coefficient to obtain the adjustment request ratio.

[0020] In one embodiment of the present invention, the total amount of predicted requests is obtained in the following manner:

[0021] The first time series data is input into a pre-trained request total amount prediction model to obtain the predicted request total amount at the test time output by the request total amount prediction model, wherein the first time series data includes: the request total amount data corresponding to each trading day in a third historical time period before the test time, and the earliest time point in the third historical time period is later than the earliest time point in the second historical time period.

[0022] In one embodiment of the present invention, the total request amount prediction model is trained in the following manner:

[0023] The total number of requests for each service in the trading platform corresponding to each trading day in the fourth historical time period in the historical request database is used as sample time series data, and the sample time series data is input into the request total number prediction model to be trained to obtain the prediction result output by the request total number prediction model to be trained;

[0024] Calculating model loss based on the prediction result and the true prediction value corresponding to the sample time series data;

[0025] Based on the model loss, the data smoothing factor, trend smoothing factor and seasonal smoothing factor corresponding to the total request volume prediction model to be trained are adjusted until the model converges to obtain a trained total request volume prediction model, wherein the data smoothing factor is an adjustment parameter for the magnitude of the input time series data, the trend smoothing factor is an adjustment parameter for the data change trend in the input time series data, and the seasonal smoothing factor is an adjustment parameter for the seasonal data change in the input time series data.

[0026] In one embodiment of the present invention, before inputting the first time series data into a pre-trained request total amount prediction model to obtain the predicted request total amount at the test time output by the request total amount prediction model, the method further includes:

[0027] If the request data in the historical request database meets the model update condition, a first request total amount prediction model is trained based on the request data in the historical request database, and the pre-trained request total amount prediction model is updated to the first request total amount prediction model.

[0028] According to another aspect of an embodiment of the present invention, a test case generating device is provided, the device comprising:

[0029] A request ratio obtaining module, used to obtain a first request ratio and a second request ratio, wherein the first request ratio is: the ratio of the number of requests for each service in the trading platform in a first historical time period before the test time, and the second request ratio is: the ratio of the number of requests for each service in the trading platform in a second historical time period before the test time, the earliest time point in the second historical time period is later than the earliest time point in the first historical time period, and the second historical time period is shorter than the first historical time period;

[0030] A request ratio determination module, configured to determine a base request ratio based on the first request ratio;

[0031] A request ratio adjustment module, configured to adjust the ratio of the number of requests for each service in the base request ratio based on the second request ratio to obtain an adjusted request ratio;

[0032] a test request quantity obtaining module, configured to obtain the number of test requests for each service in the trading platform based on the adjustment request ratio and the total reference request amount, wherein the total reference request amount is the total request amount obtained based on the number of requests for each service in the trading platform in the first historical time period;

[0033] A prediction data acquisition module, used to predict the total predicted request amount and predicted request ratio of the trading platform during the test time, wherein the predicted request ratio is: the predicted ratio of the number of requests for each service in the trading platform;

[0034] A surplus request quantity obtaining module, used for obtaining the surplus request quantity for each service in the trading platform based on the predicted total request quantity and the predicted request ratio;

[0035] The test case generation module is used to generate a test case for stress testing the trading platform based on the number of test requests and the number of margin requests for each service in the trading platform.

[0036] In one embodiment of the present invention, the request ratio acquisition module is specifically used to obtain a first request ratio and a second request ratio corresponding to the test phase to which the trading platform belongs, wherein the test phase is at least one of the following phases: a usage phase, a system update phase, and a system online phase; the test case generation module is specifically used to generate a test case for stress testing the trading platform in the test phase based on the number of test requests and the number of balance requests for each service in the trading platform corresponding to the test phase.

[0037] In one embodiment of the present invention, the request ratio adjustment module is specifically used to determine the adjustment reference ratio based on the second request ratio; for each service, calculate the first difference between the adjustment reference ratio corresponding to the service and the benchmark request ratio, and adjust the ratio value corresponding to the service in the benchmark request ratio according to the first difference and a preset adjustment coefficient to obtain the adjusted request ratio.

[0038] In one embodiment of the present invention, the prediction data acquisition module obtains the predicted total request volume in the following manner: inputting first time series data into a pre-trained request volume prediction model to obtain the predicted total request volume at the test time output by the request volume prediction model, wherein the first time series data includes: the request volume data corresponding to each trading day in a third historical time period before the test time, the earliest time point in the third historical time period being later than the earliest time point in the second historical time period.

[0039] In one embodiment of the present invention, the total request volume prediction model is trained in the following manner: the total request volume for each service in the trading platform corresponding to each trading day in the fourth historical time period in the historical request database is used as sample time series data, and the sample time series data is input into the total request volume prediction model to be trained to obtain the prediction result output by the total request volume prediction model to be trained; based on the prediction result and the true prediction value corresponding to the sample time series data, the model loss is calculated; based on the model loss, the data smoothing factor, trend smoothing factor and seasonal smoothing factor corresponding to the total request volume prediction model to be trained are adjusted until the model converges to obtain a trained total request volume prediction model, wherein the data smoothing factor is an adjustment parameter for the magnitude of the input time series data, the trend smoothing factor is an adjustment parameter for the data change trend in the input time series data, and the seasonal smoothing factor is an adjustment parameter for the seasonal data change in the input time series data.

[0040] In one embodiment of the present invention, the device also includes: a model updating module, which is used to train a first request total amount prediction model based on the request data in the historical request database when the request data in the historical request database meets the model updating conditions, and update the pre-trained request total amount prediction model to the first request total amount prediction model.

[0041] According to another aspect of an embodiment of the present invention, there is provided an electronic device, comprising a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus;

[0042] Memory, used to store computer programs;

[0043] The processor is used to implement any of the above-mentioned test case generation methods when executing the program stored in the memory.

[0044] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, any of the above-mentioned test case generation methods is implemented.

[0045] According to another aspect of an embodiment of the present invention, there is provided a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute any of the above-mentioned test case generating methods.

[0046] Beneficial effects of the embodiments of the present invention:

[0047] From the above, it can be seen that in the process of generating test cases, the first request ratio of an earlier and longer historical time period is used as the benchmark request ratio, and the benchmark request ratio is adjusted using the second request ratio of a historical time period closer to the test time. This can make the benchmark request ratio more in line with recent service request changes and improve the accuracy of the benchmark request ratio. Then, the margin request number obtained based on the predicted total number of requests and the predicted request ratio is used to set the margin for the test request number to generate test cases, thereby further improving the accuracy of the generated test cases.

[0048] Of course, it is not necessary to achieve all of the advantages described above at the same time to implement any product or method of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the embodiments of the present invention 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 in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other embodiments can also be obtained based on these drawings.

[0050] Figure 1 A flow chart of a test case generation method provided by an embodiment of the present invention;

[0051] Figure 2 A flowchart of another test case generation method provided by an embodiment of the present invention;

[0052] Figure 3 A schematic diagram of the structure of a test case generation device provided by an embodiment of the present invention;

[0053] Figure 4 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0054] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field based on the present invention belong to the scope of protection of the present invention.

[0055] The following is a description of the execution subject of the embodiment of the present invention.

[0056] The solution provided by the embodiment of the present invention can be applied to electronic devices such as desktop computers, laptops, tablet computers, and smart phones, and can also be applied to a stress testing platform for stress testing a trading platform, that is, the stress testing platform generates test cases, and stress tests the trading platform based on the generated test cases. For ease of description, the execution subject of the test case generation method provided by the embodiment of the present invention is collectively referred to as a test case generation platform.

[0057] The test case generation method provided by the embodiment of the present invention is described in detail below.

[0058] In one embodiment of the present application, see Figure 1 A flow chart of a test case generation method is provided, the method comprising the following steps S101-S107.

[0059] Step S101: Obtain a first request ratio and a second request ratio.

[0060] Among them, the first request ratio is: the ratio of the number of requests for each service in the trading platform in the first historical time period before the test time, and the second request ratio is: the ratio of the number of requests for each service in the trading platform in the second historical time period before the test time.

[0061] The trading platform can provide users with various services. For example, the services may include multiple types, such as: fund trading services, stock trading services, bond trading services, weekly report query services, risk assessment services, knowledge consulting services, account information query services, account registration services, password modification services, etc. The test time is the preset time for simulating the stress test of the trading platform. For example, if the current time is after the end of the tenth trading day and before the beginning of the eleventh trading day, then the test time can be set to the eleventh trading day, in which case the test time can include one trading day, or the test time can be set from the eleventh trading day to the fifteenth trading day, in which case the test time can include five trading days.

[0062] The earliest time point in the second historical time period is later than the earliest time point in the first historical time period, and the second historical time period is shorter than the first historical time period. For example, if the test time is trading day A, then the first historical time period may include trading days within the month before trading day A, and the second historical time period may include the ten trading days before trading day A.

[0063] The following describes a method for obtaining the first request ratio and the second request ratio.

[0064] A historical request database can be pre-built. For each trading day in the historical time period, the historical request database records the total number of requests for each service on that trading day. For each service type on each trading day, the historical request database records the number of requests for that service type on that trading day.

[0065] In one implementation, the test case generation platform can obtain the first request ratio and the second request ratio from the historical request database. Specifically, the test case generation platform searches the historical request database for the number of requests and the total number of requests for each service type whose transaction day information belongs to the first historical time period based on the number of requests for each service type recorded and the corresponding transaction day information, and calculates the ratio between the number of requests for each service type on the transaction day for each transaction day, thereby obtaining the first request ratio. Search the historical request database for the number of requests and the total number of requests for each service type whose transaction day information belongs to the second historical time period, and calculates the ratio between the number of requests for each service type on the transaction day for each transaction day, thereby obtaining the second request ratio.

[0066] The method for obtaining the historical request data in the historical request database is described in the following embodiments and will not be described in detail here.

[0067] Step S102: Determine a reference request ratio based on the first request ratio.

[0068] Specifically, the test case generation platform calculates the proportion value corresponding to the service type in the benchmark request ratio according to the proportion value of the number of requests for each service type on each trading day in the first request ratio.

[0069] In one implementation, for each service type in the first request ratio, the test case generation platform calculates the average value of the ratio of the number of requests for that service type in the first historical time period, and obtains the average value of the ratio of the number of requests for each service type as the benchmark request ratio.

[0070] For example, if the first request ratio includes: the ratio of the number of requests for service A, service B and service C on trading day 1 is 0.2:0.5:0.3, and the ratio of the number of requests for service A, service B and service C on trading day 2 is 0.3:0.6:0.1, then the ratio of the number of requests for service B on trading day 1 is 0.5, and the ratio of the number of requests for service B on trading day 2 is 0.6. If the first historical time period only includes trading day 1 and trading day 2, the average value of the ratio of the number of requests for service B in the first historical time period is (0.5+0.6) / 2=0.55. Similarly, the average value of the ratio of the number of requests for service A in the first historical time period is calculated to be 0.25, and the average value of the ratio of the number of requests for service C is 0.2. The obtained benchmark request ratio includes: the ratio of service A, service B and service C is 0.25:0.55:0.2.

[0071] In another implementation, for each service type in the first request ratio, the test case generation platform obtains the preset percentile value of the ratio of the number of requests for that service type in the first historical time period, and uses the preset percentile value of the ratio of the number of requests for each service type as the benchmark request ratio.

[0072] In another implementation, for each service type in the first request ratio, the test case generation platform obtains the value of the mode of the ratio values ​​of the number of requests for that service type in the first historical time period, and uses the value of the mode of the ratio values ​​of the number of requests for each service type as the benchmark request ratio.

[0073] Step S103: Based on the second request ratio, the ratio of the number of requests for each service in the base request ratio is adjusted to obtain an adjusted request ratio.

[0074] In one implementation, an adjustment reference ratio is determined based on the second request ratio. For each service, a first difference between the adjustment reference ratio corresponding to the service and the base request ratio is calculated, and according to the first difference and a preset adjustment coefficient, a ratio value corresponding to the service in the base request ratio is adjusted to obtain an adjustment request ratio.

[0075] The following is an explanation of the method for determining the adjustment reference ratio.

[0076] The test case generation platform calculates the proportion value corresponding to the service type in the adjustment reference ratio based on the proportion value of the request quantity of each service type on each trading day in the second historical time period in the second request ratio, and obtains the adjustment request ratio.

[0077] The implementation method of calculating the ratio value corresponding to each service type in the adjustment reference ratio is similar to the specific implementation method of step S102, and the only difference is the name, which will not be described in detail here.

[0078] The following is an example of how to adjust the ratio value corresponding to the service in the baseline request ratio.

[0079] For example, taking the adjustment coefficient as 0.15, for each service, the proportion value corresponding to the service in the benchmark request proportion can be adjusted according to the following expression:

[0080] a′=a+0.15×(ba);

[0081] Among them, a′ is the proportion value corresponding to the service in the adjustment request ratio, a is the proportion value corresponding to the service in the benchmark request ratio, and b is the proportion value corresponding to the service in the adjustment reference ratio.

[0082] In this way, the benchmark request ratio can be adjusted more accurately according to the first difference and the preset adjustment coefficient, and thus the test cases can be generated more accurately, thereby improving the accuracy of the generated test cases.

[0083] Another implementation of obtaining the adjustment request ratio in step S103 is described below.

[0084] For each service, calculate the second difference between the ratio value of each trading day in the second request ratio corresponding to the service and the ratio value of the benchmark request ratio, and adjust the ratio value of the benchmark request ratio of the service based on the second differences of the service.

[0085] The following describes a method for adjusting the ratio value of the reference request ratio based on each second difference value.

[0086] In one method, a second reference value may be calculated based on each second difference, and then the sum of the ratio value of the benchmark request corresponding to the service and the second reference value is calculated as the ratio value corresponding to the service in the adjustment request ratio. The second reference value may be calculated in at least one of the following ways: calculating the average value of each second difference, calculating the mode of each second difference, calculating the value of a preset percentile in each second difference, and calculating the median of each second difference.

[0087] Step S104: Based on the adjustment request ratio and the total reference request amount, the number of test requests for each service in the trading platform is obtained.

[0088] The reference total request amount is the total request amount obtained based on the number of requests for each service in the trading platform in the first historical time period. For example, for each service, the average number of requests for the service in the first historical time period can be calculated as the total request amount corresponding to the service, and the total request amount corresponding to each service can be obtained as the reference total request amount.

[0089] Specifically, the test case generation platform can calculate, for each service, the ratio of the service request quantity to the sum of the ratios of all services in the adjusted request ratio, and calculate the product of the service request quantity ratio and the total number of reference requests as the test request quantity for the service.

[0090] For example, if the ratio of service A, service B and service C in the request ratio is adjusted to 0.3:0.7:0.5, then the proportion of service A to the sum of the proportions of each service is: 0.3 / (0.3+0.7+0.5)=20%, and the number of test requests for service A = 20% × the total number of reference requests.

[0091] Step S105: predicting the total number of prediction requests and the proportion of prediction requests on the trading platform during the test period.

[0092] The predicted request ratio is: the predicted ratio of the number of requests for each service in the trading platform.

[0093] The method of predicting the total number of predicted requests and the predicted request ratio is described in the following embodiments and will not be described in detail here.

[0094] Step S106: Based on the predicted total number of requests and the predicted request ratio, the number of surplus requests for each service in the trading platform is obtained.

[0095] Specifically, the test case generation platform can calculate, for each service, the predicted request ratio corresponding to the service relative to the sum of the predicted request ratios of all services, and calculate the product of the predicted request ratio and the total predicted request quantity as the remaining request quantity for the service.

[0096] For example, if the ratio of service A, service B and service C in the predicted request ratio is 0.2:0.9:0.5, the proportion value of service C to the sum of the proportion values ​​corresponding to each service is: 0.2 / (0.2+0.9+0.5)=12.5%, then the number of remaining requests for service A = 12.5%×the total number of predicted requests.

[0097] Step S107: Based on the number of test requests and the number of margin requests for each service in the trading platform, a test case for stress testing the trading platform is generated.

[0098] In one implementation, for each service, the test case generation platform adds the number of test requests and the number of surplus requests for the service to obtain the number of requests corresponding to the service in the test case, and obtains the number of requests corresponding to each service in the test case.

[0099] In another implementation, the margin coefficient corresponding to each service can be pre-set. For each service, the test case generation platform calculates the product of the margin coefficient corresponding to the service and the number of margin requests, and uses the sum of the above product and the number of test requests for the service as the number of requests corresponding to the service in the test case, thereby obtaining the number of requests corresponding to each service in the test case.

[0100] From the above, it can be seen that in the process of generating test cases, the first request ratio of an earlier and longer historical time period is used as the benchmark request ratio, and the benchmark request ratio is adjusted using the second request ratio of a historical time period closer to the test time. This can make the benchmark request ratio more in line with recent service request changes and improve the accuracy of the benchmark request ratio. Then, the margin request number obtained based on the predicted total number of requests and the predicted request ratio is used to set the margin for the test request number to generate test cases, thereby further improving the accuracy of the generated test cases.

[0101] In this way, in the process of generating test cases, data from earlier and longer historical time periods, data from historical time periods closer to the test time, and predicted data are considered. Considering these three different time dimensions of data can fully utilize data resources to dynamically generate test cases and improve the accuracy of test cases. The professionalism and reliability of stress tests using the above test cases are improved, and the test results obtained based on stress tests can more accurately evaluate the performance of the trading platform, thereby better improving the performance of the trading platform.

[0102] In another embodiment of the present application, see Figure 2 A flowchart of another test case generation method is provided, the method comprising the following steps S201-S207.

[0103] Step S201: for the test phase to which the trading platform belongs, obtain a first request ratio and a second request ratio corresponding to the test phase.

[0104] The testing phase includes at least one of the following phases: a usage phase, a system update phase, and a system launch phase.

[0105] Specifically, in the historical request database, for each request data, the test phase corresponding to the request data may be recorded, and when obtaining the first request ratio and the second request ratio, the test case generation platform may obtain the first request ratio and the second request ratio corresponding to the test phase according to the test phase corresponding to the request data. For example, if the test phase to which the trading platform belongs is the use phase, the request data belonging to the use phase may be obtained, and then the first request ratio and the second request ratio of the use phase may be obtained based on the request data belonging to the use phase.

[0106] If it is necessary to obtain test cases corresponding to multiple test stages, the first request ratio and the second request ratio corresponding to each test stage can be obtained respectively, and then the following steps S202-S207 are performed for the first request ratio and the second request ratio corresponding to the test stage until the test cases corresponding to each test stage are obtained.

[0107] Specifically, the method of obtaining the first request ratio and the second request ratio can refer to the description in step S101, which will not be described in detail here.

[0108] Step S202: Determine a base request ratio based on the first request ratio.

[0109] Step S203: Based on the second request ratio, the ratio of the number of requests for each service in the base request ratio is adjusted to obtain an adjusted request ratio.

[0110] Step S204: Based on the adjustment request ratio and the total reference request amount, the number of test requests for each service in the trading platform is obtained.

[0111] Step S205: predicting the total number of prediction requests and the proportion of prediction requests on the trading platform during the test period.

[0112] Step S206: Based on the predicted total number of requests and the predicted request ratio, the number of surplus requests for each service in the trading platform is obtained.

[0113] The implementation of steps S202-S206 may refer to the implementation of steps S102-S106 described above, and will not be described in detail here.

[0114] Step S207: Based on the number of test requests and the number of surplus requests for each service in the trading platform corresponding to the test phase, a test case for stress testing the trading platform in the test phase is generated.

[0115] The implementation of step S207 is similar to that of step S107, except that the test generated in step S207 is a test case corresponding to the test phase.

[0116] From the above, it can be seen that for different test phases, the data corresponding to the test phase can be used to generate test cases corresponding to multiple test phases. When performing stress testing, the corresponding test cases can be used to perform stress testing according to the test phase to which the trading platform to be tested belongs. In this way, the stress test can be made more in line with the situation of the trading platform and the accuracy of the stress test can be improved.

[0117] The following describes how to obtain the total number of prediction requests.

[0118] In one embodiment of the present application, the first time series data is input into a pre-trained request total amount prediction model to obtain the predicted request total amount at the test time output by the request total amount prediction model.

[0119] The first time series data includes: total request volume data corresponding to each trading day in a third historical time period before the test time, and the earliest time point in the third historical time period is later than the earliest time point in the second historical time period.

[0120] For example, the third historical time period may include trading days within two years before the test time. In this way, the first time series data may be constructed according to the total request volume data corresponding to each trading day within two years before the test time in order from early to late.

[0121] In this way, using the total request amount prediction model can obtain a more accurate predicted total request amount, and then can obtain a more accurate number of surplus requests, thereby improving the accuracy of the generated test cases.

[0122] In another embodiment of the present application, the above-mentioned total request amount prediction model can be trained according to the following steps A-C:

[0123] Step A: The total number of requests for each service in the trading platform corresponding to each trading day in the fourth historical time period in the historical request database is used as sample time series data, and the sample time series data is input into the total number of requests prediction model to be trained to obtain the prediction result output by the total number of requests prediction model to be trained.

[0124] The total request amount prediction model may be a Holt-Winters model (triple exponential smoothing model). The fourth historical time period may include: randomly selecting trading days in a time period of a preset length from a historical database, such as a time period of a preset length of two years. The total request amount prediction model may predict the predicted total request amount corresponding to the next trading day after the latest trading day in the fourth historical time period based on the sample time series data corresponding to the fourth historical time period.

[0125] Step B: Calculate the model loss based on the predicted results and the true predicted values ​​corresponding to the sample time series data.

[0126] The actual prediction value may be the total number of requests corresponding to the next trading day after the latest trading day in the fourth historical time period in the historical database.

[0127] In one implementation, the least squares method may be used to construct a loss function, and based on the loss function, the loss between the predicted result and the true predicted value may be calculated.

[0128] Step C: Based on the model loss, adjust the data smoothing factor, trend smoothing factor, and season smoothing factor corresponding to the total request volume prediction model to be trained until the model converges to obtain a trained total request volume prediction model.

[0129] Among them, the data smoothing factor is an adjustment parameter for the magnitude of the input time series data. By adjusting the data smoothing factor, the noise of the input time series data can be reduced. The trend smoothing factor is an adjustment parameter for the data change trend in the input time series data. By adjusting the trend smoothing factor, the accuracy of the model for the future change trend of the time series data can be improved. The seasonal smoothing factor is an adjustment parameter for the seasonal data changes in the input time series data. By adjusting the seasonal smoothing factor, the accuracy of the model in predicting the seasonal changes of the time series data can be improved.

[0130] After obtaining the model loss, the values ​​of the above three factors can be adjusted in the direction of reducing the model loss until the model converges. If the total request prediction model does not converge, the fourth historical time period can be updated, and the total requests for each service in the trading platform corresponding to each trading day in the updated fourth historical time period can be used as sample time series data, and then the above step A is performed. For example, the earliest trading day and the latest trading day of the original fourth historical time period can be adjusted to a later trading day.

[0131] From the above, it can be seen that adjustments are made to the magnitude, change trend and seasonal factors of the input time series data respectively. In this way, the total request amount prediction model can output more accurate results for test times in different time periods, which can improve the accuracy of the total request amount prediction model, and then obtain a more accurate number of surplus requests, thereby improving the accuracy of the generated test cases.

[0132] In another embodiment of the present application, when the total request amount prediction model is used to obtain the predicted total request amount, before step A, the following step D may also be performed.

[0133] Step D: If the request data in the historical request database meets the model update condition, a first request total amount prediction model is trained based on the request data in the historical request database, and the pre-trained request total amount prediction model is updated to the first request total amount prediction model.

[0134] The model update condition may be: the request data of a preset number of trading days that have not been used in the training process of the total request prediction model have been updated in the historical request database. For example, the preset number of trading days may be thirty trading days.

[0135] The method of obtaining the first request total amount prediction model based on the request data in the historical request database through training can refer to the above steps A to C. The only difference is the name, which will not be described in detail here.

[0136] In this way, the total request amount prediction model can be periodically updated using data updated in the historical request database, so that the total request amount prediction model can conform to the changes in the proportion of the number of requests of each service that is updated, thereby improving the accuracy of the total request amount prediction model, and then obtaining a more accurate number of surplus requests, thereby improving the accuracy of the generated test cases.

[0137] In another embodiment of the present application, the predicted request ratio is obtained in the following manner: the second time series data is input into a pre-trained request ratio prediction model to obtain the predicted request ratio of the test time output by the request ratio prediction model, wherein the second time series data includes: the request ratio corresponding to each trading day in the fifth historical time period before the test time, the earliest time point in the fifth historical time period being later than the earliest time point in the second historical time period.

[0138] The request ratio prediction model may be a vector autoregression model. The fifth historical time period may include: randomly selecting a preset number of consecutive trading days from the historical database, such as a preset number of trading days may be thirty trading days. The request total amount prediction model may predict the predicted request total amount corresponding to the next trading day after the latest trading day in the fifth historical time period based on the sample time series data corresponding to the fifth historical time period.

[0139] During the training process of the request ratio prediction model, the Bayesian information criterion can be used to determine the optimal model order of the request ratio prediction model. Then, based on the request data in the historical request database, a lag variable matrix can be constructed and the coefficient matrix and constant term of the request ratio prediction model can be solved using the least squares method. Then, the request ratio prediction model is calculated based on the model prediction results and the actual model loss. Based on the model loss, the model parameters of the request ratio prediction model are adjusted until the model converges to obtain a trained request ratio prediction model.

[0140] The following describes a method for obtaining request data in the historical request database.

[0141] In one embodiment of the present application, the service request data in the trading platform can be mirrored by a mirror switch to obtain the mirror request data. For different services, the data structure of the service request data is different. For each mirror request data, the service type to which the mirror request data belongs is determined according to the preset data segment, and the data decoding method corresponding to the service is used to obtain the parameters and parameter values ​​corresponding to each data segment in the mirror request data. After obtaining the parameters and parameter values ​​of each mirror request data, it can be determined whether the parameters and parameter values ​​of the request time and the service to which the request belongs of each mirror request data are missing. If there is a situation where the parameters or parameter values ​​are missing, the feedback data of the trading platform of the mirror request data can be obtained, and the mirror request data is repaired based on the content of the feedback data. If it is determined that the mirror request data cannot be repaired, the mirror request data is not used and recorded. If there is no situation where the parameters or parameter values ​​are missing or it is determined that the mirror request data can be repaired, the user privacy information related to the user in the mirror request data is deleted, and only the service type to which the mirror request data belongs and the request time of the mirror request data can be retained to obtain each request data. Furthermore, based on the obtained request data, the mirror request data is counted and classified by service type in a time window of minutes to obtain the number of requests corresponding to each service per minute, and the number of requests corresponding to each service in each trading day is recorded in the historical request database.

[0142] Corresponding to the above-mentioned test case generating method, an embodiment of the present invention further provides a test case generating device.

[0143] In one embodiment of the present application, see Figure 3 A schematic diagram of the structure of a test case generation device is provided, the device comprising:

[0144] The request ratio obtaining module 301 is used to obtain a first request ratio and a second request ratio, wherein the first request ratio is: the ratio of the number of requests for each service in the trading platform in a first historical time period before the test time, and the second request ratio is: the ratio of the number of requests for each service in the trading platform in a second historical time period before the test time, the earliest time point in the second historical time period is later than the earliest time point in the first historical time period, and the second historical time period is shorter than the first historical time period.

[0145] The request ratio determination module 302 is configured to determine a reference request ratio based on the first request ratio.

[0146] The request ratio adjustment module 303 is used to adjust the ratio of the number of requests for each service in the base request ratio based on the second request ratio to obtain an adjusted request ratio.

[0147] The test request quantity obtaining module 304 is used to obtain the number of test requests for each service in the trading platform based on the adjusted request ratio and the reference total number of requests, wherein the reference total number of requests is the total number of requests obtained based on the number of requests for each service in the trading platform in the first historical time period.

[0148] The prediction data acquisition module 305 is used to predict the total predicted request amount and predicted request ratio of the trading platform during the test time, wherein the predicted request ratio is: the predicted ratio of the number of requests for each service in the trading platform.

[0149] The surplus request quantity obtaining module 306 is used to obtain the surplus request quantity for each service in the trading platform based on the predicted total request quantity and the predicted request ratio.

[0150] The test case generation module 307 is used to generate a test case for stress testing the trading platform based on the number of test requests and the number of margin requests for each service in the trading platform.

[0151] From the above, it can be seen that in the process of generating test cases, the first request ratio of an earlier and longer historical time period is used as the benchmark request ratio, and the benchmark request ratio is adjusted using the second request ratio of a historical time period closer to the test time. This can make the benchmark request ratio more in line with recent service request changes and improve the accuracy of the benchmark request ratio. Then, the margin request number obtained based on the predicted total number of requests and the predicted request ratio is used to set the margin for the test request number to generate test cases, thereby further improving the accuracy of the generated test cases.

[0152] In one embodiment of the present invention, a request ratio acquisition module is specifically used to obtain a first request ratio and a second request ratio corresponding to a test phase to which a trading platform belongs, wherein the test phase is at least one of the following phases: a usage phase, a system update phase, and a system online phase; a test case generation module is specifically used to generate a test case for stress testing the trading platform in the test phase based on the number of test requests and the number of remaining requests for each service in the trading platform corresponding to the test phase.

[0153] From the above, it can be seen that for different test phases, the data corresponding to the test phase can be used to generate test cases corresponding to multiple test phases. When performing stress testing, the corresponding test cases can be used to perform stress testing according to the test phase to which the trading platform to be tested belongs. In this way, the stress test can be made more in line with the situation of the trading platform and the accuracy of the stress test can be improved.

[0154] In one embodiment of the present invention, the request ratio adjustment module is specifically used to determine the adjustment reference ratio based on the second request ratio; for each service, calculate the first difference between the adjustment reference ratio corresponding to the service and the benchmark request ratio, and adjust the ratio value corresponding to the service in the benchmark request ratio according to the first difference and a preset adjustment coefficient to obtain the adjustment request ratio.

[0155] In this way, the benchmark request ratio can be adjusted more accurately according to the first difference and the preset adjustment coefficient, and thus the test cases can be generated more accurately, thereby improving the accuracy of the generated test cases.

[0156] In one embodiment of the present invention, the prediction data acquisition module obtains the predicted total request volume in the following manner: inputting the first time series data into a pre-trained request volume prediction model to obtain the predicted total request volume at the test time output by the request volume prediction model, wherein the first time series data includes: the request volume data corresponding to each trading day in a third historical time period before the test time, the earliest time point in the third historical time period being later than the earliest time point in the second historical time period.

[0157] In this way, using the total request amount prediction model can obtain a more accurate predicted total request amount, and then can obtain a more accurate number of surplus requests, thereby improving the accuracy of the generated test cases.

[0158] In one embodiment of the present invention, the total request volume prediction model is trained in the following manner: the total request volume for each service in the trading platform corresponding to each trading day in the fourth historical time period in the historical request database is used as sample time series data, and the sample time series data is input into the total request volume prediction model to be trained to obtain the prediction result output by the total request volume prediction model to be trained; based on the prediction result and the true prediction value corresponding to the sample time series data, the model loss is calculated; based on the model loss, the data smoothing factor, trend smoothing factor and seasonal smoothing factor corresponding to the total request volume prediction model to be trained are adjusted until the model converges to obtain a trained total request volume prediction model, wherein the data smoothing factor is an adjustment parameter for the magnitude of the input time series data, the trend smoothing factor is an adjustment parameter for the data change trend in the input time series data, and the seasonal smoothing factor is an adjustment parameter for the seasonal data change in the input time series data.

[0159] From the above, it can be seen that adjustments are made to the magnitude, change trend and seasonal factors of the input time series data respectively. In this way, the total request amount prediction model can output more accurate results for test times in different time periods, which can improve the accuracy of the total request amount prediction model, and then obtain a more accurate number of surplus requests, thereby improving the accuracy of the generated test cases.

[0160] In one embodiment of the present invention, the above-mentioned device also includes: a model updating module, which is used to train a first request total amount prediction model based on the request data in the historical request database when the request data in the historical request database meets the model updating conditions, and update the pre-trained request total amount prediction model to the first request total amount prediction model.

[0161] In this way, the total request amount prediction model can be periodically updated using data updated in the historical request database, so that the total request amount prediction model can conform to the changes in the proportion of the number of requests of each service that is updated, thereby improving the accuracy of the total request amount prediction model, and then obtaining a more accurate number of surplus requests, thereby improving the accuracy of the generated test cases.

[0162] The embodiment of the present invention further provides an electronic device, such as Figure 4 As shown, it includes a processor 401 , a communication interface 402 , a memory 403 and a communication bus 404 , wherein the processor 401 , the communication interface 402 , and the memory 403 communicate with each other via the communication bus 404 .

[0163] Memory 403, used for storing computer programs;

[0164] The processor 401 is used to execute any of the test case generation methods described above when executing the program stored in the memory 403.

[0165] The communication bus 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 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.

[0166] The communication interface is used for communication between the above electronic device and other devices.

[0167] The memory may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0168] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0169] In another embodiment of the present invention, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned test case generation methods are implemented.

[0170] In another embodiment of the present invention, a computer program product including instructions is provided, which, when executed on a computer, enables the computer to execute any test case generating method in the above embodiments.

[0171] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by 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 described in 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, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). 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 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 Solid State Disk (SSD)), etc.

[0172] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0173] Each embodiment in this specification is described in a related manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device, electronic device, storage medium, and computer program product embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0174] The above description is only a preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims

1. A test case generation method, characterized in that: The method comprises: Obtaining a first request ratio and a second request ratio, wherein the first request ratio is: a ratio of the number of requests for each service in the trading platform in a first historical time period before a test time, and the second request ratio is: a ratio of the number of requests for each service in the trading platform in a second historical time period before the test time, wherein the earliest time point in the second historical time period is later than the earliest time point in the first historical time period, and the second historical time period is shorter than the first historical time period; Determining a base request ratio based on the first request ratio; Based on the second request ratio, adjusting the ratio of the number of requests for each service in the base request ratio to obtain an adjusted request ratio; Based on the adjusted request ratio and the reference total request amount, obtaining the number of test requests for each service in the trading platform, wherein the reference total request amount is the total request amount obtained based on the number of requests for each service in the trading platform in the first historical time period; Predicting the total predicted request amount and predicted request ratio of the trading platform during the test time, wherein the predicted request ratio is: the predicted ratio of the number of requests for each service in the trading platform; Based on the predicted total number of requests and the predicted request ratio, obtaining the number of surplus requests for each service in the trading platform; Based on the number of test requests and the number of margin requests for each service in the trading platform, a test case for stress testing the trading platform is generated.

2. The method according to claim 1, characterized in that The obtaining of the first request ratio and the second request ratio comprises: For a test phase to which the trading platform belongs, obtaining a first request ratio and a second request ratio corresponding to the test phase, wherein the test phase is at least one of the following phases: a use phase, a system update phase, and a system online phase; The generating of a test case for stress testing the trading platform based on the number of test requests and the number of margin requests for each service in the trading platform comprises: Based on the number of test requests and the number of margin requests for each service in the trading platform corresponding to the test phase, a test case for stress testing the trading platform in the test phase is generated.

3. The method according to claim 1, characterized in that: The adjusting, based on the second request ratio, the ratio of the number of requests for each service in the base request ratio to obtain the adjusted request ratio includes: Based on the second request ratio, determining an adjustment reference ratio; For each service, calculate the first difference between the adjustment reference ratio corresponding to the service and the benchmark request ratio, and adjust the ratio value corresponding to the service in the benchmark request ratio according to the first difference and the preset adjustment coefficient to obtain the adjustment request ratio.

4. The method according to any one of claims 1 to 3, characterized in that The total amount of prediction requests is obtained as follows: The first time series data is input into a pre-trained request total amount prediction model to obtain the predicted request total amount at the test time output by the request total amount prediction model, wherein the first time series data includes: the request total amount data corresponding to each trading day in a third historical time period before the test time, and the earliest time point in the third historical time period is later than the earliest time point in the second historical time period.

5. The method according to claim 4, characterized in that The total request amount prediction model is trained in the following way: The total number of requests for each service in the trading platform corresponding to each trading day in the fourth historical time period in the historical request database is used as sample time series data, and the sample time series data is input into the request total number prediction model to be trained to obtain the prediction result output by the request total number prediction model to be trained; Calculating model loss based on the prediction result and the true prediction value corresponding to the sample time series data; Based on the model loss, the data smoothing factor, trend smoothing factor and seasonal smoothing factor corresponding to the total request volume prediction model to be trained are adjusted until the model converges to obtain a trained total request volume prediction model, wherein the data smoothing factor is an adjustment parameter for the magnitude of the input time series data, the trend smoothing factor is an adjustment parameter for the data change trend in the input time series data, and the seasonal smoothing factor is an adjustment parameter for the seasonal data change in the input time series data.

6. The method according to claim 4, characterized in that Before inputting the first time series data into a pre-trained request total amount prediction model to obtain the predicted request total amount at the test time output by the request total amount prediction model, the method further includes: If the request data in the historical request database meets the model update condition, a first request total amount prediction model is trained based on the request data in the historical request database, and the pre-trained request total amount prediction model is updated to the first request total amount prediction model.

7. A test case generating device, characterized in that: The device comprises: A request ratio obtaining module, used to obtain a first request ratio and a second request ratio, wherein the first request ratio is: the ratio of the number of requests for each service in the trading platform in a first historical time period before the test time, and the second request ratio is: the ratio of the number of requests for each service in the trading platform in a second historical time period before the test time, the earliest time point in the second historical time period is later than the earliest time point in the first historical time period, and the second historical time period is shorter than the first historical time period; A request ratio determination module, configured to determine a base request ratio based on the first request ratio; A request ratio adjustment module, configured to adjust the ratio of the number of requests for each service in the base request ratio based on the second request ratio to obtain an adjusted request ratio; a test request quantity obtaining module, configured to obtain the number of test requests for each service in the trading platform based on the adjustment request ratio and the total reference request amount, wherein the total reference request amount is the total request amount obtained based on the number of requests for each service in the trading platform in the first historical time period; A prediction data acquisition module, used to predict the total predicted request amount and predicted request ratio of the trading platform during the test time, wherein the predicted request ratio is: the predicted ratio of the number of requests for each service in the trading platform; A surplus request quantity obtaining module, used for obtaining the surplus request quantity for each service in the trading platform based on the predicted total request quantity and the predicted request ratio; The test case generation module is used to generate a test case for stress testing the trading platform based on the number of test requests and the number of margin requests for each service in the trading platform.

8. The device according to claim 7, characterized in that The request ratio obtaining module is specifically used to obtain, for the test phase to which the trading platform belongs, a first request ratio and a second request ratio corresponding to the test phase, wherein the test phase is at least one of the following phases: a usage phase, a system update phase, and a system launch phase; the test case generating module is specifically used to generate a test case for stress testing the trading platform in the test phase based on the number of test requests and the number of surplus requests for each service in the trading platform corresponding to the test phase; and / or The request ratio adjustment module is specifically configured to determine an adjustment reference ratio based on the second request ratio; for each service, calculate a first difference between the adjustment reference ratio corresponding to the service and a benchmark request ratio, and adjust a ratio value corresponding to the service in the benchmark request ratio according to the first difference and a preset adjustment coefficient to obtain an adjustment request ratio; and / or The predicted data acquisition module obtains the predicted total request volume in the following manner: inputting the first time series data into a pre-trained total request volume prediction model to obtain the predicted total request volume at the test time output by the total request volume prediction model, wherein the first time series data includes: total request volume data corresponding to each trading day in a third historical time period before the test time, the earliest time point in the third historical time period being later than the earliest time point in the second historical time period; and / or The total request volume prediction model is trained in the following manner: the total request volume for each service in the trading platform corresponding to each trading day in the fourth historical time period in the historical request database is used as sample time series data, and the sample time series data is input into the total request volume prediction model to be trained to obtain the prediction result output by the total request volume prediction model to be trained; based on the prediction result and the true prediction value corresponding to the sample time series data, the model loss is calculated; based on the model loss, the data smoothing factor, trend smoothing factor and seasonal smoothing factor corresponding to the total request volume prediction model to be trained are adjusted until the model converges to obtain a trained total request volume prediction model, wherein the data smoothing factor is an adjustment parameter for the magnitude of the input time series data, the trend smoothing factor is an adjustment parameter for the data change trend in the input time series data, and the seasonal smoothing factor is an adjustment parameter for the seasonal data change in the input time series data; and / or The device also includes: a model updating module, which is used to train a first request total amount prediction model based on the request data in the historical request database when the request data in the historical request database meets the model updating condition, and update the pre-trained request total amount prediction model to the first request total amount prediction model.

9. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, for implementing the method steps described in any one of claims 1 to 6 when executing a program stored in a memory.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method steps described in any one of claims 1 to 6 are implemented.

Images