Test case determination method and device, computer equipment, computer readable storage medium and computer program product

Abstract

The invention relates to a test case determination method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the steps of analyzing context log code data of a change code block corresponding to a test object based on a static code analysis model and a function call relation tree corresponding to the test object, and determining one or more groups of code execution logic data of the change code block; aiming at each group of code execution logic data, determining a plurality of test cases corresponding to each logic node in the code execution logic data based on a test case and code association relationship library; based on the number of hit times of each test case in the code execution logic data, determining a hit probability value of each test case selected by the code execution logic data; and determining the test case corresponding to the hit probability value meeting the preset selected condition as a target test case of the code execution logic. By adopting the method, the efficiency of accurately testing the code can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer device, readable storage medium, and program product for determining test cases. Background Technology

[0002] As software development continues to evolve, the codebase of software in scenarios such as communication services and Android systems is growing larger and more complex, leading to increasingly larger test case libraries and higher costs for testing and test case maintenance. To improve testing efficiency and make the entire testing process more efficient, accurate, and reliable, precision testing technology has emerged. Precision testing refers to obtaining a final list of test cases based on the scope of code changes and the relationships between test cases and code (generally established through functions and the context of function calls), thus accurately locating the scope of code testing.

[0003] In related technologies, the method for accurate testing typically involves running the test case by instrumenting code for each new test case. This allows the dynamic execution logic of the code to be understood. Then, by statically compiling and parsing the source code, the static calling logic can be obtained. Finally, based on the scope of changes made in the code submission and combined with the analysis of the static calling logic, the dynamic execution logic of the code with a high degree of matching can be derived, thus obtaining the corresponding test cases. However, code instrumentation requires inserting additional code snippets into the source code, usually at the entry and exit points of functions. For functions with high cyclomatic complexity, this can lead to lower accuracy in testing changed code. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for determining test cases that can improve the efficiency of accurate code testing, in order to address the above-mentioned technical problems.

[0005] Firstly, this application provides a method for determining test cases, including:

[0006] Based on the static code parsing model and the function call relationship tree corresponding to the test object, the context log code data of the modified code block corresponding to the test object is analyzed to determine one or more sets of code execution logic data of the modified code block;

[0007] For each set of code execution logic data, based on the test case and code association library, multiple test cases corresponding to each logical node in the code execution logic data are determined; based on the number of times each test case is hit in the code execution logic data, the hit probability value of selecting each test case in the code execution logic data is determined;

[0008] The test cases corresponding to the hit probability values ​​that meet the preset selection conditions are determined as the target test cases for the code execution logic.

[0009] In one embodiment, the method further includes:

[0010] The source code file is parsed based on the static code parsing model to determine the location data of each function and the calling relationship between each function; based on the location data and the calling relationship, the function call relationship tree is generated.

[0011] In one embodiment, the method further includes:

[0012] Based on the log file parsing model, the dynamic log files generated by each test case when executing the source code file are parsed to determine the dynamic log data;

[0013] Based on the feature generation model, feature extraction is performed on the dynamic log data to obtain the dynamic log features corresponding to each test case.

[0014] Based on the dynamic log features, static log feature library and function call relationship tree, the sample code execution logic data for each test case is determined;

[0015] The correspondence between multiple test cases and the sample code execution logic data corresponding to each test case is determined as the test case and code association library.

[0016] In one embodiment, the dynamic log features include the positional features of each logical node in the execution logic code of the test case and the dynamic log content features. The step of determining the code execution logic data for each test case based on the dynamic log features, the static log feature library, and the function call relationship tree includes:

[0017] In response to the fact that the dynamic log feature does not include the location feature, based on a preset matching algorithm, the dynamic log content feature is matched with each static log content feature in the static log feature library to obtain a first matching result. The target static log content feature corresponding to the first matching result that satisfies the first preset matching condition is determined, and the location feature corresponding to the target static log content feature is determined as the location feature corresponding to the dynamic log feature.

[0018] In response to the dynamic log features of the test case not meeting the execution logic conditions, the code execution logic data for each test case is determined based on the function call relationship tree, the dynamic log content features, and the position features corresponding to the dynamic log features.

[0019] In one embodiment, the analysis of the context log code data of the modified code block corresponding to the test object based on the static code parsing model and the function call relationship tree corresponding to the test object, to determine one or more sets of code execution logic data of the modified code block, includes:

[0020] Identify the static log code data of the code logic at the same level as the changed code block corresponding to the test object; based on the static code parsing model, parse the static log code data to determine the first static log feature;

[0021] Based on the first static log features and the function call relationship tree, determine the multiple sets of calling functions and called functions corresponding to the modified code block;

[0022] For each group of calling functions and called functions, based on the static code parsing model, the static log code data of the calling functions and called functions is parsed to determine the second static log feature corresponding to the static log code data of the calling functions and called functions. Based on the second static log feature data, a set of code execution logic data of the modified code block is determined.

[0023] In one embodiment, determining multiple test cases corresponding to each logical node in the code execution logic data based on the test case and code association library includes:

[0024] For each logical node in the code execution logic data, based on a preset matching algorithm, a second matching result is calculated between the logical node and each sample logical node in the test case and code association database; the test cases corresponding to the sample logical nodes that satisfy the second preset matching conditions are determined as the test cases corresponding to the logical node.

[0025] Secondly, this application also provides a test case determination apparatus, comprising:

[0026] The first determining module is used to analyze the context log code data of the modified code block corresponding to the test object based on the static code parsing model and the function call relationship tree corresponding to the test object, and determine one or more sets of code execution logic data of the modified code block;

[0027] The second determining module is used to determine, for each set of code execution logic data, multiple test cases corresponding to each logical node in the code execution logic data based on the test case and code association library; and to determine the hit probability value of selecting each test case in the code execution logic data based on the number of times each test case is hit in the code execution logic data.

[0028] The testing module is used to determine the test cases corresponding to the hit probability values ​​that meet the preset selection conditions as the target test cases for the code execution logic.

[0029] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0030] Based on the static code parsing model and the function call relationship tree corresponding to the test object, the context log code data of the modified code block corresponding to the test object is analyzed to determine one or more sets of code execution logic data of the modified code block;

[0031] For each set of code execution logic data, based on the test case and code association library, multiple test cases corresponding to each logical node in the code execution logic data are determined; based on the number of times each test case is hit in the code execution logic data, the hit probability value of selecting each test case in the code execution logic data is determined;

[0032] The test cases corresponding to the hit probability values ​​that meet the preset selection conditions are determined as the target test cases for the code execution logic.

[0033] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0034] Based on the static code parsing model and the function call relationship tree corresponding to the test object, the context log code data of the modified code block corresponding to the test object is analyzed to determine one or more sets of code execution logic data of the modified code block;

[0035] For each set of code execution logic data, based on the test case and code association library, multiple test cases corresponding to each logical node in the code execution logic data are determined; based on the number of times each test case is hit in the code execution logic data, the hit probability value of selecting each test case in the code execution logic data is determined;

[0036] The test cases corresponding to the hit probability values ​​that meet the preset selection conditions are determined as the target test cases for the code execution logic.

[0037] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0038] Based on the static code parsing model and the function call relationship tree corresponding to the test object, the context log code data of the modified code block corresponding to the test object is analyzed to determine one or more sets of code execution logic data of the modified code block;

[0039] For each set of code execution logic data, based on the test case and code association library, multiple test cases corresponding to each logical node in the code execution logic data are determined; based on the number of times each test case is hit in the code execution logic data, the hit probability value of selecting each test case in the code execution logic data is determined;

[0040] The test cases corresponding to the hit probability values ​​that meet the preset selection conditions are determined as the target test cases for the code execution logic.

[0041] The aforementioned method, apparatus, computer equipment, computer-readable storage medium, and computer program product for determining test cases analyze the context log code data of the modified code block corresponding to the test object based on a static code parsing model and the function call relationship tree corresponding to the test object, thereby determining one or more sets of code execution logic data for the modified code block. This improves the accuracy of locating the code execution logic data of the modified code block in complex scenarios through static logs and function call relationships. For each set of code execution logic data, multiple test cases corresponding to each logical node in the code execution logic data are determined based on a test case and code association library. Based on each test case... The hit probability value of each test case is determined by the number of hits in the code execution logic data. This achieves automated screening of test cases, improving the efficiency and accuracy of test case screening. Test cases with hit probability values ​​that meet preset selection conditions are identified as target test cases for the code execution logic data. The modified code block is tested based on the target test cases to obtain test results. This achieves the selection of effective test cases to test the modified code, improving the effectiveness of test cases. While ensuring test effectiveness, the test scope is accurately narrowed, improving the testing efficiency of the modified code block, and further improving the performance and reliability of the system where the test object is located. Attached Figure Description

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

[0043] Figure 1This is a flowchart illustrating a method for determining test cases in one embodiment;

[0044] Figure 2 This is a flowchart illustrating a method for determining test cases in one embodiment;

[0045] Figure 3 This is a flowchart illustrating a method for determining test cases in one embodiment;

[0046] Figure 4 This is a structural block diagram of a device for determining test cases in one embodiment;

[0047] Figure 5 This is an internal structural diagram of a computer device in one embodiment; Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0049] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0050] In one exemplary embodiment, such as Figure 1 As shown, a method for determining test cases is provided. This embodiment illustrates the application of this method to a terminal. It is understood that this method can also be applied to a server, and further to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0051] Step 101: Based on the static code parsing model and the function call relationship tree corresponding to the test object, analyze the context log code data of the changed code block corresponding to the test object to determine one or more sets of code execution logic data of the changed code block.

[0052] The static code parsing model is a model for parsing context log code data. The test object refers to a software product with executable code carrier attributes, used to provide specific functions to users. It can receive code change instructions through a continuous integration / continuous delivery (CI / CD) pipeline to achieve version building, testing, deployment, and functional / performance updates. Optionally, change instructions can include update code commit instructions and update version release instructions, etc. For example, the test object can include game software, web products, and various software forms such as client applications, server systems, embedded firmware, and AI services. The function call relationship tree includes the meaning of each function in the source code files of the source code library and the function call relationships. The call relationship includes the calling function and the called function for each function. A modified code block refers to a code segment in the source code library where code has been modified, added, or deleted. Optionally, a modified code block can be a single function, a class, a set of interface definitions, a configuration script, or a collection of multiple related code units. Context log code data refers to the printed log data of the logical node to which the modified code block belongs, as well as the printed log data of the calling and called functions. This printed log data includes the input and output parameters, variable declarations, dependent global constants, etc., of the function to which the modified code block belongs. Code execution logic data represents the logical node to which the modified code belongs, the execution logic within that logical node, the calling logic of the calling and called functions, and the execution dependencies.

[0053] Specifically, the terminal can respond to code change instructions; and the terminal can compare the original codebase with the current codebase using version control tools to obtain the changed code block corresponding to the test object. The terminal can determine the static log code data at the same level of code logic as the changed code block; based on the static code parsing model, it can parse the static log code data to determine the first static log feature; based on the first static log feature and the function call relationship tree, it can determine multiple sets of calling functions and called functions corresponding to the changed code block; for each set of calling functions and called functions, based on the static code parsing model, it can parse the static log code data of the calling functions and called functions to determine the second static log feature corresponding to the static log code data of the calling functions and called functions; based on the second static log feature data, it can determine a set of code execution logic data of the changed code block. Optionally, when the changed code block includes multiple sets of calling functions and called functions, multiple sets of code execution logic data can be obtained.

[0054] Step 102: For each set of code execution logic data, based on the test case and code association library, determine multiple test cases corresponding to each logical node in the code execution logic data; based on the number of times each test case is hit in the code execution logic data, determine the hit probability value of selecting each test case in the code execution logic data.

[0055] The test case and code association library includes multiple test cases and their associated code execution logic. A test case is a standardized verification scheme that is pre-built to verify whether the functionality or performance of a test object meets preset standards. It contains input data, execution steps, and expected results and is used for repeatable test execution, defect verification, and regression testing.

[0056] Specifically, the terminal can, for each logical node in each set of code execution logic data, calculate a second matching result between the logical node and each sample logical node in the test case and code association database based on a preset matching algorithm; the test cases corresponding to the sample logical nodes that satisfy the second preset matching conditions are then identified as the test cases corresponding to the logical nodes. Optionally, each logical node may hit multiple test cases or may not hit any test cases. The terminal can obtain the total number of logical nodes in each set of code execution logic data, determine the number of times each test case hits in that set of code execution logic data, and determine the ratio of the number of times the test case hits to the total number of logical nodes in that set of code execution logic data as the hit probability value of that test case in that set of code execution logic data.

[0057] Step 103: Determine the test cases corresponding to the hit probability values ​​that meet the preset selection conditions as the target test cases for the code execution logic data.

[0058] The preset selection criteria refer to predefined judgment standards used to select test cases. These criteria can be greater than a selection threshold or a preset number of cases. The test result indicates whether the execution result of the modified code block conforms to the expected logic of the code.

[0059] Specifically, the terminal can sort the hit probability values ​​of each test case corresponding to each group of code execution logic data, select a preset number of test cases, and determine the test cases of the preset number of data as the test cases corresponding to the hit probability values ​​that satisfy the preset selection conditions, as well as the target test cases for the code execution logic data. Optionally, the terminal can determine the hit probability values ​​corresponding to the hit probability values ​​that are greater than the selection threshold as the test cases corresponding to the hit probability values ​​that satisfy the preset selection conditions, as well as the target test cases for the code execution logic data. It should be understood that the preset number and selection threshold can be determined based on the actual application scenario, and are not specifically limited here.

[0060] In addition, the terminal can run the modified code block separately through each target test case to obtain the actual output results after the target test case executes the code. The actual output results are compared with the expected results to obtain the test results, which include whether the execution of the modified code block meets the expectations.

[0061] The aforementioned method for determining test cases analyzes the context log code data of the modified code block corresponding to the test object based on a static code parsing model and the function call relationship tree corresponding to the test object, thereby determining one or more sets of code execution logic data for the modified code block. This improves the accuracy of locating the code execution logic data of the modified code block in complex scenarios through static logs and function call relationships. For each set of code execution logic data, multiple test cases corresponding to each logical node in the code execution logic data are determined based on the test case and code association library. The hit probability value for selecting each test case in the code execution logic data is determined based on the number of times each test case hits the code execution logic data. This achieves automated screening of test cases, improving the efficiency and accuracy of test case screening, and identifying test cases with hit probability values ​​that meet preset selection conditions as target test cases for the code execution logic data. The modified code block is then tested based on the target test cases to obtain test results. This method selects effective test cases to test the modified code, improving the effectiveness of test cases. While ensuring test effectiveness, it accurately narrows the test scope, improves the testing efficiency of the modified code block, and further enhances the performance and reliability of the system where the test object is located.

[0062] In one exemplary embodiment, the method for determining test cases further includes:

[0063] The source code file is parsed based on a static code parsing model to determine the location data of each function and the call relationship between each function; based on the location data and call relationship, a function call relationship tree is generated.

[0064] The location data refers to the position of each function in the source code file. Optionally, the location data may include the file name, class name, line name, etc.

[0065] Specifically, the terminal can parse the source code file based on a static code parsing model, determine the location data of each function, identify the call relationships between all functions, establish directed call relationships between functions, and generate a function call tree based on the location data and the call relationships between functions. The function call tree includes the call relationships between each function, the caller, and the callee. Optionally, the static code parsing model can be a CallTree or constructed by writing a script to traverse and parse the source code file.

[0066] In this embodiment, a function call relationship tree is constructed to quickly find the upstream and downstream dependent functions of the modified code block, thereby improving the accuracy and efficiency of testing the modified code block.

[0067] In one exemplary embodiment, the method for determining test cases further includes:

[0068] Based on the log file parsing model, the dynamic log files generated by the execution source code files of each test case are parsed to determine the dynamic log data; based on the feature generation model, features are extracted from the dynamic log data to obtain the dynamic log features corresponding to each test case; based on each dynamic log feature, the static log feature library, and the function call relationship tree, the sample code execution logic data of each test case is determined; the correspondence between multiple test cases and the sample code execution logic data corresponding to each test case is determined as the test case and code association library.

[0069] The log file parsing model is a model for parsing the log files of test case executions to obtain dynamic log data. Dynamic log characteristics include the location characteristics of each function in the execution logic code of the test cases and the characteristics of the dynamic log content. Dynamic log data refers to the log data generated during the execution of the source code file in each test case. Log data represents the running status, fault location, and testing of the code file. Logs can include structured logs, unstructured logs, and can also include location data corresponding to the code.

[0070] Specifically, the terminal can obtain the log files generated by the source code files during the execution of each test case, and parse the log files based on the log file parsing model to obtain dynamic log data. The dynamic log data includes log content data and may also include location data. Optionally, whether the dynamic log data includes location data depends on the specific log management module in the test case. If the dynamic log data does not include location data, it can be obtained based on the steps in the subsequent embodiments, which will not be elaborated here.

[0071] The terminal can extract features from dynamic log data based on a feature generation model to obtain initial dynamic log features. Then, based on a redundancy removal strategy, redundant features are removed from the initial dynamic log features to obtain the dynamic log features corresponding to each test case. Optionally, the source code file includes a recursive function. During the loop of the recursive function, multiple duplicate log entries may occur; these duplicate log entries are removed based on the redundancy removal strategy.

[0072] The terminal can determine the code execution logic based on the location features and log features in the dynamic log features, and store the correspondence between each test case and the code execution logic corresponding to the dynamic log features in the database to form a test case and code association library.

[0073] In one instance, if the functions in the source code file do not include logging, the function call relationship is determined based on the function call relationship data. Based on the call relationship, the code execution logic of the test cases during the execution process is determined, and the correspondence between the test cases and the code execution logic is stored in the database.

[0074] In one example, the source code files are divided into two files (File1 and File2), defining three functions (FucA, FucB, and FucC) with no return value (Void). The execution chain starts from FucA. File1 contains the definitions of two functions (FucA() and FucB()), while File2 contains only one function (FucC()). The FucA() function first executes the `Printf("RunFucA…");` statement (outputting the string "RunFucA…" to the console), then calls the FucB() function, triggering its execution. The FucB() function is also a function with no return value. Its body uses ellipses (...) to indicate unwritten business logic code. Its core action is to call the FucC() function after executing its own logic, triggering its execution. The FucC() function only executes the `Printf("RunFucC…");` statement (outputting the string "RunFucC…" to the console) without any other calls or logic.

[0075] The specific control logic is as follows: When the program executes the FucA() function, the following chained call flow is triggered: FucA is executed, "RunFucA..." is output, and FucB is called; FucB is executed, its internal undefined logic is run, and FucC is called; FucC is executed, and "RunFucC..." is output; after FucC is completed, it returns to the call location of FucB, and FucB continues to complete the remaining logic (if any); after FucB is completed, it returns to the call location of FucA, FucA is completed, and the entire call chain ends.

[0076] In one example, the terminal can use a relational database to build a model, associating test cases with data in the database to create data samples. Furthermore, since the code covered by the test cases has temporal logical relationships, the relational database model to be trained is used with temporal data to obtain a trained relational database model. In the precise test case recommendation process, one or more sets of static log feature data parsed from the changed code blocks also have a temporal sequence. The corresponding target test cases are determined using the trained relational database model. For example, the relational database model to be trained can include one of the following: recurrent neural network, long short-term memory network, gated recurrent unit, and Transformer.

[0077] In this embodiment, by generating dynamic log features, a test case and code association library is constructed, which enables the association of each test case with the code execution logic, so as to determine the target test case when the code block is changed, thereby improving the testing efficiency of the changed code block.

[0078] In one exemplary embodiment, the method for determining test cases further includes:

[0079] In response to the fact that dynamic log features do not include location features, and based on a preset matching algorithm, the dynamic log content features are matched with each static log content feature in the static log feature library to obtain a first matching result. The target static log content feature corresponding to the first matching result that satisfies the first preset matching condition is determined, and the location feature corresponding to the target static log content feature is determined as the location feature corresponding to the dynamic log feature. In response to the fact that the dynamic log features of the test case do not meet the execution logic conditions, the code execution logic data of each test case is determined based on the function call relationship tree, each dynamic log content feature and the location feature corresponding to the dynamic log feature.

[0080] The preset matching algorithm is used to filter static log content features from the static log feature library that match the dynamic log content features. The static log feature library includes various static log content features and their corresponding location features. The first preset matching condition can be greater than a preset matching threshold. The preset matching algorithm can be a matching similarity algorithm such as a cosine similarity calculation algorithm.

[0081] Specifically, if the dynamic log features do not include location features, the terminal matches the dynamic log content features with each static log content feature in the static log feature library based on a preset matching algorithm to obtain a first matching result; it then determines the target static log content feature corresponding to the first matching result that satisfies the first preset matching condition, and identifies the location feature corresponding to the target static log content feature as the location feature corresponding to the dynamic log feature. Optionally, the terminal can calculate the similarity value between the dynamic log content feature and each static log content feature in the static log feature library. If the similarity value is greater than a preset matching threshold, it determines the target static log content feature corresponding to the first matching result that satisfies the first preset matching condition, and identifies the location feature corresponding to the target static log content feature as the location feature corresponding to the dynamic log feature. Optionally, when the log function satisfies the condition for obtaining location information, the terminal parses the log file based on a log file parsing model to obtain location data and log content data, and extracts features from the location data and the log content data respectively based on a feature generation model to obtain location features and log content features.

[0082] The terminal uses the log content and location features from the dynamic log characteristics of the test case to determine the call relationships between functions. It then identifies these relationships based on a function call tree, obtaining the identification result. If the identification result indicates an anomaly in the call relationship, meaning the logical execution conditions are not met, the terminal determines the actual calling functions for each dynamic log content feature and its corresponding location feature based on the function call tree. Finally, based on the actual calling functions, the dynamic log content features, and their corresponding location features, the terminal generates the code execution logic data for each test case. Optionally, if the logical execution conditions are met, the terminal determines the code execution logic data for that test case based on the dynamic log content features and their corresponding location features.

[0083] In one example, the terminal can parse the log code in the source code file using a static code parsing model to obtain static log data, and then extract static log features from the static log data using a feature generation model. These static log features are then stored in a database. If each function has multiple log printing lines, there will be multiple log feature vector data entries in the feature library.

[0084] Additionally, the terminal can perform cleaning processing on the initial log data. The initial log content data needs to be cleaned to remove noise / irrelevant data such as symbols and formatting characters. Log location data (the file, class, and function it belongs to) needs to be cleaned to remove noise / irrelevant data such as symbols and function parameters.

[0085] For example, if test case FucA is tested, FucB and FucC will inevitably be tested. Therefore, the log file will contain print data such as "RunFucA..." and "RunFucC...". This dynamic log data will generate dynamic log features "RunFucA" and "RunFucC". Based on the function call relationship tree, it can be determined that there is a function B between function A and function C. Based on the dynamic log features, the static log feature library, and the function call relationship tree, the code logic that will be executed when this test case runs (i.e., the dynamic code execution logic) can be calculated: File1 FucA RunFucA, File1 FucB, File2 FucC RunFucC.

[0086] In this embodiment, since the dynamic log features do not include location features, the corresponding location features are obtained based on the static log feature library. Furthermore, when the logical execution conditions are not met, the corresponding code execution logic data is generated based on the function call relationship tree. This improves the location of changed code blocks and enhances the accuracy of test case matching.

[0087] In one exemplary embodiment, such as Figure 2 As shown, the specific implementation process of step 101, "Based on the static code parsing model and the function call relationship tree corresponding to the test object, analyze the context log code data of the modified code block corresponding to the test object to determine one or more sets of code execution logic data of the modified code block," may include:

[0088] Step 201: Determine the static log code data of the code logic at the same level as the changed code block corresponding to the test object; based on the static code parsing model, parse the static log code data to determine the first static log feature.

[0089] The context log code data includes static log code data of the modified code block at the same level of code logic, as well as static log code data of each calling function and the called function.

[0090] Specifically, the terminal can obtain the context log file of the modified code block, and query the static log file of the same level of code logic as the modified code block based on a code logic level division strategy; and parse the static log file based on a static code parsing model to determine the static log code data of the same level as the modified code block, and extract features from the static log code data based on a feature generation model to obtain the first static log feature. Optionally, if no static log feature data of the same level of code execution logic is found, the location data of the modified code block is determined; if no static log code data of each calling function or called function is found, the location data of each calling function or called function is determined. Optionally, the code logic level division strategy can be to add a logic node identifier to the logic node at each level, and determine the corresponding logic level based on the logic node identifier.

[0091] Step 202: Based on the first static log characteristics and the function call relationship tree, determine the multiple sets of calling functions and called functions corresponding to the modified code block.

[0092] Step 203: For each group of calling and called functions, based on the static code parsing model, parse the static log code data of the calling and called functions, determine the second static log feature corresponding to the static log code data of the calling and called functions, and based on the second static log feature data, determine a set of code execution logic data of the modified code block.

[0093] Specifically, for each group of calling and called functions, the terminal can query the static log code files of the calling and called functions of the modified code block based on a code logic level segmentation strategy; and parse each static log code file based on a static code parsing model to determine the static log code data of the calling and called functions, and extract features from the static log code data based on a feature generation model to obtain a second static log feature. Based on the second static log feature of the calling function, the code execution sub-logic corresponding to the calling function is determined, and based on the second static log feature of the called function, the code execution sub-logic corresponding to the called function is determined. Based on the code execution sub-logic corresponding to the calling and called functions of this group, a set of code execution logic data is determined. Optionally, each group of calling and called functions forms a set of code execution logic data, i.e., at least one set of code execution logic data is obtained. Optionally, if no static log feature data of code execution logic data at the same level is found, the location data of the called or called function is determined. Optionally, the number of calling and called functions in each group does not exceed a preset number.

[0094] For example, the source code files are divided into two files (File1 and File2), which define a total of four functions with no return value (Void) (FucA1, FucA2, FucB, FucC). File1 contains the definitions of three functions: FucA1(), FucA2(), and FucB(boolbFlag); File2 contains a single function definition with a boolean parameter: FucC(boolbFlag). Scenario 1: Execute FucA1(); FucA1 executes, outputs "RunFucA1", executes its modified code, and calls FucB(true); FucB(true) executes, calls FucC(true); FucC(true) executes, enters the if branch, executes the modified code in FucC, and outputs "Run FucC success."; FucC returns to FucB after execution, FucB returns to FucA1 after execution, and the entire chain ends. Scenario 2, executing FucA2(): FucA2 executes, outputs "RunFucA2", and calls FucB(false); FucB(false) executes, runs its own undefined logic, and calls FucC(false); FucC(false) executes, enters the else branch, and outputs "Run FucC fail."; FucC returns to FucB after execution, FucB returns to FucA2 after execution, and the entire chain ends.

[0095] In this embodiment, by analyzing the context log code data of the modified code block corresponding to the test object based on the static code parsing model and the function call relationship tree corresponding to the test object, one or more sets of code execution logic data of the modified code block are determined. This can achieve a smaller code matching range than the function-level approach, thereby improving the matching accuracy and precision of the modified code.

[0096] In an exemplary embodiment, the specific implementation process of step 102, "determining multiple test cases corresponding to each logical node in the code execution logic data based on the test case and code association library," may include:

[0097] For each logical node in the code execution logic data, based on a preset matching algorithm, the second matching result of the logical node and test cases with each sample logical node in the code association database is calculated; the test cases corresponding to the sample logical nodes that satisfy the second preset matching conditions are determined as the test cases corresponding to the logical nodes.

[0098] The second matching result is the similarity data between static log features and dynamic log features.

[0099] Specifically, for each logical node in the code execution logic data, the terminal can calculate a second matching result for the logical node and each sample logical node in the code association database based on a preset matching algorithm. The test cases corresponding to the sample logical nodes that satisfy the second matching result and meet the second preset matching conditions are then identified as the test cases corresponding to the logical nodes. Optionally, the preset matching algorithm can be a cosine similarity calculation algorithm. For example, the terminal can calculate the similarity value between the logical node and each sample logical node in the code association database, and determine the similarity value as the second matching result. If the similarity value is greater than a similarity threshold, the test cases corresponding to the sample logical nodes that satisfy the second preset matching conditions are identified, and these test cases are identified as the test cases corresponding to the logical nodes.

[0100] In one example, in the example above, the code logic generated by static parsing of the modified code block is: FucA1 Run FucA1, FucB, FucC Run FucC fail.

[0101] The code execution logic for test case 1 is: FucA1 Run FucA1, FucB, FucC Run FucC succeed. The code execution logic for test case 2 is: FucA2 Run FucA2, FucB, FucC Run FucC fail. Based on the calculation method in this embodiment, the hit rate of test case 1 is 100%, and the hit rate of test case 2 is 0%. Therefore, the test case corresponding to this changed code is test case 1. It should be understood that this is only used as an example and does not constitute a specific limitation.

[0102] In this embodiment, by using a test case and code association library, multiple test cases corresponding to each logical node in the code execution logic data are determined, and the number of hits of each logical node in the test cases is calculated, thereby calculating the hit rate of each test case in the code execution logic, which further improves the accuracy of code selection.

[0103] In one exemplary embodiment, such as Figure 3 As shown, the method for determining test cases specifically includes the following steps:

[0104] The terminal generates a static log feature library and function call relationship tree: First, the entire source code is parsed using a static code parsing model to generate a function call relationship tree and to parse out all log data in the code file. Then, static log features are output using a feature generation model, and finally, a static log feature library is formed.

[0105] The statically extracted log data is first cleaned and then converted into feature vectors. The log content data needs to be cleaned to remove noise / irrelevant data such as symbols and format characters. The log location data (the file, class, and function) needs to be cleaned to remove noise / irrelevant data such as symbols and function parameters, and the effective features are extracted.

[0106] The generated static log features are converted into static log feature vectors and stored in the database. If a function has multiple log printing lines, then multiple log feature vector data will be stored in the feature library.

[0107] Generate the association between test cases and code: Running test cases, the generated log files are parsed to extract dynamic log data, and then the dynamic log features are output through the "feature generation model." Each test case generates a set of dynamic log feature data, which needs further cleaning to remove redundant data. If the dynamic log features lack location features, the "static log feature library" is used to obtain location features based on log content features. Since some functions do not print logs, the "function call relationship tree" is used to further complete the dynamic execution logic of the code during test case execution, thereby generating a test case and code association library.

[0108] Dynamic log data may contain code location information (file, class, and function). The specifics depend on whether the log management module includes this functionality and the log format. If recursive functions or for / while loops print logs, it's redundant and needs deduplication; otherwise, it will affect the accurate location of test cases. Dynamic log characteristics are not entirely the same as static log characteristics; similarity can be matched using algorithms such as cosine similarity.

[0109] Precise test case recommendations: In a CI / CD pipeline, precise testing can be used at various stages, including code commits and version releases. Code commits focus on precise testing of the scope of changes made in the current code release, while version releases can focus on precise testing of the scope of changes compared to the previous version.

[0110] Based on the static parsing of the modified code, one or more sets of code execution logic are generated: The "static code parsing model" analyzes the context of the modified code block, querying log data within the same level of code logic; if no log data is found, only the location data of the modified code block is parsed. Combined with the function call tree, the caller of the modified function can be obtained, and the context of the modified function within the caller function is analyzed, similarly querying log data within the same level of code logic; if no log data is found, only the location data of the caller function is parsed. Ultimately, the caller's code execution logic is formed. The "static code parsing model" analyzes the context of the modified code block, querying the called function within the same level of code logic, and then continues searching for log data in the first level of code logic within the called function; if no log data is found, only the location data of the called function is parsed. Ultimately, the callee's code execution logic is formed; the number of iterations can be limited (e.g., a maximum of 5 levels of parsing for both caller and callee). Since there may be multiple callers and callees, one or more sets of code execution logic can be output.

[0111] Based on one or more sets of code execution logic output, and combined with a test case and code association library, the optimal set of test cases is recommended.

[0112] Each code execution logic group contains multiple logical nodes (i.e., location features and log features). First, for the logical node corresponding to the changed function, test cases are matched in the "test case and code association library". Matching can be done through algorithms such as cosine similarity. If a match is found, test cases are matched for other logical nodes.

[0113] Each logical node may hit 0 to n test cases, and the cumulative hit rate of the test cases is calculated. The hit rate of each test case in each group of code logic is calculated as follows: Hit rate of test cases = Number of test cases hit / Total number of logical nodes;

[0114] The test cases are sorted from highest to lowest based on their hit rate within each group. A threshold is used to control the number of recommended test cases in each group. Finally, all recommended test cases from all groups are merged and deduplicated.

[0115] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0116] Based on the same inventive concept, this application also provides a test case determination apparatus for implementing the test case determination method described above. This apparatus can be applied to or integrated into a chip or chip module, for example. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more test case determination apparatus embodiments provided below can be found in the limitations of the test case determination method described above, and will not be repeated here.

[0117] In one exemplary embodiment, such as Figure 4 As shown, a test case determination device 40 is provided, comprising: a first determination module 41, a second determination module 42, and a test module 43, wherein:

[0118] The first determining module 41 is used to analyze the context log code data of the changed code block corresponding to the test object based on the static code parsing model and the function call relationship tree corresponding to the test object, and determine one or more sets of code execution logic data of the changed code block;

[0119] The second determining module 42 is used to determine, for each group of code execution logic data, multiple test cases corresponding to each logic node in the code execution logic data based on the test case and code association library; and to determine the hit probability value of selecting each test case in the code execution logic data based on the number of times each test case is hit in the code execution logic data.

[0120] Test module 43 is used to determine the test cases corresponding to the hit probability values ​​that meet the preset selection conditions as the target test cases of the code execution logic.

[0121] In one embodiment, the first determining module 41 is further configured to parse the source code file based on the static code parsing model, determine the location data of each function, and determine the calling relationship between each function; and generate the function call relationship tree based on the location data and the calling relationship.

[0122] In one embodiment, the first determining module 41 is further configured to parse the dynamic log files generated by each test case when executing the source code file based on the log file parsing model, and determine the dynamic log data;

[0123] Based on the feature generation model, feature extraction is performed on the dynamic log data to obtain the dynamic log features corresponding to each test case.

[0124] Based on the dynamic log features, static log feature library and function call relationship tree, the sample code execution logic data for each test case is determined;

[0125] The correspondence between multiple test cases and the sample code execution logic data corresponding to each test case is determined as the test case and code association library.

[0126] In one embodiment, the first determining module 41 is further configured to, in response to the dynamic log feature not including the location feature, match the dynamic log content feature with each static log content feature in the static log feature library based on a preset matching algorithm to obtain a first matching result, determine the target static log content feature corresponding to the first matching result that satisfies the first preset matching condition, and determine the location feature corresponding to the target static log content feature as the location feature corresponding to the dynamic log feature.

[0127] In response to the fact that the dynamic log features of the test cases do not meet the execution logic conditions, the code execution logic data of each test case is determined based on the function call relationship tree, the dynamic log content features, and the position features corresponding to the dynamic log features.

[0128] In one embodiment, the first determining module 41 is used to determine the static log code data of the same level of code logic as the changed code block corresponding to the test object; based on the static code parsing model, the static log code data is parsed to determine the first static log feature;

[0129] Based on the first static log features and the function call relationship tree, determine the multiple sets of calling functions and called functions corresponding to the modified code block;

[0130] For each group of calling functions and called functions, based on the static code parsing model, the static log code data of the calling functions and called functions is parsed to determine the second static log feature corresponding to the static log code data of the calling functions and called functions. Based on the second static log feature data, a set of code execution logic data of the modified code block is determined.

[0131] In one embodiment, the second determining module 42 is used to calculate, based on a preset matching algorithm, a second matching result for each logical node in the code execution logic data, the logical node and each sample logical node in the test case and code association relationship library; and to determine the test cases corresponding to the sample logical nodes that satisfy the second preset matching conditions as the test cases corresponding to the logical nodes.

[0132] Regarding the modules / units included in the various devices and products described in the above embodiments, they can be software modules / units, hardware modules / units, or a combination of both. For example, for various devices and products applied to or integrated into a chip, all of their modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits; for various devices and products applied to or integrated into a chip module, all of their modules / units can be implemented using hardware methods such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The components can be implemented using software programs that run on the processor integrated within the chip module. The remaining (if any) modules / units can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into the terminal, each of its components / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or in different components within the terminal. Alternatively, at least some modules / units can be implemented using software programs that run on the processor integrated within the terminal, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits.

[0133] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 5As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a method for determining test cases. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0134] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0135] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0136] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0137] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0138] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0139] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0140] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0141] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for determining test cases, characterized in that, The method includes: Based on the static code parsing model and the function call relationship tree corresponding to the test object, the context log code data of the modified code block corresponding to the test object is analyzed to determine one or more sets of code execution logic data of the modified code block; For each set of code execution logic data, based on the test case and code association library, multiple test cases corresponding to each logical node in the code execution logic data are determined; based on the number of times each test case is hit in the code execution logic data, the hit probability value of selecting each test case in the code execution logic data is determined; The test cases corresponding to the hit probability values ​​that meet the preset selection conditions are determined as the target test cases for the code execution logic.

2. The method according to claim 1, characterized in that, The method further includes: The source code file is parsed based on the static code parsing model to determine the location data of each function and the calling relationship between each function; based on the location data and the calling relationship, the function call relationship tree is generated.

3. The method according to claim 2, characterized in that, The method further includes: Based on the log file parsing model, the dynamic log files generated by each test case when executing the source code file are parsed to determine the dynamic log data; Based on the feature generation model, feature extraction is performed on the dynamic log data to obtain the dynamic log features corresponding to each test case. Based on the dynamic log features, static log feature library and function call relationship tree, the sample code execution logic data for each test case is determined; The correspondence between multiple test cases and the sample code execution logic data corresponding to each test case is determined as the test case and code association library.

4. The method according to claim 3, characterized in that, The dynamic log features include the location features of each logical node in the execution logic code of the test case and the dynamic log content features. The step of determining the code execution logic data for each test case based on the dynamic log features, the static log feature library, and the function call relationship tree includes: In response to the fact that the dynamic log feature does not include the location feature, based on a preset matching algorithm, the dynamic log content feature is matched with each static log content feature in the static log feature library to obtain a first matching result. The target static log content feature corresponding to the first matching result that satisfies the first preset matching condition is determined, and the location feature corresponding to the target static log content feature is determined as the location feature corresponding to the dynamic log feature. In response to the fact that the dynamic log features of the test cases do not meet the execution logic conditions, the code execution logic data of each test case is determined based on the function call relationship tree, the dynamic log content features, and the position features corresponding to the dynamic log features.

5. The method according to claim 4, characterized in that, The method involves analyzing the context log data of the modified code block corresponding to the test object based on the static code parsing model and the function call relationship tree of the test object, to determine one or more sets of code execution logic data for the modified code block, including: Identify the static log code data of the code logic at the same level as the changed code block corresponding to the test object; based on the static code parsing model, parse the static log code data to determine the first static log feature; Based on the first static log features and the function call relationship tree, determine the multiple sets of calling functions and called functions corresponding to the modified code block; For each group of calling functions and called functions, based on the static code parsing model, the static log code data of the calling functions and called functions is parsed to determine the second static log feature corresponding to the static log code data of the calling functions and called functions. Based on the second static log feature data, a set of code execution logic data of the modified code block is determined.

6. The method according to claim 5, characterized in that, The method of determining multiple test cases corresponding to each logical node in the code execution logic data based on the test case and code association library includes: For each logical node in the code execution logic data, based on a preset matching algorithm, a second matching result is calculated between the logical node and each sample logical node in the test case and code association relationship library; the test cases corresponding to the sample logical nodes that satisfy the second preset matching conditions are determined as the test cases corresponding to the logical node.

7. A device for determining test cases, characterized in that, The device includes: The first determining module is used to analyze the context log code data of the modified code block corresponding to the test object based on the static code parsing model and the function call relationship tree corresponding to the test object, and determine one or more sets of code execution logic data of the modified code block; The second determining module is used to determine, for each set of code execution logic data, multiple test cases corresponding to each logical node in the code execution logic data based on the test case and code association library; and to determine the hit probability value of selecting each test case in the code execution logic data based on the number of times each test case is hit in the code execution logic data. The testing module is used to determine the test cases corresponding to the hit probability values ​​that meet the preset selection conditions as the target test cases for the code execution logic.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

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

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images