Test case generation methods, systems, electronic devices, and storage media

Abstract

This application relates to a test case generation method, system, electronic device, and storage medium. The method includes: acquiring the dynamic rendering attributes of interactive elements of a page under test in a runtime environment; performing static analysis on the front-end source code of the page under test to extract static structural information of the interactive elements; fusing the static structural information and dynamic rendering attributes into structured page context information; embedding the page context information as generation constraints into prompts in a preset large language model, wherein the prompts contain constraint instructions for the large language model to generate location information based solely on elements in the page context information; and calling the large language model embedded with the page context information to generate test cases. This application, by fusing static structural information and dynamic rendering attributes to construct a structured page context, reduces the probability of the model generating non-existent elements or invalid location information, thereby improving the executability of the generated test cases.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a test case generation method, system, electronic device, and storage medium. Background Technology

[0002] Automated test case generation based on large language models is currently a research hotspot in the field of software testing. Utilizing large language models to assist in generating test cases for web applications can significantly reduce the cost of manually writing test cases. However, existing test case generation schemes based on large language models still have the following technical shortcomings: (i) Insufficient granularity of information retrieval in the Document Object Model (DOM) results in a lack of precise runtime context for the model. Existing solutions typically obtain the DOM tree structure of a webpage through browser automation tools and directly pass the DOM tree text to a large language model. However, the DOM information obtained by this method is only a snapshot of the tree structure and cannot provide precise visual coordinates of elements (such as the return value of getBoundingClientRect), calculated Cascading Style Sheets (CSS) styles (such as display, visibility, and opacity), disabled states, and runtime dynamic attributes such as Accessible Rich Internet Applications (ARIA) roles. Due to the lack of such fine-grained information, the large language model cannot accurately determine the actual visibility and interactivity of elements when generating test cases, and is prone to generating operation steps for invisible elements, disabled elements, or elements that do not actually exist on the page.

[0003] (ii) Static source code information and runtime DOM information are separate, making it impossible to form complementary verification. Some technical solutions attempt to extract component definition information, property configurations, and Application Programming Interface (API) call paths by analyzing front-end source code (such as JSX files for React components or Vue template files); others obtain the real-time state of DOM elements through runtime tools. However, the acquisition channels for these two types of information are independent of each other, and existing technologies lack a technical mechanism to effectively integrate the static design information of the front-end source code with the dynamic state information of the runtime DOM and uniformly inject them into the large language model's prompts. Due to the separation of static and dynamic information, the large language model cannot simultaneously refer to the page's design intent and the actual rendering state, making it difficult to achieve a balance between semantic accuracy and executability in the generated operation steps.

[0004] (iii) The illusion problem of large language models is prominent, and the generated content lacks real DOM constraints. When generating test cases, large language models, limited by their probability distribution-based generation mechanism, often exhibit hallucination phenomena, namely, guessing the elements and attributes that may exist on the page, generating CSS selectors that do not actually exist (e.g., fabricating an identifier "#submit-btn" that does not actually exist on the page, while the actual identifier for this button is "#btn-submit" or the identifier attribute does not exist at all) or fictitious operation targets. Existing technical solutions lack an effective constraint mechanism to provide large language models with a "list of interactive elements that actually exist on the current page," and the output of large language models lacks cross-validation with the real DOM structure, resulting in low executability of generated test cases.

[0005] To address the aforementioned issues, existing solutions still have significant room for improvement, and there is a lack of a test case generation method that can simultaneously utilize static source code information and runtime DOM information to constrain the large language model generation process. Summary of the Invention

[0006] This application provides a test case generation method, system, electronic device, and storage medium to at least solve the technical problems in the prior art where incomplete information leads to illusions and poor executability when generating test cases from large language models.

[0007] According to one aspect of the embodiments of this application, a test case generation method is provided, comprising: obtaining dynamic rendering attributes of interactive elements of a page under test in a runtime environment; performing static analysis on the front-end source code of the page under test to extract static structural information of the interactive elements; fusing the static structural information and the dynamic rendering attributes into structured page context information; embedding the page context information as an element information source of a large language model into preset prompt words; wherein the prompt words are preset with constraint instructions that the large language model can only reference elements listed in the page context information to generate positioning information; and calling the large language model embedded with the page context information and the constraint instructions to generate test cases.

[0008] According to another aspect of the embodiments of this application, a test case generation system is provided, comprising: an attribute acquisition module, used to acquire dynamic rendering attributes of interactive elements of a page under test in a runtime environment; a static analysis module, used to perform static analysis on the front-end source code of the page under test and extract static structural information of the interactive elements; an information fusion module, used to fuse the static structural information and the dynamic rendering attributes into structured page context information; a prompt word construction module, used to embed the page context information as an element information source of a large language model into preset prompt words; wherein the prompt words are preset with constraint instructions that the large language model can only reference elements listed in the page context information to generate positioning information; and a test case generation module, used to call the large language model embedded with the page context information and the constraint instructions to generate test cases.

[0009] According to another aspect of the present application, an electronic device is provided, including: a processor, and a memory storing a program, the program including instructions that, when executed by the processor, cause the processor to perform the methods described above.

[0010] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to perform the method described above.

[0011] In this embodiment, by acquiring the dynamic rendering attributes and static structural information of the interactive elements of the page under test, the two are merged into structured page context information and embedded into the prompts of the large language model. Furthermore, a constraint instruction is preset to generate positioning information based only on elements in the page context information. This enables the large language model to generate test cases based on real and complete page element information, effectively suppressing model illusion and improving the executability and accuracy of generated test cases. This solves the technical problem in the prior art where incomplete information leads to illusions and poor executability when the large language model generates test cases. Attached Figure Description

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

[0013] Figure 1 A flowchart of the test case generation method provided in the embodiments of this application; Figure 2An overall architecture diagram of the test case generation system based on a large language model provided in the embodiments of this application; Figure 3 A flowchart for runtime element information collection and attribute extraction in a browser environment is provided as an embodiment of this application; Figure 4 A flowchart illustrating the logical judgment for generating CSS selectors provided in this application embodiment; Figure 5 A timing interaction diagram for generating and executing test cases based on a large language model, provided in an embodiment of this application; Figure 6 A schematic diagram of the test case generation system provided in the embodiments of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0014] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that embodiments of this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the embodiments of this application. It should be understood that the accompanying drawings and embodiments are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0015] According to one aspect of the embodiments of this application, a test case generation method is provided. Figure 1 A flowchart of the test case generation method provided in the embodiments of this application is shown below. Figure 1 As shown, the method includes the following steps: Step S102: Obtain the dynamic rendering attributes of interactive elements on the tested page in the runtime environment. Dynamic rendering attributes refer to the runtime state information of the Document Object Model (DOM) nodes after the tested web application is actually rendered in the browser environment, including but not limited to the element's geometric coordinates (obtained via getBoundingClientRect), calculated styles (obtained via getComputedStyle), visibility state (such as display, visibility, and opacity attributes), and current attribute values.

[0016] The test execution engine first launches a persistent browser instance using a browser automation tool (such as Playwright, Selenium, or Puppeteer) and navigates to the target page address of the web application under test. After waiting for the page to reach a preset stable state (e.g., network idle state), the engine injects an automated script into the browser's page context.

[0017] This script executes within the page's runtime environment, traversing the page's document object model based on a pre-defined list of interactive element selectors to identify all interactive elements. Interactive elements include native HTML interactive tags (such as links, buttons, input boxes, text fields, dropdowns, and options), Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA) role marker elements (such as button roles, link roles, checkbox roles, radio button roles, etc.), and unique components of mainstream front-end UI frameworks.

[0018] For each identified interactive element, the script performs a visibility check: first, it calls the element geometry detection interface to filter elements with a width and height of 0; second, it calls the element's calculated style retrieval interface to obtain the element's calculated style, filtering elements with a display attribute value of none, a visibility attribute value of hidden, or an opacity attribute value of 0. Only elements that pass both visibility checks are retained.

[0019] In practice, for each interactive element that passes the detection, the script collects its dynamic rendering attributes, including: tag name, HTML attribute set, WAI-ARIA attribute and role type, disabled status flags, and the element's geometric coordinates and size information in the page viewport. Simultaneously, the script generates a uniquely validated CSS selector for each element according to a preset priority chain.

[0020] Step S104: Perform static analysis on the front-end source code of the page under test to extract static structural information of interactive elements. Static structural information refers to structured data extracted from the source code files of the web application under test through static analysis, including but not limited to structured data obtained through static parsing (e.g., through regular expression matching, character scanning, or abstract syntax tree parsing), predefined component properties (Props), application programming interface (API) call definitions, and pre-defined test identifiers (such as data-testid) from the development phase.

[0021] While or before acquiring dynamic rendering attributes, the static analysis engine obtains the front-end source code files (including TSX, JSX, or Vue format files) of the page under test. The engine performs static analysis on the source code using a combination of regular expression matching and character scanning to extract design-time static structure information of interactive elements.

[0022] In practical implementation, static structural information includes, but is not limited to: placeholder text for input box components, static option lists for dropdown components (including display text and corresponding values ​​for each option), display text for button components, column header lists for table components, titles of pop-up components and their internal fields and button information, as well as the call paths and method types of application programming interfaces (APIs). This information is determined during code writing and reflects the page's design intent and business semantics.

[0023] Step S106 involves fusing static structural information and dynamic rendering attributes into structured page context information. For example, static structural information is used as the structural definition of page elements, and dynamic rendering attributes are used as the current state parameters of page elements; these two are then fused together into structured page context information. By fusing these two types of information, this application can construct context text containing the entire page, thereby solving the problem of inaccurate test case generation caused by relying solely on static code or dynamic DOM.

[0024] After acquiring the static structural information extracted from static analysis and the dynamic rendering attributes captured at runtime, the information fusion module performs a fusion operation. Specifically, the fusion module uses the static structural information as the structural definition of page elements and the dynamic rendering attributes as the current state parameters of page elements, and performs a one-to-one association mapping according to the element identifier.

[0025] For example, for the same input box element, the fusion module associates the placeholder text in its static structural information (such as "Please enter the task name") with the geometric coordinates, CSS selectors, and visibility state in the dynamic rendering properties to form a complete description of the same element.

[0026] After the association is completed, the fusion module generates a structured text summary for each element, based on a preset structured format, from the visible text, key attributes, and geometric coordinates. This structured text summary is presented in a clear line format, with each element occupying a separate line and attributes separated by delimiters.

[0027] Step S108: The page context information is used as the element information source of the large language model and embedded into the preset prompt words; the prompt words contain preset constraint instructions that the large language model can only refer to the elements listed in the page context information to generate positioning information.

[0028] The prompt word construction module obtains structured page context information and embeds it into the specified placeholder position of the preset large language model prompt word template. The prompt word template also contains preset constraint instructions that constrain the large language model's generation behavior. These constraint instructions include, but are not limited to, prohibiting fabricated elements, requiring the use of visible text, and requiring the use of provided selectors.

[0029] By embedding page context information and constraint instructions together with prompt words, a complete generative constraint environment is constructed. When the large language model performs inference in this environment, its output space is limited to the range of elements that actually exist in the page context information, thereby reducing the probability of the model generating elements that do not exist on the page or invalid location information.

[0030] Step S110: Invoke the large language model that embeds page context information and constraint instructions to generate test cases.

[0031] The prompt word construction module sends complete prompt words, embedding page context information and constraint instructions, to the large language model, which then performs inference and generation. Based on the page context information in the prompt words, the large language model constructs operation steps using only descriptions of elements actually existing on the page, generating test cases containing operation sequences and element location information.

[0032] The generated test cases can be parsed and executed by the subsequent automated execution engine to perform functional verification on the web application under test.

[0033] The technical means adopted in the embodiments of this application can achieve the following main technical effects: By integrating runtime dynamic rendering attributes with static structural information, a complete element view that combines design intent and real-time status is provided for large language models, reducing the probability of missing elements or invalid positioning information in the model-generated page.

[0034] This application embodiment simultaneously acquires two types of information from the page under test: one type is the dynamic rendering attributes captured by runtime injected scripts, including real-time state parameters such as the actual geometric coordinates of elements, calculated styles, visibility status, and disabled status; the other type is the static structure information extracted through static analysis of the front-end source code, including design-time defined elements such as input box placeholders, drop-down list options, and button text.

[0035] By fusing these two types of information and injecting them into the prompts of the large language model, the model gains a complete view of the elements: static structural information provides the design intent and business semantics of the page, enabling the model to understand the expected behavior of each element; dynamic rendering attributes provide precise executable information of the elements in the current page state, enabling the model to generate realistic and effective locators. The two types of information complement and verify each other; static information tells the model "what should be on the page," while dynamic information tells the model "what is actually on the page and where it is."

[0036] Compared to existing solutions that only provide DOM tree text or only provide source code information, this application embodiment achieves this by fusing dynamic and static information. This eliminates the need for the large language model to guess the existence of page elements or create its own locators. Instead, it directly generates test cases based on real element information, thereby reducing the probability of the model generating non-existent elements or invalid location information on the page and improving the executability and accuracy of the generated test cases.

[0037] It should be noted that the large language model can only generate location information based on elements in the page context information. Combined with the "structural definition" (design-time intent) and "current state parameters" (runtime real-world state) simultaneously contained in the context information, a closed, realistic, and complete element information space is constructed. By constraining the model output to the range of elements provided by the page context, the probability of the model generating non-existent or invalid location information is reduced, solving the problem of existing technologies where incomplete information leads to model guessing and fabricating elements.

[0038] The "structural definition" and "current state parameters" are linked and integrated into a complete description of the same element. The "structural definition" provides the business semantics of the element to the large language model (such as the expected input content of a form), ensuring that the generated operation description conforms to the design intent. The "current state parameters" provide precise executable information of the element in the actual page (such as uniquely verified CSS selectors and geometric coordinates). These two types of information are integrated and mutually verified during the model input phase, ensuring that the generated test cases are both semantically accurate and executable, achieving a balance between business semantic accuracy and technical executability.

[0039] By embedding the fused page context information as constraint prompts and pre-defined constraint instructions, a "constraint-based" generation environment is constructed. During inference, the target elements of all operations in the large language model are confined to the set of elements explicitly listed in the context information, and the positioning information used (such as selectors and text) must be directly derived from attribute values ​​in the context information. This mechanism transforms the DOM structure of the real page into hard constraints during model generation, changing the existing model's pattern of free generation followed by passive verification, thereby improving the executability of the first generated test cases.

[0040] In some embodiments, obtaining the dynamic rendering attributes of interactive elements of the tested page in the runtime environment includes: identifying interactive elements in the page by executing a script in the browser context of the tested page, and performing visibility detection on each interactive element to exclude invisible elements; collecting the tag name, HTML attributes, WAI-ARIA attributes and roles, disabled status, and geometric coordinates and size information of the detected interactive elements; generating a uniquely verified CSS selector for each interactive element; wherein, generating the CSS selector includes: matching element attributes sequentially according to a preset priority chain, and filtering out CSS class names that begin with dynamic status keywords.

[0041] Optionally, obtain the dynamic rendering properties of interactive elements on the tested page in the runtime environment, specifically including the following: Launch a browser instance using a browser automation tool (such as Playwright, Selenium, or Puppeteer) and navigate to the target page of the web application under test. After the page loads, inject an automated script into the browser's page context. This script executes in the runtime environment of the page under test, traversing the page's document object model according to a pre-defined list of interactive element selectors to identify all interactive elements on the page. The pre-defined list of interactive element selectors includes: native HTML interactive tags (such as links, buttons, input boxes, text fields, dropdown lists, and options), WAI-ARIA role tags (such as button roles, link roles, tab roles, checkbox roles, radio button roles, combo box roles, option roles, menu item roles, and list box roles), and nodes with pre-defined interactive semantics, role attributes, or frame component identification characteristics.

[0042] For each identified interactive element, the script performs a visibility check: First, it calls the element geometry detection interface to obtain the element's geometry within the page viewport. If the element's width and height are both 0, it is considered invisible and excluded. Second, it calls the element's calculated style retrieval interface to obtain the element's final display style after Cascading Style Sheets (CSS) calculations. If the element's display property is `none`, its visibility property is `hidden`, or its opacity property is 0, it is considered invisible and excluded. Through this dual visibility check, only elements that are actually visible and operable in the current page state are retained.

[0043] For each interactive element that passes visibility detection, the script collects the following fine-grained attribute information: the element's tag name, set of HTML attributes, WAI-ARIA attribute and role type, disabled status flag, and the element's geometric coordinates and size information on the page. The geometric coordinates include the horizontal and vertical position of the element's center point within the page viewport, and the size information includes the element's width and height.

[0044] For each collected interactive element, the script calls a selector generation function to generate a uniquely validated CSS selector according to a preset priority chain. The priority chain proceeds as follows: first, it attempts to use the element's identifier attribute; if it exists, an identifier selector is generated and uniqueness is validated. If it does not exist or validation fails, it attempts to use the test data identifier attribute. If this also fails, it attempts to use the element name attribute, the class name combination after filtering dynamic state classes, the accessibility tag attribute, the title attribute, and the placeholder attribute in sequence. If none of these strategies can generate a unique selector, a path fallback strategy is used, generating a selector based on the ancestor node path of the document object model, limiting the fallback depth to a preset number of levels.

[0045] When generating the class name combination selector, the script first filters the list of element class names, removing all class names that begin with dynamic state keywords. In one embodiment, this can be done by matching and filtering using preset dynamic state keywords (including class name prefixes corresponding to active, hover, focused, selected, expanded, shown, hidden, and disabled states). In another embodiment, it can be done by comparing DOM snapshots of the page in two different states (such as the initial state and the state after interaction), identifying those class names that have changed, and classifying them as dynamic class names for filtering. After filtering, the remaining top few static class names are extracted and combined.

[0046] After each candidate selector is generated, the script calls the Document Object Model's native query interface to count the number of elements on the current page that match that selector. Only when the number of matches is exactly one, meaning the selector uniquely matches the element on the current page, is that selector determined as the CSS selector for that element; otherwise, the next strategy in the priority chain is tried.

[0047] In this embodiment, a runtime script is injected to perform dual visibility detection (geometric size detection combined with calculated style detection) on interactive elements. A preset priority chain and uniqueness verification mechanism are used to generate CSS selectors, ensuring that each element selector provided to the large language model is unique and valid in the current page state. Compared to directly using the original document object model tree or a fixed priority strategy, this embodiment effectively avoids location failures caused by invisible elements, non-unique selectors, or selectors relying on dynamic state class names. After the CSS selectors are embedded in the prompts of the large language model, the initial location success rate of test cases generated by the model based on these selectors is significantly improved during the automated execution phase, thereby enhancing the executability of the test cases.

[0048] In some embodiments, the preset priority chain order is: id attribute > data-testid attribute > name attribute > class combination after filtering dynamic state classes > aria-label attribute > title attribute > placeholder attribute > path fallback.

[0049] Optionally, the order of the preset priority chain is as follows: The preset priority chain is arranged in descending order of priority. Higher-priority selectors have better stability and uniqueness, while lower-priority selectors serve as fallback options when higher-priority strategies fail. The selector generation function attempts each selector in the order of this priority chain, and stops trying subsequent strategies once a selector that passes the uniqueness verification is generated.

[0050] First priority: Identifier attribute. The selector generation function first checks if the element has an identifier attribute. An identifier attribute is a unique identifier assigned to an element in the HTML standard, possessing inherent global uniqueness within the same page. If an element has an identifier attribute and its value is not empty, the generator directly constructs an identifier selector using that identifier value, formatted as a hash symbol followed by the identifier value. Because the uniqueness of identifier attributes is guaranteed by the HTML specification, this selector is considered unique without additional validation, making it the highest priority selection strategy.

[0051] Second priority: Test data identifier attribute. If an element does not have an identifier attribute or the identifier attribute is empty, the generator checks whether the element has a test data identifier attribute. The test data identifier attribute is a custom attribute specifically reserved for automated testing in front-end development to identify interactive elements. It also has a globally unique design convention within the same page. If an element has a test data identifier attribute and its value is not empty, the generator constructs a selector in the form of an attribute selector, with the format: left square brackets, test data identifier attribute name, equal sign, attribute value enclosed in double quotes, and right square brackets. This selector also has a uniqueness guarantee and requires no additional validation.

[0052] Third priority: Name attribute. If an element does not have an identifier attribute and a test data identifier attribute, the generator checks if the element has a name attribute. Name attributes are commonly used for form control elements and are usually unique within the same form field. The generator constructs a selector using the tag name combined with the name attribute, in the format of tag name, left square brackets, name attribute name, equal sign, attribute value enclosed in double quotes, and right square brackets. After generation, the generator calls the Document Object Model's native query interface to verify the uniqueness of the selector, and only uses it after confirming that it matches only one element on the current page.

[0053] Fourth priority: Class name combinations after filtering dynamic state classes. If none of the above strategies generate a valid selector, the generator enters the class name combination strategy. First, the generator obtains the complete list of element class names and filters each class name in the list using dynamic state keywords. Dynamic state keywords include, but are not limited to: class name prefixes corresponding to active state, hover state, focused state, selected state, expanded state, shown state, hidden state, and disabled state. The generator uses regular expressions to match class names that begin with these keywords and removes them from the class name list. After filtering, the generator takes the first few class names from the remaining static class names in order and combines them, constructing a combination selector with the tag name followed by multiple class name selectors, each class name selector starting with a dot. The generator verifies whether the number of matches for this combination selector on the current page is one. If it is unique, the selector is used; if not, the generator adjusts the selection order of class names or increases the number of class names to try again until a unique selector is generated or all class name combinations have been tried.

[0054] Fifth priority: Accessibility tag attribute. If the class name combination strategy fails to generate a unique selector, the generator checks whether the element has an accessibility tag attribute. Accessibility tag attributes provide an accessibility name for an element and are commonly used for interactive elements such as buttons and links. The generator constructs the selector as an attribute selector, with the format: tag name, left square bracket, accessibility tag attribute name, equal sign, attribute value enclosed in double quotes, right square bracket, and verifies its uniqueness.

[0055] Sixth priority: Title attribute. If the accessibility tag attribute strategy fails, the generator checks if the element has a title attribute. Title attributes typically display additional information as tooltips and generally offer good differentiation within the same page. The generator constructs selectors using attribute selectors and verifies their uniqueness.

[0056] Seventh priority: Placeholder attributes. If the title attribute strategy fails, the generator checks if the element has a placeholder attribute. Placeholder attributes are common in input box elements and are used to suggest the expected input content to the user. The generator constructs selectors as attribute selectors and verifies their uniqueness.

[0057] Eighth Priority: Path Backtracking. If all attribute-based strategies fail to generate a selector that passes uniqueness verification, the generator enters the path backtracking strategy. This strategy constructs a selector based on the path of the element's ancestor nodes, in the format of a hierarchical path starting from the root node and descending level by level to the target element. To control the selector length and stability, the generator limits the backtracking depth to a preset number of levels and immediately stops backtracking when it encounters an ancestor node with an identifier attribute, using that identifier as the starting point of the path. The generator uses this path selector as the final selector and no longer performs uniqueness verification, because the path selector is theoretically unique based on the structural position of the document object model.

[0058] Through the priority chain described above, the selector generator can generate a unique, stable, and optimal Cascading Style Sheet selector for each interactive element in the current page state.

[0059] In this embodiment, an eight-level priority chain from identifier attributes to path fallback is designed, with each level having a clear progressive relationship and uniqueness verification mechanism. High-priority strategies such as identifier attributes, test data identifier attributes, and name attributes utilize uniqueness guarantees in HTML specifications and front-end engineering conventions to quickly generate the most stable selector. Mid-priority class name combination strategies filter dynamic state class names such as active, hover, focused, and selected states, ensuring that the generated selector does not depend on temporary class names of elements in specific interaction states, thus maintaining validity under different page states (such as before and after mouse hover, before and after element selection). Low-priority accessibility tag attributes, title attributes, and placeholder attributes provide alternative solutions based on semantic attributes. The lowest-priority path fallback strategy serves as the final guarantee.

[0060] Compared to existing solutions that employ a single strategy (such as based solely on class name or path) or fail to filter dynamic state class names, the priority chain in this embodiment prioritizes the most stable selector type while ensuring selector uniqueness. Simultaneously, filtering dynamic state class names prevents selectors from becoming ineffective due to page state changes. This makes the generated selectors applicable to various scenarios in automated testing: accurately locating elements in the initial page state and maintaining location capabilities even after user interaction and state changes, improving the reliability and maintainability of test cases in long-running or multi-step interaction scenarios.

[0061] In some embodiments, the visibility detection includes: determining the geometric dimensions of an element and filtering elements whose width and height are both 0; obtaining the calculated style of an element and filtering elements whose display attribute value is none, visibility attribute value is hidden, or opacity attribute value is 0.

[0062] Optionally, visibility detection includes judgments in the following two dimensions: Dimension 1: Geometric Dimension Detection. Preferably, for each identified interactive element, the automated script first calls the element geometric dimension detection interface provided by the browser to obtain the precise geometric dimension data of the element in the current page viewport, including the element's width and height values. Then, the script judges the obtained width and height values: if both the width and height values ​​are 0, the element is determined to have no actual geometric space on the page and is considered invisible, thus being excluded; if at least one of the width and height values ​​is greater than 0, the element is determined to be geometrically visible and proceeds to the next dimension of detection.

[0063] It should be noted that an element's width and height being 0 typically occurs in the following scenarios: the element has not yet been rendered, the element has been clipped to invisibility by its parent container, the element's size has been explicitly set to 0 by the Cascading Style Sheets, or the element's content is empty and there is no explicit size definition.

[0064] Dimension Two: Post-Calculation Style Detection. Preferably, for elements that pass the geometric dimension detection, the automated script further calls the browser's post-calculation style retrieval interface to obtain the final display style value of the element after complete calculation by the Cascading Style Sheets. The script focuses on the following three style properties: First, the display property. The script retrieves the value of the element's display property. If the value is none, it indicates that the element is hidden in the document flow and does not occupy any layout space. It is therefore determined to be an invisible element and excluded.

[0065] Second, the visibility attribute. The script retrieves the visibility attribute value of an element. If the value is hidden, it means that although the element may occupy layout space, its content is not visually visible, and it is judged as an invisible element and excluded.

[0066] Third, the opacity attribute. The script retrieves the opacity attribute value of an element. If the value is 0 or rounded to 0, it indicates that the element is completely transparent and the user cannot visually perceive its existence. Therefore, it is considered an invisible element and is excluded.

[0067] An element is considered visible only if it simultaneously meets all of the following conditions: width greater than 0, height greater than 0, display property value not equal to none, visibility property value not equal to hidden, and opacity property value greater than 0. This combination of dual-dimensional and multi-attribute detection accurately filters out elements on the page that are truly visible and operable to the user.

[0068] In this embodiment, by combining geometric size detection and post-calculated style detection, the geometric space occupancy and visual presentation status of elements are dually verified, comprehensively covering various situations that cause elements to be invisible. Compared to existing solutions that rely on only a single detection method or only detect some attributes, this embodiment can accurately identify the following types of invisible elements: asynchronously loaded components that have not yet been rendered, child elements clipped by the parent container, pop-ups or placeholders explicitly hidden by Cascading Style Sheets, tab content in a hidden state, and transition elements in transparency gradient animations, etc. After filtering out these invisible elements, each element in the element list subsequently provided to the large language model is an element that is actually visible and operable to the user in the current page state, thereby effectively suppressing the illusion problem of the large language model generating invalid operation steps for invisible elements.

[0069] In some embodiments, static structural information and dynamic rendering attributes are integrated into structured page context information, including: using static structural information as the structural definition of page elements and using dynamic rendering attributes as the current state parameters of page elements; in a preset prompt word template, the structural definition and the current state parameters are associated to generate a structured text summary containing visible text, attributes and coordinates of the elements.

[0070] Optionally, the static structural information and dynamic rendering attributes are merged into structured page context information, including the following steps: First, the static structural information extracted from the front-end source code of the page under test is defined as the structural definition of page elements. The structural definition describes the inherent attributes of elements at design time, including but not limited to: element tag type definition, placeholder text, static option lists, button display text, table column headers, etc. This information is determined during code writing and does not change with the page's runtime state.

[0071] Secondly, dynamically rendered properties captured from the runtime environment are defined as the current state parameters of page elements. These current state parameters describe the real-time state of the element after the page has actually been rendered, including but not limited to: the element's geometric coordinates and size in the viewport, calculated Cascading Style Sheet properties (display, visibility, and opacity properties), disabled state flags, and WAI-ARIA properties and role values. This information is dynamically determined at runtime and updates in real time as user interaction or page state changes.

[0072] Furthermore, a prompt word template for a large language model is pre-defined. This template reserves a structured placeholder area to carry page context information. The prompt word template also pre-defines a set of instructions that constrain the generation behavior of the large language model. These instructions include, but are not limited to: prohibiting the creation of elements that do not exist on the page, requiring the use of text that is actually visible on the page for description, and directly using the attributes in the element list to construct operation steps when a list of page elements is provided.

[0073] Furthermore, within the structured placeholder area of ​​the prompt word template, the structural definition of the same page element is mapped one-to-one with the current state parameters according to the element identifier. Specifically, for each interactive element, its static structural information (such as label type, placeholder text, and design-time option list) is associated with its runtime dynamic rendering attributes (such as current geometric coordinates, disabled state, and calculated style) to form a complete description of the same element.

[0074] Subsequently, following a preset text summary format, the associated information is converted into a structured text description. This structured text summary, for each interactive element, contains at least the following three dimensions of information: Visible text: The actual text content displayed on the page for an element, used to support large language models in identifying elements and describing operation steps based on text semantics; Attribute information: Key identifying attributes of an element (such as identifier, category name, input type, etc.) are used to support the generation of accurate cascading style sheet selectors for large language models; Coordinate information: The geometric coordinates of the element in the page viewport, used to support the coordinate back-off positioning mechanism during the test execution phase.

[0075] The final generated structured text summary is presented in a clear line format, with each element occupying a separate line and attributes separated by delimiters. This structured text summary, as complete page context information, is embedded in the reserved placeholder area of ​​the prompt word template, serving as the sole source of element information for the large language model when generating test cases.

[0076] In this embodiment, by defining static structural information as the structural definition of an element and dynamic rendering attributes as the current state parameters of an element, and mapping the two together in the prompt word template, this embodiment constructs a complete element view for the large language model. This view contains information at two levels: the structural definition level provides the design intent of the element (such as the expected input content of form fields and all selectable options in dropdown lists), and the current state parameter level provides precise information about the element during actual page operation (such as the element's precise Cascading Style Sheet selector, current coordinate position, and disabled state). When the large language model generates test cases based on this complete view, it can both refer to design-time information to understand the expected behavior and business semantics of the element and use runtime information to generate precise and executable locators. Compared to existing solutions that only provide design-time source code information or only provide runtime document object model snapshots, this embodiment enables the large language model to simultaneously utilize the advantages of both types of information: static structural information prevents the model from generating semantically ambiguous operation descriptions due to a lack of business semantics, and dynamic rendering attributes prevent the model from generating unexecutable Cascading Style Sheet selectors due to a lack of precise positioning information. The synergistic effect of the fusion of these two types of information improves the accuracy of the business semantics and the technical executability of the generated test cases.

[0077] In some embodiments, after generating test cases, the method further includes: parsing and executing the generated test cases using a four-level progressive positioning strategy based on the CSS selectors and visible text carried in the generated test cases; when the positioning fails, recording a failure log and using the failure log as a negative sample to update the constraint instructions in the prompt words.

[0078] Optionally, after generating test cases, the process also includes parsing, executing, and providing closed-loop feedback for the test cases, specifically including the following steps: After obtaining the test cases generated from the large language model, the test execution engine first parses the test cases, extracting each operation step and its associated location information. For each operation step, the execution engine attempts to locate the target element in the real browser environment according to the following priority order: First, the execution engine attempts to locate the element using the optimal Cascading Style Sheets selector carried in the test case. This optimal selector is a precise selector generated for each interactive element after uniqueness verification during the aforementioned runtime attribute retrieval phase, and has the characteristic of uniquely hitting the target element in the current page state.

[0079] If the optimal selector is successfully located, the execution engine performs the corresponding operation on the element (such as clicking, entering text, selecting an option, etc.) and continues to execute the next step in the test case.

[0080] If the optimal selector fails to locate the element, the execution engine switches to an auxiliary location strategy based on visible text. The execution engine searches a pre-built element map table for exact matches or substring matches based on the target text described in the test case (such as the text "Submit" on a button or the label "Username" next to an input box). If a unique element is matched, the exact selector of that element is used to locate the element and perform the operation.

[0081] If location based on visible text still fails, the execution engine records detailed information about the failure, including but not limited to: the step number of the failure, the selector expression used, the text matching pattern attempted, the Uniform Resource Locator (URL) of the current page, the page title, and the timestamp of the failure. This information is formatted into a structured failure log.

[0082] Furthermore, the execution engine processes the recorded structured failure logs as negative samples. Negative samples indicate that the large language model generated unexecutable test cases under the current prompt word configuration, reflecting insufficient guidance or deviation of the current constraint instructions on the large language model.

[0083] Subsequently, the execution engine feeds back the collected negative samples to the prompt word engineering side. The prompt word engineering side analyzes the negative samples to identify common reasons for location failures, such as: the large language model fabricating non-existent selectors, using text descriptions that don't exist on the page, or incorrectly assuming the interactive state of elements. Based on the analysis results, the prompt word engineering side updates the constraint instructions in the prompt words accordingly, such as: strengthening the weight of the instruction "prohibit fabricating non-existent elements on the page," adding the constraint condition "element descriptions must be completely consistent with visible text," or supplementing location guidance for specific scenarios.

[0084] The updated constraint instructions are applied to the next round of test case generation, forming a complete closed loop of "generation-execution-failure-analysis-update". As the number of closed loop iterations increases, the executability of test cases generated by the large language model gradually improves.

[0085] In this embodiment, the location failure logs during the test case execution phase are used as negative samples and fed back to the prompt word engineering side for updating constraint instructions, thereby constructing an optional closed loop of generation-execution-feedback. Compared to existing solutions that end after generating test cases once, this embodiment uses a closed-loop mechanism to continuously optimize the generation behavior of the large language model based on actual execution results. Specifically, when the large language model fabricates non-existent elements or uses imprecise descriptions, location failures will inevitably occur during the execution phase. These failure logs are recorded as negative samples and used for analysis. The prompt word engineering side strengthens or adds constraint instructions based on the analysis results, thereby more effectively limiting the output space of the large language model in subsequent generation. With multiple iterations of the closed loop, the hallucination behavior of the large language model is continuously suppressed, and the pass rate of the generated test cases on the first execution increases. This effect does not depend on retraining or fine-tuning the large language model itself; it can be achieved solely through prompt word engineering and closed-loop feedback, featuring low implementation cost and high iteration efficiency.

[0086] In some embodiments, the above four-level progressive positioning strategy includes: Level 1, using CSS selectors in the test case to locate elements; Level 2, if Level 1 positioning fails, then searching for elements through a pre-built three-level index mapping table, which is indexed by the element's visible text, WAI-ARIA attribute and role, and HTML tag name; Level 3, if Level 2 positioning fails, then calling the semantic positioning interface of the browser's automated driving tool to locate the element; Level 4, if Level 3 positioning fails, then falling back to the geometric coordinates carried in the test case for positioning.

[0087] Optionally, the generated test cases are parsed and executed, including performing the following steps using a four-level progressive localization strategy: Level 1: Cascading Style Sheet (CSS) selector positioning. Preferably, the execution engine first obtains the CSS selector carried in the test case. This selector is the optimal selector generated after uniqueness verification during the runtime attribute retrieval phase. The execution engine calls the native positioning interface of the browser's automation-driven tool and uses this selector to find the target element in the current page. If the search is successful and the unique element returned is in an interactive state, the positioning is complete, and the execution engine directly performs the corresponding operation on the element. If the search fails or the number of returned elements is not unique, the second level of positioning is initiated.

[0088] Level 2: Three-level index mapping table lookup. Preferably, if the first-level location fails, the execution engine switches to the pre-built three-level index mapping table for element lookup. This three-level index mapping table is pre-built during the runtime DOM context capture phase and contains the following three dimensions of index: First-level index: The index is built based on the visible text of the elements. The execution engine extracts the target text of the operation described in the test case and performs an exact match search in the first-level index; if no exact match is found, a substring match search is performed, that is, searching for all candidate elements in the visible text that contain the target text.

[0089] Second-level index: An index is built based on WAI-ARIA attributes and roles. If the first-level index does not match the target element, the execution engine extracts semantic role information that may be involved in the test case and searches for candidate elements with the corresponding WAI-ARIA roles or attributes in the second-level index.

[0090] Third-level index: Indexed by HTML tag name. If the first two levels of index do not match the target element, the execution engine filters out candidate elements with corresponding tag names from the third-level index based on the element type described in the test case (such as button, input box, link, etc.).

[0091] The execution engine comprehensively scores all candidate elements obtained during the three-level index lookup process, sorts them according to text matching degree, role matching degree, and tag matching degree, and selects the candidate element with the highest score as the target element. If the unique target element is successfully located, the corresponding operation is performed; if it still cannot be located or multiple elements are located, the third-level positioning is initiated.

[0092] Level 3: Semantic Location Interface Location. Preferably, if Level 2 location fails, the execution engine calls the semantic location interface built into the browser's automation-driven tool for location. The semantic location interface supports searching based on combinations of element roles and names, such as searching by the button role and name "Submit," searching by the input box role and placeholder text "Please enter username," or searching by the link role and containing specific text. The execution engine dynamically constructs semantic location conditions based on the operation description in the test case and calls the semantic location interface to find matching elements on the page. If the search is successful, the corresponding operation is executed; if the search fails, it proceeds to Level 4 location.

[0093] Level 4: Geometric Coordinate Fallback Positioning. Preferably, if Level 3 positioning fails, the execution engine falls back to the lowest-level positioning method, namely geometric coordinate-based positioning. The execution engine extracts the geometric coordinate information of the target element carried in the test case. This coordinate information is the horizontal and vertical position of the element's center point in the page viewport, recorded during the runtime attribute capture phase. The execution engine calls the underlying interface of the browser's automation-driven tools to perform a mouse click or touch operation at the specified coordinate position. This method does not rely on any element attributes or selectors and can serve as a final fault-tolerance mechanism if all the above semantic-level positioning strategies fail.

[0094] The four-level positioning strategy described above starts with the method that has the highest accuracy and lowest error tolerance, and progresses step by step to methods with lower accuracy but higher error tolerance. If positioning at a certain level is successful, the positioning attempt at subsequent levels is terminated, and the corresponding user action is executed; only when positioning at the current level fails will it automatically degrade to the next level to continue trying, thereby maximizing the positioning success rate while ensuring execution efficiency.

[0095] In this embodiment, a four-level progressive positioning strategy, ranging from precise to fuzzy and from semantic to underlying layers, is employed, enabling each level to possess different positioning accuracy and fault tolerance. The first level utilizes a uniquely verified Cascading Style Sheet selector, offering the highest positioning accuracy and fastest execution speed, suitable for most scenarios under normal conditions. The second level employs a three-level index mapping table to search by text, role, and tag name, compensating for selector deficiencies through multi-dimensional semantic matching when selectors fail. The third level invokes the built-in semantic positioning interface of the browser's automated driving tools, capable of handling dynamically generated or frequently changing modern front-end framework components. The fourth level falls back to geometric coordinate positioning as a final fault tolerance guarantee.

[0096] When a high-precision strategy fails due to dynamic page changes or selector aging, it automatically degrades to the next level strategy to continue trying, avoiding the interruption of the entire test case execution due to the failure of a single strategy. Compared to existing positioning schemes that rely solely on a single selector or solely on text matching, the four-level progressive strategy in this embodiment can maintain a high positioning success rate under various boundary conditions (such as dynamic changes in element attributes, selector updates, page structure reconstruction, asynchronous rendering delays, etc.), thereby improving the robustness and reliability of large language model-generated test cases in the automated execution phase.

[0097] In some embodiments, the three-level index mapping table is constructed as follows: a first-level index is built by the visible text of the element; a second-level index is built by the WAI-ARIA attribute and role; and a third-level index is built by the HTML tag name.

[0098] Optionally, the three-level index mapping table is constructed in the following way: After completing the capture of all interactive elements and the generation of CSS selectors during the runtime DOM context capture phase, the execution engine immediately begins the process of building a three-level index mapping table. This index mapping table is stored in memory to support fast element lookup during subsequent test case execution phases.

[0099] First-level index: Indexing is built based on the visible text of elements. Preferably, the execution engine traverses all interactive elements that pass the visibility detection and extracts the visible text content actually displayed on the page for each element. For the extracted visible text, the execution engine establishes a mapping relationship from the text content to the corresponding set of element references.

[0100] In the first-level index, the execution engine constructs data structures for two matching patterns simultaneously: Exact match index: Stores the element reference corresponding to the complete visible text of the element as the key. When the test case provides the complete target text of the action (such as "Submit" on a button or "View More" in a link), the execution engine can directly locate the unique element through this index.

[0101] Substring Matching Index: For the visible text of each element, the execution engine extracts the first few characters of the text as a prefix key and stores them in a separate prefix index structure. When an exact match fails, the execution engine uses the prefix of the target text in the test case as a query condition to search for all candidate elements in the prefix index whose visible text begins with that prefix. If prefix matching still yields no results, the execution engine further performs inclusion matching, searching for all candidate elements in the visible text that contain the target text as a substring.

[0102] To optimize matching efficiency, the execution engine truncates the length of visible text, retaining only the first preset number of characters for index building, thus avoiding excessively long text content from affecting matching speed and storage efficiency.

[0103] Second-level index: An index is built based on WAI-ARIA attributes and roles. Preferably, the execution engine traverses all interactive elements and extracts the WAI-ARIA attributes and role information for each element. WAI-ARIA attributes include accessibility label attributes, accessibility description attributes, etc.; WAI-ARIA roles include button roles, link roles, checkbox roles, radio button roles, combo box roles, option roles, menu item roles, list box roles, etc.

[0104] The execution engine establishes a mapping relationship from role type to a collection of element references. Specifically, for elements with a clear WAI-ARIA role, the role name is used as the key to store all element references corresponding to that role; for elements with a WAI-ARIA attribute but without an explicitly declared role, the attribute name combined with the attribute value is used as a composite key for indexing.

[0105] The second-level index is primarily used in the following scenarios: test cases do not provide precise visible text (e.g., the element is a purely graphical button without a text label), but provide a semantic role description of the element (e.g., the "button" role in "Click the close button"). The execution engine can quickly filter out all candidate elements with that role through the role index, and then combine it with other auxiliary information for precise positioning.

[0106] Third-level index: Indexed by HTML tag names. Preferably, the execution engine traverses all interactive elements and extracts the HTML tag name of each element, including but not limited to: link tags, button tags, input box tags, text field tags, dropdown tags, option tags, etc.

[0107] The execution engine establishes a mapping from tag names to a set of element references. The third-level index, as the broadest index dimension, has relatively low positioning precision but the widest coverage. This index is mainly used in the following scenarios: test cases only describe the element type without providing any text or role information (such as "click the first input box on the page"). The execution engine can quickly retrieve all elements of the specified type through the tag index and then further filter them based on their position order or visual location in the document object model tree.

[0108] The three-level index mapping table is rebuilt after each page navigation or page refresh to ensure that the index data remains synchronized with the actual DOM state of the current page. For content dynamically loaded via asynchronous requests in single-page applications, the execution engine incrementally updates the index mapping table when it detects changes in the DOM structure, re-indexing only the changed parts to avoid the performance overhead of a full rebuild.

[0109] In this embodiment, a three-level index mapping table is constructed, progressively based on visible text, WAI-ARIA attributes and roles, and HTML tag names. Each level of the index has different matching precision and application scenarios. The first-level index is based on visible text, supports exact matching and substring matching, and can cover most positioning needs based on semantic description. It is the most commonly used and most accurate positioning method. The second-level index is based on WAI-ARIA attributes and roles, and can handle interactive elements without text tags or with dynamically changing text (such as graphic buttons and icon buttons), making up for the shortcomings of pure text matching. The third-level index is based on HTML tag names, and can filter by element type when text and role information are lacking, serving as the lowest-level semantic positioning guarantee.

[0110] The execution engine can flexibly select appropriate index dimensions for searching based on the types of information available in the test cases. When a single dimension cannot uniquely determine the target element, the execution engine can combine the index results of multiple dimensions for cross-filtering, gradually narrowing down the range of candidate elements until a unique element is determined. Compared to existing solutions that only provide single-dimensional search capabilities or require real-time traversal of the entire document object model tree, the three-level index mapping table in this embodiment achieves a good balance between location success rate and search efficiency, improving the response speed and accuracy of element location during the test case execution phase.

[0111] Figure 2The overall architecture diagram of the test case generation system based on a large language model provided in the embodiments of this application is as follows: Figure 2 As shown, the system can be divided into four main layers: information acquisition layer, information fusion layer, LLM generation layer, and execution verification layer. The specific functions of each layer are as follows: The information acquisition layer is responsible for obtaining raw data from the tested page from different dimensions, specifically including two parallel branches: Static Analysis Branch: Input is front-end source code (such as TSX, JSX, Vue, etc.). The source code is statically scanned and analyzed using a source code parser (e.g., source_driven_test_generator.py). Output is design-time element information, including predefined placeholders, options, and API definitions. This information reflects the pre-defined page structure and attributes during the development phase.

[0112] Runtime Scan Branch: The input is the web application under test. JavaScript is injected using automated tools (such as Playwright) (Playwright JS injection). The Document Object Model (DOM) tree is traversed within the browser context using a runtime DOM scanner (e.g., flow_executor.py::_build_element_map). The output is runtime element information, specifically including element coordinates, selectors, and visibility states. This reflects the actual state of the page after rendering.

[0113] The information fusion layer is responsible for standardizing the heterogeneous data obtained from the two branches mentioned above so that the large language model can understand it.

[0114] Page Context Formatter: Receives "design-time element information" from static analysis and "runtime element information" from runtime scans. It cleans, deduplicates, and restructures these two types of data.

[0115] Structured context text: Formatted data is transformed into a structured text format (such as JSON or a specific markup language) that can contain both static definitions and dynamic states of elements.

[0116] The LLM (Language Modeling) prompt assembly engine receives "structured context text" and combines it with a requirements document and a pre-defined prompt template (containing specific constraint rules). It embeds the contextual information into specific locations within the prompt template to generate the final complete prompt text sent to the large language model.

[0117] The LLM generation layer is responsible for generating test logic based on the context.

[0118] Large Language Model (LLM): Receives "complete prompt words" as input. Guided by pre-defined constraints (such as "prohibit fabricated elements" and "prefer text positioning"), the model performs inference based on the provided page context.

[0119] Output: The model outputs test case text, which typically includes operation steps described in natural language and the corresponding expected results.

[0120] Flow parser: For example, the parse_multi_flows module is responsible for parsing the unstructured or semi-structured text output by the LLM into machine-executable steps. This step transforms natural language into a standardized sequence of operational instructions.

[0121] The execution verification layer is responsible for implementing the generated steps and providing feedback.

[0122] The four-level progressive positioning engine is the core component of the execution. It receives "executable steps" and an element mapping table generated from the information gathering layer. This engine uses a hierarchical strategy (such as trying selectors first, then text matching if that fails, then coordinates if that fails, etc.) to accurately locate page elements.

[0123] Location result: The engine outputs the specific element location result for subsequent operations.

[0124] Playwright browser execution: Based on the location results and executable steps, drive the browser to perform specific user actions (such as clicking, typing, etc.).

[0125] Execution Report: Generates a report that includes the success / failure status of the location.

[0126] Feedback loop: If a location failure or other anomaly occurs during execution, the system will record a failure log. These logs, as negative samples, can be fed back into the system (e.g., used to optimize prompt word templates or update element mapping strategies), thus forming a closed loop of continuous optimization.

[0127] Figure 3 The flowchart for runtime element information collection and attribute extraction in a browser environment provided in the embodiments of this application is as follows: Figure 3 The diagram illustrates the process of performing deep scanning, filtering, and attribute extraction of page elements in a browser environment using automated testing tools (such as Playwright). The specific process includes the following steps: First, launch the browser context. Use an automated tool such as Playwright to launch the browser instance under test, navigate to the target URL, and load the web page under test.

[0128] During page loading, the system waits for the network to be idle to ensure that the main resources of the page (such as HTML, CSS, JavaScript and asynchronous data) have been fully loaded and the DOM tree has been built.

[0129] Subsequently, JavaScript is injected into the browser context of the current page. This script is used to perform subsequent DOM traversal and attribute extraction operations on the client side, bypassing the same-origin policy restriction and directly accessing the page's internal state.

[0130] After the script injection is complete, the system enters the stage of traversing interactive elements. The system scans the DOM tree according to a predefined list of interactive element selectors (such as a tag, button tag, input tag, select tag, and elements with specific role attributes).

[0131] During the traversal, a three-level index is built synchronously. The system builds indexes by priority: _by_text (text-based), _by_role (role-based), and _by_tag (tag-based) for quick element location later. For each element encountered, the system executes strict visibility detection logic to exclude invisible or invalid interfering elements: First, it checks if the element has been scanned. If scanned, it skips; otherwise, it continues. The `getBoundingClientRect` interface is called to obtain the element's geometric coordinates and dimensions. The width is checked to see if it is 0. If the width is 0, it is considered invisible, and further processing of the element is terminated. If the width is not 0, `getComputedStyle` is called to obtain the element's computed style. Key CSS properties are checked: `display` is checked for being none, `visibility` for being hidden, and `opacity` for being 0. If any of these conditions are met, the element is considered invisible, and processing is terminated. If none of these conditions are met (i.e., no), the element is considered visible, and the next step of attribute collection begins.

[0132] For valid elements that pass visibility detection, fine-grained attribute collection is performed. The system extracts multi-dimensional features including tag, type, id, text, placeholder, aria-label, role, coordinates, and size. Then, the getBestSelector algorithm is called to generate a multi-level priority CSS selector. This step generates a unique and robust CSS selector for the current element within the current page context, based on a preset priority strategy (e.g., ID over class name, stable class name over dynamic class name).

[0133] Finally, the extracted attribute information and the generated best selector are added to the result list. The system repeats the above steps until all target elements have been traversed, and finally outputs a complete list containing all visible and interactive elements on the page and their location information, which is used for subsequent interaction with the large language model.

[0134] Figure 4 The flowchart for the logical judgment of generating CSS selectors provided in the embodiments of this application is as follows: Figure 4 As shown, a preset priority chain strategy is used to try different attribute combinations sequentially to ensure that the generated locator is both stable and efficient. The specific process includes the following steps: The process begins with the input DOM element. The system first checks if the element has an `id` attribute. If yes, it directly returns an `id` selector (e.g., `#elementId`). This is the highest priority locator, offering uniqueness and extremely high stability. If no, it continues checking if the element has a `data-testid` attribute. If yes, it generates a `data-testid` selector. This is a test-specific attribute with priority second only to `id`. If no, it continues checking if the element has a `name` attribute. If yes, it generates a `tag+name` selector (e.g., `input[name="username"]`). Combining this with the tag name further narrows the selection. If no, it proceeds to the class processing logic.

[0135] If none of the above high-priority attributes exist, does the system check if the element has a class attribute? If not, skip this logic and proceed to subsequent ARIA attribute or text positioning logic. If yes, the system performs the operation of filtering dynamic state class names.

[0136] In this step, the system will remove class names that change with state (such as classes that start with dynamic keywords such as is-active or has-open), and only retain static class names with semantic meaning.

[0137] After filtering, a class selector is generated.

[0138] If an element does not have a valid class name, or the generated class selector is still insufficient for targeting, the system will continue to try the following attributes (logic branches in the diagram): Does it have an aria-label attribute? If yes, generate an aria-label selector. Does it have a title attribute? If yes, generate a title selector. Does it have a placeholder attribute? If yes, generate a placeholder selector.

[0139] If all attribute-based positioning methods fail (i.e., all conditions in the diagram are "no"), the system enters a path fallback strategy: the system obtains the parent DOM path and generates a css-path selector. While absolute or relative paths based on the DOM tree structure are slightly less robust, they guarantee the generation of a usable locator in all situations.

[0140] Finally, the process returns the generated selector, which can be used by the subsequent test case generation or execution module.

[0141] Figure 5 The timing interaction diagram provided for generating and executing test cases based on a large language model in the embodiments of this application is as follows: Figure 5 As shown, the process from user submission of test requirements to final generation of the test report involves four main interactive entities: user / requirement document, system (i.e., the test case generation system of this application), Playwright browser (as the runtime environment), and Large Language Model (LLM). The interaction flow between these entities specifically includes the following steps: Step 1: Submit Test Requirements. Users submit test requirements to the system through the front-end interface or API (or upload a requirement document). This requirement includes a description of the function to be tested and information such as the target URL.

[0142] Step 2: Launch and Navigation. After receiving the request, the system instructs the Playwright browser to launch an instance and automatically navigate to the target URL.

[0143] Step 3: Page Scanning. After the page loads, the system injects JavaScript into the Playwright browser. The browser executes this script to scan the DOM structure of the current page, identifying interactive elements and their attributes.

[0144] Step 4: Return Element Information. The Playwright browser returns a list of scanned elements to the system. This list includes runtime properties such as element coordinates, CSS selectors, tag names, visibility, and text content.

[0145] Step 5: Context Construction. The system processes the received list of elements, formatting it into page context text. Additionally, the system can selectively parse the front-end source code to obtain static element information (design-time attributes), and merge the two to form a structured text summary containing the entire page view.

[0146] Step 6: Assemble and Send Prompt Messages. Based on a preset prompt message template, the system assembles the page context text with the user's requirements document to construct a complete prompt message containing strictly constrained instructions. The system then sends this prompt message to the large language model.

[0147] Step 7: Generate and return test cases. The large language model infers based on the page context information in the prompt words, generates test case text that conforms to the constraints (including operation steps and location information), and returns it to the system.

[0148] Step 8: Parsing and Execution. After receiving the text returned by the large language model, the system parses it into executable flow steps. Subsequently, the system instructs the Playwright browser to execute test operations (such as clicking, typing, etc.) sequentially according to the parsed steps.

[0149] Step 9: Four-level progressive positioning verification. During each step, the Playwright browser internally executes a four-level progressive positioning verification strategy. This involves sequentially attempting to locate the target element using CSS selectors, index maps, semantic positioning interfaces, and coordinate positioning to ensure robust positioning.

[0150] Step 10: Feedback on execution results. The Playwright browser will report the execution results of each step (including whether the location was successful or failed) back to the system.

[0151] Step 11: Generate Test Report. The system summarizes all execution results, generates the final test report, and sends it back to the user / requirements document.

[0152] According to another aspect of the embodiments of this application, a test case generation system is provided. Figure 6 A schematic diagram of the test case generation system provided in the embodiments of this application, such as... Figure 6 As shown, the test case generation system includes: an attribute acquisition module 602, a static analysis module 604, an information fusion module 606, a prompt word construction module 608, and a test case generation module 610. The test case generation system will be described in detail below.

[0153] The attribute acquisition module 602 is used to acquire the dynamic rendering attributes of interactive elements of the page under test in the runtime environment.

[0154] The static analysis module 604, connected to the attribute acquisition module 602, is used to perform static analysis on the front-end source code of the page under test and extract the static structure information of interactive elements.

[0155] The information fusion module 606, connected to the static analysis module 604, is used to fuse static structural information and dynamic rendering attributes into structured page context information.

[0156] The prompt word construction module 608, connected to the aforementioned information fusion module 606, is used to embed page context information as the element information source of the large language model into preset prompt words; the prompt words contain preset constraint instructions that the large language model can only reference elements listed in the page context information to generate positioning information.

[0157] The test case generation module 610, connected to the aforementioned prompt word construction module 608, is used to call the large language model that embeds page context information and constraint instructions to generate test cases.

[0158] It should be noted that the attribute acquisition module 602, static analysis module 604, information fusion module 606, prompt word construction module 608, and use case generation module 610 mentioned above correspond to steps S102 to S110 in the method embodiment. The examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above method embodiment.

[0159] According to another aspect of the embodiments of this application, an electronic device is provided, including: a processor, and a memory storing a program, the program including instructions that, when executed by the processor, cause the processor to perform the methods of the embodiments of this application.

[0160] refer to Figure 7 The present invention describes a structural block diagram of an electronic device that can serve as a server or client in embodiments of this application, which is an example of a hardware device that can be applied to various aspects of this application. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the application described and / or claimed herein.

[0161] like Figure 7As shown, the electronic device includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 702 or a computer program loaded into a random access memory (RAM) 703 from a storage unit 708. The RAM 703 may also store various programs and data required for the operation of the electronic device. The computing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0162] Multiple components in the electronic device are connected to I / O interface 705, including: input unit 706, output unit 707, storage unit 708, and communication unit 709. Input unit 706 can be any type of device capable of inputting information into the electronic device. Input unit 706 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of the electronic device. Output unit 707 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 708 may include, but is not limited to, disks and optical discs. Communication unit 709 allows the electronic device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, and wireless communication transceivers, such as Bluetooth devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0163] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, CPUs, graphics processing units (GPUs), various special-purpose artificial intelligence (AI) computing units, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above. For example, in some embodiments, the method embodiments of this application can be implemented as computer programs tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed on an electronic device via ROM 702 and / or communication unit 709. In some embodiments, the computing unit 701 can be configured to perform the methods described above by any other suitable means (e.g., by means of firmware).

[0164] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein, when the program is running, it controls the device where the computer-readable storage medium is located to execute the method of the embodiments of this application.

[0165] The computer-readable storage medium can be any medium capable of storing program code, including but not limited to: disks, optical disks, solid-state drives (SSDs), read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), flash memory, USB flash drives, portable hard drives, magneto-optical disks, CD-ROMs, DVD-ROMs, etc. This storage medium can be sold or distributed as a standalone product. When installed in a general-purpose computing device, it enables the device to generate test cases as described in this application.

[0166] It should be noted that the term "comprising" and its variations used in the embodiments of this application are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; and the term "some embodiments" means "at least some embodiments". The modifications of "one" and "multiple" mentioned in the embodiments of this application are illustrative and not restrictive. Those skilled in the art should understand that, unless explicitly indicated otherwise in the context, they should be understood as "one or more".

[0167] The steps described in the method embodiments provided in this application can be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of protection of this application is not limited in this respect.

[0168] The term "embodiment" in this specification refers to a specific feature, structure, or characteristic described in connection with an embodiment that may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily imply the same embodiment, nor does it imply independence from or alternative to other embodiments. The various embodiments in this specification are described in a related manner, with reference to each other for similar or identical parts. In particular, for apparatus, device, and system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, and relevant details are referred to in the description of the method embodiments.

[0169] 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 patent protection. 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 scope of protection of this application. Therefore, the scope of protection of this application should be determined by the appended claims.

Claims

1. A test case generation method characterized by, include: Get the dynamic rendering properties of interactive elements on the page under test in the runtime environment; Static analysis is performed on the front-end source code of the page under test to extract the static structure information of interactive elements; The static structural information and the dynamic rendering attributes are merged into structured page context information; The page context information is used as the element information source of the large language model and embedded into the preset prompt words; The prompt word is pre-set with a constraint instruction that the large language model can only refer to the elements listed in the page context information to generate location information; The large language model, which embeds the page context information and the constraint instructions, is invoked to generate test cases.

2. The method of claim 1, wherein, Obtain the dynamic rendering properties of interactive elements on the tested page in the runtime environment, including: By executing a script in the browser context of the page under test, interactive elements on the page are identified, and visibility detection is performed on each interactive element to exclude invisible elements. Collect the tag name, HTML attributes, WAI-ARIA attributes and roles, disabled status, geometric coordinates and size information of the interactive elements that pass the detection; Generate a uniquely verified CSS selector for each interactive element; wherein, generating the CSS selector includes: matching element attributes sequentially according to a preset priority chain, and filtering out CSS class names that begin with dynamic state keywords.

3. The method of claim 2, wherein, The visibility detection includes: Determine the geometric dimensions of an element, filtering out elements whose width and height are both 0; Get the calculated style of an element, and filter elements with a display property value of none, a visibility property value of hidden, or an opacity property value of 0.

4. The method according to claim 1, characterized in that, The process of fusing the static structural information with the dynamic rendering attributes into structured page context information includes: The static structural information is used as the structural definition of the page element, and the dynamic rendering attributes are used as the current state parameters of the page element. In the preset prompt word template, the structure definition is associated with the current state parameter to generate a structured text summary containing visible text, attributes, and coordinates of elements.

5. The method according to claim 2, characterized in that, Following the generation of test cases, the following is also included: Based on the CSS selectors and visible text carried in the generated test cases, a four-level progressive positioning strategy is used to parse and execute the generated test cases; When the positioning operation fails, a failure log is recorded, and the failure log is used as a negative sample to update the constraint instructions in the prompt word.

6. The method according to claim 5, characterized in that, The four-level progressive positioning strategy includes: The first level involves using the CSS selectors in the test cases to locate elements. The second level involves searching for elements if the first level fails. The element is searched using a pre-built three-level index mapping table, which is indexed by the visible text of the element, the WAI-ARIA attribute, the role, and the HTML tag name. The third level, if the second level of location fails, calls the semantic location interface of the browser's automation-driven tool to locate the location. Fourth level: If the third level of positioning fails, then fall back to the geometric coordinates carried in the test case for positioning.

7. The method according to claim 6, characterized in that, The three-level index mapping table is constructed in the following way: A first-level index is created based on the visible text of each element; Create a second-level index based on WAI-ARIA attributes and roles; Create a third-level index based on HTML tag names.

8. A test case generation system, characterized in that, include: The attribute acquisition module is used to obtain the dynamic rendering attributes of interactive elements of the page under test in the runtime environment; The static analysis module is used to perform static analysis on the front-end source code of the page under test and extract the static structure information of interactive elements. The information fusion module is used to fuse the static structural information with the dynamic rendering attributes into structured page context information; The prompt word construction module is used to embed the page context information as the element information source of the large language model into preset prompt words; The prompt word is pre-set with a constraint instruction that the large language model can only refer to the elements listed in the page context information to generate location information; The test case generation module is used to call the large language model that embeds the page context information and the constraint instructions to generate test cases.

9. An electronic device, comprising: A processor and a memory storing a program, characterized in that the program includes instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform the method of any one of claims 1 to 7.

Images