A test case processing method and system

Abstract

This application discloses a test case processing method and system. The method determines the test case type. If the test case type is a performance test case, a first assertion sequence expected value is obtained, which is used to detect the execution status of the test case corresponding to the performance test case type. If the test case type is a functional test case, a second assertion sequence expected value is obtained, which is used to detect the execution status of the test case corresponding to the functional test case type. This approach eliminates the need for manually setting assertion expected values, avoiding errors caused by human intervention and improving the accuracy and quality of test case testing. Furthermore, by processing test cases of different types, separate assertion sequence expected values ​​are obtained for each type, improving the granularity of test case testing.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a test case processing method and system. Background Technology

[0002] The accuracy of testing each case directly impacts the stable operation of financial institutions. Setting assertions for test cases during the testing process is a common practice for verifying the success of test case execution.

[0003] Assertions are a technique used to compare the output value of a test case with its expected value, and their use can improve code quality. The correctness of the assertion's expected value directly affects the test results. Currently, the expected value of an assertion is generally set manually as a static value and bound to the test case.

[0004] Currently, manually setting static assertion expectations cannot meet the ever-growing demand for automated testing. Furthermore, manually setting assertion expectations can lead to the generation of incorrect assertion expectations, resulting in reduced accuracy and quality of testing test cases. Summary of the Invention

[0005] In view of this, this application discloses a test case processing method and system, which aims to improve the accuracy, test quality and granularity of testing test cases.

[0006] To achieve the above objectives, the disclosed technical solution is as follows:

[0007] The first aspect of this application discloses a test case processing method, the method comprising:

[0008] Determine the case type of the test cases to be tested; the case types include performance test case types and functional test case types;

[0009] If the test case type is the performance test case type, then the test case corresponding to the performance test case type is calculated using a pre-built performance test metric assertion sequence expected value model to obtain the first assertion sequence expected value; the first assertion sequence expected value is used to detect the execution status of the test case corresponding to the performance test case type.

[0010] If the test case type is the functional test case type, then the test case corresponding to the functional test case type is matched with the pre-built functional test case assertion sequence library, and the second assertion sequence expected value is obtained according to the matching result; the second assertion sequence expected value is used to detect the execution status of the test case corresponding to the functional test case type.

[0011] Preferably, if the test case type is the performance test case type, then the test case corresponding to the performance test case type is calculated using a pre-built performance test metric assertion sequence expected value model to obtain the first assertion sequence expected value, including:

[0012] Obtain system features and case features;

[0013] The system features and case features are standardized and multicollinearity is eliminated to obtain the processing results.

[0014] Based on a pre-established linear regression model, determine the model coefficients;

[0015] A performance test metric assertion sequence expected value model is constructed using the model coefficients and the processing results.

[0016] The first assertion sequence expected value is obtained by calculating the features of the test case corresponding to the performance test case type using the performance test indicator assertion sequence expected value model.

[0017] Preferably, after calculating the features of the test case corresponding to the performance test case type using the performance test metric assertion sequence expected value model to obtain the first assertion sequence expected value, the method further includes:

[0018] An assertion library for performance test cases is established using the system features, the case features, and pre-acquired preset historical performance test cases.

[0019] Obtain the actual value of the assertion sequence; the assertion sequence is predicted by the performance test metric assertion sequence expected value model.

[0020] Compare whether the expected value of the first assertion sequence is consistent with the actual value of the assertion sequence;

[0021] If they match, delete the test case corresponding to the performance test case type.

[0022] If they are inconsistent, the features of the test case corresponding to the performance test case type and the actual value of the assertion sequence are stored in the assertion library of the performance test case.

[0023] Preferably, if the test case type is the functional test case type, then the test case corresponding to the functional test case type is matched with a pre-built functional test case assertion sequence library, and the expected value of the second assertion sequence is obtained based on the matching result, including:

[0024] Decompose the test cases corresponding to the functional test case type to obtain the characteristics of the test cases corresponding to the functional test case type; the characteristics of the test cases include method name, interface name, number of input parameters, input parameter list and cyclomatic complexity of the interface;

[0025] By using a preset hierarchical matching method, the features of the test case corresponding to the functional test case type are matched with preset features in the pre-built functional test case assertion sequence library to obtain the matching result. Based on the matching result, the second assertion sequence expected value of the test case corresponding to the functional test case type is generated.

[0026] Preferably, the step of matching the features of the test case with preset features in the functional test case assertion sequence library using a preset hierarchical matching method to obtain a matching result, and generating a second assertion sequence expected value for the test case corresponding to the functional test case type based on the matching result, includes:

[0027] The method names, interface names, number of input parameters, input parameter lists, and cyclomatic complexity of the interfaces in the functional test case assertion sequence library are sorted according to a preset sorting rule to obtain the sorted method names, sorted interface names, sorted number of input parameters, sorted input parameter lists, and sorted cyclomatic complexity of the interfaces.

[0028] Match the method names of the test cases with the sorted method names;

[0029] If the method name of the test case matches the sorted method names, then the interface name of the test case is matched with the sorted interface names.

[0030] If the interface name of the test case matches the sorted interface name, then the number of input parameters of the test case is matched with the number of input parameters in the sorted order.

[0031] If the number of input parameters of the test case matches the number of input parameters after sorting, then the input parameter list of the test case is matched with the sorted input parameter list.

[0032] If the input parameter list of the test case matches the sorted input parameter list, then the cyclomatic complexity of the interface of the test case is matched with the cyclomatic complexity of the sorted interface.

[0033] If the cyclomatic complexity of the interface of the test case matches the cyclomatic complexity of the sorted interfaces, then the expected value of the second assertion sequence of the test case corresponding to the functional test case type is generated.

[0034] Preferred options also include:

[0035] If any set of test cases fails to match the features in the functional test case assertion sequence library, then the features of the next test case corresponding to the functional test case type will be matched.

[0036] A second aspect of this application discloses a test case processing system, the system comprising:

[0037] A determination unit is used to determine the case type of the test case; the case type includes performance test case type and functional test case type;

[0038] The calculation unit is configured to, if the test case type is the performance test case type, calculate the test case corresponding to the performance test case type using a pre-built performance test metric assertion sequence expected value model to obtain a first assertion sequence expected value; the first assertion sequence expected value is used to detect the execution status of the test case corresponding to the performance test case type.

[0039] The matching unit is configured to, if the test case type is the functional test case type, match the test case corresponding to the functional test case type with a pre-built functional test case assertion sequence library, and obtain a second assertion sequence expected value based on the matching result; the second assertion sequence expected value is used to detect the execution status of the test case corresponding to the functional test case type.

[0040] Preferably, the computing unit includes:

[0041] The acquisition module is used to acquire system features and case features;

[0042] The processing module is used to standardize the system features and the case features and eliminate multicollinearity to obtain the processing results;

[0043] The determination module is used to determine the model coefficients based on a pre-established linear regression model;

[0044] The construction module is used to construct a performance test index assertion sequence expected value model using the model coefficients and the processing results;

[0045] The calculation module is used to calculate the features of the test case corresponding to the performance test case type using the performance test indicator assertion sequence expected value model, and obtain the first assertion sequence expected value.

[0046] Preferred options also include:

[0047] A building unit is used to build an assertion library for performance test cases based on the system features, the case features, and pre-acquired preset historical performance test cases.

[0048] An acquisition unit is used to acquire the actual value of the assertion sequence; the assertion sequence is predicted by the performance test metric assertion sequence expected value model.

[0049] A comparison unit is used to compare whether the expected value of the first assertion sequence is consistent with the actual value of the assertion sequence;

[0050] The deletion unit is used to delete the test case corresponding to the performance test case type if the results are consistent.

[0051] A storage unit is used to store the features of the test case corresponding to the performance test case type and the actual value of the assertion sequence into the assertion library of the performance test case if there is a discrepancy.

[0052] Preferably, the matching unit includes:

[0053] The decomposition module is used to decompose the pre-acquired test cases to obtain the characteristics of the test cases; the characteristics of the test cases include method name, interface name, number of input parameters, input parameter list, and cyclomatic complexity of the interface;

[0054] The matching module is used to match the features of the test case corresponding to the functional test case type with the preset features in the pre-built functional test case assertion sequence library using a preset hierarchical matching method, obtain the matching result, and generate the second assertion sequence expected value of the test case corresponding to the functional test case type based on the matching result.

[0055] As described above, this application discloses a test case processing method and system. The method determines the test case type, which includes performance test case types and functional test case types. If the test case type is a performance test case type, a first assertion sequence expected value is obtained by calculating the test case corresponding to the performance test case type using a pre-built performance test indicator assertion sequence expected value model. This first assertion sequence expected value is used to detect the execution status of the test case corresponding to the performance test case type. If the test case type is a functional test case type, a second assertion sequence expected value is obtained by matching the test case corresponding to the functional test case type with a pre-built functional test case assertion sequence library, and the second assertion sequence expected value is used to detect the execution status of the test case corresponding to the functional test case type. This method eliminates the need for manual setting of assertion expected values, avoiding the generation of incorrect assertion expected values ​​due to human error, and improving the accuracy of test case testing. Furthermore, by processing test cases of different case types, the expected values ​​of assertion sequences corresponding to different case types are obtained, thereby improving the fine-grainedness of testing test cases. Attached Figure Description

[0056] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0057] Figure 1 This is a flowchart illustrating a test case processing method disclosed in an embodiment of this application;

[0058] Figure 2 This is a schematic diagram illustrating the interface call relationships disclosed in the embodiments of this application;

[0059] Figure 3 This is a schematic diagram illustrating the cyclomatic complexity disclosed in the embodiments of this application;

[0060] Figure 4 This is a schematic diagram of the process for obtaining the expected value of the second assertion sequence as disclosed in an embodiment of this application;

[0061] Figure 5 This is a schematic diagram of the structure of a test case processing system disclosed in an embodiment of this application;

[0062] Figure 6 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application. Detailed Implementation

[0063] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0064] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0065] As can be seen from the background technology, the current method of manually setting static assertion expected values ​​cannot meet the ever-expanding demand for automated testing. At the same time, because manually setting assertion expected values ​​leads to the generation of incorrect assertion expected values, it reduces the accuracy and quality of testing test cases.

[0066] To address the aforementioned issues, this application discloses a test case processing method and system. This eliminates the need for manually setting assertion expected values, avoiding the generation of incorrect assertion expected values ​​due to human error, and improving the accuracy and quality of test case testing. Furthermore, by processing test cases of different types, assertion sequence expected values ​​corresponding to different case types are obtained, improving the fine-grained nature of test case testing. The specific implementation is described in detail in the following embodiments.

[0067] refer to Figure 1 The diagram shown is a flowchart illustrating a test case processing method disclosed in an embodiment of this application. The test case processing method mainly includes the following steps:

[0068] S101: Determine the case type of the test case; the case type includes performance test case type and functional test case type. If the case type of the test case is a performance test case type, then execute S102; if the case type of the test case is a functional test case type, then execute S103.

[0069] The number of test cases can be multiple.

[0070] The performance test case type corresponds to performance testing, which involves testing various performance indicators of the system by simulating normal, peak, and abnormal load conditions. Performance indicators include response time, maximum concurrency, etc.

[0071] The tests corresponding to the functional test case type are functional tests, which refer to verifying each function of the application version package and checking whether each function meets the user's requirements.

[0072] S102: The expected value of the first assertion sequence is obtained by calculating the test case corresponding to the performance test case type through the pre-built performance test metric assertion sequence expected value model; the expected value of the first assertion sequence is used to detect the execution status of the test case corresponding to the performance test case type.

[0073] In S102, an assertion sequence is a test case that often contains several sub-functions. The implementation of a sub-function usually includes two methods: internal and external.

[0074] In object-oriented programming languages, the internal mechanism is the method. In procedural programming languages, the internal mechanism is the function. The external mechanism is usually the calling interface. Each method (function) or interface return value can be set with an assertion. Several assertions are combined to form a sequence, with the format {{method (function) or interface number, assertion value}, {method (function) or interface number, assertion value}…}.

[0075] The expected value of the first assertion sequence is used to detect whether the execution of the test case corresponding to the performance test case type is successful or not.

[0076] The expected value of the first assertion sequence is formed by combining the expected values ​​of several assertions in a test case into a sequence, in the format {{method (function) or interface number, assertion expected value}, {method (function) or interface number, assertion expected value}...}.

[0077] The specific expected values ​​of the first assertion sequence are shown in A1-A5:

[0078] A1: Obtain system features and case features.

[0079] System characteristics refer to the basic attributes of the system, such as the size of the hardware resources of the devices, physical architecture, logical architecture, number of users, transaction volume, and other information.

[0080] Case characteristics refer to the basic attributes of a case, such as case number, which sub-functions it contains, sub-function numbers, method or interface name, input parameter list, number of input parameters, cyclomatic complexity, and interface call complexity.

[0081] A2: Standardize the system features and case features and eliminate multicollinearity to obtain the processing results.

[0082] Specifically, the process of standardizing system features and case features and eliminating multicollinearity to obtain the processing results is as follows:

[0083] (1) Standardize the system features and case features, classify them according to character values, and convert the feature values ​​from character type to numeric type, as shown in Table 1.

[0084] Feature Name Actual value (character type) After standardization (numerical type) Database version 11g 1 Database version 12c 2

[0085] Table 1

[0086] In this context, 11g and 12c are the actual values ​​of the database version. Numeric type 1 represents a standardized value for one database version, while numeric type 2 represents a standardized value for another database version.

[0087] (2) Use the variance inflation factor (VIF) to perform multicollinearity analysis on each feature, screen out the system features and case features with correlation, and eliminate multicollinearity.

[0088] Construct a linear regression model for each feature and the other features. Taking feature y1 as an example, feature y1 includes system features and case features. The specific calculation formula for feature y1 is shown in formula (1).

[0089] y1 = c2y2 + c3y3 + ... + c p y p +c0+ε (1)

[0090] Where y1 is the response time assertion value sequence; y2 is the concurrency assertion value sequence; y3 is the processing capacity assertion value sequence; c p For feature y p The regression coefficients with feature y1; y p c1 represents the sequence of assertion values ​​for performance index p; c2 represents the regression coefficients of feature y2 and feature y1; c3 represents the regression coefficients of feature y3 and feature y1; c p For feature y p The regression coefficients with feature y1; c0 is the constant term; ε is the random error term.

[0091] The decision coefficient R is obtained from the linear regression model. 2 Calculate the variance inflation factor of the first feature y1. If the VIF1 value is greater than 10, the feature is discarded from the sequence of independent variables in the performance test assertion expected value regression model; otherwise, it is added to the feature set, for example, {y1, y2, y5...}.

[0092] A3: Determine the model coefficients based on the pre-established linear regression model.

[0093] The process of determining the model coefficients based on the pre-established linear regression model is as follows:

[0094] System characteristics and case characteristics are independent variables (including but not limited to), and the asserted expected value of the performance test index is the dependent variable y. A linear regression model is established to obtain the model coefficients and confidence intervals of system characteristics and case characteristics. The calculation formula for variable y is shown in formula (2).

[0095]

[0096] Where x1 represents the number of CPU cores in the response time case set; x2 represents the memory size in the response time case set; x p The value of feature p in the response time class case set; a0 is a constant term; a1 and b1 are regression coefficients of x1 and y; a2 and b2 are regression coefficients of x2 and y; a2 and b p All are x p The regression coefficient of y; ε is the random error term.

[0097] The expressions for the model coefficients of system features and case features are shown in formula (3).

[0098]

[0099] Where y1 is the response time assertion value sequence; y2 is the concurrency assertion value sequence; y n Let n be the sequence of assertion values ​​for the nth performance test metric, where n is an integer greater than or equal to 1.

[0100] y 11 For the assertion value of case 1 in response to the time-based class, case 1 indicates the first execution of this case, y 12 This represents the assertion value for case 2 in the response time category, where case 2 indicates the second execution of this case; y 1m This is the assertion value for the m-th case in the response time class, where m is an integer greater than or equal to 1.

[0101] x1 represents the number of CPU cores in the response time-related case set. 11 The number of CPU cores on the device used in the response time-based test case 1, x 12 The number of CPU cores used in the response time-based test case 2; x 1m The number of CPU cores of the device used in the m-th test case of the response time class.

[0102] x2 represents the feature memory size in the response time class case set; x 21The feature memory size used during the test of the response time class case 1; x 22 The feature memory size used during the test of response time-based case 2; x 2m The memory size used for the m-th test case of the response time class is the feature size, where m is an integer greater than or equal to 1.

[0103] x p For the feature p; x in the response time class case set p1 The size of feature p used in the response time class case 1 test; x p2 The size of feature p used in the response time class case 2 test; x pm The value of feature p is the size of the m-th test case in the response time class, where m is an integer greater than or equal to 1.

[0104] The model coefficients for specific system features and case features are shown in Table 2.

[0105]

[0106] Table 2

[0107] In Table 2, y1 is the response time assertion value sequence; y3 is the availability assertion value sequence; y4 is the system transaction volume assertion value sequence; y5 is the system processing capacity assertion value sequence; y7 is the transaction success rate assertion value sequence; a1 is the regression coefficient of x1 and y; b1 is the regression coefficient of x1 and y; a2 is the regression coefficient of x2 and y; b2 is the regression coefficient of x2 and y; a p For x p The regression coefficient of y; b p For x p The regression coefficient with y.

[0108] A4: Construct a model of the expected value of the assertion sequence of performance test indicators using model coefficients and processing results.

[0109] Specifically, by analyzing the confidence interval and whether the parameter affects the test results, the expected value model of the performance index assertion sequence is obtained based on the model coefficients.

[0110] For example, based on the values ​​of the confidence interval, we know b2, a p b p The reliability of the feature is low. Analysis shows that the value of b2 affects the test results and needs to be retained. p and b p If the value has no impact on the test results, this type of feature item will be removed, and so on.

[0111] The expected value model of the performance index assertion sequence is shown in Equations (4), (5) and (6).

[0112] y1=0.023x1 (4)

[0113] y3=0.011x1 (5)

[0114]

[0115] Where y1 is the sequence of response time assertion values; y3 is the sequence of availability assertion values; y4 is the sequence of system transaction volume assertion values; x1 is the number of characteristic CPU cores in the response time case set; and x2 is the size of characteristic memory in the response time case set.

[0116] A5: The expected value of the first assertion sequence is obtained by calculating the features of the test cases corresponding to the performance test case types through the performance test metric assertion sequence expected value model.

[0117] Optionally, after calculating the characteristics of the test cases corresponding to the performance test case type through the performance test metric assertion sequence expected value model to obtain the first assertion sequence expected value, B1-B5 are executed.

[0118] B1: Establish an assertion library for performance test cases by using system features, case features, and pre-acquired preset historical performance test cases.

[0119] System characteristics include the number of CPU cores, memory, and number of cluster machines.

[0120] Case characteristics include the complexity of API calls, etc.

[0121] The preset historical performance test cases are performance test cases before the current moment.

[0122] The assertion library for specific performance test cases is shown in Table 3.

[0123]

[0124] Table 3

[0125] Table 3 shows the assertion library for performance test cases, which includes performance test case number (N0001, N0002, N0003), system characteristics (number of CPU cores, number of memory, number of cluster machines), case characteristics (interface call complexity), and assertion value (response time).

[0126] Among them, the performance test case number N0001 has 2 CPU cores, 8GB of memory, 3 cluster machines, an interface call complexity of 11, and a response time of 33ms.

[0127] The performance test case number N0002 has 4 CPU cores, 16GB of memory, 6 cluster machines, an interface call complexity of 23, and a response time of 17ms.

[0128] The performance test case number N0003 has 2 CPU cores, 6GB of memory, 9 cluster machines, an interface call complexity of 19, and a response time of 29ms.

[0129] API call complexity measures the complexity of calling external APIs in a test case, including the number of API calls and their relationships. The number of API calls includes the number of nested API calls; a higher number of API calls results in a longer sequence of expected assertions. API call relationships are categorized into three types: single-point calls, dependent calls, and circular calls. A diagram illustrating specific API call relationships is shown below. Figure 2 As shown.

[0130] Figure 2 In the code, interface 1 is a single-point call method, interfaces 2, 3, 4 and 5 are dependent call methods, and interface 6 is a circular call method.

[0131] The API call complexity of test case n is calculated using C. n The complexity model for constructing the interface call is shown in the following formula (7).

[0132]

[0133] in, Let c be the number of interfaces that are called using dependency calls in the test case n. q b q All of these depend on the complexity coefficient of calling the interface. c represents the number of interfaces that are called in a loop in test case n. p b p All are complexity coefficients for loop-based API calls, m n For test case n, the number of interfaces using single sign-on, c f This represents the complexity coefficient of a single-point API call.

[0134] The complexity of the test case code structure is represented by cyclomatic complexity. The specific representation of cyclomatic complexity is as follows: Figure 3 As shown.

[0135] Figure 3 In this context, a cyclomatic complexity of 1 means that the code has only one path. For a piece of code with one branch, its cyclomatic complexity is 2.

[0136] Cyclomatic complexity represents the maximum number of assertions for a given method or interface in a given test case. A higher cyclomatic complexity indicates a greater likelihood of errors occurring during testing.

[0137] B2: Obtain the actual value of the assertion sequence; the assertion sequence is predicted by the performance test metric assertion sequence expected value model.

[0138] Among them, the expected value of the assertion sequence that has passed the performance test is obtained, and the actual value of the assertion sequence is predicted by the model.

[0139] The assertion sequence method measures the assertion status of a test case, the cyclomatic complexity measures the maximum number of assertions in the interface or method of the test case, and the number of interface calls measures the assertion sequence length of the test case.

[0140] B3: Compare whether the expected value of the first assertion sequence is consistent with the actual value of the assertion sequence.

[0141] B4: If they match, delete the test case corresponding to the performance test case type.

[0142] B5: If they are inconsistent, the actual values ​​of the features and assertion sequences of the test case corresponding to the performance test case type will be stored in the assertion library of the performance test case.

[0143] The characteristics of the test cases include case name, case number, system characteristics, and case features.

[0144] The actual values ​​of the assertion sequence are predicted by the performance test metric assertion sequence expected value model, and the regression model of the performance test metric assertion sequence expected value is trained to achieve self-learning optimization of the regression model of the performance test metric assertion sequence expected value.

[0145] S103: Match the pre-built functional test case assertion sequence library with the test cases corresponding to the functional test case types, and obtain the expected value of the second assertion sequence based on the matching result; the expected value of the second assertion sequence is used to detect the execution status of the test cases corresponding to the functional test case types.

[0146] Specifically, the expected value of the second assertion sequence is used to detect whether the execution of the test case corresponding to the functional test case type is successful or not.

[0147] The process of building a functional test case assertion sequence library is as follows:

[0148] The tested functional test cases are broken down into sub-functions, which are then decomposed into methods or interfaces. Each method or interface has a unique identifier, name, parameter list, number of parameters, cyclomatic complexity, and assertions. The cyclomatic complexity of a test case is the maximum of the cyclomatic complexities of all interfaces or methods (functions). The length of the assertion sequence for a test case is the number of calls to that interface or method (function).

[0149] To better understand, the following example uses a functional test case of SMS alerts for transaction volume monitoring. For instance, this test case can be broken down into two sub-functions: monitoring and alerting. The monitoring sub-function includes an interface for obtaining real-time transaction volume, an interface for obtaining historical transaction volume, a method for calculating the transaction volume baseline, and a method for comparing real-time transaction volume data with baseline data to determine whether an alert should be issued. If the real-time transaction volume is greater than the baseline data, the alert interface is called, and the parameters determine whether to call the SMS alert interface or the email alert interface. If the real-time transaction volume is less than the baseline data, no alert is issued.

[0150] Set assertions at each interface or method (function), as shown in Table 4.

[0151]

[0152]

[0153] Table 4

[0154] In Table 4, the assertion sequence is {{I0001, 0}, {M0001, "Alarm" or "No Alarm"}, {I0002, "SMS Alarm" or "Email Alarm"}...}. The length of the assertion sequence is 7, which is equal to the number of interface or method (function) calls. The cyclomatic complexity of the test case is 2, which is the maximum cyclomatic complexity of each interface or method (function). All historically tested functional test case assertion sequences and case features are stored in the database to form a functional test case assertion sequence library.

[0155] Specifically, the process of matching a pre-built functional test case assertion sequence library with the test cases corresponding to the functional test case types, and obtaining the expected value of the second assertion sequence based on the matching results, is as follows:

[0156] First, decompose the test cases corresponding to the functional test case types to obtain the characteristics of the test cases corresponding to the functional test case types; the characteristics of the test cases include method name, interface name, number of input parameters, input parameter list, and cyclomatic complexity of the interface.

[0157] Specifically, the functional test case corresponding to the functional test case type (e.g., case number GA0001) is decomposed into sub-functions, and the sub-functions are decomposed into methods or interfaces. Each method or interface is parsed to extract case characteristics such as name, input parameter list, number of input parameters, and cyclomatic complexity, and combined into a list L of methods or interfaces, where L is {l1, l2, ... l... n}, where n is an integer greater than or equal to 1.

[0158] Where l1 represents the first decomposed method or interface name, parameter list, number of input parameters, cyclomatic complexity, etc.; l2 represents the second decomposed method or interface name, parameter list, number of input parameters, cyclomatic complexity, etc.; n The information includes the name of the nth method or interface, the list of input parameters, the number of input parameters, the cyclomatic complexity, etc., where n is an integer greater than or equal to 1.

[0159] For example:

[0160] l n The information includes the name of the nth method or interface, the list of input parameters, the number of input parameters, and the cyclomatic complexity.

[0161] {

[0162] l1: {method or interface name M1, {input parameter P} 11 Input parameter P 12 Input parameter P 13 …},N1,Q1…},

[0163] l2: {method or interface name M2, {input parameter P} 21 Input parameter P 22 Input parameter P 23 …},N2,Q2},

[0164] …}

[0165] Where N1 is the number of input parameters of method or interface 1; Q1 is the cyclomatic complexity of method or interface 1; N2 is the number of input parameters of method or interface 2; and Q2 is the cyclomatic complexity of method or interface 2.

[0166] Then, using a preset hierarchical matching method, the features of the test cases corresponding to the functional test case type are matched with preset features in the pre-built functional test case assertion sequence library to obtain the matching results. Based on the matching results, the expected value of the second assertion sequence of the test cases corresponding to the functional test case type is generated.

[0167] Specifically, the case characteristics of each method or interface decomposed from the test case corresponding to the functional test case type, such as name, input parameter list, number of input parameters, cyclomatic complexity, etc., are matched with the data in the functional test case assertion sequence library using a hierarchical matching method.

[0168] For example, l1, l2, ... are sequentially retrieved from the interface list L. The name of the method or interface of l1, its input parameter list, the number of input parameters, and its cyclomatic complexity are matched against the data in the assertion sequence library. A hierarchical matching method is used: the method or interface names and parameter names in the assertion sequence library are sorted alphabetically. Only if the method or interface name matches successfully is the count of input parameters matched; only if the count of input parameters is the same is the parameter list matched; only if the parameter list matches successfully is the cyclomatic complexity matched, and so on. If any matching fails, the next test case interface or method is matched. When all test cases have identical characteristics, the assertion value of the corresponding method or interface in the assertion sequence library is retrieved as the expected assertion value for that test case method or interface. This hierarchical matching method avoids inefficient full table scans and improves matching efficiency.

[0169] Specifically, the process involves using a pre-defined hierarchical matching method to match the features of the test cases corresponding to the functional test case type with pre-defined features in a pre-built functional test case assertion sequence library, obtaining the matching results, and then generating the expected value of the second assertion sequence for the test cases corresponding to the functional test case type based on the matching results. Figure 4 As shown.

[0170] refer to Figure 4 As shown, S302 above involves matching the features of the test case corresponding to the functional test case type with preset features in the pre-built functional test case assertion sequence library using a preset hierarchical matching method to obtain the matching result, and generating the expected value of the second assertion sequence of the test case corresponding to the functional test case type based on the matching result. The process mainly includes the following steps:

[0171] S401: Sort the method name, interface name, number of input parameters, input parameter list and cyclomatic complexity of the interface in the functional test case assertion sequence library according to the preset sorting rules, and obtain the sorted method name, sorted interface name, sorted number of input parameters, sorted input parameter list and sorted cyclomatic complexity of the interface.

[0172] S402: Match the method name of the test case with the sorted method names. If the method name of the test case matches the sorted method names, execute S403. If the method name of the test case does not match the sorted method names, execute S408.

[0173] If the method name of the test case matches the sorted method names, the match is successful; otherwise, the match fails.

[0174] S403: Match the interface name of the test case with the sorted interface names. If the interface name of the test case matches the sorted interface names, execute S404. If the interface name of the test case fails to match the sorted interface names, execute S408.

[0175] If the interface name of the test case matches the sorted interface names, the match is successful; otherwise, the match fails.

[0176] S404: Match the number of input parameters of the test case with the sorted number of input parameters. If the number of input parameters of the test case matches the sorted number of input parameters, execute S405. If the number of input parameters of the test case does not match the sorted number of input parameters, execute S408.

[0177] If the number of input parameters of the test case is the same as the number of input parameters after sorting, the match is successful; otherwise, the match fails.

[0178] S405: Match the input parameter list of the test case with the sorted input parameter list. If the input parameter list of the test case matches the sorted input parameter list, execute S406. If the input parameter list of the test case fails to match the sorted input parameter list, execute S408.

[0179] If the input parameter list of the test case is the same as the sorted input parameter list, the match is successful; otherwise, the match fails.

[0180] S406: Match the cyclomatic complexity of the interface to be tested with the cyclomatic complexity of the sorted interfaces. If the cyclomatic complexity of the interface to be tested matches the cyclomatic complexity of the sorted interfaces, then execute S407. If the cyclomatic complexity of the interface to be tested fails to match the cyclomatic complexity of the sorted interfaces, then execute S408.

[0181] In this process, if the cyclomatic complexity of the interface to be tested is the same as the cyclomatic complexity of the sorted interfaces, the match is successful; otherwise, the match fails.

[0182] S407: Generate the expected value of the second assertion sequence for the test case corresponding to the functional test case type.

[0183] In S407, after all the methods or interfaces in the test case corresponding to the functional test case type have been matched, the matching results are combined to generate the expected value of the assertion sequence for the test case. For example, the expected value of the assertion sequence for test case GA0001 is as follows: GA0001: {{l1: 0}, {l2: "SMS alarm" or "email alarm"}...}.

[0184] The system only matches the number of input parameters if the method name or interface name matches successfully. If the number of input parameters is the same, it matches the input parameter list. Only if the input parameter list matches successfully does it perform cyclomatic matching, until all case features in the matching feature set match successfully. This avoids inefficient full table scans, improves matching efficiency, and increases the reusability of historical case data.

[0185] S408: Perform the matching of the characteristics of the test case corresponding to the next functional test case type.

[0186] If any set of test cases fails to match the features in the functional test case assertion sequence library, then the feature matching of the next test case corresponding to the functional test case type will proceed.

[0187] In the hierarchical matching method, the case features used are dynamically changing through self-learning. When any set of test case features fails to match the features in the functional test case assertion sequence library, an assertion sequence for the test case is manually created, and the relevant information is added to the assertion sequence library. Simultaneously, the reasons for the matching failure are analyzed, new case feature factors are extracted, and these case feature factors are added to the case features that need to be matched.

[0188] In automated testing processes, the expected values ​​of automatically generated assertion sequences are automatically assembled with the test case execution steps, improving testing efficiency.

[0189] This application continuously and dynamically optimizes the regression model of the expected value of the assertion sequence using historical case data, thereby improving the reusability of historical cases and the accuracy of assertion sequence generation, enhancing test quality, and strengthening the stable operation capability of the production environment.

[0190] By automating the entire process, it has significant advantages in large-scale test cases such as microservices and distributed systems at the current stage. At the same time, it is highly user-friendly and easy to promote.

[0191] In this embodiment, there is no need to manually set assertion expected values, avoiding the generation of incorrect assertion expected values ​​due to human error, thus improving the accuracy and quality of testing test cases. Furthermore, by processing test cases of different types, assertion sequence expected values ​​corresponding to different case types are obtained, improving the fine-grainedness of test case testing.

[0192] Based on the above embodiments Figure 1 The present application discloses a test case processing system in addition to a method for processing test cases. Figure 5 As shown, the test case processing system includes a determination unit 501, a calculation unit 502, and a matching unit 503.

[0193] The determination unit 501 is used to determine the case type of the test case; the case type includes performance test case type and functional test case type.

[0194] The calculation unit 502 is used to calculate the first assertion sequence expected value for the test case corresponding to the performance test case type if the test case type is a performance test case type. The first assertion sequence expected value is used to detect the execution status of the test case corresponding to the performance test case type.

[0195] The matching unit 503 is used to match the test case corresponding to the functional test case type with the pre-built functional test case assertion sequence library if the test case type is a functional test case type, and obtain the expected value of the second assertion sequence based on the matching result; the expected value of the second assertion sequence is used to detect the execution status of the test case corresponding to the functional test case type.

[0196] Furthermore, the computing unit 502 includes an acquisition module, a processing module, a determination module, a construction module, and a computing module.

[0197] The acquisition module is used to acquire system features and case features.

[0198] The processing module is used to standardize system features and case features and eliminate multicollinearity to obtain the processing results.

[0199] The determination module is used to determine the model coefficients based on a pre-established linear regression model.

[0200] A building module is used to construct a model of the expected value of the performance test metric assertion sequence using model coefficients and the processing results.

[0201] The calculation module is used to calculate the features of the test cases corresponding to the performance test case types through the performance test metric assertion sequence expected value model, and obtain the first assertion sequence expected value.

[0202] Furthermore, the test case processing system also includes a creation unit, an acquisition unit, a comparison unit, a deletion unit, and a storage unit.

[0203] The establishment unit is used to build an assertion library for performance test cases by using system features, case features, and pre-acquired preset historical performance test cases.

[0204] The acquisition unit is used to acquire the actual value of the assertion sequence; the assertion sequence is predicted by the performance test metric assertion sequence expected value model.

[0205] The comparison unit is used to compare whether the expected value of the first assertion sequence is consistent with the actual value of the assertion sequence.

[0206] The delete unit is used to delete the test case corresponding to the performance test case type if they are consistent.

[0207] The storage unit is used to store the actual values ​​of the characteristics and assertion sequences of the test case corresponding to the performance test case type into the assertion library of the performance test case if there is a discrepancy.

[0208] Furthermore, the matching unit 503 includes a decomposition module and a matching module.

[0209] The decomposition module is used to decompose the test cases corresponding to the functional test case types, and obtain the characteristics of the test cases corresponding to the functional test case types. The characteristics of the test cases include the method name, interface name, number of input parameters, input parameter list, and cyclomatic complexity of the interface.

[0210] The matching module is used to match the features of the test case corresponding to the functional test case type with the preset features in the pre-built functional test case assertion sequence library using a preset hierarchical matching method, obtain the matching result, and generate the second assertion sequence expected value of the test case corresponding to the functional test case type based on the matching result.

[0211] Furthermore, the matching module includes a sorting submodule, a first matching submodule, a second matching submodule, a third matching submodule, a fourth matching submodule, a fifth matching submodule, and a generation submodule.

[0212] The sorting submodule is used to sort the method names, interface names, number of input parameters, input parameter lists, and cyclomatic complexity of the interfaces in the functional test case assertion sequence library according to a preset sorting rule, so as to obtain the sorted method names, sorted interface names, sorted number of input parameters, sorted input parameter lists, and sorted cyclomatic complexity of the interfaces.

[0213] The first matching submodule is used to match the method names of the test cases with the sorted method names.

[0214] The second matching submodule is used to match the interface name of the test case with the sorted interface names if the method name of the test case matches the sorted method names.

[0215] The third matching submodule is used to match the number of input parameters of the test case with the number of input parameters after sorting if the interface name of the test case matches the sorted interface name.

[0216] The fourth matching submodule is used to match the input parameter list of the test case with the sorted input parameter list if the number of input parameters of the test case matches the number of input parameters after sorting.

[0217] The fifth matching submodule is used to match the cyclomatic complexity of the interface of the test case with the cyclomatic complexity of the sorted interface if the input parameter list of the test case matches the sorted input parameter list.

[0218] The generation submodule is used to generate the expected value of the second assertion sequence of the test case corresponding to the functional test case type if the cyclomatic complexity of the interface to be tested successfully matches the cyclomatic complexity of the sorted interfaces.

[0219] Furthermore, the test case processing system also includes an execution unit.

[0220] The execution unit is used to perform feature matching for the next set of test cases corresponding to the functional test case type if the features of any set of test cases fail to match the features in the functional test case assertion sequence library.

[0221] In this embodiment, there is no need to manually set assertion expected values, avoiding the generation of incorrect assertion expected values ​​due to human error, thus improving the accuracy and quality of testing test cases. Furthermore, by processing test cases of different types, assertion sequence expected values ​​corresponding to different case types are obtained, improving the fine-grainedness of test case testing.

[0222] This application embodiment also provides a storage medium, which includes stored instructions, wherein the instructions, when executed, control the device where the storage medium is located to execute the above-described test case processing method.

[0223] This application also provides an electronic device, the structural schematic diagram of which is shown below. Figure 6 As shown, it specifically includes a memory 601 and one or more instructions 602, wherein one or more instructions 602 are stored in the memory 601 and are configured to be executed by one or more processors 603 to perform the above-mentioned test case processing method.

[0224] For the foregoing method embodiments, in order to simplify the description, they 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, because according to this application, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0225] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system-type embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0226] The steps in the methods of the various embodiments of this application can be adjusted, combined, or deleted according to actual needs.

[0227] Finally, it should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0228] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0229] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A test case processing method, characterized in that, The method includes: Determine the case type of the test cases to be tested; the case types include performance test case types and functional test case types; If the test case type is the performance test case type, then the test case corresponding to the performance test case type is calculated using a pre-built performance test metric assertion sequence expected value model to obtain the first assertion sequence expected value; the first assertion sequence expected value is used to detect the execution status of the test case corresponding to the performance test case type. If the test case to be tested is of the functional test case type, then the test case to be tested corresponding to the functional test case type is matched with the pre-built functional test case assertion sequence library, and the second assertion sequence expected value is obtained according to the matching result; the second assertion sequence expected value is used to detect the execution status of the test case to be tested corresponding to the functional test case type. If the test case type is the performance test case type, then the test case corresponding to the performance test case type is calculated using a pre-built performance test metric assertion sequence expected value model to obtain the first assertion sequence expected value, including: Obtain system features and case features; The system features and case features are standardized and multicollinearity is eliminated to obtain the processing results. Based on a pre-established linear regression model, determine the model coefficients; A performance test metric assertion sequence expected value model is constructed using the model coefficients and the processing results. The first assertion sequence expected value is obtained by calculating the features of the test case corresponding to the performance test case type using the performance test indicator assertion sequence expected value model.

2. The method according to claim 1, characterized in that, After calculating the features of the test cases corresponding to the performance test case type using the performance test metric assertion sequence expected value model to obtain the first assertion sequence expected value, the method further includes: An assertion library for performance test cases is established using the system features, the case features, and pre-acquired preset historical performance test cases. Obtain the actual value of the assertion sequence; the assertion sequence is predicted by the performance test metric assertion sequence expected value model. Compare whether the expected value of the first assertion sequence is consistent with the actual value of the assertion sequence; If they match, delete the test case corresponding to the performance test case type. If they are inconsistent, the features of the test case corresponding to the performance test case type and the actual value of the assertion sequence are stored in the assertion library of the performance test case.

3. The method according to claim 1, characterized in that, If the test case type is the functional test case type, then the test case corresponding to the functional test case type is matched with the pre-built functional test case assertion sequence library, and the expected value of the second assertion sequence is obtained based on the matching result, including: Decompose the test cases corresponding to the functional test case type to obtain the characteristics of the test cases corresponding to the functional test case type; the characteristics of the test cases include method name, interface name, number of input parameters, input parameter list and cyclomatic complexity of the interface; By using a preset hierarchical matching method, the features of the test case corresponding to the functional test case type are matched with preset features in the pre-built functional test case assertion sequence library to obtain the matching result. Based on the matching result, the second assertion sequence expected value of the test case corresponding to the functional test case type is generated.

4. The method according to claim 3, characterized in that, The step of matching the features of the test case with preset features in the functional test case assertion sequence library using a preset hierarchical matching method to obtain a matching result, and generating a second assertion sequence expected value for the test case corresponding to the functional test case type based on the matching result, includes: The method names, interface names, number of input parameters, input parameter lists, and cyclomatic complexity of the interfaces in the functional test case assertion sequence library are sorted according to a preset sorting rule to obtain the sorted method names, sorted interface names, sorted number of input parameters, sorted input parameter lists, and sorted cyclomatic complexity of the interfaces. Match the method names of the test cases with the sorted method names; If the method name of the test case matches the sorted method names, then the interface name of the test case is matched with the sorted interface names. If the interface name of the test case matches the sorted interface name, then the number of input parameters of the test case is matched with the number of input parameters in the sorted order. If the number of input parameters of the test case matches the number of input parameters after sorting, then the input parameter list of the test case is matched with the sorted input parameter list. If the input parameter list of the test case matches the sorted input parameter list, then the cyclomatic complexity of the interface of the test case is matched with the cyclomatic complexity of the sorted interface. If the cyclomatic complexity of the interface of the test case matches the cyclomatic complexity of the sorted interfaces, then the expected value of the second assertion sequence of the test case corresponding to the functional test case type is generated.

5. The method according to claim 4, characterized in that, Also includes: If any set of test cases fails to match the features in the functional test case assertion sequence library, then the features of the next test case corresponding to the functional test case type will be matched.

6. A test case processing system, characterized in that, The system includes: A determination unit is used to determine the case type of the test case; the case type includes performance test case type and functional test case type; The calculation unit is configured to, if the test case type is the performance test case type, calculate the test case corresponding to the performance test case type using a pre-built performance test metric assertion sequence expected value model to obtain a first assertion sequence expected value; the first assertion sequence expected value is used to detect the execution status of the test case corresponding to the performance test case type. A matching unit is configured to, if the test case type is the functional test case type, match the test case corresponding to the functional test case type with a pre-built functional test case assertion sequence library, and obtain a second assertion sequence expected value based on the matching result; the second assertion sequence expected value is used to detect the execution status of the test case corresponding to the functional test case type. The computing unit includes: The acquisition module is used to acquire system features and case features; The processing module is used to standardize the system features and the case features and eliminate multicollinearity to obtain the processing results; The determination module is used to determine the model coefficients based on a pre-established linear regression model; The construction module is used to construct a performance test index assertion sequence expected value model using the model coefficients and the processing results; The calculation module is used to calculate the features of the test case corresponding to the performance test case type using the performance test indicator assertion sequence expected value model, and obtain the first assertion sequence expected value.

7. The system according to claim 6, characterized in that, Also includes: A building unit is used to build an assertion library for performance test cases based on the system features, the case features, and pre-acquired preset historical performance test cases. The acquisition unit is used to retrieve the actual value of the assertion sequence; The assertion sequence is predicted using the performance test metric assertion sequence expected value model; A comparison unit is used to compare whether the expected value of the first assertion sequence is consistent with the actual value of the assertion sequence; The deletion unit is used to delete the test case corresponding to the performance test case type if the results are consistent. A storage unit is used to store the features of the test case corresponding to the performance test case type and the actual value of the assertion sequence into the assertion library of the performance test case if there is a discrepancy.

8. The system according to claim 6, characterized in that, The matching unit includes: The decomposition module is used to decompose the pre-acquired test cases to obtain the characteristics of the test cases; the characteristics of the test cases include method name, interface name, number of input parameters, input parameter list, and cyclomatic complexity of the interface; The matching module is used to match the features of the test case corresponding to the functional test case type with the preset features in the pre-built functional test case assertion sequence library using a preset hierarchical matching method, obtain the matching result, and generate the second assertion sequence expected value of the test case corresponding to the functional test case type based on the matching result.

Images