Use case recommendation method, use case recommendation system, electronic equipment and storage medium

Through the feature extraction and concentration of the online request data, the problem of high use of case maintenance costs in existing technologies is solved, and the streamlined and comprehensive testing of the case set is realized, reducing the needs of artificial modification cases.

CN119357038APending Publication Date: 2025-01-24ZHEJIANG TMALL TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202310882158.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2023-07-18
Publication Date
2025-01-24

AI Technical Summary

Technical Problem

In the prior art, by recording a large amount of online real traffic as a use case for automated regression testing, the maintenance cost is extremely high, and once the source code of the application changes, the use case needs to be manually modified, and the cost is uncontrollable.

Method used

By obtaining online request calls to be executed, including interface data information and code line data information, characteristic extraction, determining the first case set and code line coverage information, and then determine the second use case, form a recommended case set for use cases and use Return to test.

Benefits of technology

The minimum use case set guarantees the comprehensiveness of the test, reduces the use of case structure and maintenance costs of testers, and reduces the needs of artificial modifications.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119357038A_ABST
    Figure CN119357038A_ABST
Patent Text Reader

Abstract

The embodiment of the invention provides a use case recommendation method, a use case recommendation system, electronic equipment and a storage medium. The method comprises the steps that data information which is called and executed by a collected online request is acquired, and the data information comprises interface data information and code line data information; performing feature extraction on the interface data information to obtain interface feature information; determining a first use case set according to the interface feature information; determining code line coverage information according to the first use case set and the code line data information; determining a second use case set according to the code line coverage information; and determining a recommended case set for regression testing according to the first case set and the second case set. By adopting the technical scheme provided by the embodiment of the invention, not only can the simplification of the recommended use case be ensured, but also the full coverage of the service scene can be ensured to the greatest extent, so that the test comprehensiveness can be ensured by using the minimum use case set, and the use case construction and maintenance cost of test personnel can be reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a use case recommendation method, a use case recommendation system, an electronic device, and a storage medium. Background Art

[0002] As the complexity of different service systems increases, the complexity of applications within the system also increases. To ensure the smooth operation of the service system, the service system needs to be tested and maintained. At present, the commonly used test and maintenance method is regression testing. During the regression test, a large amount of real online traffic is often recorded as a use case to perform automated regression to ensure that the service scenario can be fully covered. However, this method of directly recording a large amount of real online traffic as a use case has extremely high maintenance costs. Once the source code of the application changes, the use case needs to be manually modified, and the cost is uncontrollable. Summary of the invention

[0003] In view of the above problems, the present application provides a use case recommendation method, a use case recommendation system, an electronic device and a storage medium that solve the above problems or at least partially solve the above problems.

[0004] In one embodiment of the present application, a use case recommendation method is provided. The method comprises:

[0005] Acquire the collected data information of the online request call execution, wherein the data information includes interface data information and code line data information;

[0006] Extracting features from the interface data information to obtain interface feature information;

[0007] Determining a first use case set according to the interface feature information;

[0008] Determining code line coverage information according to the first use case set and the code line data information;

[0009] Determining a recommended second use case set according to the code line coverage information;

[0010] Based on the first use case set and the second use case set, a recommended use case set is determined for regression testing.

[0011] In another embodiment of the present application, a use case recommendation system is also provided. The system includes:

[0012] The collection end is used to collect online requests and record the data information of the collected online request calls and executions; wherein the data information includes interface data information and code line data information;

[0013] The recommendation end is used to obtain the data information from the acquisition end; perform feature extraction on the interface data information in the data information to obtain interface feature information; determine a first use case set based on the interface feature information; determine code line coverage information based on the first use case set and the code line data information in the data information; determine a second use case set based on the code line coverage information; and determine a recommended use case set for regression testing based on the first use case set and the second use case set.

[0014] In another embodiment of the present application, an electronic device is provided. The electronic device includes: a memory and a processor, wherein the memory is used to store a computer program; the processor is coupled to the memory and is used to execute the computer program stored in the memory to implement the steps in the use case recommendation method provided in each embodiment of the present application.

[0015] In another embodiment of the present application, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program, and when the computer program is executed, the steps in the use case recommendation method provided in each embodiment of the present application can be implemented.

[0016] The technical solutions provided by the embodiments of the present application will obtain the collected data information of the online request call execution, and the data information includes interface data information and code line data information; then, according to the interface feature information obtained by feature extraction of the interface data information, the first use case set can be determined, and the code line coverage information can be determined according to the first use case set and the code line data information, so as to determine the second use case set according to the code line coverage information, so as to determine the recommended use case set for regression testing according to the first use case set and the second use case set. This solution determines the recommended use case set by utilizing interface data information, code line data information (or, and method link data information), etc., which can not only ensure the simplicity of the recommended use cases (the number of use cases is relatively small), but also ensure the full coverage of the service scenarios to the greatest extent possible, so as to achieve the use of the minimum use case set to ensure the comprehensiveness of the test, and help reduce the use case construction and maintenance costs of testers. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0018] Figure 1 A flowchart of a use case recommendation method provided for implementation of the present application is provided;

[0019] Figure 2 A schematic diagram of the principle of collecting online requests provided for implementation of the present application is provided;

[0020] Figure 3 and Figure 4 A schematic diagram of the proposed use case provided is implemented for this application;

[0021] Figure 5 A schematic diagram of the principle of extracting features of the provided return value and determining the first use case set is implemented for the first application;

[0022] Figure 6 A schematic diagram of the structure of a use case recommendation device provided for implementation of the present application;

[0023] Figure 7 The present invention provides a structural schematic diagram of an electronic device provided for implementation of the present application. DETAILED DESCRIPTION

[0024] At present, the number of applications in the service systems provided by service providers is often large. With the development of services and personnel changes within service providers, the complexity of applications is also increasing day by day, and the number of application interfaces and the amount of abandoned code are also increasing. When the service system needs to be upgraded to improve the quality of online services and ensure the smooth operation of online services, it is extremely difficult to perform maintenance such as inspection and regression testing on the service system. In the existing solutions, in order to reduce the difficulty of testing, in the regression testing process, automatic regression is often performed by recording a large amount of real online traffic (requests) as use cases. Although the practice of recording a large amount of traffic as a use case for automatic regression can ensure full coverage of service scenarios as much as possible and reduce test omissions, due to the huge number of use cases, the assertion configuration cost and maintenance cost are extremely high, and once the source code of the application changes, the use case needs to be manually modified, and the cost is uncontrollable.

[0025] In order to solve the above problems, the present application provides a use case recommendation method, a use case recommendation system, an electronic device and a storage medium. This solution is based on the interface data information, code line data information and method link data information collected for online requests to implement use case recommendations for regression testing, and can ensure that the recommended use cases are both streamlined and can ensure full coverage of service scenarios as much as possible. In addition, the present application can also make intelligent assertion recommendations for recommended use cases, which can reduce the assertion configuration cost of the use cases. Moreover, the recommended use case logic also includes a use case replacement mechanism, which can avoid maintaining duplicate use cases and reduce the cost of use case configuration and maintenance.

[0026] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.

[0027] In some processes described in the specification, claims and the above-mentioned figures of this application, multiple operations appearing in a specific order are included, and these operations may not be executed or executed in parallel in the order in which they appear in this article. The serial numbers of the operations, such as 101, 102, etc., are only used to distinguish different operations, and the serial numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this article are used to distinguish different messages, devices, modules, etc., and do not represent the order of precedence, nor do they limit "first" and "second" to different types. The term "or / and" in this application is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example: A or / and B, indicating that A can exist alone, A and B can exist at the same time, and B can exist alone; the character " / " in this application generally indicates that the front and back associated objects are an "or" relationship. It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a product or system including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such product or system. In the absence of further restrictions, the elements defined by the sentence "including one..." do not exclude the existence of other identical elements in the product or system including the elements. In addition, the following embodiments are only some embodiments of the present application, not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present application.

[0028] The following is a detailed description of the use case recommendation method provided in each embodiment of the present application.

[0029] The execution subject of the use case recommendation method provided in the following embodiments may be a corresponding use case recommendation device, which may be a hardware with an embedded program integrated on an electronic device, or an application software installed in the electronic device, or a tool software embedded in the device operating system, etc., which is not limited in the embodiments of the present application. The electronic device may be a client or a server, wherein the client may be any terminal device such as a mobile phone, a tablet computer, a desktop computer, a laptop computer, a smart wearable device, etc., and the server may be a common server, a cloud or a virtual server, etc., which is not specifically limited in the embodiments of the present application.

[0030] Figure 1 FIG. 1 is a flow chart of a method for recommending a use case provided by an embodiment of the present application. Figure 1 The use case recommendation method provided in the embodiment of the present application includes the following steps:

[0031] 101. Acquire the collected data information of the online request call execution, wherein the data information includes interface data information and code line data information;

[0032] 102. Extract features from the interface data information to obtain interface feature information;

[0033] 103. Determine a first use case set according to the interface feature information;

[0034] 104. Determine code line coverage information according to the first use case set and the code line data information;

[0035] 105. Determine a second use case set according to the code line coverage information;

[0036] 106. Determine a recommended use case set for regression testing based on the first use case set and the second use case set.

[0037] In the above 101, the online request is a real request from the user, and the online request can also be called online traffic. Specifically, the online request may include but is not limited to browser requests, submission requests, etc. When collecting online requests, the collection can be performed according to the pre-set collection conditions. The collection conditions may include but are not limited to the collection frequency, request type, request environment (client type and application sending the request), collection ratio, etc. If the online request meets the collection conditions, the collection operation is performed; otherwise, if the online request does not meet the collection conditions, the collection is not performed.

[0038] Furthermore, for the collected online requests, the interfaces, code lines, method links, etc. that are executed by the online request calls will also be recorded. Specifically, when recording, the records can be stored in the corresponding data storage unit by day, week, month, etc. This embodiment does not specifically limit the period of record storage. Preferably, the records are stored by day. For example, when storing records by day, for code lines, each time a code line is called, a code line data record will be created for the called code line, and the recorded code line data may include a code line identifier, such as a code line number; similarly, for interfaces, each time an interface is called, an interface data record will be created for the called interface, wherein the recorded interface data may include but is not limited to an interface identifier, an interface signature, input parameters, return values, etc.; for method links, each time an online request is collected, a method link record can be created for the method called and executed by the online request. For example, for the collected online request 1, a method link record created is: method c1—>method c2.

[0039] Figure 2The schematic diagram shows the principle of collecting online requests and recording the data information of corresponding calls executed for the collected online requests.

[0040] According to the storage record cycle agreed upon above, the execution subject of this embodiment will periodically obtain the data information recorded for the collected online requests from the corresponding data storage unit. The obtained data information may include but is not limited to interface data information, code line data information, and method link data information.

[0041] The above-mentioned interface data information includes the interface data of each interface being called, and the interface data includes the return value and input parameter field of the corresponding interface, and the return value includes the return value field, the field value of the return value field, etc. When the interface data information is subsequently subjected to feature extraction, the field features of each field contained in the interface data information and the structural features of the return value may be extracted. Based on this, in an achievable technical solution, the above-mentioned interface data information contains at least one interface data, and each interface data includes a return value and at least one input parameter field; and the above-mentioned 102 "perform feature extraction on the interface data information to obtain interface feature information" may specifically include:

[0042] 1021. Extract features of the return value included in each piece of interface data to obtain at least one return value structure feature and at least one return value field feature;

[0043] 1022. Perform feature extraction on each input parameter field included in each piece of interface data to obtain at least one input parameter field feature.

[0044] In the above 1021, the structural type of the return value generally includes a structured return type and an unstructured return type. The structural format of the return value of the unstructured return type is often relatively simple, and the structural format is generally: {the specific value returned}; the structural format of the return value of the structured return type is often relatively complex, and its structural format often includes various fields and corresponding field values, etc. The structural format is such as: {field 1: field value, field 2: field value, ...}, and some of the various fields included above are meaningless fields and / or fields that disrupt the structure, such as account numbers, serial numbers and other class fields. Based on the above description, in order to reduce the amount of data processing for feature extraction, when it is determined that the return value is a structured return type, the return value may be denoised first, and then feature extraction may be performed. Therefore, assuming that the target return value is the return value included in an interface data in the interface data information, the method provided in this embodiment may also include the following steps:

[0045] 1020a. Determine whether it is necessary to denoise the target return value;

[0046] 1020b. When necessary, perform denoising on the target return value to obtain the denoised target return value; and trigger the step of "extracting features of the target return value" in the above step 1021 based on the denoised target return value.

[0047] In specific implementation, when denoising, some noise data in the target return value is removed. Noise data may include but is not limited to: fields with no service meaning such as account number and timestamp, and numerical fields that disrupt structural features such as ID and sequence number.

[0048] Furthermore, during feature extraction, the corresponding structural feature extraction method can be used to extract the structural framework of each return value to obtain the corresponding return value structural features, and then perform deduplication processing to finally obtain at least one return value structural feature. And the corresponding field feature extraction method can also be used to extract the field features of the return value field contained in each return value after denoising, so as to obtain at least one return value field feature. The structural feature extraction method and field feature extraction method described above can be any type of feature algorithm or feature extraction model, as long as it can accurately extract the structural framework of the return value and the field features of the return value field, and this embodiment is not limited by comparison. For example, the structural feature extraction method and the field feature extraction method can be a pre-trained machine learning model, such as a neural network model, a deep learning model, etc. Based on the above content, in a specific implementable scheme, the above 1021 "perform feature extraction on the return value included in each interface data to obtain at least one return value structural feature and at least one return value field feature" can be implemented by the following steps:

[0049] 10211. Extract the structural framework of each return value to obtain the return value structural features corresponding to each return value;

[0050] 10212. De-duplicate the obtained return value structure feature to obtain the at least one return value structure feature;

[0051] 10213. Perform feature extraction on the return value field contained in each return value to obtain at least one return value field feature.

[0052] In specific implementation, when feature extraction is performed on the return value of an unstructured return type, the extracted return value structure framework is generally "{}", and the fields contained in the return value are empty (null); accordingly, for the return value of the unstructured return type, the obtained return value structure features and return value field features are of empty type.

[0053] When extracting features from the return value of a structured return type, the extracted return value structure features and return value field features are often non-null types.

[0054] For example, taking the return value A of the structured return type as an example, assume that the structure of the return value A after denoising is as follows:

[0055] {'DEFAULT_MODEL_KEY',

[0056] 'models._defaultModel.437***.offerId', 'models._defaultModel.546***.offerId',

[0057] 'models._defaultModel.547***.offerId', 'models._defaultModel.547***..offerId',

[0058] 'models._defaultModel.583***.offerId', 'models._defaultModel.567***..offerId',

[0059] 'models._defaultModel.626***.offerId',

[0060] 'success'}

[0061] Then, the structural framework extracted from the above denoised return value A can be shown as follows:

[0062] {'DEFAULT_MODEL_KEY',

[0063] 'models._defaultModel...offerId', 'models._defaultModel...offerId',

[0064] 'models._defaultModel...offerId', 'models._defaultModel...offerId',

[0065] 'models._defaultModel...offerId', 'models._defaultModel....offerId',

[0066] 'models._defaultModel...offerId',

[0067] 'success'}

[0068] According to the structural framework of the return value A extracted above, the return value structural features of the return value A can be obtained as follows:

[0069] {'DEFAULT_MODEL_KEY','models...offerId','success'}

[0070] By analogy, the return value structural features of other return values ​​can also be obtained. After obtaining the return value structural features of each return value, the obtained return value structural features can be further deduplicated (de-included), so as to finally obtain at least one return value structural feature, and each return value structural feature in the at least one return value structural feature is different.

[0071] Fields (such as return value fields and input parameter fields) can be understood as attributes of data, and field values ​​represent the values ​​under the attributes. For example, still taking the above return value A as an example, the denoised return value A contains the following return value fields: DEFAULT_MODEL_KEY, models._defaultModel, models.offerId, success. When extracting features from the return value fields contained in the above return value, the extracted return value field features may include but are not limited to at least one of the following: attribute features of the field, semantic features of the field, content features of the field, field values ​​corresponding to the field, etc.; wherein, the semantic features of the field can be used to characterize the semantics of the field, and the content features of the field can be used to characterize the specific content corresponding to the field. According to the extracted return value field features of each return value field, the category to which each return value field belongs can be determined, such as environment field, parameter field, and parameter field can be further subdivided into enumeration field, numerical field (such as numerical range field, constant value field), ordinary field, etc.

[0072] Similarly, after obtaining the return value field features of each return value field contained in each return value, the obtained return value field features may be further deduplicated, thereby ultimately obtaining at least one return value field feature.

[0073] For the specific implementation of the above step 1022 "perform feature extraction on each input parameter field included in each interface data to obtain at least one input parameter field feature", please refer to the relevant content of performing feature extraction on each return value field included in each return value described above to obtain at least one return value field feature, which will not be described in detail here.

[0074] It should be supplemented here that: for the above-mentioned interface data information, before feature extraction, statistical analysis can be performed to determine the hotspot interface; then, based on the hotspot interface, feature extraction is performed on the interface data information to obtain interface feature information. Specifically, feature extraction is performed on the return value and input parameter field in the interface data corresponding to each hotspot interface. Therefore, before executing the above step 102, the method provided in this embodiment may also include the following steps:

[0075] S11, performing statistical analysis on each interface call according to the interface data information to determine the popularity of each interface;

[0076] S12, determining a hotspot interface according to the heat of each interface;

[0077] S13. Trigger execution of the above step 102 according to the hotspot interface.

[0078] For example, combined with Figure 2 , assuming that the data information obtained above is recorded for the n collected online requests, according to the interface data information, it is determined that interface a1 is called by request 1 and request 2 among the n online requests, then the number of times interface a1 is called is 2, and accordingly, the heat of interface a1 is 2 / n. By analogy, the heat of other interfaces can also be determined. Of course, the number of calls to each interface can also be directly regarded as the heat of each interface. According to the determined heat of each interface, the interface whose heat is greater than or equal to the preset heat threshold can be determined as a hotspot interface. The above heat threshold can be flexibly set according to actual conditions, and this embodiment does not make specific limitations.

[0079] From the above content, the interface characteristic information obtained includes at least one return value structure feature, at least one return value field feature, and at least one input parameter field feature. When determining the first use case set later, the corresponding different input parameter fields, return value fields, and return value structures can be combined by class according to the interface characteristic information to form different first use cases. Based on this, in an implementable solution, the above 103 "determine the first use case set according to the interface characteristic information" can specifically include:

[0080] 1031. Determine at least one type of return value field according to the at least one return value field feature;

[0081] 1032. Determine at least one type of input parameter field according to the at least one input parameter field feature;

[0082] 1033. Combine and process the at least one type of input parameter field, the at least one type of return value field, and the at least one return value structural feature to obtain at least one first use case.

[0083] In the above 1031, each return value field included in each return value may be clustered according to at least one return value field feature, so as to determine at least one type of return value according to the clustering analysis result. In the clustering analysis, the feature similarity between different return value field features may be analyzed, but not limited to. If the feature similarity is greater than or equal to a preset similarity threshold, the return value fields corresponding to the different return value field features may be clustered into one type.

[0084] For the specific implementation description of the above 1032, please refer to the specific implementation description of the above 1031, which will not be repeated here.

[0085] In the above 1033, when the combination processing is performed, the return value fields and input parameter fields of different categories and different return value structure features can be combined. Each combination can obtain a first use case. Each first use case is composed of at least one category of input parameter fields, at least one category of return value fields, and a return value structure feature. The at least one first use case obtained by the combination constitutes a first use case set.

[0086] Furthermore, in order to ensure the reliability of the first use case, assertion information can also be configured for the first use case. Assertions, also called verification points or run breakpoints, can be used to detect the "soundness" of the use case. In simple terms, assertions are comparisons between results and expectations. If the results are consistent with expectations, the assertion succeeds (the assertion is true) and the use case passes; if the results are inconsistent with the preset, the assertion fails (the assertion is false), the use case fails, and an exception reminder is thrown. For example, suppose there is a condition in the use case that the field value of field a must be greater than 18. The assertion provided can be: field a>18. If the assertion is true, the value of field a is greater than 18, and the use case will run normally; when the assertion is false, the assertion exception will be thrown, the use case will stop running, and the exception information will be printed.

[0087] At present, assertions are mostly manually written and configured, which has the problems of high configuration cost, large workload, and non-standard assertions. In this embodiment, assertions can be intelligently configured for use cases. Specifically, assertions can be intelligently configured for use cases based on the categories of each field contained in the use case, the return value structure characteristics, etc. Based on this, the above step 103 can also include the following steps:

[0088] 1034. Determine whether each first use case satisfies an assertion adding rule based on the category to which each field included in at least one first use case belongs and the return value structure characteristics;

[0089] 1035. To meet the first use case of adding assertion rules, configure adaptive assertion information.

[0090] In specific implementation, in the feature extraction stage, for each field feature (such as input parameter field feature, return value field feature) and return value structure feature extracted, it can be determined which categories of fields and return value structures need to add assertions. For example, if the return value structure feature is a non-empty type (such as a non-"{}" type), the field category is a valued or existing numeric field, etc., it can be determined that assertions need to be added. Afterwards, when adding assertions for the first use case, it can be determined in combination with the determination result whether the first use case meets the assertion adding rule, and if it does, the assertion can be automatically configured for the first use case, or the assertion can be recommended to the user (such as a tester or a use case maintenance personnel) for the first use case to configure the assertion based on the user's selection, or the use case that needs to add assertions can be recommended to the user so that the user can manually write the assertion, etc. This embodiment is not limited to this.

[0091] For example, assuming that the return value feature of a first use case T is a non-empty type, specifically {'DEFAULT_MODEL_KEY', 'models...offerId', 'success'}; and further, determining a numerical field of a return value field f contained in the first use case T, more specifically, a numerical range field that requires the field value to be greater than a certain numerical value, then it can be determined that the first use case T satisfies the assertion adding rule, and the field that needs to be asserted is the return value field f; then, the first use case T can be configured with adapted assertion information in the following ways:

[0092] Method 1: According to the return value field f included in the first use case T, a target assertion template matching the category to which the return value field f belongs can be selected from multiple preset assertion templates, so as to automatically add assertion information to the first use case T according to the target assertion template for the return value field f in the first use case T. For example, the return value field f can be filled into the adaptation position of the target assertion template to generate assertion information, and then the generated assertion information is added to the first use case T.

[0093] Method 2: For the first use case T, recommend to the user assertion information that can be added to the first use case T, wherein the assertion information can be generated using but not limited to the relevant content described in Method 1; if it is monitored that the user directly triggers a confirmation adding operation on the recommended assertion information, the recommended assertion information is added to the first use case T; if it is monitored that the user triggers a modification and confirmation adding operation on the recommended assertion information, the assertion information modified by the user can be added to the first use case T.

[0094] Method three: The first use case T that needs to add an assertion can be recommended to the user, and when recommending, the return value field f that needs to be asserted in the first use case T is highlighted, and / or a prompt message that an assertion needs to be added is displayed for the return value field f, so that the user can directly identify the field that needs to be asserted, and manually write the assertion information for the field that needs to be asserted.

[0095] Based on the above content, the step of “configuring adapted assertion information to meet the first use case of adding assertion rules” in 1035 above can be implemented by using the steps included in any of the following items:

[0096] Determine an adapted target assertion template for the first use case; generate the assertion information according to the target assertion module; add the assertion information to the first use case; or,

[0097] The first use case is displayed, wherein, when displayed, fields in the first use case that need to be asserted are highlighted; in response to an assertion configuration operation triggered by a user on the highlighted field, assertion information configured by the user is added to the first use case.

[0098] Figure 5 A schematic diagram showing the principle of extracting features from a return value and determining a first use case set.

[0099] In the above 104, the code line data information at least includes code line identification (such as code line number) information. Based on the code line identification information, the hot code lines that are actually called and executed online can be determined by heat statistics; then, the first use cases included in the first use case set obtained above are used as input data to analyze which hot code lines have been covered and which hot code lines have not been covered, so as to obtain code line coverage information. That is, in an achievable technical solution, the above 104 "determine the code line coverage information according to the first use case set and the code line data information" can specifically include:

[0100] 1041. Perform heat statistics on the code lines according to the code line identification information included in the code line data information to determine hot code lines;

[0101] 1042. Based on each first use case included in the first use case set, determine the covered code lines and uncovered code lines in the hotspot code lines.

[0102] In specific implementation, the number of times each code line is called can be counted based on the code line identification information, and the number of times each code line is called can be regarded as the heat of each code line; thus, the code line whose heat is greater than or equal to the corresponding heat threshold is determined as the hot code line. Furthermore, each first use case in the first use case set can be executed, and the code line identification of the called code line can be recorded during the execution process, so as to determine which of the above hot code lines are called and executed and which hot code lines are not called and executed based on the recorded code line identification, and the hot code lines that are called and executed are considered to be covered code lines, and the hot code lines that are not called and executed are considered to be uncovered code lines.

[0103] In the above 105, the use cases corresponding to the uncovered code lines can be determined according to the code line coverage information to form a second use case set, so that the use cases in the first use case set and the second use case set are used as recommended use cases for regression testing. Based on this, in an achievable solution, the above 105 "determining the second use case set according to the code line coverage information" includes:

[0104] 1051. Search, according to the code line coverage information, a use case corresponding to the uncovered code line from a use case pool;

[0105] 1052. Determine the second use case set according to the use cases corresponding to the uncovered code lines.

[0106] In specific implementation, the use cases in the use case pool are determined based on a large number of pre-recorded online requests. When performing a search operation on the uncovered code line, the use cases corresponding to the uncovered code line can be determined based on the situation that each use case in the use case pool has called and executed the uncovered code line to form the second use case set.

[0107] For example, suppose there are 100 hot code lines in total, among which, according to the first use case set, the hot code behaviors of lines 0 to 80 have been covered, and the remaining 20 lines (81 to 100) of hot code behaviors are not covered. For these uncovered code lines, you can find out from the use case pool which use cases have called and executed these uncovered code lines. Each time you search, you can prioritize the use cases that have called and executed the largest number of uncovered code lines as the use cases corresponding to the uncovered code lines. For example, if neither use case A nor use case B in the use case pool is in the first use case set, and during the first search, it is determined that use case A covers (has been called and executed) 10 lines of code from 81 to 91, and use case B covers 5 lines of code from 88 to 92, then use case A can be selected as the second use case and added to the second use case set, and the uncovered lines of code are updated. After the update, only 9 lines of code (92 to 100) remain uncovered; then, the use case that covers the most lines of code among the remaining 9 lines of code is searched from the use case pool again and added to the second use case set as the second use case, and so on, and the corresponding use cases are searched repeatedly from the use case pool until all uncovered lines of code are covered. After the above search, the use cases corresponding to all uncovered lines of code found can constitute the second use case set.

[0108] It should be noted here that the above operation of reversely searching the use cases corresponding to the uncovered code lines from the use case pool can be called use case reverse analysis.

[0109] In the above 106, each use case in the first use case set and each use case in the second use case set may be aggregated and superimposed to obtain a final recommended use case set.

[0110] Furthermore, the acquired data information may include method link data information in addition to interface data information and code data information, and the second use case set determined in step 105 may be supplemented with use cases based on the method link data information to improve the coverage of service scenarios. Based on this, the method provided in this embodiment may also include the following steps:

[0111] 107. Determine a hotspot method link according to the method link data information;

[0112] 108. Searching for a use case corresponding to the hot method link from the use case pool;

[0113] 109. Add the use case corresponding to the hotspot method link to the second use case set; or, determine a third use case set based on the use case corresponding to the hotspot method link, so as to determine a recommended use case set based on the third use case set, the first use case set and the second use case set.

[0114] In specific implementation, the method links can be subjected to heat statistics analysis based on the method link data information to determine the heat of each method link, and then the hot method link can be determined based on the heat of each method link. When performing a search operation on a hot method link, if one or more use cases in the use case pool have called and executed the hot method link, the use case corresponding to the one or more use cases in this hot method link is determined.

[0115] For example, combined with Figure 2 , assuming that the above method link data information is recorded for the n collected online requests, according to the method link data information, after statistical analysis, it is determined that a method link Link1 "method c1->method c2" is called by the three requests of request 1, request 4, and request 5 among the n online requests, then the number of times this method link Link1 is called is 3, and accordingly, the heat is 3 / n. By analogy, the heat of other method links can also be determined. Of course, the number of calls of each method link can also be directly regarded as the heat of each method link. According to the heat of each method link determined, the method link whose heat is greater than or equal to the preset heat threshold can be determined as a hot method link. The above heat threshold can be flexibly set according to actual conditions, and this embodiment does not make specific restrictions. Further, if it is determined that the above method link Link1 is a hot method link, and this method link Link1 has been called and executed by use case 1 and use case 3 in the use case pool, then use case 1 and use case 3 are the use cases corresponding to method link Link1. By analogy, the use cases corresponding to other hot links can also be determined.

[0116] Adding the use cases corresponding to the above hot method links to the second use case set can cover the missed hot rows.

[0117] In summary, the technical solution provided in this embodiment will obtain the data information collected from the online request call execution, and the data information includes interface data information and code line data information; then, according to the interface feature information obtained by feature extraction of the interface data information, the first use case set can be determined, and the code line coverage information can be determined according to the first use case set and the code line data information, so as to determine the second use case set according to the code line coverage information, so as to determine the recommended use cases for regression testing according to the first use case set and the second use case set. This solution determines the recommended use cases by utilizing interface data information and code line data information, etc., which can not only ensure the simplicity of the recommended use cases (the number of use cases is relatively small), but also ensure the full coverage of the service scenarios to the greatest extent possible, so as to achieve the use of the minimum use case set to ensure the comprehensiveness of the test, and help reduce the use case construction and maintenance costs of testers.

[0118] Furthermore, after the second use case set (or, and the third use case set) is determined, assertion information can also be configured for each use case in the second use case set (or, and the third use case set), wherein the method of configuring the assertion information may be, but is not limited to, intelligent automatic addition of assertions or manual addition of assertions. For the implementation of intelligent automatic addition of assertions, please refer to the above-described implementation description of intelligent configuration of adaptive assertion information for the first use case, which will not be described in detail here. And, and / or the currently determined second use case set (or, and the third use case set) can also be superimposed with the previously recommended existing use case set to update the existing use case set, so as to use the updated existing use case set as the final use case set for regression testing. Wherein, when superimposing, based on the corresponding use case replacement mechanism (replacement rule), a replacement operation can be performed to filter out duplicate use cases, thereby avoiding the maintenance of duplicate use cases and reducing use case maintenance costs, configuration costs, etc.

[0119] For implementation of the use case recommendation method provided in the above embodiment, see Figure 3 As shown, it can be briefly described as follows:

[0120] See Figure 3 , three types of data information can be collected by collecting online requests, namely, interface data information, code line data information, and method link data information. Each interface data in the interface data information includes interface signature, input parameters, return value, etc. After feature extraction, combination, etc. of the return value, input parameters, etc., the coarsest granularity of simplified use cases can be obtained. Before feature extraction, combination, etc., the interface data information can also be subjected to heat statistics analysis to determine the hot interface, so as to perform feature extraction, combination, etc. on the return value, input parameters, etc. corresponding to the hot interface. The above code line data information includes the line number information of the code line called and executed. After heat statistics of the code line data information, the hot code lines actually used online can be obtained; using the above simplified use cases as input data, it is possible to analyze which hot code lines have been covered and which hot code lines have not been covered, so as to reversely find the use cases corresponding to the uncovered hot code lines from the use case pool and add them to the recommended use case set. The above reverse operation of finding the use cases corresponding to the covered hot code lines from the use case pool is called use case reverse analysis. Furthermore, the above-mentioned method link data information includes the method link of the interface. By clustering and performing heat statistics analysis on the method link data information, the hot method links actually used online can be obtained. The use cases corresponding to the hot method links can be found from the use case pool and added to the recommended use case set, which can cover the high-hotspot code lines missed in the reverse analysis of the use case.

[0121] It is necessary to add that: identifying hot interfaces can help testers quickly locate the core interfaces of applications; identifying hot code lines can provide scientific and reliable "denominator" data for line coverage indicators); identifying hot method links can help testers identify the core scenarios and important links of applications. And, Figure 3 The derived data shown in the figure may include the hot code line results counted in the current period (daily, weekly, monthly, etc.), the hot code line results counted in the historical period, the hot code line data that the application should cover, the hot code line data that the application has covered, the line-level hot code coverage of the application, the hot code line data that a single interface should cover, the hot code line data that a single interface has covered, the line-level hot code coverage of a single interface, etc. During the reverse analysis of the use case, the derived data can be used as follows:

[0122] 1) The hot code line results counted on a daily / weekly basis can help technicians understand the core code in the engineering code. The higher the number of calls, the more important the content is and the more quality assurance is needed.

[0123] 2) The first use case set selects the required use cases through structural analysis of traffic data, which is a forward analysis. The code lines covered by the first use case set are excluded in the reverse analysis of the use cases. For the code lines not covered by the first use case set, use cases corresponding to the code lines not covered by the first use case set will be selected from the use case pool (pre-recorded traffic) as supplementary use cases to supplement the use cases for the first use case set. During the reverse analysis of this use case, the data of the hot code lines that should be covered by the application will be used to remove the data of the hot code lines that have been covered, so as to obtain the code lines that are not covered by the use cases. The above-mentioned supplementary use cases are the use case results obtained by filtering the recorded traffic through the uncovered code lines. The screening process is also called the reverse analysis of the use cases.

[0124] Or, see Figure 4 As shown, it can be briefly described as follows: according to the characteristic information corresponding to the interface data information (such as return value structure characteristics, return value field characteristics, input parameter field characteristics, etc.), code line data information and method link data information, feature-based use case screening, code line-based use case screening, and method link-based use case screening can be performed respectively, so as to determine the recommended use case based on the screening results.

[0125] In summary, this solution adopts a triple recommendation mechanism to recommend use cases. Specifically, it adopts a triple recommendation mechanism to intelligently select corresponding use cases from the use case pool (pre-recorded online traffic) as recommended use cases. Using the use cases recommended by this method for regression testing can enable the application to achieve about 80% hotspot code coverage. Moreover, this solution can achieve one-click test coverage capabilities by recommending use cases and combining intelligent assertions. Under the premise of ensuring the improvement of overall quality stability, it is expected to save 10 man-days per existing application, 1 man-day / regression / time after release, and 0.5 man-days / new interface release self-test in daily quality assurance work in the later stage.

[0126] Another embodiment of the present application also provides a flowchart of a use case recommendation method. The use case recommendation method includes the following steps:

[0127] 201. Acquire the collected data information of the online request call execution, wherein the data information includes interface data information, code line data information, and method link information;

[0128] 202. Extract features from the interface data information to obtain interface feature information;

[0129] 203. Determine a first use case set according to the interface feature information;

[0130] 204. Determine code line coverage information according to the first use case set and the code line data information;

[0131] 205. Determine a second use case set according to the code line coverage information;

[0132] 206. Determine a third use case set according to the method link information;

[0133] 207. Determine a recommended use case set for regression testing based on the first use case set, the second use case set, and the third use case set.

[0134] For the specific implementation description of the above 201 to 207, please refer to the relevant content in other embodiments above.

[0135] It should be noted here that the use case recommendation method provided in this embodiment may include other steps in addition to the steps given above. For other steps that may be included and specific implementation descriptions, please refer to the relevant content in other embodiments above, and no further details will be given here.

[0136] Another embodiment of the present application also provides a use case recommendation system. The use case recommendation system includes: a collection end and a recommendation end, wherein:

[0137] The collection end is used to collect online requests and record the data information of the collected online request calls and executions; wherein the data information includes interface data information and code line data information;

[0138] A recommendation end is used to obtain the data information from the acquisition end; perform feature extraction on the interface data information in the data information to obtain interface feature information; determine a first use case set according to the interface feature information; determine code line coverage information according to the first use case set and the code line data information in the data information; determine a second use case set according to the code line coverage information; determine a recommended use case set for regression testing according to the first use case set and the second use case set

[0139] The above-mentioned collection end may be an online collection machine for collecting online requests, such as a client. The recommendation end may be a server end with data processing capabilities.

[0140] Furthermore, the above data information also includes method link data information; and

[0141] The above-mentioned recommendation end is also used to determine the hot method link based on the method link data information; search for the use case corresponding to the hot method link from the use case pool; add the use case corresponding to the hot method link to the second use case set; or, determine the third use case set based on the use case corresponding to the hot method link, so as to determine the recommended use case set based on the third use case set, the first use case set and the second use case set.

[0142] It should be noted here that, in addition to being able to execute the above-mentioned steps, each end included in the use case recommendation system provided in this embodiment can also execute other steps. For the specific steps that each end can execute and the implementation description of each step, please refer to the relevant content in other embodiments above, and no further details will be given here.

[0143] Figure 6 FIG. 1 shows a structural block diagram of a use case recommendation device provided by an embodiment of the present application. Figure 6 As shown, the use case recommendation device includes: an acquisition module 31, an extraction module 32 and a determination module 33; wherein,

[0144] The acquisition module 31 is used to acquire the collected data information of the online request call execution, wherein the data information includes interface data information and code line data information;

[0145] An extraction module 32, used to extract features from the interface data information to obtain interface feature information;

[0146] The determination module 33 is used to determine the first use case set based on the interface feature information; and is also used to determine the code line coverage information based on the first use case set and the code line data information; determine the second use case set based on the code line coverage information; and determine the recommended use case set for regression testing based on the first use case set and the second use case set.

[0147] Furthermore, the above-mentioned interface data information contains at least one interface data, and each interface data includes a return value and at least one input parameter field; and the above-mentioned extraction module 32, when used to perform feature extraction on the interface data information to obtain interface feature information, can be specifically used for: performing feature extraction on the return value included in each interface data to obtain at least one return value structure feature and at least one return value field feature; performing feature extraction on each input parameter field included in each interface data to obtain at least one input parameter field feature.

[0148] Furthermore, the above-mentioned extraction module 32, when used to perform feature extraction on the return value included in each interface data to obtain at least one return value structural feature and at least one return value field feature, can be specifically used to: extract the structural framework of each return value to obtain the return value structural feature corresponding to each return value; deduplicate the obtained return value structural feature to obtain the at least one return value structural feature; perform feature extraction on the return value field contained in each return value to obtain the at least one return value field feature.

[0149] Furthermore, the target return value is a return value included in an interface data in the interface data information, and the device provided in this embodiment also includes: a determination module, used to determine whether it is necessary to denoise the target return value; a denoising module, used to denoise the target return value when necessary to obtain the denoised target return value; a trigger execution module, used to trigger the execution of the step of extracting features from the target return value according to the denoised target return value.

[0150] The above-mentioned determination module 33, when used to determine the first use case set based on the interface characteristic information, is specifically used to: determine at least one type of return value field based on the at least one return value field characteristic; determine at least one type of input parameter field based on the at least one input parameter field characteristic; combine the at least one type of input parameter field, the at least one type of return value field, and the at least one return value structure characteristic to obtain at least one first use case.

[0151] Furthermore, the above-mentioned determination module 33 can also be used to determine whether each first use case satisfies the assertion adding rule based on the category to which each field contained in at least one first use case belongs and the return value structure characteristics; and the device provided in this embodiment also includes: a configuration module, which is used to configure adapted assertion information for the first use case that satisfies the assertion adding rule.

[0152] Furthermore, the above-mentioned determination module 33, when used to determine the code line coverage information based on the first use case set and the code line data information, is specifically used to: determine the hot code lines based on the code line identification information contained in the code line data information; based on each first use case contained in the first use case set, determine the covered code lines and the uncovered code lines in the hot code lines.

[0153] Furthermore, the above-mentioned determination module 33, when used to determine the recommended second use case set based on the code line coverage information, is specifically used to: search for use cases corresponding to uncovered code lines from a use case pool based on the code line coverage information; and determine the second use case set based on the use cases corresponding to the uncovered code lines.

[0154] Furthermore, the above-mentioned data information also includes method link data information; and the above-mentioned determination module 33 is also used to determine the hotspot method link based on the method link data information; and the device provided in this embodiment also includes: a search module, used to search for the use case corresponding to the hotspot method link from the use case pool; add the use case corresponding to the hotspot method link to the second use case set, or determine the third use case set based on the use case corresponding to the hotspot method link, so as to determine the recommended use case set based on the third use case set, the first use case set and the second use case set.

[0155] It should be noted here that: for the contents not fully described in the steps of the use case recommendation device provided in this embodiment, please refer to the corresponding contents of the above embodiments, and no further description will be given here. In addition, in addition to the above steps, the use case recommendation device provided in this embodiment may also include other parts or all of the steps in the above embodiments, and the details may be referred to the corresponding contents of the above embodiments, and no further description will be given here.

[0156] Another embodiment of the present application provides a use case recommendation device, the structure of which is similar to Figure 6 Specifically, the use case recommendation device provided in the embodiment of the present application includes: an acquisition module, an extraction module and a determination module; wherein,

[0157] An acquisition module is used to acquire the collected data information of the online request call execution, wherein the data information includes interface data information, code line data information, and method link data information;

[0158] An extraction module, used for extracting features from the interface data information to obtain interface feature information;

[0159] A determination module is used to determine a first use case set based on the interface feature information; and is also used to determine code line coverage information based on the first use case set and the code line data information; determine a second use case set based on the code line coverage information; determine a third use case set based on the method link information; and determine a recommended use case set for regression testing based on the first use case set, the second use case set and the third use case set.

[0160] It should be noted here that: for the contents not fully described in the steps of the use case recommendation device provided in this embodiment, please refer to the corresponding contents of the above embodiments, and no further description will be given here. In addition, in addition to the above steps, the use case recommendation device provided in this embodiment may also include other parts or all of the steps in the above embodiments, and the details may be referred to the corresponding contents of the above embodiments, and no further description will be given here.

[0161] Figure 7 FIG. 1 shows a schematic diagram of a structure of an electronic device provided by an embodiment of the present application. Figure 7 As shown, the electronic device includes: a memory 41 and a processor 42. The memory 41 is used to store one or more computer instructions; the processor 42, coupled with the memory 41, is used for one or more computer instructions (such as computer instructions for implementing data storage logic) to implement the steps in the use case recommendation method provided in each embodiment of the present application.

[0162] The above-mentioned memory 41 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0163] Further, if Figure 7 As shown, the processing device may also include: a communication component 43, an audio component 44, a power supply component 45 and other components. Figure 7 Only some components are shown schematically, which does not mean that the processing device only includes Figure 7 Components shown.

[0164] Accordingly, an embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed, it can implement the use case recommendation method steps or functions provided in the above-mentioned embodiments of the present application.

[0165] The method in the present application can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. Therefore, the present application also provides a computer program product, which includes a computer program / instructions. When the computer program / instructions are executed by a processing component such as a processor, the process or function in the use case recommendation method provided in each embodiment of the present application can be executed in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user device, a core network device, an OAM or other programmable device.

[0166] The computer program or instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer program or instructions may be transmitted from one website, computer, server or data center to another website, computer, server or data center by wired or wireless means. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium, such as a floppy disk, a hard disk, or a magnetic tape; it may also be an optical medium, such as a digital video disk; it may also be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both volatile and non-volatile types of storage media.

[0167] Through the description of the above implementation modes, those skilled in the art can clearly understand that each implementation mode can be implemented by means of software plus a necessary general hardware platform, and of course, can also be implemented by hardware. Based on such an understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0168] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A use case recommendation method, characterized in that: include: Acquire the collected data information of the online request call execution, wherein the data information includes interface data information and code line data information; Extracting features from the interface data information to obtain interface feature information; Determining a first use case set according to the interface feature information; Determining code line coverage information according to the first use case set and the code line data information; Determine a second use case set according to the code line coverage information; Based on the first use case set and the second use case set, a recommended use case set is determined for regression testing.

2. The method according to claim 1, characterized in that The interface data information contains at least one piece of interface data, each piece of interface data includes a return value and at least one input parameter field; as well as, Extracting features from the interface data information to obtain interface feature information includes: Extracting features of the return value included in each piece of interface data to obtain at least one return value structure feature and at least one return value field feature; Feature extraction is performed on each input parameter field included in each piece of interface data to obtain at least one input parameter field feature.

3. The method according to claim 2, characterized in that Perform feature extraction on the return value included in each piece of interface data to obtain at least one return value structure feature and at least one return value field feature, including: Extract the structural framework of each return value to obtain the return value structural features corresponding to each return value; Deduplication processing is performed on the obtained return value structural features to obtain the at least one return value structural feature; Feature extraction is performed on the return value field contained in each return value to obtain the at least one return value field feature.

4. The method according to claim 2, characterized in that: The target return value is a return value included in an interface data in the interface data information. And, the method further comprises: Determine whether it is necessary to denoise the target return value; When necessary, denoising the target return value to obtain the denoised target return value; According to the denoised target return value, the step of extracting features from the target return value is triggered.

5. The method according to any one of claims 2 to 4, characterized in that Determining a first use case set according to the interface feature information includes: Determine at least one type of return value field according to the at least one return value field feature; Determining at least one type of input parameter field according to the at least one input parameter field feature; The at least one type of input parameter field, the at least one type of return value field, and the at least one return value structural feature are combined and processed to obtain at least one first use case.

6. The method according to claim 5, characterized in that Also includes: Based on the category to which each field included in at least one first use case belongs and the return value structure characteristics, determining whether each first use case satisfies the assertion adding rule; To meet the first use case of adding assertion rules, configure the adapted assertion information.

7. The method according to claim 6, characterized in that To meet the first use case of adding assertion rules, configure the adapted assertion information, including: Determine an adapted target assertion template for the first use case; generate the assertion information according to the target assertion template; add the assertion information to the first use case; or The first use case is displayed, wherein, when displayed, fields in the first use case that need to be asserted are highlighted; in response to an assertion configuration operation triggered by a user on the highlighted field, assertion information configured by the user is added to the first use case.

8. The method according to any one of claims 2 to 4, characterized in that Determining code line coverage information according to the first use case set and the code line data information includes: Determine the hot code line according to the code line identification information included in the code line data information; Based on each first use case included in the first use case set, the covered code lines and the uncovered code lines in the hotspot code lines are determined.

9. The method according to claim 8, characterized in that Determining a second use case set according to the code line coverage information includes: According to the code line coverage information, searching for use cases corresponding to the uncovered code lines from a use case pool; The second use case set is determined according to the use cases corresponding to the uncovered code lines.

10. The method according to claim 9, characterized in that The data information also includes method link data information; as well as The method further comprises: Determining a hotspot method link according to the method link data information; From the use case pool, searching for a use case corresponding to the hot method link; Add the use case corresponding to the hot method link to the second use case set; or, determine a third use case set based on the use case corresponding to the hot method link, so as to determine a recommended use case set based on the third use case set, the first use case set and the second use case set.

11. A use case recommendation system, characterized in that: include: The collection end is used to collect online requests and record the data information of the collected online request calls and executions; wherein the data information includes interface data information and code line data information; The recommendation end is used to obtain the data information from the acquisition end; perform feature extraction on the interface data information in the data information to obtain interface feature information; determine a first use case set based on the interface feature information; determine code line coverage information based on the first use case set and the code line data information in the data information; determine a second use case set based on the code line coverage information; and determine a recommended use case set for regression testing based on the first use case set and the second use case set.

12. The system according to claim 11, characterized in that The data information also includes method link data information; and The recommendation end is further used to determine a hot method link according to the method link data information; and to search for a use case corresponding to the hot method link from a use case pool; Adding the use case corresponding to the hotspot method link to the second use case set; Alternatively, a third use case set is determined according to the use case corresponding to the hotspot method link, so as to determine a recommended use case set according to the third use case set, the first use case set and the second use case set.

13. An electronic device, characterized in that: include: A memory and a processor, wherein The memory is used to store computer programs; The processor, coupled to the memory, is configured to execute the computer program stored in the memory to implement the steps in the use case recommendation method according to any one of claims 1 to 10.

14. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which, when executed, can implement the steps in the use case recommendation method according to any one of claims 1 to 10.