Knowledge graph construction and test case recommendation method for supporting test case recommendation

Abstract

The application relates to a knowledge graph construction and test case recommendation method supporting test case recommendation, which comprises the following steps: analyzing historical test case data, constructing a business test knowledge graph, taking a function module and a test case extracted from the historical test case data as nodes in the business test knowledge graph, and establishing a coverage relationship between the test case and the function module; analyzing source code and program running data of the source code, constructing a code knowledge graph, taking a code element extracted from the source code as a node in the code knowledge graph, and establishing a dependency relationship between the code elements; constructing a composite knowledge graph according to the business test knowledge graph and the code knowledge graph, and the composite knowledge graph comprises an association path of a test case node associated to a corresponding implemented code element node through a function module node. Thus, data support is provided for intelligent recommendation of test cases, dependence on manual experience is reduced, and the analysis speed of the influence range after code modification is accelerated.

Description

[0001] This application claims the full benefit of Singapore Patent Application No. 10202503681Q, filed with the Intellectual Property Office of Singapore on December 11, 2025, entitled “Knowledge Graph Construction Method Supporting TestCase Recommendation and Test Case Recommendation Method”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of software testing technology, and in particular to a knowledge graph construction and test case recommendation method that supports test case recommendation. Background Technology

[0003] During the development and iteration of an application (APP), as APP functions are continuously updated and code is frequently changed (such as adding functions, fixing defects, optimizing logic, etc.), regression testing is required to verify whether the changes have an adverse effect on the original functions or introduce new defects.

[0004] Currently, in regression testing, test case selection generally relies on human experience, meaning test cases are manually selected to perform regression testing on the updated app. However, manual selection has many drawbacks. For example, non-critical path test cases are repeatedly executed, resulting in a serious waste of testing resources. Also, when the application code is modified, manually analyzing the scope of the change takes 1-2 days, leading to a delayed response and the potential to miss high-risk scenarios.

[0005] Therefore, in the existing technology, the method of manually selecting test cases has technical problems such as low efficiency and inaccurate test case selection. Summary of the Invention

[0006] This application provides a knowledge graph construction and test case recommendation method that supports test case recommendation, in order to solve the technical problems of low efficiency and inaccurate test case selection in the existing technology of manually screening test cases.

[0007] Firstly, this application provides a method for constructing a knowledge graph that supports test case recommendation, characterized in that the method includes: Analyze historical test case data to construct a business test knowledge graph. The business test knowledge graph uses functional modules and test cases extracted from the historical test case data as nodes, and establishes the coverage relationship between test cases and functional modules. The source code and its program execution data are parsed to construct a code knowledge graph, in which code elements extracted from the source code are used as nodes, and dependencies between code elements are established. Based on the business test knowledge graph and the code knowledge graph, a composite knowledge graph is constructed. The composite knowledge graph contains the association paths of test cases to the corresponding code elements implemented through functional modules.

[0008] Secondly, this application provides a test case recommendation method, the method comprising: In response to code change events affecting the source code, obtain information about the code change. Based on the code change information and the composite knowledge graph obtained by any of the methods described in the first aspect, the target code elements affected by the code change event are determined. From the composite knowledge graph, find the target functional module node that has a path associated with the target code element, and from the composite knowledge graph, find the test case node that has a path associated with the target functional module node; Based on the test case nodes found from the composite knowledge graph, the target test cases to be recommended are determined.

[0009] Thirdly, this application provides a knowledge graph construction apparatus that supports test case recommendation, the apparatus comprising: The business test graph construction module is used to parse historical test case data and construct a business test knowledge graph. The business test knowledge graph uses functional modules and test cases extracted from the historical test case data as nodes and establishes the coverage relationship between test cases and functional modules. The code graph construction module is used to parse the source code and the program execution data of the source code to construct a code knowledge graph. The code knowledge graph uses code elements extracted from the source code as nodes and establishes dependencies between code elements. The graph integration module is used to construct a composite knowledge graph based on the business test knowledge graph and the code knowledge graph. The composite knowledge graph contains the association paths of test cases to the corresponding code elements through functional modules.

[0010] Fourthly, this application provides a test case recommendation device, the device comprising: The code change identification module is used to obtain information about the code change in response to code change events to the source code; The target code element determination module is used to determine the target code elements affected by the code change event based on the current code change information and the composite knowledge graph obtained by the method described in any one of the first aspects. The graph query module is used to find target functional module nodes that have an associated path with the target code element from the composite knowledge graph, and to find test case nodes that have an associated path with the target functional module nodes from the composite knowledge graph. The test case recommendation module is used to determine the target test cases to be recommended based on the test case nodes found from the composite knowledge graph.

[0011] Fifthly, this application provides an electronic device, comprising: a processor and a memory, wherein the processor is configured to execute a knowledge graph construction program for supporting test case recommendations stored in the memory to implement the knowledge graph construction program method for supporting test case recommendations as described in any one of the first aspects; or, to execute a test case recommendation program stored in the memory to implement the test case recommendation method as described in any one of the second aspects.

[0012] Sixthly, this application provides a storage medium storing one or more programs that can be executed by one or more processors to implement the knowledge graph construction program method supporting test case recommendation as described in the first aspect; or to implement the test case recommendation method as described in the second aspect.

[0013] Compared with the prior art, the technical solution provided in this application has the following advantages: The method provided in this application can construct a business test knowledge graph by parsing historical test cases, establish coverage relationships with functional modules and test cases as nodes, and realize the structured association between test cases and business functions; at the same time, it can construct a code knowledge graph by parsing source code and runtime data, establish dependency relationships with code elements as nodes, and clarify the association logic at the code level; the composite knowledge graph further opens up the association path from test cases through functional modules to code elements, forming a closed-loop mapping of "test cases-functional modules-code elements". This process breaks down the knowledge silos between business scenarios and code modules, provides data support for intelligent recommendation of test cases, reduces the reliance on human experience, and speeds up the analysis of the impact range after code modification, thereby enabling efficient and accurate intelligent recommendation of test cases. Attached Figure Description

[0014] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0016] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0017] Figure 1 A flowchart illustrating an embodiment of a knowledge graph construction method supporting test case recommendation provided in this application. Figure 2 A flowchart illustrating another embodiment of a knowledge graph construction method supporting test case recommendation provided in this application. Figure 3 A schematic diagram of the structure of a business testing knowledge graph provided in an embodiment of this application; Figure 4 A flowchart illustrating another embodiment of a knowledge graph construction method supporting test case recommendation provided in this application. Figure 5 A schematic diagram of the structure of a code knowledge graph provided in an embodiment of this application; Figure 6 A flowchart illustrating another embodiment of a knowledge graph construction method supporting test case recommendation provided in this application. Figure 7 A flowchart illustrating an embodiment of a test case recommendation method provided in this application; Figure 8 A flowchart illustrating an embodiment of a knowledge graph construction and test case recommendation method supporting test case recommendation provided in this application; Figure 9 A block diagram illustrating an embodiment of a knowledge graph construction apparatus that supports test case recommendation, provided in this application. Figure 10 A block diagram illustrating an embodiment of a test case recommendation device provided in this application; Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0019] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0020] To address the inefficiencies and inaccuracies of manual test case selection in existing technologies, this application provides a knowledge graph construction and test case recommendation method that supports test case recommendation. It constructs a business test knowledge graph by parsing historical test cases, establishing coverage relationships between functional modules and test cases, thus achieving a structured association between test cases and business functions. Simultaneously, it constructs a code knowledge graph by parsing source code and runtime data, establishing dependencies between code elements, clarifying the logical connections at the code level. The composite knowledge graph further connects test cases through functional modules to code elements, forming a closed-loop mapping of "test case - functional module - code element." This process breaks down the knowledge silos between business scenarios and code modules, providing data support for intelligent test case recommendation, reducing reliance on manual experience, and accelerating the analysis of the impact of code modifications. This enables efficient and accurate intelligent recommendation of test cases.

[0021] The knowledge graph construction and test case recommendation method supporting test case recommendation provided in this application will be further explained and described below with reference to the accompanying drawings and specific embodiments. The embodiments do not constitute a limitation on the embodiments of this invention.

[0022] To facilitate understanding, the knowledge graph construction method for supporting test case recommendations provided in this application will be further explained and illustrated with specific embodiments. These embodiments do not constitute a limitation on the embodiments of this invention.

[0023] Figure 1 This is a flowchart illustrating an embodiment of a knowledge graph construction method supporting test case recommendation, provided in this application. Figure 1 As shown, the process may include the following steps: Step 101: Parse historical test case data and construct a business test knowledge graph. The above business test knowledge graph uses functional modules and test cases extracted from historical test case data as nodes, and establishes the coverage relationship between test cases and functional modules.

[0024] The aforementioned historical test case data refers to test case data used to test functional modules within a historical time period. This data may include, but is not limited to, test cases built and applied within the historical time period, and test cases built but not applied within the historical time period. Optionally, this historical test case data may include, but is not limited to, test case descriptions, functional modules, operational actions, and expected results. The design goal of a test case is to verify the correctness of the business logic of a specific functional module.

[0025] The aforementioned functional modules refer to testable units in the system that have independent business functions, such as the payment process, product category browsing function, or user login function in an APP.

[0026] The coverage relationship mentioned above refers to the association between test cases and functional modules. That is, when a test case covers a functional module, it indicates that the test case can be used to test the correctness of the business logic of the covered functional module. A test case can cover multiple functional modules, and a functional module can be covered by multiple test cases.

[0027] For example, if the historical test case data consists of test cases for the payment function of an e-commerce platform, the test cases may include TC001, TC002, and TC003. The functional modules being tested may include the payment process and the inventory process. Then, the above coverage relationship may include: TC001 covers the payment process → verifying the core payment link; TC002 covers the payment process → verifying the amount calculation logic; TC003 covers inventory management → verifying the inventory synchronization mechanism; TC001 covers both the payment process and inventory management → verifying the real-time deduction of inventory after successful payment (combined business scenarios).

[0028] In this step, in order to associate test cases with the functional modules of the system, test cases corresponding to each functional module can be determined efficiently and accurately based on historical test case data.

[0029] As an optional implementation, the execution entity of this application embodiment may have a test case library (such as Jira / Testlink (a web-based test case management system)) for storing historical test case data. Based on this, historical test case data can be obtained from the test case library.

[0030] As an alternative implementation, the execution entity of this application embodiment can obtain the aforementioned historical test case data from a third-party platform.

[0031] As another optional implementation, in order to obtain more comprehensive historical test case data, the execution entity of this application embodiment can obtain historical test case data from a pre-built test case library and a third-party platform, respectively.

[0032] Then, the historical test case data can be parsed to determine the test cases, functional modules, and coverage relationships between them. Based on the parsed test cases, functional modules, and coverage relationships, a business test knowledge graph can be constructed to represent business tests.

[0033] As an optional implementation, the execution entity of this application embodiment can use NLP (Natural Language Processing) technology to parse the above-mentioned historical test case data.

[0034] As for the specifics of how historical test case data is parsed and the business test knowledge graph is constructed, this will be explained in the following text. Figure 2 The process shown will be explained in detail here.

[0035] Step 102: Parse the source code and the program execution data of the source code, and construct a code knowledge graph. The code knowledge graph uses code elements extracted from the source code as nodes and establishes dependencies between code elements.

[0036] The source code mentioned above refers to the development code used when developing an app, which may include, but is not limited to, Java code, Python code, etc.

[0037] The aforementioned program execution data refers to the relevant data generated during the actual execution of the source code, such as dynamic call chains. For example, when a user performs a "payment" operation, JaCoCo (Java Code Coverage, a code coverage tool for Java projects) instrumentation technology can record the call chain of related methods in PaymentService (such as a series of execution paths, like PaymentService.pay() calling OrderDAO.query()). This type of data can be used to deduce the corresponding payment process.

[0038] The aforementioned code knowledge graph may include various code elements extracted from the source code, as well as the dependencies between these code elements.

[0039] The aforementioned code elements refer to the basic units or components extracted from the source code that constitute the program structure. They are the core components of nodes in the code knowledge graph, and specifically include, but are not limited to, the following types: Basic syntax elements: variables (namespaces for storing data), constants (fixed values), functions (code blocks that implement specific functionalities), methods (functions defined in a class), classes (data and method encapsulation units in object-oriented programming), interfaces (defining the method specifications that a class must implement), enumerations (a set of named constants), etc. Structured elements: Modules (code files or collections divided by function), packages (combinations of multiple modules used to organize code structure), components (code units with independent functions, such as UI components, tool components, etc.); Logical control elements include conditional blocks (such as if-else structures), loop blocks (such as for / while structures), and exception handling blocks (such as try-catch structures). These elements embody the execution logic of the code.

[0040] The dependencies between the aforementioned code elements refer to the relationships between different code elements in terms of syntax, execution, or functional implementation. These dependencies are the core components of the edges in a code knowledge graph, and include at least one of the following: call relationships, inheritance relationships, implementation relationships, and reference relationships. These dependencies may include, but are not limited to, syntax dependencies, resource dependencies, and execution dependencies.

[0041] Syntactic dependencies can include: invocation dependencies, such as function B calling function A, then function B depends on function A; a method of class A calling a method of class B, then class A depends on class B; inheritance dependencies, such as class B inheriting from class A, then class B depends on class A (requiring reuse of class A's attributes and methods); implementation dependencies, such as class B implementing interface A, then class B depends on interface A (requiring adherence to the method specifications defined by interface A); and reference dependencies, such as variable A referencing object B, then variable A depends on object B; a parameter of function A being an instance of class B, then function A depends on class B.

[0042] The resource dependencies mentioned above may include: data dependencies, such as function B's output being used as function A's input, in which case function B depends on the data result of function A; and configuration dependencies, such as module A loading parameters from configuration file B, in which case module A depends on configuration file B.

[0043] The execution dependencies mentioned above may include: timing dependencies, such as code block A must be executed before code block B (e.g., initialization operations and business logic operations), in which case code block B depends on code block A; exception dependencies, such as exception handling block A catching exceptions thrown by function B, in which case exception handling block A depends on function B.

[0044] In practical applications, the functional modules of an application are implemented through code. Therefore, when updating the functional modules of an application, it is also done by changing the code. However, the code of each functional module is not independent of each other. A change in the code of one functional module may affect the code of multiple functional modules.

[0045] Therefore, in this step, to quickly locate the affected code elements and related functional modules when code changes occur, the execution entity of this application embodiment can parse the application's source code and its actual runtime data to obtain the code elements included in the source code and the dependencies between these elements. Subsequently, a code knowledge graph containing each code element and its dependencies can be constructed. These dependencies reflect the code's organizational structure, execution logic, and functional relationships, serving as the core basis for constructing the code knowledge graph and aiding in analyzing the scope of code change impacts, test case coverage paths, and other scenarios.

[0046] As an optional implementation, when parsing the source code, the execution entity of this application embodiment can use tools such as ANTLR (Another Tool for Language Recognition) to parse the source code and generate an AST (Abstract Syntax Tree), and extract code elements such as classes, methods, and parameters from the AST.

[0047] As an optional implementation, the execution entity of this application embodiment can use dynamic analysis technology to parse the obtained program running data to determine the calling order and dependency relationship of different code elements (such as classes and methods) during the execution process.

[0048] As for the specifics of how the source code and its execution data are parsed to construct the code knowledge graph, this will be explained below. Figure 4 The process shown will be explained in detail here.

[0049] Step 103: Based on the above business test knowledge graph and code knowledge graph, construct a composite knowledge graph. The composite knowledge graph contains the association paths of test case nodes to the corresponding code element nodes through functional module nodes.

[0050] The aforementioned association path refers to the directed association chain connecting three types of nodes—"test cases," "functional modules," and "code elements"—within a composite knowledge graph. Specifically, it manifests as: First-level association: the "coverage relationship" between test case nodes and functional module nodes (i.e., which functional module the test case verifies); Second-level association: the "implementation association" between functional module nodes and code element nodes (i.e., which code elements develop and implement the functional module; the strength of the association can be quantified by association probability). For example: "Test case A → Coverage → Functional module B → Implemented by code element C (such as a specific class or function)" forms the association path "Test case A - Functional module B - Code element C".

[0051] In this step, to further establish the relationships between test cases, functional modules, and code elements, the execution entity of this application embodiment can construct a composite knowledge graph containing the association paths between test case nodes, functional module nodes, and code element nodes based on the constructed business test knowledge graph and code knowledge graph. Since this composite knowledge graph contains the association paths from test case nodes to corresponding implemented code element nodes via functional module nodes, it can intuitively display the verification logic of test cases for functions and the mapping relationship between functions and underlying code, providing a traceable basis for test case recommendation (such as recommending test cases that need regression when code changes).

[0052] As an optional implementation, a business test knowledge graph can be used as a foundation. Each element (test case node or functional module node) within this knowledge graph is traversed to determine if a relationship exists between the test case node and the code element in the code knowledge graph. Optionally, if a relationship is determined, a path can be constructed between the two elements. Based on this, after traversing each element in the business test knowledge graph, the aforementioned composite knowledge graph can be obtained.

[0053] As an alternative implementation, a code knowledge graph can be used as a foundation. Each code element node in the code knowledge graph is traversed to determine if there is a relationship between each element (test case node or functional module node) included in the business test knowledge graph and that code element node. Optionally, if a relationship is determined, a connection path can be constructed between the two. Based on this, after traversing each code element node in the code knowledge graph, the aforementioned composite knowledge graph can be obtained.

[0054] Furthermore, when constructing the aforementioned composite knowledge graph, after determining the relationships between elements (test case nodes or functional module nodes) in the business test knowledge graph and code element nodes in the code knowledge graph, and constructing the association paths, the association probability between the two can be determined, and this association probability can be reflected as the weight of the association path in the composite knowledge graph. This approach allows the composite knowledge graph to more accurately reflect the relationships between test cases and code elements, as well as between functional modules and code elements.

[0055] As for the specifics of how to further construct the aforementioned composite knowledge graph, this will be explained in the following text. Figure 6 The process shown will be explained in detail here.

[0056] Furthermore, in one embodiment, after constructing the aforementioned composite knowledge graph, the executing entity of this application embodiment can update the aforementioned business test knowledge graph and / or code knowledge graph in real time or periodically, as well as update the aforementioned composite knowledge graph.

[0057] As an optional implementation, the execution entity in this application embodiment can parse historical test case data in real time or periodically to update the business test knowledge graph and composite knowledge graph.

[0058] As an alternative implementation, the execution entity in this application embodiment can parse the source code in real time or periodically to update the code knowledge graph and composite knowledge graph.

[0059] As another optional implementation, the execution entity of this application embodiment can parse historical test case data and source code in real time or periodically to update the business test knowledge graph, code knowledge graph, and composite knowledge graph.

[0060] In another embodiment, the executing entity of this application embodiment may update the aforementioned business testing knowledge graph and / or code knowledge graph, as well as the aforementioned composite knowledge graph, in response to a specific event. The aforementioned specific event refers to an event that changes any element or any relationship in the business testing knowledge graph and / or code knowledge graph, or the composite knowledge graph, such as adding a test case, code changes, or the emergence of a new defect in any of the aforementioned knowledge graphs.

[0061] As an optional implementation, the aforementioned specific event can be an event that updates test cases (adding test cases, deleting test cases, or modifying test cases, etc.). Based on this, the execution entity of this application embodiment can analyze the specific event to determine the target test case to be updated. Then, the aforementioned target test case can be updated, and the business test knowledge graph and composite knowledge graph can be updated accordingly.

[0062] As an alternative implementation, the aforementioned specific event can be an event that updates functional modules and code elements (e.g., adding or deleting functionality by updating code). Based on this, the execution entity of this application embodiment can analyze the specific event to determine the target functional module and target code element to be updated. Subsequently, the aforementioned target functional module and target code element can be updated, and the business test knowledge graph, code knowledge graph, and composite knowledge graph can be updated accordingly.

[0063] As another optional implementation, the aforementioned specific event can be an event that updates code elements (e.g., standardizing the source code according to a preset standard while ensuring that the functional modules remain unchanged). Based on this, the execution entity of this application embodiment can analyze the specific event to determine the target code element to be updated. Then, the target code element can be updated, and the code knowledge graph and composite knowledge graph can be updated accordingly.

[0064] As another optional implementation, the aforementioned specific event can be an event that simultaneously updates test cases, functional modules, and code elements (e.g., adding new functionality to the application by updating the source code, and adding test cases for that new functionality). Based on this, the execution entity of this application embodiment can analyze the specific event to determine the target test cases, target functional modules, and target code elements to be updated. Then, the aforementioned target test cases, target functional modules, and target code elements can be updated, and the business test knowledge graph, code knowledge graph, and composite knowledge graph can be updated accordingly.

[0065] The technical solution provided in this application constructs a business test knowledge graph by parsing historical test case data. The business test knowledge graph uses functional modules and test cases extracted from the historical test case data as nodes, and establishes a coverage relationship between test cases and functional modules. The source code and the program execution data of the source code are parsed to construct a code knowledge graph. The code knowledge graph uses code elements extracted from the source code as nodes, and establishes a dependency relationship between code elements. Based on the business test knowledge graph and the code knowledge graph, a composite knowledge graph is constructed. The composite knowledge graph contains the association path of test cases to the corresponding implemented code elements through functional modules. This technical solution constructs a business test knowledge graph by analyzing historical test cases, establishing coverage relationships between functional modules and test cases to achieve a structured association between test cases and business functions. Then, it constructs a code knowledge graph by analyzing source code and runtime data, establishing dependencies between code elements to clarify the logical connections at the code level. The composite knowledge graph further connects test cases through functional modules to code elements, forming a closed-loop mapping of "test case - functional module - code element." This process breaks down the knowledge silos between business scenarios and code modules, providing data support for intelligent test case recommendation, reducing reliance on human experience, and accelerating the analysis of the impact of code modifications. This enables efficient and accurate intelligent recommendation of test cases.

[0066] See Figure 2 The flowchart below shows another embodiment of a knowledge graph construction method that supports test case recommendation, provided by this application. Figure 2 The process shown is in Figure 1 Based on the illustrated process, the text describes how historical test case data is parsed to construct a business test knowledge graph. For example... Figure 2 As shown, the process may include the following steps: Step 201: Parse historical test case data and extract the functional modules corresponding to the test cases.

[0067] In this step, the aforementioned historical test case data may include one or more test cases, and each test case may test one or more functional modules. Based on this, the execution entity of this application embodiment parses each test case in the historical test case data to obtain the functional module corresponding to each test case.

[0068] As an optional implementation, the description text of the above test cases may include, but is not limited to, the following information: test case description, functional module, operation action, and expected result. For example, for the "user login" functional module, the designed test cases may include: For the "user login" functional module, the operation steps are "enter the correct username and password, and click the login button", and the expected result is "successfully redirected to the homepage".

[0069] Based on this, the execution entity of this application embodiment can extract the functional modules of test cases through NLP technology.

[0070] Furthermore, to ensure the accuracy of the extracted functional modules, the executing entity in this embodiment can utilize NLP technology to extract information such as the operation object and business scenario from the test case description. Then, semantic matching can be performed with pre-stored application functional module names (such as "user login" and "order payment") to identify the functional module targeted by each test case.

[0071] At the same time, by combining the execution records of test cases, it can be determined whether they fully cover the core logic of the corresponding functional modules, thereby establishing a clear coverage relationship between the two and providing a basis for the association of nodes in the business test knowledge graph.

[0072] Step 202: Determine the priority labels of the functional modules.

[0073] The aforementioned priority labels are used to characterize the test importance level of functional modules. They can be represented by letters, numbers, or other identifiers, and this application embodiment does not impose any restrictions on this. For example, P can represent a priority label, and P0, P1, P2, etc., can represent different priority labels, with the test importance level they represent decreasing sequentially.

[0074] In practical applications, the operation of an application may include multiple functional modules, and different functional modules may have different levels of importance. For example, in a product sales platform, "order payment" is more important than "browsing history".

[0075] Based on this, in order to identify the importance of functional modules and to focus on testing functional modules with high importance levels when testing functional modules, the execution entity of this application embodiment can determine a priority label for each functional module to characterize the test importance level of the corresponding functional module.

[0076] In one embodiment, when determining the priority label of a functional module, the historical test case data can be parsed to obtain the historical test execution frequency and defect correlation value of the functional module. The historical test execution frequency value measures how frequently the functional module was tested in historical tests; it can be the proportion of the number of historical test executions of the functional module to the total number of tests in the project. The defect correlation value measures the degree of correlation between defects in the functional module during testing and defects in the entire application; it can be the proportion of the number of historical defects associated with the functional module to the total number of defects in the project.

[0077] As an optional implementation, when determining the historical test execution frequency value for each functional module, one can determine the number of times each functional module has been tested in the past, as well as the total number of tests conducted on the entire application. Then, the historical test execution frequency value can be obtained by dividing the historical test execution count by the total number of tests conducted on the entire application.

[0078] Furthermore, in order to make unified quantitative comparisons with other indicators, the above historical test execution frequency values ​​can be expressed as a percentage. Based on this, the first percentage obtained by dividing the above historical test execution times by the total number of tests in the project can be converted into a percentage, for example, 80% can be converted into 80.

[0079] Furthermore, to increase the distinguishability of the historical test execution frequency value, the execution entity in this application embodiment can use a segmented mapping rule to determine the aforementioned historical test execution frequency value. Optionally, different correspondences between first percentage intervals and percentage values ​​can be pre-defined. Then, after dividing the number of historical test executions by the total number of tests in the project to obtain the first percentage, the target first percentage interval to which the first percentage belongs can be determined from the aforementioned correspondence, and the first target percentage value corresponding to the target first percentage interval can be determined as the historical test execution frequency value of the functional module.

[0080] For example, the following correspondence between the first percentage range and the percentage value can be preset: [80%, 100%] → 100, (50%, 80%) → 80, [0, 50%] → 60. Based on this, assuming that the "payment process" is executed 800 times in 1000 tests, then the first percentage corresponding to the "payment process" can be 80%. From the above correspondence, it can be determined that the historical test execution frequency value of the "payment process" function module can be 100.

[0081] Optionally, in the method for determining the historical test execution frequency value, if there are newly added functional modules that have not participated in the test, the historical test execution frequency value of the functional module can be set to a preset value. The preset value can be 100 or other values. This application embodiment does not limit this.

[0082] As an optional implementation, when determining the defect correlation value of a functional module, the number of historical defects that occurred in the testing of each functional module, as well as the total number of defects in the application testing project, can be determined. Then, the number of historical defects can be divided by the total number of defects in the project to obtain the defect correlation value of that functional module.

[0083] Furthermore, in order to make unified quantitative comparisons with other indicators, the above defect correlation value can be expressed as a percentage. Based on this, the second percentage obtained by dividing the above historical defect count by the total number of project defects can be converted into a percentage, for example, 70% can be converted into 70.

[0084] Furthermore, to increase the distinguishability of the defect correlation value, the execution entity of this application embodiment can use a segmented mapping rule to determine the defect correlation value. Optionally, different correspondences between second percentage intervals and percentage values ​​can be pre-defined. Then, after dividing the number of historical defects by the total number of defects in the project to obtain the second percentage, the target second percentage interval to which the second percentage belongs can be determined from the above correspondence, and the second target percentage value corresponding to the target second percentage can be determined as the defect correlation value of the functional module.

[0085] For example, the following correspondence between the second percentage range and the percentage value can be preset: [80%, 100%] → 100, (50%, 80%) → 80, [0, 50%] → 60. Based on this, assuming that the total number of defects in the application during testing is 300 and the number of historical defects in the "payment process" during testing is 30, then the second percentage corresponding to the "payment process" can be 10%. From the above correspondence, the defect correlation value of the "payment process" functional module can be determined to be 60.

[0086] Optionally, in the method for determining the defect correlation value, if there are newly added functional modules that have not participated in the test, the defect correlation value of the functional module can be set to a preset value. The preset value can be 100 or other values. This application embodiment does not limit this.

[0087] In this embodiment, after determining the historical test execution frequency and defect correlation value of a functional module, a weighted calculation can be performed based on the historical test execution frequency, defect correlation value, and a predefined priority score. Then, the priority label of the functional module can be determined based on the weighted calculation result. The aforementioned predefined priority score can be a manually defined priority score for the test cases corresponding to the functional module.

[0088] As an optional implementation, the weight values ​​corresponding to the historical test execution frequency, defect correlation, and priority score can be preset. Then, based on the weight values ​​corresponding to the historical test execution frequency, defect correlation, and priority score, a weighted sum can be performed to obtain the priority score.

[0089] Then, the priority label corresponding to the aforementioned priority score can be determined from the pre-set correspondence between priority scores and priority labels.

[0090] For example, assuming the weight of the historical test execution frequency value is 20%, the weight of the defect correlation value is 30%, and the weight of the priority score value is 50%, then the priority score can be obtained by weighted summing the above historical test execution frequency value, defect correlation value, and priority score value using the following formula (I): Formula (1) Among them, the above As priority scores, the above The above refers to the historical test execution frequency values. The above is the defect correlation value. This is the priority score.

[0091] Continuing to assume the following correspondence between priority scores and priority labels: S≥80→P0 (Core), 50≤S<80→P1 (Important), S<50→P2 (General). And assuming a priority score of 70, then the priority label for the functional module can be determined as P1 from the above correspondence.

[0092] Step 203: Establish the coverage relationship between test cases and their corresponding functional modules.

[0093] Step 204: Construct a graph structure using the above functional modules and test cases as nodes and the above coverage relationships as edges, and use the above priority tags as attributes of functional module nodes to form a business test knowledge graph.

[0094] The following provides a unified explanation of steps 203 and 204: In this embodiment of the application, as can be seen from step 201, when the executing entity extracts the functional modules corresponding to the test cases, it can extract the corresponding functional modules for each test case. Based on this, after extracting the functional modules of each test case, the association between the test case and the functional modules can be established.

[0095] In this step, based on the association between the constructed test cases and functional modules, a coverage relationship between the test cases and their corresponding functional modules can be established. On this basis, a graph structure can be constructed using the aforementioned functional modules and test cases as nodes and the aforementioned coverage relationship as edges. Simultaneously, to indicate the importance level of each functional module during testing, the execution entity in this embodiment can use the priority label corresponding to each functional module as an attribute of the functional module node, thereby forming a business test knowledge graph.

[0096] For example, suppose the functional modules include: "User Registration", "Product Search" and "Order Submission", and each node has a priority tag attribute. For example, the priority tag for "User Registration" is "High", the priority tag for "Product Search" is "Medium", and the priority tag for "Order Submission" is "High".

[0097] Continuing with the assumption that the test cases include: “Test Case 001”, “Test Case 002”, and “Test Case 003”, “Test Case 001” is used to test the “User Registration” function module, “Test Case 002” is used to test the “Product Search” and “User Registration” function modules, and “Test Case 003” is used to test the “Order Submission” function module.

[0098] Based on this, the following can be constructed according to steps 203 and 204: Figure 3 The business testing knowledge graph shown. See also... Figure 3 This is a schematic diagram of the structure of a business testing knowledge graph provided in an embodiment of this application, such as... Figure 3 As shown, "Test Case 001" is connected to "User Registration", indicating that "Test Case 001" covers the "User Registration" functional module, and the attribute of the "User Registration" functional node is "High"; "Test Case 002" is connected to both "User Registration" and "Product Search", indicating that "Test Case 002" covers both the "Product Search" and "User Registration" functional modules, and the attribute of the "Product Search" functional module node is "Medium"; "Test Case 003" is connected to "Order Submission", indicating that "Test Case 003" covers the "Order Submission" functional module, and the attribute of the "Order Submission" functional module node is "High".

[0099] The technical solution provided in this application, by parsing historical test case data, extracts the functional modules corresponding to the test cases, determines the priority tags of the functional modules, establishes the coverage relationship between the test cases and their corresponding functional modules, constructs a graph structure with the aforementioned functional modules and test cases as nodes and the aforementioned coverage relationship as edges, and uses the aforementioned priority tags as attributes of the functional module nodes to form a business test knowledge graph. This technical solution, by using functional modules and test cases as nodes and coverage relationships as edges when constructing the business test knowledge graph, and assigning priority tag attributes to the functional modules, can clearly present the association between test cases and functional modules, facilitating the rapid location of test cases corresponding to specific functional modules. Simultaneously, by combining priority tags, priority can be given to the test coverage of high-priority functional modules, improving the rationality of test resource allocation and test efficiency, and providing structured knowledge support for the management, execution, and optimization of test cases.

[0100] See Figure 4 This is a flowchart of another embodiment of a knowledge graph construction method that supports test case recommendation provided in this application. Figure 4 The process shown is in Figure 1 Based on the illustrated process, the text describes how the source code and its execution data are parsed to construct a code knowledge graph. For example... Figure 4 As shown, the process may include the following steps: Step 401: Parse the source code and its program execution data, and extract the code elements and dependencies between them.

[0101] In this step, in order to determine the code elements contained in the source code and the dependencies between the code elements, the execution subject of this application embodiment, after obtaining the source code of the application and the program running data of the source code, can extract the code elements in the source code and the dependencies between the code elements by parsing the source code and the program running data of the source code.

[0102] As an optional implementation, static parsing of the source code can be performed first. Alternatively, syntax parsing tools such as ANTLR can be used to convert the source code into an Abstract Syntax Tree (AST) based on the syntax rules of the programming language to which the source code belongs.

[0103] Then, by traversing the AST, code elements such as classes, methods, properties, parameters, interfaces, and functions can be extracted. At the same time, the static dependencies between code elements can be analyzed, such as class inheritance relationships (e.g., ClassA inherits from ClassB), method call relationships (e.g., MethodX calls MethodY), parameter passing relationships, etc., to form a preliminary dependency set.

[0104] Next, dynamic analysis can be performed on the program's runtime data to determine dynamic call chains, module interaction trajectories, data flow, and other program runtime data during execution. For example, when a user triggers the "order submission" function, the execution path of the OrderService class's submit() method calling the InventoryService's check() method and the PaymentService's deduct() method can be captured in real time. From this, the dynamic dependencies of code elements in actual operation can be extracted, such as the order of method calls and cross-module collaboration relationships.

[0105] Finally, the results of the static and dynamic analysis can be combined. The code elements and static dependencies obtained from static analysis are compared and integrated with the dynamic dependencies obtained from dynamic analysis. Inconsistent data is eliminated and missing associations are supplemented. Finally, the complete dependency relationships between code elements (including static structural dependencies and dynamic execution dependencies) are determined, providing core data of nodes (code elements) and edges (dependencies) for building a code knowledge graph.

[0106] Step 402: Determine the code risk assessment value of the code element.

[0107] The above code risk assessment value can be used as a quantitative assessment indicator to characterize the risks of code elements in terms of security, stability, and maintainability, and it can reflect the severity of the potential problems of the code element.

[0108] In this step, in order to quickly identify high-risk code elements during code changes or testing, the execution entity of this application embodiment can determine the code risk assessment value of each code element, so as to intuitively reflect the potential risk level of the code element in terms of security, stability, etc. through the code risk assessment value.

[0109] As an optional implementation, when determining the risk level score of a code element, the program execution data of the source code can be analyzed first to obtain the risk level score, historical change frequency value, and defect density value of the code element. The risk level score characterizes the risk level of the code element. These risks may include, but are not limited to, high concurrency risk, resource leakage risk, and security vulnerability risk. A higher risk level score indicates a higher degree of risk for the code element; that is, the risk level score is positively correlated with the degree of risk of the code element. The historical change frequency value characterizes the proportion of historically modified lines of code to the total number of modified lines in the project. The defect density value characterizes the proportion of the number of historical defects associated with the code element to the number of lines of code.

[0110] As an optional implementation, static analysis can be performed on the program execution data of the source code to detect the risk scores corresponding to code elements across different risk dimensions. These risk dimensions may include, but are not limited to, high concurrency risk, resource leakage risk, security vulnerability risk, and code complexity.

[0111] Then, based on the pre-set weight values ​​corresponding to each risk dimension, the risk scores corresponding to each risk dimension can be weighted and summed to obtain the risk level score of the code element.

[0112] As an optional implementation, when determining the historical change frequency value for each code element, one can determine the number of historical lines modified for that code element within a historical time period, as well as the total number of lines modified in the application within that historical time period. Then, the historical change frequency value for the code element can be obtained by dividing the historical change number by the total number of lines modified.

[0113] Furthermore, in order to make unified quantitative comparisons with other indicators, the above historical change frequency values ​​can be expressed as a percentage. Based on this, the third percentage of the historical number of modified lines divided by the total number of modified lines of the above project can be converted into a percentage, for example, 70% can be converted into 70.

[0114] Furthermore, to increase the distinguishability of the historical change frequency value, the execution entity of this application embodiment can use a segmented mapping rule to determine the aforementioned historical change frequency value. Optionally, different correspondences between third percentage intervals and percentage values ​​can be pre-defined. Then, after dividing the number of historical modified lines by the total number of modified lines of the aforementioned project to obtain the third percentage, the target third percentage interval to which the third percentage belongs can be determined from the aforementioned correspondence, and the third target percentage value corresponding to the target third percentage can be determined as the historical change frequency value of the code element.

[0115] Optionally, in the method for determining the historical change frequency value, if there is a newly added code element, the historical change frequency value of the code element can be determined as a preset value. The preset value can be 0 or other values, and this application embodiment does not limit this.

[0116] As an optional implementation, when determining the defect density value of a code element, one can first determine the number of historical defects that are related to that code element among the defects that appeared in the test, as well as the number of lines of code that are related to that code element. Then, the defect density value of the code element can be obtained by dividing the number of historical defects by the number of lines of code.

[0117] Furthermore, in order to make unified quantitative comparisons with other indicators, the above defect density value can be expressed as a percentage. Based on this, the fourth percentage of the number of historical defects divided by the number of lines of code can be converted into a percentage, for example, 70% can be converted into 70.

[0118] Furthermore, to increase the distinguishability of the defect density value, the execution entity of this application embodiment can use a segmented mapping rule to determine the defect density value. Optionally, different correspondences between fourth percentage intervals and percentage values ​​can be pre-defined. Then, after dividing the number of historical defects by the number of lines of code to obtain the fourth percentage, the target fourth percentage interval to which the fourth percentage belongs can be determined from the above correspondence, and the fourth target percentage value corresponding to the target fourth percentage can be determined as the defect density value of the code element.

[0119] Optionally, in the method for determining the defect density value, if there is a newly added code element, the defect density value of the code element can be determined as a preset value. The preset value can be 0 or other values, and this application embodiment does not limit this.

[0120] In this embodiment, after determining the risk level score, historical change frequency value, and defect density value of the code element, a weighted calculation can be performed based on the risk level score, historical change frequency value, and defect density value of the code element to obtain the code risk assessment value of the code element.

[0121] As an optional implementation, the weight values ​​corresponding to the aforementioned risk level score, historical change frequency value, and defect density value can be pre-set. Then, based on the weight values ​​corresponding to the risk level score, historical change frequency value, and defect density value, a weighted sum can be performed on these values ​​to obtain the code risk assessment value for the code element.

[0122] For example, assuming the risk level score has a weight of 40%, the historical change frequency value has a weight of 30%, and the defect density value has a weight of 30%, then the code risk assessment value can be obtained by weighting and summing the above risk level score, historical change frequency value, and defect density value using the following formula (II): Formula (II) Wherein, R represents the risk level score, and the above... The above are historical change frequency values. The above represents the defect density value. This is the code risk assessment value.

[0123] Step 403: Construct a graph structure with code elements as nodes and the above dependencies as edges, and use the code risk assessment value as an attribute of the code element node to form a code knowledge graph.

[0124] In this step, the execution entity of this application embodiment can extract the code elements contained in the source code, the dependencies between the code elements, and the code risk assessment value of each code element. Then, it can construct a graph structure using the code elements as nodes and the dependencies as edges. Simultaneously, to label the risk level of each code element, the execution entity of this application embodiment can use the code risk assessment value corresponding to each code element as an attribute of the code element node, thereby forming a code knowledge graph.

[0125] For example, suppose that by parsing the source code of APP1 and its program execution data, code elements A, B, C, and D can be extracted. Code element A can call code elements B and D, and code element B can call code elements C and D.

[0126] Continuing to assume that code element A has a code risk assessment value of 40, code element B has a code risk assessment value of 50, code element C has a code risk assessment value of 60, and code element D has a code risk assessment value of 70, a system can be established as follows: Figure 5 The code knowledge graph shown. See also Figure 5 This is a schematic diagram of the structure of a code knowledge graph provided in an embodiment of this application, such as... Figure 5 As shown, the code knowledge graph may include: code element A node, code element B node, code element C node, and code element D node.

[0127] In this example, the attribute value of code element A is 40, the attribute value of code element B is 50, the attribute value of code element C is 60, and the attribute value of code element D is 70. Code element A can connect to code element B and code element D, and code element B can connect to code element C and code element D.

[0128] Furthermore, to represent the above calling relationship, code element A can point to code element B and code element D respectively via arrows, and code element B can point to code element C and code element D respectively via arrows.

[0129] The technical solution provided in this application analyzes the source code and its program execution data to extract code elements and dependencies between them. It then determines the code risk assessment value of each code element, constructs a graph structure using code elements as nodes and the aforementioned dependencies as edges, and uses the code risk assessment value as an attribute of the code element node to form a code knowledge graph. This technical solution, by using code elements as nodes, dependencies as edges, and code risk assessment values ​​as attributes of code elements during the code knowledge graph construction, systematically organizes the relationships between code elements, clearly presents the code structure and execution logic, and intuitively identifies high-risk code elements using risk assessment values. This facilitates developers and testers in accurately locating potential problems, optimizing code quality, improving code maintenance efficiency, and providing reliable technical support for analyzing the impact of code changes and determining testing priorities.

[0130] See Figure 6 The flowchart below is an embodiment of another knowledge graph construction method that supports test case recommendation provided in this application. Figure 6 The process shown is in Figure 1 Based on the illustrated process, the text describes how a composite knowledge graph is constructed from the business test knowledge graph and the code knowledge graph. For example... Figure 6 As shown, the process may include the following steps: Step 601: Determine the first association probability between the functional module nodes in the business test knowledge graph and the code element nodes in the code knowledge graph.

[0131] The aforementioned functional module nodes refer to the nodes corresponding to the functional modules included in the business testing knowledge graph.

[0132] The code element nodes mentioned above are the nodes corresponding to the code elements contained in the code knowledge graph.

[0133] The aforementioned first association probability is a quantitative indicator used to measure the likelihood of a relationship between functional module nodes in the business test knowledge graph and code element nodes in the code knowledge graph.

[0134] In this step, associating functional module nodes with code element nodes is essentially a correspondence between "business requirements" and "technical implementation" (e.g., "payment process" corresponds to "PaymentService class"). Therefore, in order to more accurately determine the association between functional module nodes in the business test knowledge graph and code element nodes in the code knowledge graph, the execution subject of this application embodiment can determine the association probability value between functional module nodes in the business test knowledge graph and code elements in the code knowledge graph (hereinafter referred to as "first association probability" for ease of distinction).

[0135] As an optional implementation, multiple combinations of functional module nodes in the business test knowledge graph and code element nodes in the code knowledge graph can be determined first. Each combination may include a functional module node and a code element node.

[0136] For example, suppose the business test knowledge graph includes two nodes: Functional Module 1 and Functional Module 2, and the code knowledge graph includes three nodes: Code Element 1, Code Element 2, and Code Element 3. Then, by pairing functional module nodes and code element nodes, the possible combinations include: {Functional Module 1 node, Code Element 1 node}, {Functional Module 1 node, Code Element 2 node}, {Functional Module 1 node, Code Element 3 node}, {Functional Module 2 node, Code Element 1 node}, {Functional Module 2 node, Code Element 2 node}, and {Functional Module 2 node, Code Element 3 node}.

[0137] Based on this, the following processing can be performed on any set of functional module nodes and code element nodes: First, the functional module nodes and code element nodes are encoded using a graph neural network (GNN) to generate the first feature vector of the functional module nodes and the second feature vector of the code element nodes.

[0138] The aforementioned graph neural network can be used to learn the structural and semantic features of the graph. Therefore, for functional module nodes in the business test knowledge graph, the graph neural network can encode the functional module nodes by learning the dependencies between them, generating a first feature vector containing structural and semantic features. For code element nodes in the code knowledge graph, the graph neural network can transform each code element node (such as the "PaymentService.pay() method") into a second feature vector containing technical features by learning features such as "class and method inclusion relationship", "method call chain", and "numerical features of code attributes" (such as risk level and change frequency).

[0139] Subsequently, the similarity between the first and second feature vectors can be calculated using a cross-graph attention mechanism. Since the "functional modules" of the business testing knowledge graph and the "code elements" of the code knowledge graph are essentially a correspondence between "business requirements" and "technical implementations" (e.g., "payment process" corresponds to the "PaymentService class"), the graph neural network can calculate the similarity between the feature vectors of two graph nodes using the "cross-graph attention mechanism." For example, the feature vector of the "payment process" module will be compared with the feature vectors of code nodes such as the "PaymentService class" and the "PayApiController method." The higher the attention weight, the stronger the semantic connection between the two (i.e., "this code element is the core of implementing this business function"). This comparison not only relies on the attributes of the nodes themselves (e.g., matching the keyword "payment"), but also takes into account the overall structure of the graph (e.g., "payment process" depends on "order query," while "PaymentService" calls "OrderDAO," and this structural correspondence strengthens the association weight).

[0140] Finally, based on the above similarity, the first association probability between functional module nodes and code element nodes can be determined.

[0141] Optionally, the above similarity can be determined as the first association probability between functional module nodes and code element nodes.

[0142] Step 602: Determine the second association probability between test case nodes in the business test knowledge graph and code element nodes in the code knowledge graph.

[0143] The aforementioned test case nodes refer to the nodes corresponding to the test cases of the functional modules included in the business test knowledge graph.

[0144] The aforementioned second association probability is a quantitative indicator used to measure the likelihood of a relationship between test case nodes in the business test knowledge graph and code element nodes in the code knowledge graph.

[0145] In practical applications, test cases in the business test knowledge graph are used to test functional modules, while code elements in the code knowledge graph are used to implement functional modules. There is a certain relationship between test cases and code elements, that is, test cases can cover the code elements of the corresponding functional modules.

[0146] Based on this, in order to determine the association between test case nodes and code element nodes in the business test knowledge graph, the execution subject of this application embodiment can determine the association probability between test case nodes in the business test knowledge graph and code element nodes in the code knowledge graph (hereinafter referred to as "second association probability" for easy distinction).

[0147] As an optional implementation, multiple combinations of test case nodes in the business test knowledge graph and code element nodes in the code knowledge graph can be determined first. Each combination may include a test case node and a code element node.

[0148] For example, suppose the business test knowledge graph includes test case 1 node and test case 2 node, and the code knowledge graph includes code element 1 node, code element 2 node, and code element 3 node. Then, by combining test case nodes and code element nodes in pairs, the resulting combinations can include: {test case 1 node, code element 1 node}, {test case 1 node, code element 2 node}, {test case 1 node, code element 3 node}, {test case 2 node, code element 1 node}, {test case 2 node, code element 2 node}, and {test case 2 node, code element 3 node}.

[0149] Based on this, the following processing can be performed on any set of test case nodes and code element nodes: First, the test case nodes and code element nodes are encoded using a graph neural network to generate the third feature vector of the test case nodes and the second feature vector of the code element nodes.

[0150] The aforementioned graph neural network can be used to learn the structural and semantic features of the graph. Therefore, for test case nodes in the business test knowledge graph, the graph neural network can encode the test case nodes by learning the coverage relationship between the test case nodes and functional nodes, generating a third feature vector containing structural and semantic features. For code element nodes in the code knowledge graph, the graph neural network can transform each code element node (such as the "PaymentService.pay() method") into a second feature vector containing technical features by learning features such as "class and method inclusion relationship", "method call chain", and "numerical features of code attributes" (such as risk level and change frequency).

[0151] Next, the coverage relationship between test case nodes and functional module nodes in the business test knowledge graph can be obtained, as well as the first association probability between functional module nodes and code element nodes. The coverage relationship and the first association probability are parameters already determined in the above process and can be directly obtained, so they will not be elaborated upon here.

[0152] Then, based on the aforementioned coverage relationship and the first association probability, the similarity between the third feature and the second feature vector can be calculated through a cross-graph attention mechanism.

[0153] In this step, since the test case nodes and code element nodes are indirectly associated through functional module nodes, the graph neural network can refer to the coverage relationship between the test case nodes and functional module nodes, as well as the first association probability between functional module nodes and code element nodes, when determining the similarity between the third feature vector and the second feature vector. It then uses a cross-graph attention mechanism to calculate the similarity between the third feature vector and the second feature vector. For example, the association probability between the "Payment Process" module and the "PaymentService class" might reach 0.9 (strong association); the association probability between the "User Login" test case and the "LoginController.check() method" might reach 0.85 (strong association), while the association probability with the "OrderService class" might only be 0.1 (weak association).

[0154] Finally, based on the above similarity, the second association probability between test case nodes and code element nodes can be determined.

[0155] Optionally, the above similarity can be determined as a second association probability between test case nodes and code element nodes.

[0156] Step 603: Determine the association relationship between the functional module node and the code element node based on the first association probability, and determine the association relationship between the test case node and the code element node based on the second association probability.

[0157] Step 604: Use the first association probability as the edge weight between the functional module node and the code element node that have an association relationship, and use the second association probability as the edge weight between the test case node and the code element node that have an association relationship.

[0158] Step 605: Integrate the relationships between functional module nodes and code element nodes, the relationships between test case nodes and code element nodes, and the coverage relationships between functional module nodes and test case nodes to form a composite knowledge graph containing the association paths of test cases to the corresponding implemented code elements through functional modules.

[0159] The following provides a unified explanation of steps 603 and 605: In this embodiment, after determining the association probability between any two of the functional module node, test case node, and code element node, the association relationship between the functional module node and the code element node is determined based on the first association probability, and the association relationship between the test case node and the code element node is determined based on the second association probability. The first association probability is used as the edge weight between the functional module node and the code element node that have an association relationship, and the second association probability is used as the edge weight between the test case node and the code element node that have an association relationship (in a knowledge graph, there is an edge between two nodes that have an association relationship). In specific implementation, a threshold mechanism can be adopted to determine whether there is an association relationship between the functional module node and the code element node based on the first association probability (for example, if the first association probability exceeds a predetermined threshold, it is considered that there is an association relationship, otherwise it is considered that there is no association relationship), and to determine whether there is an association relationship between the test case node and the code element node based on the second association probability (for example, if the second association probability exceeds a predetermined threshold, it is considered that there is an association relationship, otherwise it is considered that there is no association relationship).

[0160] Then, the relationships between functional module nodes and code element nodes, the relationships between test case nodes and code element nodes, and the coverage relationships between functional module nodes and test case nodes can be integrated to form a composite knowledge graph containing the association paths of test cases to the corresponding implemented code elements through functional modules. That is, in this composite knowledge graph, test case nodes can be associated to the corresponding implemented code elements through functional module nodes.

[0161] The technical solution provided in this application determines a first association probability between functional module nodes in the business test knowledge graph and code element nodes in the code knowledge graph, and a second association probability between test case nodes in the business test knowledge graph and code element nodes in the code knowledge graph. The association relationship between functional module nodes and code element nodes is determined based on the first association probability, and the association relationship between test case nodes and code element nodes is determined based on the second association probability. The first association probability is used as the edge weight between functional module nodes and code element nodes with an association relationship, and the second association probability is used as the edge weight between test case nodes and code element nodes with an association relationship. The association relationships between functional module nodes and code element nodes, test case nodes and code element nodes, and the coverage relationship between functional module nodes and test case nodes are integrated to form a composite knowledge graph containing the association paths from test cases to the corresponding implemented code elements via functional modules. This technical solution deeply integrates business testing with code implementation during the construction of a composite knowledge graph. On one hand, by using quantified association probabilities (first and second association probabilities) as edge weights, it achieves a precise mapping between business functions, test cases, and code elements, intuitively displaying test coverage paths and facilitating the rapid identification of test blind spots and high-risk code. On the other hand, the integrated composite knowledge graph connects the data links between the business and technical layers, automatically inferring affected functional modules and test cases when code changes occur, supporting intelligent adjustments to test strategies, and providing a panoramic view for test case optimization and defect root cause analysis, thereby improving testing efficiency and quality and reducing cross-team collaboration costs.

[0162] This concludes the explanation of the knowledge graph construction method for supporting test case recommendation provided in this application. The following specific embodiments further illustrate the test case recommendation method provided in this application; however, these embodiments do not constitute a limitation on the present invention.

[0163] See Figure 7 The above is a flowchart of an embodiment of a test case recommendation method provided in this application. Figure 7 The process shown is in Figure 1 , Figure 2 , Figure 4 ,or Figure 6 Based on the composite knowledge graph obtained from any of the illustrated processes, a description is provided of how test case recommendations are specifically performed. For example... Figure 7 As shown, the process may include the following steps: Step 701: In response to a code change event to the source code, obtain information about the code change.

[0164] The aforementioned code change event refers to an event in which changes occur to the code or code information (such as the attribute information of the code) in the source code. Such code change events may include, but are not limited to: adding code or code information, deleting code or code information, and modifying code or code information.

[0165] The above code change information can be used to characterize the code (e.g., a line or several lines of code within a code element) or code element that has been changed in connection with the above code change event.

[0166] In one embodiment, when a technician updates the application's source code, the executing entity of this application embodiment can respond to the code change event and determine the changed code or change code information. Then, based on the changed code or change code information, the code element to which the changed code or change code information belongs can be determined, and that code element can be identified as the current code change information.

[0167] In another embodiment, when a technician updates the application's source code, the executing entity of this application embodiment can respond to the code change event and determine the changed code or change code information. Then, the changed code or change code information can be identified as the current code change information.

[0168] Step 702: Based on the above code change information and the composite knowledge graph, determine the target code elements affected by the code change event.

[0169] The aforementioned composite knowledge graph refers to... Figure 1 , Figure 2 , Figure 4 ,or Figure 6 The composite knowledge graph obtained by any of the illustrated processes may include the functional modules of the project (or application) before it was updated, test cases, and code elements included in the source code.

[0170] The aforementioned target code elements refer to the target code elements affected by this code change event. The term "affected" here is broad, encompassing both the changed code element and the code elements affected by the changed code element. For example, if the code element "PaymentService" calls the code element "OrderDAO," meaning there is a dependency between them, then when the code within the code element "PaymentService" changes, both "PaymentService" and "OrderDAO" become affected target code elements.

[0171] In this step, when a code change event occurs in the source code, the execution entity of this application embodiment can, in advance, [implement a mechanism]... Figure 1 , Figure 2 , Figure 4 ,or Figure 6 The process shown constructs a composite knowledge graph that includes the project's functional modules, test cases, code elements, and the relationships between them. Therefore, the execution entity of this application embodiment can determine the target code element affected by the code change event based on the code change information corresponding to the code change event and the composite knowledge graph.

[0172] As an optional implementation, when the code change information represents the code that has changed, the target code element to which the code change information belongs can be determined first, and then the target code element affected by the code change event can be determined based on the target code element and the composite knowledge graph.

[0173] As an alternative implementation, if the code change information represents a changed code element, then that code element can be identified as the target code element. Subsequently, the target code elements affected by the code change event can be determined based on the target code element and the composite knowledge graph.

[0174] As an optional implementation, if the code change event is a new code element event, the new code element indicated by the code change information can be determined first.

[0175] Subsequently, since the newly added code element is not included in the current composite knowledge graph, the initial target code element that has a dependency relationship with the newly added code element can be obtained from the source code based on the newly added code element.

[0176] Subsequently, in order to further accurately determine the target code elements affected by the code change event, the execution subject of this application embodiment can determine the code elements that have a dependency relationship with the initial target code elements from the composite knowledge graph based on the initial target code elements.

[0177] Finally, the initial target code element and the code elements that have dependencies on the initial target code element can be identified together as target code elements affected by the code change event.

[0178] As an alternative implementation, if the code change event does not involve adding new code elements, since the composite knowledge graph already contains all code elements from the source code, to save time, the code elements that depend on the code element indicated by the code change information can be directly identified from the composite knowledge graph. Then, the code element indicated by the code change information and the code elements that depend on it, identified from the composite knowledge graph, can be combined as the target code element affected by the code change event.

[0179] Step 703: From the above composite knowledge graph, find the target functional module node that has a path associated with the target code element, and from the composite knowledge graph, find the test case node that has a path associated with the target functional module node.

[0180] In one embodiment, since code elements are the technical implementation methods of functional modules at the technical level, when the executing entity of this application determines the target code element corresponding to the code change event, it can search for the target functional module node that has an associated path with the target code element from the aforementioned composite knowledge graph. The aforementioned associated path can be the connecting edge between the target code element node and the target functional module node in the composite knowledge graph.

[0181] As an optional implementation method, through Figure 6 As shown in the process, when constructing a composite knowledge graph, the first association probability between each group of functional module nodes and code element nodes is determined, and the association path between the two is constructed using the first association probability as the weight of the edge.

[0182] Based on this, in order to find target functional module nodes that are strongly associated with the target code element, the execution entity of this application embodiment can search for functional module nodes in the above-mentioned composite knowledge graph that satisfy a first set condition regarding the first association probability with the target code element, and determine the functional module node as a target functional module node with an association path with the target code element. The first set condition may be that the first association probability is greater than or equal to a preset probability threshold (e.g., 0.8).

[0183] In one embodiment, based on the target functional module node determined above, the execution entity of this application embodiment can search for test case nodes that have an associated path with the target functional module node from the above composite knowledge graph.

[0184] As an optional implementation method, through Figure 2As shown in the process, when constructing a business test knowledge graph, test cases with coverage relationships and their corresponding functional modules can be directly linked to form an association path. Based on this, when the execution entity of this application determines the test case node that has an association path with the target functional module node, it can search for the test case node with an association path with the target functional module node from the above-mentioned composite knowledge graph for each target functional node.

[0185] Step 704: Determine the target test cases to be recommended based on the test case nodes found from the composite knowledge graph.

[0186] In this step, when the execution entity of this application recommends test cases, it can determine the target test cases to be recommended based on the test case nodes found from the composite knowledge graph in the above steps.

[0187] As an optional implementation method, through Figure 2 As shown in the process, when constructing the business test knowledge graph, a priority label can be set for each functional module node as an attribute of that functional module. The above composite knowledge graph is directly constructed based on the business test knowledge graph. Therefore, all functional module nodes contained in the above composite knowledge graph have a corresponding priority label.

[0188] Based on this, when determining the target test cases to be recommended according to the test case nodes found in the composite knowledge graph, it can be determined whether the priority label of each target functional module node corresponding to the aforementioned test case node meets the second preset condition. The aforementioned second preset condition can be used to characterize the target functional module node as having a higher priority, that is, the priority label is a preset identifier indicating a priority greater than a preset priority.

[0189] Optionally, for each target functional module node, if the priority label of the target functional module node meets the above-mentioned second setting condition, it indicates that the target functional module is very important in the operation of the application. Therefore, in order to further ensure accurate testing of the target functional module, the execution subject of this application embodiment can determine all the test case nodes corresponding to the target functional module node found from the composite knowledge graph as target test cases to be recommended. That is, it is recommended to test all the test cases found.

[0190] Optionally, for each target functional module node, if it is determined that the priority label of the target functional module node does not meet the second setting condition mentioned above, it indicates that the target functional module node is not an important functional module node and does not need to be tested in detail. Therefore, some test case nodes can be selected from the multiple test case nodes found as target test cases.

[0191] As an exemplary implementation method, through Figure 4 As shown in the process, when constructing a code knowledge graph, each code element node can have a code risk assessment value as an attribute. Figure 6 As shown in the process, when constructing a composite knowledge graph, a second association probability between code element nodes and test case nodes can be determined based on the business test knowledge graph and the code knowledge graph, and this second association probability can be used as the weight value of the association path between the two.

[0192] Based on this, the execution entity of this application embodiment can sort the test case nodes found in the above-mentioned composite knowledge graph according to the code risk assessment value of the determined target code element and the second association probability between the target code element and the test case node.

[0193] As an exemplary implementation, for each found test case node, the target code risk assessment value of the target code element with an associated path to that test case node, and the target second association probability between the two can be determined. Then, the target code risk assessment value and the target second association probability can be weighted and summed according to a pre-set weight value to obtain the recommended score for that test case node. Where there are multiple target code risk assessment values, the average or maximum value of the multiple target code risk assessment values ​​can be determined as the final target code risk assessment value; where there are multiple target second association probabilities, the average or maximum value of the multiple target second association probabilities can be determined as the final target second association probability.

[0194] Then, the test case nodes can be sorted according to the recommended score of each found test case node in a preset order to obtain a test case node sequence. The preset order can be from smallest to largest or from largest to smallest, and this embodiment of the application does not limit it.

[0195] Finally, based on the above ranking results, target test cases to be recommended can be selected from the test case nodes found in the composite knowledge graph.

[0196] As an optional implementation, if the above sorting results are arranged in descending order of recommended scores, the first N test cases in the test case sequence can be selected as the target test cases to be recommended. N is a positive integer.

[0197] As an alternative implementation, if the above sorting results are arranged in ascending order of recommended scores, the last N test cases in the test case sequence can be selected as the target test cases to be recommended.

[0198] Furthermore, in one embodiment, after recommending target test cases, the executing entity of this application embodiment may, in response to the code change event, modify the aforementioned... Figure 1 , Figure 2 , Figure 4 ,as well as Figure 6 The process outlined herein involves updating the business test knowledge graph and / or code knowledge graph, as well as the composite knowledge graph. For detailed update procedures, please refer to [reference needed]. Figure 1 The process shown is not repeated here.

[0199] The technical solution provided in this application, in response to a code change event in the source code, obtains the code change information, identifies the target code element affected by the code change event based on the code change information and a composite knowledge graph, searches for target functional module nodes with associated paths to the target code element in the composite knowledge graph, and searches for test case nodes with associated paths to the target functional module nodes in the composite knowledge graph. Based on the test case nodes found in the composite knowledge graph, the target test cases to be recommended are determined. This technical solution, by responding to a code change event, accurately locates the affected target code element using a composite knowledge graph, and traces the associated target functional modules and test cases to ultimately determine the target test cases to be recommended, achieves automated and precise tracking of the impact of code changes. This process not only eliminates the tedious steps of manually sorting out the scope of change impact, greatly improving test preparation efficiency, but also avoids insufficient testing due to human oversight, ensuring that the changed code is effectively verified in relevant functional scenarios, thereby reducing the risk of software defects and ensuring the stability and reliability of system iteration.

[0200] See Figure 8 This is a flowchart illustrating an embodiment of a knowledge graph construction and test case recommendation method that supports test case recommendation, provided in this application. Figure 8 As shown, the process may include the following steps: Step 801: Parse historical test case data and construct a business test knowledge graph. The business test knowledge graph uses functional modules and test cases extracted from historical test case data as nodes, and establishes the coverage relationship between test cases and functional modules.

[0201] Step 802: Parse the source code and the program execution data of the source code, construct a code knowledge graph, in which code elements extracted from the source code are used as nodes, and the dependency relationships between code elements are established.

[0202] Step 803: Based on the above business test knowledge graph and code knowledge graph, construct a composite knowledge graph. The composite knowledge graph contains the association paths of test case nodes to the corresponding code element nodes through functional module nodes.

[0203] For a detailed description of steps 801 to 803, please refer to the descriptions in steps 101 to 103, which will not be repeated here.

[0204] Step 804: In response to the code change event to the source code, obtain the code change information.

[0205] Step 805: Based on the above code change information and the composite knowledge graph, determine the target code elements affected by the code change event.

[0206] Step 806: From the above composite knowledge graph, find the target functional module node that has a path associated with the target code element, and from the composite knowledge graph, find the test case node that has a path associated with the target functional module node.

[0207] Step 807: Determine the target test cases to be recommended based on the test case nodes found in the composite knowledge graph.

[0208] For a detailed description of steps 804 to 807, please refer to the descriptions in steps 701 to 704, which will not be repeated here.

[0209] The technical solution provided in this application, through the construction of a three-level system of business test knowledge graph, code knowledge graph, and composite knowledge graph, achieves full-link association from business functions to code implementation, and automatically derives affected test cases when code changes. On the one hand, through the structured expression of the knowledge graph, scattered test cases, functional modules, and code elements are integrated into an organic whole, clearly showing the mapping relationship between business and technology; on the other hand, based on the intelligent recommendation mechanism of the composite knowledge graph, the test cases to be executed are accurately located when code changes, greatly reducing the cost of manual analysis, improving testing efficiency and coverage, ensuring that the impact of changes is fully verified, and ultimately improving software quality and iteration speed.

[0210] See Figure 9 This is a block diagram of an embodiment of a knowledge graph construction device that supports test case recommendation, provided in this application. Figure 9 As shown, the device may include: The business test graph construction module 91 is used to parse historical test case data and construct a business test knowledge graph. The business test knowledge graph uses functional modules and test cases extracted from the historical test case data as nodes and establishes the coverage relationship between test cases and functional modules. The code graph construction module 92 is used to parse the source code and the program execution data of the source code, construct a code knowledge graph, wherein the code knowledge graph uses code elements extracted from the source code as nodes and establishes dependencies between code elements; The graph integration module 93 is used to construct a composite knowledge graph based on the business test knowledge graph and the code knowledge graph. The composite knowledge graph contains the association path of test case nodes to the corresponding code element nodes through functional module nodes.

[0211] See Figure 10 This is a block diagram illustrating an embodiment of a test case recommendation device provided in this application. Figure 10 As shown, the device may include: The code change recognition module 1001 is used to obtain code change information in response to code change events to the source code; The target code element determination module 1002 is used to determine the target code elements affected by the code change event based on the current code change information and the obtained composite knowledge graph. The graph query module 1003 is used to search for target functional module nodes that have an associated path with the target code element from the composite knowledge graph, and to search for test case nodes that have an associated path with the target functional module nodes from the composite knowledge graph. The test case recommendation module 1004 is used to determine the target test cases to be recommended based on the test case nodes found from the composite knowledge graph.

[0212] like Figure 11 As shown in the diagram, this application provides a schematic diagram of the structure of an electronic device, including a processor 111, a communication interface 112, a memory 113, and a communication bus 114. The processor 111, communication interface 112, and memory 113 communicate with each other via the communication bus 114. Memory 113 is used to store computer programs; In one embodiment of this application, when the processor 111 executes the program stored in the memory 113, it implements the knowledge graph construction method supporting test case recommendations provided in any of the foregoing method embodiments, including: Analyze historical test case data to construct a business test knowledge graph. The business test knowledge graph uses functional modules and test cases extracted from the historical test case data as nodes, and establishes the coverage relationship between test cases and functional modules. The source code and its program execution data are parsed to construct a code knowledge graph, in which code elements extracted from the source code are used as nodes, and dependencies between code elements are established. Based on the business test knowledge graph and the code knowledge graph, a composite knowledge graph is constructed. The composite knowledge graph contains the association paths of test cases to the corresponding code elements implemented through functional modules.

[0213] In another embodiment of this application, when the processor 111 executes the program stored in the memory 113, it implements the test case recommendation method provided in any of the foregoing method embodiments, including: In response to code change events affecting the source code, obtain information about the code change. Based on the aforementioned code change information and any of the aforementioned knowledge graph construction methods that support test case recommendations, the composite knowledge graph obtained determines the target code elements affected by the code change event; From the composite knowledge graph, find the target functional module node that has a path associated with the target code element, and from the composite knowledge graph, find the test case node that has a path associated with the target functional module node; Based on the test case nodes found from the composite knowledge graph, the target test cases to be recommended are determined.

[0214] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the knowledge graph construction method or test case recommendation method supporting test case recommendation provided in any of the foregoing method embodiments.

[0215] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0216] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0217] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0218] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A knowledge graph construction method that supports test case recommendation, characterized in that, The method includes: Analyze historical test case data to construct a business test knowledge graph. The business test knowledge graph uses functional modules and test cases extracted from the historical test case data as nodes, and establishes the coverage relationship between test cases and functional modules. The source code and its program execution data are parsed to construct a code knowledge graph, in which code elements extracted from the source code are used as nodes, and dependencies between code elements are established. Based on the business test knowledge graph and the code knowledge graph, a composite knowledge graph is constructed. The composite knowledge graph contains the association paths of test case nodes to the corresponding code element nodes through functional module nodes.

2. The method according to claim 1, characterized in that, The process of parsing historical test case data and constructing a business test knowledge graph includes: Analyze historical test case data, extract the functional modules corresponding to the test cases, and determine the priority tags of the functional modules; Establish the coverage relationship between test cases and their corresponding functional modules; A graph structure is constructed using the functional modules and test cases as nodes and the coverage relationships as edges. The priority tags are used as attributes of the functional module nodes to form a business test knowledge graph.

3. The method according to claim 2, characterized in that, The determination of the priority label of the functional module includes: Analyze historical test case data to obtain the historical test execution frequency and defect correlation value of the functional module; The priority label of the functional module is determined by weighting the historical test execution frequency value, defect correlation value, and predefined priority score value of the functional module.

4. The method according to claim 1, characterized in that, The process of parsing the source code and its program execution data to construct a code knowledge graph includes: Parse the source code and its program execution data, and extract the code elements and dependencies between them. Determine the code risk assessment value of the code element; A graph structure is constructed using the code elements as nodes and the dependencies as edges, and the code risk assessment value is used as an attribute of the code element nodes to form a code knowledge graph.

5. The method according to claim 4, characterized in that, Determining the code risk assessment value of the code element includes: The program execution data of the source code is analyzed to obtain the risk level score, historical change frequency value, and defect density value of the code elements; The code risk assessment value of the code element is obtained by weighting the risk level score, historical change frequency value, and defect density value of the code element.

6. The method according to claim 1, characterized in that, The step of constructing a composite knowledge graph based on the business test knowledge graph and the code knowledge graph includes: Determine the first association probability between the functional module nodes in the business test knowledge graph and the code element nodes in the code knowledge graph; Determine the second association probability between test case nodes in the business test knowledge graph and code element nodes in the code knowledge graph; The association between the functional module node and the code element node is determined based on the first association probability, and the association between the test case node and the code element node is determined based on the second association probability. The first association probability is used as the edge weight between the functional module node and the code element node that have an association relationship, and the second association probability is used as the edge weight between the test case node and the code element node that have an association relationship. Based on the association relationships between the functional module nodes and the code element nodes, the association relationships between the test case nodes and the code element nodes, and the coverage relationships between the functional module nodes and the test case nodes, a composite knowledge graph is formed that includes the association paths of test cases to the corresponding implemented code elements through the functional modules.

7. The method according to claim 6, characterized in that, Determining the first association probability between functional module nodes in the business test knowledge graph and code element nodes in the code knowledge graph includes: For any set of functional module nodes and code element nodes, perform the following processing: The functional module nodes and the code element nodes are encoded using a graph neural network to generate a first feature vector for the functional module nodes and a second feature vector for the code element nodes. The similarity between the first feature vector and the second feature vector is calculated using a cross-graph attention mechanism; Based on the similarity, a first association probability between the functional module node and the code element node is determined.

8. The method according to claim 6, characterized in that, Determining the second association probability between test case nodes in the business test knowledge graph and code element nodes in the code knowledge graph includes: For any set of test case nodes and code element nodes, perform the following processing: The test case node and the code element node are encoded using a graph neural network to generate the third feature vector of the test case node and the second feature vector of the code element node. Obtain the coverage relationship between the test case node and the functional module node in the business test knowledge graph, as well as the first association probability between the functional module node and the code element node; Based on the coverage relationship and the first association probability, the similarity between the third feature vector and the second feature vector is calculated through a cross-graph attention mechanism; Based on the similarity, a second association probability between the test case node and the code element node is determined.

9. The method according to claim 1, characterized in that, The method further includes: In response to a specific event, update the business test knowledge graph and / or the code knowledge graph, as well as update the composite knowledge graph.

10. A test case recommendation method, characterized in that, The method includes: In response to code change events affecting the source code, obtain information about the code change. Based on the code change information and the composite knowledge graph obtained by the method of any one of claims 1-9, the target code elements affected by the code change event are determined; From the composite knowledge graph, find the target functional module node that has a path associated with the target code element, and from the composite knowledge graph, find the test case node that has a path associated with the target functional module node; Based on the test case nodes found from the composite knowledge graph, the target test cases to be recommended are determined.

11. The method according to claim 10, characterized in that, The step of searching for target functional module nodes that have a path associated with the target code element from the composite knowledge graph includes: From the composite knowledge graph, find the functional module nodes whose first association probability with the target code element satisfies the first set condition, and determine them as target functional module nodes that have an association path with the target code element.

12. The method according to claim 10, characterized in that, The step of determining the target test cases to be recommended based on the test case nodes found from the composite knowledge graph includes: If the priority label of the target functional module node meets the second set condition, the test case node found from the composite knowledge graph will be determined as the target test case to be recommended. If the priority label of the target functional module node does not meet the second set condition, the test case nodes found from the composite knowledge graph are sorted according to the code risk assessment value of the target code element and the second association probability between the target code element and the test case node. Based on the ranking results, target test cases to be recommended are selected from the test case nodes found in the composite knowledge graph.

13. A knowledge graph construction device that supports test case recommendation, characterized in that, The device includes: The business test graph construction module is used to parse historical test case data and construct a business test knowledge graph. The business test knowledge graph uses functional modules and test cases extracted from the historical test case data as nodes and establishes the coverage relationship between test cases and functional modules. The code graph construction module is used to parse the source code and the program execution data of the source code to construct a code knowledge graph. The code knowledge graph uses code elements extracted from the source code as nodes and establishes dependencies between code elements. The graph integration module is used to construct a composite knowledge graph based on the business test knowledge graph and the code knowledge graph. The composite knowledge graph contains the association paths of test case nodes to the corresponding code element nodes through functional module nodes.

14. A test case recommendation device, characterized in that, The device includes: The code change identification module is used to obtain information about the code change in response to code change events to the source code; The target code element determination module is used to determine the target code elements affected by the code change event based on the current code change information and the composite knowledge graph obtained by the method of any one of claims 1-9. The graph query module is used to find target functional module nodes that have an associated path with the target code element from the composite knowledge graph, and to find test case nodes that have an associated path with the target functional module nodes from the composite knowledge graph. The test case recommendation module is used to determine the target test cases to be recommended based on the test case nodes found from the composite knowledge graph.

15. An electronic device, characterized in that, include: A processor and a memory, the processor being configured to execute a knowledge graph construction program supporting test case recommendations stored in the memory to implement the knowledge graph construction program method supporting test case recommendations as described in any one of claims 1-9; or, to execute a test case recommendation program stored in the memory to implement the test case recommendation method as described in any one of claims 10-12.

16. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the knowledge graph construction program method supporting test case recommendation as described in any one of claims 1-9; or to implement the test case recommendation method as described in any one of claims 10-12.

Images