Page test case generation method and device, computer device, and storage medium

Abstract

This application relates to a method, apparatus, computer device, storage medium, and computer program product for generating page test cases. The method includes: generating a task configuration package based on constrained prompts; generating static code based on the task configuration package, elements in the original page, and basic styles; obtaining a noise-carrying script; the noise-carrying script including a page node structure carrying noise; generating a noisy page to be tested based on the static code and the noise-carrying script; and generating page test cases for testing the page to be tested based on the task configuration package and the page to be tested. This method can ensure high performance in generating page test cases while effectively improving the accuracy of the generated page test cases, achieving low-cost, large-scale production of high-quality web interaction test cases.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer device, storage medium, and computer program product for generating page test cases. Background Technology

[0002] With the development of computer and internet technologies, front-end testing has become an important task in the application development and maintenance process. It involves executing test cases in the application to determine whether there are any abnormalities in the page functionality of the application for the test case based on the execution results of the test cases.

[0003] However, current methods for generating page test cases typically involve testing directly on online websites, closely mimicking real-world operations. But websites frequently undergo iterations and redesigns, rendering existing test cases obsolete and unable to be repeatedly verified. Furthermore, this approach heavily relies on manual annotation for dataset construction, resulting in high costs and hindering rapid expansion. Therefore, how to ensure high performance in page test case generation while simultaneously improving the accuracy of the generated test cases has become a pressing issue. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for generating page test cases, which can not only ensure high performance in generating page test cases, but also effectively improve the accuracy of the generated page test cases, thus achieving low-cost, large-scale mass production of high-quality Web interaction test cases.

[0005] Firstly, this application provides a method for generating page test cases. The method includes: generating a task configuration package based on constrained prompts; generating static code based on the task configuration package, elements in the original page, and basic styles; obtaining a noise-carrying script; the noise-carrying script including a page node structure carrying noise; generating a noisy page to be tested based on the static code and the noise-carrying script; and generating page test cases for testing the page to be tested based on the task configuration package and the page to be tested.

[0006] Secondly, this application also provides a page test case generation device. The device includes: a generation module, configured to generate a task configuration package based on constrained prompts; generate static code based on the task configuration package, elements in the original page, and basic styles; an acquisition module, configured to acquire a noise-carrying script; the noise-carrying script includes a page node structure carrying noise; the generation module is further configured to generate a noisy page to be tested based on the static code and the noise-carrying script; and generate page test cases for testing the page to be tested according to the task configuration package and the page to be tested.

[0007] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor. The memory stores a computer program, and the processor, when executing the computer program, performs the following steps: generating a task configuration package based on constrained prompts; generating static code based on the task configuration package, elements in the original page, and basic styles; obtaining a noise-carrying script; the noise-carrying script includes a page node structure carrying noise; generating a noisy page to be tested based on the static code and the noise-carrying script; and generating page test cases for testing the page to be tested according to the task configuration package and the page to be tested.

[0008] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps: generating a task configuration package based on constrained prompts; generating static code based on the task configuration package, elements in the original page, and basic styles; obtaining an interference script; the interference script including a page node structure carrying noise; generating a noisy page to be tested based on the static code and the interference script; and generating page test cases for testing the page to be tested according to the task configuration package and the page to be tested.

[0009] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps: generating a task configuration package based on constrained prompts; generating static code based on the task configuration package, elements in the original page, and basic styles; obtaining an interference script; the interference script including a page node structure carrying noise; generating a noisy page to be tested based on the static code and the interference script; and generating page test cases for testing the page to be tested according to the task configuration package and the page to be tested.

[0010] The aforementioned page test case generation method, apparatus, computer equipment, storage medium, and computer program product generate a task configuration package based on constrained prompts, and generate static code based on the task configuration package, elements in the original page, and basic styles; furthermore, they obtain an interference script, which includes a page node structure carrying noise, generate a noisy page to be tested based on the static code and the interference script, and generate page test cases for testing the page to be tested based on the task configuration package and the page to be tested. Since the task configuration package in this application is generated based on conditional prompts, the static code generated based on the task configuration package, elements in the original page, and basic styles is more accurate and closer to real-world usage scenarios. Furthermore, because the interference script includes page node structures carrying noise, the noisy test page generated based on the static code and interference script is also closer to actual page usage scenarios. It can automatically reproduce the interference of real web pages, breaking the dilemma of balancing realism and scalability in the traditional Web intelligent agent evaluation field. It also overcomes cost and scale bottlenecks, ensuring high performance in generating page test cases while effectively improving the accuracy of the generated page test cases. It completely eliminates manual intervention and achieves low-cost, large-scale production of high-quality Web interaction test cases. Attached Figure Description

[0011] Figure 1 This is an application environment diagram of the page test case generation method in one embodiment;

[0012] Figure 2 This is a flowchart illustrating a method for generating page test cases in one embodiment;

[0013] Figure 3 This is a schematic diagram of the front-end interactive page in one embodiment;

[0014] Figure 4 This is a schematic diagram of the application interaction for flight search in one embodiment;

[0015] Figure 5 This is a schematic diagram of the overall process of collaborative processing for the fully automated pipeline operation of the page test case generation method provided in one embodiment;

[0016] Figure 6 This is a flowchart illustrating the automated webpage verification process for an assembled webpage to be tested, as shown in one embodiment.

[0017] Figure 7 This is a comparative diagram showing the interactive page after iterative updates in one embodiment;

[0018] Figure 8 This is a schematic diagram illustrating the principle of an offline page dynamically responding to user interaction actions, as provided in one embodiment.

[0019] Figure 9 This is a structural block diagram of a page test case generation device in one embodiment;

[0020] Figure 10 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0021] 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 merely illustrative and not intended to limit the scope of this application.

[0022] It should be noted that in the following description, the terms "first, second, and third" are used only to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, and third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0023] The page test case generation method provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104, or it can be located in the cloud or on another network server. Terminal 102 receives a test case generation request and sends it to server 104. Server 104 generates a task configuration package based on constrained prompts and generates static code based on the task configuration package, elements in the original page, and basic styles. Furthermore, server 104 can obtain a noise-carrying page node structure, generate a noisy page to be tested based on the static code and the noise-carrying script, and generate page test cases for testing the page to be tested according to the task configuration package and the page to be tested. The page test cases are then returned to terminal 102. Upon receiving the page test cases from server 104, terminal 102 can perform interactive testing on the original page based on the page test cases. In other words, terminal 102 can execute the page test cases to perform interactive testing on the page to be tested, obtain test results, and verify the test results. If the verification results indicate that the test results meet the expected test results, terminal 102 can use the page test cases as target test cases.

[0024] Terminal 102 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smart TV, smartwatch, IoT device, or portable wearable device. IoT devices can include smart in-vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc.

[0025] Server 104 can be an independent physical server or a service node in a blockchain system. The service nodes in the blockchain system form a peer-to-peer (Peer To Peer) network. The Peer To Peer protocol is an application layer protocol that runs on top of the Transmission Control Protocol (TCP).

[0026] In addition, server 104 can also be a server cluster consisting of multiple physical servers, which can be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery network (CDN), and big data and artificial intelligence platforms.

[0027] Terminal 102 and server 104 can be connected via Bluetooth, USB (Universal Serial Bus) or network, etc., and this application does not impose any restrictions.

[0028] In one embodiment, such as Figure 2 As shown, a method for generating page test cases is provided. This method can be executed by the server or terminal alone, or by both the server and terminal. This method can be applied to... Figure 1 Taking the terminal in the example, the explanation includes the following steps:

[0029] Step 202: Generate a task configuration package based on the constrained prompts.

[0030] In this application, "hint words" refers to constrained hint words used to introduce different user preferences, limitations, and decision-making contexts. In other words, the constrained hint words in this application are designed to give different test tasks clear objectives and differentiated difficulty. For example, constrained hint words in this application can be generated based on the interaction relationships of the original page and user description data. The user description data can be randomly assigned user profiles. For instance, based on randomly assigned user description data such as "a traveler in a hurry and with a limited budget," task constraints such as "prioritize direct flights, prices below a certain threshold, and departure times cannot be too late" will automatically be formed. Therefore, the generated constrained hint words could include: "prioritize direct flights, prices below a certain threshold, and departure times cannot be too late." Test cases generated in this way are more specific than simply "searching for flights" and are better able to evaluate the agent's ability to complete web interaction tasks under multiple conditional trade-offs.

[0031] A task configuration package refers to a package used to execute test tasks or to perform interactive tests on a page. Specifically, the test task in this application refers to a task used to perform interactive tests on a specific page. The task configuration package in this application includes at least information such as target conditions, page state change rules, and business constraints. For example, in some scenarios, the task configuration package in this application may include: task prompts, user profiles, target page type, key interaction steps, target state, difficulty parameters, and judgment conditions.

[0032] It is understood that the task configuration package in this application can be used to generate pages to be tested, as well as test cases and evaluation rules. Furthermore, the task configuration package T in this application can be a task configuration package containing the final configuration results, initially generated by the high-temperature model Planner and then verified and corrected by the low-temperature model Reviewer; it is not simply a package directly output by the high-temperature model and used immediately.

[0033] Specifically, the page test case generation method provided in this application can be widely applied to various testing scenarios that support real-time page interaction, such as AI dialogue products and data assistant products. For example, the page test case generation method provided in this application completely breaks through the bottleneck of Web test set construction in the traditional way. That is, the technical solution of this application completely replaces the extremely time-consuming manual code writing and crowdsourced annotation by introducing a multi-Agent fully automated pipeline, which can achieve low-cost, large-scale mass production of high-quality Web interaction test cases.

[0034] like Figure 3 The image shown is a schematic diagram of the front-end interactive page. In... Figure 3 In the application scenario diagram shown, when a technician (the object of operation) wants to modify the front-end interactive page of the new version (e.g., to... Figure 3When testing the web interaction page shown, the operating object can generate a test case build request by triggering a target operation (such as triggering an operation to start automatically building test cases). The terminal can then call a first intelligent agent (such as a high-temperature model) based on the test information carried in the test case build request. The first intelligent agent then determines, for example, the test case build request. Figure 3 The interaction relationships of the original page shown are used to reflect the association between page controls, actions, state changes after actions, and business constraints in the original page. The first intelligent agent generates conditional prompts based on the interaction relationships and user description data. Furthermore, the terminal can use the first intelligent agent to determine the expected difficulty of different test tasks for testing the page under test, and generate a task configuration package based on the expected difficulty and prompts.

[0035] In one embodiment, the first intelligent agent is a first temperature model whose temperature parameter is greater than a temperature threshold; generating a task configuration package based on the expected difficulty and the prompt words through the first intelligent agent includes: the terminal can generate a task configuration package based on the expected difficulty and the prompt words through the first temperature model.

[0036] In one embodiment, after generating page test cases for testing the page under test based on the task configuration package and the page under test, the method further includes: the terminal executing the page test cases to perform interactive testing on the page under test, obtaining test results, and verifying the test results to obtain verification results; if the verification results indicate that the test results meet the expected test results, the terminal uses the page test cases as target test cases.

[0037] In one embodiment, the original page includes an e-commerce page; the terminal determines the interaction relationships of the original page through a first intelligent agent, including: the terminal extracts task chains from the Web Action Knowledge Graph through the first intelligent agent; the task chains are used to reflect the association relationships between page controls, executable actions, state changes after execution, and business constraints in the e-commerce page; wherein, the Web Action Knowledge Graph is constructed based on page type, page controls, executable actions, state changes after execution, and business constraint relationships.

[0038] In one embodiment, determining the expected difficulty of different test tasks for testing the page under test includes: the terminal adjusting the parameter range of each indicator in the control vector according to the evaluation target and the target difficulty to obtain the adjusted control vector; wherein, each indicator in the control vector includes an indicator for representing the intensity of visual interference, an indicator for representing the amount of information, an indicator for representing the reasoning requirements, an indicator for representing whether risky operations are involved, an indicator for representing the number of click steps or the depth of page hierarchy, an indicator for representing whether information is collected across pages, and an indicator for representing whether interactive operations with a complexity greater than a threshold are included; the terminal determines the expected difficulty of different test tasks for testing the page under test based on the adjusted control vector.

[0039] Step 204: Generate static code based on the task configuration package, elements in the original page, and basic styles.

[0040] The original page refers to the actual website page, that is, the real website page (online page). For example, such as... Figure 3 The image shown is a schematic diagram of an e-commerce page on an online website. The original page in this application can be a real online e-commerce page as shown in Figure 3.

[0041] An element refers to a component (DOM element) contained in the original page. For example, in this application, an element can refer to the various DOM nodes contained in the original page, and in some cases, it can also be called a DOM element. A DOM node (information) is the basic unit in the Document Object Model (DOM) that describes the document structure. Each DOM node represents the elements, text, attributes, and other components of an HTML or XML document. For example, the node types of DOM nodes include at least element nodes, attribute nodes, text nodes, comment nodes, and document nodes.

[0042] Basic styles refer to the styles of elements, that is, the basic styles of all DOM nodes (DOM elements) contained in the original page.

[0043] Static code refers to the static front-end code used to create interactive test pages. In other words, the reason for generating static front-end code in this application's technical solution is to enable offline front-end simulation, while utilizing the browser's local storage in conjunction with scripts to achieve decoupling between the front-end and back-end.

[0044] Specifically, after the terminal generates a task configuration package based on the conditional prompts, the terminal can evaluate the initially generated task configuration package and obtain the evaluation result. If the evaluation result indicates that the task configuration package does not meet the preset conditions, the terminal can further determine the adjustment direction of the task configuration package and adjust the task configuration package based on the adjustment direction to obtain the adjusted task configuration package. Furthermore, the terminal can generate static code based on the adjusted task configuration package, the elements in the original page, and the basic styles.

[0045] In one embodiment, evaluating the task configuration package to obtain an evaluation result includes: the terminal evaluating the task configuration package through a second intelligent agent to obtain an evaluation result; and determining the adjustment direction of the task configuration package and adjusting the task configuration package based on the adjustment direction when the evaluation result indicates that the task configuration package does not meet preset conditions to obtain an adjusted task configuration package includes: when the evaluation result indicates that the task configuration package does not meet preset conditions, the terminal can generate feedback text reflecting the adjustment direction of the task configuration package based on the evaluation result through the second intelligent agent, so that the first intelligent agent can adjust the task configuration package based on the feedback text to obtain an adjusted task configuration package.

[0046] In one embodiment, the step of evaluating the task configuration package through the second intelligent agent to obtain the evaluation result includes: the terminal can obtain the expected difficulty and weight vector of the test task in each dimension of the task configuration package through the second intelligent agent, and calculate the comprehensive difficulty based on the expected difficulty and the weight vector; further, the terminal determines the relationship between the comprehensive difficulty and the difficulty threshold, and generates the evaluation result based on the relationship between the comprehensive difficulty and the difficulty threshold.

[0047] In one embodiment, generating an evaluation result based on the relationship includes: generating an evaluation result indicating that the task configuration package does not meet preset conditions when the difference between the overall difficulty and the difficulty threshold is greater than the tolerance; and generating an evaluation result indicating that the task configuration package meets preset conditions when the difference between the overall difficulty and the difficulty threshold is not greater than the tolerance.

[0048] In one embodiment, after determining the adjustment direction of the task configuration package and adjusting the task configuration package based on the adjustment direction to obtain the adjusted task configuration package when the evaluation result indicates that the task configuration package does not meet the preset conditions, the method further includes: the terminal evaluating the adjusted task configuration package to obtain an evaluation result; and generating static code based on the adjusted task configuration package, elements in the original page, and basic styles, including: when the adjusted task configuration package meets the preset conditions, the terminal generating static code based on the adjusted task configuration package, elements in the original page, and basic styles.

[0049] In one embodiment, if the adjusted task configuration package meets preset conditions, static code is generated based on the adjusted task configuration package, elements in the original page, and basic styles. This includes: if the adjusted task configuration package meets preset conditions, the terminal obtains page elements and basic styles from the original page through a third intelligent agent, and generates static code based on the adjusted task configuration package, page elements, and basic styles through the third intelligent agent; the static code is used to create an interactive test page.

[0050] For example, such as Figure 4 The image shows a schematic diagram of the application interaction for flight search, illustrating its application in scenarios such as... Figure 4 The following example illustrates a real-time interactive scenario for a shopping application product. Figure 5 The diagram shown illustrates the overall workflow of the fully automated pipeline operation for generating page test cases provided in this application. Figure 5 The process flow shown includes at least the following steps: Step 502 Planning Phase, Step 504 Research and Collection Phase, Step 506 Website (Webpage) Creation Phase, and Step 508 Security and Delivery Phase. When technicians (the users) want to modify the front-end interactive pages of the new version (e.g., for... Figure 4 When testing the web interaction page shown, the target object can generate a test case build request by triggering a target operation (such as triggering an operation to start automatically building test cases). The terminal can then call a first intelligent agent (such as a high-temperature model as a planner) based on the test information carried in the test case build request, and determine the relevant information from the Web action knowledge graph through the first intelligent agent. Figure 4 The interaction relationships of the original page shown can be abstracted as follows: Action nodes such as "flight search → filter direct flights → select low-priced cabins" and their sequential dependencies can be extracted. These dependencies are the extracted interaction relationships, used to reflect the associations between page controls, executed actions, state changes after execution, and business constraints in the original page. For example, in... Figure 3 In the e-commerce page shown, the terminal follows the instructions as follows: Figure 5 The processing flow shown calls a first intelligent agent (such as a high-temperature model as a planner), and through the first intelligent agent, action nodes such as "search for products - filter prices - add to cart - submit order" and their sequential dependencies can be abstracted from the Web action knowledge graph.

[0051] Furthermore, the terminal can generate conditional prompts based on interaction relationships and user description data through a first intelligent agent. For example, the terminal can obtain randomly assigned user description data, i.e., the user's Persona, such as: a traveler in a hurry and with a limited budget. Thus, conditional prompts can be generated based on interaction relationships and the Persona. Furthermore, the terminal can determine, through the first intelligent agent, prompts used for testing... Figure 4 The interactive page shown has different expected difficulty levels for different test tasks, and a task configuration package T0 is generated based on the expected difficulty and prompts.

[0052] It is understandable that the purpose of using randomly assigned user personas in the technical solution of this application is to introduce different user preferences, constraints, and decision-making contexts into the task, thereby generating constrained prompts that are closer to real-world usage scenarios. In other words, the goal is not merely to increase textual descriptions, but to give the test task clear objectives and differentiated difficulty. For example, "passengers in a hurry and with limited budgets" would create task constraints such as "prioritizing direct flights, prices below a certain threshold, and departure times that cannot be too late." Test cases generated in this way are more specific than simply "searching for flights" and are better able to evaluate the agent's ability to complete web interaction tasks under multiple conditional trade-offs.

[0053] Furthermore, the terminal can evaluate the initially generated task configuration package T0 through a second intelligent agent (such as a low-temperature model as a reviewer), obtain the evaluation result, and if the evaluation result indicates that the task configuration package T0 does not meet the preset conditions, the terminal can generate feedback text reflecting the adjustment direction of the task configuration package based on the evaluation result through the second intelligent agent (such as a low-temperature model as a reviewer). For example, the feedback text generated in this application can be: "The current task visual interference (dvisual) meets the standard, but the logical reasoning (dreason) is weak, and a step of comparing the freight costs of different commodities needs to be added." That is, this feedback text will be automatically returned to the planner, i.e., the first intelligent agent (such as a high-temperature model as a planner), for targeted modification, so that the first intelligent agent can adjust the task configuration package T0 based on the feedback text to obtain the adjusted task configuration package T.

[0054] Furthermore, if the adjusted task configuration package T meets preset conditions, the terminal, through a third intelligent agent (such as a code generation agent), obtains information from... Figure 4The page elements and basic styles are obtained from the original page shown. Then, a third-party intelligent agent (such as a code generation agent) generates static code based on the adjusted task configuration package T, page elements, and basic styles. For example, the static code generated in this application is static HTML / CSS / JS code, which is used to create... Figure 4 The interactive test page shown is shown.

[0055] Step 206: Obtain the interference script; the interference script includes a page node structure carrying noise.

[0056] In this application, the interference script refers to the script used to reproduce the actual webpage (i.e., the original page). For example, the interference script constructed in this application includes at least a page node structure carrying noise. In this application, the page node structure refers to the webpage DOM structure, and the page node structure carrying noise refers to the webpage DOM structure carrying noise. For example, the way to construct the page node structure carrying noise (webpage DOM structure) in this application can be shown in the following formula (1): DOM′=DOM∪N(ρ(t),Δt,ε) (1)

[0057] Where N represents the noise function, ρ(t) represents the increasing probability of the pop-up being triggered with each interaction step, Δt is the network hyper-artifact created by setTimeout, and ε represents the random nesting of meaningless... Tags are used to test the robustness of an agent against changes in the webpage's DOM structure.

[0058] Step 208: Generate a noisy test page based on static code and interference scripts.

[0059] Here, the page to be tested refers to a simulated test page that is designed to simulate the original page. For example, in this application, the page to be tested could be a page assembled based on a task configuration package and a interference script (used to simulate the real original page).

[0060] A noisy test page refers to a test page constructed with added noise. For example, the noisy test page generated in this application randomly mixes in pop-up ads, cookie confirmation boxes, and other noise, deliberately creating DOM loading delays to replicate the interference of a real webpage. In other words, traditional purely static webpages are often too idealized; the environment is too clean, removing common pop-up ads or network lag, which can easily lead to an inflated success rate and fail to reflect the true level of the intelligent agent.

[0061] Step 210: Generate page test cases for testing the page under test based on the task configuration package and the page to be tested.

[0062] In this context, a page test case refers to a test case used to perform interactive testing on a page. For example, the page test cases in this application could be web interaction test cases.

[0063] Specifically, after the terminal generates static code based on the task configuration package, elements and basic styles in the original page, the terminal can obtain interference scripts in the technical solution of this application because the clean environment in the traditional method can easily lead to the distortion of the evaluation results. The interference scripts include page node structures carrying noise. For example, the interference scripts in this application include a pre-built noisy web page DOM structure. The terminal can generate a noisy page to be tested based on the static code and the interference script (carrying noise), and generate page test cases for testing the page to be tested according to the task configuration package and the page to be tested.

[0064] In one embodiment, generating a noisy test page based on static code and a jitter script includes: a terminal can generate a noisy test page based on static code and a jitter script through a third intelligent agent; after generating the noisy test page based on the static code and the jitter script, the method further includes: the terminal constructs a state container for storing browser state data, and generates an initial state snapshot based on a task configuration package and initial page business data; the initial state snapshot is used to represent the business state of the test page at the current moment, and the initial state snapshot is stored in the state container; when a change is detected in the initial state snapshot in the state container, the test page is redrawn based on the updated state snapshot to obtain an updated test page.

[0065] In one embodiment, the method further includes: the terminal can verify the updated page to be tested through a fourth intelligent agent to obtain a verification result; if the verification result indicates that the verification is successful, the terminal determines that the page to be tested is a page to be tested that meets the testing conditions.

[0066] In one embodiment, after storing the initial state snapshot in the state container, the method further includes: in response to a triggered interaction action, the terminal generates an updated state snapshot based on the initial data snapshot and the interaction action, and stores the updated state snapshot in the state container.

[0067] In one embodiment, generating a noisy test page based on static code and a noise script using a third intelligent agent includes: the terminal generating the test page and target content within the test page using the third intelligent agent based on the static code, the noise script, and target text in the task configuration package; the method further includes: the terminal generating verification logic for the test page using the third intelligent agent based on the judgment logic in the task configuration package; and verifying the updated test page using a fourth intelligent agent to obtain a verification result includes: the terminal verifying the updated test page using the fourth intelligent agent based on the verification logic to obtain a verification result.

[0068] In one embodiment, the method further includes: the terminal can encode the target text and the determination logic to obtain the encoded target text and determination logic, and perform hash rearrangement processing on the attributes and identifiers of the page nodes used to generate the target content in the page to be tested to obtain the attributes and identifiers of the hash rearranged page nodes.

[0069] In one embodiment, the page node structure includes at least a preset pop-up, a confirmation box, a noise function, a pop-up trigger probability, network artifact parameters, and a preset label; the step of generating a noisy test page based on the static code and the interference script includes: the terminal generating a noisy test page based on the static code, the preset pop-up, the confirmation box, the noise function, the pop-up trigger probability, the network artifact parameters, and the preset label through a third intelligent agent.

[0070] In one embodiment, the method further includes: the terminal executing page test cases to perform interactive testing on the page under test and obtaining test results; if the test results meet the test conditions, the terminal obtaining the interaction sequence of the current interactive test, generating a target trajectory based on the interaction sequence, and generating target test cases for testing the page under test based on the target trajectory and page test cases.

[0071] In one embodiment, the interaction sequence is composed of observation action pairs, each consisting of observed page information and an action to be performed; generating the target trajectory based on the interaction sequence includes: the terminal mapping each observation action pair contained in the interaction sequence to a directed state graph, and performing graph structure denoising processing based on the directed state graph to obtain the target trajectory.

[0072] In one embodiment, the step of performing graph structure denoising based on the directed state graph to obtain the target trajectory includes: the terminal using page snapshot features in the observed page information as nodes and the executed actions as edges, performing graph structure denoising on the directed state graph based on a preset path algorithm to obtain the target trajectory; wherein the target trajectory does not contain redundant branches.

[0073] In one embodiment, generating target test cases for testing the page under test based on the target trajectory and page test cases includes: the terminal generating a sample based on the target trajectory, and combining the sample and the page test cases into target test cases for testing the page under test.

[0074] In one embodiment, after generating page test cases for testing the page under test based on the task configuration package and the page under test, the method further includes: the terminal executing the page test cases to perform interactive testing on the page under test, obtaining test results, and verifying the test results to obtain verification results; if the verification results indicate that the test results meet the expected test results, the terminal uses the page test cases as target test cases.

[0075] In one embodiment, verifying the test results to obtain verification results includes: for any step in the interaction test, the terminal uses a fourth agent to capture a screen snapshot and DOM tree of the page to be tested corresponding to any step, and merges the screen snapshot and DOM tree into an observation vector; further, the terminal can filter the observation vector based on the gaze hotspot attention mask to obtain the decision action for the target component in the page to be tested, and determine the verification result based on the decision action.

[0076] In one embodiment, the method further includes: the terminal can generate an operation log based on the decision action; the operation log includes at least an operation sequence number, and the sliding window is updated based on the operation sequence number; when the verification result indicates that the test result meets the expected test result, the terminal can generate a diagnostic report based on the target operation step corresponding to the operation sequence number at a preset position in the sliding window; the diagnostic report is generated based on the action result, page state change, and abnormal event in the target operation step; the terminal can adjust the noise carried in the interference script based on the diagnostic report through a third intelligent agent to obtain the adjusted interference script, and generate a noisy test page based on the static code and the adjusted interference script through the third intelligent agent.

[0077] In one embodiment, the step of adjusting the noise carried in the interference script based on the diagnostic report by a third intelligent agent to obtain an adjusted interference script includes: the terminal can adjust the pop-up area or z-index level carried in the interference script based on the diagnostic report by a third intelligent agent to obtain an interference script carrying the adjusted pop-up area or z-index level; wherein, the z-index level is attribute information used to control the stacking order of page elements in the direction perpendicular to the screen.

[0078] For example, in applications such as Figure 3 The following example illustrates a real-time interaction scenario using a shopping application. Assume the terminal constructs a request carrying test information based on test cases, invokes a first intelligent agent (e.g., a high-temperature model as a planner), and generates a task configuration package T0 based on constrained prompts. The terminal then invokes a second intelligent agent (e.g., a low-temperature model as a reviewer), and the first intelligent agent evaluates and corrects the task configuration package T0 to obtain an adjusted task configuration package T. Finally, the terminal invokes a third intelligent agent (e.g., a code generation agent), and the code generation agent, based on the task configuration package, such as... Figure 3 After generating static HTML / CSS / JS code from the elements and basic styles in the original page shown, the terminal can obtain the interference script, which includes a page node structure carrying noise. For example, the page node structure carrying noise can be defined as shown in the aforementioned formula (1).

[0079] Furthermore, the terminal can generate a noisy test page (a simulated offline page) based on static code and interference scripts, and generate page test cases for testing the test page according to the task configuration package and the test page. It is understood that the noisy test page generated in this application is generated by staticizing HTML / CSS / JS static code, but as... Figure 3 The interactions in the original page shown rely on dynamic data such as backend state, API responses, and user sessions. Therefore, the technical solution in this application needs to abstract this dynamic backend data into state container data stored in the browser's local storage (localStorage). This is equivalent to adding a "local backend state" to the static page. Thus, after simulating user actions and generating an `at` event, the frontend routing or page logic no longer requests the real backend, but instead reads and modifies the state data (such as JSON data snapshots) in the browser's local storage (localStorage), and then triggers a page re-render or DOM update. In this way, although the test page constructed in this application is an offline page, it can still exhibit interactive effects such as clicking, jumping, expanding, submitting, and state changes.

[0080] In this embodiment, a task configuration package is generated based on constrained prompts. Static code is then generated based on the task configuration package, elements in the original page, and basic styles. Further, an interference script is obtained, which includes a page node structure carrying noise. A noisy test page is generated based on the static code and the interference script. Finally, page test cases are generated to test the test page based on the task configuration package and the test page. Since the task configuration package in this application is generated based on constrained prompts, the static code generated based on the task configuration package, elements in the original page, and basic styles is more accurate and closer to real-world usage scenarios. Furthermore, because the interference script includes a noisy page node structure, the noisy test page generated based on the static code and the interference script is also closer to actual page usage scenarios. This automatically reproduces the interference of real web pages, breaking the dilemma of balancing realism and scalability in traditional Web intelligent agent evaluation. It also overcomes cost and scale bottlenecks, ensuring high performance in page test case generation while effectively improving the accuracy of the generated page test cases. This completely eliminates manual intervention and achieves low-cost, large-scale production of high-quality Web interaction test cases.

[0081] In one embodiment, after generating page test cases for testing the page under test based on the task configuration package and the page under test, the method further includes:

[0082] Execute page test cases to perform interactive tests on the page under test and obtain test results;

[0083] The test results were verified to obtain the verification results;

[0084] If the verification results indicate that the test results meet the expected test results, the page test case will be used as the target test case.

[0085] Interaction testing refers to performing page interaction tests on the page to be tested.

[0086] Target test cases refer to test cases that can actually be used, i.e., test cases automatically generated in this application. Only when a test case passes verification, i.e., when the verification result indicates that the test result meets the expected test result, will the page test case be used as a target test case. In other words, only test cases that successfully run and trigger the expected result will be stored in the database. Otherwise, they will not be stored in the database and can be directly discarded or ignored.

[0087] Specifically, for application in, such as Figure 3 The following example illustrates a real-time interactive scenario for a shopping application product. Figure 6 The diagram shows a workflow for automatically verifying assembled web pages. Figure 6 In the execution improvement phase shown, the modules invoked by the terminal include at least a page expansion module 100, an image generation module 200, a content enrichment module 300, and a network random injection module 400. Through the collaborative processing of these modules, more accurate verification results can be obtained. The terminal automatically generates test parameters based on the task configuration package and the page to be tested. Figure 3 After generating the page test cases for the page to be tested corresponding to the original page shown, the terminal can call, as shown in the example... Figure 6 The fourth agent shown is the verification agent (used to verify the webpage under test), and it executes test cases on the page to enable the verification of the webpage. Figure 3 The test page corresponding to the original page shown is subjected to interactive testing to obtain test results. Furthermore, the terminal can verify the test results through a verification agent, obtaining a verification result. If the verification result indicates that the test results meet the expected test results (i.e., the actual test results meet the expected test results), the page test case is used as the target test case. This ensures that by having the verification agent run the test task itself, only test cases that successfully complete the process and trigger the expected results are ultimately stored in the database. In other words, only test cases that trigger the expected results are stored as target test cases, thus fundamentally guaranteeing the accuracy of the generated test data, i.e., test cases. This effectively improves the accuracy of the generated page test cases and achieves low-cost, large-scale production of high-quality Web interactive test cases.

[0088] In one embodiment, before generating the task configuration package based on constrained prompts, the method further includes:

[0089] The first intelligent agent determines the interaction relationships of the original page; the interaction relationships are used to reflect the associations between page controls, actions, state changes after actions, and business constraints in the original page.

[0090] The first intelligent agent generates conditional prompts based on interaction relationships and user description data;

[0091] The constraint-based prompt word generation task configuration package includes:

[0092] The first intelligent agent determines the expected difficulty of different test tasks for testing the page under test, and generates a task configuration package based on the expected difficulty and prompt words.

[0093] In this context, the first intelligent agent refers to the agent used to generate the initial task configuration package. Specifically, the first intelligent agent in this application is used to generate a draft (test plan) with controllable difficulty. For example, the first intelligent agent in this application could be a high-temperature model, which serves as the planner to improve the diversity and exploratory nature of task generation, enabling the combination of different scenarios, paths, and constraints. The low-temperature model, on the other hand, acts as a reviewer, used to stably check whether the initially generated test tasks are reasonable, executable, and whether their difficulty meets the requirements.

[0094] It is understood that the main difference between the high-temperature model and the low-temperature model in this application lies in the different generation parameters or the different roles they play: the high-temperature model focuses on divergent generation, while the low-temperature model focuses on deterministic verification. They can be the same base model using different temperature parameters, or they can be two different model configurations; the model structures themselves do not necessarily have to be different.

[0095] Specifically, for application in, such as Figure 3 The following example illustrates a real-time interactive scenario using a shopping application. The terminal can invoke the first intelligent agent, the high-temperature model, and determine, through the high-temperature model, the following... Figure 3 The interaction relationships shown are those of the original page (e-commerce page); these interaction relationships are used to reflect, for example... Figure 3 The original page shown illustrates the relationships between page controls, actions, state changes after actions, and business constraints. For example, the terminal can extract task chains from the Web action knowledge graph through a first intelligent agent; task chains are used to reflect, for example, Figure 3 The diagram illustrates the relationships between page controls, executable actions, post-action state changes, and business constraints on an e-commerce page. The Web Action Knowledge Graph is constructed based on page types, page controls, executable actions, post-action state changes, and business constraints. In other words, the Web Action Knowledge Graph in this application can be constructed based on common page types, page controls, executable actions, post-action state changes, and business constraints. For example, in... Figure 3 In the e-commerce page shown, the terminal can abstract action nodes such as "search for products - filter prices - add to cart - submit order" and their sequential dependencies from the Web action knowledge graph.

[0096] It is understandable that the reason for extracting interaction relationships from the graph using a high-temperature model in this application is primarily to generate more diverse task paths and business scenarios, avoiding overly simplistic test cases. The "interaction relationships" extracted here do not simply enumerate all controls on the page, but rather refer to the relationships between controls, actions, state changes, and business objectives. For example, in... Figure 3 In the e-commerce page shown, "entering keywords in the search box" affects the "product list display," "price filtering" changes the range of candidate products, and "adding to cart" changes the cart status. The high-temperature model can combine these relationships to create a task chain of "searching for a certain type of product—filtering prices—selecting specific specifications—adding to cart," thereby generating test tasks that more closely resemble real-world usage.

[0097] Furthermore, the terminal can generate conditional prompts based on interaction relationships and randomly assigned user description data through a first intelligent agent, and can also determine, through the first intelligent agent, the prompts used for testing, such as... Figure 3 The expected difficulty of different test tasks for the page to be tested is shown, and a task configuration package is generated based on the expected difficulty and prompts. Thus, the technical solution designed in this application breaks through the dilemma of balancing realism and scalability in the traditional field of Web intelligent agent evaluation, and overcomes cost and scale bottlenecks. It can rely on a fully automated multi-agent pipeline to completely eliminate human intervention, ensuring high performance in generating page test cases while effectively improving the accuracy of the generated page test cases, achieving low-cost, large-scale production of high-quality Web interaction test cases.

[0098] In one embodiment, the step of determining the expected difficulty of different test tasks used to test the page under test includes:

[0099] The parameter ranges of each indicator in the control vector are adjusted according to the evaluation objectives and the difficulty of the objectives to obtain the adjusted control vector. The indicators in the control vector include indicators for representing the intensity of visual interference, indicators for representing the amount of information, indicators for representing the reasoning requirements, indicators for representing whether risky operations are involved, indicators for representing the number of click steps or the depth of page levels, indicators for representing whether information is collected across pages, and indicators for representing whether interactive operations with a complexity greater than the degree threshold are included.

[0100] Based on the adjusted control vector, the expected difficulty of different test tasks used to test the page under test is determined.

[0101] In this application, the complexity of the test task is controlled by a vector (control vector), which can be defined as follows: D=[d depth ,d breadth ,d interact ,d visual ,d info ,d reason ,d risk That is, the control vector D corresponds to a specific quantitative indicator. For example, d depth Represents the smallest DOM layer or the number of clicks; d breadth It limits the breadth of information collected across pages; d interact This determines whether complex components such as dropdowns and drag-and-drop functionality need to be handled; risk This controls whether operations such as "confirm payment" or "delete order" are included, as these pose risks.

[0102] It is understood that the initial ranges of each index in the control vector D in this application can be preset, for example, d depth Indicates the number of clicks or the depth of the page hierarchy, d breadth Indicates whether to collect information across multiple pages, d interact Indicates whether complex interactions such as dropdowns and drag-and-drop are included, d visual d represents the intensity of visual interference. info Indicates information content, d reason Indicating a reasoning requirement, d risk This indicates whether risky operations such as payment or deletion are involved. These metrics are not fixed and can be dynamically adjusted based on the evaluation objectives, target difficulty (Starget), reviewer feedback, and the actual execution results of the verification agent. For example, when the test task is too simple, d can be increased. reason or d interact Add multi-condition comparisons or complex control operations; when the test task is too complex, the d can be reduced. visual or d risk This reduces pop-up interference and risk steps.

[0103] Specifically, at the terminal, through the first intelligent agent, the method for testing is determined as follows: Figure 3 When determining the expected difficulty of different test tasks for the page to be tested, as shown, the terminal can use a first intelligent agent (such as a high-temperature model) to adjust the parameter range of each indicator in the control vector according to the evaluation target and target difficulty, thereby obtaining the adjusted control vector. Based on the adjusted control vector, the parameters used for testing, such as... Figure 3 The expected difficulty of different test tasks for the page to be tested is shown. The indicators in the control vector include an indicator d used to represent the intensity of visual interference. visual d, an indicator used to represent the amount of information info The index d used to represent the reasoning requirements reason Indicator d used to indicate whether a risky operation is involved risk d is an indicator used to represent click steps or page hierarchy depth. depth d, an indicator used to indicate whether information is collected across pages. breadth The metric d is used to indicate whether an interactive operation contains a complexity level greater than a certain threshold. interact Therefore, using vectors to control the complexity of the constructed test tasks transforms the subjective description of "how difficult the task is" into a quantifiable and adjustable parameter, facilitating the generation of test cases with different difficulty levels and simplifying subsequent screening and evaluation, thereby effectively improving the efficiency of page test case generation.

[0104] In one embodiment, after generating the task configuration package based on constrained prompts, the method further includes:

[0105] The task configuration package is evaluated, and the evaluation results are obtained.

[0106] If the evaluation results indicate that the task configuration package does not meet the preset conditions, determine the direction of adjustment for the task configuration package, and adjust the task configuration package based on the adjustment direction to obtain the adjusted task configuration package.

[0107] The generation of static code based on the task configuration package, elements in the original page, and basic styles includes:

[0108] Based on the adjusted task configuration package, elements and basic styles in the original page, static code is generated.

[0109] The preset conditions can be determined based on a pre-set difficulty threshold Starget. For example, in this application, the preset conditions can be: |Spred–Starget|≤ε (ε is the tolerance), that is, the difference between the overall difficulty Spred of the task draft contained in the task configuration package and the difficulty threshold Starget is not greater than the tolerance ε. Spred is the overall difficulty of the task draft contained in the task configuration package obtained by evaluating the task configuration package. In other words, Spred is the overall difficulty of the task draft contained in the task configuration package, and Starget is the pre-set difficulty threshold.

[0110] Specifically, for application in, such as Figure 3 The following example illustrates a real-time interactive scenario using a shopping application. After the terminal generates a task configuration package T0 based on constrained prompts using a first intelligent agent, it can evaluate the task configuration package T0 and obtain an evaluation result. If the evaluation result indicates that the task configuration package T0 does not meet preset conditions, for example, if |Spred–Starget|>ε (ε is the tolerance), meaning the difference between the overall difficulty Spred of the task draft contained in the task configuration package T0 and the difficulty threshold Starget is greater than the tolerance ε, the terminal can use a second intelligent agent (such as a low-temperature model) to determine the adjustment direction of the task configuration package T0 and adjust it based on the adjustment direction to obtain an adjusted task configuration package T. Then, based on the adjusted task configuration package T, such as… Figure 3 The page elements (DOM nodes or DOM elements) and basic styles in the original page shown are used to generate static code. This allows the entire process of the technical solution provided in this application to employ dual-model validation from task planning onwards: first, one model generates diverse task drafts, and then another model evaluates them. To ensure long-term data availability, the solution provided in this application does not rely on online websites but generates static front-end code, enabling offline simulation testing of the front-end. Utilizing the browser's local storage in conjunction with scripts achieves decoupling between the front-end and back-end. This ensures high performance in generating page test cases while effectively guaranteeing the normal operation of the back-end, without mutual interference, thus achieving front-end and back-end decoupling.

[0111] In one embodiment, the step of evaluating the task configuration package to obtain the evaluation result includes:

[0112] The task configuration package is evaluated by a second intelligent agent to obtain the evaluation results;

[0113] When the evaluation result indicates that the task configuration package does not meet the preset conditions, the step of determining the adjustment direction of the task configuration package and adjusting the task configuration package based on the adjustment direction to obtain the adjusted task configuration package includes:

[0114] If the evaluation results indicate that the task configuration package does not meet the preset conditions, the second agent generates feedback text based on the evaluation results to reflect the adjustment direction of the task configuration package, so that the first agent can adjust the task configuration package based on the feedback text to obtain the adjusted task configuration package.

[0115] In this context, the second agent refers to the agent used to evaluate the initial task configuration package. Specifically, the second agent in this application evaluates the initially generated draft (test plan). For example, the second agent in this application could be a low-temperature model, which acts as a reviewer to generate modification suggestions for the first agent, the high-temperature model Planner. The low-temperature model, acting as a reviewer, is used to consistently check whether the initially generated test task is reasonable, executable, and whether its difficulty meets requirements. For instance, the low-temperature model in this application can be used to compare the predicted difficulty Spred of the current task with the target difficulty Starget, and further analyze the deviations in each dimension of the control vector D, thereby generating more accurate modification suggestions for the Planner.

[0116] Specifically, for application in, such as Figure 3 The following example illustrates a real-time interactive scenario using a shopping application. After the terminal generates a task configuration package T0 based on constrained prompts using a first agent, the terminal can evaluate the task configuration package T0 using a second agent. If the evaluation result indicates that the task configuration package T0 does not meet preset conditions—for example, if |Spred–Starget|>ε (ε is the tolerance), meaning the difference between the overall difficulty Spred of the task drafts included in the task configuration package T0 and the difficulty threshold Starget is greater than the tolerance ε—the terminal can use the second agent (e.g., a low-temperature model) to generate feedback text reflecting the adjustment direction of the task configuration package T0 based on the evaluation result |Spred–Starget|>ε. This allows the first agent (e.g., a high-temperature model) to adjust the task configuration package T0 based on the feedback text, resulting in an adjusted task configuration package T. For example, the terminal can use the second agent (e.g., a low-temperature model) to generate a text feedback similar to a gradient descent direction reflecting the adjustment direction of the task configuration package T0 based on the evaluation result |Spred–Starget|>ε. The "gradient descent-like direction" mentioned here does not refer to backpropagation in mathematics, but rather to the direction of text adjustment that brings the task difficulty closer to the target value. For example, the text feedback might state: "Current task visual interference d..." visual Meets the standard, but logical reasoning d reason "The model is too weak and needs to be compared with the shipping costs of different products." This feedback text was returned to the planners, namely the high-temperature model, for targeted modification.

[0117] That is, when |Spred–Starget| > ε, the low-temperature model compares the predicted difficulty Spred of the current task with the target difficulty Starget, and further analyzes the deviations in each dimension of the control vector D, generating modification suggestions, i.e., feedback text, for the Planner. This feedback text is mainly generated based on the task draft, complexity vector D, the weights W of each dimension, the target difficulty Starget, and the current predicted difficulty Spred. For example, if the task is generally relatively simple, and d reason d info If the difficulty is too low, the Reviewer can generate feedback text such as: "The current task can be completed with just a single click. Reasoning and information are insufficient; it is recommended to add cross-page price comparison or multi-condition filtering steps." If the task is too difficult, the Reviewer can generate feedback text such as: "Reduce pop-up interference or reduce the number of operation steps." This constitutes a non-gradient text Markov decision loop. After multiple iterations, the draft matures, and the final corrected task configuration package T is output. This task configuration package T includes natural language prompts for the agent and defines the final goal of the task, such as: the shopping cart must contain a product with a specific ID and the total price must be less than a certain value. This lays the foundation for the generation of subsequent test pages, thereby effectively improving the accuracy of subsequent test page generation.

[0118] In one embodiment, the step of evaluating the task configuration package and obtaining the evaluation result by a second intelligent agent includes:

[0119] The second intelligent agent obtains the expected difficulty and weight vector of each dimension of the test task in the task configuration package, and calculates the comprehensive difficulty based on the expected difficulty and weight vector.

[0120] Determine the relationship between overall difficulty and difficulty threshold;

[0121] Evaluation results are generated based on relationships.

[0122] In this application, the task configuration package T can be understood as the final configuration result generated initially by the high-temperature model Planner and then verified and corrected by the low-temperature model Reviewer, rather than simply being used directly after being output by the high-temperature model.

[0123] The purpose of the task configuration package T is to serve as a unified input for the entire subsequent process, used to generate the test page, test cases, and evaluation rules. For example, in this application, the task configuration package T typically includes information such as task prompts, user profile, target page type, key interaction steps, target state, difficulty parameters, and judgment conditions. For instance, in a flight booking task, the task configuration package T may include information such as: "The user profile is a traveler in a hurry and with a limited budget," "Needs to find direct flights," "Price is below a certain threshold," "The final page should select flights that meet the conditions," and "Key operations include filtering direct flights and selecting flights," so that the subsequent code generation agent can generate the corresponding test page based on the task configuration package T, and the verification agent can also determine whether the task is completed based on the task configuration package T.

[0124] Overall difficulty refers to the combined difficulty Spred of all the task drafts included in the task configuration package. The difficulty threshold refers to a pre-set difficulty threshold Starget. Expected difficulty refers to the expected difficulty d of all the task drafts included in the task configuration package. i In one embodiment, the calculation method for the comprehensive difficulty Spred in this application can be as shown in the following formula (2): (2)

[0125] Wherein, the weight vector is W=[w1,w2,...,w7], and the expected difficulty is d=[d1,d2,...,d7].

[0126] Specifically, for application in, such as Figure 3 The following example illustrates the real-time interaction scenario of a shopping application product. After the terminal generates a task configuration package T0 based on the constrained prompts using the first agent, the terminal can obtain the expected difficulty d and weight vector W of each dimension of the test task in the task configuration package T0 through the second agent. Based on the above formula (2), the expected difficulty d and weight vector W, the terminal calculates the comprehensive difficulty Spred of each task draft (task), and calculates the difference between the comprehensive difficulty Spred and the difficulty threshold Starget, or calculates the absolute value of the difference between the comprehensive difficulty Spred and the difficulty threshold Starget. Then, the evaluation result is generated based on the difference Spred – Starget or the absolute value of the difference |Spred – Starget|. This forms a non-gradient text Markov decision closed loop. After multiple iterations, the draft matures, and the final corrected task configuration package T is output. The task configuration package T contains natural language prompts for the agent and defines the final goal of the task, such as: there must be a product with a specific ID in the shopping cart and the total price must be less than a certain value. This lays the foundation for the generation of the subsequent test webpage, thereby effectively improving the accuracy of the subsequent test webpage generation.

[0127] In one embodiment, if the evaluation result indicates that the task configuration package does not meet preset conditions, the method further includes determining the adjustment direction of the task configuration package, adjusting the task configuration package based on the adjustment direction, and obtaining the adjusted task configuration package.

[0128] The adjusted task configuration package was evaluated, and the evaluation results were obtained.

[0129] The process of generating static code based on the adjusted task configuration package, elements in the original page, and basic styles includes:

[0130] If the adjusted task configuration package meets the preset conditions, static code is generated based on the adjusted task configuration package, elements in the original page, and basic styles.

[0131] Specifically, for application in, such as Figure 3 The following example illustrates a real-time interactive scenario using a shopping application. The terminal can use a second agent (e.g., a low-temperature model) to generate feedback text reflecting the adjustment direction of task configuration package T0 based on the evaluation result |Spred–Starget|>ε. This allows the first agent (e.g., a high-temperature model) to adjust task configuration package T0 based on the feedback text. After obtaining the adjusted task configuration package T, the terminal can use the second agent (e.g., the low-temperature model) to evaluate the adjusted task configuration package T and obtain an evaluation result. Specifically, if the difference between the overall difficulty of the adjusted task configuration package T and the difficulty threshold is greater than the tolerance, an evaluation result is generated indicating that task configuration package T does not meet the preset conditions; if the difference is not greater than the tolerance, an evaluation result is generated indicating that task configuration package T meets the preset conditions. In other words, if the adjusted task configuration package meets the preset conditions (i.e., the difference between the overall difficulty of the adjusted task configuration package T and the difficulty threshold is not greater than the tolerance), the terminal can call a third agent, i.e., a code generation agent, and use the code generation agent to adjust the task configuration package T based on the adjusted task configuration package T, such as... Figure 3 The elements and basic styles of the original page shown are used to generate static code. This forms a non-gradient text Markov decision loop. After multiple iterations, the draft matures, and the final output is a revised task configuration package T. This task configuration package T contains natural language prompts for the agent and defines the final goal of the task, such as: the shopping cart must contain an item with a specific ID and the total price must be less than a certain value. This lays the foundation for the generation of subsequent test pages, thereby effectively improving the accuracy of subsequent test page generation.

[0132] In one embodiment, the step of generating static code based on the adjusted task configuration package, elements in the original page, and basic styles, when the adjusted task configuration package meets preset conditions, includes:

[0133] If the adjusted task configuration package meets the preset conditions, the page elements and basic styles are obtained from the original page through a third intelligent agent.

[0134] A third-party intelligent agent generates static code based on the adjusted task configuration package, page elements, and basic styles; the static code is used to create interactive test pages.

[0135] Here, the third intelligent agent refers to the intelligent agent used to generate static code. For example, the third intelligent agent in this application can be such as... Figure 5 The code shown generates the Agent.

[0136] Specifically, for application in, such as Figure 3 The following example illustrates a real-time interactive scenario using a shopping application. The terminal evaluates the adjusted task configuration package T using a second intelligent agent (e.g., a low-temperature model), obtains the evaluation result, and, if the adjusted task configuration package meets preset conditions—that is, if the difference between the overall difficulty of the adjusted task configuration package T and the difficulty threshold is no greater than the tolerance—the terminal can invoke a third intelligent agent, namely the code generation agent, and generate the agent from the data. Figure 3 The page elements and basic styles are obtained from the original page shown, and an Agent is generated through code. Based on the adjusted task configuration package T, page elements (DOM nodes), and the basic styles of DOM nodes, static HTML / CSS / JS code is generated. This static HTML / CSS / JS code is used to create an interactive test page.

[0137] In this embodiment, the entire process of the technical solution, starting from task planning, adopts a dual-model verification approach: first, one model generates diverse task drafts, and then another model evaluates them. To ensure long-term data availability, the solution provided in this application does not rely on online websites but generates static front-end code, enabling the front-end to perform offline simulation testing. By utilizing the browser's local storage in conjunction with scripts, front-end and back-end decoupling is achieved. This ensures high performance in generating page test cases while effectively guaranteeing the normal operation of the back-end, without mutual interference, thus achieving front-end and back-end decoupling.

[0138] In one embodiment, the step of generating a noisy test page based on static code and a noise-generating script includes:

[0139] A noisy test page is generated based on static code and interference scripts using a third intelligent agent.

[0140] After generating a noisy test page based on the static code and the interference script, the method further includes:

[0141] Build a state container to store browser state data;

[0142] An initial state snapshot is generated based on the task configuration package and the initial business data of the page; the initial state snapshot is used to represent the business state of the page to be tested at the current moment.

[0143] Store the initial state snapshot in the state container;

[0144] If a change is detected in the initial state snapshot in the state container, the page under test is redrawn based on the updated state snapshot to obtain the updated page under test.

[0145] Here, the state container refers to the browser's local state container. For example, the state container in this application is a state container built in the browser's local storage (localStorage). The reason for building a localStorage state container in this application is to use local JSON state to simulate real backend data and page state transitions, so that the static offline page can still complete frontend rendering and interaction based on state changes after simulating user operations, instead of dynamically regenerating the page to be tested each time.

[0146] Initial business data for a page refers to the business data related to the page that is automatically retrieved when the page is initialized, and data such as products, orders, flights, filter conditions, and shopping cart are written to the browser's localStorage.

[0147] The initial state snapshot can refer to the initial Jt, that is, the initial Jt stored in the state container. It can be understood that in this application, the snapshot of the JSON data stored locally in the browser is recorded as Jt, and the user's interaction action is recorded as at. That is, the page to be tested (offline page) in this application has already been generated by static HTML / CSS / JS code, but... Figure 3 The interactions in the original page shown rely on dynamic data such as backend state, API responses, and user sessions. Therefore, the technical solution in this application needs to abstract this dynamic backend data into state container data stored in the browser's local storage (localStorage). This is equivalent to adding a "local backend state" to the static page. Thus, after simulating user actions and generating an `at` event, the frontend routing or page logic no longer requests the real backend, but instead reads and modifies the state data (such as JSON data snapshots) in the browser's local storage (localStorage), and then triggers a page re-render or DOM update. In this way, although the test page constructed in this application is an offline page, it can still exhibit interactive effects such as clicks, jumps, expansions, submissions, and state changes.

[0148] It is understood that the locally stored JSON data snapshot Jt in this application is generated based on the task configuration package T and the initial business data of the page, representing the business state behind the page at the current moment. For example... Figure 7 The image shown is a comparison diagram of the interactive page after iterative updates. For example, when updating the interactive page... Figure 7 The redesigned page shown here automatically writes data such as products, orders, flights, filter conditions, and shopping cart to localStorage during initialization. Therefore, each time a simulated user interaction action is executed, the script updates this JSON, creating a new state snapshot. t+1 For example, on a shopping page, the initial Jt can record "shopping cart is empty, product A is in stock, current filter conditions are empty"; when the user clicks "add to cart", Jt... t+1 The updated message is "The shopping cart contains item A, quantity 1, total price has changed." The advantages of using JSON data snapshots in this technical solution are: clear structure, ease of front-end reading and writing and state replay, no reliance on real back-end interfaces, suitability for offline operation of static pages, and convenient for subsequent verification agents to check whether the page state has achieved the task objective.

[0149] An updated state snapshot refers to a snapshot of the updated state. For example, in this application, an updated state snapshot could be represented as J. t+1 In some cases, the update logic for the state snapshot can be expressed as shown in the following formula (3):

[0150] Jt+1=Φ(Jt,at) (3)

[0151] Here, the snapshot of the locally stored JSON data is denoted as Jt, and the user's interaction action is denoted as at.

[0152] Specifically, after acquiring the interference script, the terminal can use a third-party intelligent agent (code generation agent) to generate a noisy test page based on static code and the interference script. It then constructs a state container to store browser state data. For example, the terminal constructs a browser localStorage state container, denoting a snapshot of locally stored JSON data as Jt, user interaction actions as at, and generating an initial state snapshot Jt based on the task configuration package T and the initial business data of the page. This initial state snapshot Jt is stored in the state container. The initial state snapshot Jt represents the current business state of the test page. Furthermore, the terminal can detect changes in Jt in the state container using the page DOM and redraw the page accordingly. That is, if a change is detected in the initial state snapshot Jt in the state container, the terminal can update the state snapshot (e.g., Jt) based on the updated state snapshot (e.g., Jt). t+1 By redrawing the page to be tested, you can get the updated page to be tested.

[0153] It is understood that the user interaction action 'at' executed each time in this application is automatically simulated and generated based on the parameters in the task configuration package T. That is, the interaction action 'at' can be understood as the user interaction action automatically simulated at step 't'. However, it is not generated out of thin air, but is jointly determined by the task configuration package T and the current page state. For example, the task configuration package T describes information such as the task objective, operable pages, input parameters, and action constraints. After the terminal reads the current DOM and Jt in the state container, it automatically determines what action should be executed next and automatically generates the corresponding interaction action 'at'.

[0154] In this embodiment, by constructing a state container in the browser's localStorage and dynamically maintaining changes in the Jt (Jack-Track) within the state container, the static page (offline page) acquires the interactive capabilities of a real webpage. By detecting changes in the Jt within the state container, it's equivalent to adding a "local backend state" to the static page. This means that after a user action generates an `at` event, the frontend routing or page logic no longer requests the real backend; instead, it reads and modifies the Jt in localStorage before triggering a page re-render or DOM update. Thus, although the page is offline, it still exhibits interactive effects such as clicks, navigation, expansion, submission, and state changes. This method, provided in this application, does not rely on an online website but generates static frontend code, achieving offline frontend simulation. Furthermore, by utilizing the browser's local storage in conjunction with scripts, it achieves decoupling between the frontend and backend.

[0155] In one embodiment, after storing the initial state snapshot in a state container, the method further includes:

[0156] In response to triggered interaction actions, an updated state snapshot is generated based on the initial data snapshot and the interaction action;

[0157] Store updated state snapshots in the state container.

[0158] In this context, the interactive action refers to the user interaction action automatically simulated and generated based on the parameters in the task configuration package T. That is, the interactive action *at* can be understood as the user interaction action automatically simulated at step *t*. However, it is not generated out of thin air, but is determined by the task configuration package T and the current page state. For example, the task configuration package T describes information such as the task objective, operable pages, input parameters, and action constraints. After the terminal reads the current DOM and the state container Jt, it automatically determines what action to perform next and automatically generates the corresponding interactive action *at*. For example, assuming the test task is "testing the login process," the task configuration package T contains: Objective: Complete login; Username: test_user; Password: 123456; Executable actions: Input, Click, Redirect verification; During execution, the following actions may be automatically generated: a1 = Enter test_user in the username input box; a2 = Enter 123456 in the password input box; a3 = Click the login button; a4 = Check whether to redirect to the homepage, etc. In essence, the interactive action *at* in this application is: the *t*th user interaction action automatically planned and simulated by the terminal based on the task configuration package T, the current page DOM, and the current state Jt.

[0159] Specifically, such as Figure 8 The diagram shown is a timing diagram of the offline page dynamic response to user interaction actions provided in this application. After the terminal stores the initial state snapshot in the state container, the terminal automatically plans and simulates the execution of the t-th user interaction action based on the task configuration package T, the current page DOM, and the current state Jt. For example, ... Figure 8 As shown, after the terminal executes the interactive action a1=entering test_user in the username input box, the terminal responds to the triggered interactive action a1 by generating an updated state snapshot J based on the initial data snapshot Jt and the interactive action a1. t+1 =Φ(Jt,at), and update the state snapshot J. t+1 Stored in a state container.

[0160] It is understood that the static code in this application is responsible for generating and running the page under test, and Jt is the initial state data used by the page during runtime. The relationship between the two can be understood as follows:

[0161] Static code: HTML / CSS / JS, which determines the components, buttons, input fields, rendering logic, and event logic of the page.

[0162] Initial Jt: The initial JSON state written to localStorage when the page loads, which determines what content the page displays and what state it is in at the beginning.

[0163] Subsequent Jt changes: After the user performs an interactive action (at), the Jt is automatically updated, and the page is re-rendered or its display is changed according to the new state (updated Jt).

[0164] For example, suppose static code is used to generate a "shopping cart page," but the number of items displayed, whether the user is logged in, and whether buttons are clickable are not hardcoded in the static code, but are determined by the initial Jt: {"login": true,"cartItems": ["Item A", "Item B"],"submitEnabled": true}. Therefore, the initial Jt in this application can be initial state data configured based on the operational requirements of the page under test. It is related to the static code, but is not the static code itself; the static code reads the dynamically changing Jt to complete the rendering, and interactive actions further drive the Jt to continuously change. This allows the method provided in this application to enable offline pages to have interactive capabilities, without relying on an online website. Instead, it generates static front-end code, achieving offline front-end simulation, and utilizes the browser's local storage in conjunction with scripts to achieve decoupling between the front-end and back-end.

[0165] In one embodiment, the method further includes:

[0166] The updated test page is verified using a fourth intelligent agent, and the verification result is obtained.

[0167] If the verification result indicates that the verification passed, the page to be tested is determined to be a page that meets the testing conditions.

[0168] The fourth intelligent agent refers to the intelligent agent used to verify the page or test case under test. For example, the fourth intelligent agent in this application can be a verification agent. As another example, the verification agent in this application could be the verification agent of a real headless browser that has been launched.

[0169] Specifically, when a change is detected in the initial state snapshot in the state container, the terminal redraws the page under test based on the updated state snapshot. After obtaining the updated page under test, the terminal can call the fourth agent, namely the verification agent, to verify the updated page under test, obtain the verification result, and determine the page under test as meeting the test conditions if the verification result indicates that the verification passed. That is, the page under test (the assembled webpage) generated in this application cannot be directly stored in the database; it must prove its solvability. The terminal automatically starts a verification agent of a real headless browser, responsible for verifying the webpage under test, and follows a closed-loop processing flow of "multimodal observation-reasoning-action". For example, the maximum fault tolerance step is K. At any step k, the terminal can capture a screen snapshot and a simplified DOM tree of the page through the verification agent, and merge the screen snapshot and the simplified DOM tree into an observation vector Ok, and determine the verification result based on the observation vector Ok. Only when the verification result indicates that the verification passed can the page under test be determined as meeting the test conditions. In other words, data is only allowed to be stored after the verification agent overcomes interference and achieves the preset goal. Furthermore, if the verification result indicates that the verification failed, for example, if the verification agent gets stuck in a dead end within K steps (e.g., the payment button is locked by a malicious pop-up that cannot be closed), the terminal does not simply discard the entire batch of data. Instead, it innovatively incorporates a hot-fix mechanism. The terminal can capture the last three operations through the detection process and generate a diagnostic report to feed back to the front-end stages. If the diagnostic report determines that the data is physically unsolvable, the terminal will fine-tune the noise in the front-end stages, such as reducing the pop-up area or adjusting the z-index level, and then recompile and test again. This allows for quick and accurate identification of the specific reasons for the task's unsolvability and feedback of the problem to the front-end page generation or noise injection stages, rather than simply discarding the entire data. This ensures high performance in generating page test cases while effectively improving the accuracy of the generated page test cases, achieving low-cost, large-scale production of high-quality web interaction test cases.

[0170] In one embodiment, the step of generating a noisy test page based on static code and a noise script by a third intelligent agent includes:

[0171] Using a third intelligent agent, the page to be tested and the target content in the page to be tested are generated based on the target text in the static code, the interference script and the task configuration package.

[0172] The method further includes: generating verification logic for the page to be tested based on the judgment logic in the task configuration package through a third intelligent agent;

[0173] The step of verifying the updated page to be tested through a fourth intelligent agent to obtain a verification result includes:

[0174] The fourth intelligent agent verifies the updated page to be tested based on the verification logic, and obtains the verification result.

[0175] In this application, the target text and decision logic primarily originate from the task configuration package T. The task configuration package T can contain task objectives, key conditions, expected page states, and decision rules. The third-party intelligent agent, i.e., the code generation agent, can automatically generate the target content and corresponding verification logic on the page based on this information. For example, if the task configuration package T defines "select a direct flight with a price less than 1000 yuan," then "direct flight" and "price less than 1000 yuan" are target text or target conditions. The decision logic can check whether the finally selected flight meets the direct flight flag, whether the price field is less than 1000 yuan, and whether the page state has entered the selected state. Furthermore, the terminal can Base64 encode these target texts and decision logic and perform hash rearrangement of the DOM's class and id to prevent the intelligent agent from directly reading the source code and cheating.

[0176] Specifically, the terminal can generate a test page and its target content based on the target text in the static code, interference script, and task configuration package using a third intelligent agent (code generation agent). The terminal can also generate verification logic for the test page based on the judgment logic in the task configuration package T using a fourth intelligent agent (verification agent). The updated test page is then verified based on the verification logic to obtain the verification result.

[0177] In one embodiment, the method further includes: the terminal can encode the target text and the judgment logic to obtain the encoded target text and judgment logic, and perform hash rearrangement on the attributes and identifiers of the page nodes used to generate the target content in the page under test to obtain the hash rearranged attributes and identifiers of the page nodes. That is, the terminal can Base64 encode these target texts and judgment logic, and perform hash rearrangement on the DOM's class and id to prevent the agent from directly reading the source code to cheat.

[0178] In this embodiment, the static page is redrawn by detecting changes in the JSON in the browser's local storage through the page DOM. This enables the simulation of real backend data and page state transitions using local JSON states. The static offline page can still complete front-end rendering and interaction based on state changes after user operations, instead of dynamically regenerating the page to be tested each time. This breaks through cost and scale bottlenecks, and can effectively improve the accuracy of generated page test cases while ensuring high performance. It achieves low-cost, large-scale production of high-quality web interaction test cases.

[0179] In one embodiment, the page node structure includes at least a preset pop-up, a confirmation box, a noise function, a pop-up trigger probability, network artifact parameters, and preset tags; the step of generating a noisy test page based on static code and interference scripts includes:

[0180] A noisy test page is generated by a third intelligent agent based on the static code, the preset pop-up, the confirmation box, the noise function, the pop-up trigger probability, the network artifact parameters, and the preset tags.

[0181] Specifically, for application in, such as Figure 3 The following example illustrates a real-time interactive scenario using a shopping application. After the terminal obtains the interference script, the interference script includes a noisy page node structure, i.e., a webpage DOM structure. The page node structure (webpage DOM structure) contains at least a preset pop-up, a confirmation box, a noise function, a pop-up trigger probability, network artifact parameters, and preset tags. Then, the terminal can use a third-party intelligent agent, i.e., a code-generated agent, to generate a noisy test page based on static code, preset pop-ups, confirmation boxes, noise functions, pop-up trigger probabilities, network artifact parameters, and preset tags.

[0182] It is understood that the noise parameters mentioned in this application, as shown in the aforementioned formula (1), can be pre-configured with initial values ​​according to the task difficulty, but are not fixed and can be dynamically adjusted according to the execution results of the verification agent. Here, the noise function N is used to uniformly control noise types such as pop-ups, delays, and DOM interference; ρ(t) represents the trigger probability of the pop-up changing with the number of interaction steps; Δt represents the delay time of simulated network loading; ε represents the insertion of meaningless parameters. The number of tags or the nesting level.

[0183] For example, the initial configuration could be set as follows: the pop-up trigger probability ρ(t) is 5%-10%, increasing slightly with the number of operation steps; the network latency Δt is set to 300-1500ms; meaningless. Nesting ε can be set to 1-3 levels. If the verification finds the task too difficult, the probability of pop-ups can be reduced or the obstructed area can be decreased; if the task is too easy, the delay or DOM interference can be appropriately increased.

[0184] In this embodiment, compared to the traditional method where purely static web pages are often too idealistic and can easily lead to an artificially high success rate for the tested intelligent agent, the technical solution of this application incorporates a noise mechanism, deliberately mixing in random advertising pop-ups and cookie confirmation boxes to artificially create DOM loading delays, thus restoring the interference of the actual web page and making the test results closer to the real value, without being too artificially high, effectively improving the accuracy of the generated page test cases.

[0185] In one embodiment, the method further includes:

[0186] Execute page test cases to perform interactive tests on the page under test and obtain test results;

[0187] If the test results meet the test conditions, obtain the interaction sequence used in this interaction test;

[0188] Generate target trajectory based on interaction sequence;

[0189] Generate target test cases for testing the page under test based on the target trajectory and page test cases.

[0190] The interaction sequence refers to the original trajectory recorded during the execution of the verification agent's task. For example, the interaction sequence in this application can be represented as shown in the following formula (4):

[0191] τraw={(o1,a1),...,(om,am)} (4)

[0192] Here, o1 represents the page information observed by the Agent in step 1, such as a page screenshot, DOM summary, and state snapshot; a1 represents the first action performed by the Agent under this observation, such as clicking the search box or entering keywords. om represents the page observation in step m, and am represents the action performed in step m. For example, in a shopping task, (o1, a1) could be "observe the homepage search box—enter the product name", (o2, a2) could be "observe the product list—click the price filter", and (om, am) could be "observe the shopping cart page—click to confirm adding". The improvement here is that instead of simply saving a single click log, observations and actions are recorded in pairs, which can then be directly mapped to a state graph, eliminating redundant steps such as accidental clicks, repeated scrolling, and invalid backtracking, and extracting a cleaner golden trajectory, i.e., the target trajectory.

[0193] The target trajectory refers to the purified trajectory, that is, the trajectory after removing redundant branches. In some cases, the target trajectory in this application may also be called the golden trajectory.

[0194] Specifically, after generating page test cases for testing the page under test based on the task configuration package and the page to be tested, the terminal can execute the page test cases to perform interactive testing on the page under test, obtain test results, and obtain the interaction sequence for this interactive test if the test results meet the test conditions. Furthermore, the terminal can generate a target trajectory based on the interaction sequence, and generate target test cases for testing the page under test based on the target trajectory and the page test cases. For example, the terminal can use the refined target trajectory as a demonstration example, and package it together with a test set containing multiple page test cases to obtain target test cases for testing the page under test. This can also provide corpus for subsequent SFT and reinforcement learning.

[0195] In this embodiment, the verification agent will run the task itself, and only test cases that successfully complete the process and trigger the expected results will be finally stored in the database, so as to fundamentally guarantee the accuracy of the generated test data.

[0196] In one embodiment, the interaction sequence consists of observation-action pairs, each pair comprising observing page information and performing an action; the step of generating a target trajectory based on the interaction sequence includes:

[0197] Map each observation-action pair contained in the interaction sequence to a directed state graph;

[0198] The target trajectory is obtained by performing denoising processing on the directed state graph structure.

[0199] Specifically, after generating page test cases for testing the page under test based on the task configuration package and the page under test, the terminal can execute the page test cases to perform interactive testing on the page under test, obtain test results, and, if the test results meet the test conditions, obtain the interaction sequence for this interactive test. Further, the terminal can map each observation action pair contained in the interaction sequence into a directed state graph, and perform graph structure denoising processing based on the directed state graph to obtain the target trajectory. For example, the terminal uses page snapshot features in the observed page information as nodes and executed actions as edges, and performs graph structure denoising on the directed state graph based on a preset path algorithm to obtain the target trajectory; wherein the target trajectory does not contain redundant branches.

[0200] In one embodiment, the step of generating target test cases for testing the page under test based on the target trajectory and page test cases includes: the terminal can generate a sample based on the target trajectory, and combine the sample and page test cases into target test cases for testing the page under test.

[0201] In this embodiment, considering that the Agent may make mistakes, scroll ineffectively, or repeatedly backtrack during exploration, the algorithm maps the interaction sequence into a directed state graph. Using page snapshot features as nodes and interaction actions as edges, it runs a shortest path algorithm to denoise the graph structure, pruning redundant branches and extracting a golden trajectory. This purified golden trajectory can serve as a demonstration example, packaged together with the test set as test cases for inclusion in the database. Thus, the technical solution designed in this application breaks through the dilemma of balancing realism and scalability in the traditional field of Web intelligent agent evaluation, overcoming cost and scale bottlenecks. It can rely on a fully automated multi-Agent pipeline, completely eliminating manual intervention, ensuring high performance in generating page test cases while effectively improving the accuracy of the generated page test cases, achieving low-cost, large-scale production of high-quality Web interaction test cases.

[0202] In one embodiment, the step of verifying the test results to obtain the verification results includes:

[0203] For any step in the interactive test, the fourth agent captures a screenshot of the page under test and the DOM tree corresponding to any step.

[0204] Merge screen snapshots and the DOM tree into an observation vector;

[0205] The observation vector is filtered based on the gaze hotspot attention mask to obtain the decision action for the target component in the page to be tested.

[0206] The verification results are determined based on the decision-making actions.

[0207] Specifically, for any step in the interactive testing, the terminal can use the fourth intelligent agent, the verification agent, to capture a screenshot and DOM tree of the page under test corresponding to that step, and then merge the screenshot and DOM tree into an observation vector Ok. Simultaneously, to simulate human behavior, a gaze-based hotspot attention mask is introduced. When processing the observation vector Ok, the terminal reduces the weight of or removes flashing advertisements and meaningless DOM elements, ensuring the verification agent focuses on the core interactive components and outputs a decision action ak = π (ok). In other words, the terminal can filter the observation vector Ok based on the gaze-based hotspot attention mask to obtain the decision action ak = π (ok) for the target component on the page under test, and determine the verification result based on the decision action ak = π (ok). Therefore, the technical solution designed in this application breaks through the dilemma of balancing realism and scalability in the traditional field of Web intelligent agent evaluation, and overcomes the bottlenecks of cost and scale. It can rely on a fully automated multi-agent pipeline to completely eliminate human intervention, and can effectively improve the accuracy of generated page test cases while ensuring high performance. This achieves low-cost, large-scale mass production of high-quality Web interaction test cases.

[0208] In one embodiment, the method further includes:

[0209] An operation log is generated based on the decision-making action; the operation log includes at least the operation sequence number.

[0210] Update the sliding window based on the operation sequence number;

[0211] If the verification results indicate that the test results meet the expected test results, a diagnostic report is generated based on the target operation step corresponding to the operation number at the preset position in the sliding window; the diagnostic report is generated based on the action results, page state changes and abnormal events in the target operation step.

[0212] The noise carried in the interference script is adjusted based on the diagnostic report by a third intelligent agent to obtain the adjusted interference script;

[0213] A noisy test page is generated using a third-party intelligent agent based on static code and a modified interference script.

[0214] The target operation steps can refer to maintaining a sliding window based on the operation sequence number to retain a preset number of operation steps (such as the most recent three steps) before the failure occurred, rather than simply capturing them by time. For example, the target operation steps in this application can be the "three steps" captured before the failure occurred.

[0215] Specifically, the terminal can generate operation logs based on decision actions. The operation logs include at least the operation sequence number, and the sliding window is updated based on the operation sequence number. If the verification result indicates that the test result meets the expected test result, the terminal can generate a diagnostic report based on the target operation step corresponding to the operation sequence number at a preset position in the sliding window, such as capturing the last three operations. The diagnostic report is generated based on the action results, page state changes, and abnormal events in the target operation step. Furthermore, the terminal can adjust the noise carried in the interference script based on the diagnostic report through a third intelligent agent to obtain the adjusted interference script. The terminal can then generate a noisy test page based on the static code and the adjusted interference script through the third intelligent agent.

[0216] In one embodiment, the step of adjusting the noise carried in the interference script based on the diagnostic report by a third intelligent agent to obtain the adjusted interference script includes:

[0217] Using a third-party intelligent agent, based on the diagnostic report, the area or z-index level of the pop-up carried in the interference script is adjusted to obtain an interference script carrying the adjusted pop-up area or z-index level; where z-index level is attribute information used to control the stacking order of page elements in the direction perpendicular to the screen.

[0218] In other words, the terminal in this application can record an operation log after each operation performed by the verification agent through the detection process. This log includes the operation sequence number, timestamp, action type, target control, page screenshot, DOM summary, localStorage state snapshot, and exception information. The "capture the last three operations" here mainly refers to maintaining a sliding window based on the operation sequence number to retain the three most recent steps before the failure occurred, rather than simply capturing them by time.

[0219] Furthermore, the diagnostic report in this application is generated based on the action results, page state changes, and abnormal events in these three steps. For example, if the page state does not change after clicking the "pay button" three times consecutively, and the screenshot shows a pop-up window obscuring the button, the generated diagnostic report can provide a repair suggestion: "The payment button is obscured by the pop-up window; it is recommended to reduce the pop-up window's z-index or shrink its area." This allows for quick and accurate identification of the specific reasons why the task is unsolvable and provides feedback to the preceding page generation or noise injection stages, rather than simply discarding the entire data. Consequently, in the final evaluation stage, fixed click trajectory comparison is abandoned. For complex tasks with multi-step state transitions, the underlying detection script automatically generates a unique operation code on the page after the key operation is completed. Subsequently, only the operation code and the final state of the page need to be verified to determine the success or failure of the task. This is because the operation code in this application is used to prove that the state transition corresponding to the key operation has actually occurred, and the final state of the page is used to prove that the task objective has been met. With the combination of the two, it is not necessary to force the agent to execute according to a fixed click path; as long as the objective is ultimately achieved, success is determined. For example, during the specific judgment, the terminal can verify whether the operation code matches the preset key operation and check whether the final state of the page meets the target conditions in the task configuration package. Here, "final state of the page" means that the business data, DOM display results, and local state data on the page all meet expectations when the task ends. For example, in a shopping task, if the operation code indicates "the specified product has been added to the shopping cart," and the final page displays that the product, quantity, and price in the shopping cart meet the requirements, then the task is considered successful; otherwise, it is considered a failure.

[0220] Furthermore, the "critical operation" in this application does not refer to all click behaviors, but rather to operations that substantially change the state of the task objective. These operations can be pre-determined based on the target conditions, page state change rules, and business constraints in the task configuration package. For example, in a shopping task, "adding a specified product to the shopping cart," "selecting a specified specification," and "submitting filter conditions" are critical operations, while ordinary scrolling and closing irrelevant pop-ups are generally not considered critical operations. The dedicated operation code in this application is a verification identifier automatically generated by the page detection script after the critical operation is completed. It can be generated by hashing parameters such as the critical operation ID, the current page state snapshot, the business state in localStorage, the step number, the timestamp, or a random salt value. For example, after a user adds product A to the shopping cart, the script reads information such as "product ID=A, quantity=1, shopping cart status=updated, step=3" and generates the corresponding operation code for subsequent determination of whether the critical state has been truly achieved.

[0221] Compared to traditional technologies, which typically pre-record a standard operation trajectory, such as "click the search box—enter keywords—click the filter button—select price range—click confirm," and then compare the click positions, control sequences, or operation types of the tested agent to this trajectory during evaluation, this approach is rather rigid because the same task often has multiple feasible paths. For example, a user can filter prices before entering keywords, or search first and then sort; as long as a product that meets the criteria is found, the task is considered successful. However, fixed click step comparisons only recognize preset paths, easily misjudging reasonable alternative operations as failures. The technical solution in this application achieves flexible and accurate judgment through joint verification of "key operation codes + final page state + task target conditions." It no longer requires the agent to execute according to a fixed click path, but rather judges whether it has completed key state transitions and ultimately reached the target state defined in the task configuration package.

[0222] For example, in a shopping task, the agent can search for products first and then filter by price, or it can go to the category page first and then filter by product. As long as the specified products, quantity, and price meet the requirements in the final shopping cart, and the corresponding key operation code is generated, the task is considered successful. This approach accommodates different reasonable paths while avoiding misjudgments caused by only looking at the final page. Consequently, the entire task can be fully automated through a multi-agent pipeline, reducing production costs. In the evaluation phase, fixed path comparisons are completely abandoned, making the judgment more flexible and accurate.

[0223] In one embodiment, this application also provides an application scenario in which the above-described page test case generation method is applied. Specifically, the application of the page test case generation method in this application scenario is as follows:

[0224] The system addresses the pain points of high manual construction costs and test dataset failures after real-world website redesigns by employing a multi-agent, pipeline-based approach to generate web interaction data. The entire process, starting with task planning, utilizes a dual-model validation: one model generates diverse task drafts, while another model performs quality checks. To ensure long-term data availability, the system does not rely on online websites but instead generates static front-end code. Offline front-end simulation leverages the browser's local storage in conjunction with scripts to achieve decoupling between the front-end and back-end.

[0225] Furthermore, purely static web pages are often overly idealistic, which can easily lead to an inflated success rate for the tested agents. Therefore, this system incorporates a noise mechanism, deliberately mixing in random pop-up ads and cookie confirmation boxes to artificially create DOM loading delays and reproduce the interference of real web pages.

[0226] Closed-loop verification is performed after data generation. The system verifies that the Agent runs the task itself, and only test cases that successfully complete the process and trigger the expected results are ultimately stored in the database, thus fundamentally ensuring the accuracy of the generated test data.

[0227] In the final evaluation phase, fixed click path comparison was abandoned. For complex tasks involving multi-step state transitions, the system automatically generates a unique operation code on the page after key operations are completed using an underlying detection script. Subsequent success or failure can be determined simply by verifying this operation code and the final state of the page. This allows the entire task to run fully automatically through a multi-agent pipeline, reducing production costs. Furthermore, fixed path comparison was completely abandoned in the evaluation phase, making the judgment flexible and accurate.

[0228] Traditional testing methods mainly fall into two categories:

[0229] One method involves testing directly on an online website. This closely resembles real-world testing, but websites are frequently updated and redesigned. Once these changes occur, existing test cases become obsolete and cannot be reused for verification.

[0230] Another approach is to manually build a sandbox. While this solves the problem of test case failures, the environment is too clean, removing common pop-up ads or network lag, leading to an artificially high success rate that fails to reflect the agent's true performance.

[0231] Both of these approaches rely heavily on manual data construction, which is costly and cannot be scaled up significantly. Furthermore, existing technologies often rely on rigid comparisons of fixed click steps when evaluating task completion.

[0232] The drawbacks of traditional evaluation techniques include:

[0233] Testing relying on online websites is prone to becoming invalid due to page updates. Local sandboxes, on the other hand, are too clean, shielding against real-world interference and leading to inflated model performance. Both also heavily rely on manual annotation, resulting in high costs and hindering rapid expansion. Furthermore, evaluations only recognize pre-defined single-click paths, which is rigid and prone to misjudgments.

[0234] Tests relying on online websites are prone to failure due to page updates, primarily because online websites continuously iterate, and page layout, DOM structure, button positions, control names, navigation flows, or API return content may all change. Existing test cases typically depend on these fixed page elements, and once the website is redesigned, the original element positioning and operation paths may become invalid. For example, the original test script required clicking the "Buy Now" button on the page, but after the website update, the button is renamed "Order Now," or the button's hierarchy, ID, or class changes, the script will be unable to correctly recognize the control, causing the test task to fail, even if the actual business function itself remains usable.

[0235] Therefore, to address the aforementioned issues, this application proposes an automatic data generation method for multi-agent web interaction tasks. The entire task runs fully automatically through a multi-agent pipeline, reducing production costs. Furthermore, in the evaluation phase, fixed-path comparisons are completely abandoned, allowing for flexible and accurate judgments.

[0236] On the product side, the technical solution of this application completely breaks through the bottleneck of traditional Web test set construction. By introducing a multi-agent fully automated pipeline, the system completely replaces the extremely time-consuming manual code writing and crowdsourced annotation, realizing low-cost, large-scale mass production of high-quality Web interaction test cases.

[0237] On the technical side, the technical solution provided in this application operates on a fully automated production line, and the core algorithm and implementation details are divided into the following: Figure 5 The steps shown are as follows:

[0238] The first step is knowledge graph + dual-loop task planning.

[0239] To generate drafts with manageable difficulty and to avoid logical errors, a Web Action Knowledge Graph was introduced. The High Temperature Model, acting as the planner, first extracts interaction relationships from the graph, such as the interaction relationship of "flight search → filter direct flights → select low-priced cabins." Simultaneously, it randomly assigns a user persona, such as that of a traveler in a hurry and with a limited budget, thereby generating conditional prompts.

[0240] The complexity of the task is controlled by the vector D: D = [d depth ,d breadth ,d interact ,d visual ,d info ,d reason ,d risk ].

[0241] The vector D corresponds to a specific quantification metric. For example, d depth Represents the smallest DOM layer or the number of clicks; d breadth It limits the breadth of information collected across pages; d interact This determines whether complex components such as dropdowns and drag-and-drop functionality need to be handled; risk This controls whether operations such as "confirm payment" or "delete order" are included, as these pose risks.

[0242] Next, the low-temperature model intervenes as a reviewer to evaluate and revise the draft. Based on the expected difficulty of each dimension of the draft and combined with the weight vector W=[w1,w2,...,w7], the overall difficulty Spred is calculated. The calculation method of the overall difficulty Spred in this application can be as shown in the aforementioned formula (2).

[0243] Set a difficulty threshold Starget. If |Spred–Starget| > ε (ε is the tolerance), the low-temperature model will generate text feedback similar to the gradient descent direction. For example, the text feedback might state: "Current task visual interference d..." visual Meets the standard, but logical reasoning d reason The feedback was deemed "weak, requiring the addition of a step comparing shipping costs for different goods." This feedback was returned to the planners for targeted modifications to the high-temperature model.

[0244] This constitutes a non-gradient text Markov decision closed loop. After multiple iterations, the draft is finalized, and the task configuration package T is output. The task configuration package T contains natural language prompts for the agent and defines the final goal of the task, such as: the shopping cart must contain an item with a specific ID and the total price must be less than a certain value, laying the foundation for subsequent webpage generation.

[0245] The second step involves front-end generation and state container creation.

[0246] After the system receives the task configuration T, it generates an Agent through code to obtain DOM nodes and basic styles from the real website and rewrites them into static HTML / CSS / JS code. In order to enable the offline page to have interactive capabilities, a state container of the browser's localStorage is constructed, and the snapshot of the locally stored JSON data is recorded as Jt, and the user's interactive action is recorded as at. The front end takes over the back end routing, and the state update logic in the state container is as shown in the aforementioned formula (3).

[0247] The system redraws based on changes in the Jt (Junction) of the page's DOM. Furthermore, to prevent large models from cheating by directly parsing the source code to obtain answers, the system introduces an obfuscation and encryption mechanism. The target text and decision logic are Base64 encoded, and the DOM's class and id attributes are randomly hashed and rearranged, forcing the agent to understand the page only through realistic visual perception.

[0248] Step 3: Injecting environmental noise

[0249] A clean environment can easily lead to distorted evaluation results. Therefore, a noisy script was deliberately added, and the DOM structure of the webpage with noise is defined as shown in the aforementioned formula (1).

[0250] The fourth step is closed-loop verification, anomaly repair, and golden trajectory extraction.

[0251] The assembled webpage cannot be directly added to the database; it must first prove its decryptability. The system will launch a verification agent from a real headless browser to verify the webpage.

[0252] Furthermore, the verification process follows a closed-loop workflow of "multimodal observation-reasoning-action." The maximum number of fault-tolerant steps is K. At any step k, the verification agent captures a screenshot of the page and a simplified DOM tree, merging them into an observation vector Ok. To simulate human behavior, a gaze hotspot attention mask is introduced. When processing Ok, the system reduces the weight of or removes flashing ads and meaningless DOM elements, ensuring the verification agent focuses on the core interactive components and outputs the decision action ak = π (ok).

[0253] If the verification agent gets stuck in a dead end within K steps, such as the payment button being locked by a malicious pop-up that cannot be closed, the system will not simply discard the entire batch of data. Instead, an innovative hot-fix mechanism is incorporated. The system captures the last three operations during the detection process and generates a diagnostic report to feed back to the upstream stages. If the diagnostic report determines that a physically unsolvable problem has been caused, the system will fine-tune the noise in the upstream stages, such as reducing the pop-up area or adjusting the z-index level, and then recompile and test again.

[0254] Once the verification agent overcomes the interference and achieves the preset goal, the data can obtain permission to be stored in the database. Even more valuable is that the system automatically records this interaction sequence τraw.

[0255] Meanwhile, considering that the verification agent may encounter errors, invalid scrolling, or repeated backtracking during the trial and error process, the algorithm maps the interaction sequence τraw into a directed state graph. Using page snapshot features as nodes and interaction actions as edges, it runs a shortest path algorithm to denoise the graph structure, pruning redundant branches and extracting a single optimal trajectory. This refined trajectory can serve as a demonstration example, packaged together with the test set to form the final test data. In other words, the "Web interaction data" automatically generated by multiple agents in this application can specifically refer to test data or test cases (test sets) used to test interactive pages.

[0256] The beneficial effects of the technical solution provided in this application include:

[0257] The technical solution of this application breaks through the dilemma of balancing realism and scalability in the traditional field of Web intelligent agent evaluation, overcomes the bottleneck of cost and scale, and relies on a fully automated multi-agent pipeline to completely eliminate manual labor. It can ensure the high performance of page test case generation while effectively improving the accuracy of the generated page test cases, and realize the low-cost, large-scale mass production of high-quality Web interaction test cases.

[0258] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0259] Based on the same inventive concept, this application also provides a page test case generation apparatus for implementing the page test case generation method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more page test case generation apparatus embodiments provided below can be found in the limitations of the page test case generation method described above, and will not be repeated here.

[0260] In one embodiment, such as Figure 9 As shown, a page test case generation device is provided, including: a generation module 902 and an acquisition module 904, wherein:

[0261] The generation module 902 is used to generate a task configuration package based on the constraint-based prompts; and to generate static code based on the task configuration package, elements in the original page, and basic styles.

[0262] The acquisition module 904 is used to acquire the interference script; the interference script includes a page node structure carrying noise.

[0263] The generation module 902 is also used to generate a noisy page to be tested based on the static code and the interference script; and to generate page test cases for testing the page to be tested based on the task configuration package and the page to be tested.

[0264] In one embodiment, the apparatus further includes: an execution module for executing the page test cases to perform interactive testing on the page under test and obtain test results; a verification module for verifying the test results and obtaining verification results; and, if the verification results indicate that the test results meet the expected test results, using the page test cases as target test cases.

[0265] In one embodiment, the apparatus further includes: a determining module, configured to determine the interaction relationships of the original page through a first intelligent agent; the interaction relationships are used to reflect the association relationships between page controls, executed actions, state changes after executing actions, and business constraints in the original page; the generating module is further configured to generate conditional prompts based on the interaction relationships and user description data through the first intelligent agent; and to determine the expected difficulty of different test tasks for testing the page under test through the first intelligent agent, and generate a task configuration package based on the expected difficulty and the prompts.

[0266] In one embodiment, the apparatus further includes: an adjustment module, configured to adjust the parameter range of each indicator in the control vector according to the evaluation target and the target difficulty, to obtain an adjusted control vector; wherein, each indicator in the control vector includes an indicator for representing the intensity of visual interference, an indicator for representing the amount of information, an indicator for representing the reasoning requirements, an indicator for representing whether risky operations are involved, an indicator for representing the number of click steps or the depth of page hierarchy, an indicator for representing whether information is collected across pages, and an indicator for representing whether interactive operations with a complexity greater than a threshold are included; the determination module is further configured to determine the expected difficulty of different test tasks for testing the page under test based on the adjusted control vector.

[0267] In one embodiment, the apparatus further includes: an evaluation module for evaluating the task configuration package and obtaining an evaluation result; an adjustment module for determining an adjustment direction for the task configuration package when the evaluation result indicates that the task configuration package does not meet preset conditions, and adjusting the task configuration package based on the adjustment direction to obtain an adjusted task configuration package; and a generation module for generating static code based on the adjusted task configuration package, elements in the original page, and basic styles.

[0268] In one embodiment, the evaluation module is further configured to evaluate the task configuration package through a second intelligent agent to obtain an evaluation result; the generation module is further configured to, when the evaluation result indicates that the task configuration package does not meet preset conditions, generate feedback text based on the evaluation result through the second intelligent agent to reflect the adjustment direction of the task configuration package, so that the first intelligent agent adjusts the task configuration package based on the feedback text to obtain an adjusted task configuration package.

[0269] In one embodiment, the acquisition module is further configured to acquire, through the second intelligent agent, the expected difficulty and weight vector of each dimension of the test task in the task configuration package; the device further includes: a calculation module, configured to calculate the comprehensive difficulty based on the expected difficulty and the weight vector; determine the relationship between the comprehensive difficulty and the difficulty threshold; and the generation module is further configured to generate an evaluation result based on the relationship.

[0270] In one embodiment, the evaluation module is further configured to evaluate the adjusted task configuration package and obtain an evaluation result; the generation module is further configured to generate static code based on the adjusted task configuration package, elements in the original page, and basic styles, provided that the adjusted task configuration package meets preset conditions.

[0271] In one embodiment, the acquisition module is further configured to, under the condition that the adjusted task configuration package meets preset conditions, acquire page elements and basic styles from the original page through a third intelligent agent; the generation module is further configured to, through the third intelligent agent, generate static code based on the adjusted task configuration package, the page elements and the basic styles; the static code is used to create an interactive page to be tested.

[0272] In one embodiment, the generation module is further configured to generate a noisy page to be tested based on the static code and the interference script using a third intelligent agent; the apparatus further includes: a construction module for constructing a state container for storing browser state data; the generation module is further configured to generate an initial state snapshot based on the task configuration package and the initial business data of the page; the initial state snapshot is used to represent the business state of the page to be tested at the current moment; a storage module for storing the initial state snapshot in the state container; and a redrawing module for redrawing the page to be tested based on the updated state snapshot when a change is detected in the initial state snapshot in the state container, to obtain an updated page to be tested.

[0273] In one embodiment, the generation module is further configured to generate the updated state snapshot based on the initial data snapshot and the interaction action in response to the triggered interaction action; the storage module is further configured to store the updated state snapshot in the state container.

[0274] In one embodiment, the apparatus further includes: a verification module, configured to verify the updated page to be tested by a fourth intelligent agent to obtain a verification result; and a determination module, configured to determine that the page to be tested is a page to be tested that meets the testing conditions if the verification result indicates that the verification is successful.

[0275] In one embodiment, the generation module is further configured to generate a test page and target content in the test page based on the static code, the interference script, and the target text in the task configuration package using a third intelligent agent; generate verification logic for the test page based on the judgment logic in the task configuration package using a third intelligent agent; and the verification module is further configured to verify the updated test page based on the verification logic using a fourth intelligent agent to obtain a verification result.

[0276] In one embodiment, the page node structure includes at least a preset pop-up, a confirmation box, a noise function, a pop-up trigger probability, network artifact parameters, and a preset label; the generation module is further configured to generate a noisy test page based on the static code, the preset pop-up, the confirmation box, the noise function, the pop-up trigger probability, the network artifact parameters, and the preset label using a third intelligent agent.

[0277] In one embodiment, the apparatus further includes: an execution module, configured to execute the page test cases to perform interactive testing on the page under test and obtain test results; an acquisition module, further configured to acquire the interaction sequence of the current interactive test if the test results meet the test conditions; a generation module, further configured to generate a target trajectory based on the interaction sequence; and generate target test cases for testing the page under test based on the target trajectory and the page test cases.

[0278] In one embodiment, the interaction sequence is composed of observation action pairs, each observation action pair consisting of observed page information and an execution action; the device further includes: a mapping module, configured to map each observation action pair contained in the interaction sequence into a directed state graph; the execution module is further configured to perform graph structure denoising processing based on the directed state graph to obtain the target trajectory.

[0279] Each module in the aforementioned page test case generation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0280] In one embodiment, a computer device is provided, which may be a terminal or a server. In this embodiment, the computer device is described as a terminal, and its internal structure diagram is as follows. Figure 10 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When executed by the processor, the computer program implements a page test case generation method. The display unit of the computer device is used to form a visually visible image. It can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0281] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0282] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0283] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0284] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0285] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0286] 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 computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, etc., and are not limited to these.

[0287] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0288] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for generating page test cases, characterized in that, The method includes: Generate task configuration packages based on conditional prompts; Based on the task configuration package, elements and basic styles in the original page, generate static code; Obtain the interference script; the interference script includes a page node structure carrying noise; A noisy test page is generated based on the static code and the interference script; Based on the task configuration package and the page to be tested, generate page test cases for testing the page to be tested.

2. The method according to claim 1, characterized in that, After generating page test cases for testing the page under test based on the task configuration package and the page under test, the method further includes: Execute the page test cases to perform interactive testing on the page under test and obtain test results; The test results were verified to obtain the verification results; If the verification result indicates that the test result meets the expected test result, the page test case will be used as the target test case.

3. The method according to claim 1, characterized in that, Before generating the task configuration package based on the constrained prompt words, the method further includes: The interaction relationships of the original page are determined through the first intelligent agent; the interaction relationships are used to reflect the association between page controls, executed actions, state changes after the execution of actions, and business constraints in the original page. The first intelligent agent generates conditional prompts based on the interaction relationship and user description data. The constraint-based prompt word generation task configuration package includes: The first intelligent agent determines the expected difficulty of different test tasks used to test the page to be tested, and generates a task configuration package based on the expected difficulty and the prompt words.

4. The method according to claim 3, characterized in that, Determining the expected difficulty of different test tasks used to test the page under test includes: The parameter ranges of each indicator in the control vector are adjusted according to the evaluation target and the target difficulty to obtain the adjusted control vector; wherein, each indicator in the control vector includes an indicator for representing the intensity of visual interference, an indicator for representing the amount of information, an indicator for representing the reasoning requirements, an indicator for representing whether risky operations are involved, an indicator for representing the number of click steps or the depth of page levels, an indicator for representing whether information is collected across pages, and an indicator for representing whether interactive operations with a complexity greater than a certain threshold are included. Based on the adjusted control vector, the expected difficulty of different test tasks used to test the page under test is determined.

5. The method according to claim 1, characterized in that, After generating the task configuration package based on the constrained prompt words, the method further includes: The task configuration package is evaluated to obtain the evaluation results; If the evaluation result indicates that the task configuration package does not meet the preset conditions, the adjustment direction of the task configuration package is determined, and the task configuration package is adjusted based on the adjustment direction to obtain the adjusted task configuration package; The generation of static code based on the task configuration package, elements in the original page, and basic styles includes: Based on the adjusted task configuration package, elements and basic styles in the original page, static code is generated.

6. The method according to claim 5, characterized in that, The evaluation of the task configuration package to obtain the evaluation result includes: The task configuration package is evaluated by a second intelligent agent to obtain an evaluation result; When the evaluation result indicates that the task configuration package does not meet the preset conditions, the step of determining the adjustment direction of the task configuration package and adjusting the task configuration package based on the adjustment direction to obtain the adjusted task configuration package includes: If the evaluation result indicates that the task configuration package does not meet the preset conditions, the second agent generates feedback text based on the evaluation result to reflect the adjustment direction of the task configuration package, so that the first agent adjusts the task configuration package based on the feedback text to obtain the adjusted task configuration package.

7. The method according to claim 6, characterized in that, The evaluation of the task configuration package by the second intelligent agent to obtain the evaluation result includes: The second intelligent agent obtains the expected difficulty and weight vector of each dimension of the test task in the task configuration package, and calculates the comprehensive difficulty based on the expected difficulty and the weight vector. Determine the relationship between the overall difficulty and the difficulty threshold; Evaluation results are generated based on the aforementioned relationship.

8. The method according to claim 5, characterized in that, When the evaluation result indicates that the task configuration package does not meet the preset conditions, the method further includes determining the adjustment direction of the task configuration package, adjusting the task configuration package based on the adjustment direction, and obtaining the adjusted task configuration package. The adjusted task configuration package was evaluated, and the evaluation results were obtained. The process of generating static code based on the adjusted task configuration package, elements in the original page, and basic styles includes: If the adjusted task configuration package meets the preset conditions, static code is generated based on the adjusted task configuration package, elements in the original page, and basic styles.

9. The method according to claim 8, characterized in that, If the adjusted task configuration package meets preset conditions, static code is generated based on the adjusted task configuration package, elements in the original page, and basic styles, including: If the adjusted task configuration package meets the preset conditions, the page elements and basic styles are obtained from the original page through a third intelligent agent. The third intelligent agent generates static code based on the adjusted task configuration package, page elements, and basic styles; the static code is used to create an interactive test page.

10. The method according to claim 1, characterized in that, The process of generating a noisy test page based on the static code and the interference script includes: A noisy test page is generated based on the static code and the interference script by a third intelligent agent. After generating a noisy test page based on the static code and the interference script, the method further includes: Build a state container to store browser state data; An initial state snapshot is generated based on the task configuration package and the initial business data of the page; the initial state snapshot is used to represent the business state of the page to be tested at the current moment. The initial state snapshot is stored in the state container; If a change is detected in the initial state snapshot in the state container, the page under test is redrawn based on the updated state snapshot to obtain the updated page under test.

11. The method according to claim 10, characterized in that, After storing the initial state snapshot in the state container, the method further includes: In response to a triggered interaction, the updated state snapshot is generated based on the initial data snapshot and the interaction. The updated state snapshot is stored in the state container.

12. The method according to claim 10, characterized in that, The method further includes: The updated test page is verified by a fourth intelligent agent to obtain the verification result. If the verification result indicates that the verification is successful, the page to be tested is determined to be a page to be tested that meets the testing conditions.

13. The method according to claim 12, characterized in that, The step of generating a noisy test page based on the static code and the interference script using a third intelligent agent includes: A third intelligent agent generates a page to be tested and the target content in the page to be tested based on the static code, the interference script and the target text in the task configuration package. The method further includes: generating verification logic for the page to be tested based on the judgment logic in the task configuration package through a third intelligent agent; The step of verifying the updated page to be tested through a fourth intelligent agent to obtain a verification result includes: The fourth intelligent agent verifies the updated page to be tested based on the verification logic to obtain the verification result.

14. The method according to claim 1, characterized in that, The page node structure includes at least a preset pop-up, a confirmation box, a noise function, a pop-up trigger probability, network artifact parameters, and a preset tag; The process of generating a noisy test page based on the static code and the interference script includes: A noisy test page is generated by a third intelligent agent based on the static code, the preset pop-up, the confirmation box, the noise function, the pop-up trigger probability, the network artifact parameters, and the preset tags.

15. The method according to claim 1, characterized in that, The method further includes: Execute the page test cases to perform interactive testing on the page under test and obtain test results; If the test results meet the test conditions, obtain the interaction sequence for this interaction test; Generate the target trajectory based on the interaction sequence; Based on the target trajectory and the page test cases, target test cases are generated for testing the page to be tested.

16. The method according to claim 15, characterized in that, The interaction sequence consists of observation action pairs, which are composed of observing page information and performing an action. The generation of the target trajectory based on the interaction sequence includes: Map each observation action pair contained in the interaction sequence to a directed state graph; The target trajectory is obtained by performing graph structure denoising processing based on the directed state graph.

17. A page test case generation device, characterized in that, The device includes: The generation module is used to generate a task configuration package based on constrained prompts; and to generate static code based on the task configuration package, elements in the original page, and basic styles. An acquisition module is used to acquire an interference script; the interference script includes a page node structure carrying noise. The generation module is also used to generate a noisy page to be tested based on the static code and the interference script; and to generate page test cases for testing the page to be tested based on the task configuration package and the page to be tested.

18. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 16.

19. A computer-readable storage 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 according to any one of claims 1 to 16.

20. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 16.

Images