Test case generation method, device, equipment, medium and program product

Abstract

The application provides a test case generation method and device, equipment, medium and program product, and relates to the field of artificial intelligence. The method determines a test document used for indicating test product attributes and test strategies, and performs structured path modeling on the test document to generate a path graph containing node constraint conditions and multiple logical branches, which can structurally express and clearly depict complex branch logic originally dispersed in business documents. The path graph is analyzed and processed by a path coverage algorithm to generate multiple branch paths, and the multiple branch paths are combined to obtain a test case set covering multiple logical branches, which can improve path coverage integrity and test case generation efficiency in a complex logical branch scenario, thereby reducing the difficulty of manually analyzing and constructing test cases, and improving the accuracy and comprehensiveness of test case generation.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence, and in particular to a method, apparatus, device, medium, and program product for generating test cases. Background Technology

[0002] With the deepening digitalization of business sectors such as finance and e-commerce, the business rules of business systems are becoming increasingly complex. Logical architectures with nested conditions, multiple parameter combinations, and deep branching levels have become the mainstream design. These complex logical branches directly support core business scenarios such as quotation calculation, risk verification, and order rule adaptation. Their accuracy and stability directly determine the service quality and risk control security of the business system. Therefore, comprehensive and accurate testing of complex logical branches is a core element in ensuring the stable operation of complex business systems.

[0003] Currently, the industry commonly employs manual testing methods for testing multi-condition branching logic in complex business systems. Specifically, this relies on testers manually designing test cases based on program code or business documents, and manually drawing flowcharts or writing test scripts by analyzing program logic or detailed design documents to determine the logical paths that need to be covered. However, this approach, due to its heavy reliance on testers' business understanding and code analysis experience, lacks a standardized and structured design system. When faced with complex branching scenarios involving deep nesting and multiple conditions, it is prone to missing critical execution paths, resulting in insufficient test coverage. Therefore, it can be concluded that existing manual testing methods are insufficient for accurately and comprehensively generating test cases.

[0004] Therefore, there is an urgent need for an accurate and comprehensive test case generation scheme. Summary of the Invention

[0005] This application provides a method, apparatus, device, medium, and program product for generating test cases, in order to solve the technical problems of low accuracy and insufficient coverage of existing test case generation.

[0006] Firstly, this application provides a method for generating test cases, including:

[0007] The test document determines the product pricing and is used to indicate the product attributes and test strategies.

[0008] Perform structured path modeling on the test document to generate a path graph containing node constraints; the path graph contains multiple logical branches;

[0009] The path graph is parsed and processed using a path coverage algorithm to generate multiple branch paths;

[0010] By combining multiple branch paths, a set of test cases covering multiple logical branches can be obtained.

[0011] In one possible implementation, the test document is structured into a path model to generate a path graph containing node constraints, including:

[0012] Visualization tools are used to graphically model the test document, generating multiple logical nodes and the relationships between each logical node and its constraints.

[0013] Structured path modeling is performed based on multiple logical nodes and relationships to generate multiple logical branches; these branches are then integrated to generate a path graph.

[0014] The logical nodes include decision nodes and processing nodes, and the node constraints include at least one of the following: field value range, field format, and data source type.

[0015] In one possible implementation, the method further includes:

[0016] Based on node constraints, test data that meets path requirements is generated.

[0017] Based on the test data, simulated tests are performed on the test case set to generate test log files.

[0018] In one possible implementation, test data that meets path requirements is generated based on node constraints, including:

[0019] Obtain the test information required for the simulation test;

[0020] Test data is generated based on test information and node constraints by means of user manual input and / or reading historical file data;

[0021] The test data includes at least one of the following: data that meets the node constraints and data that does not meet the node constraints.

[0022] In one possible implementation, based on test data, simulated testing is performed on the test case set to generate a test log file, including:

[0023] Determine the transmission interval parameter for the test data;

[0024] Test data is sent to the market data simulation device according to the sending interval parameter to simulate market data from different market data providers. Based on the test data, the test case set is simulated and tested, and a test log file is generated.

[0025] In one possible implementation, the method further includes:

[0026] Define the analysis prompts, which are used to indicate the analysis task and the output format of the results;

[0027] Based on the analysis prompts, the test log file is analyzed and verified to obtain the judgment results of the correctness of the judgment logic of each branch path;

[0028] The judgment results are displayed on a visual interface so that users can check the results of the simulation test.

[0029] Secondly, this application provides a test case generation apparatus, comprising:

[0030] The module determines the test documents for product pricing. These test documents indicate the product attributes and test strategies.

[0031] The generation module is used to perform structured path modeling on the test document and generate a path graph containing node constraints; the path graph contains multiple logical branches.

[0032] The generation module is also used to parse the path graph using a path coverage algorithm to generate multiple branch paths;

[0033] The processing module is used to combine multiple branch paths to obtain a set of test cases that cover multiple logical branches.

[0034] In one possible implementation, the generation module is further configured to:

[0035] Visualization tools are used to graphically model the test document, generating multiple logical nodes and the relationships between each logical node and its constraints.

[0036] Structured path modeling is performed based on multiple logical nodes and relationships to generate multiple logical branches; these branches are then integrated to generate a path graph.

[0037] The logical nodes include decision nodes and processing nodes, and the node constraints include at least one of the following: field value range, field format, and data source type.

[0038] In one possible implementation, the processing module is further configured to:

[0039] Based on node constraints, test data that meets path requirements is generated.

[0040] Based on the test data, simulated tests are performed on the test case set to generate test log files.

[0041] In one possible implementation, the processing module is further configured to:

[0042] Obtain the test information required for the simulation test;

[0043] Test data is generated based on test information and node constraints by means of user manual input and / or reading historical file data;

[0044] The test data includes at least one of the following: data that meets the node constraints and data that does not meet the node constraints.

[0045] In one possible implementation, the processing module is further configured to:

[0046] Determine the transmission interval parameter for the test data;

[0047] Test data is sent to the market data simulation device according to the sending interval parameter to simulate market data from different market data providers. Based on the test data, the test case set is simulated and tested, and a test log file is generated.

[0048] In one possible implementation, the processing module is further configured to:

[0049] Define the analysis prompts, which are used to indicate the analysis task and the output format of the results;

[0050] Based on the analysis prompts, the test log file is analyzed and verified to obtain the judgment results of the correctness of the judgment logic of each branch path;

[0051] The judgment results are displayed on a visual interface so that users can check the results of the simulation test.

[0052] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the aforementioned method.

[0053] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the aforementioned method.

[0054] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0055] The test case generation method, apparatus, device, medium, and program product provided in this application, by determining the test document used to indicate the test product attributes and test strategies, and performing structured path modeling on the test document to generate a path graph containing node constraints and multiple logical branches, can structurally express and clearly depict the complex branch logic originally scattered in business documents; by parsing the path graph through a path coverage algorithm to generate multiple branch paths, and combining the multiple branch paths to obtain a set of test cases covering multiple logical branches, it can improve the path coverage completeness and test case generation efficiency in complex logical branch scenarios, thereby reducing the difficulty of manually analyzing and constructing test cases, and improving the accuracy and comprehensiveness of test case generation. Attached Figure Description

[0056] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0057] Figure 1 A flowchart illustrating a test case generation method provided in this application;

[0058] Figure 2 A schematic diagram of a path diagram provided for this application;

[0059] Figure 3 A flowchart illustrating the simulation test process for a test case provided in this application;

[0060] Figure 4 A schematic diagram of the structure of a test case generation device provided in this application;

[0061] Figure 5 This is a schematic diagram of the structure of an electronic device provided in this application.

[0062] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0063] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0064] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0065] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0066] It should be noted that the test case generation method, apparatus, device, medium and program product provided in this application can be used in the field of artificial intelligence, or in any field other than artificial intelligence. The application field of the test case generation method, apparatus, device, medium and program product in this application is not limited.

[0067] With the deepening digitalization of business sectors such as finance and e-commerce, the business rules of business systems are becoming increasingly complex. Logical architectures with nested conditions, multiple parameter combinations, and deep branching levels have become the mainstream design. These complex logical branches directly support core business scenarios such as quotation calculation, risk verification, and order rule adaptation. Their accuracy and stability directly determine the service quality and risk control security of the business system. Therefore, comprehensive and accurate testing of complex logical branches is a core element in ensuring the stable operation of complex business systems.

[0068] Currently, the industry commonly employs manual testing methods for testing multi-condition branching logic in complex business systems. Specifically, this relies on testers manually designing test cases based on program code or business documents, and manually drawing flowcharts or writing test scripts by analyzing program logic or detailed design documents to determine the logical paths that need to be covered. However, this approach, due to its heavy reliance on testers' business understanding and code analysis experience, lacks a standardized and structured design system. When faced with complex branching scenarios involving deep nesting and multiple conditions, it is prone to missing critical execution paths, resulting in insufficient test coverage. Therefore, it can be concluded that existing manual testing methods are insufficient for accurately and comprehensively generating test cases.

[0069] In view of this, how to improve the path coverage completeness and test case generation accuracy of complex logical branch tests has become an urgent technical problem to be solved. To address the above problem, the test case generation method, apparatus, device, medium, and program product provided in this application, by determining the test document used to indicate the test product attributes and test strategies, and performing structured path modeling on the test document to generate a path graph containing node constraints and multiple logical branches, can structurally express and clearly depict the complex branch logic originally scattered in business documents; by parsing the path graph through a path coverage algorithm to generate multiple branch paths, and combining these multiple branch paths to obtain a set of test cases covering multiple logical branches, it can improve the path coverage completeness and test case generation efficiency in complex logical branch scenarios, thereby reducing the difficulty of manually analyzing and constructing test cases, and improving the accuracy and comprehensiveness of test case generation.

[0070] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0071] Figure 1 A flowchart illustrating a test case generation method provided in this application is shown below. Figure 1 As shown in the embodiments of this application, the method for generating test cases includes:

[0072] S101. Test documents for determining product pricing. Test documents are used to indicate the attributes of the test product and the test strategy.

[0073] In this application, the executing entity can be a test case generation service deployed in the testing platform, or it can be a stand-alone test management server or an application server connected to the rule engine and the quotation system.

[0074] Test documentation records test objectives, logical branches, and constraints, such as "Quotation risk control testing must cover price validity checks and data source priority judgment." Test product attributes characterize key field information related to the quotation object under test, including field name, field type, field source, field status, legal value range, and dependencies between fields. Test strategies characterize the logical scope requiring verification, including main flow branches, abnormal flow branches, boundary value branches, mutually exclusive branches, and verification requirements for specified nodes.

[0075] For example, relevant information about product pricing can be obtained from business requirements documents, detailed design documents, interface specification documents, rule configuration tables, and historical test baselines related to product pricing; then, the obtained relevant information can be preprocessed, such as format normalization, to obtain test documents containing test product attributes and test strategies.

[0076] S102. Perform structured path modeling on the test document to generate a path graph containing node constraints; the path graph contains multiple logical branches.

[0077] A path diagram can use a directed graph structure to represent the product quotation process. Nodes in the path diagram represent logical processing units or state units, and edges represent the execution flow relationships between nodes. Node constraints are used to limit the input conditions that must be met when the corresponding node is triggered. Multiple logical branches refer to different execution paths triggered by different judgment results, different field combinations, or different abnormal conditions within the same path diagram.

[0078] For example, firstly, the process layer information in the test document is read to identify the start node, sequential processing node, and end node, and the basic backbone process is constructed accordingly. Then, the rule layer information is read, and each rule entry is attached to the corresponding process node to form branching relationships under different conditions. Finally, the field layer information is read, and field constraints are written into the node metadata. For example, the age field value range, whether the information status is valid, and whether the channel field belongs to an authorized channel are recorded on the quotation admission node.

[0079] In another example, modeling can be automatically performed directly based on the logical descriptions in the test document, automatically identifying logical semantics such as "if", "otherwise", "and", "or", "exception return", "proceed to the next step" and generating corresponding graph structures, reducing the workload of manual node-by-node configuration.

[0080] In addition, to ensure the executability of the path graph, the system will also perform graph validity checks to check for isolated nodes, nodes without exit points, duplicate exit definitions, overlapping and conflicting conditions, or unreachable branches.

[0081] In one possible implementation, the test document is subjected to structured path modeling to generate a path graph containing node constraints. The specific process is as follows:

[0082] Visualization tools are used to graphically model the test document, generating multiple logical nodes and the relationships between each logical node and its constraints.

[0083] Structured path modeling is performed based on multiple logical nodes and relationships to generate multiple logical branches; these branches are then integrated to generate a path graph.

[0084] The logical nodes include decision nodes and processing nodes, and the node constraints include at least one of the following: field value range, field format, and data source type.

[0085] In this context, visualization tools refer to software tools used to transform business logic into graphical paths, such as UML modeling tools or control flow diagram tools. Decision nodes represent logical nodes for conditional judgments, such as the judgment condition "Is the price valid?". Processing nodes represent nodes for specific processing logic, such as "Calling risk control services or sending host quotes". Field value range defines the range of valid values ​​for a field, for example, bid∈[0,1000]; meaning the bid field's value range is [0,1000], and values ​​outside this range trigger the "illegal price" path. Field format defines the data format of a field, for example, field format=JSON or field format=XML; meaning the "market data" field's format is JSON, and data that does not conform to the format triggers the "parsing failure" path. Data source type defines the data source type, for example, source=reuters or source=ubs; meaning when the "data source type" is reuters, priority judgment logic is triggered.

[0086] For example, firstly, the judgment conditions and processing actions are parsed from the test document and drawn as nodes and connections using graphical modeling software, forming a correspondence between nodes and constraints. Then, based on the different branches output by the judgment nodes and their corresponding constraint information, multiple logical branches are generated. These logical branches are then merged, connected, and hierarchically organized to form a path diagram that expresses the complete business flow. This path diagram can uniformly represent field constraints, branch jumps, and processing results, presenting the complex conditional logic in the test document in a structured manner.

[0087] By using visualization tools to transform test documents into path diagrams and by explicitly defining constraints during the generation process, we can ensure that the generated test cases accurately match the path requirements, avoid path coverage omissions caused by logical abstraction, and further improve the comprehensiveness and accuracy of test case generation.

[0088] Figure 2 A schematic diagram of a path diagram provided for this application, such as Figure 2 As shown, the product's pricing status is first determined. If it is in manual pricing status, the system waits for the user to input the product price, then packages all received product prices and sends them to the host.

[0089] If the pricing is automatic, the product's pricing mechanism is determined. If the product's pricing mechanism is a single data source, all the basic data required for product pricing is obtained. This basic data is then sent to the pricing engine to calculate the product's price. Further, it is determined whether the price is empty, negative, or inverted. If at least one of these conditions is met, an alarm is triggered, and the price is removed. If the price meets the criteria of not being empty, not being negative, and not inverted, the difference between the current price and the previous price is calculated as "current price - previous price". The price difference is then determined to be less than risk parameter 1. If the price difference is less than risk parameter 1, the price is confirmed as the product's price and sent to the host. If the price difference is greater than or equal to risk parameter 1, it is determined whether the price difference is greater than risk parameter 2. If the price difference is less than or equal to risk parameter 2, a risk warning is generated, and the price is sent to the host. If the price difference is less than or equal to risk parameter 2, the price is removed.

[0090] If the product's pricing mechanism uses multiple data source pricing (e.g., pricing source 1, pricing source 2, pricing source 3), then it is determined whether the product has a dedicated data source reading priority order configured separately. If a dedicated data source reading priority order is set, then the pricing judgment is made from the highest priority pricing source (e.g., pricing source 1). Then, all the basic data required for product pricing is obtained. All the basic data is sent to the pricing engine to calculate the product's pricing source and the corresponding pricing (e.g., pricing source 1 - pricing 1).

[0091] Further, the system checks if quote 1 is empty, negative, or inverted. If quote 1 meets the criteria of not being empty, not being negative, and not inverted, it calculates the difference between quote 1 and the previous quote corresponding to quote source 1 for that product: "quote 1 - previous quote". Then, it checks if this price difference is less than risk parameter 1. If it is, quote 1 is determined as the product price and sent to the host. If the price difference is greater than or equal to risk parameter 1, it checks if the price difference is greater than risk parameter 2. If it is less than or equal to risk parameter 2, a risk warning is generated, and quote 1 is sent to the host. If the price difference is less than or equal to risk parameter 2, it checks if quote source 1 is the lowest priority quote source. If it is, quote 1 is removed.

[0092] If price source 1 is not the lowest priority price source, then other price sources of the same priority (such as price source 2) are compared. First, it is determined whether price 2 corresponding to price source 2 is empty, negative, or inverted. If price 2 meets the criteria of not being empty, not being negative, and not being inverted, then price 2 is compared horizontally with the prices corresponding to other price sources of the same priority. If there is a price inversion between price 2 and the prices corresponding to other price sources, then the next priority price source of price source 1 (such as price source 3) is switched to execute the above judgment process. If there is no price inversion, then price 2 corresponding to price source 2 is used as the price corresponding to price source 1. If price 2 has at least one of the following: empty, negative, or inverted, then the price from price source 1 is discarded.

[0093] If quote 1 contains at least one of the following: empty quote, negative quote, or quote pending, then it is determined whether quote source 1 is the lowest priority quote source. If quote source 1 is the lowest priority quote source, a risk warning is generated, and quote 1 is removed. If quote source 1 is not the lowest priority quote source, the next priority quote source (e.g., quote source 3) is switched, and the above judgment process is executed. If no dedicated data source reading priority order is set, the default priority settings corresponding to all quote sources are obtained, and the above judgment process is executed. After all quotes have been judged, all the final quotes are packaged and sent to the host.

[0094] S103. The path graph is parsed and processed using a path coverage algorithm to generate multiple branch paths.

[0095] The path coverage algorithm is used to traverse a path graph containing node constraints, identify multiple logical branches in the path graph, and map different logical branches to multiple branch paths. A branch path is a complete execution sequence from the start node to the end node. The sequence includes not only the order of the nodes traversed, but also the conditional results and cumulative constraints at each decision node. The goal of the parsing process is not merely to output the topological sequence of the graph, but to output path descriptions that can be directly used for test case generation.

[0096] For example, starting from the beginning node, the path graph is expanded using depth-first traversal, breadth-first traversal, or a combination of traversals based on constraint pruning. At each node visited, the constraint expression of that node is read, and the accumulated conditions on the current branch are merged with this constraint. If an unsatisfiable condition arises after merging constraints (e.g., the same field is simultaneously constrained to "greater than 60" and "less than 18" on the same branch path), the candidate branch path is marked as a conflict path, and expansion is terminated. If the constraint can be satisfied, the traversal continues along the corresponding exit of that node until the end node is reached. For multi-branch nodes, the algorithm expands each exit separately to identify all reachable branch paths. For nodes containing boundary conditions, the system can split the interval endpoints during parsing. For example, "price less than 100,000", "price equal to 100,000", "price greater than 100,000 and less than 500,000", and "price greater than or equal to 500,000" can be parsed as different path conditions so that the subsequently generated test data can hit the boundary and non-boundary branches respectively. For abnormal verification nodes, the system retains the branch path that caused the interruption, so that the abnormal return branch path and the normal quotation branch path are added to the branch path set together.

[0097] By systematically traversing the path graph using a path coverage algorithm and combining it with constraint consistency judgment, all multi-layered logical branches that are difficult to fully identify manually can be transformed into manageable path results. This reduces the chance of missing cross branches, abnormal branches, and boundary branches, and provides accurate path basis for the construction of subsequent test cases.

[0098] S104. Combine multiple branch paths to obtain a set of test cases covering multiple logical branches.

[0099] Each test case corresponds to a branch path or a set of branch paths that satisfy the same test strategy, and includes input data, preconditions, execution entry point, expected traversed nodes, expected processing result, and path identifier. Combination processing refers to organizing, merging, deduplicating, and instantiating the multiple branch paths output by the path coverage algorithm according to predetermined rules, transforming the path information into directly executable test cases. These predetermined rules can be established based on the relationships between paths, execution order, constraint compatibility, test strategy labels, and coverage priority.

[0100] The generated test cases include, for example:

[0101] start([Start])-->recv[Receive quotes\nchannel:reuters / ubs / cmds\n];

[0102] recv-->chk{checks if the price is valid\nille:bid=" or ask=", bid>ask, bid<0 or ask<0};

[0103] chk --Yes-->Risk control longitudinal comparison to see if it is less than rate1 [calls the ATS service and sends the host quote];

[0104] chk--No-->;

[0105] chk -- Yes --> Risk control longitudinal comparison: Is it less than or equal to rate2? [Risk warning, and call the ATS service to send a host quote];

[0106] chk--No-->;

[0107] chk -- Yes --> Is it the lowest priority data source? [Risk warning: exclude bids from this round];

[0108] chk -- No --> recv [Receive quotes from the second data source];

[0109] recv-->chk{checks if the price is valid\nille:bid=" or ask=", bid>ask, bid<0 or ask<0};

[0110] chk--Yes-->Risk control longitudinal comparison: Is it greater than rate3? [Risk warning, exclude bids from this round];

[0111] chk -- No ---> [Risk warning, and calls the ATS service to send a host quote];

[0112] call-->Res{host interface returns\nstatus:200 / not 200};

[0113] Res--Success-->end([End]);

[0114] Res--Failure-->err;

[0115] err-->end

[0116] This embodiment provides a method for generating test cases. It involves determining a test document for a product price quote, which indicates the product attributes and testing strategies; performing structured path modeling on the test document to generate a path graph containing node constraints, with multiple logical branches; parsing the path graph using a path coverage algorithm to generate multiple branch paths; and combining these branch paths to obtain a set of test cases covering multiple logical branches. This application solves the problem of incomplete test case coverage in existing technologies by combining structured path modeling and a path coverage algorithm. The path graph construction transforms abstract business logic into a visual path, and the path coverage algorithm systematically parses all branch paths, avoiding the omission of key logical branches during manual design.

[0117] In one possible implementation, Figure 3 A flowchart illustrating a simulated test case for this application is provided, as shown below. Figure 3 As shown, it includes:

[0118] S301. Based on node constraints, generate test data that meets path requirements.

[0119] Node constraints can be jointly determined by the decision nodes and processing nodes in the path graph. When generating test data, the field constraints, value ranges, format requirements, and data source types associated with each target branch path are first read. Then, matching inputs are generated according to the coverage requirements of the target branch path. If necessary, boundary values, outliers, or reverse data that does not meet the constraints can also be constructed to form test data for different branches. Test data can be stored using structured data records, with the field order consistent with the interface parameters or business forms, so that it can be directly input into the simulation test environment for execution.

[0120] By generating test data based on node constraints, the matching degree between test data and path requirements is improved, while reducing the workload of manually constructing data and improving the efficiency and accuracy of test data preparation.

[0121] In one possible implementation, test data that meets path requirements is generated based on node constraints, including:

[0122] Obtain the test information required for the simulation test;

[0123] Test data is generated based on test information and node constraints by means of user manual input and / or reading historical file data;

[0124] The test data includes at least one of the following: data that meets the node constraints and data that does not meet the node constraints.

[0125] The test information indicates the type of quote that needs to be tested, such as "spot quote". Then, the test information is matched with the node constraints in the path graph, and candidate values ​​for the fields to be tested are generated based on the testers' manual input. Test data is then generated based on these candidate values. Alternatively, when reading historical file data, field values ​​are extracted from historical test files, historical execution log files, or historical business sample files. The extracted results are then filtered, mapped, and reorganized according to the test information to ensure they conform to the test data corresponding to the target branch path. Furthermore, during the generation of test data, for data that meets the node constraints, field values ​​are controlled within the constraint range, and the dependencies between fields are kept consistent. For data that does not meet the node constraints, field values ​​that are out of range, incorrectly formatted, or mismatched in data source type are constructed to trigger abnormal or validation branches.

[0126] For example, the manual input method is suitable for scenarios that require construction based on specific boundary values, outliers, or manually specified combinations of conditions, while the method of reading historical file data is suitable for scenarios that require quick reuse of existing valid samples, playback of historical defect samples, or generation of batch test samples. The two methods can be used individually or in combination to form a test dataset that covers different branch conditions.

[0127] By constructing test data that meets path requirements based on node constraints, different data formats that satisfy and do not satisfy constraints can be covered simultaneously. This creates a one-to-one verification relationship between the test data and the target branch, improving the verification of complex logical paths and enhancing the coverage of abnormal and boundary conditions.

[0128] S302. Based on the test data, perform simulated testing on the test case set and generate test log files.

[0129] Test log files can include execution time, test case identifiers, input data, nodes traversed, branch results, and error stack information, enabling subsequent comparison and analysis of coverage in conjunction with the path diagram.

[0130] For example, during simulated testing, a set of test cases is loaded into a market data simulation device, which drives the logic to run step by step according to the test data and outputs test log files. By reproducing real business scenarios through the market data simulation device, the credibility of the test results is improved, and the comprehensiveness of the test verification is further optimized.

[0131] In one possible implementation, based on test data, simulated testing is performed on the test case set to generate a test log file, including:

[0132] Determine the transmission interval parameter for the test data;

[0133] Test data is sent to the market data simulation device according to the sending interval parameter to simulate market data from different market data providers. Based on the test data, the test case set is simulated and tested, and a test log file is generated.

[0134] The simulation device refers to a testing tool used to simulate an external input environment, such as a market data simulator or an API simulator. The sending interval parameter is used to limit the time interval between two consecutive test data transmissions to the market data simulation device. For example, it can be set according to the requirements of the market data refresh frequency, order book change frequency, and message arrival order based on the test cases. This application does not restrict the way the sending interval parameter is set.

[0135] For example, after receiving test data sent according to the sending interval parameter, the market data simulation device can map fields such as price, trading volume and timestamp to the data formats of different market data providers, and simulate market data input from multiple providers within the same test period. This allows the test case set to trigger corresponding branches for simulation verification under the same business processing environment, and write the test data and execution status to the test log file to form a traceable test record.

[0136] Understandably, by combining the sending interval parameter with the message scheduling mechanism of the market simulation device, test data can enter the market simulation device in a manner close to the real market flow. The test case set then completes path triggering and result verification based on these simulated market data. The final output test log file is used to record the execution status and judgment result corresponding to each test data. In this way, test cases can complete consistency verification under different market data sources and different arrival rhythms, and abnormal responses and path coverage during the test process can be completely saved in the log.

[0137] For example, the input log files are shown in the table below:

[0138] Table 1 shows examples of log files.

[0139]

[0140] In one possible implementation, the method further includes:

[0141] Define the analysis prompts, which are used to indicate the analysis task and the output format of the results;

[0142] Based on the analysis prompts, the test log file is analyzed and verified to obtain the judgment results of the correctness of the judgment logic of each branch path;

[0143] The judgment results are displayed on a visual interface so that users can check the results of the simulation test.

[0144] For example, the analysis prompt is: "Analysis task: Please extract the risk control status of A from the given log file, extract the current quote from field 1, extract the previous quote from field 2, and extract the risk control judgment result from field 3; Result output format: display the current quote, previous quote, and risk control judgment result in a list format."

[0145] For example, based on the determined analysis prompts, the log file is extracted in a structured manner, and the text log is converted into an analysis object containing field names, field values, node order and branch markers. The judgment logic of the branch path is verified to be correct when the test case is simulated, and the judgment result is obtained. Finally, the judgment result is displayed on the visualization interface so that users can check the results of the simulation test.

[0146] By analyzing prompt words to parse test logs, the system can automatically verify the path execution results, reducing the workload of manual comparison and further improving the efficiency and accuracy of test verification.

[0147] Figure 4 A schematic diagram of the structure of a test case generation device provided in this application is shown below. Figure 4 As shown, the test case generation device 400 provided in this application embodiment includes:

[0148] Module 401 is used to determine the test document for the product quotation. The test document is used to indicate the test product attributes and test strategies.

[0149] The generation module 402 is used to perform structured path modeling on the test document and generate a path graph containing node constraints; the path graph contains multiple logical branches.

[0150] The generation module 402 is also used to parse the path graph using a path coverage algorithm to generate multiple branch paths;

[0151] Processing module 403 is used to combine multiple branch paths to obtain a set of test cases covering multiple logical branches.

[0152] In one possible implementation, the generation module 402 is further configured to:

[0153] Visualization tools are used to graphically model the test document, generating multiple logical nodes and the relationships between each logical node and its constraints.

[0154] Structured path modeling is performed based on multiple logical nodes and relationships to generate multiple logical branches; these branches are then integrated to generate a path graph.

[0155] The logical nodes include decision nodes and processing nodes, and the node constraints include at least one of the following: field value range, field format, and data source type.

[0156] In one possible implementation, the processing module 403 is further configured to:

[0157] Based on node constraints, test data that meets path requirements is generated;

[0158] Based on the test data, simulated tests are performed on the test case set to generate test log files.

[0159] In one possible implementation, the processing module 403 is further configured to:

[0160] Obtain the test information required for the simulation test;

[0161] Test data is generated based on test information and node constraints by means of user manual input and / or reading historical file data;

[0162] The test data includes at least one of the following: data that meets the node constraints and data that does not meet the node constraints.

[0163] In one possible implementation, the processing module 403 is further configured to:

[0164] Determine the transmission interval parameter for the test data;

[0165] Test data is sent to the market data simulation device according to the sending interval parameter to simulate market data from different market data providers. Based on the test data, the test case set is simulated and tested, and a test log file is generated.

[0166] In one possible implementation, the processing module 403 is further configured to:

[0167] Define the analysis prompts, which are used to indicate the analysis task and the output format of the results;

[0168] Based on the analysis prompts, the test log file is analyzed and verified to obtain the judgment results of the correctness of the judgment logic of each branch path;

[0169] The judgment results are displayed on a visual interface so that users can check the results of the simulation test.

[0170] The test case generation device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0171] Figure 5 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 4As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0172] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0173] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0174] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method; its implementation principle and technical effect are similar and will not be described in detail here.

[0175] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the technical solution of the above method embodiments. Its implementation principle and technical effects are similar, and will not be repeated here.

[0176] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0177] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0178] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0179] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0180] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0181] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0182] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0183] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only.

[0184] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A method for generating test cases, characterized in that, include: A test document for determining product pricing, wherein the test document is used to indicate the test product attributes and test strategies; The test document is subjected to structured path modeling to generate a path graph containing node constraints; the path graph contains multiple logical branches. The path graph is parsed using a path coverage algorithm to generate multiple branch paths; By combining multiple branch paths, a set of test cases covering the multiple logical branches is obtained.

2. The method according to claim 1, characterized in that, The step of performing structured path modeling on the test document to generate a path graph containing node constraints includes: The test document is graphically modeled using visualization tools to generate multiple logical nodes and the relationship between each logical node and its constraints. Structured path modeling is performed based on multiple logical nodes and their relationships to generate multiple logical branches; the multiple logical branches are then integrated to generate the path graph. The logical node includes a judgment node and a processing node, and the node constraints include at least one of the following: field value range, field format, and data source type.

3. The method according to any one of claims 1-2, characterized in that, The method further includes: Based on node constraints, test data that meets path requirements is generated. Based on the test data, simulated tests are performed on the test case set to generate test log files.

4. The method according to claim 3, characterized in that, The generation of test data that meets path requirements based on node constraints includes: Obtain the test information required for the simulation test; The test data is generated based on the test information and the node constraints by means of user manual input and / or reading historical file data; The test data includes at least one of the following: data that satisfies the node constraints and data that does not satisfy the node constraints.

5. The method according to claim 3, characterized in that, The step of performing simulated testing on the test case set based on the test data and generating a test log file includes: Determine the transmission interval parameter for the test data; The test data is sent to the market data simulation device according to the sending interval parameter to simulate market data from different market data providers. Based on the test data, the test case set is simulated and tested to generate a test log file.

6. The method according to claim 3, characterized in that, The method further includes: Determine analysis prompts, which are used to indicate the analysis task and the output format of the results; Based on the analysis prompts, the test log file is analyzed and verified to obtain the judgment results of the correctness of the judgment logic of each branch path; The judgment results are displayed on a visual interface so that users can check the results of the simulation test.

7. A test case generation device, characterized in that, include: The determination module is used to determine the test document for the product quotation, and the test document is used to indicate the test product attributes and test strategies; The generation module is used to perform structured path modeling on the test document and generate a path graph containing node constraints; the path graph contains multiple logical branches. The generation module is also used to parse the path graph using a path coverage algorithm to generate multiple branch paths; The processing module is used to combine multiple branch paths to obtain a set of test cases covering the multiple logical branches.

8. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.

Images