Intelligent automatic scene testing method and system based on code change detection
By using an intelligent automated scenario testing method based on code change detection, test tasks are automatically created, solving the problems of incomplete test coverage and redundancy in Java projects with rapid iteration. This achieves full-process automation and accurate testing, adapting to the needs of high-frequency iteration.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- JIANGSU ZHIJIAN LOGISTICS CO LTD
- Filing Date
- 2025-12-29
- Publication Date
- 2026-04-17
AI Technical Summary
Existing automated testing platforms struggle to adapt to the rapid iteration requirements of Java projects. They lack in-depth analysis of code structure, resulting in incomplete or redundant test coverage. Furthermore, the code repository and testing platform lack effective linkage, requiring manual synchronization of code differences, leading to fragmented processes that are prone to errors.
The intelligent automated scenario testing method based on code change detection automatically creates test tasks by parsing code difference details, realizing full automation of the process from code submission to test task execution, including code difference comparison, parsing, and test task generation.
It achieves fully automated testing without human intervention, accurately locates the impact of code changes, avoids redundant testing, reduces operation and maintenance costs, and adapts to rapid iteration requirements.
Smart Images
Figure CN121880192A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of artificial intelligence technology, and in particular to an intelligent automated scenario testing method and system based on code change detection. Background Technology
[0002] With the accelerating pace of software development and iteration, automated testing has become a core component in ensuring project quality. This is especially true in Java projects with complex business scenarios and numerous API call chains, such as logistics and transportation, where the accuracy and efficiency of testing directly impact system delivery efficiency and deployment stability. However, current automated testing processes still face many industry pain points, and traditional solutions struggle to adapt to the demands of rapid iteration in development.
[0003] Existing automated testing platforms generally rely on manual intervention. After code changes, testers must manually select interfaces and scenarios to be verified, which is not only inefficient but also prone to overlooking critical business scenarios. Furthermore, they lack in-depth analysis capabilities of code structure (classes, methods, call relationships), making it impossible to accurately pinpoint the impact of code modifications, resulting in incomplete test coverage or prominent redundant testing issues. In addition, the code repository and testing platform lack effective linkage, requiring manual synchronization of code difference information and manual creation of test tasks. This fragmented process is prone to errors and makes it difficult to form a closed loop of "code change → test task".
[0004] Traditional solutions, such as manually sorting out the affected interfaces and batch testing based on file extensions, have limitations such as being time-consuming, inflexible, and costly to maintain, and cannot meet the rapid iteration needs of large-scale projects.
[0005] Therefore, there is an urgent need for a method that can automatically associate code changes, accurately locate the scope of impact, and automatically create test tasks. Summary of the Invention
[0006] In view of this, the present invention proposes an intelligent automated scenario testing method and system based on code change detection, which can accurately trace the affected interfaces based on code changes and automatically create and execute test tasks throughout the entire process.
[0007] To achieve the above objectives, the present invention provides the following technical solution: An intelligent automated scenario testing method based on code change detection includes: In response to a commit operation on the development branch, the code change detection interface is triggered to obtain details of the code differences; In response to the deployment of the development branch code to the test environment, the code parsing interface is triggered to parse the code difference details and obtain the code parsing results; A test task is created based on the code parsing results; The automated testing platform is invoked to execute the test task and return the test results.
[0008] Based on the above technical solution, the present invention can be further improved as follows: Optionally, the trigger code change detection interface obtains code difference details, including: The development branch code and the main branch code are compared to obtain code difference details, which include changed files and changed line number ranges.
[0009] Optionally, after obtaining the code difference details step, the following may be included: The details of the code differences are stored in the file difference information table.
[0010] Optionally, the code parsing results include the classes, methods, and call relationships of the development branch.
[0011] Optionally, after the step of parsing the code difference details to obtain the code parsing result, the following steps are included: Store the class in the branch resolution information table, the method in the method information table, and the call relationship in the method call relationship table.
[0012] Optionally, creating a test task based on the code parsing results includes: Query the file difference information table to obtain code difference details; Query the method information table, match the affected methods that are associated with the code difference details, and generate a list of affected methods; Based on the method call relationship table, the call chain of the affected methods is traced to generate a list of affected interfaces; Create a test task based on the list of affected interfaces.
[0013] Optionally, after the step of matching affected methods associated with the code difference details and generating a list of affected methods, the following steps are included: Perform uniqueness verification on the interface paths in the affected interface list, remove duplicate interface paths, and generate a deduplicated target interface list.
[0014] An intelligent automated scenario testing system based on code change detection includes: The change detection module is used to respond to the commit operation of the development branch code, trigger the code change detection interface, and obtain details of code differences; The code parsing module is used to respond to the deployment of the development branch code to the test environment, trigger the code parsing interface, and parse the code difference details to obtain the code parsing results; The task creation module is used to trigger the test task creation interface in response to the completion of code parsing, and to create test tasks based on the code parsing results; The test execution module is used to call the automated testing platform to execute the test tasks and return the test results.
[0015] An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the method described herein.
[0016] A non-transitory computer-readable storage medium having a computer program stored thereon, the computer program implementing the steps of the method when executed by a processor.
[0017] The present invention has the following advantages: The intelligent automated scenario testing method based on code change detection in this invention realizes the automatic triggering of the entire process from code submission to test task execution without manual intervention, which greatly improves testing efficiency; accurately locates the impact range of code changes on development branches, avoiding redundant testing and scenario omissions; and establishes a closed loop between the code repository and the testing platform to adapt to rapid iteration requirements and reduce operation and maintenance costs. Attached Figure Description
[0018] For illustrative and not limiting purposes, the present invention will now be described in conjunction with embodiments and accompanying drawings, wherein: Figure 1 This is a schematic diagram of the first process of the intelligent automated scenario testing method based on code change detection in an embodiment of the present invention; Figure 2 This is a schematic diagram of the second process of the intelligent automated scenario testing method based on code change detection in an embodiment of the present invention; Figure 3 This is a schematic diagram of the main components of the intelligent automated scenario testing system based on code change detection in an embodiment of the present invention; Figure 4 This is a schematic diagram of the physical structure of the electronic device provided by the present invention. Detailed Implementation
[0019] To enable those skilled in the art to better understand the present invention, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0020] It should be noted that the terms "first," "second," etc., in the specification and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be used interchangeably where appropriate for the embodiments of the invention described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0021] It should be noted that, where there is no conflict, the embodiments and features of the present invention can be combined with each other. The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.
[0022] Figure 1 This is a schematic diagram of the first process of the intelligent automated scenario testing method based on code change detection in an embodiment of the present invention, as shown below. Figure 1 As shown, the intelligent automated scenario testing method based on code change detection provided in this embodiment of the invention includes the following steps S101 to S104.
[0023] S101, in response to a commit operation on the development branch code, triggers the code change detection interface to obtain details of code differences.
[0024] The development branch code and the main branch code are compared to obtain code difference details, which include changed files and changed line number ranges.
[0025] The details of the code differences are stored in the file difference information table.
[0026] After developers commit the development branch code to the GitLab development branch, Git CI / CD triggers the "Generate Git Code Change Interface" ( / api / code / analysis / branch / getGitDiffInfo) call; the interface synchronizes the development branch code to the local machine, compares the differences with the main branch, stores the branch information (service name, branch name, commit identifier) in the git_diff_branch_info table, and stores the difference details (file name, new and old file line numbers) in the file difference information table (git_diff_branch_info table).
[0027] Code change detection technology: Branch code synchronization: Synchronize the development branch code to the local machine. If the branch already exists locally, update the code; otherwise, create the branch and synchronize it.
[0028] Branch difference comparison: Obtain the code differences between the development branch and the main branch through Git interfaces (such as git diff) and parse the list of difference information.
[0029] Difference details extraction: Extract the changed file name (full path), the start / end line number of the old file change, and the start / end line number of the new file change from each difference information, and store them in the git_diff_info table; at the same time, record the basic branch information (service name, branch name, latest commit identifier) in the git_diff_branch_info table.
[0030] S102, in response to the operation of deploying development branch code to the test environment, triggers the code parsing interface to parse the code difference details and obtain the code parsing results.
[0031] Obtain the classes, methods, and calling relationships of the aforementioned development branch; The code parsing results are obtained based on the classes, methods, and call relationships of the aforementioned development branches.
[0032] Store the class in the branch resolution information table, the method in the method information table, and the call relationship in the method call relationship table.
[0033] After the service is deployed to the test environment, the system triggers the "Project Code Analysis Interface" ( / api / code / analysis / branch / parseProject). The interface uses asynchronous processing to synchronize the GitLab project code. It extracts classes, methods and call relationships through the static code parsing module and stores them in parser_branch_info (branch parsing information table), parser_method_info (method information table), and parser_method_call_info (method call relationship table), respectively.
[0034] Synchronize code from GitLab to the local directory based on the project name and branch name, and traverse the src / main / java directory to obtain all Java files (unifying the code directory structure to ensure no omissions).
[0035] The StaticJavaParser, based on Jparser, reads Java files and generates the root node CompilationUnit of the Abstract Syntax Tree (AST). It then traverses the AST using the Visitor pattern. Class information extraction: Parse the ClassOrInterfaceDeclaration node to obtain the fully qualified class name (package name + class name); Method information extraction: During class node traversal, nested MethodVisitor extracts the method name, parameter type (generating a unique method identifier: method name + parameter type), start / end line number, and whether it is a Controller interface (if the class belongs to the Controller layer, httpApiFlag=1 and record the interface path pathName). Method call relationship: During the method information extraction process, the MethodCallExpr object list in the method is parsed to extract method call information, including the method name and parameter names.
[0036] Data storage: Store method information in the parser_method_info table, and store the method call relationship (caller class identifier, caller method identifier, callee class identifier, callee method identifier) in the parser_method_call_info table.
[0037] S103, create test tasks based on code parsing results.
[0038] Query the file difference information table to obtain code difference details; Query the method information table, match the affected methods that are associated with the code difference details, and generate a list of affected methods; Based on the method call relationship table, the call chain of the affected methods is traced to generate a list of affected interfaces; After the step of matching affected methods that are associated with the code difference details and generating a list of affected methods, the following steps are included: Perform uniqueness verification on the interface paths in the affected interface list, remove duplicate interface paths, and generate a deduplicated target interface list.
[0039] Create a test task based on the list of affected interfaces.
[0040] Specifically: After the code parsing is complete, the system triggers the "Create Automated Test Task Interface Based on Code Changes" ( / api / code / analysis / branch / autoTest); the interface executes the following logic: Step 1: Query git_diff_info to get code change details (changed files, line number range); Step 2: Query parser_method_info to find methods whose "change line number and method line number intersect", and generate a list of affected methods; Step 3: Trace the call chain of the affected methods through parser_method_call_info until the method with httpApiFlag=1 (Controller interface) is found, and collect the interface path (pathName) to form a list of affected interfaces; Step 4: Call the automated testing platform API to create a test task based on the list of affected interfaces.
[0041] Method matching logic: The CommonUtil.checkOverlap method is used to determine whether there is an intersection between the "code change line number range" and the "method line number range", and the methods affected by the change are matched.
[0042] Call chain tracing logic: Based on the call relationship in the parser_method_call_info table, a "breadth-first traversal" is used to trace the callers of the affected methods until there are no parent callers; during the process, methods with httpApiFlag=1 are selected, and their interface paths pathName are collected to form a list of affected interfaces.
[0043] Deduplication: Deduplication is performed using the interface path (pathName) to prevent the same interface from being added to the test task repeatedly.
[0044] S104 calls the automated testing platform to execute the test task and returns the test results.
[0045] The automated testing platform executes tasks and returns results, allowing testers to view interface test reports and guide developers in optimizing code.
[0046] One embodiment is as follows: Taking the "order module development" of a logistics and transportation system as an example, the application process of this method is explained: Scenario: Developers are developing the "Create Order" function in the "Order Module" (com.fuyoukache.order package) of the logistics system. They modify the createOrder method in OrderController.java and commit the code to the dev-order branch.
[0047] Change detection: After code is committed, the getGitDiffInfo interface is triggered to synchronize the dev-order branch code, compare the differences with the master branch, and find that there are changes in lines 100-120 of OrderController.java. The difference information is stored in the git_diff_info table.
[0048] Code Analysis: After the dev-order branch is deployed to the test environment, the parseProject interface is triggered to parse OrderController.java: Extract information about the createOrder method (method identifier: createOrder(String, Integer), line number: 95-125, httpApiFlag=1, pathName= / api / order / create); Extract the call relationship (createOrder calls orderService.save) and store it in the parser_method_call_info table.
[0049] Test task creation: Trigger the autoTest interface, match the createOrder method corresponding to the change line number (100-120), trace it back to the Controller interface, and call the automated testing platform to create the test task via the / api / order / create interface.
[0050] Test execution: The test platform executes tasks to verify the parameter validation and business logic correctness of the "Create Order" interface and outputs a test report; if the test passes, the iteration is completed, and if it fails, feedback is sent to the development team for fixes.
[0051] All three core interfaces of this invention support passing in projectName (project name) and branchName (branch name), and return a status object (code: 0 = success, 1 = failure; desc: operation description), as shown in Table 1:
[0052] Table 1
[0053] Integration with GitLab: Implement functions such as code cloning, branch switching, and diff querying through the JgitUtil utility class; Integration with automated testing platforms: Pass the list of affected interfaces via HTTP requests to trigger the creation of test tasks.
[0054] In this invention: Static code analysis involves analyzing project code without running it. It uses specific tools and techniques to parse information such as classes, methods, and method call relationships to understand the code's structure and logic. In this system, Jparser is used to extract key information from Java code.
[0055] Code change detection examines the differences between development branch code and main branch code during development. By comparing these differences, it identifies the modified code content, such as the files and scope of the changed code, thereby determining the extent of the code changes.
[0056] The list of affected interfaces is generated by "changing methods → calling chain tracing → filtering controller layer methods" based on the externally exposed interfaces (controller layer methods) affected by code changes. An automated testing platform is an external system that provides automated scenario testing capabilities. It can create automated test tasks related to interfaces based on an interface list. This system uses it to create automated test tasks for interfaces affected by code changes.
[0057] The key database tables store core data from the system's execution process. These include tables related to static code analysis: `parser_branch_info` (code analysis branch information), `parser_method_info` (method information), and `parser_method_call_info` (method call relationship table), as well as tables related to code change detection: `git_diff_branch_info` (code difference branch information) and `git_diff_info` (detailed code difference information).
[0058] Figure 2 This is a schematic diagram of the second process of the intelligent automated scenario testing method based on code change detection in an embodiment of the present invention, as shown below. Figure 2 As shown, this illustrates the entire collaborative process from code changes to the execution of automated test tasks, which can be broken down into three layers: "system interaction layer, core function layer, and data storage layer." I. System Interaction Layer (Top Layer) External systems: These represent the business systems that need to be tested (such as logistics, e-commerce, etc.), and provide "code repository / testing functionality" (presumably the entry point for triggering code changes and applying test results).
[0059] GitLab system: code repository, responsible for storing code, recording code changes (commits, branch merging, etc.), and providing "code synchronization / difference query" capabilities (providing the test system with the original code and change data).
[0060] Automated testing platform: The platform that ultimately executes test tasks. It receives and executes tasks issued by the testing system through the "Create Test Task" interface.
[0061] Project code analysis interface: the entry point for code parsing, triggering the core capability of "static code parsing" (analyzing code structure, methods, and call relationships).
[0062] Generate Git code change API: Triggers the core capability of "code change detection" (compares branch code differences and generates change details).
[0063] Create Automated Test Task Interface: Triggers the "Create Test Task" process, converting the parsed code changes into test tasks.
[0064] II. Core Functional Layer (Middle Layer) Interface Function: The system's "central scheduling layer" is responsible for receiving requests from upper-layer systems (GitLab, automated testing platforms, etc.) and calling "core capabilities" to complete tasks.
[0065] Calling core capabilities: Includes three core functions: Static code analysis: Analyzes the code structure (classes, methods, call relationships) to provide a basis for accurately locating the scope of impact of code changes (corresponding to the "code analysis interface" in the patent).
[0066] Code change detection: Compare the code of the development branch with the base branch to generate change details (corresponding to the "code change detection interface" in the patent).
[0067] Create test tasks: Generate and issue test tasks based on code analysis results and change details.
[0068] III. Data Storage Layer (Bottom Layer) Core module: The logical layer that connects data storage and core functions, ensuring data flow.
[0069] Code parsing related tables: Store static code parsing results (such as class, method, and call relationship data) to support the function of "precisely locating affected interfaces".
[0070] Code change detection related tables: Store details of code changes (such as changed files, line numbers, and branch comparison data) to provide a basis for test task creation.
[0071] Database storage: The above data is persistently stored to ensure that the system is traceable and analyzable.
[0072] IV. Overall Process Logic Code change trigger: After code is committed to the development branch, the GitLab system triggers "code change detection" through the "Generate Git Code Change Interface", compares the branch differences, generates code difference details, and stores them in the "Code Change Detection Related Table".
[0073] Code parsing: After the code is deployed to the test environment, the "Static code parsing" is triggered through the "Project code analysis interface" to analyze the code structure, generate parsing results, and store them in the "Code parsing related table".
[0074] Test task creation: The interface function layer calls the "Create Test Task" capability, and combines "Code Difference Details + Parsing Results" to issue test tasks to the automated testing platform through the "Create Automated Test Task Interface".
[0075] Test execution and feedback: The automated testing platform executes tasks, and the results can be fed back to "external systems" (such as for business verification and defect repair).
[0076] This invention breaks through the traditional "manually sorting out the scope of impact" model. Based on the method call chain of static code parsing and the matching of code change line numbers, it automatically locates the affected external interfaces and realizes the mapping of "code change → affected interface" without manual intervention.
[0077] The project code analysis interface adopts asynchronous processing (AsyncUtils task submission) to avoid interface blocking caused by parsing large-scale projects (such as 100,000 lines of code), improve system response efficiency, and adapt to high-frequency code submission scenarios.
[0078] Decoupled integration with GitLab and automated testing platforms is achieved through standardized utility classes (JgitUtil, HTTP client), supporting the replacement of code repositories (such as GitLab → GitHub) or testing platforms (such as custom testing systems) without modifying the core logic.
[0079] Based on "line number range intersection judgment" (CommonUtil.checkOverlap) and "unique method identifier" (class full path + method name + parameter type), this method ensures that the matching of changed methods is complete and without redundancy, thus solving the problem of insufficient accuracy in traditional "file-level matching". The comparison results between this invention and traditional solutions are shown in Table 2; Table 2
[0080] This invention automatically completes code change detection, affected interface location, and test task creation, reducing test preparation time from "hours" to "minutes," adapting to the high-frequency iteration requirements of agile development. Based on static code analysis and call chain tracing, it accurately locates affected interfaces, avoiding the risk of missed tests (such as missing indirectly called interfaces) and redundant tests (such as testing unchanged interfaces) that are inherent to traditional manual judgment. Testers are not required to manually analyze the scope of impact or create test tasks, reducing manpower investment; external system integration is decoupled, and core code does not need to be refactored when adding new business modules or replacing tools. Designed for the code structure of Java projects in the logistics and transportation industry (such as standardized Controller layer interfaces and clear service layering), it can be directly applied to the testing of core modules such as orders, drivers, and freight, ensuring the stability of business functions. It can be embedded in CI / CD pipelines (such as Jenkins) to achieve full-process automation of "code submission → automatic testing → deployment," accelerating project delivery cycles.
[0081] Figure 3 This is a schematic diagram illustrating the main components of the intelligent automated scenario testing system based on code change detection according to an embodiment of the present invention. Figure 3 As shown, the intelligent automated scenario testing system 1 based on code change detection provided in this embodiment of the invention includes a change detection module 10, a code parsing module 20, a task creation module 30, and a test execution module 40.
[0082] The change detection module 10 is used to respond to the commit operation of the development branch code, trigger the code change detection interface, and obtain details of code differences; The code parsing module 20 is used to respond to the operation of deploying the development branch code to the test environment, trigger the code parsing interface, and parse the code difference details to obtain the code parsing result; Task creation module 30 is used to create test tasks based on the code parsing results; The test execution module 40 is used to call the automated testing platform to execute the test tasks and return the test results.
[0083] The intelligent automated scenario testing system based on code change detection in this invention adopts a layered architecture design, with clear responsibilities and low coupling between each layer, as shown in Table 3: Table 3
[0084] The operating environment is shown in Table 4; Table 4
[0085] Figure 4 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of the present invention, such as... Figure 4 As shown, the electronic device 50 includes: a processor 501, a memory 502, and a bus 503; The processor 501 and the memory 502 communicate with each other via the bus 503. The processor 501 is used to call program instructions in the memory 502 to execute the methods provided in the above-described method embodiments, and to execute the methods provided in the embodiments of the present invention.
[0086] This embodiment provides a non-transitory computer-readable storage medium that stores computer instructions, which cause a computer to execute the method provided in this embodiment of the invention.
[0087] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various storage media capable of storing program code, such as ROM, RAM, magnetic disk, or optical disk.
[0088] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.
Claims
1. An intelligent automated scenario testing method based on code change detection, characterized in that, include: In response to a commit operation on the development branch, the code change detection interface is triggered to obtain details of the code differences; In response to the deployment of the development branch code to the test environment, the code parsing interface is triggered to parse the code difference details and obtain the code parsing results; A test task is created based on the code parsing results; The automated testing platform is invoked to execute the test task and return the test results.
2. The intelligent automated scenario testing method based on code change detection according to claim 1, characterized in that, The triggered code change detection interface obtains details of code differences, including: The development branch code and the main branch code are compared to obtain code difference details, which include changed files and changed line number ranges.
3. The intelligent automated scenario testing method based on code change detection according to claim 2, characterized in that, After obtaining the code difference details, the steps include: The details of the code differences are stored in the file difference information table.
4. The intelligent automated scenario testing method based on code change detection according to claim 3, characterized in that, The code parsing results include the classes, methods, and call relationships of the development branch.
5. The intelligent automated scenario testing method based on code change detection according to claim 4, characterized in that, After parsing the code difference details to obtain the code parsing result, the following steps are included: Store the class in the branch resolution information table, the method in the method information table, and the call relationship in the method call relationship table.
6. The intelligent automated scenario testing method based on code change detection according to claim 5, characterized in that, The creation of a test task based on the code parsing results includes: Query the file difference information table to obtain code difference details; Query the method information table, match the affected methods that are associated with the code difference details, and generate a list of affected methods; Based on the method call relationship table, the call chain of the affected methods is traced to generate a list of affected interfaces; Create a test task based on the list of affected interfaces.
7. The intelligent automated scenario testing method based on code change detection according to claim 6, characterized in that, After the step of matching affected methods that are associated with the code difference details and generating a list of affected methods, the following steps are included: Perform uniqueness verification on the interface paths in the affected interface list, remove duplicate interface paths, and generate a deduplicated target interface list.
8. A system for intelligent automated scenario testing based on code change detection, characterized in that, include: The change detection module is used to respond to the commit operation of the development branch code, trigger the code change detection interface, and obtain details of code differences; The code parsing module is used to respond to the deployment of the development branch code to the test environment, trigger the code parsing interface, and parse the code difference details to obtain the code parsing results; The task creation module is used to trigger the test task creation interface in response to the completion of code parsing, and to create test tasks based on the code parsing results; The test execution module is used to call the automated testing platform to execute the test tasks and return the test results.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.
10. A non-transitory computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.