Test case screening method and device and storage medium

Abstract

The invention relates to the technical field of software testing, and discloses a test case screening method and device and a storage medium, and the method comprises the steps: extracting a test data item and an operation instruction item of an input condition in case screening, and obtaining a standardized input descriptor; taking the test cases with overlapped value domains in the standardized input descriptors as a class of similar test case clusters; taking the test cases with consistent operation instruction sequence structures in the standardized input descriptors as second-class similar test case clusters; collecting the first class of similar test case clusters and the second class of similar test case clusters as similar test case domains; separating a state code and an output data mode of expected output description in the similar test case domain; when the state code is consistent with the output data mode, a redundancy identification result is obtained; based on the redundancy identification result, redundant test cases in case screening are removed, and target test cases of case screening are obtained; the efficiency of the test case screening method can be improved.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a method, apparatus and storage medium for screening test cases. Background Technology

[0002] Existing technologies lack standardized processing procedures for input conditions when screening test cases, making it impossible to systematically extract the core features of test data items and operation instructions. This results in a chaotic presentation of input information for different test cases. Consequently, test cases with similar characteristics are difficult to classify accurately, requiring a significant amount of time for manual comparison during the screening process, which severely impacts the pace of the screening work.

[0003] Current technologies for identifying redundant test cases lack comprehensive criteria, relying solely on simple comparisons across a single dimension to determine redundancy. This fails to consider both the similarity of input features and the consistency of expected outputs. Consequently, some test cases that are not actually redundant are mistakenly removed, or some truly redundant test cases go unidentified. This reduces the completeness of test coverage and increases unnecessary testing costs, failing to meet the need for efficient and accurate test case selection. Summary of the Invention

[0004] This disclosure provides a method, apparatus, and storage medium for screening test cases.

[0005] Firstly, this disclosure provides a method for filtering test cases, including: S1. Extract the test data items and operation instruction items of the input conditions in the test case filtering to obtain the standardized input descriptor of the test case filtering; S2. The test cases with overlapping value ranges in the standardized input descriptors are taken as a cluster of similar test cases for the test case screening. S3. Test cases with consistent operation instruction sequence structures in the standardized input descriptors are selected as a cluster of two similar test cases for the test cases. S4. Gather the first type of similar test case cluster and the second type of similar test case cluster to form the similar test case domain for the test cases; S5. Separate the state code and output data pattern of the expected output description in the similar test case domain; S6. When the status code is consistent with the output data pattern, the redundancy identification result of the use case screening is obtained; S7. Based on the redundancy identification results, remove redundant test cases from the test case filtering to obtain the target test cases for the test case filtering.

[0006] In a preferred embodiment, the extraction of test data items and operation instruction items from the input conditions in the test case filtering to obtain the standardized input descriptor for the test case filtering includes: Extract the data input elements and instruction execution flow of the input conditions in the test case filtering to obtain the input element set of the test case filtering; The representation format of the input element data in the input element set is standardized to obtain the standard test data items for the use case screening. The key operation instructions in the input element set are used as the standard operation instructions for the use case screening. The standard test data items and the standard operation instructions are integrated and encapsulated to obtain the standardized input descriptor for the test case screening.

[0007] In a preferred embodiment, the step of selecting test cases with overlapping value ranges in the standardized input descriptors as a cluster of similar test cases for the test case screening includes: Define the range of data values ​​for test data elements in the standardized input descriptor; Based on the numerical intervals that intersect within the data value range, establish the value range overlap relationship for the use case screening; Based on the value range overlap relationship, test cases with common value ranges are filtered in the test case filtering to obtain the candidate test case group of the test case filtering; To verify the substantial overlap of value ranges in the candidate test case group, a cluster of similar test cases is obtained by filtering the test cases. The formula for calculating the substantial overlap index of the value ranges of the candidate test case group is as follows: ; In the formula, The value range overlap substantive index, The length of the overlapping interval of the value range overlap relationship. Test cases within the range of data values Length of the value range Test cases within the range of data values Length of the value range Test cases within the range of data values The center point of the value range Test cases within the range of data values The center point of the value range These are the preset scaling parameters.

[0008] In a preferred embodiment, the step of selecting test cases with consistent operation instruction sequence structures in the standardized input descriptors as a cluster of two similar test cases for test case screening includes: Separate the basic instruction elements and execution order of the operation instruction sequence to obtain the instruction element sequence selected by the use case; Based on the sequential relationship and dependencies of instruction execution in the instruction element sequence, construct the structural mapping relationship for the use case screening; Based on the structural mapping relationship, test cases with the same instruction elements and consistent logical associations in the test case screening are selected to obtain the candidate instruction similarity group of the test case screening; Verify the structural consistency of the operation instruction sequences in the candidate instruction similarity group to obtain the two types of similar test case clusters selected by the test cases.

[0009] In a preferred embodiment, the process of aggregating the first type of similar test case cluster and the second type of similar test case cluster to filter the test cases includes: Identify test cases that coexist in both the first type of similar test case cluster and the second type of similar test case cluster to obtain the common test case group for the test case screening. The non-shared test cases in the first type of similar test case cluster and the second type of similar test case cluster are summarized, and test cases with a single similarity feature are added to obtain the test case set for the test case selection. The integrity of the test case set is verified to obtain the similar test case domains selected from the test cases.

[0010] In a preferred embodiment, separating the state encoding and output data pattern of the expected output description in the similar test case domain includes: Separate the state description portion and the data output portion of the expected output description in the similar test case domain; The feature information of the execution result in the state description section is standardized and encoded to obtain the state code for the use case screening.

[0011] The data organization and content characteristics of the data output section are analyzed to obtain the output data pattern for the use case selection.

[0012] In a preferred embodiment, obtaining the redundancy identification result of the use case screening when the state code matches the output data pattern includes: For the same execution results in the state codes, a state homogeneity determination is performed to obtain the state consistency result of the used case screening; Confirm the correspondence between the structure and content in the output data pattern to obtain the data matching results of the use case filtering; When the state consistency result and the data matching result are both confirmed to be consistent, it is determined that there is a redundant relationship between the test cases, and the redundancy identification result of the test case screening is obtained.

[0013] In a preferred embodiment, the step of removing redundant test cases from the test case screening based on the redundancy identification result to obtain the target test cases for the test case screening includes: Locate the test cases marked in the redundancy identification results at their corresponding positions in the test case filtering to obtain the list of test cases to be removed from the test case filtering; Delete the test cases from the list of test cases to be removed to obtain the preliminary filter set for test case filtering; Verify the completeness of the functional coverage of the test cases retained in the initial screening set to obtain the target test cases for the selected test cases.

[0014] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention generates standardized input descriptors by extracting test data items and operation instruction items from the input conditions of test cases. Then, based on the value domain overlap characteristics and operation instruction sequence structure characteristics, it divides the test cases into first-class and second-class similar test case clusters. In the first-class cluster division, the accuracy of similarity judgment is ensured by verifying the substantial overlap of value domains. Finally, a complete similar test case domain is formed. This process can efficiently focus on test cases with potential correlation, greatly improve the accuracy of similar test case identification and the efficiency of the screening process, and reduce the time consumption of invalid screening steps.

[0015] 2. When screening target test cases, this invention first separates the state code and output data pattern of the expected output description in the similar test case domain. Redundancy is determined only when both are confirmed to be consistent. Then, the functional coverage integrity of the retained test cases is verified by locating the test cases to be removed and deleting the redundant test cases. This not only achieves the accurate removal of redundant test cases, but also ensures the completeness of the functional coverage of the target test cases, effectively avoids redundant test cases occupying test resources, and ensures that subsequent testing work can be carried out based on high-quality target test cases, thereby improving the effectiveness of the overall testing work. Attached Figure Description

[0016] The present disclosure will be described in more detail below based on embodiments and with reference to the accompanying drawings: Figure 1 The flowchart of a test case selection method according to Embodiment 1 of the present invention is shown; Figure 2 This diagram shows a functional block diagram of a test case screening device according to Embodiment 2 of the present invention; Detailed Implementation

[0017] To enable those skilled in the art to better understand the technical solutions of this disclosure, and to fully understand and implement the process of how this disclosure applies technical means to solve technical problems and achieve corresponding technical effects, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, not all embodiments. The embodiments of this disclosure and the various features within them can be combined with each other without conflict, and the resulting technical solutions are all within the protection scope of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort should fall within the protection scope of this disclosure.

[0018] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0019] Example 1

[0020] Figure 1 This is a flowchart illustrating a test case selection method provided in an embodiment of this disclosure. Figure 1 As shown, a method for filtering test cases includes: S1. Extract the test data items and operation instruction items of the input conditions in the test case filtering to obtain the standardized input descriptor of the test case filtering; In this embodiment of the invention, the step of extracting test data items and operation instruction items from the input conditions in the test case filtering to obtain the standardized input descriptor for the test case filtering includes: Extract the data input elements and instruction execution flow of the input conditions in the test case filtering to obtain the input element set of the test case filtering; The representation format of the input element data in the input element set is standardized to obtain the standard test data items for the use case screening. The key operation instructions in the input element set are used as the standard operation instructions for the use case screening. The standard test data items and the standard operation instructions are integrated and encapsulated to obtain the standardized input descriptor for the test case screening.

[0021] Specifically, first, clarify the scope of the input conditions for test case screening. This scope includes all the initial information required to complete the test case screening. Then, identify the content related to the test data in each input condition. This content covers the data type, source, and specific value information, and determines these contents as data input elements. At the same time, sort out all the operation instructions involved in the input conditions, organize the execution steps of the operation instructions according to the actual execution sequence, clarify the operation object and execution purpose of each step, and form an instruction execution flow. Finally, integrate all the identified data input elements and the sorted instruction execution flow together to form the input element set for test case screening.

[0022] Furthermore, a comprehensive analysis is first conducted on the current representation of all data input elements in the input element set to identify differences in representation. These differences include variations in data formats, inconsistencies in units of measurement, and differences in the terminology used to describe the data. Based on the actual testing purpose of the data input elements and industry-standard data representation specifications, unified representation rules are formulated. These rules clearly define unified data formats, standard units of measurement, and standardized descriptive terminology. Following these unified representation rules, the representation of each data input element is adjusted to ensure consistency in format, units, and terminology across all data input elements. The resulting standard test data items for test case selection are then obtained.

[0023] Furthermore, the instruction execution flow in the input element set is first broken down into independent operation instructions according to the execution sequence to ensure that no instruction participating in the process is missed. Then, the role of each independent operation instruction in the entire test case screening process is analyzed to determine whether the instruction directly affects the normal progress of the test case screening logic and whether it plays a core supporting role in the final achievement of the test objective. If both conditions are met, the operation instruction is identified as a key operation instruction. Finally, all identified key operation instructions are summarized and organized to form standard operation instructions for test case screening.

[0024] Furthermore, an integrated encapsulated structural framework is designed. This framework requires two independent but interconnected areas: one area for storing standard test data items and the other for storing standard operation instructions. The specific locations of these two areas within the framework and the correspondence between data items and instructions are clearly defined. All previously obtained standard test data items are then sequentially filled into the pre-defined standard test data item storage area within the framework, ensuring the accurate location and completeness of each data item. Next, all standard operation instructions are sequentially filled into the pre-defined standard operation instruction storage area within the framework, ensuring the order of instructions matches the actual execution logic and accurately corresponds to the associated standard test data items. Finally, the information-filled structural framework is integrated and encapsulated to form a complete, unified, and directly usable descriptive carrier for subsequent test case screening steps. This carrier is the standardized input descriptor for test case screening.

[0025] In general, the process involves first clarifying the specific scope of input conditions for test case selection, then identifying the data input elements related to the test data one by one, and finally outlining the complete instruction execution flow according to the actual execution sequence of the operation instructions. Then, all the identified data input elements are integrated with the outlined instruction execution flow to obtain the final set of input elements for test case selection.

[0026] In general, the process begins with a comprehensive analysis of the current representation of all data input elements in the input element set, identifying differences in data format, units of measurement, and descriptive terminology. Then, by combining the actual testing purpose of the data input elements with industry-standard data representation specifications, a unified representation rule is developed. Subsequently, the representation of each data input element is adjusted according to this rule to ensure consistency in format, units, and terminology across all data input elements, thereby obtaining standard test data items for test case selection.

[0027] In general, the process involves first breaking down the instruction execution flow of the input element set into multiple independent operation instructions according to the execution sequence, then analyzing the role of each independent operation instruction in the entire test case screening process to determine whether it directly affects the normal progress of the test case screening logic and whether it plays a core supporting role in the final achievement of the test objective. Operation instructions that meet these two conditions are identified as key operation instructions. Finally, all key operation instructions are summarized to obtain the standard operation instructions for test case screening.

[0028] In summary, the process involves first designing an integrated and encapsulated structural framework. This framework contains two independent but interconnected areas, which are used to store standard test data items and standard operation instructions, respectively. The specific locations of the two areas within the framework and the correspondence between the data items and instructions are clearly defined. Then, the previously obtained standard test data items and standard operation instructions are filled into the corresponding areas of the framework, ensuring that the information is complete and the order of the instructions conforms to the actual execution logic. Finally, the framework with the information filled in is integrated and encapsulated as a whole to form a standardized input descriptor for test case screening.

[0029] S2. The test cases with overlapping value ranges in the standardized input descriptors are taken as a cluster of similar test cases for the test case screening. In this embodiment of the invention, the step of using test cases with overlapping value ranges in the standardized input descriptors as a cluster of similar test cases for test case screening includes: Define the range of data values ​​for test data elements in the standardized input descriptor; Based on the numerical intervals that intersect within the data value range, establish the value range overlap relationship for the use case screening; Based on the value range overlap relationship, test cases with common value ranges are filtered in the test case filtering to obtain the candidate test case group of the test case filtering; To verify the substantial overlap of value ranges in the candidate test case group, a cluster of similar test cases is obtained by filtering the test cases. The formula for calculating the substantial overlap index of the value ranges of the candidate test case group is as follows: ; In the formula, The value range overlap substantive index, The length of the overlapping interval of the value range overlap relationship. Test cases within the range of data values Length of the value range Test cases within the range of data values Length of the value range Test cases within the range of data values The center point of the value range Test cases within the range of data values The center point of the value range These are the preset scaling parameters.

[0030] Specifically, test data elements corresponding to each test case are extracted from the standardized input descriptor. The specific type and test scenario of each test data element are clarified. Based on all the legal values ​​that the test data element may involve in the actual test process, and combined with the constraints on the data element in the test requirements, the minimum and maximum boundary values ​​of each test data element are determined. All possible value ranges between these two boundary values ​​are determined, thereby defining the data value range of the test data elements in the standardized input descriptor.

[0031] Furthermore, the data value ranges of all test data elements corresponding to all test cases are listed one by one. The test cases are grouped according to the type of test data elements to ensure that the test cases in the same group correspond to the same type of test data elements. Then, the data value ranges of any two test cases in each group are compared one by one to determine whether there is at least one mutually inclusive numerical part between the two value ranges. If such a numerical interval exists, an association record is established for the two test cases. All such association records together constitute the value range overlap relationship for test case screening.

[0032] Furthermore, all established value range overlap relationships are organized, and test cases with direct or indirect relationships are grouped together. Direct relationship means that there is a clear value range overlap relationship between two test cases, and indirect relationship means that two test cases establish a value range overlap relationship through a third test case. In the classification process, it is ensured that each test case in the same set has a common value range with at least one other test case in the set. Each test case set formed in this way is the candidate test case group for test case screening.

[0033] Furthermore, the data value range of any two test cases within the candidate test case group is analyzed. First, the length of the overlapping portion of the two value ranges is measured. Then, the overall length of the data value range of each test case is measured. Next, the center point of each of the two test case data value ranges is determined, and the distance between the two center points is calculated. Based on the proportion of the overlapping portion length to the smaller of the overall lengths of the two test case value ranges, and the distance between the two center points, a comprehensive judgment is made on whether the overlap of the two value ranges has practical significance. If the proportion reaches a set reasonable level and the distance between the center points is within a relatively close range, then the overlap is determined to be substantial. The candidate test case group that passes this verification is identified as a cluster of similar test cases for test case screening.

[0034] Specifically, from the test data metadata value range previously defined for two test cases in the candidate test case group, find the overlapping part of the two value ranges. By measuring the numerical span of the overlapping part, the obtained value is the length of the overlapping interval of the value range overlap relationship.

[0035] Furthermore, the range of test data metadata values ​​for test case A in the candidate test case group is measured, and the numerical span of this range from the minimum boundary value to the maximum boundary value is calculated. The result is the length of the range of test case A.

[0036] Furthermore, the range of test data metadata values ​​for test case B in the candidate test case group is measured, and the numerical span of this range from the minimum boundary value to the maximum boundary value is calculated. The result is the length of the range of test case B.

[0037] Furthermore, in the candidate test case group, after determining the minimum and maximum boundary values ​​of the data value range of test case A, the intermediate value of these two boundary values ​​is calculated. This intermediate value is the center point of the value range of test case A.

[0038] Furthermore, in the candidate test case group, after determining the minimum and maximum boundary values ​​of the data value range of test case B, the intermediate value of these two boundary values ​​is calculated. This intermediate value is the center point of the value range of test case B.

[0039] Furthermore, based on the specific scenario requirements for test case selection and the characteristics of test data elements, a fixed value is pre-set before the entire test case selection process begins. This value is used to adjust the degree of influence of the distance between the center points of the test case value range on the subsequent calculation results. This fixed value is the preset scaling parameter.

[0040] Furthermore, the formula calculates a substantial overlap index, comparing the length of the overlapping portion of the value ranges of two test cases with the shorter value range of the two, to obtain the proportion of the overlap length in the shorter value range. At the same time, it combines the distance between the center points of the value ranges of the two test cases and adjusts the influence of this distance on the result in a specific way, ultimately obtaining an index value that reflects whether the overlap of the value ranges of the two test cases has practical significance.

[0041] Furthermore, when the value range overlap substantiality index calculated by this formula reaches a set reasonable threshold, it can be determined that the value range overlap of two test cases in the candidate test case group is substantial. Based on these test cases that pass the determination, a cluster of similar test cases of a class of test cases can be accurately obtained for test case screening. This ensures that the similarity of test cases in a cluster of similar test cases is real and effective, avoiding misjudgment of similar test cases due to accidental small overlaps, and providing a reliable foundation for a cluster of similar test cases of a class of test cases for subsequent accurate screening of target test cases.

[0042] In summary, the test data elements corresponding to each test case are extracted from the standardized input descriptor. Combining the type of the test data element, the test scenario to which it belongs, and the constraints of the test requirements on the data element, the minimum and maximum boundary values ​​of each test data element are determined, thereby defining the range of data values ​​of the test data elements in the standardized input descriptor.

[0043] In general, the process involves first listing the data value ranges of all test data elements corresponding to all test cases, then grouping the test cases according to the type of test data elements, and then comparing the data value ranges of any two test cases within each group to determine if there are any mutually inclusive numerical ranges. If so, an association record is established for these two test cases, and all association records together constitute the value range overlap relationship for test case screening.

[0044] In general, the process involves organizing the established value range overlap relationships and grouping test cases that have direct or indirect relationships together. Direct relationship means that there is a clear value range overlap relationship between two test cases, while indirect relationship means that two test cases establish a value range overlap relationship through a third test case. This ensures that test cases in the same set have a common value range. Each such set is a candidate test case group for test case screening.

[0045] In general, the analysis involves examining the data value range of any two test cases within a candidate test case group. By comprehensively judging the proportion of the overlapping length of the two test cases to the shorter value range, and whether the distance between the center points of the two value ranges is within a reasonable range, the study verifies whether the overlap of the two value ranges has practical significance. The candidate test case group that passes this verification is identified as a cluster of similar test cases for test case screening.

[0046] S3. Test cases with consistent operation instruction sequence structures in the standardized input descriptors are selected as a cluster of two similar test cases for the test cases. In this embodiment of the invention, the step of using test cases with consistent operation instruction sequence structures in the standardized input descriptors as a cluster of two similar test cases for test case screening includes: Separate the basic instruction elements and execution order of the operation instruction sequence to obtain the instruction element sequence selected by the use case; Based on the sequential relationship and dependencies of instruction execution in the instruction element sequence, construct the structural mapping relationship for the use case screening; Based on the structural mapping relationship, test cases with the same instruction elements and consistent logical associations in the test case screening are selected to obtain the candidate instruction similarity group of the test case screening; Verify the structural consistency of the operation instruction sequences in the candidate instruction similarity group to obtain the two types of similar test case clusters selected by the test cases.

[0047] Specifically, the sequence of operation instructions corresponding to each test case is extracted from the standardized input descriptor. Each operation instruction in the sequence is then broken down, and the target operation and the specific operation action to be performed for each instruction are identified. The target operation and the operation action are integrated to form the basic instruction elements of each instruction. At the same time, according to the order in which these operation instructions are triggered and executed in the actual test scenario, all the decomposed basic instruction elements are arranged in sequence to form a sequence that contains both basic instruction elements and reflects the execution order. This sequence is the instruction element sequence for test case selection.

[0048] Furthermore, the obtained instruction element sequence is analyzed segment by segment. First, the execution position of each instruction in the sequence is determined, clarifying the succession relationship that the next instruction can only be started after the previous instruction is executed, thus forming the order of instruction execution. Then, it is checked whether each instruction has any constraints that require the execution result of other specific instructions to function properly. For example, a data modification instruction needs to rely on the previous data read instruction to obtain the initial value before it can be executed, thus sorting out the dependencies of all instructions. Afterward, the sorted order of instruction execution and dependencies are presented in a one-to-one correspondence, for example, by constructing a structural mapping relationship for use case screening through the correspondence record between instruction number and associated instruction number.

[0049] Furthermore, the structural mapping relationships corresponding to different test cases are compared one by one. First, it is checked whether the types and specific contents of the basic instruction elements contained in the structural mapping relationships of the two test cases being compared are completely identical, ensuring that there are no missing or different instruction elements. Then, it is checked whether the execution order and dependency conditions reflected by these basic instruction elements in the structural mapping relationship are completely matched. That is, in test case A, instruction one is executed before instruction two and instruction three depends on instruction one, and test case B must also satisfy the same logical association. Test cases that simultaneously satisfy the same basic instruction elements and consistent logical associations are grouped into a set, which is the candidate instruction similarity group for test case screening.

[0050] Furthermore, a comprehensive review of the operation instruction sequences of all test cases within the candidate instruction similarity group is conducted. First, it is confirmed that the types and quantities of basic instruction elements in the operation instruction sequence of each test case within the group are completely consistent, and there is no situation where a test case contains more or fewer instruction elements. Next, it is checked whether the execution order of the same basic instruction elements in all test cases is completely identical, ensuring that there is no difference in the instruction execution order. Finally, it is verified whether the dependency conditions between each instruction are completely consistent, that is, the dependency relationship between any two instructions remains consistent in all test cases within the group. After verifying that all aspects are consistent, the candidate instruction similarity group is determined to satisfy the structural consistency of the operation instruction sequence, and this candidate instruction similarity group is the second-class similarity test case cluster for test case screening.

[0051] In summary, the process involves extracting the sequence of operation instructions corresponding to each test case from the standardized input descriptor, breaking down each operation instruction in the sequence to identify the operation object and the specific operation action, integrating the two into basic instruction elements, and then arranging all basic instruction elements in an orderly manner according to the execution order of the operation instructions in the actual test, ultimately obtaining the instruction element sequence for test case selection.

[0052] In general, the analysis involves analyzing the sequence of instruction elements. First, the execution relationship between each instruction in the sequence is clarified, and the order of the preceding and following instructions is determined. Then, it is identified whether each instruction depends on the execution result of other preceding instructions to start. The dependencies of all instructions are sorted out, and then these sequential relationships and dependencies are organized and presented in a corresponding association form to construct a structural mapping relationship for use case selection.

[0053] In general, the structural mapping relationships of different test cases are compared one by one. First, it is confirmed that the basic instruction elements contained in the compared test cases are completely the same in terms of type and content. Then, it is checked that these instruction elements maintain logical consistency in terms of execution sequence and dependency conditions. Test cases that meet both conditions are grouped into a set to obtain candidate instruction similarity groups for test case screening.

[0054] In summary, a comprehensive review is conducted on all test cases within the candidate instruction similarity group to confirm that the types and quantities of basic instruction elements, the order of instruction execution, and the dependencies between instructions are completely consistent in the operation instruction sequence of each test case within the group. This verifies the structural consistency of the operation instruction sequence, and the candidate instruction similarity group that passes the verification is determined as the second-class similar test case cluster for test case screening.

[0055] S4. Gather the first type of similar test case cluster and the second type of similar test case cluster to form the similar test case domain for the test cases; In this embodiment of the invention, the aggregation of the first type of similar test case cluster and the second type of similar test case cluster, which constitutes the similar test case domain for the test case selection, includes: Identify test cases that coexist in both the first type of similar test case cluster and the second type of similar test case cluster to obtain the common test case group for the test case screening. The non-shared test cases in the first type of similar test case cluster and the second type of similar test case cluster are summarized, and test cases with a single similarity feature are added to obtain the test case set for the test case selection. The integrity of the test case set is verified to obtain the similar test case domains selected from the test cases.

[0056] Specifically, first, list all test cases contained in a cluster of similar test cases of the first type to form a list of test cases of the first type. At the same time, list all test cases contained in a cluster of similar test cases of the second type to form a list of test cases of the second type. Select the first test case from the list of test cases of the first type and check whether the test case exists in the list of test cases of the second type. If it exists, mark it as a test case to be assigned to the common group. In the same way, check whether each test case in the list of test cases of the first type exists in the list of test cases of the second type. Collect all test cases that exist in both lists together. The set formed is the common test case group for test case screening.

[0057] Furthermore, firstly, from all test cases in a cluster of similar test cases of the first type, test cases that have already been assigned to a common test case group are removed, resulting in non-common test cases in the cluster of similar test cases of the first type. Then, from all test cases in a cluster of similar test cases of the second type, test cases that have already been assigned to a common test case group are removed, resulting in non-common test cases in the cluster of similar test cases of the second type. The obtained non-common test cases of the first type and the second type are merged. These merged non-common test cases all have only one or two similar features, belonging to single similarity feature test cases. The merged single similarity feature test cases are integrated with the previously obtained common test case group to form a complete set, which is the test case set for test case filtering.

[0058] Furthermore, first, obtain the total number of test cases contained in the initial type I and type II similar test case clusters, as the baseline total number for verification; then, count the number of test cases contained in the currently obtained test case set, and compare this number with the baseline total number. If the number is inconsistent, it indicates that there are omissions in the test case set, and the process of summarizing non-common test cases needs to be checked again to supplement the missing test cases; if the number is consistent, then check one by one whether each test case in the type I similar test case cluster exists in the test case set, and at the same time check whether each test case in the type II similar test case cluster exists in the test case set, to ensure that no test case in any original cluster is omitted; when it is confirmed that the test case set contains all test cases of the type I and type II similar test case clusters and there are no additional irrelevant test cases, the test case set integrity verification is determined to be passed, and the test case set that passes the verification is the similar test case domain for test case screening.

[0059] In general, the process involves first identifying all test cases contained in one type of similar test case cluster and the second type of similar test case cluster, forming two independent test case lists. Then, each test case in one list is compared to see if it exists in the other list. All test cases that exist in both lists are collected and integrated to obtain the common test case group for test case selection.

[0060] In general, the process involves first removing test cases that have been assigned to a common test case group from a cluster of similar test cases of the first type, and then filtering out the non-common test cases in that cluster. At the same time, test cases that have been assigned to a common test case group from a cluster of similar test cases of the second type are also removed, and then the non-common test cases in that cluster are filtered out. These non-common test cases all have only one or two types of similarity features. Then, the two groups of non-common test cases are summarized and combined with the common test cases to form the test case set for test case filtering.

[0061] In general, the process involves first counting the total number of test cases contained in the initial first-class and second-class similar test case clusters as the verification benchmark. Then, the number of test cases in the current test case set is counted and compared with the benchmark total. If the numbers match, each test case in the two original clusters is checked one by one to ensure that it exists in the test case set. Once it is confirmed that no test cases from any original cluster are missing and there are no additional irrelevant test cases, the test case set completeness verification is deemed to have passed. The test case set that has passed the verification is the similar test case domain for test case screening.

[0062] S5. Separate the state code and output data pattern of the expected output description in the similar test case domain; In this embodiment of the invention, separating the state code and output data pattern of the expected output description in the similar test case domain includes: Separate the state description portion and the data output portion of the expected output description in the similar test case domain; The feature information of the execution result in the state description section is standardized and encoded to obtain the state code for the use case screening.

[0063] The data organization and content characteristics of the data output section are analyzed to obtain the output data pattern for the use case selection.

[0064] Specifically, when separating the state description and data output parts of the expected output description in similar test case domains, first clarify the complete text content of the expected output description, perform semantic analysis on the text sentence by sentence, and determine the core purpose of each sentence. If the text is used to qualitatively describe the result state after the test case is executed, then the text is classified into the state description part. If the text is used to present specific quantitative or structured information generated after the test case is executed, then the text is classified into the data output part. This ensures that the state description part and the data output part completely cover all qualitative state descriptions and quantitative data presentations in the expected output description, and that the two parts have no overlap or omissions.

[0065] Furthermore, when standardizing and encoding the feature information of the execution result in the status description section to obtain the status code for test case screening, firstly, all feature information directly related to the execution result is extracted from the status description section. This feature information needs to cover the nature of the execution result, the business scenario corresponding to the execution result, and the impact of the execution result. Then, a fixed and unique encoding rule is pre-defined. This rule assigns a unique fixed character or number to each type of execution result's nature, business scenario, and impact. For example, the feature information corresponding to "successful execution in the data transmission scenario without affecting subsequent test case execution" is combined and assigned the code "TSU" according to the preset rule. Then, the extracted feature information combination is compared with the preset encoding rule one by one to find the code that matches perfectly. The code obtained by the match is the status code for test case screening.

[0066] Furthermore, when analyzing the data organization and content characteristics of the data output section to obtain the output data pattern for use case screening, the text of the data output section is first structurally decomposed to observe the presentation form of the data. It is determined whether the data is organized as a single independent data item, an ordered list, a key-value correspondence, a hierarchical nested structure, or a table. The relationship between different data units is clarified. Then, the specific attributes of each data unit in the data output section are analyzed to determine the data type, data format specifications, and data value constraints. Finally, the analyzed organization and content characteristics are integrated according to a fixed descriptive framework to form a fixed specification that can accurately reflect the structure and attributes of the data output section. This specification is the output data pattern for use case screening.

[0067] In summary, by separating the state description and data output portions of the expected output descriptions in similar test case domains, we can clearly distinguish between qualitative descriptions and quantitative presentations in the expected output, avoiding confusion between the two types of information. Furthermore, by standardizing and encoding the characteristic information of the execution results in the state description portion to obtain the state code for test case screening, different forms of state descriptions can be transformed into a unified and standardized coding format, ensuring the consistency and identifiability of state information. Simultaneously, by analyzing the data organization and content characteristics of the data output portion to obtain the output data pattern for test case screening, we can clarify the specific form and core characteristics of the data output, making the data-related information more organized. These operations together provide accurate, standardized, and reliable references for subsequent test case screening, effectively reducing screening bias caused by unclear or inconsistent information, improving the accuracy and efficiency of test case screening, and ensuring that the selected test cases accurately match the testing requirements.

[0068] S6. When the status code is consistent with the output data pattern, the redundancy identification result of the use case screening is obtained; In this embodiment of the invention, obtaining the redundancy identification result of the use case screening when the state code is consistent with the output data pattern includes: For the same execution results in the state codes, a state homogeneity determination is performed to obtain the state consistency result of the used case screening; Confirm the correspondence between the structure and content in the output data pattern to obtain the data matching results of the use case filtering; When the state consistency result and the data matching result are both confirmed to be consistent, it is determined that there is a redundant relationship between the test cases, and the redundancy identification result of the test case screening is obtained.

[0069] Specifically, the expected output description text for each test case in the similar test case domain is first obtained. The text content is analyzed sentence by sentence to identify the part describing the state of the test execution result. This part is usually used to explain whether the execution was successful, whether an exception occurred, and the type of exception, etc., which are non-data information. This part is identified as the state description part. At the same time, the part describing the specific output data is identified. This part usually includes quantifiable or structured information such as returned values, text, and data structures. This part is identified as the data output part. This completes the separation of the state description part and the data output part of the expected output description in the similar test case domain.

[0070] Furthermore, we first analyze all possible execution result features in the status description section, including specific features such as execution success identifiers, execution failure reasons, and exception triggering scenarios. Then, we pre-define unified standardized coding rules, assigning a unique and fixed coding symbol to each specific execution result feature to ensure that the same feature corresponds to the same code, and different feature corresponds to different codes. After that, we match the execution result feature information in the status description section of each test case with the feature items in the standardized coding rules, and convert the feature information into the corresponding coding symbol based on the matching result. The converted coding symbol is the status code for test case selection.

[0071] Furthermore, first analyze the presentation format of the data output section to determine whether it is a single independent data entry, a list of multiple ordered data entries, or key-value pair related data, and record the specific manifestation of this organizational form; then further analyze the content characteristics of the data in the data output section, including the data type, data format requirements, and the relationships between data; integrate the analyzed data organization forms and content characteristics to form a standardized form that can uniformly describe the characteristics of the data output section, and this standardized form is the output data pattern for use case screening.

[0072] In general, the approach involves starting with the expected output description text of each test case in the similar test case domain, analyzing the text content sentence by sentence, identifying the non-data information such as whether the execution was successful or whether any exceptions occurred as the status description part, and identifying the part containing quantifiable or structured information such as specific values, text, and data structures as the data output part. This process separates the status description part and the data output part of the expected output description in the similar test case domain.

[0073] In general, the process involves first sorting out all the feature information related to execution results in the status description section, such as execution success indicators and execution failure reasons. Then, a unified standardized coding rule is pre-defined to assign a unique and fixed coding symbol to each specific execution result feature information. After that, the execution result feature information in the status description section of each test case is matched with the feature items in the coding rule, and the matching result is converted into the corresponding coding symbol to finally obtain the status code for test case screening.

[0074] In general, the process involves first analyzing the presentation format of the data output to determine whether it is a single data entry, an ordered list of data, or key-value pairs, thus establishing the data organization format. Next, the data types, format requirements, and interrelationships within the output data are analyzed to clarify the data content characteristics. Finally, the established data organization format and the identified data content characteristics are integrated to form a standardized format that uniformly describes the characteristics of the data output. This standardized format is the output data pattern for use case filtering.

[0075] S7. Based on the redundancy identification results, remove redundant test cases from the test case filtering to obtain the target test cases for the test case filtering.

[0076] In this embodiment of the invention, the step of removing redundant test cases from the test case screening based on the redundancy identification result to obtain the target test cases for the test case screening includes: Locate the test cases marked in the redundancy identification results at their corresponding positions in the test case filtering to obtain the list of test cases to be removed from the test case filtering; Delete the test cases from the list of test cases to be removed to obtain the preliminary filter set for test case filtering; Verify the completeness of the functional coverage of the test cases retained in the initial screening set to obtain the target test cases for the selected test cases.

[0077] Specifically, first, the redundancy identification results are obtained. These results contain unique identifiers for all test cases marked as redundant. These unique identifiers can be the test case's name, number, or unique identification code. Next, the original test case set used for filtering is retrieved. Each test case in this set has a specific storage location record, which includes the test case's index position in the set and its associated classification information. The unique identifier of each redundant test case in the redundancy identification results is matched one by one with the test case identifiers in the original test case set. Based on the matching results, the specific storage location of each redundant test case in the original set is determined. The identifiers and corresponding location information of all redundant test cases with determined locations are organized into a structured list, which is the list of test cases to be removed during test case filtering.

[0078] Further, first obtain the original test case set for filtering and the generated list of test cases to be removed. Then, compare each test case in the original test case set with the test cases in the list of test cases to be removed, based on the unique identifier of the test case. If the unique identifier of a test case in the original set does not appear in the list of test cases to be removed, then the test case is determined to be a test case to be retained. Repeat the above process to compare and filter all test cases in the original set one by one, collect all the test cases determined to be retained, and integrate these retained test cases to form a new test case set. This set is the preliminary filtering set for test case filtering.

[0079] Further, first, obtain the test requirement document corresponding to this test case selection, and extract a list of all functional points that need to be covered from the document. The list clearly records the specific test objectives and verification requirements for each functional point. Then, match each retained test case in the preliminary selection set with the functional point list one by one, checking whether the test objective of each test case is consistent with the test objective of a certain functional point, and whether the test steps of the test case can effectively verify the normal execution or abnormal scenarios of the corresponding functional point. If each functional point in the functional point list can find at least one matching retained test case in the preliminary selection set, the functional coverage of the preliminary selection set is considered complete. If there are unmatched functional points, the list of test cases to be removed needs to be re-checked to confirm whether test cases covering the functional point have been mistakenly deleted. If they have been mistakenly deleted, they are added back to the preliminary selection set until all functional points are covered. When the preliminary selection set meets the functional coverage completeness requirements, the preliminary selection set is the target test case for test case selection.

[0080] In summary, the process involves first obtaining the unique identifiers of all test cases marked as redundant in the redundancy identification results, then retrieving the original test case set used for filtering, and determining the specific storage location of each redundant test case in the original set by matching the unique identifiers of the redundant test cases with the identifiers of the test cases in the original set one by one. Finally, the identifiers and corresponding location information of these redundant test cases are organized into a structured list to obtain the list of test cases to be removed for filtering.

[0081] In general, the process involves first obtaining the original test case set and the list of test cases to be removed. Each test case in the original set is then compared with the test cases in the list of test cases to be removed. Test cases whose identifiers do not appear in the list of test cases to be removed are identified as test cases to be retained. Finally, all test cases to be retained are integrated to form a new test case set, resulting in the initial set of test case selection.

[0082] In general, the process involves first extracting a list of all functionalities that need to be covered from the test requirements document, then matching each retained test case in the initial screening set with the list of functionalities one by one to check whether each test case can effectively cover the corresponding functionalities. If there are any uncovered functionalities, the initial screening set is adjusted until all functionalities are covered. At this point, the initial screening set that meets the functional coverage integrity requirements is the target test case for test case screening.

[0083] Example 2

[0084] like Figure 2 As shown in the figure, this embodiment also provides a functional block diagram of a test case screening device.

[0085] The test case filtering device 100 described in this embodiment can be installed in a storage medium. Depending on its functionality, the test case filtering device 100 may include a standardized input descriptor generation module 101, a single-type similar test case cluster partitioning module 102, a double-type similar test case cluster partitioning module 103, a similar test case domain construction module 104, an expected output feature separation module 105, a redundant test case identification module 106, and a target test case filtering module 107. The module described in this invention can also be called a unit, which refers to a series of computer program segments that can be executed by the storage medium's processor and perform a fixed function, stored in the storage medium's memory.

[0086] In this embodiment, the functions of each module / unit are as follows: The standardized input descriptor generation module 101 is used to extract test data items and operation instruction items of input conditions in test case screening to obtain the standardized input descriptor of the test case screening. The similar test case cluster partitioning module 102 is used to take test cases with overlapping value domains in the standardized input descriptors as a similar test case cluster for the test case screening. The binary similar test case clustering module 103 is used to take test cases with consistent operation instruction sequence structures in the standardized input descriptors as binary similar test case clusters for test case screening. The similar test case domain construction module 104 is used to gather the first type of similar test case cluster and the second type of similar test case cluster to form the similar test case domain for the test cases; The expected output feature separation module 105 is used to separate the state code and output data pattern of the expected output description in the similar test case domain; The redundant test case identification module 106 is used to obtain the redundancy identification result of the test case screening when the status code is consistent with the output data pattern. The target test case filtering module 107 is used to remove redundant test cases in the test case filtering based on the redundancy identification results, so as to obtain the target test cases of the test case filtering.

[0087] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0088] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0089] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for selecting test cases, characterized in that, The method includes: S1. Extract the test data items and operation instruction items of the input conditions in the test case filtering to obtain the standardized input descriptor of the test case filtering; S2. The test cases with overlapping value ranges in the standardized input descriptors are taken as a cluster of similar test cases for the test case screening. S3. Test cases with consistent operation instruction sequence structures in the standardized input descriptors are selected as a cluster of two similar test cases for the test cases. S4. Gather the first type of similar test case cluster and the second type of similar test case cluster to form the similar test case domain for the test cases; S5. Separate the state code and output data pattern of the expected output description in the similar test case domain; S6. When the status code is consistent with the output data pattern, the redundancy identification result of the use case screening is obtained; S7. Based on the redundancy identification results, remove redundant test cases from the test case filtering to obtain the target test cases for the test case filtering.

2. The test case selection method as described in claim 1, characterized in that, The process of extracting test data items and operation instruction items from the input conditions in the test case filtering yields the standardized input descriptor for the test case filtering, including: Extract the data input elements and instruction execution flow of the input conditions in the test case filtering to obtain the input element set of the test case filtering; The representation format of the input element data in the input element set is standardized to obtain the standard test data items for the use case screening. The key operation instructions in the input element set are used as the standard operation instructions for the use case screening. The standard test data items and the standard operation instructions are integrated and encapsulated to obtain the standardized input descriptor for the test case screening.

3. The test case selection method as described in claim 1, characterized in that, The step of selecting test cases with overlapping value ranges in the standardized input descriptors as a cluster of similar test cases for the test case screening includes: Define the range of data values ​​for test data elements in the standardized input descriptor; Based on the numerical intervals that intersect within the data value range, establish the value range overlap relationship for the use case screening; Based on the value range overlap relationship, test cases with common value ranges are filtered in the test case filtering to obtain the candidate test case group of the test case filtering; To verify the substantial overlap of value ranges in the candidate test case group, a cluster of similar test cases is obtained by filtering the test cases. The formula for calculating the substantial overlap index of the value ranges of the candidate test case group is as follows: ； In the formula, The value range overlap substantive index, The length of the overlapping interval of the value range overlap relationship. Test cases within the range of data values The length of the value range, Test cases within the range of data values The length of the value range, Test cases within the range of data values The center point of the value range Test cases within the range of data values The center point of the value range These are the preset scaling parameters.

4. The test case selection method as described in claim 1, characterized in that, The test cases with consistent operation instruction sequence structures in the standardized input descriptors are selected as the second type of similar test case clusters for test case screening, including: Separate the basic instruction elements and execution order of the operation instruction sequence to obtain the instruction element sequence selected by the use case; Based on the sequential relationship and dependencies of instruction execution in the instruction element sequence, construct the structural mapping relationship for the use case screening; Based on the structural mapping relationship, test cases with the same instruction elements and consistent logical associations in the test case screening are selected to obtain the candidate instruction similarity group of the test case screening; Verify the structural consistency of the operation instruction sequences in the candidate instruction similarity group to obtain the two types of similar test case clusters selected by the test cases.

5. The test case selection method as described in claim 1, characterized in that, The aggregation of the first type of similar test case cluster and the second type of similar test case cluster, which forms the similar test case domain for the test cases, includes: Identify test cases that coexist in both the first type of similar test case cluster and the second type of similar test case cluster to obtain the common test case group for the test case screening. The non-shared test cases in the first type of similar test case cluster and the second type of similar test case cluster are summarized, and test cases with a single similarity feature are added to obtain the test case set for the test case selection. The integrity of the test case set is verified to obtain the similar test case domains selected from the test cases.

6. The test case selection method as described in claim 1, characterized in that, The process of separating the state encoding and output data pattern of the expected output description in the similar test case domain includes: Separate the state description portion and the data output portion of the expected output description in the similar test case domain; The feature information of the execution result in the state description section is standardized and encoded to obtain the state code for the use case screening. The data organization and content characteristics of the data output section are analyzed to obtain the output data pattern for the use case selection.

7. The test case selection method as described in claim 1, characterized in that, When the state code matches the output data pattern, the redundancy identification result of the use case screening is obtained, including: For the same execution results in the state codes, a state homogeneity determination is performed to obtain the state consistency result of the used case screening; Confirm the correspondence between the structure and content in the output data pattern to obtain the data matching results of the use case filtering; When the state consistency result and the data matching result are both confirmed to be consistent, it is determined that there is a redundant relationship between the test cases, and the redundancy identification result of the test case screening is obtained.

8. The test case selection method as described in claim 1, characterized in that, Based on the redundancy identification results, redundant test cases are removed from the test case filtering to obtain the target test cases for the test case filtering, including: Locate the test cases marked in the redundancy identification results at their corresponding positions in the test case filtering to obtain the list of test cases to be removed from the test case filtering; Delete the test cases from the list of test cases to be removed to obtain the preliminary filter set for test case filtering; Verify the completeness of the functional coverage of the test cases retained in the initial screening set to obtain the target test cases for the selected test cases.

9. A test case screening device, characterized in that, include: The standardized input descriptor generation module is used to extract test data items and operation instruction items of input conditions in test case filtering to obtain the standardized input descriptor of the test case filtering. A similar test case cluster partitioning module is used to identify test cases with overlapping value ranges in the standardized input descriptors as a similar test case cluster for the test cases to be filtered. The binary similar test case cluster partitioning module is used to identify test cases with consistent operation instruction sequence structures in the standardized input descriptors as binary similar test case clusters for test case filtering. The similar test case domain construction module is used to gather the first type of similar test case cluster and the second type of similar test case cluster to form the similar test case domain for the test cases. The expected output feature separation module is used to separate the state code and output data pattern of the expected output description in the similar test case domain; A redundant test case identification module is used to obtain the redundancy identification result of the test case screening when the status code is consistent with the output data pattern. The target test case filtering module is used to remove redundant test cases from the test case filtering based on the redundancy identification results, so as to obtain the target test cases of the test case filtering.

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

Images