Browser-based debugging and ai-generated front-end testing system and control method

Abstract

This invention provides a front-end testing system and its control method based on browser debugging and AI generation. The system includes an input module, an automated control adaptation layer, a debugging protocol collector, a test evidence package builder, a test case generation orchestrator, an AI code generation engine, a script quality gate, and a self-healing and backfeeding module. The self-healing and backfeeding module is data-connected to the script quality gate to determine the failure reasons of failed test script drafts and to use corresponding strategies to correct the failed test script drafts, effectively improving test case construction efficiency. The test intent structure, structured evidence package information, and test constraint template drive the AI ​​code generation engine to generate test script drafts, reducing reliance on manual writing and positioning, as well as waiting for experience, shortening the path from requirement documents to executable test cases, reducing manual dependence, and improving bridging stability.

Description

Technical Field

[0001] This invention relates to the technical field of software testing, specifically to a front-end testing system and its control method based on browser debugging and AI generation. Background Technology

[0002] Existing front-end automated testing typically relies on manually written scripts: testers need to understand the page structure, locate elements, handle asynchronous operations and pop-ups, maintain selectors, and complete assertions and wait conditions, etc. With frequent front-end iterations and the increasing use of components and dynamic rendering, traditional methods generally suffer from the following defects and shortcomings: 1) High use case construction cost: There is a lack of automated bridging between requirements documents and operation paths and executable scripts; or even if bridging exists, selectors and timing conditions mostly rely on human experience, making the bridging fragile. 2) Location and assertion are fragile and cannot automatically generate high-quality assertions: Most assertion generation only covers operation steps, lacks repeatable verifiable assertions and reproducible environmental constraints, and changes in the Document Object Model (DOM) can easily cause selectors to fail, resulting in frequent script maintenance. 3) Insufficient observability: It is difficult to reliably determine the internal state of the page and the actual business results based solely on interface interaction behavior (such as clicks and screenshots), such as network requests, rendering completion, console errors, performance lag, etc. 4) Slow test case accumulation and low regression efficiency: It is difficult to automatically accumulate and cover boundary scenarios and abnormal links, which requires manual supplementation and is time-consuming. When requirements change, regression test cases are difficult to update in a timely manner.

[0003] Therefore, there is an urgent need to provide a new solution to address the defects and shortcomings of the existing technologies. Summary of the Invention

[0004] To address the shortcomings and deficiencies in the existing technologies, this invention provides a front-end testing system and its control method based on browser debugging and AI generation.

[0005] The specific solution provided by this invention is as follows: A front-end testing system based on browser debugging and AI generation, characterized in that: the system includes: The input module receives user requirement documents and user operation paths, or user requirement documents and recorded business action trajectories, and parses the test intent structure from them. An automation control adaptation layer is connected to the browser data to perform secondary encapsulation of the browser automation framework, thereby unifying action primitives and outputting a standard action event stream. A debugging protocol collector, which is connected to the browser data to subscribe to and pull internal browser signals based on the browser debugging protocol or its message channel; A test evidence package builder is connected to the automation control adaptation layer and the debugging protocol acquisition unit respectively to generate a structured evidence package by aligning the standard action event stream and internal signals to a unified timeline. A test case generator orchestrator is connected to the input module and the test evidence package builder to combine test intent structure, structured evidence package information and test constraint template into prompt words; The AI ​​code generation engine is connected to the test case generation orchestrator to call the AI ​​code generation model based on prompts and output test script drafts. A script quality gate is connected to the AI ​​code generation engine to verify the output test script drafts. Only after all verifications are passed can the test script drafts be stored in the database for execution. The self-healing and recharge module is connected to the script quality gate data to determine the failure reasons of the failed test script drafts and to use corresponding strategies to correct the failed test script drafts.

[0006] As a further preferred embodiment of the present invention, the test intent structure parsed in the input module includes at least the page range, test target, preconditions, key assertion points, data dependencies, optional abnormal scenarios, and optional boundary scenarios.

[0007] As a further preferred embodiment of the present invention, in the automation control adaptation layer... The action primitives include at least click, input, wait, assertion, screenshot, and route redirection primitives; Furthermore, all the action primitives described herein are in DSL format. The standard action event flow includes a structured action sequence formed by uniformly encapsulating the user operation path or business action trajectory through the automation control adaptation layer, and the standard action event flow includes at least the step number, action type, action target, input parameters and execution result fields.

[0008] As a further preferred embodiment of the present invention, in the debugging protocol collector, The browser internal signals subscribed to and pulled by the debugging protocol collector include at least the following: 1) DOM snapshot, accessibility tree, layout information and visibility information; wherein, the layout information includes at least the coordinates, size, hierarchy, relative position and occlusion relationship of page elements or nodes, and the visibility information includes at least whether the node is displayed, whether the node is in the viewport, whether the node is occluded, whether the node is interactive and the node transparency status information. 2) Network requests and responses, HTTP response status codes, and key interface payload summaries, wherein the key interfaces include at least those related to page rendering, list loading, data submission, status change, permission verification, and business result confirmation. 3) Debug potential problems, debug actual errors, uncaught exceptions, and page logs; wherein, the uncaught exceptions include at least script execution exceptions, unhandled Promise rejections, and resource loading exceptions; 4) Performance timing of navigation and summary, long tasks, and resource loading failure signals; the long tasks include tasks whose main thread continuously occupies more than a preset threshold; 5) and key status signals during page runtime; the key status signals include at least the route switching completion signal, the page ready status signal, the request idle signal, the global loading end signal, and the global status change signal.

[0009] As a further preferred embodiment of the present invention, the test evidence package builder aligns the standard action event stream and internal signals to a unified timeline, and then generates a structured evidence package by executing a desensitization and field pruning strategy. The desensitization and field pruning strategy includes the following steps: 1) Identify sensitive and non-critical fields; 2) Replace or delete the execution mask and hash code; 3) Only retain logs and performance snippets relevant to the current step; 4) Delete redundant fields and reversible personal information fields that are irrelevant to the current step; 5) Generate an anonymized, structured evidence package; The structured evidence package uses step nodes as indexes and stores DOM differential digests, key network request digests, logs and performance snippets, screenshot indexes, and video indexes related to each step node; among them, The key network request summary includes at least the request method, interface path, request time, response time, response status code, request parameters, return fields, business success flag, exception code, and time consumption information.

[0010] As a further preferred embodiment of the present invention, the test case generation orchestrator can select different prompt templates and test constraint templates according to different scenarios; wherein... The prompt templates include at least a smoke template, a regression template, an abnormal link template, and a performance sentinel template; the test constraint templates include at least an assertion and wait specification template, a retry strategy template, and a selector strategy template.

[0011] As a further preferred embodiment of the present invention, when the AI ​​code generation engine calls the AI ​​code generation model based on the prompt words and outputs a test script draft, it includes the following steps: 1) Receive prompts consisting of the test intent structure, structured evidence package information, and test constraint template; 2) Analyze the target scenario, the page to be operated on, key steps, expected assertions, and constraint rules; 3) Generate interactive actions based on the encapsulated action DSL; 4) Automatically supplement waiting conditions and assertion conditions based on the structured evidence package; 5) Output a draft of test scripts with a consistent style.

[0012] As a further preferred embodiment of the present invention, the script quality gate performs at least the following checks on the output test script draft: 1) Syntax, dependency and executability verification: The script syntax, dependency references and runtime configuration of the test script draft are verified respectively. When the verification results show that the test script draft has no syntax errors, all dependencies are complete, and the script can be loaded and executed normally, the syntax verification, dependency verification and executability verification are considered to be qualified. 2) Waiting and assertion specification verification: This verifies whether the test script draft sets up waiting and assertions according to the specification, and whether there are any unfounded fixed delays; when the verification result shows that the test script draft contains valid assertions, the waiting method conforms to the specification, and fixed delays are not used or are restricted, the waiting specification verification and assertion specification verification are deemed to be qualified. 3) Location strategy verification: Verify whether the element location method in the test script draft is stable; when the verification result shows that the test script draft only uses role, text, label or stable attribute location methods and does not use easily invalidated location methods, the location strategy verification is considered qualified. 4) Blacklist API Validation: This test script draft is used to verify whether there are any low-level interfaces or dangerous interfaces that are prohibited from being called from the blacklist. When the validation result is that there are no low-level interfaces or dangerous interfaces that are prohibited from being called from the blacklist in the test script draft, the blacklist API validation is considered to be qualified. 5) Data Cleaning Verification: Verify whether there is cleanup, rollback, or recovery logic data in the draft test script; if the verification result shows that there is no cleanup, rollback, or recovery logic data in the draft test script, the data cleanup verification is considered qualified. And it satisfies: The priority of the following checks is gradually reduced: syntax, dependency and executability checks, wait and assertion specification checks, location strategy checks, blacklist API checks, and data cleanup checks.

[0013] As a further preferred embodiment of the present invention, in the self-healing and re-feedback module, the reason for the execution failure of the test script draft is determined based on the structured evidence package of the failure point, and the reason for failure includes at least: A1) Selector drift; A2) Insufficient waiting time; A3) Interface error; A4) Unstable occlusion or animation; When revising the draft test script that failed to execute using the corresponding strategy: B1) Automatically trigger local rewriting for selector drift to promote selector self-healing; B2) Adjust the waiting strategy to address insufficient waiting; B3) Perform mock testing on interfaces for anomalies and repair the interface environment; B4) To address unstable occlusion, implement occlusion handling; to address unstable animation, perform animation stabilization operations and testing. The revised test script draft will be verified again through the script quality gate. If the verification is successful, the corresponding patch will be generated and the corresponding repair method will be re-implanted as a prompt word fragment.

[0014] Furthermore, the present invention also provides a control method for a front-end testing system based on browser debugging and AI generation, characterized by comprising the following steps: S100: The input module receives the user requirement document and user operation path or the user requirement document and recorded business action sequence, and parses the test intent structure from it; S200: The automation control adaptation layer encapsulates the browser automation framework to unify action primitives and output standard action event streams; S300: The debug protocol collector subscribes to and pulls internal browser signals based on the browser debug protocol or its message channel; S400: The test evidence package builder generates a structured evidence package by aligning the standard action event stream and internal signals to a unified timeline; S500: The test case generator orchestrator combines test intent structure, structured evidence package information, and test constraint templates into prompt words; S600: The AI ​​code generation engine calls the AI ​​code generation model based on prompts and outputs a draft test script; S700: The script quality gate verifies the output test script draft. Only after all verifications are passed can the test script draft be entered into the database for execution. S800: The self-healing and recharge module determines the reason for the failure of the test script draft and adopts the corresponding strategy to correct the failed test script draft.

[0015] Compared with existing technologies, the technical effects that this invention can achieve include: 1) This invention provides a front-end testing system and its control method based on browser debugging and AI generation, which effectively improves the efficiency of test case construction. By driving the AI ​​code generation engine to generate test script drafts through test intent structure, structured evidence package information and test constraint template, it reduces the reliance on manual writing and positioning and waiting for experience, shortens the path from requirement documents to executable test cases, reduces manual dependence, and improves bridging stability.

[0016] 2) This invention provides a front-end testing system and its control method based on browser debugging and AI generation. By re-encapsulating the browser automation framework to unify action primitives and output standard action event streams, the underlying automation capabilities are encapsulated into a stable and constrained domain-specific language (DSL), enabling the AI ​​generation engine to generate more controllable and standardized test script drafts.

[0017] 3) This invention provides a front-end testing system and its control method based on browser debugging and AI generation. By combining test intent structure, structured evidence package information and test constraint template into prompt words, it avoids generating only operation scripts, ensures that the prompt words are complete and effective, and thus improves the effectiveness and accuracy of the test script draft generated based on the prompt words.

[0018] 4) This invention provides a front-end testing system and its control method based on browser debugging and AI generation. By aligning standard action event streams and internal signals to a unified timeline, a structured evidence package is generated. This package can not only record user interface interaction behavior, but also record the internal state of the page and the actual business results, providing a calculable basis for automatic assertion and stable waiting.

[0019] 5) This invention provides a front-end testing system and its control method based on browser debugging and AI generation, which enhances observability and traceability. By aligning standard action event streams and internal signals to a unified timeline, a structured evidence package is generated. The structured evidence package binds each action step with an internal signal to form an end-to-end evidence chain, which facilitates rapid identification of failure types.

[0020] 6) This invention provides a front-end testing system and its control method based on browser debugging and AI generation. By setting up self-healing and backfeeding modules, it can determine the failure reasons of failed test script drafts and use corresponding strategies to correct the failed test script drafts. Instead of regenerating the entire failed test script draft, it makes minimal patches to the failed steps, effectively reducing maintenance costs while backfeeding the repair experience into the rules and prompt words, making the system more and more stable with use. Attached Figure Description

[0021] Figure 1 The figure shown is a schematic diagram of the system provided by the present invention.

[0022] Figure 2 The diagram shown is a flowchart illustrating the reasons for execution failure and the corresponding correction strategies in this invention.

[0023] Figure 3 The diagram shown is a flowchart of the steps of the method provided by the present invention. Detailed Implementation

[0024] 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 some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installed," "equipped with," "connected," etc., should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0026] [First Embodiment] like Figure 1 The figure shown is a front-end testing system based on browser debugging and AI generation provided in the first embodiment of the present invention. The system includes: The input module receives user requirement documents and user operation paths, or receives user requirement documents and recorded business action trajectories, and parses the test intent structure from them. The test intent structure parsed in the input module includes at least the page scope, test objective, preconditions, key assertion points, data dependencies, optional exception scenarios, and optional boundary scenarios.

[0027] An automation control adaptation layer connects to the browser data to perform secondary encapsulation of the browser automation framework, thereby unifying action primitives and outputting a standard action event stream. In this embodiment, the automation control adaptation layer can be based on Playwright encapsulation. In the automation control adaptation layer, Action primitives include at least click, input, wait, assertion, screenshot, and route redirection primitives; Furthermore, all action primitives adopt the domain-specific language DSL format. By providing action primitives in a stable and constrained DSL format, it is easy to standardize the script and minimize the replacement of subsequent self-healing patches. A standard action event stream is a structured sequence of actions formed by uniformly encapsulating user operation paths or business action trajectories through an automation control adaptation layer. A standard action event stream includes at least the following fields: step number, action type, action target, input parameters, and execution result; for example, "Login → Enter a list → Add → Save → Verify successful save".

[0028] A debug protocol collector connects to the browser to subscribe to and retrieve internal browser signals based on the browser debug protocol or its message channel. In this embodiment, the debug protocol collector can subscribe to events based on the ChromeDevTools Protocol and its message channel (such as chrome-devtools-mcp). In the debug protocol collector mentioned in this embodiment, The browser's internal signals subscribed to and pulled by the debug protocol collector include at least the following: 1) DOM snapshot, accessibility tree, layout information (such as the coordinates, size, hierarchy, relative position, occlusion relationship and other geometric layout features of page elements or nodes) and visibility information (such as whether a node is displayed, whether a node is in the viewport, whether a node is occluded, whether a node is interactive and the node's transparency status). 2) Network requests and responses, HTTP response status codes, and key interface payload summaries. The key interfaces mentioned in this embodiment include at least those related to page rendering, list loading, data submission, status change, permission verification, and business result confirmation. 3) Debug potential problems (Console error), debug actual errors (Console warn), uncaught exceptions (such as script execution exceptions, unhandled Promise rejections, resource loading related exceptions, etc.), and page logs; 4) Performance timing of navigation and summarization, long tasks, and resource loading failure signals; In this embodiment, long tasks include tasks whose main thread continuously occupies more than a preset threshold. 5) and key status signals during page operation. In this embodiment, key status signals include at least the route switching completion signal, the page ready status signal, the request idle signal, the global loading end signal, and the global status change signal.

[0029] The test evidence package builder connects to both the automation control adaptation layer and the debugging protocol collector to align standard action event streams and internal signals to a unified timeline, generating a structured evidence package. This alignment not only records user interface interactions but also internal page states and actual business results, providing a calculable basis for automatic assertions and stable waiting. Furthermore, by aligning standard action event streams and internal signals to a unified timeline, observability and traceability are enhanced. The structured evidence package binds each action step with an internal signal, forming an end-to-end evidence chain, facilitating rapid identification of failure types.

[0030] In the test evidence package builder mentioned in this embodiment, after aligning the standard action event stream and internal signals to a unified timeline, a structured evidence package is generated by executing desensitization and field pruning strategies; The desensitization and field pruning strategy includes the following steps: 1) Identify sensitive and non-critical fields; 2) Replace or delete the execution mask (including account, password, token, cookie, mobile phone number, email, ID number, etc.) and hash code; 3) For DOM, network packets, logs, performance data, etc., only retain logs and performance fragments relevant to the current step; 4) Delete redundant fields and reversible personal information fields that are irrelevant to the current step; 5) Generate an anonymized, structured evidence package; The structured evidence package is indexed by step nodes and stores DOM differential summaries, key network request summaries, log and performance snippets, screenshot indexes, and video indexes related to each step node; among them, A key network request summary should include at least the request method, interface path, request time, response time, response status code, request parameters, returned fields, business success flag, exception code, and time consumption information.

[0031] The test case generator orchestrator connects with the input module and the test evidence package builder to combine test intent structure, structured evidence package information and test constraint templates into prompt words. In this embodiment, the test case generation orchestrator can select different prompt templates and test constraint templates according to different scenarios; The prompt template is used to organize the test intent structure, structured evidence package information, target scenario description, and output format requirements; it is more focused on the organization of generated content. Test constraint templates are used to define the script rules that must be met when generating code, such as waiting methods, assertion methods, location priorities, retry rules, and cleanup rules. They are more focused on generating behavioral constraints.

[0032] In this embodiment, the prompt templates include at least a smoke template, a regression template, an anomaly link template, and a performance sentinel template; the test constraint templates include at least an assertion and wait specification template, a retry policy template, and a selector policy template; wherein, Smoke template: Used for rapid availability verification of core processes; Regression template: Used for stable regression and full-process validation of existing business links; Abnormal link template: used for scenarios such as incorrect input, failure return, boundary conditions, and exception prompts; Performance Sentinel Template: Used for performance monitoring scenarios such as critical page loading, interactive response, and resource anomalies; Assertion and Wait Specification Template: Used to constrain fixed sleep, require signal-driven wait, and must include repeatable assertions; Retry strategy template: used to limit the retryable steps, the number of retries, and the retry trigger conditions; Selector strategy template: Used to limit the priority of using role, text, label, and stable attributes to avoid fragile positioning.

[0033] The AI ​​code generation engine is connected to the test case generation orchestrator to call the AI ​​code generation model based on prompts and output a test script draft. It is worth noting that the test script draft uses a packaged action and assertion DSL to avoid directly stacking the underlying API, which would lead to inconsistent script style and reduced controllability. In the AI ​​code generation engine provided in this embodiment, the AI ​​code generation engine can call the Codex-type AI code generation model to generate TypeScript-style scripts.

[0034] In the AI ​​code generation engine provided in this embodiment, when the AI ​​code generation engine calls the AI ​​code generation model based on the prompt words and outputs a test script draft, it includes the following steps: 1) Receive prompts consisting of the test intent structure, structured evidence package information, and test constraint template; 2) Analyze the target scenario, the page to be operated on, key steps, expected assertions, and constraint rules; 3) Generate interactive actions based on the encapsulated action DSL, and use the encapsulated primitives (such as ui.clickByRole(), ui.fillSmart(), etc.). 4) Automatically supplement waiting conditions and assertion conditions based on the structured evidence package; assertion conditions are automatically extracted and completed from the evidence package: for example, key fields returned by the interface, page stability conditions (network idle + DOM stable), empty console errors, and zero resource loading failures; waiting conditions are derived from performance timing and DOM change statistics (for example, corresponding waiting logic can be automatically generated based on internal signals such as completion of key requests, stabilization of DOM changes, appearance of page prompts, no errors in the console, and completion of resource loading), prioritizing signal-driven waiting, thus prioritizing execution based on observable signals rather than relying on fixed-duration delays. This can reduce occasional failures caused by asynchronous loading, animations, and slow requests. 5) Output a draft of test scripts with a consistent style.

[0035] By using an AI code generation engine to call the AI ​​code generation model based on prompts and output test script drafts, execution stability is effectively improved. This is achieved by deriving waiting conditions from network, DOM changes, and performance timing signals in the evidence package, avoiding significant fixed delays and reducing occasional failures caused by asynchronous loading, animations, and slow requests. Furthermore, assertion quality is significantly enhanced by automatically extracting "repeatable verifiable" assertion points such as key fields returned by the API, page stability conditions, and empty console errors. This allows the script to not only perform operations but also verify its internal correctness, reducing false positives and false negatives. Ultimately, this reduces fixed delays, improves execution stability, and enhances assertion quality.

[0036] The script quality gate connects to the AI ​​code generation engine to verify the output test script drafts. Only after all verifications are passed is the test script draft sent to the test case library for execution. The test script draft, script version, associated prompt words, execution records, patch records, and rule fragments that have passed the script quality gate verification are all sent to the test case library. The test case library can be used for test script storage, version management, regression calls, and experience reinjection.

[0037] In this embodiment, the script quality gate performs at least the following checks on the output test script draft: 1) Syntax, dependency and executability verification: The script syntax, dependency references and runtime configuration of the test script draft are verified respectively. When the verification results show that the test script draft has no syntax errors, all dependencies are complete, and the script can be loaded and executed normally, the syntax verification, dependency verification and executability verification are considered to be qualified. 2) Waiting and assertion specification verification: This verifies whether the test script draft sets up waiting and assertions according to the specification, and whether there are any unfounded fixed delays; when the verification result shows that the test script draft contains valid assertions, the waiting method conforms to the specification, and fixed delays are not used or are restricted, the waiting specification verification and assertion specification verification are deemed to be qualified. 3) Location strategy verification: Verify whether the element location method in the test script draft is stable; when the verification result shows that the test script draft only uses role, text, label or stable attribute location methods and does not use easily invalidated location methods, the location strategy verification is considered qualified. 4) Blacklist API Validation: This test script draft is used to verify whether there are any low-level interfaces or dangerous interfaces that are prohibited from being called from the blacklist. When the validation result is that there are no low-level interfaces or dangerous interfaces that are prohibited from being called from the blacklist in the test script draft, the blacklist API validation is considered to be qualified. 5) Data Cleaning Verification: Verify whether there is cleanup, rollback, or recovery logic data in the draft test script; when the verification result shows that there is no cleanup, rollback, or recovery logic data in the draft test script, the data cleanup verification is deemed qualified to ensure that the environment will not be polluted or subsequent tests will not be affected after the test is completed; And it satisfies: The validation priorities for syntax, dependency and executability, wait and assertion specification validation, location strategy validation, blacklist API validation, and data cleanup validation decrease progressively. The priority is to first ensure the test script draft can run smoothly, then ensure the test script draft specification is stable, then ensure the test script draft is controlled and secure, and finally ensure the closed-loop environment for implementing the test script draft.

[0038] The self-healing and recharge module is connected to the script quality gate data to determine the reasons for the failure of the test script draft and to use corresponding strategies to correct the failed test script draft.

[0039] like Figure 2 As shown, in the self-healing and re-feedback module provided in this embodiment, the reason for the execution failure of the test script draft is determined based on the structured evidence package of the failure point. The reasons for failure include at least the following: A1) Selector drift; A2) Insufficient waiting time; A3) Interface error; A4) Unstable occlusion or animation; When revising the draft test script that failed to execute using the corresponding strategy: B1) Automatically trigger local rewriting for selector drift to promote selector self-healing; B2) Adjust the waiting strategy to address insufficient waiting; B3) Perform mock testing on interfaces for anomalies and repair the interface environment; B4) To address unstable occlusion, implement occlusion handling; to address unstable animation, perform animation stabilization operations and testing. The revised test script draft will be verified again through the script quality gate. If the verification is successful, the corresponding patch will be generated and the corresponding repair method will be re-implanted as a prompt word fragment.

[0040] By setting up self-healing and backfeed modules, the reasons for the failure of test script drafts can be determined, and corresponding strategies can be adopted to correct the test script drafts that fail. Instead of regenerating the entire test script drafts that fail, minimal patches are applied to the failed steps, which effectively reduces maintenance costs while backfeeding the repair experience into the rules and prompts, making the system more and more stable over time.

[0041] [Second Embodiment] like Figure 3 As shown, the second embodiment of the present invention also provides a control method for the front-end testing system based on browser debugging and AI generation mentioned in the first embodiment, including the following steps: S100: The input module receives the user requirement document and user operation path or the user requirement document and recorded business action trajectory, and parses the test intent structure from it. S200: The automation control adaptation layer encapsulates the browser automation framework to unify action primitives and output standard action event streams; S300: The debug protocol collector subscribes to and pulls internal browser signals based on the browser debug protocol or its message channel; S400: The test evidence package builder generates a structured evidence package by aligning the standard action event stream and internal signals to a unified timeline; S500: The test case generator orchestrator combines test intent structure, structured evidence package information, and test constraint templates into prompt words; S600: The AI ​​code generation engine calls the AI ​​code generation model based on prompts and outputs a draft test script; S700: The script quality gate verifies the output test script draft. Only after all verifications are passed can the test script draft be entered into the database for execution. S800: The self-healing and recharge module determines the reason for the failure of the test script draft and adopts the corresponding strategy to correct the failed test script draft.

[0042] Specific example: Generating regression test cases based on recorded trajectories S100: Record business action trajectory: for example, "Login → Enter a list → Add → Save → Verify save success"; S200: It performs secondary encapsulation of the browser automation framework to unify action primitives and output standard action event streams; S300: Retrieve internal signals: Subscribe to Network records to save key interface request and response summaries; Subscribe to Runtime / Console records exceptions; Collect DOM differences and accessibility tree fragments; Collect performance time-series summaries; S400: Generate a structured evidence package: bind the "click save" action with internal signals such as the save interface response, the appearance of a page toast, and DOM stability conditions to form step evidence; S500: Test Case Generation Orchestrator Assembly Prompts: Includes assertion specifications (prohibit sleep, must assert interface success and page prompts), positioning strategy (prioritize role / text), and data cleanup requirements; S600: The AI ​​code generation engine generates test script drafts: actions use DSL; wait for "critical request completion + DOM stability"; assertions include interface fields and page hints; and clean up test data or restore state in the end phase; S700: Test script drafts enter quality gate verification: if they do not meet the specifications, they are regenerated or partially corrected; if they pass, they are stored and executed. S800: Local self-healing after execution failure: S801: Location failure scenario: Page redesign causes the original selector to become invalid. The system retrieves the accessibility tree, DOM fragments and historical location candidates for this step through the evidence package. S802: Generate candidate locations: Generate multiple candidates by combining role, visible text, label, relative layout, and stable attributes, and then test and verify them. S803: Output minimal patch: Replace this step in the original script with the new clickByRole() or combined positioning method, and add the necessary waiting conditions; S804: After the patch passes through the quality gate, it is fed back in: the new version of the test case is written, and the "location strategy of this type of page" is precipitated as a rule fragment to improve the subsequent generation effect.

[0043] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A front-end testing system based on browser debugging and AI generation, characterized by: The system includes: The input module receives user requirement documents and user operation paths, or user requirement documents and recorded business action trajectories, and parses the test intent structure from them. An automation control adaptation layer is connected to the browser data to perform secondary encapsulation of the browser automation framework, thereby unifying action primitives and outputting a standard action event stream. A debugging protocol collector, which is connected to the browser data to subscribe to and pull internal browser signals based on the browser debugging protocol or its message channel; A test evidence package builder is connected to the automation control adaptation layer and the debugging protocol acquisition unit respectively to generate a structured evidence package by aligning the standard action event stream and internal signals to a unified timeline. A test case generator orchestrator is connected to the input module and the test evidence package builder to combine test intent structure, structured evidence package information and test constraint template into prompt words; The AI ​​code generation engine is connected to the test case generation orchestrator to call the AI ​​code generation model based on prompts and output test script drafts. A script quality gate is connected to the AI ​​code generation engine to verify the output test script drafts. Only after all verifications are passed can the test script drafts be stored in the database for execution. The self-healing and recharge module is connected to the script quality gate data to determine the failure reasons of the failed test script drafts and to use corresponding strategies to correct the failed test script drafts.

2. The front-end testing system based on browser debugging and AI generation according to claim 1, characterized in that: The parsed test intent structure in the input module includes at least the page scope, test objective, preconditions, key assertion points, data dependencies, optional exception scenarios, and optional boundary scenarios.

3. The front-end testing system based on browser debugging and AI generation according to claim 1, characterized in that: In the automated control adaptation layer The action primitives include at least click, input, wait, assertion, screenshot, and route redirection primitives; Furthermore, all the action primitives described herein are in DSL format. The standard action event flow includes a structured action sequence formed by uniformly encapsulating the user operation path or business action trajectory through the automation control adaptation layer, and the standard action event flow includes at least the step number, action type, action target, input parameters and execution result fields.

4. The front-end testing system based on browser debugging and AI generation according to claim 1, characterized in that: In the debugging protocol collector The browser internal signals subscribed to and pulled by the debugging protocol collector include at least the following: 1) DOM snapshot, accessibility tree, layout information and visibility information; wherein, the layout information includes at least the coordinates, size, hierarchy, relative position and occlusion relationship of page elements or nodes, and the visibility information includes at least whether the node is displayed, whether the node is in the viewport, whether the node is occluded, whether the node is interactive and the node transparency status information. 2) Network requests and responses, HTTP response status codes, and key interface payload summaries, wherein the key interfaces include at least those related to page rendering, list loading, data submission, status change, permission verification, and business result confirmation. 3) Debug potential problems, debug actual errors, uncaught exceptions, and page logs; wherein, the uncaught exceptions include at least script execution exceptions, unhandled Promise rejections, and resource loading exceptions; 4) Performance timing of navigation and summary, long tasks, and resource loading failure signals; the long tasks include tasks whose main thread continuously occupies more than a preset threshold; 5) and key status signals during page runtime; the key status signals include at least the route switching completion signal, the page ready status signal, the request idle signal, the global loading end signal, and the global status change signal.

5. The front-end testing system based on browser debugging and AI generation according to claim 1, characterized in that: In the test evidence package builder, after aligning the standard action event stream and internal signals to a unified timeline, a structured evidence package is generated by executing desensitization and field pruning strategies. The desensitization and field pruning strategy includes the following steps: 1) Identify sensitive and non-critical fields; 2) Replace or delete the execution mask and hash code; 3) Only retain logs and performance snippets relevant to the current step; 4) Delete redundant fields and reversible personal information fields that are irrelevant to the current step; 5) Generate an anonymized, structured evidence package; The structured evidence package uses step nodes as indexes and stores DOM differential digests, key network request digests, logs and performance snippets, screenshot indexes, and video indexes related to each step node; among them, The key network request summary includes at least the request method, interface path, request time, response time, response status code, request parameters, return fields, business success flag, exception code, and time consumption information.

6. The front-end testing system based on browser debugging and AI generation according to claim 1, characterized in that: The test case generation orchestrator can select different prompt templates and test constraint templates according to different scenarios; wherein... The prompt templates include at least a smoke template, a regression template, an abnormal link template, and a performance sentinel template; the test constraint templates include at least an assertion and wait specification template, a retry strategy template, and a selector strategy template.

7. The front-end testing system based on browser debugging and AI generation according to claim 1, characterized in that: In the AI ​​code generation engine, when the AI ​​code generation engine calls the AI ​​code generation model based on prompt words and outputs a draft test script, the following steps are included: 1) Receive prompts consisting of the test intent structure, structured evidence package information, and test constraint template; 2) Analyze the target scenario, the page to be operated on, key steps, expected assertions, and constraint rules; 3) Generate interactive actions based on the encapsulated action DSL; 4) Automatically supplement waiting conditions and assertion conditions based on the structured evidence package; 5) Output a draft of test scripts with a consistent style.

8. The front-end testing system based on browser debugging and AI generation according to claim 1, characterized in that: The script quality gate performs at least the following checks on the output test script draft: 1) Syntax, dependency and executability verification: The script syntax, dependency references and runtime configuration of the test script draft are verified respectively. When the verification results show that the test script draft has no syntax errors, all dependencies are complete, and the script can be loaded and executed normally, the syntax verification, dependency verification and executability verification are considered to be qualified. 2) Waiting and assertion specification verification: This verifies whether the test script draft sets up waiting and assertions according to the specification, and whether there are any unfounded fixed delays; when the verification result shows that the test script draft contains valid assertions, the waiting method conforms to the specification, and fixed delays are not used or are restricted, the waiting specification verification and assertion specification verification are deemed to be qualified. 3) Location strategy verification: Verify whether the element location method in the test script draft is stable; when the verification result shows that the test script draft only uses role, text, label or stable attribute location methods and does not use easily invalidated location methods, the location strategy verification is considered qualified. 4) Blacklist API Validation: This test script draft is used to verify whether there are any low-level interfaces or dangerous interfaces that are prohibited from being called from the blacklist. When the validation result is that there are no low-level interfaces or dangerous interfaces that are prohibited from being called from the blacklist in the test script draft, the blacklist API validation is considered to be qualified. 5) Data Cleaning Verification: Verify whether there is cleanup, rollback, or recovery logic data in the draft test script; if the verification result shows that there is no cleanup, rollback, or recovery logic data in the draft test script, the data cleanup verification is considered qualified. And it satisfies: The priority of the following checks is gradually reduced: syntax, dependency and executability checks, wait and assertion specification checks, location strategy checks, blacklist API checks, and data cleanup checks.

9. The front-end testing system based on browser debugging and AI generation according to claim 1, characterized in that: In the self-healing and re-feedback module, the reasons for the execution failure of the test script draft are determined based on the structured evidence package of the failure point. The reasons for failure include at least the following: A1) Selector drift; A2) Insufficient waiting time; A3) Interface error; A4) Unstable occlusion or animation; When revising the draft test script that failed to execute using the corresponding strategy: B1) Automatically trigger local rewriting for selector drift to promote selector self-healing; B2) Adjust the waiting strategy to address insufficient waiting; B3) Perform mock testing on interfaces for anomalies and repair the interface environment; B4) To address unstable occlusion, implement occlusion handling; to address unstable animation, perform animation stabilization operations and testing. The revised test script draft will be verified again through the script quality gate. If the verification is successful, the corresponding patch will be generated and the corresponding repair method will be re-implanted as a prompt word fragment.

10. The control method for the front-end testing system based on browser debugging and AI generation according to any one of claims 1-9, characterized in that: Includes the following steps: S100: The input module receives the user requirement document and user operation path or the user requirement document and recorded business action sequence, and parses the test intent structure from it; S200: The automation control adaptation layer encapsulates the browser automation framework to unify action primitives and output standard action event streams; S300: The debug protocol collector subscribes to and pulls internal browser signals based on the browser debug protocol or its message channel; S400: The test evidence package builder generates a structured evidence package by aligning the standard action event stream and internal signals to a unified timeline; S500: The test case generator orchestrator combines test intent structure, structured evidence package information, and test constraint templates into prompt words; S600: The AI ​​code generation engine calls the AI ​​code generation model based on prompts and outputs a draft test script; S700: The script quality gate verifies the output test script draft. Only after all verifications are passed can the test script draft be entered into the database for execution. S800: The self-healing and recharge module determines the reason for the failure of the test script draft and adopts the corresponding strategy to correct the failed test script draft.

Images