Method and device for generating test cases

Abstract

The present invention relates to the technical field of software development and software testing, and discloses a method and device for generating test cases, the method comprising: obtaining a parameter list of each interface function of a tested library and a dependency relationship between each interface function; wherein the dependency relationship between each interface function comprises: a sequence relationship and a nested relationship; generating an abstract signature list according to the parameter list of each interface function; wherein the abstract signature comprises: a callback parameter in the parameter list of the interface function and a property corresponding to the callback parameter; and generating a target test case according to the abstract signature and the dependency relationship between each interface function.

Description

Technical Field

[0001] The present invention relates to the technical field of software development and software testing, and in particular to a method and device for generating test cases. Background Art

[0002] In modern software development, asynchronous APIs (Asynchronous Application Programming Interface) are increasingly used. They allow applications to continue to perform other tasks while waiting for operations to complete, thereby improving overall performance and user experience. However, testing asynchronous APIs is more complex than synchronous APIs, especially in determining which API functions expect synchronous callbacks and the location of the parameters that the callbacks should pass.

[0003] Currently, runtime monitoring techniques infer function signatures by capturing function calls and return values ​​at runtime. However, this technique requires adding additional monitoring code to the application, which may affect performance and may not capture all possible function calls. Summary of the invention

[0004] In view of this, the present invention provides a method and device for generating a test case.

[0005] In a first aspect, the present invention provides a method for generating test cases, the method comprising: obtaining a parameter list of each interface function of a tested library and a dependency relationship between each interface function; wherein the dependency relationship between each interface function comprises: a sequence relationship and a nested relationship; generating an abstract signature list according to the parameter list of each interface function; wherein the abstract signature comprises: callback parameters in the parameter list of the interface function and properties corresponding to the callback parameters; generating a target test case according to the abstract signature and the dependency relationship between each interface function.

[0006] The method for generating test cases provided in this embodiment can more comprehensively understand the structure and function of the library by obtaining the parameter list and dependency relationship of the interface function, without adding additional monitoring code to the application, so in theory it has little impact on the performance of the application.

[0007] In addition, by generating a list of abstract signatures, especially focusing on callback parameters and their properties, this method can identify the key interaction points between interface functions, thereby accurately locating the focus of the test and ensuring that key functions and interactions are fully tested.

[0008] In addition, when generating the abstract signature list, special attention is paid to callback parameters and their properties, and asynchronous calls and event processing logic are accurately identified and tested to ensure that these complex behaviors can be correctly executed in different scenarios. In addition, precise analysis of dependencies can reveal potential dependency issues, such as circular dependencies or unresolved dependencies, which may cause errors or performance issues in actual operation.

[0009] In a possible implementation, a target test case is generated according to the dependency relationship between the abstract signature and each interface function, including: iteratively expanding the test case tree starting from the root node, randomly selecting an interface function from the function signature pool at the extension point of each callback node to call, and obtaining a function call node; wherein the function signature pool maps the parameter type, the number of parameters and the interface function in the abstract signature list; filling the function call node with the target abstract signature corresponding to the selected interface function; for each parameter in the function call node, generating the parameter value corresponding to each parameter according to the target abstract signature; generating the corresponding nested call structure of each interface function according to the parameter value, the parameter type and the dependency relationship between the various interface functions; and traversing the test case tree according to the nested call structure to generate the target test case.

[0010] The method for generating test cases provided in this embodiment can ensure that all interface functions and the dependencies between them are fully considered and tested by iteratively expanding the test case tree, so that possible execution paths and dependency scenarios can be automatically explored, thereby improving the test coverage.

[0011] In addition, the function signature pool maps the parameter type, number of parameters, and interface function in the abstract signature list, which enables quick matching of the appropriate function signature when selecting an interface function. Generating parameter values ​​based on the target abstract signature ensures that the parameters in the test case match the expected input of the interface function, thereby improving the accuracy of the test.

[0012] In addition, by traversing the test case tree, the nested call relationship can be clearly displayed, thus ensuring the comprehensiveness and accuracy of the test.

[0013] In one possible implementation, determining the target abstract signature includes: randomly selecting an interface function from a function signature pool, and determining the number of abstract signatures corresponding to the interface function; if the number of abstract signatures corresponding to the interface function is multiple, randomly selecting a target abstract signature from the multiple abstract signatures.

[0014] The method for generating test cases provided by this embodiment randomly selects interface functions and abstract signatures to ensure that each generated test case is unique, thereby increasing the randomness and diversity of the test. This helps to discover errors or abnormal behaviors that only occur under specific conditions, and improves the coverage and quality of the test. In addition, when the interface function corresponds to multiple abstract signatures, random selection can ensure that the test case can cover different parameter combinations and call scenarios.

[0015] In a possible implementation, the function signature pool also includes: an internal callback function; wherein, according to the nested call structure, the test case tree is traversed to generate a target test case, including: using the CodeQL tool to mine and identify a nested example set corresponding to the nested call structure between interface function calls; wherein the nested examples are used to characterize parameter passing information between external functions and internal callback functions; randomly selecting an internal callback function from the function signature pool, and calling the internal callback function and the parameters corresponding to the internal callback function in the callback of the external function to construct a target test case.

[0016] The method for generating test cases provided in this embodiment, by introducing internal callback functions, the test cases can simulate the complex scenarios in the actual software operation more deeply. This method not only tests the direct call of the interface function, but also tests the nested call relationship between them, thereby improving the breadth and depth of the test. By randomly selecting internal callback functions and calling them in the callback of the external function, the test case can simulate complex callback logic to discover potential problems. By utilizing the existing API usage, a test case with a nested relationship is generated, thereby more comprehensively testing the functions and interactions of the API.

[0017] In a second aspect, the present invention provides a device for generating test cases, the device comprising: an acquisition module, used to obtain a parameter list of each interface function of a tested library and a dependency relationship between each interface function; wherein the dependency relationship between each interface function comprises: a sequence relationship and a nested relationship; a first generation module, used to generate an abstract signature list according to the parameter list of each interface function; wherein the abstract signature comprises: callback parameters in the parameter list of the interface function and properties corresponding to the callback parameters; a second generation module, used to generate a target test case according to the abstract signature and the dependency relationship between each interface function.

[0018] In one possible implementation, the second generation module includes: a calling unit, which is used to iteratively expand the test case tree starting from the root node, and at the extension point of each callback node, randomly select an interface function from the function signature pool for calling to obtain a function call node; wherein the function signature pool maps the parameter type, number of parameters and interface function in the abstract signature list; a filling unit, which is used to fill the target abstract signature corresponding to the selected interface function into the function call node; a first generation unit, which is used to generate a parameter value corresponding to each parameter in the function call node according to the target abstract signature; a second generation unit, which is used to generate a corresponding nested call structure for each interface function according to the parameter value, parameter type, and the dependency relationship between each interface function; a third generation unit, which is used to traverse the test case tree according to the nested call structure to generate a target test case.

[0019] In one possible implementation, the device also includes: a first selection module, used to randomly select an interface function from a function signature pool and determine the number of abstract signatures corresponding to the interface function; a second selection module, used to randomly select a target abstract signature from multiple abstract signatures if the number of abstract signatures corresponding to the interface function is multiple.

[0020] In a third aspect, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the method for generating test cases according to the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0021] In a fourth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the method for generating test cases according to the first aspect or any corresponding embodiment thereof.

[0022] In a fifth aspect, the present invention provides a computer program product, comprising computer instructions for causing a computer to execute the method for generating test cases according to the first aspect or any corresponding embodiment thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0024] Figure 1is a flow chart of a method for generating a test case according to an embodiment of the present invention;

[0025] Figure 2 is a structural block diagram of a device for generating test cases according to an embodiment of the present invention;

[0026] Figure 3 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0027] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0028] Based on relevant technologies, asynchronous APIs (Asynchronous Application Programming Interface) are increasingly used in modern software development. They allow applications to continue to perform other tasks while waiting for operations to complete, thereby improving overall performance and user experience. However, testing asynchronous APIs is more complex than synchronous APIs, especially in determining which API functions expect synchronous callbacks and the location of the parameters that the callbacks should pass.

[0029] Currently, runtime monitoring techniques infer function signatures by capturing function calls and return values ​​at runtime. However, this technique requires adding additional monitoring code to the application, which may affect performance and may not capture all possible function calls.

[0030] Based on this, the present invention provides a method for generating test cases. By obtaining the parameter list and dependency relationship of the interface function, the structure and function of the library can be more comprehensively understood without adding additional monitoring code in the application. Therefore, in theory, the performance of the application is less affected.

[0031] In addition, by generating a list of abstract signatures, especially focusing on callback parameters and their properties, this method can identify the key interaction points between interface functions, thereby accurately locating the focus of the test and ensuring that key functions and interactions are fully tested.

[0032] In addition, when generating the abstract signature list, special attention is paid to callback parameters and their properties, and asynchronous calls and event processing logic are accurately identified and tested to ensure that these complex behaviors can be correctly executed in different scenarios. In addition, precise analysis of dependencies can reveal potential dependency issues, such as circular dependencies or unresolved dependencies, which may cause errors or performance issues in actual operation.

[0033] According to an embodiment of the present invention, a method embodiment for generating test cases is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0034] In this embodiment, a method for generating a test case is provided, which can be used in computer devices, such as computers, servers, etc. Figure 1 is a flow chart of a method for generating a test case according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0035] Step S101, obtaining a parameter list of each interface function of the tested library and a dependency relationship between each interface function; wherein the dependency relationship between each interface function includes: a sequence relationship and a nested relationship.

[0036] The library under test can be used to represent the software library or module under test, which contains multiple interface functions. The interface function is used to represent the functions or methods provided by the library for other codes to call. The parameter list can be used to represent the set of input parameters received by the interface function. The dependency relationship between each interface function can be used to represent the call or association relationship between interface functions, including sequence relationship and nested relationship; among them, the sequence relationship is used to represent the order of function calls; the nested relationship is used to represent the relationship of calling another function inside a function, especially the use of callback functions.

[0037] Specifically, the step of obtaining the parameter list of the interface function can be to consult the official documentation or API reference manual of the library being tested. These documents usually list all interface functions and their parameters. Pay attention to the type, name, default value (if any), and meaning of the parameter. If there is no detailed documentation, you can use static code analysis tools to parse the source code. These tools can identify function definitions and extract parameter lists. You need to ensure that the tool supports the programming language used by the library being tested.

[0038] Understand the calling relationships between functions by reading the source code. Identify which functions are preconditions and which functions are postconditions. Use a debugger or logging tool to track the order of function calls at runtime.

[0039] Nested relationships refer to the situation where one interface function calls another interface function. Use static code analysis tools to identify function calls within functions. Pay special attention to function pointers or delegates that are passed as parameters. Analyze the callback mechanism in the tested library. Determine which functions are called as callbacks, their triggering conditions, and when to call them. At runtime, set breakpoints to observe the calls to callback functions. Verify that the parameters and return values ​​of the callback function meet expectations.

[0040] As an example, you need to pick an efficient automated scanning tool. The automated scanning tool can parse the source code or binary file and identify all API functions. The automated scanning tool will deeply analyze the source code or binary file to extract the structure and parameter information of the API function. When identifying the parameters of the API function, pay special attention to those function pointers or delegates that may be used as callbacks. By checking the type and naming convention of the parameters, you can further confirm which parameters are callback parameters. In some cases, this may require combining context or documentation information. For example: a graphics library that contains multiple API functions, one of which is draw_image, which accepts an image data and a callback parameter on_draw_complete. During the automated API detection process, the system will recognize that on_draw_complete is a callback parameter and mark it as an asynchronous callback in the abstract signature.

[0041] Step S102, generating an abstract signature list according to the parameter list of each interface function; wherein the abstract signature includes: callback parameters in the parameter list of the interface function and properties corresponding to the callback parameters.

[0042] The abstract signature is used to represent the abstract representation of the interface function parameter list. Specifically, it may include the callback parameters in the interface function parameter list and the properties corresponding to the callback parameters. Among them, the properties corresponding to the callback parameters may include: whether the parameter is a callback for a synchronous call, a callback for an asynchronous call, or a non-callback value.

[0043] Specifically, parse the definition of the interface function from the source code or API documentation, including the function name, parameter list, and return type. Identify which parameters in the parameter list are callback functions. This can be determined by the type of parameter (such as function pointer, delegate) and naming convention. Determine the type of the callback function (synchronous, asynchronous, etc.) based on its definition and usage context. Analyze the conditions that trigger the callback, and record the callback parameters and return value. Determine the execution context of the callback function. Build an abstract signature for each interface function, including the function name, parameter list (especially marking the callback parameters and their properties), return type, and any additional property information (such as thread safety, exception handling, etc.).

[0044] In a possible implementation, the generated abstract signature may be stored in a database, and an index may be created for easy retrieval.

[0045] Step S103, generating a target test case according to the abstract signature and the dependency relationship between each interface function.

[0046] According to the software requirements specification and functional points, determine the target interface functions and related dependencies that need to be tested. Identify the critical paths and potential risk points as the focus of the test cases. For each interface function, design basic functional test cases to verify its correctness. Include normal input, boundary input and abnormal input. According to the dependencies, design test cases to verify the calling order and nesting relationship between functions. Ensure that the preconditions are correctly met and the post-processing is correctly executed. Design test cases to verify the behavior of the callback parameters marked in the abstract signature. Include synchronous callbacks, asynchronous callbacks and event-driven callbacks. Verify the triggering conditions, parameter passing and return values ​​of the callback function. Combine multiple interface functions for testing to verify the interaction and collaboration between them.

[0047] Use professional test management tools (such as TestRail, Jira, etc.) to write test cases. Each test case should include key information such as test title, test steps, expected results, and actual results.

[0048] As an example, test cases for sequential and nested API calls are generated through a test case tree, that is, test cases containing sequential and nested API calls can be generated according to the test case tree. Such test cases can be used to test the functionality and performance of the API.

[0049] The test case tree is a tree structure used to represent the generated test cases. The test case tree is defined based on two mappings. The first is the mapping of variable names to non-callback values, called the value pool (V). The second is the mapping of function names to abstract signatures, called the function signature pool (S). A test case tree is an ordered tree structure in which the nodes can be one of the following types: Function call node (CC): represents a function call, including function name, parameter list and callback type. Value node (VV): represents a non-callback value, which can be a variable or a constant. Condition node (II): represents a conditional statement used to control the execution flow of the test case. The root node of the test case tree is a special callback node, which represents the function contained in the entire test case.

[0050] Test cases are created iteratively, extending the test by inserting new call nodes into the existing test case. Each callback node in the test case tree has an extension point that can add another child node in the rightmost position. For callback nodes that have no children, there is a special extension point for adding the first child node. Select the parameters to be passed to the function. Once the function to be tested is selected, the parameters need to be generated. This is done by consulting the list of signatures generated during the discovery phase. If the function has multiple signatures, a signature is randomly selected. The signature indicates the number of parameters that the generated test should pass to the function, and which parameters (if any) are callback parameters. If the function has no signature, a random number of parameters (between 0 and 5) is selected and randomly generated parameter values ​​are used to fill these positions. It is important to note that in this case, no callback parameters are generated. For non-callback parameters, the parameter type is randomly selected from JavaScript primitive types (such as numbers, strings, and booleans), arrays, functions, etc. If the selected type is a primitive value, object, or array, a randomly generated value is used. If the selected type is a function, an available function is selected from the API being tested or the runtime environment (such as console.log). If the selected type is something else, a variable available in the current scope is chosen, which includes values ​​passed through nested API calls. This helps generate well-formed parameters, as values ​​(including objects) can be passed from outer calls to inner calls. Also, since we deal with many file system-related libraries, string raw values ​​are randomly selected from a pre-generated list of valid file names that correspond to the hierarchy of directories and files generated during testing. Then, leveraging existing API usage, test cases are generated with nested relationships, allowing for more comprehensive testing of API functionality and interactions.

[0051] The method for generating test cases provided in this embodiment can more comprehensively understand the structure and function of the library by obtaining the parameter list and dependency relationship of the interface function, without adding additional monitoring code in the application, so in theory, it has little impact on the performance of the application. In addition, by generating an abstract signature list, especially paying attention to the callback parameters and their properties, the method can identify the key interaction points between the interface functions, thereby accurately locating the focus of the test and ensuring that key functions and interactions are fully tested. In addition, when generating the abstract signature list, special attention is paid to the callback parameters and their properties, accurately identifying and testing asynchronous calls and event processing logic, and ensuring that these complex behaviors can be correctly executed in different scenarios. In addition, accurate analysis of dependencies can reveal potential dependency problems, such as circular dependencies or unresolved dependencies, which may cause errors or performance problems in actual operation.

[0052] In a possible implementation, the above step S103 includes:

[0053] Step a1, iteratively expand the test case tree starting from the root node, and at the extension point of each callback node, randomly select an interface function from the function signature pool to call, and obtain a function call node; wherein the function signature pool maps the parameter type, number of parameters and interface function in the abstract signature list.

[0054] The test case tree is used to characterize the hierarchical relationship and dependency relationship of test cases. Each node represents a test step or function call. The callback node is used to characterize the node in the test case tree that needs to call the callback function. These nodes are the key points for the expansion of the test case tree. The function signature pool is used to characterize a set of all interface function signatures. Each signature includes information such as the name, parameter type, number of parameters, and return type of the interface function. Specifically, starting from the root node of the test case tree, according to the extension point of the callback node, an interface function is randomly selected from the function signature pool for calling, and a new function call node is created as a child node of the current node. Specifically, the test case tree can be traversed using a recursive or iterative method. When a callback node is encountered, an interface function is randomly selected from the function signature pool and a corresponding function call node is created.

[0055] As an example, each callback node in the test case tree has an extension point to add another child node in the rightmost position. For callback nodes that have no children, there is a special extension point for adding the first child node.

[0056] As an example, start from the root node of the test case tree. The root node usually represents the starting point of a test scenario or test case. Traverse the test case tree and check whether each node is a callback node.

[0057] When a callback node is encountered, perform the following operations: Randomly select an interface function from the function signature pool. This selection process can be based on some random algorithm or strategy to ensure that a different combination of interface functions is obtained each time the test is performed. Create a new function call node as a child of the current callback node. This new node represents a call to the selected interface function. For the newly created function call node, relevant information needs to be filled in, including: The name of the interface function: obtained from the function signature pool. Parameter type and number: also obtained from the function signature pool and corresponding to the selected interface function. Possible return value types (although this step may not be directly used when generating test cases, it helps to understand the expected behavior of the interface function). If the newly created function call node itself contains a callback node (that is, the interface function it calls may also contain a callback), repeat the above expansion process for this node. Otherwise, continue to traverse the test case tree until all callback nodes have been expanded.

[0058] Step a2, fill the target abstract signature corresponding to the selected interface function into the function call node.

[0059] The target abstract signature (including parameter type, parameter quantity and interface function name) corresponding to the interface function selected in step a1 is filled into the newly created function call node. Specifically, when creating a function call node, the relevant information of the target abstract signature is stored as a node attribute.

[0060] Step a3: for each parameter in the function call node, generate a parameter value corresponding to each parameter according to the target abstract signature.

[0061] Get the target abstract signature of the selected interface function. This signature contains the function name, parameter list (including parameter type, number of parameters and parameter name) and return type. Traverse the parameter list to understand the type and constraints of each parameter (such as whether it is required, whether it has a default value, whether it has a specific value range, etc.). For each parameter, generate a parameter value that meets the requirements according to its type.

[0062] If the parameter type is a basic type (such as an integer, floating point number, string, Boolean value, etc.): a random value can be generated or a preset value can be used according to the parameter's value range or constraints.

[0063] Complex types (such as objects, structures, arrays, etc.): You may need to use specific generation strategies or tools to generate parameter values ​​that meet the requirements. For example, for object types, you can generate an object instance containing the necessary properties; for array types, you can generate an array containing a specified number of elements.

[0064] If a parameter has default or optional values, consider using those when generating the parameter value as well. In some cases, the value of a parameter may depend on the values ​​of other parameters or the context of the test case. For example, a function's parameter may need to be calculated or transformed based on the value of another parameter. In this case, you need to consider these dependencies and contextual information when generating the parameter value.

[0065] After generating parameter values, it is best to verify that they meet the requirements and constraints of the target abstract signature. This can be achieved through simple type checking, value range verification, or dependency checking. Store the generated parameter values ​​in the corresponding attributes of the function call node. In this way, when executing the test case, you can easily obtain these parameter values ​​and pass them to the interface function.

[0066] Step a4, generating a corresponding nested call structure for each interface function according to parameter values, parameter types, and dependencies between each interface function.

[0067] The nested call structure is used to characterize the calling relationship between interface functions, including the order and nesting level of function calls.

[0068] Clarify the dependencies between various interface functions. This can be obtained through interface documents, business logic or code analysis. Dependencies can include direct function call relationships, parameter passing relationships and callback mechanisms. According to the dependencies, determine the calling order of each interface function. The determination of the calling order needs to take into account the execution premise of the function, that is, some functions may need to be called after other functions have been executed and returned specific results. According to the calling order, start to build a nested call structure. This structure can be a tree structure, in which each node represents the call of an interface function. For each function node, its name, parameter list (including parameter value and parameter type) and possible return value type need to be recorded. If a function needs to call other functions (that is, there are nested calls), create child nodes under its node to represent these called functions. When building a nested structure, special attention should be paid to the processing of parameter passing. In particular, when the return value of a function is used as a parameter of another function, it is necessary to ensure that this passing relationship is correctly reflected in the nested structure. Variables or placeholders can be used to represent parameter values ​​and replaced when executing test cases. If there is a callback mechanism, it needs to be clearly marked in the nested structure. This is usually expressed by creating special callback nodes or using specific syntax. The handling of callback nodes needs to take into account the issues of asynchronous execution and result delivery, ensuring that the test case can correctly simulate the callback process. After building the nested call structure, it needs to be verified to ensure its correctness and completeness. This can be achieved by comparing it with the interface documentation or business logic. If any problems or omissions are found, the structure needs to be adjusted and optimized.

[0069] Step a5: traverse the test case tree according to the nested call structure to generate the target test case.

[0070] Ensure that the root node of the test case tree has been created and is ready to receive nested function calls. Start at the top level of the nested call structure and traverse downward layer by layer. Each node represents a call to an interface function. For each function node in the nested call structure, create a corresponding test case node in the test case tree. These nodes should contain the name of the function, the expected parameter values ​​(including parameters passed from other function return values), the parameter types, and the possible return value types. If a function node contains child nodes (i.e., nested calls), create child nodes under the test case node to represent these called functions. Ensure that the nested relationship is correctly reflected in the test case tree, that is, the child nodes should exist as children of the parent node. According to the dependencies in the nested call structure, set the dependencies and preconditions between test cases. Add assertions and verification points in the test case nodes to check whether the return value of the interface function meets expectations. These assertions and verification points should be set based on the interface documentation, business logic, or expected test scenarios. After the traversal is completed, generate specific test cases based on the test case tree.

[0071] The method for generating test cases provided by the present embodiment can ensure that all interface functions and the dependencies between them are fully considered and tested by iteratively expanding the test case tree, so that possible execution paths and dependency scenarios can be automatically explored, thereby improving the coverage of the test. In addition, the function signature pool maps the parameter type, number of parameters and interface function in the abstract signature list, which enables the rapid matching of the appropriate function signature when selecting the interface function. By generating parameter values ​​according to the target abstract signature, it can be ensured that the parameters in the test case match the expected input of the interface function, thereby improving the accuracy of the test. In addition, by traversing the test case tree, the nested call relationship can be clearly displayed, thereby ensuring the comprehensiveness and accuracy of the test.

[0072] In a possible implementation, the method further includes:

[0073] Step b1, randomly select an interface function from the function signature pool, and determine the number of abstract signatures corresponding to the interface function.

[0074] A random number generator can be used to randomly select an interface function from the function signature pool. This selection should be uniform, that is, the probability of each interface function being selected should be equal. For the selected interface function, find the number of its corresponding abstract signatures. An interface function may have multiple overloaded versions or variants, each with its own abstract signature (i.e., parameter list and return type). If the interface function has only one abstract signature, use that signature directly as the target abstract signature. If the interface function has multiple abstract signatures, proceed to step b2.

[0075] Step b2: If there are multiple abstract signatures corresponding to the interface function, a target abstract signature is randomly selected from the multiple abstract signatures.

[0076] In step b1, the number of abstract signatures corresponding to the interface function has been determined. If the number is greater than 1, execute this step. A random number generator can be used to randomly select one of the multiple abstract signatures as the target abstract signature, and the selected target abstract signature can be recorded for use in subsequent test case generation or execution.

[0077] The method for generating test cases provided by this embodiment randomly selects interface functions and abstract signatures to ensure that each generated test case is unique, thereby increasing the randomness and diversity of the test. This helps to discover errors or abnormal behaviors that only occur under specific conditions, and improves the coverage and quality of the test. In addition, when the interface function corresponds to multiple abstract signatures, random selection can ensure that the test case can cover different parameter combinations and call scenarios.

[0078] In a possible implementation, the function signature pool further includes: an internal callback function; wherein the above step a5 includes:

[0079] Step a51, using the CodeQL tool to mine and identify a nested example set corresponding to the nested call structure between interface function calls; wherein the nested example is used to characterize parameter transfer information between external functions and internal callback functions.

[0080] CodeQL uses a special query language, called QL (Query Language), to describe rules and patterns for static code analysis. QL is a declarative language, similar to SQL, that allows developers to describe specific patterns, vulnerabilities, and errors in the code at a high level of abstraction. By writing QL queries, developers can define the code properties and relationships they are interested in, and use the CodeQL engine to analyze the code base to find code instances that match the query.

[0081] Use CodeQL to perform static analysis on the code base and identify the nested call structure between interface function calls. For example: find the call sites of API functions in the AST, including external calls and internal callbacks. Check whether the same parameters are used in external calls and internal callbacks. If the parameter values ​​are equal (or the parameters are logically related, such as references to the same object), these calls are considered nested calls. Pay special attention to the calling relationship between external functions and internal callback functions, and how parameters are passed between them. Based on the mined nested call structure, generate a set of nested examples. These examples should be able to clearly represent the parameter passing information between external functions and internal callback functions. Each nested example should contain the call of the external function, the definition and call of the internal callback function, and the parameter passing path between them.

[0082] Step a52, randomly select an internal callback function from the function signature pool, and call the internal callback function and the parameters corresponding to the internal callback function in the callback of the external function to build a target test case.

[0083] When the test generator needs to select a function nested in a callback for a certain function, the nested example set is consulted. If there is a matching nested example, the external function associated with the selected internal callback function is determined according to the nested example set generated in step a51. In the callback part of the external function, the selected internal callback function is called and the corresponding parameters are passed. A test case is constructed, including the call of the external function, the definition and call of the internal callback function, and the parameter passing.

[0084] In one possible implementation, add necessary assertions and verification points to the test case to check whether the execution results of the internal callback function meet expectations. These assertions and verification points should be set based on the interface documentation, business logic, or expected test scenarios. Record the constructed test cases in the test case library for subsequent test execution and result analysis.

[0085] As an example, the CodeQL tool is used to mine and identify nested examples between API calls. The method uses the static analysis function of CodeQL to identify the functions imported by the API and the cases where the same parameters are used in external and internal calls by traversing the AST of the existing API client. The relationship between these API calls can be determined by checking whether the values ​​of the parameters are equal. The developed test generator uses the set of nested examples obtained by mining. When selecting a function to be nested in the callback of a certain function, the test generator refers to the set of nested examples to find an example that matches the function. If there is a matching nested example, the test generator randomly selects a corresponding internal function and calls it in the callback of the external function. Similarly, when selecting parameters, the test generator consults the selected nested examples to determine which parameters to reuse from the external function or back and forth. In this way, it is possible to leverage existing API usage and generate test cases with nested relationships, thereby more comprehensively testing the functionality and interaction of the API.

[0086] The method for generating test cases provided in this embodiment, by introducing internal callback functions, the test cases can simulate the complex scenarios in the actual software operation more deeply. This method not only tests the direct call of the interface function, but also tests the nested call relationship between them, thereby improving the breadth and depth of the test. By randomly selecting internal callback functions and calling them in the callback of the external function, the test case can simulate complex callback logic to discover potential problems. By utilizing the existing API usage, a test case with a nested relationship is generated, thereby more comprehensively testing the functions and interactions of the API.

[0087] In this embodiment, a device for generating test cases is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0088] This embodiment provides a device for generating test cases, such as Figure 2 As shown, it includes: an acquisition module 201, which is used to obtain the parameter list of each interface function of the tested library and the dependency relationship between each interface function; wherein the dependency relationship between each interface function includes: a sequence relationship and a nested relationship; a first generation module 202, which is used to generate an abstract signature list according to the parameter list of each interface function; wherein the abstract signature includes: callback parameters in the parameter list of the interface function, and properties corresponding to the callback parameters; a second generation module 203, which is used to generate a target test case according to the abstract signature and the dependency relationship between each interface function.

[0089] In one possible implementation, the second generation module 203 includes: a calling unit, which is used to iteratively expand the test case tree starting from the root node, and at the extension point of each callback node, randomly select an interface function from the function signature pool for calling to obtain a function call node; wherein the function signature pool maps the parameter type, number of parameters and interface function in the abstract signature list; a filling unit, which is used to fill the target abstract signature corresponding to the selected interface function into the function call node; a first generation unit, which is used to generate a parameter value corresponding to each parameter in the function call node according to the target abstract signature; a second generation unit, which is used to generate a corresponding nested call structure for each interface function according to the parameter value, parameter type, and the dependency relationship between each interface function; a third generation unit, which is used to traverse the test case tree according to the nested call structure to generate a target test case.

[0090] In one possible implementation, the device also includes: a first selection module, used to randomly select an interface function from a function signature pool and determine the number of abstract signatures corresponding to the interface function; a second selection module, used to randomly select a target abstract signature from multiple abstract signatures if the number of abstract signatures corresponding to the interface function is multiple.

[0091] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0092] The device for generating test cases in this embodiment is presented in the form of a functional unit, where the functional unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0093] The embodiment of the present invention also provides a computer device having the above Figure 2 The apparatus for generating test cases is shown.

[0094] See also Figure 3 , Figure 3 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such as Figure 3As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 3 A processor 10 is taken as an example.

[0095] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0096] The memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiment.

[0097] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0098] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0099] The computer device further comprises a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0100] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0101] A part of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of the computer program instruction in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc., and accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium accessible to the computer.

[0102] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A method for generating a test case, characterized in that: The method comprises: Obtain the parameter list of each interface function of the tested library and the dependency relationship between each interface function; wherein the dependency relationship between each interface function includes: sequence relationship and nested relationship; Generate an abstract signature list according to the parameter list of each interface function; wherein the abstract signature includes: callback parameters in the parameter list of the interface function and properties corresponding to the callback parameters; A target test case is generated according to the dependency relationship between the abstract signature and each interface function.

2. The method for generating a test case according to claim 1, characterized in that: The generating a target test case according to the dependency relationship between the abstract signature and each interface function comprises: Iteratively expand the test case tree starting from the root node, and at the extension point of each callback node, randomly select an interface function from the function signature pool to call, and obtain a function call node; wherein the function signature pool maps the parameter type, the number of parameters, and the interface function in the abstract signature list; Fill the target abstract signature corresponding to the selected interface function into the function call node; For each parameter in the function call node, generate the parameter value corresponding to each parameter according to the target abstract signature; Generate the corresponding nested call structure of each interface function according to the parameter value, parameter type, and the dependency relationship between each interface function; According to the nested call structure, traverse the test case tree and generate the target test case.

3. The method for generating a test case according to claim 2, characterized in that: Determine the target abstract signature, including: Randomly select an interface function from the function signature pool and determine the number of abstract signatures corresponding to the interface function; If there are multiple abstract signatures corresponding to the interface function, a target abstract signature is randomly selected from the multiple abstract signatures.

4. The method for generating a test case according to claim 2, characterized in that: The function signature pool also includes: an internal callback function; wherein, according to the nested call structure, traversing the test case tree to generate a target test case includes: Use CodeQL tools to mine and identify nested example sets corresponding to nested call structures between interface function calls; where nested examples are used to represent parameter transfer information between external functions and internal callback functions; Randomly select an internal callback function from the function signature pool, and call the internal callback function and the corresponding parameters of the internal callback function in the callback of the external function to build the target test case.

5. A device for generating test cases, characterized in that: The device comprises: The acquisition module is used to obtain the parameter list of each interface function of the tested library and the dependency relationship between each interface function; wherein the dependency relationship between each interface function includes: sequence relationship and nested relationship; The first generation module is used to generate an abstract signature list according to the parameter list of each interface function; wherein the abstract signature includes: callback parameters in the parameter list of the interface function and properties corresponding to the callback parameters; The second generating module is used to generate a target test case according to the dependency relationship between the abstract signature and each interface function.

6. The device for generating test cases according to claim 5, characterized in that: The second generation module includes: The calling unit is used to iteratively expand the test case tree starting from the root node, and at the extension point of each callback node, randomly select an interface function from the function signature pool to call, and obtain a function calling node; wherein the function signature pool maps the parameter type, the number of parameters and the interface function in the abstract signature list; A filling unit, used to fill the target abstract signature corresponding to the selected interface function into the function call node; A first generating unit, configured to generate, for each parameter in the function call node, a parameter value corresponding to each parameter according to the target abstract signature; The second generating unit is used to generate a corresponding nested call structure for each interface function according to the parameter value, parameter type, and the dependency relationship between each interface function; The third generating unit is used to traverse the test case tree according to the nested call structure and generate the target test case.

7. The device for generating test cases according to claim 6, characterized in that: The device also includes: The first selection module is used to randomly select an interface function from the function signature pool and determine the number of abstract signatures corresponding to the interface function; The second selection module is used to randomly select a target abstract signature from the multiple abstract signatures if the number of abstract signatures corresponding to the interface function is multiple.

8. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method for generating test cases according to any one of claims 1 to 4 by executing the computer instructions.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the method for generating a test case according to any one of claims 1 to 4.

10. A computer program product, characterized in that The method comprises computer instructions, wherein the computer instructions are used to cause a computer to execute the method for generating a test case according to any one of claims 1 to 4.

Images