Test case generation method and computer device

Abstract

This application discloses a method and computer device for generating test cases. The method includes: acquiring a code change file; determining front-end and back-end change data based on the code change file; acquiring a code knowledge graph, which includes multiple call chains; calculating the total score of all call chains; determining a target call chain based on the total score of all call chains; and inputting the target call chain and the front-end and back-end change data into a large language model to generate test cases. This application uses code changes as trigger points to accurately locate the functionalities involved in the code modification. With the help of the code knowledge graph, multiple call chains containing the changed functions can be quickly obtained. The target call chain is filtered by the total score of each call chain, focusing on high-priority test chains, reducing the scope of invalid tests, lowering testing costs, and improving testing efficiency.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a method for generating test cases and a computer device. Background Technology

[0002] The rapid iteration speed of existing software means that code changes resulting from these iterations have a significant impact on both the front-end and back-end. Therefore, accurate testing is crucial for ensuring system stability. However, related technologies often struggle to capture the actual scope of impact, business context, and operational processes associated with software iterations. This leads to test cases generated by these technologies being disconnected from actual business needs, failing to cover all the testing requirements of the real business. Consequently, the accuracy of test cases generated by these technologies is poor. Summary of the Invention

[0003] One objective of this application is to provide a method and computer device for generating test cases, thereby improving the poor accuracy of test cases in related technologies.

[0004] In a first aspect, embodiments of this application provide a method for generating test cases, comprising: acquiring code change files; determining front-end and back-end change data based on the code change files, the front-end and back-end change data including a set of changed functions, the set of changed functions being a collection of functional functions that have changed on the front-end and on the back-end; acquiring a code knowledge graph, the code knowledge graph including multiple call chains, each call chain representing the function call relationship generated between the front-end and back-end by a triggering event; acquiring test requirement information; determining a requirement matching score corresponding to the call chain based on the test requirement information, the requirement matching score reflecting the degree of matching between the functional description information of the call chain and the test requirement information; determining a total score for the call chain based on the content matching score and the requirement matching score of the call chain; selecting call chains that meet preset filtering conditions as target call chains based on the total score of all call chains; and inputting the target call chains and the front-end and back-end change data into a pre-trained large language model, so that the large language model performs a test case generation operation to obtain test cases.

[0005] In a second aspect, embodiments of this application provide a computer device, a memory, and a processor. The memory is connected to the processor, and the processor is configured to execute one or more computer programs stored in the memory. When the processor executes one or more computer programs, it causes the computer device to implement the above-described method for generating test cases.

[0006] The embodiments of this application can achieve the following technical effects: First, by using code changes as the trigger point and obtaining the code change files and determining the set of changed functions, the embodiments of this application can accurately locate the functional functions involved in the code modification, providing accurate analysis objects for subsequent analysis of the scope of impact of the change. Second, by leveraging a pre-built code knowledge graph, the embodiments of this application can quickly obtain multiple call chains containing the changed functions, achieving automated identification of the scope of impact of code changes and avoiding the inefficiency and omissions caused by manually sorting out call relationships. Third, by using content matching operations, the embodiments of this application quantify the correlation between call chains and changed functions, filter out the core call chains affected by the change, reduce interference from irrelevant links, improve screening efficiency, and by introducing test requirement information and calculating requirement matching scores, filter highly relevant call chains from a business perspective, so that the target call chains simultaneously meet technical impact and business requirements, improving screening accuracy. At the same time, by combining the content matching score and the requirement matching score to obtain a total score, a multi-dimensional comprehensive evaluation is achieved, taking into account both the intensity of the change's impact and business relevance, resulting in more reasonable screening results. Finally, the target call chains are filtered based on the total score, focusing on high-priority test links, reducing the scope of invalid tests, lowering testing costs, and improving testing efficiency. Finally, this embodiment utilizes a large language model to process the target call chain and front-end / back-end change data, enabling automated generation of test cases. This significantly reduces the cost of manually writing test cases and improves testing efficiency. Overall, this embodiment can quickly respond to iterative development needs, ensure a high degree of matching between test cases and code changes, and improve test coverage and the accuracy of test case generation. Attached Figure Description

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

[0008] Figure 1 A flowchart illustrating a method for generating test cases provided in an embodiment of this application; Figure 2 A flowchart illustrating the extraction of modified code, matching of source code libraries, and searching of source files provided in the embodiments of this application; Figure 3 This is a schematic diagram illustrating a code example where the event handling function name and the front-end method body are mutually mapped, as provided in the embodiments of this application. Figure 4 This is a schematic diagram illustrating the effect of the Vue parser provided in this embodiment of the application parsing the front-end source code; Figure 5This is a schematic diagram of Swagger annotation information provided in the embodiments of this application; Figure 6 A schematic diagram showing Swagger annotation information and Spring MVC annotation information provided for an embodiment of this application; Figure 7 This is a schematic diagram illustrating method call tracing provided in an embodiment of this application; Figure 8 This is a schematic diagram illustrating the effect of the Java parser provided in this embodiment of the application parsing the backend source code; Figure 9 A schematic diagram of the structure of a test case generation device provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0009] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0010] It should be noted that, unless there is a conflict, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than the module division in the device or the order in the flowchart. Moreover, the terms "first," "second," and "third" used in this application do not limit the data or execution order, but only distinguish identical or similar items with essentially the same function and effect.

[0011] With the rapid development of artificial intelligence (AI) technology, using AI models to generate test cases to improve the efficiency of testers has become a popular trend in the software testing field. However, current AI model-based test case generation technology still has many shortcomings and struggles to meet the actual needs of iterative software testing.

[0012] First, existing AI models rely heavily on requirements documents to generate test cases. When there are no requirements documents or the requirements documents are not clearly defined, the AI ​​models lack effective information to rely on and cannot generate accurate and realistic test cases.

[0013] Secondly, even with requirements documents, AI models struggle to grasp the actual impact, business background, and complete operational process of the requirements, resulting in isolated test cases that cannot be deeply integrated with the actual business processes of the software, leading to poor usability.

[0014] Furthermore, the pace of software iteration is constantly accelerating, while traditional manual test case writing is time-consuming, and existing AI model generation solutions cannot quickly adapt to code changes, making it difficult to respond quickly to the software iteration rhythm and complete test coverage in a timely manner.

[0015] The inventors also discovered that when software code changes, the front-end and back-end code parsing of related technologies are independent, making it difficult to construct a complete end-to-end call chain. This results in an inability to accurately pinpoint the full-chain impact scope corresponding to the code change. Back-end parsing also frequently faces problems such as ambiguous class names, difficulties in parsing complex expressions, and incorrect import statement matching, leading to inaccurate identification of method call relationships and further affecting the accuracy of test cases.

[0016] Therefore, the test case generation method provided in this application can break free from excessive reliance on requirement documents, accurately associate with business links, and quickly adapt to code changes. Furthermore, this application effectively utilizes code knowledge graphs, using code change files as driving points to automatically trace the complete business logic chain behind code changes. It leverages large language models to quickly filter out accurate, reliable, and business-logic-aligned target call chains, dynamically generating high-coverage, easily maintainable automated test cases. Ultimately, it achieves an automated closed loop from "code change" to "business understanding" to "test assurance," thereby meeting the dual requirements of testing efficiency and quality in software iteration scenarios.

[0017] The following embodiments of this application provide a method for generating test cases. Please refer to... Figure 1 In this embodiment of the application, test cases are generated through steps S11 to S19, as detailed below: Step S11: Obtain the code change file.

[0018] Code change files are files whose code has been modified. These include front-end change files and back-end change files. Front-end change files are those where front-end code has been modified, and back-end change files are those where back-end code has been modified.

[0019] In this embodiment of the application, the code change file is obtained through steps S111 to S114, as detailed below: Step S111: Obtain the code commit identifier.

[0020] Code commit identifiers are used to identify each code commit made by a developer. When developers submit code to the DevOps platform, they include a requirement number. The DevOps platform binds the code commit identifier (i.e., the commit ID) to the requirement number, thereby retrieving a list of commit IDs contained in the corresponding requirement, which serves as the input range for subsequent change analysis.

[0021] Step S112: Obtain multiple original change files from the preset code repository based on the code commit identifier.

[0022] The original change files are the files whose code changes occurred during this code commit. This embodiment generates a file retrieval command based on the code commit identifier and sends it to the code repository (e.g., a Git repository). This allows the code repository to filter out multiple original change files corresponding to the code commit identifier. In this embodiment, within a code repository containing both original change files and original unchanged files, multiple original change files are retrieved from the code repository using the characteristics of the original change files, and then stored locally.

[0023] In this embodiment, a `git diff` command is sent to the code repository based on the commit ID. The code repository responds to the `git diff` command, comparing the differences between the commit and its parent commit. The output includes the path information of the changed files. The output is parsed to extract the relative paths and file names of all changed files, generating a list of changed file paths.

[0024] In some embodiments, this application uses the full lifecycle information collected by the DevOps platform to copy the files and code of the code repository to the local machine for storage. Specifically, the full lifecycle information includes the latest branch information of the project development. Based on the latest branch information, this application switches to the branch where the code has been changed and copies the files and code of that branch to the local clone repository for storage. Then, it iterates through the list of changed file paths and reads the complete text content of each changed file in the local clone repository by path for subsequent analysis.

[0025] Thus, this embodiment of the application has obtained the physical file content and precise row and column number information of all changed files within the scope of this requirement, providing a high-quality data source for subsequent analysis tasks.

[0026] Step S113: Perform an invalid change file filtering operation on multiple original change files to obtain one or more valid change files.

[0027] Invalid change files are original change files that have no analytical value, while valid change files are original change files that have analytical value. This application embodiment can set multiple filtering conditions to filter out invalid change files from multiple original change files, thereby obtaining valuable and meaningful valid change files.

[0028] In some embodiments, the present application determines the total number of change code lines in the original change file. When the total number of change code lines is greater than a first line count threshold, the original change file is determined to meet the filtering conditions, and the original change file is set as an invalid change file and filtered out. When the total number of change code lines is less than a second line count threshold, the original change file is determined to meet the filtering conditions, and the original change file is set as an invalid change file and filtered out. When the total number of change code lines is between the second line count threshold and the first line count threshold, the original change file is set as a valid change file and retained.

[0029] When the total number of changed lines of code exceeds the first line threshold, the original change file contains too many changes and is likely to have no core business logic changes. Parsing it is time-consuming and inefficient. Filtering out the original change file can improve the parsing speed of valid change files in the later stages and avoid wasting resources.

[0030] When the total number of changed lines of code is less than the second line threshold, this is considered a minor change file, usually manifested as a change in punctuation marks. If only punctuation marks are modified without any substantial changes to functions, interfaces, or business logic, it provides no support for subsequent call chain construction and test case generation. Filtering the original change file can reduce redundant parsing operations.

[0031] In some embodiments, this application detects that the original modified file contains blank lines, determines that the original modified file meets the filtering conditions, and filters out the original modified file as an invalid modified file. Blank lines refer to original modified files containing no valid code content, only whitespace characters. Such original modified files have no parsing value; filtering them avoids invalid parsing and ensures that subsequent parsing focuses on valid code.

[0032] This application embodiment can eliminate redundant and invalid information from interfering with the parsing process by filtering out invalid change files, thereby improving the parsing efficiency of subsequent steps and ensuring the accuracy of the parsed data. This provides high-quality input data for subsequent code knowledge graph construction and test case generation.

[0033] Step S114: Based on preset naming characteristics, identify the front-end change file and the back-end change file from one or more valid change files.

[0034] Front-end files are typically named with prefixes like ".js" or ".vue". Back-end files are typically named with prefixes like ".java". This application utilizes the naming characteristics of both front-end and back-end files to set valid change files whose naming characteristics match those of the front-end files as front-end change files, and those whose naming characteristics match those of the back-end files as back-end change files.

[0035] This application embodiment utilizes code commit identifiers to reliably locate valid front-end and back-end change files in the code repository, providing a high-quality data foundation for subsequent end-to-end parsing and generation of test cases.

[0036] Step S12: Determine the front-end and back-end change data based on the code change file.

[0037] The front-end and back-end change data includes the change function set, front-end change data, and back-end change data. The change function set is a collection of functional functions that have undergone changes in the front-end and back-end. Front-end change data includes front-end code change information, corresponding API data, front-end pages, and trigger condition data. Back-end change data includes back-end code change information, corresponding API data, and the addresses of the back-end API calls.

[0038] In some embodiments, this application can determine front-end change data based on code change files. Specifically, determining front-end and back-end change data based on code change files includes the following steps: A1. When the code change file is the front-end change file, determine the front-end code change path based on the front-end change file.

[0039] The front-end code change path is the path to the modified code within the front-end change file. It is used to locate the changed code within the front-end change file. The front-end code change path consists of the file path of the front-end change file, the file name, and the line number where the code was modified.

[0040] A2, using the front-end code change path as the search condition, queries the code knowledge graph to see if the front-end code area corresponding to the front-end code change path is a script area.

[0041] The script area is in the front-end change file. <script>部分。本申请实施例结合前端代码变更路径，在代码知识图谱中查询与前端代码变更路径对应的变更位置是否属于前端变更文件的脚本区域(即<script>部分)。对于前端的文件，<script>部分是存放前端的功能函数、接口调用代码的核心区域，非<script>部分（如<template>模板区域或<style>样式区域）的变更，通常不涉及功能函数变更，无需进一步处理。

[0042] A3，响应于与前端代码变更路径对应的前端代码区域为脚本区域，在预设的本地克隆仓库中查找出与前端代码变更路径对应的前端代码区域。

[0043] 前端代码区域为本地克隆仓库中由前端代码变更路径定位的代码区域。本地克隆仓库与远程的代码仓库构成克隆关系，即代码仓库中与项目开发最新分支信息的代码和文件均已克隆在本地克隆仓库中，本申请实施例根据前端代码变更路径的文件路径和文件名称，在本地克隆仓库中查找出前端变更文件，然后再根据前端代码变更路径的代码发生变更的行号，在该前端变更文件中查找出前端代码区域。

[0044] A4，基于前端代码区域提取出前端变更数据及前端出现变更的功能函数。

[0045] 前端代码区域包含前端页面、前端发生变更的功能函数及调用该功能函数的接口数据、触发条件数据等。本申请实施例可以在前端代码区域进行语义分析，解析出前端页面、功能函数及调用该功能函数的接口数据、触发条件数据等，并将前端代码变更信息、前端页面、调用该功能函数的接口数据、触发条件数据等打包成前端变更数据。本申请实施例通过步骤A1至步骤A4，能够可靠准确地从本地克隆仓库中查找出前端变更数据及前端出现变更的功能函数，为后续代码解析步骤提供高质量的数据源。

[0046] 在一些实施例中，本申请实施例可以基于代码变更文件确定后端变更数据。具体的，基于代码变更文件确定后端变更数据包括以下步骤：B1，在代码变更文件为后端变更文件的情况下，基于后端变更文件确定后端代码变更路径。

[0047] 后端代码变更路径为后端变更文件中代码发生变更的代码路径，用于在后端变更文件中定位发生变更的代码。后端代码变更路径由后端变更文件的文件路径、文件名称及代码发生变更的行号组成。

[0048] B2，在预设的本地克隆仓库中查找出与后端代码变更路径对应的后端代码区域。

[0049] 本申请实施例根据后端代码变更路径的文件路径和文件名称，在本地克隆仓库中查找出后端变更文件，然后再根据后端代码变更路径的代码发生变更的行号，在该后端变更文件中查找出后端代码区域。

[0050] B3，基于后端代码区域提取出后端变更数据及后端出现变更的功能函数。

[0051] 后端代码区域包含后端发生变更的功能函数及调用该功能函数的接口数据、触发条件数据等。本申请实施例可以在后端代码区域进行语义分析，解析出功能函数及调用该功能函数的接口数据、触发条件数据等，并将后端代码变更信息、接口数据、触发条件数据等打包成后端变更数据。本申请实施例通过步骤B1至步骤B3，能够可靠准确地从本地克隆仓库中查找出后端变更数据及后端出现变更的功能函数，为后续代码解析步骤提供高质量的数据源。

[0052] 本申请实施例将前端发生变更的功能函数和后端发生变更的功能函数归纳成变更函数集。为了详细阐述变更函数集的获得过程，本申请实施例结合图2对此做出说明，具体如下：首先，本申请实施例基于Git Diff命令获得多个原始变更文件，即通过git diff+commit_id命令生成原始变更文件。

[0053] 其次，本申请实施例基于变更解析器(GitDiffParser)对原始变更文件进行解析，提取关键变更信息，为后续函数定位提供标准化输入，具体过程有：1）解析文件路径：识别差异块中以"+++”开头的行，提取其后紧跟的文件路径字符串（变更后的文件路径）。

[0054] 2）提取变更行号：解析以"@@”开头和结尾的行，提取变更块在源文件及新文件中的起止行号范围。

[0055] 3）提取新增行内容：遍历变更块内部，提取所有以"+”开头且非"+++”的行，记录其行号及代码文本。其中，以单个"+”字符开头且非"+++”文件标记符的代码行，代表代码发生新增或修改的位置。

[0056] 4）提取新增方法定义：通过正则匹配直接识别新增的完整方法声明。

[0057] 再次，为了覆盖新增函数和已有函数内部修改两类核心代码变更场景，本申请实施例采用两种识别方式以确保遍历出发生变更的全部功能函数，如下所示：方式1：直接识别新方法（diff_direct），直接利用GitDiffParser提取的"新增方法定义”字段，对于在本次代码提交中新增的完整函数定义，此方式可以无需回溯源码，即可直接识别并登记为变更函数。

[0058] 方式2：查找变更所属函数（source_file），针对已有函数内部的代码行修改（也即变更行位于既有函数体内），基于GitDiffParser提取的文件路径字符串和起止行号范围，回溯到本地克隆仓库中对应的源码文件中，通过语法树分析定位变更行所属的上一层函数定义，此方式确保不会遗漏对存量函数的修改。

[0059] 再次，本申请实施例采用核心编排器(GitFunctionAnalyzer),整合输入以完成变更函数的最终分析，具体如下：输入1：原始变更文件（即Git Diff命令的输出）。

[0060] 输入2：项目根目录，即本地克隆仓库的文件路径。

[0061] 输入3：code_analysis_result.json，即：预解析的代码分析结果，包含方法、接口等结构化信息。

[0062] 调用FunctionFinder：执行具体的功能函数的定位与提取。

[0063] 调用ApiMappingTracer：关联变更的功能函数对应的API接口，为后续调用链构建做准备。

[0064] 再次，本申请实施例采用函数定位器执行具体的源码文件分析，精准定位变更对应的功能函数，具体如下：1）读取源文件：根据文件路径从本地克隆仓库(即源代码仓库)中加载对应的前端变更文件或后端变更文件。

[0065] 2）函数边界查找：对于方式2（source_file），以变更行号为基础，利用AST解析工具向上遍历语法树，查找包含该行号的最近函数声明节点或方法定义节点。对于前端单文件组件，增加前置过滤，仅当变更行号落入<script>标签对应的AST节点范围内，才执行后续查找。

[0066] 3）语义元数据提取：提取函数节点的完整签名（名称、参数、返回值）记忆前置的文档注释（Javadoc / JSDoc / 普通注释），作为函数的业务描述信息存储，为后续调用链构建、测试用例生成提供业务语义支撑。

[0067] 最后，本申请实施例实现源代码仓库中的函数映射，从而完成前后端发生变更的功能函数的确定，获得变更函数集。

[0068] 步骤S13，获取代码知识图谱。

[0069] 代码知识图谱为代码变更文件所属项目的代码的图谱结构。代码知识图谱包括多个调用链，每个调用链用于表示触发事件在前端到后端之间产生的函数调用关系。

[0070] 代码知识图谱可被提前构建生成，并保存在本地上。如前所述，相关技术的前端代码解析和后端代码解析互相独立，前端的调用链和后端的调用链缺乏映射，导致相关技术无法捕获到代码变更对前后端的全局影响。本申请实施例提供的代码知识图谱能够将前端的调用链和后端的调用链进行映射，为用户提供关于代码变更所产生的全局性概貌影响。

[0071] 以下，本申请实施例分为四大部分阐述代码知识图谱的生成，分别为：代码知识图谱的整体生成框架、前端子图谱的具体生成、后端子图谱的具体生成及前端子图谱和后端子图谱的融合。

[0072] ①代码知识图谱的整体生成框架。

[0073] 具体的，本申请实施例通过步骤S131至步骤S134获取代码知识图谱，具体如下所示：步骤S131，获取代码变更文件所属项目的前端源代码及后端源代码。

[0074] 本地克隆仓库存储的代码和文件均属于该项目，因此，本申请实施例直接在本地克隆仓库中获取项目的前端源代码及后端源代码。前端源代码可以为Vue源代码等。后端源代码可以为Java源代码。

[0075] 步骤S132，基于前端源代码生成前端子图谱。

[0076] 前端子图谱为前端中代码的图谱结构，用于表示前端代码内部的执行逻辑与调用关系。本申请实施例采用前端解析器处理前端源代码，从而获得前端子图谱。

[0077] 步骤S133，基于后端源代码生成后端子图谱。

[0078] 后端子图谱为后端中代码的图谱结构，用于表示后端代码内部的执行逻辑与调用关系。本申请实施例采用后端解析器处理后端源代码，从而获得后端子图谱。

[0079] 步骤S134，将前端子图谱与后端子图谱执行图谱融合操作，得到代码知识图谱。

[0080] 图谱融合操作是指将前端子图谱和后端子图谱中属于同一业务链路的调用链进行映射。示例性的，本申请实施例可以基于前端子图谱与后端子图谱之间的同一个接口地址，将前端子图谱与后端子图谱进行映射，从而获得代码知识图谱。

[0081] 本申请实施例将前端子图谱与后端子图谱进行融合，形成覆盖"前端交互 到后端处理”的端到端的代码知识图谱，实现全链路业务逻辑统一表达，为后续基于变更的功能函数快速定位目标调用链提供完整、准确的图谱支撑，保证测试用例生成的业务完整性和精准性。

[0082] ②前端子图谱的具体生成。

[0083] 本申请实施例通过步骤S1321与步骤S1322生成前端子图谱，具体如下：步骤S1321，基于前端源代码生成前端调用链。

[0084] 前端调用链用于反映前端代码内部的执行逻辑与调用关系，本申请实施例可以解析前端源代码中的交互组件、事件绑定、函数调用、API请求等，从而能够构建出从"交互组件的交互→功能函数的执行→前端调用接口的调用”的完整的前端调用链。在前端调用链中，本申请实施例可以以功能函数、前端调用接口、交互组件为图谱节点，以调用关系为边，从而形成前端调用链。

[0085] 基于前端源代码生成前端调用链包括以下步骤：C1，基于预设的栈式计数器在前端源代码中进行区域分解与行号定位，得到多个代码区域，多个代码区域包括脚本区域、模板区域及样式区域。

[0086] 采用栈式计数器方法匹配最外层的<template>、<script>、<style>标签，以处理前端源代码内部可能存在的标签嵌套结构，避免因嵌套的同名标签导致区域提取错误。通过标签栈计数，分别确定三个代码区域的起始行号与结束行号，模板区域为<template>标签至< / template>标签之间的内容。脚本区域为<script>标签至< / script> The content between tags. The style area is... <style>标签至< / style> The content between the tags. Record the line number range of the above area for later code location tracing.

[0087] C2 determines the front-end call relationship based on the script area and the template area.

[0088] The front-end call relationship is used to represent the call relationship between front-end interactive components, front-end method bodies, and front-end call interfaces. This application's embodiments identify and organize the call pointers between interactive components, front-end method bodies, and front-end call interfaces, forming a structured relationship of "interactive component → front-end method body → front-end call interface," thus establishing the dependency and call structure between various execution units of the front-end code.

[0089] Specifically, determining the front-end call relationship based on the script area and the template area includes the following steps: C21 extracts component information and event binding relationships based on the template area.

[0090] This application embodiment performs AST syntax tree traversal analysis in the template area to extract components. First, it extracts all component information, identifying all semantically meaningful component tags in the template area, including but not limited to button components (el-button), input boxes (el-input), and hyperlink components (...). Tags), menu item components (el-menu-item), etc.

[0091] Furthermore, the plain text content of all child nodes within the interactive component tag is recursively collected and used as the component's display name. The component path is then generated based on its nesting hierarchy in the DOM tree (e.g., div>el-form>el-button). For example, part of the front-end page code is " <el-button> submit< / el-button> In this embodiment of the application, the component name "Submit" of the front-end component "el-button" is extracted, and the component path of the front-end component "el-button" on the front-end page is recorded, wherein the component path is div>el-form>el-button.

[0092] Then, nodes with the first format instruction are selected from all components. For each node, the name of its event handler function is extracted, and a mapping relationship between the component path and the event handler function name is established. In other words, this step simultaneously obtains information about all components and the event binding relationships of interactive components.

[0093] For example, the first format directive is a Vue event binding directive, that is, an attribute directive prefixed with "@" or "v-on:", such as @click or v-on:click. This type of first format directive is used to indicate that the node of the first format directive can be clicked or manipulated, and can trigger a function. Therefore, the node is an "interactive node" that responds to a specific interactive behavior.

[0094] C22 extracts the front-end method body and its content based on the script region.

[0095] The front-end method body contains the business logic bound to the interactive component, and the method content of the front-end method body represents the action of the front-end method body. Please refer to [link / reference]. Figure 3 The code highlighted in the first red box (31) is the event binding for the Vue front-end table component. The complete code is `@selection-change="handleSelectionChange"`. Here, `@selection-change` is the first format directive. `handleSelectionChange` is the name of the bound event handler function, which maps to the front-end method body.

[0096] The content of a front-end method body includes the function body bound to the interactive component, internal logic, variables, and execution flow. This application embodiment uses lexical analysis algorithms and regular expression matching to identify each front-end method body in a method block, extract the method content of the front-end method body, and supports multiple definition formats (such as ordinary functions, arrow functions, and object methods).

[0097] The method block is a dedicated area for storing front-end method bodies, which include one or more function calls. This application embodiment uses a lexical analysis algorithm to identify each front-end method body within the method block and extract the content of each method (i.e., the code of the function call) from within the front-end method body.

[0098] The embodiments of this application can reliably and accurately extract functional functions from the script area, and are compatible with multiple function writing styles, providing complete method logic content for the front-end call chain.

[0099] C23 extracts the front-end call interfaces that the front-end method body needs to call based on the script region.

[0100] The front-end call interface is the interface through which the front-end initiates requests to the back-end. The front-end call interface is written in the front-end method body. In this embodiment of the application, the front-end call interface is extracted from the front-end method body in order to establish the association between the front-end logic and the back-end interface, and to provide a matching basis for the fusion of front-end and back-end sub-graphs.

[0101] This application embodiment supports the identification of multiple front-end API calls, identifying all front-end API calls capable of initiating requests to the back-end from the front-end method body, and thus extracting the URL address of the front-end API call. For example, this application embodiment scans the front-end method body and identifies the following front-end API calls: "axios.get / post / ...", "this.$axios.*", "request({ url: ...})", and "this.$get / post / ...". As another example, this application embodiment scans the front-end method body and identifies front-end API calls imported from the @ / api module by matching function names.

[0102] This application embodiment automatically identifies all HTTP requests sent to the backend from the frontend method body, is compatible with various interface call writing methods in the project, improves parsing coverage, and also establishes a correspondence between the frontend and the backend, completing the last link of the frontend call chain.

[0103] C24 generates front-end call relationships based on the mapping relationship between component paths and event handling function names in the template area, the method content of the front-end method body in the script area, and the front-end call interface.

[0104] This application embodiment identifies and organizes the call pointers between interactive components, method bodies, and interface call statements, forming a structured front-end call relationship of "interactive component → method body → front-end call interface". Thus, this application embodiment has been able to transform scattered code into an ordered execution relationship on the front end, clarify the function call flow and interface association relationship, and construct the main body of the front-end call chain.

[0105] C3 determines the front-end call description information based on each code region.

[0106] The front-end call description information is used to describe the link of the front-end call chain. This application embodiment extracts information such as the interface title, component information, call source, and code location to describe the business meaning, execution flow, and link characteristics of the front-end call chain. This supplements the semantic description of the front-end call chain, making the link of the front-end call chain understandable and providing information support for the subsequent generation of test cases from the large language model.

[0107] Determining the front-end call description information based on each code region includes the following steps: C31 extracts various interface titles based on template areas.

[0108] All types of interface titles include page titles, pop-up window titles, and menu titles. Exemplarily, in the embodiments of the present application, the page titles of pages from h1 to h6 are extracted. For example, for the login page, " <h3 class="title"> BLUETTI DEVOPS< / h3> ", the embodiments of the present application extract the page title "BLUETTI DEVOPS". Another example is that in the embodiments of the present application, the element text with class containing title is extracted as the interface title. For example, Project List ", the embodiments of the present application extract "Project List" as the interface title. Another example is that in the embodiments of the present application, the built-in title attribute of the component is extracted as the interface title. For example, the interface titles of Element UI components include the title of the pop-up window el-dialog, the label of the tab page el-tab-pane, the menu title, the button name, etc. For example, for the pop-up window <el-dialog title="New User" / >, the embodiments of the present application extract "New User" as the pop-up window title.

[0109] In the embodiments of the present application, by extracting various interface titles, business semantic information and business scenario descriptions are given to the front-end call chain, clarifying the page, function, and business module to which the call chain belongs, providing key information such as interface names, function names, and operation scenarios for the large language model to generate test cases, and significantly improving the business compliance and usability of the test cases.

[0110] C32. Extract component information based on the template area.

[0111] Exemplarily, the full amount of front-end component information extracted in step C21 can be directly cited as the interface structured description field in the front-end call description information, without secondary parsing of the template area, saving time and resources. The embodiments of the present application realize the automatic recognition and information extraction of each front-end component in the front-end interface, covering all operable and displayable elements. The component name and component path can be directly used for the operation steps and operation positions of generating test cases, providing a structured and visual interface basis for the front-end call description information, which is beneficial to improving the readability and traceability of the front-end call chain.

[0112] C33. Extract the call source information of the function based on the script area.

[0113] The call source information is used to locate the source of the functional functions. This embodiment parses the import statement, identifies functional functions imported from the @ / api path, and establishes a mapping relationship between the function name and the module path to obtain the call source information. For example, part of the front-end page code is "import {getList, addUser} from '@ / api / project'". This embodiment identifies that the functional functions "getList()" and "addUse()" originate from the module path @ / api / project. Therefore, this embodiment maps and binds the functional functions "getList()" and "addUse()" to the module path @ / api / project to obtain the call source information. Subsequently, the functional functions "getList()" or "addUse()" are parsed in the method body. This embodiment, by parsing the import statement, understands that the functional functions "getList()" and "addUse()" are front-end call interfaces, not ordinary functions. The URL address of the functional functions "getList()" or "addUse()" can then be extracted.

[0114] Please see Figure 4 In this embodiment of the application, after the import statement of the front-end page, the functional functions listUserStoryAndBug and listVersion are identified as being imported from @ / api / project / dashboard. Therefore, both functional functions listUserStoryAndBug and listVersion are interface functions, and a mapping relationship between interface functions and module paths is established as follows: 1) listUserStoryAndBug→@ / api / project / dashboard; 2) listVersion→@ / api / project / dashboard; When the system encounters the function listVersion() in the front-end method body, it can directly identify listVersion() as an interface function, rather than a regular function.

[0115] This application embodiment achieves accurate identification of encapsulated interface functions by parsing import statements, solving the problem that interface URLs are hidden in modules and cannot be directly identified, and greatly improving the coverage and accuracy of interface call identification.

[0116] C34 generates front-end call description information based on the code location of each code region, various interface titles, component information, and function call source information.

[0117] This application integrates code location, interface information, interface title, component path, and call source information into structured front-end call description information. The front-end call description information can provide complete business semantics and rich information about the front-end call chain, providing sufficient information support for generating high-quality test cases for large models.

[0118] C4 generates a front-end call chain based on the front-end call description information and the front-end call relationship.

[0119] The embodiments of this application use the front-end call relationship as the link skeleton and the call description information as the link attribute to generate a structured front-end call chain. The front-end call chain has a clear structure and complete semantics.

[0120] Please continue reading. Figure 4 The code in the second red box (41) is "apiModule": "@ / api / project / dashboard". Here, @ / api / project / dashboard is the module path of the API interface in the front-end source code. It is used to locate the source of functionalities, and through the mapping relationship between module paths and functionalities, it can accurately call the back-end API, realizing the association between the front-end and back-end call chains.

[0121] Step S1322: Generate a front-end sub-map based on multiple front-end call chains.

[0122] This application embodiment organizes and stores multiple front-end call chains in a unified manner to form a complete code structure diagram of the front-end, thereby obtaining a front-end sub-graph. The front-end sub-graph structures and organizes the interfaces, methods, and logic of the front-end source code to form a structured graph of the front-end business processing link, providing front-end support for subsequent front-end and back-end graph fusion and end-to-end full-link analysis.

[0123] ③ The specific generation of the terminal diagram.

[0124] In this embodiment of the application, the rear terminal pattern is generated through steps S1331 and S1332, as detailed below: Step S1331: Generate a backend call chain based on the backend source code.

[0125] The backend call chain is used to reflect the execution logic and call relationship inside the backend code. In this embodiment, the classes, method bodies and call relationships in the backend source code are parsed to construct the backend call chain of "interface request → business logic → data operation".

[0126] Generating a backend call chain based on backend source code includes the following steps: D1, determine the backend call interface based on the backend source code.

[0127] The backend API serves as the external access point for backend services, receiving requests from the frontend, defining request rules, and triggering the execution of business logic within backend methods. This embodiment utilizes a backend parser to parse the backend source code and identify the backend API.

[0128] Determining the backend call interface based on the backend source code includes the following steps: obtaining interface annotation information based on the backend source code, and extracting the URL address of the backend call interface from the interface annotation information.

[0129] Interface annotation information includes Spring MVC annotation information and Swagger annotation information. Obtaining interface annotation information based on backend source code involves the following steps: extracting Spring MVC annotation information from the Spring MVC framework based on the backend source code; and parsing the pre-built interface documents using the Swagger tool based on the backend source code to obtain Swagger annotation information.

[0130] Spring MVC annotations are related to request mapping and are used to define the access rules for backend API calls. Spring MVC annotations include the URL address of the backend API call and the request method (GET / POST, etc.), and are the core identifiers of the backend API call.

[0131] The parser accurately identifies all commonly used request mapping annotations in the Spring MVC framework, covering all request methods for backend API calls, specifically including the following backend API calls: 1) @GetMapping: Corresponds to the GET request method and is used to query class interfaces; 2) @PostMapping: Corresponds to the POST request method and is used to add new class interfaces; 3) @PutMapping: Corresponds to the PUT request method and is used to modify class interfaces; 4) @DeleteMapping: Corresponds to the DELETE request method and is used to delete class interfaces; 5) @RequestMapping: A general request mapping annotation that can specify the request method, URL address, etc.

[0132] Please see Figure 5`@ApiOperation` is a Swagger annotation used to add business descriptions to APIs. `@PostMapping(" / execute")` is a Spring MVC annotation used to define backend API calls of type POST.

[0133] After the parser recognizes the Spring MVC annotation information, it extracts the URL address from the Spring MVC annotation information. The URL address is the "unique identifier" of the backend call interface. The frontend call interface initiates a request through the URL address, and the backend call interface receives the request through the URL address.

[0134] Swagger is an API documentation tool used to automatically extract code information from Swagger annotations and ultimately integrate it into API documentation that records all backend API calls made by the project. The parser parses the API documentation to obtain Swagger annotation information; the specific process is as follows: 1) Identification and information extraction of @ApiOperation.

[0135] @ApiOperation is a Spring MVC annotation used in Swagger to describe the core operations of an interface. The parser parses @ApiOperation and extracts information such as the interface operation description, notes, and response type.

[0136] 2) Analysis and information extraction of @ApiResponse.

[0137] @ApiResponse is an annotation in Swagger used to describe the rules for API response. The parser parses @ApiResponse to obtain the response status code, response message, response data type, etc.

[0138] 3) Processing and information extraction of @ApiParam.

[0139] @ApiParam is an annotation in Swagger used to describe the parameters of an API method. The parser parses @ApiParam to obtain information such as the API description of the method parameters.

[0140] Please see Figure 6 , Figure 6 The code snippet shown includes Swagger annotation information such as @ApiOperation and @ApiParam, as well as Spring MVC annotation information such as @GetMapping and @RequestParam.

[0141] Specifically, for the @ApiParam annotation information, the parser extracts the parameter description "test instruction" and the associated parameter "String instruction" from @ApiParam.

[0142] This application embodiment obtains the URL address of the backend call interface based on Spring MVC annotation information, and extracts metadata such as business description, parameters, and response of the backend call interface based on Swagger annotation information. The combination of the two can completely obtain the core information of the backend call interface, providing information support for the construction of the backend call chain and backend sub-graph.

[0143] D2 generates backend call relationships based on backend source code.

[0144] Backend call relationships are used to represent the call relationship between backend call interfaces and backend method bodies. This application's embodiments identify and organize the call relationships between backend call interfaces and backend method bodies from the backend source code, forming a skeletal structure of "interface entry to method call," clearly defining the code execution flow.

[0145] Generating backend call relationships based on backend source code includes the following steps: D21 extracts multiple backend method bodies from the backend source code.

[0146] The backend method body is used to implement the specific execution of the backend business logic. This application embodiment utilizes a backend parser to parse the backend source code and identify the information of each backend method body. The information of the backend method body includes the method signature and the method body location.

[0147] Extracting multiple backend method bodies from the backend source code involves the following steps: performing a syntax tree generation operation on the backend source code to obtain a backend abstract syntax tree, traversing the backend abstract syntax tree to find the nodes corresponding to the backend method bodies, and capturing the method content of the backend method bodies from the nodes.

[0148] The parser uses the Visitor pattern of Eclipse JDT to traverse the backend abstract syntax tree. When it reaches the MethodDeclaration node, it finds a method declaration for the backend method body. The parser captures the method signature of the backend method body, which includes the method name, parameter type list, and return type. The MethodDeclaration node is a node type in the backend abstract syntax tree, corresponding to a method declaration in Java code. In this embodiment, the method content of the backend method body is obtained by calling the toString() method of the MethodDeclaration node. The method content of the backend method body includes all code statements and local variable declarations within the backend method body.

[0149] D22 performs a forward call relationship parsing operation on multiple backend method bodies to obtain the forward call relationship.

[0150] This application's embodiments trace the call relationships between various backend method bodies downwards, forming a forward execution chain. The backend parser identifies all method call nodes through a custom Visitor pattern. For each method call, it parses the caller expression, infers the fully qualified class name of the called method through the type resolver, and records the forward dependency relationship of "which method body calls which method body". For example, if method body A calls method body B, the forward call relationship is A→B.

[0151] Please see Figure 7 The code in the third red box (71) is `orderService.save()`, where `orderService` is a member variable of the class. `orderService.save()` is used to indicate a method call.

[0152] The content in the fourth red box (72) is OrderController.createOrder() → OrderService.save(). Here, OrderController is the backend controller layer, and createOrder() is an API method.

[0153] The call relationship between OrderController.createOrder() and OrderService.save() is a forward call relationship, where OrderController.createOrder() is the caller and OrderService.save() is the callee.

[0154] D23 performs a reverse call relationship parsing operation on multiple backend method bodies to obtain the reverse call relationship.

[0155] This embodiment searches upwards for the call relationships between each backend method body. Specifically, the parser builds a method index library for all method bodies, indexed by a unique identifier, "fully qualified class name.method name". Then, it iterates through the forward call relationships of all method bodies, building a caller list for each called method body. The construction process automatically removes duplicates, ensuring that each reverse call relationship is recorded only once. For example, if method body B is called by method body A, and method body B is called by method body C, the reverse call relationship is B←A, B←C. This embodiment builds a caller list for method body B.

[0156] D24 generates backend call relationships based on forward and reverse call relationships.

[0157] This application employs a multi-layered analysis strategy to deeply mine the call dependencies between Java methods, constructing forward and reverse call relationships to form a complete backend call relationship, providing relational support for tracing the scope of impact of backend call chain changes.

[0158] D3 generates backend call description information based on the backend source code.

[0159] Backend call description information is used to describe the link of the backend call chain. In this embodiment of the application, information such as the method signature, method body location, interface address, method name, comments, function description, parameters, and return value of the backend method body are extracted to form backend call description information. This supplements the backend call chain with business semantics and explanatory information, so that the backend call chain not only has backend call relationships, but also business meaning. This makes it easier for the large language model to understand the business logic link of the backend call chain.

[0160] Generating backend call description information based on backend source code includes the following steps: D31, obtains method comment information of backend method bodies based on backend source code.

[0161] Method annotations describe the business functionality of backend method bodies. For each backend method body, the parser specifically extracts the method annotation information (such as Javadoc comments). Javadoc comments are a standardized method annotation format in Java backend code, usually located before the method declaration, starting with " / **" and ending with "* / ". They are the official descriptions of method functionality, parameters, return values, etc., provided by the developers and are the core extraction object of the parser.

[0162] Method annotation information includes method documentation and standardized tag information. The method documentation is expressed in natural language and is used to clarify the core functions, business scenarios, or usage precautions of the backend method body.

[0163] Javadoc comments include tags starting with "@", each corresponding to specific method information. Examples of standardized tags include `@param`, `@return`, and `@throws`. `@param` describes the method's parameters, including parameter names, meanings, and requirements (e.g., "not null", "range restrictions"). `@return` describes the method's return value, including the return type and meaning. `@throws` describes the types of exceptions the method might throw and the scenarios in which these exceptions might be triggered.

[0164] Method comments, as a crucial component of backend call descriptions, ensure that the backend call chain not only contains code logic but also clear business semantics, facilitating understanding of the call chain's business purpose. For subsequent call relationship analysis and change impact analysis, method comments can quickly clarify method functionality, avoiding misunderstandings caused by complex code logic.

[0165] D32 retrieves variable type information based on the backend source code.

[0166] During the parsing process, the parser maintains a dynamic type context to comprehensively capture the variable type information of all variables in the backend code, clarifying the ownership and attributes of various variables, and providing basic support for method calls, type matching, and subsequent code analysis.

[0167] Specifically, variable type information includes class field type information, method parameter type information, and local variable type information. Class field type information consists of all fields and their types extracted from the class declaration. In this embodiment, the FieldDeclaration node is traversed from the backend abstract syntax tree to record the names and corresponding types of all member variables in the class. For example, in the user class, the "username" field is of type string; the "age" field is of type integer, thus clearly identifying the attribute of the class in which the backend method body is called, providing a basis for determining the attribution of the backend method body.

[0168] The method parameter type information is the parameter type extracted from the method signature. In this embodiment, the input parameter name and parameter type for each backend method body are extracted from the method signature, clarifying the parameter requirements when calling the backend method body and avoiding calling errors caused by parameter type mismatches.

[0169] Local variable types: All local variables declared within the backend method body and their types. This embodiment of the application traverses the code within the backend method body, extracts the declaration information of all local variables, and records their names and types to ensure that the use of variables and logical operators within the backend method body conforms to type specifications.

[0170] D33 performs expression simplification operations based on the backend source code to obtain caller type information.

[0171] For complex method call chains, such as the expression "userService.getUserDao().findById()", multi-level nested calls often occur in the backend code, making direct analysis of complex expressions difficult. The parser provided in this application intelligently simplifies and progressively infers the type of each step, ultimately clarifying the true type of the outermost caller, ensuring accurate call relationship analysis and meeting the needs of backend code parsing.

[0172] Specifically, the parser starts from the leftmost end of the expression, gradually breaking down and inferring the types of intermediate results, ultimately determining the true type of the outermost caller. For example, for `userService.getUserDao().findById()`, this embodiment first analyzes `userService.getUserDao()`, inferring its return type as "Data Access Layer Object (Dao)"; then, based on this type, it determines that the caller of the subsequent `findById()` method is a "Dao layer object," thus completing type tracing. This embodiment intelligently simplifies the expressions of complex method call chains, avoiding type judgment errors caused by complex expressions and ensuring accurate call relationship analysis.

[0173] D34 parses the import statements in the backend source code to obtain class name mapping information.

[0174] When the import statement in the backend source code includes the full path of a class, this embodiment establishes a mapping relationship between the full class name and the simple class name. For example, in the import statement `import com.xxx.service.UserService`, the simple class name is `UserService`, the full class name is `com.xxx.service.UserService`, and the class name mapping information is `UserService→com.xxx.service.UserService`. When the class names `UserService` and `UserDao` appear in subsequent code, the specific package path can be directly located through the class name mapping information, clarifying the class's ownership and avoiding ambiguity.

[0175] This application adopts a precise import method to establish a precise mapping relationship between complete class names and simple class names. When using simple class names in subsequent code, the specific package path can be located directly through the class name mapping information.

[0176] When the import statement in the backend source code contains wildcards, this embodiment records the package path corresponding to the wildcard and sets the package path as a class name mapping. Subsequent code encountering a class name that does not match the exact import query will then search for a matching class under that package path.

[0177] For example, the import statement `import com.xxx.service.*` will be parsed and recorded as: `com.xxx.service.*` → package path `com.xxx.service`. When a class name (such as `OrderService`) appears in the code and the corresponding package path cannot be found through exact import, the parser searches for the class in all recorded wildcard package paths to achieve type matching.

[0178] When a class name appears in the code and the class exists in multiple wildcard import package paths, the parser will not simply choose the relevant package path. Instead, it will select the package path that best fits the current code scenario based on a priority algorithm to ensure the accuracy of type matching.

[0179] Specifically, for package paths imported using wildcards, this embodiment obtains the target class name and, based on a suffix matching priority algorithm, searches multiple package paths to see if the suffix of the package path matches the target class name. If they match, the package path whose suffix matches the target class name is set as the target package path that best matches the target class name. The class corresponding to the target class name is then searched under the target package path. If they do not match, the matching degree between the target class name and the package path is calculated, and the package path corresponding to the highest matching degree is set as the target package path. The class corresponding to the target class name is then searched under the target package path.

[0180] For example, the target class name to be matched ends with a specific suffix (such as Service, Dao, Controller, DTO, etc., commonly used backend class suffixes). The parser prioritizes selecting the package path containing the corresponding functionality as the target package path. For instance, the package paths imported using wildcards are com.xxx.service.* (service package) and com.xxx.dao.* (dao package); the target class name to be matched is UserService (ending with Service). Since the target class name ends with Service, the package path containing the keyword "service" (com.xxx.service.*) is matched first, determining that UserService comes from the com.xxx.service package, not the dao package.

[0181] For another example, the package paths imported using wildcards are com.xxx.user.service.* (user service package) and com.xxx.order.service.* (order service package); the target class name to be matched is UserService. Since the target class name UserService contains "User", it has the highest matching degree with "user" in the com.xxx.user.service.* package. Therefore, this embodiment of the application selects "com.xxx.user.service.*" as the target package path.

[0182] This application embodiment establishes a precise mapping through precise import and avoids matching errors of classes with the same name under multiple packages by using a wildcard import priority algorithm, thus ensuring accurate type inference.

[0183] D35 retrieves interface annotation information based on the backend source code.

[0184] Interface annotations are used to explain backend API calls. The description of interface annotations has been presented in the above embodiments and will not be repeated here.

[0185] D36 generates backend call description information based on the method signature, method body location, method comment information, variable type information, caller type information, class name mapping information, and interface annotation information of the backend method body.

[0186] This application embodiment generates structured backend call description information by integrating multi-dimensional information, which helps improve the readability of the backend call chain. It also supports the construction of a code knowledge graph for the entire front-end and back-end chain, connects the links between front-end and back-end code, and provides data support for the generation of automated test cases and code analysis, thereby improving the efficiency of the entire process of development, testing and operation.

[0187] D4 generates a backend call chain based on multiple backend call relationships and backend call description information.

[0188] This application embodiment integrates the backend link structure and business semantic information through multiple backend call relationships and backend call description information to form a complete and usable backend call chain.

[0189] Please see Figure 8 , Figure 8 This diagram illustrates the structured method metadata obtained by the parser (Java parser) after analyzing the backend source code according to the methods described in the above embodiment. Specifically, "methodName / methodSignature" corresponds to the extraction of the method signature, "startLine / endLine" corresponds to the location of the method body, "javadoc" corresponds to the extraction of method comment information, and "apiMapping" corresponds to the interface annotation information.

[0190] Step S1332: Generate a backend terminal map based on multiple backend call chains.

[0191] This application embodiment generates a backend sub-graph based on multiple backend call chains, which can integrate scattered call relationships into a structured and networked graph structure, realizing a holistic presentation of the call relationships of the backend code.

[0192] ④ Fusion of front-end and back-end terminal diagrams.

[0193] The front-end subgraph includes multiple front-end call chains, and the back-end subgraph includes multiple back-end call chains. The front-end subgraph and the back-end subgraph are merged to obtain a code knowledge graph. The steps include: in response to the front-end call interface address of the front-end call chain being consistent with the back-end call interface address of the back-end call chain, a mapping relationship is established between the front-end call interface and the back-end call interface, so that the front-end subgraph and the back-end subgraph form a code knowledge graph.

[0194] For example, in this embodiment of the application, the apiModule result parsed by the Vue frontend is mapped to the apiMapping field parsed by the Java backend. If the two URLs are consistent, a connection between the frontend and the backend is established.

[0195] This application embodiment can trace the call chain based on a code knowledge graph. For example, based on the code knowledge graph, this application embodiment traces upstream to record the complete call chain from the modified function to the top-level external interface. This application embodiment analyzes the traced call chain to parse business logic. For instance, by analyzing the call chain, this application embodiment can understand the core business logic and processes implemented or affected by this code change. Furthermore, this application embodiment, based on the code knowledge graph, can lock the front-end and back-end contexts, associating and mapping back-end call interfaces with corresponding interactive components such as buttons on the front-end page.

[0196] At this point, the code knowledge graph has been built and generated.

[0197] Step S14: Perform a content matching operation on the call chain and the changed function set to obtain the content matching score corresponding to the call chain.

[0198] The content matching score is used to represent the degree of correlation between the set of changed functions and the call chain generated by this code change. In this embodiment of the application, by obtaining the content matching score, the degree of correlation between the call chain and this code change is accurately quantified, and the call chains affected by the change are initially screened from multiple call chains, while completely irrelevant call chains are excluded, thus narrowing the screening range.

[0199] Performing a content matching operation on the call chain and the changed function set to obtain a content matching score corresponding to the call chain includes the following steps: determining the number of changed function functions in the call chain based on the changed function set, calculating the ratio of the number of changed function functions to the total number of function functions in the call chain, setting the content matching score corresponding to the call chain as a first score when the ratio is greater than or equal to a preset first value, setting the content matching score corresponding to the call chain as a second score when the ratio is less than the first value but greater than or equal to a preset second value, and setting the content matching score corresponding to the call chain as a third score when the ratio is less than the second value but greater than a preset third value, wherein the third score is less than the second score, and the second score is less than the first score.

[0200] The first, second, and third values ​​are customized by the designer according to business needs. For example, the first value is 50%, the second value is 20%, and the third value is 0%.

[0201] The first, second, and third scores are customized by the designer according to business needs. For example, the first score is 10 points, the second score is 6 points, and the third score is 3 points.

[0202] If the ratio h of the modified function to the total number of functions in the call chain is greater than 50%, the call chain is scored 10 points. If the ratio h is greater than 20% and less than 50%, the call chain is scored 6 points. If the ratio h is less than 20% and greater than 0%, the call chain is scored 3 points.

[0203] This application uses the ratio of the number of modified functions to the total number of functions in the call chain for evaluation. Call chains affected by code changes are graded and scored according to their degree of impact. The content matching score is positively correlated with the degree of impact of code changes. The call chain affected by code changes to a greater degree receives a higher content matching score, while the call chain affected by code changes to a lesser degree receives a lower content matching score. This makes the evaluation of the degree of impact of changes on call chains of different lengths and complexities more fair, reasonable, and accurate. It achieves standardized and quantitative grading of the degree of impact of changes, providing a more reliable basis for subsequent comprehensive scoring and target call chain screening, and improving the accuracy and applicability of the screening results.

[0204] Step S15: Obtain test requirement information.

[0205] Test requirement information is used to represent the test requirements of test cases. Test requirement information can be customized by testers based on test requirements, or it can be derived from requirements documents, etc.

[0206] Step S16: Determine the requirement matching score corresponding to the call chain based on the test requirement information.

[0207] The requirement matching score reflects the degree of matching between the functional description information of the call chain and the test requirement information. Determining the requirement matching score corresponding to each call chain based on the test requirement information includes the following steps: obtaining the functional description information of the call chain; inputting the test requirement information, the functional description information of all call chains, and preset system prompts into the large language model, so that the large language model performs the requirement matching score calculation operation to obtain the requirement matching score for each call chain. The semantic matching degree between the functional description information of the call chain and the test requirement information is positively correlated with the requirement matching score.

[0208] Functional description information describes the business functions of the call chain. This information includes the purpose of the interface, business logic, functional specifications, and annotation descriptions. Functional description information helps large language models better understand the business logic of the call chain, enabling them to shift from a code-level understanding to a business logic-level understanding, thus improving the accuracy of their analysis.

[0209] In this embodiment, the test requirement information, the functional description information of all call chains, and the system prompts are all input into the large language model. The large language model performs a requirement matching score calculation operation to obtain the requirement matching score for each call chain. Among them, the requirement matching score of the call chain selected by the large language model is the fourth score, and the requirement matching score of the call chain that is not selected is the fifth score. The fourth score is greater than the fifth score. For example, the fourth score is 4 points and the fifth score is 0 points.

[0210] For example, the system prompt is: {Call Chain 1}....{Call Chain n};{Requirement Description} Please help me determine the code call chain that matches the requirement description based on the requirement information, and output the sequence number of the call chain, separated by commas.

[0211] The functional description information for all call chains includes the functional description information for call chain 1 and the functional description information for call chain 2. The functional description information for call chain 1 is as follows: userDetail: / user / detail - Personal Weekly Report Details -> userDetail: Query a specified weekly report based on conditions -> detail: Weekly report details -> updateSelfCustomerDate: Update personal weekly report information -> getWeekOrderCustomer: Get customers who placed orders this week -> findThisWeekOrderSku: Query all SKUs ordered by me / my department within a specified range -> skuAggregation: Aggregate products and gifts by customer, SKU, and price -> setCustomerInfo: Set BS customer information -> getByCustomerNoToMap: Query customers based on customer code.

[0212] The functional description information for call chain 2 is as follows: weeklyReportOrderSummaryTask: / weeklyReportOrderSummaryTask-Customer Weekly Report - Summary of Orders Placed Last Week -> weeklyReportOrderSummaryTask: Summary of Customer Weekly Report Orders Placed Last Week Every Tuesday at 1 PM -> weeklyReportOrderSummaryTask: Update Individual Weekly Report Order Data -> findThisWeekOrderSku: Query All SKUs Ordered by Me / My Department Within a Specified Range -> skuAggregation: Aggregate Products and Gifts by Customer, SKU, and Price -> setCustomerInfo: Set BS Customer Information -> getByCustomerNoToMap: Query Customers Based on Customer Code

[0213] The testing requirements are to summarize the SKU order information in the weekly report every Tuesday, and to obtain the latest SKU order information from the BS customer.

[0214] The large language model selects call chain 2, sets the demand matching score of call chain 2 to 4 points, and sets the demand matching score of call chain 1 to 0 points.

[0215] Step S17: Determine the total score of the call chain based on the content matching score and the demand matching score of the call chain.

[0216] In this embodiment of the application, the content matching score and the demand matching score of the call chain are added together to obtain the total score of the call chain.

[0217] Step S18: Based on the total score of all call chains, select the call chains that meet the preset filtering conditions as the target call chains.

[0218] The target call chain is the call chain whose code changes affect the business logic. The preset filtering criteria are customized by the designer based on engineering experience. In some embodiments, this application determines the N call chains with the highest total scores based on the total scores of all call chains. The N call chains with the highest total scores satisfy the preset filtering criteria, where N is a positive integer, and all N call chains are set as target call chains.

[0219] For example, N is 5. In this embodiment of the application, the total scores of all call chains are sorted in ascending or descending order to obtain the sorting results. The five call chains with the highest total scores are selected as the target call chains.

[0220] Step S19: Input the target call chain and front-end and back-end change data into the pre-trained large language model so that the large language model can perform test case generation operations to obtain test cases.

[0221] As mentioned earlier, the front-end and back-end change data includes front-end code change information, the corresponding interfaces for the front-end code changes, the changed functional functions, the front-end pages, triggering condition information, etc., and also includes back-end code change information, the changed functional functions, the corresponding interfaces for the back-end code changes, and the URL address of the back-end calling interfaces. This embodiment encapsulates the target call chain and the front-end and back-end change data into structured prompts, inputs these prompts into a large language model, and enables the large language model to perform test case generation operations to obtain test cases.

[0222] For example, the prompt words in this application embodiment are as follows: The existing business process implementation code is as follows: {Call chain function code content 1}...{Call chain function code content n}. Please analyze the code content and its implementation background. Now, the functions and their changes are as follows: {Change content 1}...{Change content n}. Please analyze the business background of the function and the changes, and design test cases. The test cases must cover the changes and have complete preconditions, operation steps, and expected results.

[0223] The above-mentioned prompt words are input into the large language model. Based on the code information of each function in the call chain and the modification content of the changed function, the large language model automatically parses the business process background and code change intention, and then generates standardized test cases that cover the changed content, include preconditions, operation steps and expected results. This realizes the intelligent and automated generation of test cases, effectively improving test efficiency and coverage.

[0224] This application uses code changes as the trigger point. By acquiring the code change file and identifying the set of changed functions, it can accurately locate the functional functions involved in the code modification, providing accurate analysis targets for subsequent impact analysis. Secondly, this application leverages a pre-built code knowledge graph to quickly acquire multiple call chains containing the changed functions, achieving automated identification of the impact scope of the code change and avoiding the inefficiency and omissions caused by manually sorting out call relationships. Thirdly, this application uses content matching to quantify the correlation between call chains and changed functions, filtering out the core call chains affected by the change, reducing interference from irrelevant links, and improving filtering efficiency. Furthermore, by introducing test requirement information and calculating requirement matching scores, it filters highly relevant call chains from a business perspective, ensuring that the target call chains simultaneously meet both technical impact and business requirements, improving filtering accuracy. Combining content matching scores and requirement matching scores to obtain a total score enables multi-dimensional comprehensive evaluation, balancing the intensity of the change's impact with business relevance, resulting in more reasonable filtering results. Finally, target call chains are filtered based on the total score, focusing on high-priority test chains, reducing invalid test scope, lowering testing costs, and improving testing efficiency. Finally, this embodiment utilizes a large language model to process the target call chain and front-end / back-end change data, enabling automated generation of test cases. This significantly reduces the cost of manually writing test cases and improves regression testing efficiency. Overall, this embodiment can quickly respond to iterative development needs, ensure a high degree of matching between test cases and code changes, and improve test coverage and the accuracy of test case generation.

[0225] In summary, this application embodiment implements a method that uses code changes as a trigger point, constructs a code knowledge graph based on front-end and back-end source code, and generates a unique business logic chain. Furthermore, this application embodiment uses the call chain of the code knowledge graph as a bridge to connect the changed code and the requirement background, fully integrating the changed code with the requirements and business background, providing complete business logic information for the automated generation of test cases from a large language model.

[0226] In addition, by connecting the front-end and back-end information of code changes and displaying the functional trigger points, the test cases generated by the large language model are more like "human-written" test cases, containing clear operation steps. This forms a more accurate (specifically targeted), complete (containing complete business background and scope of impact), and clear operation steps (containing page trigger conditions) test case generation method.

[0227] Finally, the embodiments of this application combine DevOps processes, static code analysis, dependency tracing, and cutting-edge AI technology, which significantly improves the intelligence level of test case generation, test response speed, accuracy of test scope, and test case coverage, and helps to quickly maintain the test case library and reduce maintenance costs.

[0228] It should be noted that in the above embodiments, there is no necessarily a certain order between the steps. Those skilled in the art can understand from the description of the embodiments of this application that the above steps may have different execution orders in different embodiments, that is, they may be executed in parallel or in turn, etc.

[0229] As another aspect of the embodiments of this application, this application provides a test case generation apparatus. The test case generation apparatus can be a software module, which includes several instructions stored in a memory. A processor can access the memory, invoke the instructions for execution, and complete the test case generation method described in the above embodiments.

[0230] In some embodiments, the test case generation device can also be built from hardware devices. For example, the test case generation device can be built from one or more chips, which can work together to complete the test case generation method described in the various embodiments above. As another example, the test case generation device can also be built from various logic devices, such as general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), microcontrollers, ARM (Acorn RISC Machine) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination of these components.

[0231] Please see Figure 9 The test case generation device 90 includes: a code acquisition module 91, a data acquisition module 92, a graph generation module 93, a call chain filtering module 94, and a model call module 95.

[0232] The code acquisition module 91 is used to acquire code change files. The data acquisition module 92 is used to determine the front-end and back-end change data based on the code change files. The front-end and back-end change data includes a set of changed function functions, which is a collection of function functions that have changed on the front-end and back-end. The graph generation module 93 is used to acquire a code knowledge graph, which includes multiple call chains. Each call chain represents the function call relationship generated between the front-end and back-end when a triggering event occurs. The call chain filtering module 94 is used to perform a content matching operation on the call chains and the set of changed function functions to obtain a content matching score corresponding to the call chain. It also acquires test requirement information and determines the requirement matching score corresponding to the call chain based on the test requirement information. The requirement matching score reflects the matching degree between the function description information of the call chain and the test requirement information. The total score of the call chain is determined based on the content matching score and the requirement matching score. Based on the total score of all call chains, the call chains that meet the preset filtering conditions are selected as target call chains. The model calling module 95 is used to input the target call chain and the front-end and back-end change data into a pre-trained large language model so that the large language model performs a test case generation operation to obtain test cases.

[0233] In some embodiments, the call chain filtering module 94 is specifically configured to: determine the number of function calls that have changed in the call chain based on the changed function set; calculate the ratio of the number of function calls to the total number of function calls contained in the call chain; in response to the ratio being greater than or equal to a preset first value, set the content matching score corresponding to the call chain as a first score; in response to the ratio being less than the first value but greater than or equal to a preset second value, set the content matching score corresponding to the call chain as a second score; in response to the ratio being less than the second value but greater than a preset third value, set the content matching score corresponding to the call chain as a third score, wherein the third score is less than the second score, and the second score is less than the first score.

[0234] In some embodiments, the call chain filtering module 94 is specifically used to: obtain the functional description information of the call chain, input the test requirement information, the functional description information of all call chains and the preset system prompt words into the large language model, so that the large language model performs the requirement matching score calculation operation to obtain the requirement matching score of each call chain, and the semantic matching degree between the functional description information of the call chain and the test requirement information is positively correlated with the requirement matching score.

[0235] In some embodiments, the call chain filtering module 94 is specifically used to: determine the N call chains with the highest total scores based on the total scores of all call chains, the N call chains with the highest total scores satisfy the preset filtering conditions, where N is a positive integer, and set all N call chains as target call chains.

[0236] In some embodiments, the code acquisition module 91 is specifically used to: acquire code commit identifiers, acquire multiple original change files in a preset code repository based on the code commit identifiers, perform an invalid change file filtering operation on the multiple original change files to obtain one or more valid change files, and identify front-end change files and back-end change files from the one or more valid change files based on preset naming characteristics.

[0237] In some embodiments, the code change file includes a front-end change file and a back-end change file, and the front-end and back-end change data includes front-end change data and back-end change data. The code acquisition module 91 is specifically used for: when the code change file is a front-end change file, determining the front-end code change path based on the front-end change file, using the front-end code change path as a search condition, querying in the code knowledge graph whether the front-end code region corresponding to the front-end code change path is a script region, and in response to the front-end code region corresponding to the front-end code change path being a script region, finding the front-end code region corresponding to the front-end code change path in a preset local clone repository, and extracting the front-end change data and the front-end function that has changed based on the front-end code region; and / or, when the code change file is a back-end change file, determining the back-end code change path based on the back-end change file, finding the back-end code region corresponding to the back-end code change path in a preset local clone repository, and extracting the back-end change data and the back-end function that has changed based on the back-end code region.

[0238] In some embodiments, the graph generation module 93 is specifically used to: obtain the front-end source code and back-end source code of the project to which the code change file belongs; generate a front-end call chain based on the front-end source code; generate a front-end subgraph based on multiple front-end call chains; generate a back-end call chain based on the back-end source code; generate a back-end subgraph based on multiple back-end call chains; and perform a graph fusion operation on the front-end subgraph and the back-end subgraph to obtain a code knowledge graph.

[0239] In some embodiments, the map generation module 93 is specifically used to: perform region decomposition and line number positioning in the front-end source code based on a preset stack counter to obtain multiple code regions, the multiple code regions including script regions, template regions and style regions; determine the front-end call relationship based on the script regions and template regions, the front-end call relationship is used to represent the call relationship between front-end interactive components, front-end method bodies and front-end call interfaces; determine the front-end call description information based on each code region, the front-end call description information is used to describe the link status of the front-end call chain; and generate the front-end call chain based on the front-end call description information and the front-end call relationship.

[0240] In some embodiments, the graph generation module 93 is further specifically used to: determine the backend call interface based on the backend source code; generate the backend call relationship based on the backend source code; the backend call relationship is used to describe the call relationship between the backend call interface and the backend method body of the backend; generate backend call description information based on the backend source code; the backend call description information is used to describe the link status of the backend call chain; and generate the backend call chain based on the backend call interface, the backend call relationship and the backend call description information.

[0241] In some embodiments, the graph generation module 93 is further specifically used to: extract component information and event binding relationships based on the template region, extract the front-end method body and the method content of the front-end method body based on the script region, extract the front-end call interface that the front-end method body needs to call based on the script region, and generate front-end call relationships based on the mapping relationship between component paths and event handling function names in the template region, the method content of the front-end method body in the script region, and the front-end call interface.

[0242] In some embodiments, the graph generation module 93 is further specifically used to: extract multiple backend method bodies from the backend source code, perform a forward call relationship parsing operation on the multiple backend method bodies to obtain a forward call relationship, perform a reverse call relationship parsing operation on the multiple backend method bodies to obtain a reverse call relationship, and generate a backend call relationship based on the forward call relationship and the reverse call relationship.

[0243] In some embodiments, the graph generation module 93 is further specifically used to: extract various interface titles based on the template region, extract component information based on the template region, extract the call source information of functional functions based on the script region, and generate front-end call description information based on the code position of each code region, various interface titles, component information, and call source information of functional functions.

[0244] In some embodiments, the graph generation module 93 is further specifically used to: obtain method annotation information of the backend method body based on the backend source code; obtain variable type information based on the backend source code; perform expression simplification operation based on the backend source code to obtain caller type information; parse the import statement of the backend source code to obtain class name mapping information; obtain interface annotation information based on the backend source code; and generate backend call description information based on the method signature, method body position, method annotation information, variable type information, caller type information, class name mapping information, and interface annotation information of the backend method body.

[0245] In some embodiments, the front-end subgraph includes multiple front-end call chains, and the back-end subgraph includes multiple back-end call chains. The graph generation module 93 is specifically used to: in response to the interface address of the front-end call interface of the front-end call chain being consistent with the interface address of the back-end call interface of the back-end call chain, establish a mapping relationship between the front-end call interface and the back-end call interface, so that the front-end subgraph and the back-end subgraph form a code knowledge graph.

[0246] It should be noted that the test case generation apparatus described above can execute the test case generation method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the execution method. Technical details not described in detail in the test case generation apparatus embodiments can be found in the test case generation method provided in the embodiments of this application.

[0247] See Figure 10 , Figure 10 This is a schematic diagram of a computer device provided in an embodiment of this application. The computer device 100 includes one or more processors 101 and a memory 102. The memory 102 is connected to one or more processors 101, for example, via a bus.

[0248] Processor 101 is configured to support the computer device in performing the corresponding functions in the methods described in the above method embodiments. The processor may be a central processing unit (CPU), a network processor (NP), a hardware chip, or any combination thereof. The aforementioned hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0249] Memory 102 is used to store program code, etc. Memory may include volatile memory (VM), such as random access memory (RAM); memory may also include non-volatile memory (NVM), such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); memory may also include combinations of the above types of memory.

[0250] The memory 102 can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the test case generation method in the embodiments of this application. The processor executes the various functional applications and data processing of the test case generation method and test case generation apparatus by running the non-volatile software programs, instructions, and modules stored in the memory, thereby realizing the functions of each module or unit of the test case generation method and test case generation apparatus provided in the above method embodiments.

[0251] The memory 102 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function. The data storage area may store data created based on the use of the test case generation device. In some embodiments, the memory may optionally include memory remotely located relative to the processor, which can be connected to the test case generation device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0252] The one or more modules are stored in the memory. When executed by the one or more processors, they execute the test case generation method in any of the above method embodiments. For example, they execute the method steps described in the above method embodiments to implement the functions of the modules described in the above device embodiments.

[0253] This application also provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a computer device, cause the computer device to perform the method described in the foregoing embodiments.

[0254] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0255] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A method for generating test cases, characterized in that, include: Obtain the code change file; Based on the code change file, the front-end and back-end change data are determined. The front-end and back-end change data includes a set of change functions, which is a collection of function functions that have changed on the front-end and function functions that have changed on the back-end. Obtain a code knowledge graph, which includes multiple call chains, each of which represents the function call relationship generated between the front end and the back end by the triggering event; Perform a content matching operation on the call chain and the changed function set to obtain a content matching score corresponding to the call chain; Obtain test requirement information; Based on the test requirement information, a requirement matching score is determined for the call chain. The requirement matching score is used to reflect the degree of matching between the functional description information of the call chain and the test requirement information. The total score of the call chain is determined based on the content matching score and the demand matching score of the call chain. The target call chains are selected based on the total score of all call chains and the preset filtering criteria. The target call chain and the front-end and back-end change data are input into a pre-trained large language model, so that the large language model performs a test case generation operation to obtain test cases.

2. The generation method according to claim 1, characterized in that, Perform a content matching operation on the call chain and the changed function set to obtain a content matching score corresponding to the call chain, including: The number of functional functions that have undergone changes in the call chain is determined based on the set of changed functions. Calculate the ratio of the stated number to the total number of function calls contained in the call chain; In response to the ratio being greater than or equal to a preset first value, the content matching score corresponding to the call chain is set to the first score; In response to the ratio being less than the first value and greater than or equal to a preset second value, the content matching score corresponding to the call chain is set to the second score; In response to the ratio being less than the second value and greater than a preset third value, the content matching score corresponding to the call chain is set to a third score, wherein the third score is less than the second score and the second score is less than the first score.

3. The generation method according to claim 1, characterized in that, Determining the requirement matching score corresponding to the call chain based on the test requirement information includes: Obtain the functional description information of the call chain; The test requirement information, the functional description information of all call chains, and the preset system prompt words are all input into the large language model, so that the large language model performs a requirement matching score calculation operation to obtain the requirement matching score of each call chain. The semantic matching degree between the functional description information of the call chain and the test requirement information is positively correlated with the requirement matching score.

4. The generation method according to claim 1, characterized in that, The step of selecting target call chains based on the total score of all call chains and meeting preset filtering criteria includes: The N call chains with the highest total scores are determined based on the total scores of all call chains. The N call chains with the highest total scores meet the preset filtering conditions, where N is a positive integer. Set all N call chains as the target call chain.

5. The generation method according to claim 1, characterized in that, The code change files include front-end change files and back-end change files. Obtaining the code change files includes: Get the code commit identifier; Based on the code commit identifier, retrieve multiple original change files from the preset code repository; Perform an invalid change file filtering operation on multiple original change files to obtain one or more valid change files; Based on preset naming characteristics, front-end change files and back-end change files are identified from one or more of the valid change files.

6. The generation method according to claim 1, characterized in that, The code change files include front-end change files and back-end change files, and the front-end and back-end change data include front-end change data and back-end change data. Determining the front-end and back-end change data based on the code change files includes: If the code change file is a front-end change file, the front-end code change path is determined based on the front-end change file. Using the front-end code change path as a search condition, the code knowledge graph is queried to determine whether the front-end code region corresponding to the front-end code change path is a script region. If the front-end code region corresponding to the front-end code change path is a script region, the front-end code region corresponding to the front-end code change path is found in a preset local clone repository. Based on the front-end code region, the front-end change data and the front-end function that has been changed are extracted; and / or, When the code change file is a backend change file, the backend code change path is determined based on the backend change file. The backend code region corresponding to the backend code change path is found in the preset local clone repository. The backend change data and the backend function that has changed are extracted based on the backend code region.

7. The generation method according to any one of claims 1 to 6, characterized in that, The acquisition of the code knowledge graph includes: Obtain the front-end and back-end source code of the project to which the modified code file belongs; Generate a front-end call chain based on the aforementioned front-end source code; A front-end sub-graph is generated based on multiple front-end call chains; Generate a backend call chain based on the backend source code; A backend terminal map is generated based on multiple backend call chains; Perform a graph fusion operation on the front-end subgraph and the back-end subgraph to obtain a code knowledge graph.

8. The generation method according to claim 7, characterized in that, The step of generating a front-end call chain based on the front-end source code includes: performing region decomposition and line number positioning in the front-end source code based on a preset stack counter to obtain multiple code regions, the multiple code regions including script regions, template regions and style regions; determining front-end call relationships based on the script regions and the template regions, the front-end call relationships being used to represent the call relationships between the front-end interactive components, front-end method bodies and front-end call interfaces; determining front-end call description information based on each of the code regions, the front-end call description information being used to describe the link status of the front-end call chain; and generating a front-end call chain based on the front-end call description information and the front-end call relationships. The step of generating a backend call chain based on the backend source code includes: determining a backend call interface based on the backend source code; generating a backend call relationship based on the backend source code, wherein the backend call relationship is used to describe the call relationship between the backend call interface and the backend method body of the backend; generating backend call description information based on the backend source code, wherein the backend call description information is used to describe the link status of the backend call chain; and generating a backend call chain based on the backend call interface, the backend call relationship, and the backend call description information.

9. The generation method according to claim 8, characterized in that, The step of determining the front-end call relationship based on the script area and the template area includes: extracting component information and event binding relationship based on the template area; extracting the front-end method body and method content of the front-end method body based on the script area; extracting the front-end call interface that the front-end method body needs to call based on the script area; and generating the front-end call relationship based on the mapping relationship between component path and event handling function name in the template area, the method content of the front-end method body in the script area, and the front-end call interface. The step of generating backend call relationships based on the backend source code includes: extracting multiple backend method bodies from the backend source code; performing a forward call relationship parsing operation on the multiple backend method bodies to obtain a forward call relationship; performing a reverse call relationship parsing operation on the multiple backend method bodies to obtain a reverse call relationship; and generating backend call relationships based on the forward call relationship and the reverse call relationship.

10. The generation method according to claim 8, characterized in that, The step of determining the front-end call description information based on each of the code regions includes: extracting various interface titles based on the template region, extracting component information based on the template region, extracting the call source information of the function based on the script region, and generating front-end call description information based on the code position of each of the code regions, the various interface titles, the component information, and the call source information of the function. The step of generating backend call description information based on the backend source code includes: obtaining method annotation information of the backend method body based on the backend source code; obtaining variable type information based on the backend source code; performing expression simplification operations based on the backend source code to obtain caller type information; parsing the import statements of the backend source code to obtain class name mapping information; obtaining interface annotation information based on the backend source code; and generating backend call description information based on the method signature, method body position, method annotation information, variable type information, caller type information, class name mapping information, and interface annotation information of the backend method body.

11. The generation method according to claim 7, characterized in that, The front-end subgraph includes multiple front-end call chains, and the back-end subgraph includes multiple back-end call chains. The step of performing a graph fusion operation on the front-end and back-end subgraphs to obtain a code knowledge graph includes: In response to the fact that the interface address of the front-end call interface of the front-end call chain is consistent with the interface address of the back-end call interface of the back-end call chain, a mapping relationship is established between the front-end call interface and the back-end call interface, so that the front-end subgraph and the back-end subgraph form a code knowledge graph.

12. A computer device, characterized in that, A memory and a processor, the memory being connected to the processor, the processor being configured to execute one or more computer programs stored in the memory, the processor, when executing the one or more computer programs, causing the computer device to implement the test case generation method as described in any one of claims 1-11.

Images