Use case grouping method, apparatus, computer device and storage medium

Abstract

The application relates to the computer technical field, in particular to a use case grouping method and device, computer equipment and storage medium. The use case grouping method comprises the following steps: obtaining function parameters of an unrun use case and function parameters of a run use case; obtaining a correlation degree between the unrun use case and the run use case according to the function parameters of the unrun use case and the function parameters of the run use case; obtaining a historical running time of the run use case; obtaining an estimated running time of the unrun use case according to the correlation degree and the historical running time of the run use case; and grouping the unrun use case according to the estimated running time of the unrun use case to obtain each use case group, wherein a difference degree of a total estimated running time of each use case group meets a preset difference condition. The application aims to realize load balancing of execution time between each use case group and maximize the utility of resource allocation.

Description

Technical Field

[0001] This application relates to the field of computer technology, and specifically to a method, apparatus, computer device, and storage medium for grouping use cases. Background Technology

[0002] A use case is a description of how a system responds to external requests in software engineering or systems engineering. It is a technique for obtaining requirements through user scenarios.

[0003] To facilitate the management and control of test case execution, test cases are often grouped and run in groups. Each test case group consumes a certain amount of resources, which are released after successful execution. Test cases can be grouped manually, or using random strategies, linear sorting strategies, or other similar methods.

[0004] However, the above grouping method cannot achieve full utilization of resources. Summary of the Invention

[0005] This application provides a method, apparatus, computer device, and storage medium for grouping use cases, aiming to achieve full utilization of resources.

[0006] On the one hand, this application provides a use case grouping method, the use case grouping method including:

[0007] Obtain the functional parameters of non-running test cases and the functional parameters of running test cases;

[0008] Based on the functional parameters of the unrunnd test cases and the functional parameters of the runnd test cases, the degree of correlation between the unrunnd test cases and the runnd test cases is obtained;

[0009] Obtain the historical execution time of run test cases;

[0010] Based on the degree of correlation and the historical execution time of the runnable use cases, the estimated execution time of the unrunnable use cases is obtained;

[0011] The non-runn test cases are grouped according to their estimated running time to obtain the test case groups. The difference in the total estimated running time of each test case group satisfies a preset difference condition.

[0012] In some embodiments of this application, the non-running use cases are grouped according to their estimated execution time to obtain groups of non-running use cases, including:

[0013] Obtain the first average execution time of each run test case in its historical execution time;

[0014] Obtain the second average of the estimated execution time for each unrunned test case;

[0015] Calculate the difference between the first average time consumption and the second average time consumption;

[0016] Within the preset correspondence between the difference range and the number of test case groups, find the first estimated number of test case groups that matches the difference.

[0017] Based on the first estimated number of test case groups, the number of test case groups used for grouping is obtained;

[0018] Based on the estimated execution time of each unrunnd test case, the unrunnd test cases are divided into N groups to obtain each test case group that has been completed, where N is equal to the number of test case groups.

[0019] In some embodiments of this application, before obtaining the number of use case groups for grouping based on the first estimated number of use case groups, the method further includes:

[0020] Get the number of currently unoccupied threads, where the number of threads is used to run test cases;

[0021] Based on the number of unoccupied threads, determine the number of the second estimated test case groups;

[0022] The step of obtaining the number of use case groups for grouping based on the first estimated number of use case groups includes:

[0023] Based on the first estimated number of test case groups and the second estimated number of test case groups, the number of test case groups used for grouping is obtained.

[0024] In some embodiments of this application, the degree of correlation between the unrunnd use cases and the runnd use cases is obtained based on the functional parameters of the unrunnd use cases and the functional parameters of the runnd use cases, including:

[0025] Iterate through each run test case, calculate the correlation coefficient between the functional parameters of the non-run test cases and the functional parameters of the currently iterated run test cases, and obtain the correlation coefficients between the non-run test cases and each run test case respectively;

[0026] Among the various correlation coefficients, a target correlation coefficient that satisfies the preset correlation conditions is determined;

[0027] Within the preset correlation coefficient range and correlation degree correspondence, the correlation degree that matches the target correlation coefficient is found.

[0028] In some embodiments of this application, the non-runn use cases are grouped according to their estimated execution time to obtain groups of use cases, including:

[0029] Based on the grouped unrunned test cases, obtain the estimated total running time of each uncompleted test case group in the current group;

[0030] Based on the total estimated runtime of each current use case group, determine the target use case group with the smallest total estimated runtime.

[0031] Add the unrunnted test cases that are not grouped to the target test case group, and update the total estimated execution time of each test case group until all unrunn test cases are grouped, resulting in the grouped test case groups.

[0032] In some embodiments of this application, after obtaining the grouped use case groups, the use case grouping method further includes:

[0033] During the execution of the test case group, monitor the execution time of the test case group;

[0034] If the running time of the test case group and the total estimated running time of each test case in the test case group meet the preset timeout condition, then the running of the currently unrunning test cases in the test case group will be stopped.

[0035] Regroup the non-running use cases whose operations have been suspended.

[0036] In some embodiments of this application, the use case grouping method further includes:

[0037] Get the number of currently unoccupied threads, where the number of threads is used to run the test case;

[0038] Calculate the number of available threads for each non-running test case based on the number of non-running test cases and the number of currently unoccupied threads;

[0039] Obtain the current idle CPU resources, the current idle memory resources, and the current time fluctuation coefficient; wherein, the time fluctuation coefficient is determined based on the average estimated running time of each currently unrunnd test case;

[0040] Based on the current idle CPU resources, the number of available threads for each non-running test case, and the current time consumption fluctuation coefficient, calculate the estimated available CPU resources for each thread;

[0041] Based on the current free memory resources, the number of available threads for each non-running test case, and the current time consumption fluctuation coefficient, calculate the estimated available memory resources for each thread;

[0042] If the number of available threads for each unrunned use case, the estimated available CPU resources for each thread, and the estimated available memory resources for each thread meet the preset resource shortage conditions, then a resource shortage alarm will be issued.

[0043] On the other hand, this application provides a use case grouping device, the use case grouping device comprising:

[0044] The acquisition module is used to acquire the functional parameters of both non-runn test cases and runn test cases.

[0045] The calculation module is used to obtain the degree of correlation between the non-running use cases and the running use cases based on the functional parameters of the non-running use cases and the functional parameters of the running use cases;

[0046] The estimation module is used to obtain the historical execution time of the run test cases, and based on the correlation degree and the historical execution time of the run test cases, to obtain the estimated execution time of the unrun test cases;

[0047] The grouping module is used to group the non-runn test cases according to the estimated running time of the non-runn test cases, and obtain each test case group after grouping, wherein the difference in the total estimated running time of each test case group meets a preset difference condition.

[0048] On the other hand, this application also provides a computer device, the computer device comprising:

[0049] One or more processors;

[0050] Memory; and

[0051] One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the processor to implement the use case grouping method described in any one of the first aspects.

[0052] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, the computer program being loaded by a processor to perform the steps in the use case grouping method described in any of the first aspects.

[0053] This application's embodiments calculate the correlation between unrunned and runned use cases based on their functional parameters. Based on this correlation and the historical execution time of runned use cases, the execution time of unrunned use cases can be estimated before they are run. By grouping use cases according to their estimated execution time, the total estimated execution time of each group is approximately equal. This achieves load balancing among use case groups, reducing situations where some use case groups continuously use resources while others become idle prematurely, thus maximizing the utility of resource allocation. Attached Figure Description

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

[0055] Figure 1 This is a flowchart illustrating an embodiment of the use case grouping method provided in this application.

[0056] Figure 2 This is a schematic diagram illustrating the processing of newly submitted use case code in an embodiment of this application;

[0057] Figure 3 This is a schematic flowchart of an embodiment of step 102 in this application;

[0058] Figure 4 This is a schematic diagram of the dynamic resource estimation provided in the embodiments of this application;

[0059] Figure 5 This is a schematic diagram of the use case grouping provided in the embodiments of this application;

[0060] Figure 6 This is a schematic diagram illustrating the execution of the use case group provided in the embodiments of this application;

[0061] Figure 7 This is a schematic diagram of an embodiment of the use case grouping device provided in this application.

[0062] Figure 8 This is a schematic diagram of an embodiment of the computer device provided in 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 the description of this application, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0065] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0066] It should be noted that since the method in this application embodiment is executed in an electronic device, the processing objects of each electronic device exist in the form of data or information, such as time, which is essentially time information. It can be understood that if size, quantity, position, etc. are mentioned in subsequent embodiments, they are all corresponding data that exist so that the electronic device can process them. Specific details will not be elaborated here.

[0067] This application provides a method, apparatus, computer device, and storage medium for grouping use cases, which will be described in detail below.

[0068] First, this application provides a use case grouping method. The execution subject of the use case grouping method is a use case grouping device. The use case grouping device is applied to a computer device, such as a server. The computer device can be applied to a continuous integration (CI) system.

[0069] The test case grouping method includes: obtaining the functional parameters of unrunnd test cases and runnd test cases; obtaining the correlation degree between unrunnd test cases and runnd test cases based on the functional parameters of unrunnd test cases and runnd test cases; obtaining the historical execution time of runnd test cases; obtaining the estimated execution time of unrunnd test cases based on the correlation degree and the historical execution time of runnd test cases; grouping unrunnd test cases based on the estimated execution time of unrunnd test cases to obtain each test case group, wherein the difference in the sum of the estimated execution time of each test case group meets the preset difference condition.

[0070] The embodiments of this application can extract the estimated execution time of a test case before it is run, and group them based on the execution time to achieve load balancing of the execution of each test case group. This reduces the situation where some test case groups continuously use resources while others are idle prematurely during the execution of each test case group. It is beneficial to maximize the utility of resource allocation and can save the total execution time of a large number of test cases.

[0071] The implementation details of the use case grouping method in this application embodiment are described below. The following content is only for the convenience of understanding and is not necessary for implementing this solution.

[0072] like Figure 1 The diagram shown is a flowchart of an embodiment of the use case grouping method in this application. The use case grouping method includes:

[0073] Step 101: Obtain the functional parameters of unrunnd test cases and the functional parameters of runnd test cases.

[0074] Specifically, the use cases in the embodiments of this application can be test cases, thereby enabling optimal allocation of resources in the automated testing process and reducing the total execution time of test cases.

[0075] Each use case has at least one function, and each function has at least one input parameter, which is called the function parameter of the use case. For example, the parameters of the login function include: username, password, etc.

[0076] In this application embodiment, unrunnable use cases may include new use cases that the computer device has just received, wherein the use case corresponding to the currently submitted use case code is the new use case.

[0077] If there is currently test case code submitted to the computer device of this application embodiment, the computer device of this application embodiment can extract the functional parameters of the unrunned test case from the submitted test case code.

[0078] For reference Figure 2As shown, after the test case code is submitted, the computer device will scan and temporarily store the test case code. Then, it will call the historical test case code, which includes the test cases that have been run. The historical test case code and the currently submitted test case code are processed by the diff method to obtain the change items. The change items form an unordered field pool. The test cases in the historical test case code include the test cases that have been run. Then, a sequence number mapping is constructed for the change items. For example, sequence number 1: id, method name, parameter value; sequence number 2: id, method name, parameter value... sequence number i: id, method name, parameter value, etc., where sequence number i represents the number of categories to which the change item field belongs. The number of categories is determined by querying the "preset category management form of test cases". Different methods correspond to different functions.

[0079] After obtaining the sequence number mapping table, the list of changed parameters is parsed from the sequence number mapping table. The list of changed parameters is merged and sorted. The merged and sorted parameter list and the historical test case parameter table stored in the computer device are deduplicated. The deduplication process includes: using a hash table traversal query algorithm, if the same node is found, it is deleted; if not found, it is inserted at the end of the list. This results in a "new test case logic management structure table" that does not repeat the content of the historical test cases in the sequence number mapping table. The new test case logic relationship structure table is stored in the test case code repository and the parameterization document repository.

[0080] The functional parameters of unrunnd use cases and the functional parameters of runnd use cases can be obtained from the new use case logical relationship structure table, and then step 102 is executed.

[0081] Step 102: Based on the functional parameters of the unrunnd test cases and the functional parameters of the runnd test cases, determine the degree of correlation between the unrunnd test cases and the runnd test cases.

[0082] For reference Figure 3 As shown, in some embodiments, step 101 further includes:

[0083] Step 1021: Have all run test cases been traversed?

[0084] The runnable use cases that participate in the traversal can be all runnable use cases in the computer device, or a portion of runnable use cases that are not selected according to preset rules. This application embodiment does not limit the preset rules.

[0085] If the traversal is not completed, select one of the untraversed run test cases as the run test case for this round of traversal and proceed to step 1022. If the traversal is completed, proceed to step 1023.

[0086] Step 1022: Calculate the correlation coefficient between the functional parameters of the unrunnd test cases and the functional parameters of the currently traversed run test cases.

[0087] Specifically, the formula for calculating the correlation coefficient is as follows:

[0088]

[0089] Where X represents the functional parameters of the unrunned test cases, Y represents the functional parameters of the currently run test cases, Cov(X,Y) is the covariance of X and Y, Var[X] is the variance of X, and Var[Y] is the variance of Y.

[0090] r can represent whether there is a certain degree of correlation in the linear relationship of parameter combinations between two use cases.

[0091] For example, if the unrunnd test cases include {method1[parameter1], method2[parameter2]}; and the currently traversed runnd test cases include {method3[parameter3], method4[parameter4]}, then the functional parameters of the unrunnd test cases include parameter1 and parameter2, and the functional parameters of the currently traversed runnd test cases include parameter3 and parameter4. Based on this, the correlation coefficient r1 between the unrunnd test cases and the currently traversed runnd test cases is obtained.

[0092] After traversing all the run test cases, the correlation coefficients r1, r2, ..., rn between the unrunn test cases and each run test case can be obtained, where n represents the number of run test cases traversed, and r ranges from 0 to 1. Then, step 1023 is executed.

[0093] Step 1023: Among the various correlation coefficients, determine the target correlation coefficient that meets the preset correlation conditions.

[0094] The preset correlation condition can be set to the correlation coefficient with the largest value among the correlation coefficients. Alternatively, the preset correlation condition can be set according to actual needs; this embodiment does not limit this.

[0095] Step 1024: In the preset correlation coefficient range and correlation degree correspondence relationship, find the correlation degree that matches the target correlation coefficient.

[0096] The degree of correlation can have different levels, and different correlation coefficient ranges correspond to different levels.

[0097] For example, the levels of association include:

[0098] 1. Correlation level P0: β = 0.89, corresponding to a correlation coefficient range of range a. For example, r = 0, which falls at the p0 level.

[0099] 2. Correlation level P1: β = 0.91, corresponding to a correlation coefficient range of range b;

[0100] 3. Correlation level P3: β = 0.95, corresponding to a correlation coefficient range of c;

[0101] 4. Correlation level P4: β = 0.97, corresponding to a correlation coefficient range of d;

[0102] 5. Correlation level P5: β = 0.99, corresponding to a correlation coefficient range of e.

[0103] The correlation coefficient ranges a, b, c, d, and e can be set according to requirements, and this embodiment does not limit them.

[0104] For example, if the target correlation coefficient falls within the range e, the correlation level is P5, and the specific value of the correlation level is 0.99.

[0105] Among them, such as Figure 2 As shown, the process of determining the range of the target correlation coefficient described above is... Figure 2 The interval evaluation in the process is used to determine the degree of correlation by obtaining the evaluation label, and each level has a numerical value.

[0106] Steps 1021 and 1024 above take into account the correlation of each run test case to obtain the correlation degree, which improves the accuracy of the correlation degree calculation and makes the estimated running time more accurate.

[0107] In addition to the methods for obtaining the degree of association in steps 1021 and 1024 above, the following methods can also be used;

[0108] In other embodiments, a running use case can be selected from the stored running use cases, the correlation can be calculated, and the degree of association can be determined based on the obtained correlation.

[0109] In other embodiments, after obtaining the correlation between the currently running use case and each of the previously running use cases, the degree of correlation can be determined based on the statistical value of each correlation, such as the average value, and the range of the average value.

[0110] The above provides several methods for obtaining the degree of association. In practical applications, the method for obtaining the degree of association can also be set according to the actual situation. This application embodiment does not limit this.

[0111] After obtaining the degree of association, step 103 can be executed.

[0112] Step 103: Obtain the historical execution time of the run test cases. Based on the degree of correlation and the historical execution time of the run test cases, obtain the estimated execution time of the unrun test cases.

[0113] In some embodiments, the historical execution time of a runnable use case can be multiplied by the correlation level to obtain the estimated execution time of an unrunnable use case.

[0114] Specifically, the target's already run use cases are determined based on the target's relevance coefficient, and the historical execution time of the target's already run use cases is multiplied by the degree of association corresponding to the target's relevance coefficient.

[0115] For example, if the correlation coefficient between the run test case user1 and the non-run test case user2 is the target correlation coefficient, then the run test case user1 is the target run test case. Multiplying the historical running time of the run test case user1 with the correlation degree corresponding to the target correlation coefficient, we can obtain the estimated running time of the non-run test case.

[0116] In other embodiments, correlation coefficients between unrunnd use cases and each run use case can be obtained, correlation degrees matching each correlation coefficient can be found, time consumption weights can be set according to the magnitude of each correlation degree, and each time consumption weight can be multiplied by the historical run time of each run use case to obtain the estimated run time. The greater the correlation degree, the greater the time consumption weight.

[0117] For example, the correlation coefficient between an unrunnd test case and a runnd test case a is r1, and the degree of association matching r1 is p0 level; the correlation coefficient between an unrunnd test case and a runnd test case b is r2, and the degree of association matching r2 is p0 level. Based on the relationship between the values ​​corresponding to p0 level and p1 level, the time consumption weight ta of runnd test case a and the time consumption weight tb of runnd test case b are set. Since the β value corresponding to p0 level is less than the β value corresponding to p1, ta is greater than tb.

[0118] The above describes how to estimate the execution time of unrunned test cases. (Refer to...) Figure 4 As shown, this application embodiment can not only estimate the time consumption of unrunning use cases, but also estimate the available resources of the cluster itself. The following gives the method of estimating the number of available threads, the available CPU resources of each thread, and the memory resources for each unrunning use case.

[0119] The estimated number of available threads for each non-running test case includes: obtaining the number of currently unoccupied threads, where the number of threads is the number of threads used to run the test case; calculating the number of available threads for each non-running test case based on the number of non-running test cases and the number of currently unoccupied threads; and the calculated number of threads is the estimated number of available threads for each non-running test case.

[0120] That is, the estimated number of available threads N for each running test case is N = (total number of started threads S - number of occupied threads M) / number of unrunned test cases K.

[0121] The method for estimating the available CPU resources for each thread includes: calculating the estimated available CPU resources for each thread based on the current idle CPU resources, the number of threads available for each unrunned use case, and the current latency fluctuation coefficient.

[0122] Specifically, the estimated available CPU resources for each thread = idle CPU resources / (number of available threads N * complexity coefficient i), where the complexity coefficient i is determined based on the time consumption fluctuation coefficient, which is determined based on the average estimated execution time of each currently unrunnd test case.

[0123] The following is a brief description of the process of obtaining the complexity coefficient i:

[0124] First, obtain the median of the historical execution time of each run test case, and use the median as the time fluctuation coefficient. Then, obtain the second average time of the estimated time of each non-run test case, that is, calculate: the sum of the estimated time of each non-run test case / the number of non-run test cases n.

[0125] Secondly, compare the time consumption fluctuation coefficient and the second average time consumption. If the second average time consumption is greater than the time consumption fluctuation coefficient, the complexity coefficient is the first preset value; if the second average time consumption is equal to the time consumption fluctuation coefficient, the complexity coefficient is the second preset value; if the second average time consumption is equal to the time consumption fluctuation coefficient, the complexity coefficient is the third preset value.

[0126] Among them, the first preset value > the second preset value > the third preset value.

[0127] For example, the first preset value is 1.2, the second preset value is 1.0, and the third preset value is 0.6.

[0128] The method for estimating the estimated available memory (MEM) resources for each thread includes: calculating the estimated available memory resources for each thread based on the current free memory resources, the number of threads available for each non-running test case, and the current latency fluctuation coefficient.

[0129] Specifically, the estimated available memory resources for each thread = free memory resources / (number of available threads N * complexity coefficient i).

[0130] If the number of available threads for each unrunned test case, the estimated available CPU resources for each thread, and the estimated available memory resources for each thread, as calculated above, meet the preset resource shortage conditions, then a resource shortage alarm will be issued.

[0131] For example, the preset conditions for insufficient resources may include: insufficient number of available threads, insufficient estimated available CPU resources, and insufficient estimated available memory resources. If any one of these conditions is not met, a resource shortage alarm will be issued.

[0132] For example, the number of available threads, the estimated available CPU resources, and the estimated available memory resources can be scored. If the score is lower than a preset threshold, it indicates that the preset resource shortage condition is met.

[0133] This application embodiment can monitor resources in the cluster, predict in advance whether the resources for test case execution are sufficient, and if not, issue an alarm to facilitate users in handling resource shortages and improve the success rate of test case execution.

[0134] The above are the resource estimates and operation time estimates. After obtaining the estimated operation time, proceed to step 104.

[0135] Step 104: Group the unrunnd test cases according to the estimated running time of the unrunnd test cases to obtain the grouped test case groups.

[0136] Among them, the degree of difference in the total estimated runtime of each use case group meets the preset difference condition.

[0137] Preset difference conditions indicate that the total estimated runtime is close; for example, the variance of the total estimated runtime of each use case group is the smallest.

[0138] When grouping, you can refer to Figure 5 As shown, it is necessary to first determine the number of test case groups N, and then divide the unrunn test cases into N groups.

[0139] In some embodiments, determining the number of use case groups may include: obtaining a first average of the historical execution time of each run use case; obtaining a second average of the estimated execution time of each non-run use case; and obtaining the number of use case groups for grouping based on the first average of the execution time and the second average of the execution time.

[0140] Specifically, based on the first average time consumption and the second average time consumption, the number of use case groups for grouping is obtained, including:

[0141] Calculate the difference between the first average time consumption and the second average time consumption;

[0142] Within the preset correspondence between the difference range and the number of test case groups, find the first estimated number of test case groups that matches the difference.

[0143] The number of the first estimated test case group is used as the number of test case groups used for grouping.

[0144] For example, let the first average time consumption be denoted as A, the second average time consumption as B, and the first estimated number of test case groups as X. The preset correspondence between the difference range and the number of test case groups can be as follows:

[0145] If |AB|∈[10, 100]ms, then X=2, where ms is the unit of milliseconds;

[0146] If |AB|∈[100, 500]ms, then X=8;

[0147] If |AB|∈[500, 900]ms, then X=24;

[0148] If |AB|∈[90, 1400]ms, then X=30;

[0149] If |AB|∈[1400, 2200]ms, then X=55.

[0150] In other embodiments, determining the number of test case groups may include: determining a second estimated number of test case groups based on the number of unoccupied threads, wherein the number of unoccupied threads is the number of threads used to run the test cases.

[0151] The number of unoccupied threads = the total number of started threads - the number of occupied threads.

[0152] For example, if the number of unoccupied threads is 20, then the number of the second estimated test case groups is also 20. The number of the second estimated test case groups can be used as the number of test case groups for grouping.

[0153] In other embodiments, the number of use case groups can be obtained based on the first estimated number of use case groups and the second estimated number of use case groups.

[0154] Specifically, the number of use case groups used for grouping is min(the number of first estimated use case groups and the number of second estimated use case groups), that is, the minimum of the first estimated use case group number and the second estimated use case group number is used as the number of use case groups used for grouping.

[0155] Reference Figure 5 As shown, after determining the number of use case groups for grouping, the use cases can be divided using a dynamic programming algorithm.

[0156] In some embodiments, the estimated total running time of each unrunned use case group in the current group is obtained based on each unrunned use case grouped in the group;

[0157] Based on the total estimated runtime of each use case group, determine the target use case group with the smallest total estimated runtime.

[0158] Add the unrunnted test cases that are not grouped to the target test case group, and update the total estimated execution time of each test case group until all unrunn test cases are grouped, resulting in the grouped test case groups.

[0159] For example, if the currently ungrouped unrunned test case is case1, and there are three test case groups, with the estimated total execution time of the three test case groups being t1, t2, and t3 respectively, where t3 is the smallest, then case1 is assigned to the test case group corresponding to t3, and the estimated total execution time of each test case group is updated. The updated estimated total execution time is t1, t2, t3+tcase1, where tcase1 is the execution time of test case1. If the ungrouped unrunned test case in the next round is case2, t2 is the smallest among t1, t2, and t3+tcase2. Therefore, case2 is assigned to the group corresponding to t2, and so on until all unrunned test cases are grouped.

[0160] It is worth mentioning that when grouping the first unrunnable test case, that is, when there are no test cases in each test case group, the running time of each test case group can be set to 0. If there are multiple test case groups with the same estimated running time, and the estimated running time is the smallest among all test case groups, a test case group can be randomly selected from these multiple test case groups, and the currently ungrouped unrunnable test cases can be assigned to that test case group.

[0161] The above method of dividing use case groups can also be expressed using the following dynamic programming formula:

[0162] Sub(T)=min(sub(T-Tcase_i)+1);

[0163] Where Sub(T) represents the estimated running time of the group, and Tcase_i represents the estimated running time of the i-th case case_i.

[0164] For example, refer to Figure 5 As shown, Figure 5 The diagram illustrates the grouping of 9 test cases into 3 test case groups. Each test case is labeled as case_1, case_2, case_3, ..., case_i. Each sub represents a group. The length of a single rectangle in the diagram represents the estimated runtime of the test case. After grouping, the estimated runtime of each test case group is roughly the same.

[0165] That is, the embodiments of this application use dynamic programming to find the group with the smallest total estimated running time in each round of grouping, and thus group them, which is more conducive to achieving load balancing of the running time of each use case group.

[0166] Reference Figure 6 As shown, after grouping, each test case can be executed by group, with the following steps:

[0167] 1. Each test case group is executed on a multi-threaded server basis. That is, each test case group carries several cases and is included in the thread pool to form a job. A job is a short-lived, one-time task in Kubernetes that is responsible for batch processing. It is executed only once and ensures that one or more Pods are successfully completed. Kubernetes is a portable, scalable, open-source platform for managing containerized workloads and services, which promotes declarative configuration and automation.

[0168] 2. Job1, job2, job3, ..., jobn can be executed in parallel.

[0169] 3. During the execution of the test case group, detect the time elapsed in the test case group and monitor the progress by subtracting the elapsed time from the estimated time elapsed.

[0170] 4. If the running time of the test case group and the total estimated running time of each test case in the test case group meet the preset timeout condition, then the running of the currently unrunning test cases in the test case group shall be stopped.

[0171] The preset timeout condition can be: the time elapsed before execution is greater than the estimated time elapsed * 1.5. If the preset condition is met, the circuit breaker is triggered, which means that the execution of the remaining unexecuted cases in the test case group is stopped, and the cases are included in the dynamic allocation process of test cases. The cases are then automatically rearranged, and the next round of the step of "grouping the unexecuted test cases according to the estimated execution time of the unexecuted test cases" begins.

[0172] In other words, the unrunnable test cases participating in the grouping include at least two situations: one is a newly submitted test case, and the other is an unrunnable test case that has been grouped in the previous round but has not been successfully run.

[0173] 5. If the test case is a test case, the test data / results after the test case is executed will be continuously written to the logger for use in writing and drawing test reports.

[0174] 6. Test data results are recorded. The actual time taken for each completed test case is recorded as historical time. This historical time is then input into the [Resource Dynamic Estimation Module] to update the estimated time for each test case. The update rule is to calculate the average of AVG (actual time T1, historical estimated time T2).

[0175] That is, in this embodiment of the application, after an unrunnable use case has completed its execution, it is set as a runnable use case, and the actual execution time and the estimated execution time of the use case, i.e. the average of the historical estimated execution time, are used as the historical execution time of the runnable use case.

[0176] This application's embodiments obtain the degree of correlation between two use cases through functional parameters, solving the problem of being unable to analyze the correlation of use cases; by using the degree of correlation and historical execution time, it is possible to extract the estimated execution time of the use cases, and also to extract whether the estimated server resources are sufficient for the use cases; grouping by estimated execution time can reduce the situation where some use case groups continuously occupy resources while others are idle prematurely during the execution of each use case group, so that each use case group ends as simultaneously as possible, saving the total execution time of a large number of use cases, which is conducive to maximizing the utility of resource allocation.

[0177] This application also provides a use case grouping device, referencing... Figure 7 As shown, it includes:

[0178] The acquisition module 701 is used to acquire the functional parameters of unrunned test cases and the functional parameters of run test cases.

[0179] The calculation module 702 is used to obtain the degree of correlation between the non-running use cases and the running use cases based on the functional parameters of the non-running use cases and the functional parameters of the running use cases;

[0180] The estimation module 703 is used to obtain the historical execution time of the run test cases, and to obtain the estimated execution time of the unrun test cases based on the correlation degree and the historical execution time of the run test cases.

[0181] The grouping module 704 is used to group the non-running use cases according to the estimated running time of the non-running use cases, and obtain each group of use cases after grouping, wherein the degree of difference of the sum of the estimated running time of each use case group meets the preset difference condition.

[0182] In some embodiments of this application, the calculation module 702 is further used to obtain the first average time of historical execution time for each run test case;

[0183] Obtain the second average of the estimated execution time for each unrunned test case;

[0184] Calculate the difference between the first average time consumption and the second average time consumption;

[0185] Within the preset correspondence between the difference range and the number of test case groups, find the first estimated number of test case groups that matches the difference; based on the first estimated number of test case groups, obtain the number of test case groups used for grouping.

[0186] Based on the estimated execution time of each unrunnd test case, the unrunnd test cases are divided into N groups to obtain each test case group that has been completed, where N is equal to the number of test case groups.

[0187] In some embodiments of this application, the calculation module 702 is further configured to obtain the number of currently unoccupied threads, wherein the number of threads is the number of threads used to run test cases;

[0188] Based on the number of unoccupied threads, determine the number of the second estimated test case groups;

[0189] The step of obtaining the number of use case groups for grouping based on the first estimated number of use case groups includes:

[0190] Based on the first estimated number of test case groups and the second estimated number of test case groups, the number of test case groups used for grouping is obtained.

[0191] In some embodiments of this application, the calculation module 702 is further used to traverse each run test case, calculate the correlation coefficient between the functional parameters of the non-run test cases and the functional parameters of the currently traversed run test cases, and obtain the correlation coefficients between the non-run test cases and each run test case respectively.

[0192] Among the various correlation coefficients, a target correlation coefficient that satisfies the preset correlation conditions is determined;

[0193] Within the preset correlation coefficient range and correlation degree correspondence, the correlation degree that matches the target correlation coefficient is found.

[0194] In some embodiments of this application, the grouping module 704 is further configured to obtain the estimated total running time of each unrunnd use case group in the current group based on each unrunnd use case in the group;

[0195] Based on the total estimated runtime of each current use case group, determine the target use case group with the smallest total estimated runtime.

[0196] Add the unrunnted test cases that are not grouped to the target test case group, and update the total estimated execution time of each test case group until all unrunn test cases are grouped, resulting in the grouped test case groups.

[0197] In some embodiments of this application, the grouping module 704 is further configured to monitor the elapsed execution time of the test case group during its execution.

[0198] If the running time of the test case group and the total estimated running time of each test case in the test case group meet the preset timeout condition, then the running of the currently unrunning test cases in the test case group will be stopped.

[0199] Regroup the non-running use cases whose operations have been suspended.

[0200] In some embodiments of this application, the grouping module 704 is further configured to obtain the number of currently unoccupied threads, the number of threads being the number of threads used to run the use case;

[0201] Calculate the number of available threads for each non-running test case based on the number of non-running test cases and the number of currently unoccupied threads;

[0202] Obtain the current idle CPU resources, the current idle memory resources, and the current time fluctuation coefficient; wherein, the time fluctuation coefficient is determined based on the average estimated running time of each currently unrunnd test case;

[0203] Based on the current idle CPU resources, the number of available threads for each non-running test case, and the current time consumption fluctuation coefficient, calculate the estimated available CPU resources for each thread;

[0204] Based on the current free memory resources, the number of available threads for each non-running test case, and the current time consumption fluctuation coefficient, calculate the estimated available memory resources for each thread;

[0205] If the number of available threads for each unrunned use case, the estimated available CPU resources for each thread, and the estimated available memory resources for each thread meet the preset resource shortage conditions, then a resource shortage alarm will be issued.

[0206] This application also provides a computer device that integrates any of the use case grouping devices provided in this application, the computer device comprising:

[0207] One or more processors;

[0208] Memory; and

[0209] One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the processor in the steps of the use case grouping method described in any of the embodiments of the use case grouping method described above.

[0210] This application also provides a computer device that integrates any of the use case grouping devices provided in this application. For example... Figure 8 As shown, it illustrates a structural schematic diagram of the computer device involved in the embodiments of this application, specifically:

[0211] The computer device may include components such as a processor 801 with one or more processing cores, a memory 802 with one or more computer-readable storage media, a power supply 803, and an input unit 804. Those skilled in the art will understand that... Figure 8The computer device structure shown does not constitute a limitation on the computer device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein:

[0212] The processor 801 is the control center of the computer device. It connects various parts of the computer device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 802, and by calling data stored in the memory 802, it performs various functions of the computer device and processes data, thereby providing overall monitoring of the computer device. Optionally, the processor 801 may include one or more processing cores; preferably, the processor 801 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 801.

[0213] The memory 802 can be used to store software programs and modules. The processor 801 executes various functional applications and data processing by running the software programs and modules stored in the memory 802. The memory 802 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 802 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 802 may also include a memory controller to provide the processor 801 with access to the memory 802.

[0214] The computer device also includes a power supply 803 that supplies power to the various components. Preferably, the power supply 803 can be logically connected to the processor 801 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 803 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0215] The computer device may also include an input unit 804, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0216] Although not shown, the computer device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 801 in the computer device loads the executable files corresponding to the processes of one or more application programs into the memory 802 according to the following instructions, and the processor 801 runs the application programs stored in the memory 802 to realize various functions.

[0217] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0218] Therefore, embodiments of this application provide a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc. A computer program is stored thereon, which is loaded by a processor to execute the steps in any of the use case grouping methods provided in embodiments of this application.

[0219] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the detailed descriptions of other embodiments above, which will not be repeated here.

[0220] In practice, each of the above units or structures can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units or structures, please refer to the previous method embodiments, which will not be repeated here.

[0221] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0222] The above provides a detailed description of a use case grouping method, apparatus, computer device, and storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for grouping use cases, characterized in that, The use case grouping method includes: Obtain the functional parameters of non-running test cases and the functional parameters of running test cases; Based on the functional parameters of the unrunnd test cases and the functional parameters of the runnd test cases, the degree of correlation between the unrunnd test cases and the runnd test cases is obtained; Obtain the historical execution time of run test cases; Based on the correlation degree and the historical execution time of the run test cases, the estimated execution time of the non-run test cases is obtained, wherein the historical execution time of the run test cases is multiplied by the correlation degree to obtain the estimated execution time of the non-run test cases, wherein the correlation degree has different levels, and each level has a value. The non-runn use cases are grouped according to their estimated running time to obtain the grouped use case groups. The difference in the total estimated running time of each use case group satisfies a preset difference condition. The step of obtaining the correlation degree between the non-runn test cases and the runn test cases based on the functional parameters of the non-runn test cases and the functional parameters of the runn test cases includes: traversing each runn test case, calculating the correlation coefficient between the functional parameters of the non-runn test cases and the functional parameters of the currently traversed runn test cases, and obtaining each correlation coefficient between the non-runn test cases and each runn test case; determining the target correlation coefficient that meets the preset correlation conditions among the correlation coefficients; and finding the correlation degree that matches the target correlation coefficient in the preset correspondence between the correlation coefficient range and the correlation degree. The step of grouping the unrunnable use cases according to their estimated running time to obtain grouped use case groups includes: Step S1, after determining the number of use case groups for grouping, when grouping the first unrunnable use case, randomly selecting one use case group from multiple use case groups and assigning the currently ungrouped unrunnable use cases to that use case group; Step S2, based on the grouped unrunnable use cases, obtaining the total estimated running time of each use case group that is not yet grouped; Step S3, based on the total estimated running time of each use case group, determining the target use case group with the smallest total estimated running time; Step S4, adding the ungrouped unrunnable use cases to the target use case group and updating the total estimated running time of each use case group; Step S5, repeating steps S2 to S4 until all unrunnable use cases are grouped, obtaining grouped use case groups.

2. The use case grouping method according to claim 1, characterized in that, The step of grouping the non-running use cases according to their estimated execution time to obtain groups of non-running use cases includes: Obtain the first average execution time of each run test case in its historical execution time; Obtain the second average of the estimated execution time for each unrunned test case; Calculate the difference between the first average time consumption and the second average time consumption; Within the preset correspondence between the difference range and the number of test case groups, find the first estimated number of test case groups that matches the difference. Based on the first estimated number of test case groups, the number of test case groups used for grouping is obtained; Based on the estimated execution time of each unrunnd test case, the unrunnd test cases are divided into N groups to obtain each test case group that has been completed, where N is equal to the number of test case groups.

3. The use case grouping method according to claim 2, characterized in that, Before obtaining the number of use case groups for grouping based on the first estimated number of use case groups, the method further includes: Get the number of currently unoccupied threads, where the number of threads is used to run test cases; Based on the number of unoccupied threads, determine the number of the second estimated test case groups; The step of obtaining the number of use case groups for grouping based on the first estimated number of use case groups includes: Based on the first estimated number of test case groups and the second estimated number of test case groups, the number of test case groups used for grouping is obtained.

4. The use case grouping method according to claim 1, characterized in that, After obtaining the completed use case groups, the method further includes: During the execution of the test case group, monitor the execution time of the test case group; If the running time of the test case group and the total estimated running time of each test case in the test case group meet the preset timeout condition, then the running of the currently unrunning test cases in the test case group will be stopped. Regroup the non-running use cases whose operations have been suspended.

5. The use case grouping method according to claim 1, characterized in that, The method further includes: Get the number of currently unoccupied threads, where the number of threads is used to run the test case; Calculate the number of available threads for each non-running test case based on the number of non-running test cases and the number of currently unoccupied threads; Obtain the current idle CPU resources, the current idle memory resources, and the current time fluctuation coefficient; wherein, the time fluctuation coefficient is determined based on the average estimated running time of each currently unrunnd test case; Based on the current idle CPU resources, the number of available threads for each non-running test case, and the current time consumption fluctuation coefficient, calculate the estimated available CPU resources for each thread; Based on the current free memory resources, the number of available threads for each non-running test case, and the current time consumption fluctuation coefficient, calculate the estimated available memory resources for each thread; If the number of available threads for each unrunned use case, the estimated available CPU resources for each thread, and the estimated available memory resources for each thread meet the preset resource shortage conditions, then a resource shortage alarm will be issued.

6. A use case grouping device, characterized in that, The use case grouping device includes: The acquisition module is used to acquire the functional parameters of both non-runn test cases and runn test cases. The calculation module is used to obtain the degree of correlation between the non-running use cases and the running use cases based on the functional parameters of the non-running use cases and the functional parameters of the running use cases; The estimation module is used to obtain the historical execution time of run test cases, and to obtain the estimated execution time of non-run test cases based on the correlation degree and the historical execution time of the run test cases. The estimated execution time of the non-run test cases is obtained by multiplying the historical execution time of the run test cases by the correlation degree. The correlation degree has different levels, and each level has a value. The grouping module is used to group the non-running use cases according to the estimated running time of the non-running use cases, and obtain each group of use cases after grouping, wherein the degree of difference of the total estimated running time of each group of use cases meets the preset difference condition. The calculation module determines the correlation between unrunnd test cases and runnd test cases based on their functional parameters and those of the runnd test cases. This process includes: traversing each runnd test case, calculating the correlation coefficient between the functional parameters of the unrunnd test cases and the functional parameters of the currently traversed runnd test cases, and obtaining each correlation coefficient between the unrunnd test cases and each runnd test case; identifying a target correlation coefficient that meets preset correlation conditions among the correlation coefficients; and finding a correlation degree that matches the target correlation coefficient within a preset correlation coefficient range and correlation degree correspondence relationship. The grouping module groups the unrunnable test cases according to their estimated execution time, resulting in complete test case groups. This includes: Step S1: After determining the number of test case groups for grouping, when grouping the first unrunnable test case, randomly select one test case group from multiple groups and assign the currently ungrouped unrunnable test cases to that group; Step S2: Based on the grouped unrunnable test cases, obtain the total estimated execution time of all test case groups whose grouping is incomplete; Step S3: Based on the total estimated execution time of all current test case groups, determine the target test case group with the smallest total estimated execution time; Step S4: Add the ungrouped unrunnable test cases to the target test case group and update the total estimated execution time of all current test case groups; Step S5: Repeat steps S2 to S4 until all unrunnable test cases are grouped, resulting in complete test case groups.

7. A computer device, characterized in that, The computer device includes: One or more processors; Memory; and One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the processor to implement the use case grouping method of any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, It stores a computer program, which is loaded by a processor to execute the steps in the use case grouping method according to any one of claims 1 to 5.

Images