An automated testing method for a securities trading system based on result feedback

Abstract

The present invention discloses an automated testing system for a securities trading system based on result feedback, comprising: a test case generation module, a test case execution and feedback module, a test case iterative optimization module, and an exception diagnosis module; the test case generation module reads and parses the driving data file input by the tester, extracts the features therein, generates several test case sets covering different feature combinations, and sorts all test cases by priority; the test case execution and feedback module executes the test cases in the order of priority, and generates feedback data according to the execution results; the test case iterative optimization module identifies uncovered scenarios based on the feedback data, generates new test cases, and sorts the newly generated test cases by priority; the exception diagnosis module collects various indicators during the execution of the test cases, sets the baseline values of the indicators, marks the abnormal test cases and classifies the abnormal situations, and feeds back the classified abnormal information to the test case iterative optimization module to improve the test case generation strategy.

Description

Technical Field

[0001] The present invention relates to the technical field of automated testing, and particularly relates to an automated testing method for a securities trading system based on result feedback. Background Art

[0002] User interface (UI) testing of a securities trading system is a complex process that requires comprehensive consideration of multiple dimensions such as interface diversity, real-time data updates, and user interactions to ensure the stability, security, and user-friendliness of the application. These factors work together to ensure the reliability and efficiency of the securities trading system when providing services.

[0003] Currently, UI automated testing of securities trading systems mainly relies on setting specific parameters for each test case and recording corresponding scripts. Specifically, it includes setting parameters such as fund account numbers, passwords, stock codes, trading prices, etc., and recording scripts such as login verification, order placement operations, and result verification. Test execution is carried out by issuing commands and collecting test results to evaluate the performance and stability of the application.

[0004] Although existing UI automated testing methods can meet test requirements to a certain extent, they have obvious deficiencies in terms of intelligence and flexibility. Traditional testing platforms are based on fixed operation paths and behavior patterns, making it difficult to respond in real time to changes in the securities market environment and unable to dynamically generate test scenarios and use cases that adapt to market changes, which is particularly obvious in the face of complex and dynamic market environments. And currently, the analysis of test results mainly relies on test reports and manual inspections, making it difficult to obtain in-depth analysis from result feedback and also difficult to use for optimizing subsequent test processes. Summary of the Invention

[0005] The present invention proposes an automated testing method for a securities trading system based on result feedback, which solves the problem that existing testing methods cannot be dynamically adjusted according to market changes.

[0006] To solve the above technical problems, the present invention provides an automated testing method for a securities trading system based on result feedback, including the following steps:

[0007] Step S1: Use the account type, market type, trading type, and price range in the securities trading request as trading characteristics, perform equivalence class partitioning and boundary value analysis on all the trading characteristics, combine the equivalence classes and boundary values to obtain several trading characteristic combinations, and generate a test case set covering all the trading characteristic combinations.

[0008] Step S2: Perform anomaly identification on the execution results of the test case set, cluster the identified abnormal use cases, and obtain an abnormal scenario set.

[0009] Step S3: Identify the scenarios where the price boundary values, market types, transaction types, and test paths in the test case set for the full process of securities trading are not covered, and obtain the uncovered scenario set;

[0010] Step S4: Generate a new test case set based on the uncovered scenario set and the abnormal scenario set;

[0011] Step S5: Repeat Steps S2 to S4 until the set termination condition is reached, summarize the results of this test, and generate a test report.

[0012] Preferably, after generating the test case set in Step S1, score and prioritize all the test cases in the test case set, including the following steps:

[0013] Step S11: Use the risk degree, business importance, failure impact, and historical failure rate of the test cases as evaluation indicators, and calculate the evaluation indicator values of all test cases; the risk degree is the risk level of the scenario occurring, the business importance is the importance of the scenario to the trading business, the failure impact is the impact degree on the user experience or trading system when the test case fails, and the historical failure rate is the failure probability of the test case in the historical record;

[0014] Step S12: Use the analytic hierarchy process, take the prioritization of the test cases as the target layer, the evaluation indicators as the criterion layer, and the test case set to be evaluated as the scheme layer, and construct a hierarchical structure model;

[0015] Step S13: Construct a pairwise comparison matrix of the evaluation indicators, calculate the relative weights of all evaluation indicators according to the pairwise comparison matrix, and conduct a consistency test on all relative weights;

[0016] Step S14: Calculate the comprehensive score of each test case according to the relative weights of the evaluation indicators and the evaluation indicator values of the test cases;

[0017] Step S15: Prioritize all test cases in descending order of the comprehensive scores.

[0018] Preferably, in Step S2, identify abnormal test cases according to the execution results of the test cases. The execution results include function indicators, performance indicators, error indicators, and behavior indicators. Calculate the mean values of all indicators respectively, take plus or minus three times the standard deviation of the indicator mean values as the baseline values of the indicators, and take the test cases with indicator values exceeding the baseline values as abnormal test cases.

[0019] Preferably, the functional indicators include the execution status of test cases, the reasons for execution failures, and test coverage; the performance indicators include the response time of the system when executing test cases, resource utilization rate, and throughput; the error indicators include the types of exceptions and the crash frequency of the system when executing test cases; and the behavior indicators include the number of repeated executions and the execution time of test cases.

[0020] Preferably, step S4 includes the following steps:

[0021] Step S41: Perform data cleaning and standardization processing on the execution results of all test cases;

[0022] Step S42: Convert the uncovered scenarios and exception scenarios into feature vectors, randomly generate several noise vectors as the training set for the generator of the generative adversarial network GAN, and the generator outputs several virtual test cases corresponding to the noise vectors;

[0023] Step S43: Use the several virtual test cases and the feature vectors as the training set for the discriminator of GAN, and the discriminator outputs the probability that the input test case is a real sample;

[0024] Step S44: Update the parameters of the generator according to the discrimination result of the discriminator, and use the trained generator to generate new test cases;

[0025] Step S45: Perform duplicate removal on the newly generated test cases, and score and prioritize the test cases after duplicate removal.

[0026] Preferably, the generator of the generative adversarial network GAN includes several hidden layers and an output layer. The randomly generated noise vector is input into the several hidden layers for linear transformation, the activation function is used to calculate the activation output of the hidden layer, and the activation output is passed to the output layer to generate test cases; the discriminator of the generative adversarial network GAN includes two hidden layers and an output layer. The test cases generated by the generator and the real test cases are input into the two hidden layers for linear transformation, the activation function is used to calculate the activation output of the hidden layer, and the activation output is passed to the output layer to obtain the probability that the input test case is a real test case.

[0027] Preferably, in step S44, a reinforcement learning algorithm or an adaptive generation algorithm is used to optimize the generation strategy of the generator of GAN. The reinforcement learning algorithm rewards test cases with high coverage or high success rate, enabling the generator to preferentially generate test cases with high coverage and high success rate; the adaptive generation algorithm adjusts the generation strategy according to the failure rate of test cases, and preferentially generates boundary scenario cases with high coverage and high failure rate.

[0028] Preferably, in step S45, by calculating the similarity between the newly generated test cases and the existing test cases, the test cases with a similarity greater than the set similarity threshold in the newly generated test cases are deleted, so as to implement the deduplication operation on the newly generated test cases.

[0029] Preferably, the expression for scoring the deduplicated test cases in step S45 is:

[0030] ;

[0031] In the formula, is the score of the test case; coverage is the scenario coverage rate; boundary is the boundary value; failure is the historical failure rate; are the weights of the scenario coverage rate 、 the boundary value, and the historical failure rate respectively.

[0032] Preferably, in step S1, the method of orthogonal experimental design is adopted to combine the equivalence classes and boundary values to obtain several combinations of transaction characteristics.

[0033] The advantages of the present invention at least include:

[0034] 1. Analyzing the boundary values helps to capture the situations that may cause errors on the boundaries of the input domain. The equivalence class partitioning can ensure that each input domain is represented and tested, increasing the possibility of discovering defects;

[0035] 2. By continuously identifying the uncovered scenarios and abnormal scenarios and generating new test case sets based on these scenarios, the test process can self-improve and gradually improve the test coverage rate and quality;

[0036] 3. Updating the test cases according to the latest test results during each iteration can ensure that the test cases are always consistent with the latest state of the system and can adapt to the real-time changes of the securities trading system. Description of the Drawings

[0037] Figure 1 is the schematic flowchart of the method of the embodiment of the present invention;

[0038] Figure 2 is the system framework diagram of the embodiment of the present invention. Detailed Embodiments

[0039] The following clearly and completely describes the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts fall within the protection scope of the present invention.

[0040] As Figure 1 shown, the embodiment of the present invention provides an automated testing method for a securities trading system based on result feedback, including the following steps:

[0041] Step S1: Use the account type, market type, trading type, and price range in the securities trading request as trading features, perform equivalence class partitioning and boundary value analysis on all trading features, combine the equivalence classes and boundary values to obtain several trading feature combinations, and generate a test case set covering all trading feature combinations.

[0042] Specifically, the driver data file input by the tester contains the core features of each test case, such as the scenario name, case type, i.e., positive case or negative case, market type, trading category, verification level, expected result, etc., and the file format is JSON.

[0043] The parsing of the driver data is crucial in the entire solution, which determines the coverage of the test cases and the rationality of the test strategy. First, read the driver data file, query the corresponding cases from the counter according to these feature data, such as the fund account number, maximum buyable and sellable quantity, current price, price limit for up and down, etc., perform structured parsing on them, and then extract them as feature data to create a specific scenario description for each test case. For example, when the scenario name is "Limit trading in City A", the feature data extracted after parsing may include:

[0044] Account permissions: ordinary users, VIP users, administrators.

[0045] Stock codes: multiple stock codes in City A.

[0046] Price range: high price, low price, middle price.

[0047] Asset type: cash, margin trading, etc.

[0048] Then, perform standardized preprocessing on the parsed feature data to ensure that it meets the input requirements of the model, and map the standardized feature data into the use case generation model to form a basic data set, and these data will be used as the initial input for generating use cases.

[0049] Based on the parsed feature data, multiple algorithms are used to generate different test cases to cover various possible scenarios. Through the permutation and combination of different features, test cases containing different feature combinations and covering different situations are generated. For example, the price limit trading scenario in City A may include the following combinations:

[0050] Account permissions: ordinary account, VIP account, institutional account.

[0051] Stock code: Select stocks from different sectors, such as main board stocks and STAR Market stocks.

[0052] Price: Different price ranges, such as high price, low price, and price limit, etc.

[0053] Assets: Different asset combinations, including high-asset and low-asset users.

[0054] The embodiments of the present invention adopt the full combination, orthogonal experimental design, and equivalence class partitioning methods to generate different test cases.

[0055] A. Full combination

[0056] If the number of features is small, the Cartesian product is used to generate all combinations to ensure comprehensive coverage of test cases. The Cartesian product means that for multiple sets, each element in each set is combined with each element in other sets to form a new set. Suppose there are sets A , B and C , which contain elements respectively:

[0057] ;

[0058] Then all combinations of the Cartesian product are:

[0059] .

[0060] Suppose there is the following feature data:

[0061] Account type: ordinary user (Normal), VIP user (VIP).

[0062] Market type: A-share (A), B-share (B).

[0063] Transaction type: buy (Buy), sell (Sell).

[0064] First, all features are defined as different lists respectively. Then the itertools.product function is used to generate all possible combinations of account type, market type, and transaction type to ensure that each situation is covered. There are 2 account types, 2 market types, and 2 transaction types, and a total of A combination. The output result is:

[0065] ;

[0066] ;

[0067] ;

[0068] ;

[0069] ;

[0070] ;

[0071] ;

[0072] .

[0073] Map the value of each combination to the input parameter in the test case to generate specific test cases.

[0074] B. Orthogonal experimental design

[0075] For multiple characteristic data, such as more than 5, to avoid the "combinatorial explosion" problem caused by the full combination of all characteristics, orthogonal design is used to control the number of tests and cover the main combinations. Orthogonal experimental design uses an orthogonal array (OrthogonalArray) to arrange experiments. Each row represents a test case, each column represents a test factor, that is, a characteristic, and the value in each cell represents the level of the factor under a specific combination, that is, the value.

[0076] First, list all the factors to be tested and determine the number of levels for each factor. Then, according to the number of factors and levels, select the corresponding orthogonal array. The representation method of the orthogonal array is , where indicates that the table contains N rows, that is, N test cases; s represents the number of value levels of each factor; k represents the number of factors.

[0077] For example: represents a 9-row orthogonal array with 3 factors, and each factor has 3 levels.

[0078] Map each column in the orthogonal array to the test factor, and fill in the values of each factor in the corresponding position of the orthogonal array. Finally, generate test cases. Each row in the orthogonal array represents a test case, and the combination of all rows is the set of test cases to be executed.

[0079] For example: The test case set to be generated has the following three factors:

[0080] (1) Account type: Normal user (Normal), VIP user (VIP), Institutional user (Institutional);

[0081] (2) Market type: A-share (A), B-share (B), ChiNext (C);

[0082] (3) Transaction type: Buy (Buy), Sell (Sell), Cancel (Cancel).

[0083] Each factor has 3 levels, so an orthogonal array is selected to generate combinations of the main scenarios.

[0084]

[0085] Map the orthogonal array to specific factor values and assign specific values to each factor:

[0086] (1) Factor 1 (Account type): 1 = Normal, 2 = VIP, 3 = Institutional;

[0087] (2) Factor 2 (Market type): 1 = A, 2 = B, 3 = C;

[0088] (3) Factor 3 (Transaction type): 1 = Buy, 2 = Sell, 3 = Cancel.

[0089] Convert the orthogonal array to specific test combinations according to the above mapping relationship:

[0090]

[0091] Orthogonal experimental design avoids generating all 3×3×3 = 27 combinations, but covers the main interaction cases with 9 test cases.

[0092] C. Equivalence class partitioning

[0093] Divide the input data domain into several equivalence classes. The data in each equivalence class is considered equivalent for test effects, so one or more representative values can be selected.

[0094] First, determine the test objectives and the range of input data. For example: The test case set has the following input conditions:

[0095] (1) Transaction amount: The range is from 1 to 1,000,000, in yuan;

[0096] (2) Stock code: Must be 6 digits;

[0097] (3)Account Type: It can be a Normal account, a VIP account, or an Institutional account.

[0098] Perform equivalence class partitioning on the input data fields to identify valid and invalid equivalence classes. Also, identify the boundaries of each equivalence class and supplement more boundary test cases through boundary value analysis. For example:

[0099] Equivalence class partitioning:

[0100] (1)Transaction amount:

[0101] Valid equivalence class: [1, 1,000,000];

[0102] Invalid equivalence classes: Values less than 1, such as 0, -1, and values greater than 1,000,000, such as 1,000,001.

[0103] (2)Stock code:

[0104] Valid equivalence class: 6 digits, such as 000001, 123456;

[0105] Invalid equivalence classes: Not 6 digits, such as 12345, 1234567, containing letters or special characters, such as AB1234, 123#56.

[0106] (3)Account Type:

[0107] Valid equivalence class: Normal, VIP, Institutional;

[0108] Invalid equivalence classes: Non - specified types, such as Guest, Admin.

[0109] Boundary value analysis:

[0110] (1)Transaction amount:

[0111] Minimum value = 1, inside the boundary: 1, outside the boundary: 0;

[0112] Maximum value = 1,000,000, inside the boundary: 1,000,000, outside the boundary: 1,000,001.

[0113] (2)Stock code:

[0114] Minimum value: 000001, outside the boundary: 5 - digit numbers, such as 12345;

[0115] Maximum value: 999999, outside the boundary: 7 - digit numbers, such as 1234567.

[0116] Then, use the orthogonal experiment method to generate test cases:

[0117]

[0118] In a test scenario with a clear input range, by reasonably dividing the equivalence classes and analyzing the boundary values, all valid and invalid scenarios can be covered, and problems can be effectively captured.

[0119] After generating the test case set, score and prioritize all the test cases in the test case set.

[0120] Specifically, in the embodiments of the present invention, the Analytic Hierarchy Process (AHP) is adopted. By constructing a hierarchical structure model, each test case is comprehensively scored according to factors such as the risk degree, business importance, failure impact, and historical failure rate of the test case, so as to execute the test according to the priority. The steps include:

[0121] Step S11: Define evaluation indicators.

[0122] Determine the influencing factors for prioritizing the test cases, and decompose them into the following indicators, which constitute the first-level indicators in the Analytic Hierarchy Process:

[0123] Risk degree (R): The risk level of the scenario occurring, given by business analysis and evaluation;

[0124] Business importance (I): The core importance of the scenario to the system business, and scenarios affecting key business processes have higher weights;

[0125] Failure impact (F): The degree of impact of a test failure on the user experience or the overall system;

[0126] Historical failure rate (H): The failure probability of the test case in the historical record.

[0127] Step S12: Construct a hierarchical structure model.

[0128] Construct the hierarchical structure of AHP, and divide the problem into three layers:

[0129] Goal layer: Prioritization of test cases;

[0130] Criterion layer: Risk degree, business importance, failure impact, historical failure rate;

[0131] Scheme layer: The test case set to be evaluated.

[0132] Step S13: Determine the weights of each indicator.

[0133] Construct a pairwise comparison matrix among the criterion layer indicators through expert scoring and data analysis.

[0134] For example, there are 4 indicators: risk degree (R), business importance (I), failure impact (F), and historical failure rate (H):

[0135]

[0136] Construct the pairwise comparison matrix A :

[0137] .

[0138] Divide the data in each column by the sum of that column to standardize each element of the matrix A . The calculation formula is:

[0139] ;

[0140] Where: is the standardized element; is the element in the matrix A ; is the A th j column and k th

[0141] element of the matrix A . Then sum each column of the matrix

[0142] .

[0143] Normalize the matrix according to the column sums:

[0144] .

[0145] Calculate the average value of each row of the normalized matrix to obtain the weight vector of each indicator. The calculation formula is:

[0146] ;

[0147] Where: is the element in the normalized matrix; n is the dimension of the matrix, that is, the number of indicators.

[0148] According to the normalized matrix , calculate the average value of each row:

[0149]

[0150] For example:

[0151] Average value of the first row: ;

[0152] Average value of the second row: .

[0153] And so on, finally obtaining the weight vector: , that is, risk degree (R): 40%; business importance (I): 30%; failure impact (F): 20%; historical failure rate (H): 10%.

[0154] Perform consistency verification on all weights to verify the rationality of the weights:

[0155] ;

[0156] ;

[0157] ;

[0158] In the above formula, is the maximum eigenvalue of the matrix; is the element in matrix A; is the calculated weight vector; is the consistency index; is the consistency ratio; is the random consistency index.

[0159] Among them, the random consistency index can be selected according to the following table. When n takes different dimensions, it corresponds to different values:

[0160]

[0161] If , it is considered that the weights meet the consistency requirements.

[0162] Step S14: Calculate the comprehensive score of each test case according to the relative weights of the evaluation indicators and the evaluation indicator values of the test cases.

[0163] Specifically, through the above steps, the weight vector of each indicator can be obtained and its logical consistency can be ensured. The weight vector will be used for the comprehensive scoring of test cases to guide the test priority ranking. According to the weight vector and the actual indicator values of the test cases, the comprehensive score of each test case can be calculated.

[0164] For example, the indicator values of the test cases to be evaluated are as follows:

[0165]

[0166] First, normalize all index values to the range of 0 - 1. Assume the range of all indexes is 0 - 10:

[0167] ;

[0168] where is the normalized index value; is the original index value; = 10, = 0.

[0169] The calculation results of the evaluation indexes of each test case are as follows:

[0170]

[0171] The weight vector W = [0.40, 0.30, 0.20, 0.10]. Use the comprehensive score formula to calculate the scores of each evaluation index:

[0172]

[0173] Step S15: Sort all test cases in descending order according to the comprehensive score.

[0174] Specifically, sort all test cases according to the comprehensive score. The higher the score, the higher the priority. Take the sorting result as the initial execution plan. Allocate test cases to idle devices for execution, and execute Test Case 3, Test Case 2, and Test Case 1 in sequence. Each time a test case is executed, adjust the test cases to be executed in the remaining test case set according to the result feedback of the executed test cases until the termination execution condition is triggered.

[0175] During the test execution process, the monitored indexes can be divided into the following categories:

[0176] A. Function indexes

[0177] By analyzing the running logs, obtain the function execution situation of the test cases, including:

[0178] (1) Execution status: Whether it passes successfully, including two statuses: success or failure;

[0179] (2) Reason for failure: Such as assertion failure, exception thrown;

[0180] (3) Test coverage rate: Whether the current test case covers a specific function module or path in the system.

[0181] B. Performance indexes

[0182] Obtain the response time, throughput, resource utilization rate, etc. of the system through performance monitoring tools. Performance metrics reflect the performance of the system during the execution of test cases, including:

[0183] (1) Response time: The response time of the system when processing requests, such as API interface call time, page loading time;

[0184] (2) Resource utilization rate: The occupancy of resources such as CPU, memory, disk, and network when the system executes tests;

[0185] (3) Throughput: The number of test tasks processed per unit time.

[0186] C. Error metrics

[0187] Obtain runtime errors, crashes, assertion failures, test case execution results, etc. through the automated testing tool Airtest, which reflects the stability and error conditions of the system or test cases, including:

[0188] (1) Runtime error: Capture the types of exceptions when the system executes tests;

[0189] (2) Crash frequency: The number of crashes of the system or module during test execution;

[0190] (3) Assertion failure: The failure of the expected value and the actual value of the test case to match.

[0191] D. Test behavior metrics

[0192] Obtain the number of test case executions, execution time, etc. through the automated testing tool Airtest, which reflects the behavioral characteristics of test cases, including:

[0193] (1) Number of repeated executions: The number of times a test case is repeatedly executed;

[0194] (2) Test case execution time: The overall execution duration of a single test case, that is, the total time from the start to the end of executing a single test case.

[0195] The monitored metrics need to be preprocessed, feature extracted, and standardized before they can be used as inputs for the optimization model. The feature extraction processing flow is as follows:

[0196] A. Functional metrics

[0197] (1) Execution status:

[0198] Convert the execution status into binary features: success = 1, failure = 0;

[0199] Add classification features of failure reasons: assertion failure, timeout, invalid input, etc.

[0200] (2) Test coverage:

[0201] Establish the mapping relationship between functional requirements and test cases, clarify the functional requirements covered by each test case, quickly identify the blank areas of test cases through the functional requirements not covered in the mapping table. After each round of test execution, count the change value of the coverage rate. The calculation expression of the function coverage rate is:

[0202] 。

[0203] B. Performance indicators

[0204] Normalize all performance indicators, and standardize indicators such as response time and resource utilization rate to [0, 1]. The expression for normalization is:

[0205] ;

[0206] In the formula, is the normalized index value; is the original index value; is the maximum value in the original index values.

[0207] C. Error indicators

[0208] Extract the text features of the error log, and use keyword matching to extract common error categories.

[0209] D. Test behavior indicators

[0210] (1) Number of repeated executions: Count by test case number;

[0211] (2) Test case execution time: Normalize to reduce numerical differences.

[0212] The data standardization process is as follows: Use the Min-Max normalization method for data standardization. Linearly transform the data to the interval [0, 1], where the minimum value is mapped to 0, the maximum value is mapped to 1, and the intermediate values are scaled proportionally between 0 and 1.

[0213] The data processed through the above steps can be used as feedback and input into the test case iterative optimization module.

[0214] Step S2: Identify anomalies in the execution results of the test case set, cluster the identified anomalous test cases to obtain an anomalous scenario set. It includes the following steps:

[0215] Collect various indicators during the execution of test cases, set the baseline values of the indicators, use anomaly detection algorithms to mark anomalous test cases, and classify anomalous situations through a rule engine to obtain an anomalous scenario set.

[0216] Specifically, during the execution of test cases, anomalies are automatically detected and diagnosed, and a fault mode analysis report is generated. By monitoring various performance metrics, such as response time, memory usage, network latency, etc., and analyzing anomaly patterns, it helps testers quickly locate problems, thereby improving test efficiency. It includes the following steps:

[0217] Step S21: Data collection and preprocessing.

[0218] Collect various performance metrics during use case execution, including response time, memory usage, CPU occupancy, network latency, etc. Preprocess these data into normalized values for further analysis.

[0219] Step S22: Baseline setting and anomaly detection.

[0220] Set the normal range of performance metrics, that is, the baseline value. Based on the assumption of normal distribution, the points where the data falls outside the mean ± 3 times the standard deviation are regarded as anomalies.

[0221] Use anomaly detection algorithms to identify metrics that exceed the normal range. In the embodiments of the present invention, by calculating the score of each data point, and setting the threshold to 3, the data points that exceed the set threshold are marked as anomalies. The formula for calculating the score is:

[0222] ;

[0223] where, is the current value; is the baseline mean; is the standard deviation.

[0224] Step S23: Fault classification and mode analysis.

[0225] Analyze the failed use cases, extract the core reasons for failure, such as illegal input parameters, logical errors, etc., classify the error types, such as boundary value problems, null pointer exceptions, etc. Classify the abnormal situations through a rule engine, and classify the abnormal situations into specific fault types such as response timeouts, memory leaks, network failures, etc. For example: If the response time continuously exceeds the standard, it is determined as "response timeout". If the memory usage gradually increases, it may be "memory leak".

[0226] Then analyze the anomaly patterns and generate a fault mode report containing the following information:

[0227] Involved modules: The specific modules involved in the anomaly, such as the database, network module, etc.

[0228] Possible causes: Speculate possible causes based on the analysis of exception types and patterns. For example, network latency may be due to insufficient bandwidth or slow server response.

[0229] Impact of exceptions: Analyze the possible impact of exceptions on the system or users and evaluate the risk level.

[0230] Step S3: Identify scenarios where the price boundary values, market types, transaction types, and test paths of the test case set are not covered in the entire process of securities trading, and obtain the uncovered scenario set. It includes the following steps:

[0231] Step S31: Process the feedback data.

[0232] (1) Data cleaning:

[0233] Remove outliers: Remove, for example, invalid response times, i.e., negative values, or missing execution results;

[0234] Fill in missing values: Fill in missing performance metrics with average values, default values, or historical data.

[0235] (2) Feature extraction:

[0236] Extract key features from the feedback data:

[0237] Use the success / failure status as a categorical feature, the response time as a continuous feature, and the error type as a text feature.

[0238] For example:

[0239]

[0240] (3) Data standardization:

[0241] Normalize features with different dimensions, such as coverage rate and response time, to the range [0, 1].

[0242] Step S32: Analyze the coverage rate of existing test cases, find the function modules or parameter spaces not covered by the existing test cases, and extract the uncovered areas based on code coverage tools and requirement matrices.

[0243] For example, the feature vector can be:

[0244] Test case parameter features: Input range, type, default value.

[0245] Execution result features: Pass / fail, failure point, log keyword.

[0246] Define the uncovered area as:

[0247] (1)Parameter space not covered: For example, the boundary values of the price range or certain special security codes are not covered. Suppose the price range is [90, 110], and the tested prices are [91, 95, 105]. The uncovered prices are: the lower limit 90 and the upper limit 110;

[0248] (2)Function scenario not covered: Scenarios where the function module is not tested. For example, in the order cancellation module, the failure scenario of limit order cancellation is not covered. Suppose the requirement matrix is as follows:

[0249]

[0250] (3)Path not covered: Some branches in the code execution path are not triggered. For example, the transaction timeout handling logic caused by network exceptions is not tested. For example, the code snippet is as follows:

[0251] if (price>upperLimit) {

[0252] throw new IllegalArgumentException("Price exceeds upper limit");

[0253] } else if (price<lowerLimit) {

[0254] throw new IllegalArgumentException("Price below lower limit");

[0255] }else {

[0256] executeTrade(price, quantity);

[0257] }

[0258] Using a code coverage tool or a requirements-use case mapping matrix to collect code coverage, the uncovered areas can be extracted as:

[0259] Branch: price<lowerLimit.

[0260] Scenario: Test the price below the lower limit, such as 89 yuan.

[0261] Based on the above-set uncovered areas, identify the uncovered areas, and the identification results of the uncovered areas are:

[0262]

[0263] Step S4: Generate a new test case set based on the uncovered scenario set and the exception scenario set.

[0264] Specifically, based on the feedback data, the uncovered areas, failure scenarios, etc. of the existing test cases are mined, and new test cases with high test value are generated through specific algorithms and training processes.

[0265] The inputs of this process are: {feedback data, i.e., the processed standardized data; the existing test case set, including the parameter ranges, input types, and scenario combinations of the test cases; the coverage rate, i.e., the uncovered function modules, parameter spaces, and scenario combinations}.

[0266] The outputs are: {the newly generated test case set; new test scenarios, i.e., the case combinations for the uncovered scenarios and failure scenarios}.

[0267] Generate strategies are selected according to the types of uncovered scenarios and failure scenarios. The generate strategies include:

[0268] Orthogonal experimental design: used to generate multi-parameter combinations that can cover most scenarios.

[0269] Boundary value analysis: generate boundary values for the failed or uncovered scenarios in the feedback.

[0270] Machine learning generation: use the feedback data to train a model to generate more complex test cases.

[0271] The core of generating complex test cases by machine learning is as follows: The generative adversarial network (GAN) is adopted to generate new test cases. Through the adversarial training of the generator G and the discriminator D, GAN learns the distribution of the case data and generates new test cases. In the generative adversarial network (GAN), the generator G and the discriminator D are two core components. The generator G is responsible for generating new test cases, while the discriminator D is responsible for distinguishing these generated cases from the real cases.

[0272] Generator G: The generator G is a neural network model that generates new test cases according to the input random noise vector Its goal is to make the generated test cases as close as possible to the real test cases, making it difficult for the discriminator D to distinguish between real and generated test cases.

[0273] The input of the generator G is the random noise vector , and the random noise vector is usually sampled from the standard normal distribution N (0, 1), or sampled from a uniform distribution. The random noise vector provides diversity, enabling the generator to generate a variety of different test cases. For example:

[0274] The input of the generator is: the length of the random noise vector is 3, and the values are z = [0.1, -0.3, 0.5], corresponding to price, quantity, and transaction type respectively.

[0275] The weight matrix of the hidden layer and the bias vector are:

[0276] ;

[0277] ;

[0278] The weight matrix of the output layer and the bias vector are:

[0279] ;

[0280] ;

[0281] Given the input noise vector and passing it through the linear transformation of the hidden layer, the unactivated output of the hidden layer can be obtained, including the following steps:

[0282] The generator includes multiple hidden layers corresponding to the dimension of the noise vector, and calculates the linear combination of each hidden layer neuron respectively:

[0283] The first hidden layer neuron:

[0284] .

[0285] The second hidden layer neuron:

[0286] .

[0287] The third hidden layer neuron:

[0288] .

[0289] Calculate the linear combination output of the hidden layer as:

[0290] .

[0291] Use the ReLU activation function to calculate the activated output of the hidden layer:

[0292] .

[0293] Pass the output of the hidden layer to the output layer, and the linear combination formula of the output layer is:

[0294] .

[0295] After obtaining all the neurons of the hidden layer, calculate the output parameters of the generator:

[0296] , rounding gives a price of 92.

[0297] , rounding gives a quantity of 1000.

[0298] Let 0 represent market price buy and 1 represent limit price buy:

[0299] , rounding gives a transaction type of 1, i.e., limit price buy.

[0300] That is, the generator output is: price = 92, quantity = 1000, transaction type = limit price buy.

[0301] Discriminator D: The discriminator D is a binary classification model used to distinguish whether the input sample is a real use case or a generated use case. The goal of the discriminator is to output 1 for real use cases and 0 for generated use cases.

[0302] The input of discriminator D is the use case parameters. The discriminator accepts use cases from the real data set or use cases generated by the generator as input. For example:

[0303] The input features of the discriminator are: price 、quantity 、transaction type encoded as . Suppose there are 2 neurons, corresponding to two classification types respectively, and both neurons use the ReLU activation function.

[0304] The weight matrix of the hidden layer and the bias vector are:

[0305] ;

[0306] .

[0307] The weight matrix of the output layer and the bias vector are:

[0308] ;

[0309] .

[0310] Given the input feature vector:

[0311] .

[0312] The formula for the unactivated output of the hidden layer is:

[0313] .

[0314] Use the ReLU activation function Calculate the activation output of the hidden layer :

[0315] .

[0316] Pass the output of the hidden layer To the output layer. The linear combination formula of the output layer is:

[0317] .

[0318] Use the Sigmoid activation function to map the output of the output layer to The range, representing the discrimination probability. The formula is:

[0319] .

[0320] Substitute , and calculate the output probability of the discriminator:

[0321] .

[0322] That is, the output of the discriminator is 0.168, indicating that the probability that the discriminator believes the input test case is a real sample is 16.8%. The probability is closer to 0, indicating that the model believes this test case may be a fake sample generated by the generator.

[0323] In the test cases generated by the generative adversarial network (GAN), some test cases may be redundant, that is, highly similar to the existing test cases, or of low value, that is, covering fewer scenarios or having been tested multiple times. The purpose of the screening and optimization steps is to improve the test efficiency and preferentially retain and execute those high-value test cases that cover critical scenarios or uncovered areas. It includes the following steps:

[0324] (1) Remove redundant test cases

[0325] Use cosine similarity or Euclidean distance to calculate the similarity between the generated test cases and the existing test cases, and screen out the highly similar test cases. For example, if the generated test case "price = 92, quantity = 1000, transaction type = limit buy" is the same as the existing test case, then this test case is determined to be redundant.

[0326] The calculation formula of cosine similarity is:

[0327] .

[0328] In the formula, , Are the feature vectors of the test cases, including price, quantity, transaction type, etc.; n Is the dimension of the feature vector.

[0329] If the similarity exceeds the set threshold, which is set to 0.95 in the embodiments of the present invention, the use case will be marked as redundant.

[0330] Determine whether the use cases cover the same scenarios. For example, if the transaction types, price ranges, and quantity ranges of multiple use cases are exactly the same, one or several of them can be regarded as redundant use cases.

[0331] (2)Use case scoring

[0332] The scoring criteria for use cases are as follows:

[0333] Scenario coverage rate: Give priority to covering untested scenarios.

[0334] Parameter boundary values: It is more important to test use cases that include parameter boundary values.

[0335] Historical failure rate: Give higher priority to scenarios with a high historical failure rate.

[0336] Use case score The calculation formula is:

[0337] .

[0338] In the formula, coverage is the scenario coverage rate, indicating the ratio of scenarios covered by the use case; boundary is whether the parameter is a boundary value, and the boundary value weight is usually higher; failure is the historical failure rate, used to increase the priority of use case scenarios that have failed; are respectively coverage, boundary , failure weights.

[0339] (3)Use case priority ranking

[0340] Sort the generated use cases according to the use case scores, and give priority to executing use cases with higher scores.

[0341] Suppose the GAN generates the following use cases:

[0342]

[0343] According to the scores, give priority to executing G2, followed by G3, and then G1.

[0344] Step S5: Repeat steps S2 to S4 until the set termination condition is reached, summarize the results of this test, and generate a test report.

[0345] Specifically, as the test cases are gradually optimized, the system will automatically generate a failure mode analysis report, including detailed information such as the involved modules and possible causes, thereby narrowing down the scope for testers to locate problems and improving efficiency. By analyzing the current test results, the test results of the generated cases are fed back to the GAN, thus enhancing the future case generation effect. This process enables the model to gradually generate test cases with higher coverage and greater representativeness. The steps are as follows:

[0346] Step S51: Collect feedback data, including the execution results, coverage rate, and error types of the test cases.

[0347] Execution results: Record the execution results of each test case, either successful or failed.

[0348] Coverage rate: Collect the covered scenarios and the uncovered scenarios.

[0349] Error types: Record the error information of the failed test cases, such as boundary value errors, logical errors, etc.

[0350] Step S52: Extract features and analyze the feedback data, identify the uncovered areas of the test cases, and analyze the failed test cases.

[0351] Uncovered areas: Find out the parameter combinations and scenarios that are not covered by the current test cases, and use them as the target areas for generating test cases in the next step.

[0352] Analysis of failed test cases: By analyzing the failed test cases, extract the features that lead to failure, and help the generator generate more targeted test cases.

[0353] Step S53: Update the parameters of the GAN model using the feedback data.

[0354] The generator of the GAN learns new uncovered scenarios through feedback, and the discriminator is retrained based on the feedback success / failure labels to help the generator generate more effective test cases.

[0355] The optimization algorithm adopted is reinforcement learning or adaptive generation algorithm.

[0356] Adopt the reinforcement learning algorithm Q-learning to reward the test case generation behaviors with high coverage rate or high success rate. Suppose the generator generates a test case of "price = 105, quantity = 1000, transaction type = market price buy". If the execution feedback of this test case is: covering a new scenario and successfully executed. Then, according to the coverage rate and success rate of this test case, give a positive reward: the generator increases the priority of generating test cases around the market price buy with a price of 105.

[0357] After multiple iterations, the reinforcement learning algorithm will gradually optimize the generation strategy of the generator, enabling it to preferentially generate test cases with high coverage rate and high success rate.

[0358] An adaptive generation algorithm is adopted to adjust the generation strategy according to the failure rate, and boundary values and high-risk scenarios are preferentially generated. The adaptive generation algorithm uses a probability model or a parameter adjustment method to optimize the generator.

[0359] Assume that each parameter has a set of generation probabilities. If a certain parameter combination generates a valid test case, the probability of this combination is increased. The multi-armed bandit algorithm is used to update the generation rules in real time, and select a random rule with a probability of select the optimal rule with a probability of

[0360] ;

[0361] In the formula, is the generation rule; is the rule with the optimal feedback effect; n is the number of generation rules; is the exploration coefficient.

[0362] After multiple feedback adjustments, the adaptive generator will automatically preferentially generate test cases for boundary scenarios with high coverage and high failure rates, thereby improving the test coverage and error discovery rate. Assume that the generator generates a test case: price = 92, quantity = 5000, transaction type = limit buy. If this test case covers a new scenario but triggers a failure, the reason for the failure may be a boundary value problem. Then perform adaptive update on it: increase the generation probability of test cases near the price range of 92, and increase the generation probability of test cases near the boundary values, such as the quantity value close to 5000.

[0363] By continuously improving and adjusting the test case set during the execution of the test case set, it is ensured that the test cases are optimized layer by layer based on the feedback data and new scenarios are dynamically generated, and finally the goal of comprehensively covering the test requirements with a small test case set is achieved. For example: if the result feedback after the test case execution is that the test case is successfully executed, the test case iterative optimization module will automatically identify redundant test cases and exclude duplicate test cases with similar characteristics to reduce test duplication and improve efficiency. If the test case fails, analyze the reason for the failure, conduct a correlation analysis between the failure type and other test cases, automatically adjust the priority of the relevant test cases and gradually generate more refined test cases related to the failed test case. When it is found that a specific transaction process fails, the module can generate more variant test cases to verify whether the same problem exists in different operation paths until all error paths are covered. When all test cases are successfully executed or the set coverage threshold is reached, the system will automatically stop generating new test cases and end the test process.

[0364] Such as Figure 2As shown in the figure, the embodiment of the present invention also provides an automated testing system for a securities trading system based on result feedback, including a test case generation module, a test case execution and feedback module, a test case iterative optimization module, and an exception diagnosis module.

[0365] The test case generation module is used to read and parse the driver data file input by the tester, extract the features in the driver data file, generate several test case sets covering different feature combinations, and score and prioritize all test cases.

[0366] The test case execution and feedback module executes the test cases in the order of priority, collects various metrics and result data during the execution of the test cases, and generates feedback data according to the execution results.

[0367] The test case iterative optimization module identifies the uncovered scenarios of the test case set based on the feedback data, generates new test cases, scores and prioritizes the newly generated test cases, and feeds the newly generated test cases back to the test case execution and feedback module.

[0368] The exception diagnosis module is used to collect various metrics during the execution of the test cases, set the baseline values of the metrics, mark the abnormal test cases using the anomaly detection algorithm, classify the abnormal situations through the rule engine, and feed the classified abnormal information back to the test case iterative optimization module to improve the test case generation strategy.

[0369] When actually implementing an automated testing method for a securities trading system based on result feedback provided by the embodiment of the present invention, the following steps are included:

[0370] Step 1: The tester inputs the driver data, parses and extracts the feature data from the driver data file, and then uses the extracted feature data as the input of the test case generation module to generate a set of limit order trading test cases for City A.

[0371] The driver data is generally input in the form of a file. The driver data file contains the scenario name of this test case set, such as limit order trading in City A, and the feature data of each test case in the test case set, such as positive example OR negative example, market type, transaction category, verification level, expected result, etc.

[0372] Suppose 200 test cases are generated in the set, such as test cases covering different account permissions, stock codes, prices, assets, etc.

[0373] Step 2: Use the analytic hierarchy process to score the importance of each test case, and then prioritize each test case according to the final score.

[0374] The trained benchmark data has been stored in the database. The tester can modify these weight data in advance according to the test requirements and actual situations, but the weight data is static during the test execution process.

[0375] Step 3: Execute the test cases in the order of priority. During the execution of the test cases, collect metrics such as execution results, page refresh time, interface call return time, and memory consumption, and determine whether the execution results of the test cases are abnormal based on these metrics. If the page jumps are normal for each step, all performance metrics are normal, and the execution results are consistent with the expected results, then it is determined that this test case has been executed successfully; otherwise, it is reported that the test case execution has failed, and all the collected test results are sent to the anomaly diagnosis module for anomaly diagnosis.

[0376] Step 4: If the previous test case reports successful execution, the test case generation module marks all redundant test cases that are highly similar to this test case as redundant test cases and filters them out, and then reorders the remaining test cases in the set and executes them as needed. If the previous test case reports failed execution, all the metric information and execution status results collected during the test case execution are passed to the anomaly diagnosis module.

[0377] For example, if the positive example with stock code 000001 and price 10 is executed successfully, then all test cases for verifying the trading function with the stock code of the Shenzhen Stock Exchange main board and the price within the allowable entrustment range are marked as redundant test cases.

[0378] Step 5: After receiving the information, the anomaly diagnosis module first classifies the anomalies, such as the page not jumping normally, UI changes, etc., the execution results not matching the expectations, the front-end data not matching the transaction data stored in the background, the positive example order placement process finally showing a failed order placement, etc., a certain interface call returning a timeout, page refresh timeout, etc. Then, it conducts a detailed diagnosis of the anomalies according to the diagnosis rules, repairs the anomalies that affect the subsequent execution of the entire test or sends high-level notifications such as emails or phone calls. For example, a mobile phone network disconnection can be repaired by reconnecting the network or restarting the device under test, and a counter access failure can be accelerated for repair by phone or email notification, and then the diagnosis results and repair results are fed back to the test case generation module together.

[0379] Step 6: After receiving the test case execution anomaly and diagnosis information, the test case generation module determines the scope of influence of this type of anomaly based on the diagnosis content, and regenerates new test cases for the test case set for this anomaly.

[0380] For example, during the normal order placement process for stock code 000001, if the price input box cannot be detected, it is determined as a UI change. The error test case set for this exception includes all test cases that need to operate on the price input box to determine the impact scope of the UI change. After obtaining the error type and impact scope, if it is a normal change during the development process, the tester adjusts the UI element feature information in the test case generation model according to the scope of the change. Otherwise, the developer needs to be notified to locate the source of the problem. If the exception diagnosis module reports that the interface call for available funds times out during the execution of the test case, the intelligent test case generation model generates other test cases for calling this interface to form a test case set to determine the frequency of the timeout and generates test cases for calling other interfaces related to funds to determine the impact scope of the timeout interface.

[0381] Step 7: If the test case set has been filtered to the optimal set and executed, it is considered that the condition for terminating the execution is met, and the results of this round of testing are summarized and the test report is generated.

[0382] An automated testing method for a securities trading system based on result feedback provided by an embodiment of the present invention can intelligently identify abnormal, un-covered, or weak test areas and generate corresponding test cases. Through the result feedback mechanism, the system can continuously correct the test cases, eliminate redundant tests, optimize the test path, and ensure that the test case set is always in the optimal state, thereby improving the overall testing efficiency. By automatically detecting exceptions during the testing process through feedback analysis and automatically generating targeted test cases to narrow down the problem scope, the time for testers to locate problems is significantly reduced, and the testing efficiency is remarkably improved. At the same time, the system can generate test cases for scenarios such as high-frequency trading and fast buying and selling operations based on result feedback to help the securities trading system cope with sudden situations such as rapid changes in the securities market and market fluctuations. Through multi-platform test feedback and differential comparison analysis, the system can generate test cases for different platforms to ensure that the user experience of the securities trading system is consistent on multiple platforms.

[0383] In summary, the intelligent test case generation mechanism based on result feedback makes the testing process highly automated, reduces the need for manual writing and intervention by testers, and lowers the labor cost. It can adjust the priorities of test cases and testing strategies based on feedback data, avoid waste of testing resources, and improve the utilization rate of testing resources.

[0384] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. Only the preferred embodiments of the present invention are expressed. The description is relatively specific and detailed, but it should not be construed as a limitation on the scope of the present invention. As long as the combinations of these technical features do not conflict, they should be considered as within the scope described in this specification.

[0385] It should be noted that, for those of ordinary skill in the art, without departing from the concept of the present invention, several modifications and improvements can still be made, and these all fall within the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the appended claims.

Claims

1. A method for automated testing of a securities trading system based on result feedback, characterized in that: The following steps are involved: Step S1: taking the account type, market type, transaction type and price range in the securities transaction request as transaction features, performing equivalence class division and boundary value analysis on all the transaction features, combining the equivalence classes and boundary values ​​to obtain a number of transaction feature combinations, and generating test cases covering all the transaction feature combinations to obtain a test case set; Step S2: performing abnormal identification on the execution results of the test case set, clustering the identified abnormal cases, and obtaining an abnormal scenario set; The execution results include functional indicators, performance indicators, error indicators and behavioral indicators. The means of all indicators are calculated respectively, and the positive and negative three times standard deviation of the indicator mean are used as the baseline value of the indicator. The test cases whose indicator values ​​exceed the baseline value are regarded as abnormal cases. The functional indicators include the execution status of the test case, the reasons for execution failure and the test coverage; the performance indicators include the response time, resource utilization and throughput of the system when executing the test case; the error indicators include the abnormal type and crash frequency of the system when executing the test case; the behavioral indicators include the number of repeated executions and execution time of the test case; Step S3: According to the whole process of securities trading, the scenarios of price boundary values ​​not covered, market types not covered, transaction types not covered, and test paths not covered by the test case set are identified to obtain an uncovered scenario set; Step S4: Generate a new test case set based on the uncovered scenario set and the abnormal scenario set; Step S5: Repeat steps S2 to S4 until the set termination condition is reached, summarize the test results, and generate a test report.

2. The method for automated testing of a securities trading system based on result feedback according to claim 1, characterized in that: After the test case set is generated in step S1, all test cases in the test case set are scored and prioritized, including the following steps: Step S11: The risk level, business importance, fault impact and historical failure rate of the test case are used as evaluation indicators to calculate the evaluation index values ​​of all test cases; the risk level is the risk level of the scenario, the business importance is the importance of the scenario to the transaction business, the fault impact is the impact on the user experience or the transaction system when the test case fails, and the historical failure rate is the failure probability of the test case in the historical records; Step S12: adopting the hierarchical analysis method, taking the priority ranking of test cases as the target layer, taking the evaluation index as the criterion layer, taking the set of test cases to be evaluated as the solution layer, and constructing a hierarchical structure model; Step S13: construct a pairwise comparison matrix of evaluation indicators, calculate the relative weights of all evaluation indicators according to the pairwise comparison matrix, and perform consistency check on all relative weights; Step S14: Calculate the comprehensive score of each test case according to the relative weight of the evaluation index and the evaluation index value of the test case; Step S15: Prioritize all test cases in descending order of the comprehensive scores.

3. The method for automated testing of a securities trading system based on result feedback according to claim 1, characterized in that: Step S4 includes the following steps: Step S41: performing data cleaning and standardization processing on the execution results of all test cases; Step S42: converting uncovered scenes and abnormal scenes into feature vectors, randomly generating a number of noise vectors as a training set for a generator of a generative adversarial network (GAN), wherein the generator outputs a number of virtual test cases corresponding to the noise vectors; Step S43: using the plurality of virtual test cases and the feature vectors as a training set for a GAN discriminator, wherein the discriminator outputs a probability that the input test case is a real sample; Step S44: updating the parameters of the generator according to the discrimination result of the discriminator, and generating new test cases using the trained generator; Step S45: perform deduplication operation on the newly generated test cases, and score and prioritize the deduplicated test cases.

4. The method for automated testing of a securities trading system based on result feedback according to claim 3, characterized in that: The generator of the generative adversarial network GAN includes several hidden layers and an output layer, randomly generated noise vectors are input into several hidden layers for linear transformation, activation functions are used to calculate the activation outputs of the hidden layers, the activation outputs are transferred to the output layer, and test cases are generated; The discriminator of the generative adversarial network (GAN) consists of two hidden layers and an output layer. The test cases generated by the generator and the real test cases are input into the two hidden layers for linear transformation. The activation function is used to calculate the activation output of the hidden layer, and the activation output is passed to the output layer to obtain the probability that the input test case is a real test case.

5. The method for automated testing of a securities trading system based on result feedback according to claim 3 is characterized in that: In step S44, a reinforcement learning algorithm or an adaptive generation algorithm is used to optimize the generation strategy of the GAN generator, wherein the reinforcement learning algorithm rewards test cases with high coverage or high success rate, so that the generator preferentially generates test cases with high coverage and high success rate; The adaptive generation algorithm adjusts the generation strategy according to the failure rate of the test cases, giving priority to generating boundary scenario cases with high coverage and high failure rate.

6. The method for automated testing of a securities trading system based on result feedback according to claim 3, characterized in that: In step S45, by calculating the similarity between the newly generated test cases and the existing test cases, the test cases in the newly generated test cases whose similarity is greater than the set similarity threshold are deleted, thereby achieving deduplication operation on the newly generated test cases.

7. The method for automated testing of a securities trading system based on result feedback according to claim 6, characterized in that: The expression for scoring the test cases after deduplication in step S45 is: S=w coverage ·coverage+w boundary ·boundary+w failure ·failure; In the formula, S is the score of the test case; coverage is the scenario coverage; boundary is the boundary value; failure is the historical failure rate; w coverage 、w boundary 、w failure are the weights of scenario coverage, boundary value, and historical failure rate respectively.

8. The method for automated testing of a securities trading system based on result feedback according to claim 1, characterized in that: In step S1, an orthogonal experimental design method is used to combine equivalence classes and boundary values ​​to obtain several transaction feature combinations.

Images