An automated script generation method

Abstract

The application provides an automatic script generation method, and relates to the technical field of data processing.The method comprises the following steps: step 1, extracting initial user interface elements and corresponding element attributes, constructing an initial UI model, wherein the initial UI model comprises layout information and interaction attributes of the initial user interface elements; generating a basic test script segment based on the initial UI model; step 2, executing the basic test script segment, setting multiple interactive behavior tracking points in the user interface, and obtaining user interface state change data; updating the initial UI model based on the user interface state change data to form an updated UI model. Through iterative optimization of the UI model, division of functional areas, generation of test adaptation parameters and condition test branches, and integration into a data-driven test framework, the application can cover a comprehensive complete automatic test script and improve the automation efficiency of test script generation.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to an automated script generation method. Background Technology

[0002] In existing automated test script generation technologies, test scripts are typically generated primarily through static analysis of user interface (UI) elements. A common approach is to pre-record user actions and generate scripts based on relatively fixed UI properties. However, as application functionality becomes richer and the user interface is dynamically adjusted, such static methods may face some adaptation challenges.

[0003] Specifically, existing technologies may have limited adaptability when faced with updates to UI layout or interaction logic. For example, in the order placement process of an e-commerce application, if a coupon selection area is added to the interface or the attributes of the payment button are adjusted, the script generation method based on static analysis may not be able to fully recognize these changes. This may cause the test script to encounter difficulties during execution or fail to fully cover the new interaction path. In addition, existing methods may have some shortcomings in the intelligent division of interface functional areas and the analysis of context-dependent behaviors, which may affect the adaptability and stability of the generated test scripts in complex scenarios. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide an automated script generation method to improve the generation efficiency of automated test scripts and enhance the adaptability of scripts to user interfaces.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0006] Firstly, an automated script generation method, the method comprising:

[0007] Step 1: Extract the initial user interface elements and their corresponding element attributes to construct an initial UI model. The initial UI model includes the layout information and interaction attributes of the initial user interface elements. Generate basic test script fragments based on the initial UI model.

[0008] Step 2: Execute the basic test script fragment and set multiple interaction behavior tracking points in the user interface to obtain user interface state change data; update the initial UI model based on the user interface state change data to form the updated UI model;

[0009] Step 3: Generate supplementary test script fragments based on the updated UI model, and construct a spatial segmentation map structure by analyzing the spatial distribution characteristics of user interface elements; establish the spatial influence area of ​​user interface elements based on the spatial segmentation map structure, and identify the boundary of high-density clustering area based on the spatial influence area; determine the functional area division scheme based on the boundary of high-density clustering area, and classify user interface elements into multiple functional areas according to their functional characteristics based on the functional area division scheme.

[0010] Step 4: Based on the user interface state change data, analyze the layout features and interaction attributes of user interface elements in each functional area, generate test adaptation parameters, and generate conditional test script branches based on the test adaptation parameters and the context dependency behavior of user interface elements.

[0011] Step 5: Integrate the basic test script fragments, supplementary test script fragments, and conditional test script branches into the data-driven testing framework to form a complete automated test script.

[0012] In a second aspect, a computing device includes:

[0013] One or more processors;

[0014] A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.

[0015] Thirdly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.

[0016] The above-described solution of the present invention has at least the following beneficial effects:

[0017] By leveraging interactive behavior tracking points and a dynamic UI model update mechanism, newly added dynamic elements during execution can be captured in real time, such as coupon areas and element state changes in e-commerce apps, like payment buttons changing from unclickable to clickable. This allows for iterative updates to the UI model, avoiding static script failures or incomplete coverage, and improving script adaptability in applications with frequent feature iterations. Based on the spatial distribution characteristics of UI elements, a spatial segmentation map is constructed, and spatial influence areas are established. This allows for the identification of high-density cluster boundaries to delineate core functional areas such as navigation areas, content display areas, and user operation areas. The design of elements categorized according to functional characteristics enables test scripts to be specifically adapted to the interactive characteristics of different areas, improving the logical clarity and execution stability of scripts in complex interfaces. Furthermore, by extracting layout features and interactive attributes of elements within each functional area based on UI state change data, regionalized test adaptation parameters are generated, and conditional test script branches are constructed. This allows the script to possess dynamic judgment logic, adjusting the execution path based on the results of preceding operations, effectively reducing the operation failure rate.

[0018] By integrating modular script fragments and parameterized datasets through a data-driven testing framework, the decoupling of scripts from test data and adaptation parameters is achieved. When the UI layout or interaction logic changes, only the UI model needs to be updated, script fragments supplemented, or adaptation parameters adjusted, without refactoring the entire script. It also supports batch expansion of test cases, such as adding test scenarios with different coupon types, improving script reusability and expansion efficiency. With the static basic interaction coverage built from the initial UI model, combined with dynamic element interaction paths supplemented by dynamic state capture, and further supplemented by context-dependent branch scenario coverage, a full-dimensional test coverage system is formed, which is more comprehensive than single static script coverage. At the same time, the optimization of regional adaptation parameters reduces invalid waiting and failure retries during script execution, improving test execution efficiency. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating an automated script generation method provided by an embodiment of the present invention.

[0020] Figure 2 This is a flowchart illustrating step 3 provided in an embodiment of the present invention. Detailed Implementation

[0021] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0022] like Figure 1 As shown, an embodiment of the present invention proposes an automated script generation method, the method comprising the following steps:

[0023] Step 1: Extract the initial user interface elements and their corresponding element attributes to construct an initial UI model. The initial UI model includes the layout information and interaction attributes of the initial user interface elements. Generate basic test script fragments based on the initial UI model.

[0024] Step 2: Execute the basic test script fragment and set multiple interaction behavior tracking points in the user interface to obtain user interface state change data; update the initial UI model based on the user interface state change data to form the updated UI model;

[0025] Step 3: Generate supplementary test script fragments based on the updated UI model, and construct a spatial segmentation map structure by analyzing the spatial distribution characteristics of user interface elements; establish the spatial influence area of ​​user interface elements based on the spatial segmentation map structure, and identify the boundary of high-density clustering area based on the spatial influence area; determine the functional area division scheme based on the boundary of high-density clustering area, and classify user interface elements into multiple functional areas according to their functional characteristics based on the functional area division scheme.

[0026] Step 4: Based on the user interface state change data, analyze the layout features and interaction attributes of user interface elements in each functional area, generate test adaptation parameters, and generate conditional test script branches based on the test adaptation parameters and the context dependency behavior of user interface elements.

[0027] Step 5: Integrate the basic test script fragments, supplementary test script fragments, and conditional test script branches into the data-driven testing framework to form a complete automated test script.

[0028] In this embodiment of the invention, through interactive behavior tracking points and a dynamic UI model update mechanism, newly added dynamic elements during execution can be captured in real time, such as the coupon area and element state changes in an e-commerce APP, such as the payment button changing from unclickable to clickable. The UI model is then iteratively updated to avoid the problem of static script failure or incomplete coverage, thus improving the adaptability of the script in applications with frequent function iterations. Based on the spatial distribution characteristics of UI elements, a spatial segmentation map is constructed, and spatial influence areas are established. Then, the boundaries of high-density clustering areas are identified to divide core functional areas such as navigation areas, content display areas, and user operation areas. The design of elements is categorized according to functional characteristics, enabling the test script to be specifically adapted to the interactive characteristics of different areas, improving the logical clarity and execution stability of the script under complex interfaces. Based on UI state change data, the layout characteristics and interactive attributes of elements in each functional area are extracted, regionalized test adaptation parameters are generated, and conditional test script branches are constructed, allowing the script to have dynamic judgment logic. The execution path can be adjusted according to the results of previous operations, effectively reducing the operation failure rate.

[0029] By integrating modular script fragments and parameterized datasets through a data-driven testing framework, the decoupling of scripts from test data and adaptation parameters is achieved. When the UI layout or interaction logic changes, only the UI model needs to be updated, script fragments supplemented, or adaptation parameters adjusted, without refactoring the entire script. It also supports batch expansion of test cases, such as adding test scenarios with different coupon types, improving script reusability and expansion efficiency. With the static basic interaction coverage built from the initial UI model, combined with dynamic element interaction paths supplemented by dynamic state capture, and further supplemented by context-dependent branch scenario coverage, a full-dimensional test coverage system is formed, which is more comprehensive than single static script coverage. At the same time, the optimization of regional adaptation parameters reduces invalid waiting and failure retries during script execution, improving test execution efficiency.

[0030] In a preferred embodiment of the present invention, step 1 includes:

[0031] Step 100: Parse the target application's UI definition files and source code, identify and extract all initial user interface elements. Specifically, this includes: parsing the target application's UI definition files and source code, identifying and extracting all initial user interface elements. First, determine the target application's operating platform (Android mobile, iOS mobile, or web), and select a dedicated parser accordingly. For Android mobile, match a dedicated parser for Android layout files; for iOS mobile, match a dedicated parser for iOS UI description files; and for web, match a dedicated parser for web document structure. Then, initiate the structured parsing process, simultaneously parsing the two types of core files of the target application. The first type is the UI definition file, which directly describes the core structure of the interface, containing the hierarchical relationship of layout tags, such as which component contains which child component, the unique identifier of each component, exclusive tags used to distinguish different components, and styles. The first category consists of parameters, such as the component's width, height, color, margins, font size, and other appearance configurations; and bound events, such as key configuration information triggered by user interactions like clicks, inputs, swipes, and long presses associated with the component. The second category is the front-end page rendering related source code. This type of code is responsible for controlling the loading and display of interface components. It covers component import statements (code used to import system-provided components or external components, through which the external component library used by the application can be identified), custom component class definitions (including component attribute descriptions and function implementation methods) and instance creation code (code that generates component instances through keywords), component mounting rules for rendering functions, such as how the web page rendering function loads components onto the page, how the mobile page loading method loads the layout, and conditional rendering triggering logic (logic that controls whether components are displayed through conditional statements, dedicated rendering instructions, component show / hide attributes, etc.).

[0032] During the parsing process, the parser strictly adheres to the syntax specifications of the corresponding files. The Android parser parses the layout hierarchy and component attributes according to the syntax rules of the Android layout file; the Apple parser parses the component relationships and parameters according to the format of the Apple UI description file; and the web parser parses the tag structure and rendering logic according to the web document specifications and development framework syntax. Ultimately, the tag nesting relationships, component configuration parameters, component call flow, and rendering trigger conditions in the source code are all transformed into a standardized abstract syntax tree. Each node in this syntax tree contains complete information, namely the component type (clearly marked as a button, text box, dropdown, list view, etc.), attribute configuration (including unique identifiers, style parameters, event binding lists, etc.), parent node reference (recording the identifier of the component's direct parent component), and instantiation path (recording the complete code path from the component being imported to the creation of an instance), ensuring that the information of each component is traceable.

[0033] Next, a depth-first traversal algorithm is used to identify elements. Starting from the root node of the abstract syntax tree (the root tag for web pages, the root layout component for Android, and the root component of the application window for iOS), all child nodes are traversed layer by layer in the recursive order of root node, child node, and grandchild node. For each node, type determination and element identification are performed. The focus is on identifying declaratively defined user interface elements, which are explicitly defined directly in the file. These include layout container tags, input box tags, button tags, drop-down selection tags, etc. on web pages; button components, input text components, text display components, list display components, etc. on mobile devices; after identifying external component libraries through component import statements, component instances are imported from the library and created using keywords; and custom components are defined by classes and then generated through constructors. For each identified element, its core information, such as component type, attribute configuration, parent node reference, and instantiation path, is recorded and stored in the initial element set. Simultaneously, a component instantiation call tracing mechanism is activated. Static code analysis tools are used to reverse-verify implicitly declared elements in the source code. These elements are not directly defined in the initial code and only appear under certain conditions. The focus is on tracing component instantiation triggered by dynamic function calls, such as functions that dynamically create components on the webpage or methods that dynamically load layouts on mobile devices, as well as components created through conditional rendering logic, such as those triggered by user actions or changes in data state. Examples include list item components loaded only after clicking the "Expand More" button, pop-up components displayed only after the user's input meets the requirements, and chart components created only after data loading is complete. These implicit elements are marked one by one and added to the initial element set to ensure that all initial user interface elements are identified without omission.

[0034] Suppose we want to extract the initial user interface elements of the product list page of an Android mobile shopping app. The specific process is as follows: First, we check that the installation package of this Android mobile shopping app is a dedicated Android system installation package, and the development documentation also clearly marks it as an Android mobile application. Therefore, we specifically select an Android layout file parser. When parsing the core file, we parse the Android layout configuration file of the product list page. We find that it contains a linear layout component (used to nest and wrap product card components), a text display component (used to display product name and product price respectively), a button component (marked with the add to cart function), and an image component (used to load and display product images). Each component is configured... The code is uniquely identified, with the button component bound to a click event and the text component explicitly configured with style parameters such as font size and font color. On the other hand, the Android development code is analyzed to identify component import statements such as importing system button components and importing image components from external image loading component libraries. This confirms that the application uses an external image loading component library. The code also contains the class definition of the custom component product card (covering attribute declarations such as product name and price, as well as button click event handling methods), the product card instance code created by keywords, and conditional rendering logic (explicitly setting that the add to cart button is automatically hidden when the product inventory is 0).

[0035] After completing the core file parsing, the parser strictly follows the Android layout file syntax rules, converting all the information such as the tag nesting relationship, component configuration parameters, component call flow, and rendering trigger conditions in the above interface definition file into a standardized abstract syntax tree. For example, the node information of the "Add to Cart" button is particularly specific, including component type (button), attribute configuration (unique identifier, width 80px, height 30px, red background), parent node reference (unique identifier of the product card component), and instantiation path (after importing the system button component, an instance is created by keyword and then mounted to the product card component), ensuring that the information of each node is complete and traceable.

[0036] After the abstract syntax tree is generated, a depth-first traversal algorithm is used to recursively traverse all child nodes from the root layout component node, identifying each declaratively defined user interface element. This process ultimately identifies elements such as linear layout components, product name text components, product price text components, add-to-cart button components, image components from external image loading libraries, and custom product card instances. The core information of these elements, including component type, attribute configuration, parent node reference, and instantiation path, is stored in the initial element set. Simultaneously, a component instantiation call tracing mechanism is initiated. Static code analysis tools are used to reverse-verify implicitly declared elements in the source code. During this process, it was discovered that the code contains logic where clicking the "load more" button calls a dynamic layout method to create a new product card component. This new product card component is only instantiated after a click, making it an implicitly declared element. Furthermore, combined with the previously analyzed conditional rendering logic of hiding the add-to-cart button when the product inventory is 0, the corresponding inventory 0 prompt text component (which is only displayed when the inventory is 0) is also identified as an implicit element. These two types of implicit elements are then marked and added to the initial element set.

[0037] After the above series of processes, the final initial element set covers all relevant elements, including linear layout components, product name text components, product price text components, add to cart button components, product image components, custom product card instances, new product card components generated after loading more, and inventory 0 prompt text components. This fully covers all initial user interface elements of the product list page, ensuring that nothing is omitted.

[0038] Step 101: Collect the element attributes of each initial user interface element, including position coordinates, size, element type, and interactive state. Specifically, after completing the full recognition of the initial user interface elements in Step 100, call the dedicated attribute reading interface of the corresponding platform's interface rendering engine to accurately collect the core attributes of each element. The position coordinates are recorded using a two-dimensional coordinate system relative to the element's direct parent container. First, locate the element's direct parent container, such as the linear layout container in Android or the layout container in a webpage. Then, use the methods of the mobile view class to get the distance from the left side to the left edge of the parent container and the distance from the top to the top edge of the parent container, or the offset of the left side and the offset of the top edge of the webpage document element relative to the parent container, to directly read the horizontal coordinate (x1) and vertical coordinate (y1) of the top left corner of the element. Use the methods of the mobile view class to get the distance from the right side to the left edge of the parent container and the distance from the bottom edge of the parent container, or the offset of the right side and the offset of the bottom edge of the webpage document element relative to the parent container, to read the bottom right corner of the element. The horizontal (x2) and vertical (y2) coordinates of the vertex are used for identification. The size is calculated based on the collected coordinates of the two vertices using the formula: width = x2 - x1, height = y2 - y1. The element type is determined by parsing the component's declaration identifier. For example, in an Android layout file, a component corresponding to a button tag is identified as a button type; in a webpage, a component with an input tag and a text input function is identified as an input box type; and a selection component instance imported from the component library is identified as a dropdown menu type. Specific types such as buttons, input boxes, list items, dropdown menus, and checkboxes are clearly categorized. The interactive state is determined by comprehensively reading multiple core attribute fields of the element, setting a priority for judgment. First, the enabled state is checked; if the enabled state is not enabled, all interactions are excluded. Then, specific interactive attributes are checked. If the enabled state is enabled and the clickable state is allowed, click operations are supported; if the enabled state is enabled and the inputable state is allowed, input operations are supported; if the enabled state is enabled and the selectable state is allowed, selection operations are supported. Finally, all interaction types supported by each element are determined.

[0039] Step 102: Construct an initial UI model based on the initial user interface elements and element attributes, establish the hierarchical relationship between the initial user interface elements, and generate a basic test script fragment containing a complete operation sequence based on the layout information and interaction attributes of the initial user interface elements in the initial UI model. Specifically, this includes: based on the complete element attributes collected in Step 101 and the set of initial user interface elements identified in Step 100, constructing the initial UI model with each element as an independent node. First, based on the tag nesting relationship in the interface definition file, such as the relative layout parent tag containing text display child tags in Android layout files, and the form parent tag containing button child tags in web pages, combined with the calling logic of parent and child components in the source code, such as the direct call of child components within the rendering function of the parent component, and the association achieved through reference passing by child components, establish a four-level hierarchical relationship. The root node is the core page container, such as the mobile page container in Android, the Apple page controller in Apple, and the main page container in web pages. The second level is the page layout container, such as the linear layout container in Android and the web page layout block in web pages. The third level is the business function module, such as the login module and the product list module. The fourth level is the specific user interface element, where the execution logic of the rendering function is... The rendering result is quantified by the formula: Rendering function execution result = Basic component mounting order + Conditional trigger flag × Number of dynamic component instantiations. In this formula, the basic component mounting order is a sequence of ordered values ​​(1, 2, 3...) based on the application interface's preset fixed component loading priority; smaller values ​​indicate higher component mounting priority. The conditional trigger flag is a binary variable; a value of 0 indicates no conditional rendering has been triggered (no additional dynamic components need to be loaded), while a value of 1 indicates conditional rendering has been triggered (dynamic components need to be loaded according to the rules). The number of dynamic component instantiations is the actual number of components added after triggering conditional rendering. The number of components is quantized as a non-negative integer of 0 or above (0 when not triggered, and the value is based on the actual number of newly added components after triggering). Through the calculation logic of this formula, the final rendering order of components (sorted by the numerical value of the rendering function execution result) and the number of instantiations (the sum of the number of basic components and the number of dynamically added components) can be directly determined, realizing the standardized definition of component rendering rules. The initial UI model synchronously stores complete information such as the hierarchical relationship, position coordinates, size, element type, and interactive state of each element. Combined with the above quantized rendering rules, a structured and traceable initial UI model is finally formed.

[0040] When generating basic test script fragments based on the initial UI model, interactive elements are first sorted according to the rule that the core priority of the business process is higher than the visual order. Elements related to the core business process are prioritized. For example, on the login page, you need to enter your account first, then your password, then check the agreement, and finally click login, strictly following the business logic order. Elements without business dependencies are sorted according to the visual order of the interface from top to bottom and from left to right. Then, a unique positioning method is generated for each interactive element. The unique identifier of the element is extracted first as the positioning basis. If the element does not have a unique identifier, a compound positioning expression is generated by combining the hierarchical path description (the complete hierarchical link from the root node to the element) + the position coordinate range (the interval formed by the coordinates of the upper left corner x1, y1 and the coordinates of the lower right corner x2, y2) + the element type to ensure that the positioning result is unambiguous. Finally, the corresponding interaction action type is matched for each element, such as clicking, entering fixed test data, selecting drop-down options, etc. All positioning expressions and interaction actions are concatenated in sequence according to the sorting result to form a basic test script fragment containing a complete operation sequence.

[0041] This embodiment achieves comprehensive identification and accurate attribute collection of initial user interface elements by parsing the interface definition file and source code, avoiding the element omission problem caused by static analysis relying on manual recording. The constructed initial UI model clarifies the hierarchical relationship and interaction attributes between elements, providing a structured basis for generating basic test script fragments. The generated basic test script fragments containing complete operation sequences cover the core interaction paths of the initial interface, solving the defect of incomplete initial path coverage in static scripts and improving the initial completeness and execution accuracy of the test scripts.

[0042] In a preferred embodiment of the present invention, step 2 includes:

[0043] Step 200: Execute the operation sequence in the basic test script fragment and set interaction behavior tracking points in key interactive areas of the user interface, including setting the first interaction behavior tracking point in the top navigation area, the second interaction behavior tracking point in the main content display area, and the third interaction behavior tracking point in the bottom operation area. Specifically, this includes: first, loading the basic test script fragment generated in step 102 into the automated test execution engine corresponding to the target application platform, where mobile applications are adapted to the mobile automated test execution engine and web applications are adapted to the web automated test execution engine. The execution engine simulates the operation logic of a real user and executes the operation sequence contained in the script in sequence. At the same time, through the element listening interface of the test execution engine, interaction behavior tracking points are deployed in the three key interactive areas of the user interface. The first interaction behavior tracking point is deployed in the top navigation area of ​​the interface. First, the actual height value of the top navigation bar component is obtained through the execution engine, and then the coverage lower limit is calculated according to the formula: coverage lower limit = vertical coordinate value of the top edge of the interface + height value of the top navigation bar. The coverage area of ​​the first tracking point is calculated, where the vertical coordinate value of the top edge of the interface is fixed at 0, and the final coverage area is defined as the top edge of the interface (vertical coordinate value 0) to the lower edge corresponding to the lower limit of the coverage area; the second interaction behavior tracking point is deployed in the main content display area, and its coverage area is from the bottom edge of the top navigation bar to the top edge of the bottom operation area, where the top edge of the bottom operation area is calculated by the formula: top edge of bottom operation area = vertical coordinate value of the bottom edge of the interface - height value of the bottom operation area component. The execution engine needs to obtain the vertical coordinate value of the bottom edge of the interface and the height value of the bottom operation area component first; the third interaction behavior tracking point is deployed in the bottom operation area, and its coverage area is directly defined as the top edge of the bottom operation area to the bottom edge of the interface; each interaction behavior tracking point is bound to four types of core events, namely element loading events, such as the page loading completion event of the webpage, the interface layout completion event of the mobile terminal, the rendering completion event, the attribute change listening mechanism, and core interaction events, such as click, input, etc. Through multi-event binding, comprehensive and real-time monitoring of the state changes of elements in the corresponding area is achieved.

[0044] Step 201 involves recording user interface state change data in real time through interaction behavior tracking points, and identifying dynamically loaded user interface elements and their state changes based on this data. Specifically, this includes: three interaction behavior tracking points capturing various user interface state change data in real time through bound event listener callback functions. The execution logic of these callback functions is described by a quantification formula: O = I × W + C + T, where O represents the output result of the event listener callback function, i.e., the standardized state change data encoding; I represents the unique identifier encoding of each user interface element, which is a unique positive integer generated by mapping the element's unique identifier. To ensure that the encoding of different elements is unique; W represents the event type weight, with a fixed value preset according to the state change type (element addition W=1, element deletion W=2, position coordinate offset W=3, size parameter adjustment W=4, element type association change W=5, interactive state switch W=6, show or hide state change W=7); C represents the change content quantification value, which is the numerical value converted from the specific change information, such as the position offset directly taking the coordinate difference, and the state switch using 0 / 1, where 0 corresponds to the initial state and 1 corresponds to the changed state; T represents the timestamp serialization value, which is the value converted from the original timestamp into a 10-digit integer format to ensure that the time dimension is traceable.

[0045] All data captured and standardized through this callback function is stored in a fixed structure: unique element identifier, change type, change content, and change timestamp. The data coverage includes various interface state changes such as element addition, element deletion, position coordinate offset, size parameter adjustment, element type association change, interactive state switching, and show or hide state change. After data capture, all state change data is aligned and compared with the element information in the initial UI model one by one. That is, using the unique element identifier as the core index, elements without matching records in the initial UI model are first filtered out. Then, the visibility verification mechanism of the tracking point is used to verify whether the element meets the condition of "display state is display and visibility state is visible". Elements that meet the condition are directly determined as dynamically loaded user interface elements. At the same time, for elements that already exist in the initial UI model, the specific values ​​of each attribute field before and after the change are recorded one by one. Finally, the complete information of dynamically loaded elements and the state change information of the original elements are integrated to form a structured user interface element state change dataset.

[0046] Step 202 involves updating the initial UI model using dynamically loaded user interface elements and their state changes to form the updated UI model. Specifically, this includes: based on the user interface element state change dataset generated in Step 201, updating the initial UI model. First, for dynamically loaded user interface elements identified in the dataset, the direct parent container of the element in the current interface is located through its parent container association attributes. Then, the specific hierarchical position of this direct parent container in the initial UI model is queried. Following the four-level hierarchical structure rules of the initial UI model, the dynamically loaded element is inserted as a child node into the corresponding level. Simultaneously, all core attribute information of the dynamic element, such as its position coordinates, size, element type, and interactive state, is fully supplemented to ensure the structural and attribute integrity of the dynamic element in the model. Next, for the original element change information recorded in the dataset, the corresponding elements in the initial UI model are traversed sequentially according to their unique identifiers. The position coordinate parameters, size values, and other parameters of each element are corrected one by one. The new interactive state identifier, along with all other changed attribute fields, ensures that the attribute information of the original elements in the model remains consistent with the actual state of the interface. After all dynamic element addition operations and original element attribute update operations are completed, the automated test execution engine collects the actual information of all elements in the current interface in real time. The collected actual information is then used to perform a comprehensive consistency check with the updated UI model. The check scope covers the hierarchical relationship of elements and all attribute fields. The check rule is clearly set so that the error value of a single attribute field is ≤ the preset error threshold. The preset error threshold for coordinate (position coordinates) and size (size) attributes is ±1 pixel, while the preset error threshold for state (interactive state, display state), type (element type), and structure (hierarchical relationship) attributes is 0, meaning they are completely consistent. This rule ensures that the errors of all data in the model are within a reasonable range, ultimately making the updated UI model completely match the actual state of the interface, forming a standardized and highly accurate updated UI model.

[0047] This embodiment achieves comprehensive capture of user interface state change data by setting targeted interaction behavior tracking points in key interaction areas, effectively identifying the state changes of dynamically loaded user interface elements and existing elements, thus compensating for the inability of static analysis to perceive dynamic interface changes. By iteratively optimizing the initial UI model through a dynamic update mechanism, the UI model can match the actual state of the application interface in real time, solving the problem of poor adaptability of scripts when facing UI layout adjustments or dynamic element loading. The updated UI model improves the adaptability of automated test scripts to application function iterations and dynamic interface changes.

[0048] like Figure 2 As shown, in another preferred embodiment of the present invention, step 3 includes:

[0049] Step 300: Based on the updated UI model, identify dynamically loaded user interface elements and their corresponding element attributes, and generate supplementary test script fragments based on these elements and attributes. Specifically, this includes: First, extracting the user interface element sets from both the initial UI model and the updated UI model, establishing unique element identifier indexes for each set. By calculating the difference between the two indexes, filtering out element unique identifiers that only exist in the updated UI model index, the corresponding user interface elements are identified as new elements, and these new elements are determined to be dynamically loaded user interface elements. Then, iterating through all dynamically loaded user interface elements, the system extracts the complete element attributes for each element, i.e., layout attributes covering the element's position coordinates (top-left X-axis coordinate, top-left Y-axis coordinate, bottom-right X-axis coordinate, bottom-right Y-axis coordinate) and width and height dimensions (width = bottom-right X-axis coordinate - top-left X-axis coordinate). The test script generates supplementary test script fragments based on the extracted dynamically loaded user interface elements and their corresponding complete attributes. This includes the element's X-axis coordinate, height (the ratio of the bottom-right Y-axis coordinate to the top-left Y-axis coordinate), and hierarchy (the element's priority number in the interface rendering hierarchy). Interactive attributes cover the bound event type (click, input, swipe, etc.) and event triggering conditions (the user action or data state required to trigger the event). State attributes cover the show / hide state (show / hide indicator) and interactive state (operable / inoperable indicator). Following the syntax specifications of the basic test script fragments, including element positioning format, interaction command structure, and state verification logic, a supplementary test script fragment is generated. This fragment includes element positioning statements (based on a combination of unique identifier and position coordinates), interaction trigger statements (matching the element's bound event type), and state verification statements (verifying the show and interactive states). This ensures that the supplementary test script fragments are fully compatible with the basic test script fragments in terms of syntax and execution logic, achieving seamless integration.

[0050] Step 301: Based on the updated UI model, analyze the spatial distribution characteristics of user interface elements, construct a spatial segmentation graph structure, and establish the spatial influence area of ​​user interface elements based on the spatial segmentation graph structure. Specifically, based on the updated UI model, firstly, establish a unified coordinate system for the user interface, with the top-left corner of the user interface as the origin, the horizontal direction to the right as the positive X-axis, and the vertical direction downward as the positive Y-axis. The coordinate unit is unified as pixels. Under this coordinate system, the actual display range of each user interface element is converted into a rectangular bounding box. Its core parameters are directly extracted from the element layout attributes. The top-left corner coordinates (X1, Y1) correspond to the top-left X-axis and Y-axis coordinates of the element layout attributes, and the bottom-right corner coordinates (X2, Y2) correspond to the bottom-right X-axis and Y-axis coordinates of the element layout attributes. This provides a basis for subsequent spatial analysis. Further, based on the extracted bounding box parameters, calculate the core spatial parameters of each element. That is, the center X-coordinate is calculated by the average of the top-left and bottom-right X-axis coordinates. The formula is: Center X Coordinate The center Y-coordinate is calculated by averaging the Y-axis coordinates of the top left and bottom right corners. The formula is: Center Y-coordinate The diagonal length of a rectangular bounding box is derived using the formula for the distance between two points. The formula is: Diagonal length The square operation is based on the coordinate difference in pixels, and the square root operation is used to obtain the actual pixel length of the diagonal.

[0051] After calculating the core spatial parameters of the elements, a spatial segmentation map structure is constructed based on the overall size parameters of the user interface (interface width W, interface height H, both in pixels). Considering the average width and height of mainstream user interface elements such as buttons, text boxes, and icons, and balancing segmentation accuracy and computational efficiency, the grid cell size is set to a×a (a is a preset fixed pixel value, taken as 60 pixels). Combining the interface size and the grid cell size, the number of grid cells in the spatial segmentation map is calculated, i.e., the number of horizontal grids is the ratio of the interface width to the grid cell side length rounded up. The formula is: [Formula for horizontal grid count]. , This represents the floor operation, i.e., when... When the result is not divisible by 60, take the integer part of the quotient and add 1); the vertical grid number is the ratio of the interface height to the grid cell side length, rounded up, and the formula is: Vertical Grid Number Based on the calculated number of horizontal and vertical grids, a two-dimensional spatial segmentation diagram structure is constructed. Each grid cell is an independent node, with (i, j) as the node coordinate identifier (i is the vertical index, ranging from 1 to the vertical grid number; j is the horizontal index, ranging from 1 to the horizontal grid number). Each node not only records its own coordinate range (X range is (j-1)×60 to j×60, Y range is (i-1)×60 to i×60), but also synchronously records the unique identifier of all user interface elements falling within this coordinate range, forming an association mapping relationship between grid cells and elements.

[0052] Based on the spatial segmentation diagram structure, establish the spatial influence area for each user interface element. The influence radius is defined by the element's center coordinates (center X coordinate, center Y coordinate) and half the length of the element's diagonal (the influence radius is calculated using the formula: influence radius...). Construct a circular spatial influence region, the boundary of which is described by the standard equation of a circle.

[0053] The center coordinates affect the radius (where x and y are the coordinates of any point within the region). To clarify the spatial relationship between elements, the overlap of the spatial influence regions of any two elements is determined: first, the distance between the centers of the two circles is calculated using the distance formula between two points, where the formula is the center-to-center distance. Where x and y are the coordinates of any point within the region; to clarify the spatial relationship between elements, the overlap of the spatial influence regions of any two elements is determined. First, the distance between the centers of two circles is calculated using the distance formula between two points, where the formula is the center distance. If the calculated center distance is less than the sum of the radii of influence of the two elements, it is determined that the two regions overlap. For regions that overlap, the X and Y coordinates of the intersection point are obtained by solving the standard equations of the two circles simultaneously, eliminating variables, and then solving the quadratic equation. The coordinate range of the overlapping region is determined by using the coordinates of the intersection point as the vertex. At the same time, the unique identifiers and interrelationships of all elements involved in the overlap are recorded, and finally the spatial influence regions of all user interface elements are established.

[0054] Step 302: Based on the spatial influence area, identify the boundaries of high-density clustering areas of user interface elements, and determine the functional area division scheme based on these boundaries. This scheme divides the user interface into a navigation area, a content display area, and a user operation area. Specifically, based on the spatial influence area and spatial segmentation map structure of all user interface elements, first, identify high-density clustering areas: traverse each grid cell in the spatial segmentation map and count the total number of user interface elements recorded through association mapping within each grid cell (i.e., the number of elements actually falling within the grid coordinate range). Calculate the element density of each grid cell based on its size: the area of ​​a grid cell is the square of its side length, calculated using the formula: [Formula omitted for brevity]. ( ); Element density is the ratio of the number of elements in a grid cell to the area of ​​the grid cell, and is calculated using the formula: Element density Density units are standardized to the number of elements / To accurately select high-density grid cells, it is necessary to calculate the statistical parameters of the element density of all grid cells, where the average value μ is the arithmetic mean of the densities of all grid cells, and the calculation formula is μ. ,in This represents the total number of grid cells in the spatial partitioning graph. The element density is the k-th grid cell; the standard deviation σ reflects the dispersion of the density data, and is calculated using the formula σ. That is, the square root of the sum of the squares of the differences between the density and the average value of each grid cell, divided by the total number of grid cells. The density threshold T is set as the sum of the average value and the standard deviation, and the formula is T = μ + σ. This is used to calculate the element density. The grid cells of >T are marked as high-density grid cells.

[0055] A connected component analysis algorithm is used to merge high-density grid cells. All high-density grid cells are traversed from left to right and from top to bottom. For the currently traversed high-density grid cell (i, j), it is determined whether there are other high-density grid cells in the X-axis direction (the left and right adjacent grid cells (i, j-1) and (i, j+1) in the same row) and the Y-axis direction (the upper and lower adjacent grid cells (i-1, j) and (i+1, j) in the same column). If there are adjacent high-density grid cells with shared edges, they are classified into the same connected component. This traversal and merging process is repeated until all high-density grid cells are classified into a unique connected component. Each connected component is a high-density cluster.

[0056] When calculating the boundary parameters of each high-density cluster, the X range of all grid cells within the cluster is traversed, the minimum X value is extracted as the minimum X coordinate of the cluster, and the maximum X value is extracted as the maximum X coordinate of the cluster; similarly, the Y range of all grid cells within the cluster is traversed, the minimum Y value is extracted as the minimum Y coordinate of the cluster, and the maximum Y value is extracted as the maximum Y coordinate of the cluster. These four parameters constitute the rectangular boundary of the high-density cluster (X range: from the minimum X coordinate of the cluster to the maximum X coordinate of the cluster, Y range: from the minimum Y coordinate of the cluster to the maximum Y coordinate of the cluster).

[0057] Based on the location, size, and element functional attributes of high-density clustered areas, the functional area division scheme is determined according to the following rules: For the navigation functional area, if the Y-coordinate range of the high-density clustered area falls at the top (Y range is 0 to H / 5) or bottom (Y range is 4H / 5 to H) of the user interface, and its vertical dimension (calculated by subtracting the minimum Y-coordinate from the maximum Y-coordinate of the clustered area) is less than H / 5, and the elements contained within the clustered area are mainly jump-type or menu-type elements (determined based on element interaction attributes), then the high-density clustered area is classified as the navigation functional area; for the content display area, if the Y-coordinate range of the high-density clustered area falls in the middle area of ​​the user interface (Y range is H / 5 to H / 5), then the high-density clustered area is classified as the navigation functional area. If the high-density cluster area contains elements that are primarily text or image display elements (based on element state and layout attributes), and its horizontal dimension (calculated by subtracting the minimum X-coordinate from the maximum X-coordinate of the cluster area) is greater than 3W / 4, and the elements within the cluster area are mainly text or image display elements, then the high-density cluster area is classified as a content display area. For the user operation area, if the high-density cluster area contains mainly interactive elements such as buttons, input boxes, and selection boxes (based on element interaction attributes), and its Y-coordinate falls in the middle (Y range is H / 5 to 3H / 5) or bottom (Y range is 3H / 5 to H) of the user interface, then the high-density cluster area is classified as a user operation area.

[0058] Step 303: Based on the functional area division scheme, classify the user interface elements in the updated UI model into the navigation function area, content display area, or user operation area according to their functional characteristics. Specifically, this includes: based on the functional area division scheme determined in step 302, first extracting the rectangular boundary parameters (minimum X coordinate, maximum X coordinate, minimum Y coordinate, maximum Y coordinate) of each of the navigation function area, content display area, and user operation area to provide a basis for element classification; traversing all user interface elements in the updated UI model, extracting the center coordinates (Xc, Yc) of each element calculated in step 301, and performing functional classification through coordinate range matching. For area classification, if the element's center coordinate Xc is between the minimum and maximum X coordinates of the navigation function area, and Yc is between the minimum and maximum Y coordinates of the navigation function area, then the element is classified into the navigation function area; if the element's center coordinate Xc is between the minimum and maximum X coordinates of the content display area, and Yc is between the minimum and maximum Y coordinates of the content display area, then the element is classified into the content display area; if the element's center coordinate Xc is between the minimum and maximum X coordinates of the user operation area, and Yc is between the minimum and maximum Y coordinates of the user operation area, then the element is classified into the user operation area.

[0059] For scattered elements that do not fall within the rectangular boundaries of any high-density cluster area, supplementary classification is performed based on the element's functional attributes. That is, by analyzing the element's interaction and state attributes, if the element has navigation functions such as jumping or menu switching, it is classified into the navigation function area; if the element only has information display functions and no interactive event binding, it is classified into the content display area; if the element has user-operable interactive functions, such as binding click or input events, it is classified into the user operation area. This ensures that all user interface elements in the updated UI model are accurately classified into their corresponding functional areas without omissions or mismatches.

[0060] This embodiment ensures the adaptability of test scripts to dynamic interface scenarios by identifying dynamically loaded user interface elements and generating supplementary test script fragments; it constructs spatial segmentation maps and spatial influence areas by analyzing spatial distribution characteristics, and identifies the boundaries of high-density clustering areas by combining density calculation and connected region analysis, thereby realizing the division of functional areas; by classifying user interface elements according to their functional characteristics, it clarifies the functional affiliation and spatial association of the elements, improving the logical rationality of the test scripts and the comprehensiveness of scenario coverage.

[0061] In a preferred embodiment of the present invention, step 4 includes:

[0062] Step 400: Based on the user interface state change data, extract the layout feature data of user interface elements in each functional area. Specifically, based on the user interface element state change data generated in step 201, and combined with the functional area classification results determined in step 303, extract the layout feature data of user interface elements in each area according to three categories: navigation function area, content display area, and user operation area. The extraction dimensions cover element arrangement, element spacing, alignment, hierarchical distribution, element density, and element size consistency. The specific process proceeds as follows: First, determine the element arrangement. Analyze the X1 and Y1 coordinates of the top-left corner vertex of all user interface elements in the area. The preset spacing threshold is 10 pixels. This value is suitable for the standard spacing range of most UI designs and can effectively distinguish the element arrangement direction, avoiding judgment deviations caused by spacing that is too close or too far. If the difference in Y1 coordinates between elements is ≤10 pixels, it is determined to be a horizontal arrangement. If the difference in X1 coordinates between elements is ≤10 pixels, it is determined to be a vertical arrangement. If both horizontal and vertical coordinate distribution characteristics are met, it is determined to be a grid arrangement.

[0063] Next, the element spacing is calculated. For adjacent elements in the same direction, when arranged horizontally, the difference between X1 and X2 of the next element is taken; when arranged vertically, the difference between Y1 and Y2 of the next element is taken. The spacing values ​​of all adjacent elements in the region are counted, and the average and standard deviation of the spacing are calculated as the element spacing characteristics of the region. Then, the alignment method is determined by comparing the X1 coordinate (left alignment), X2 coordinate (right alignment), Y1 coordinate (top alignment), or Y2 coordinate (bottom alignment) of all elements in the region. The proportion of elements with the same coordinate values ​​is counted, and the alignment method with the highest proportion is the main alignment method of the region. Then, the hierarchical attribute value of each element in the region is extracted, and the number and proportion of elements corresponding to each level are counted. The proportion = number of elements in the level ÷ total number of elements in the region, forming hierarchical distribution characteristic data. Finally, the element density is calculated by reusing the grid cell density data calculated in step 302, summarizing the density values ​​of all grid cells in the corresponding functional area, and taking the average value as the element density of the functional area. The density unit is the number of elements / .

[0064] Finally, the size consistency feature is extracted. First, the average width (average width = sum of widths of all elements in the area ÷ total number of elements in the area) and average height (average height = sum of heights of all elements in the area ÷ total number of elements in the area) of all elements within the area are calculated. Then, each element in the area is iterated through, and the percentage difference between the width of each element and the average width of the area is calculated: Width difference percentage = |single element width - average width| ÷ average width × 100%, and the percentage difference between the height and the average height of the area is calculated: Height difference percentage = |single element height - average height| ÷ average height × 100%. A preset threshold of 10% is set. Each element is determined to simultaneously satisfy both the width difference percentage ≤ 10% and the height difference percentage ≤ 10%. Elements that simultaneously satisfy both conditions are marked as size-consistent elements. The total number of size-consistent elements is counted, which is the number of elements meeting the conditions. Finally, the calculated percentage is used as the size consistency feature of the area, calculated as: Size consistency feature percentage = Number of elements meeting the conditions ÷ Total number of elements in the area.

[0065] Step 401: Based on the layout feature data, determine the interaction attribute data of user interface elements in each functional area. Specifically, this includes: following the layout feature data extracted in Step 400, and combining it with the interaction event records in the user interface state change data, further determine the interaction attribute data of user interface elements in each functional area. This data includes user interface element response time data, interaction success rate data, and error handling mechanism data. The specific determination process is as follows: For response time data, for each interactive element, extract the trigger timestamp and feedback timestamp of each interaction event from the state change data (the feedback timestamp is the time point at which a clear state change occurs after element interaction). Calculate the single response time using the formula: Single Response Time = Feedback Timestamp - Trigger Timestamp. Calculate the average and maximum values ​​of all single response times for that element, using these as the element's response time data. Summarize the average response time of all interactive elements within the same functional area to form the response time dataset for that area. For interaction success rate data... Power data is collected by statistically analyzing the total number of interactions and the number of successful interactions for all interactive elements within the same functional area. Successful interaction is determined by triggering a preset feedback event after the interaction, such as a button click leading to a redirect, or input content passing validation with no corresponding error record in the state change data. The interaction success rate for each element is calculated using the formula: Interaction Success Rate = Number of Successful Interactions ÷ Total Number of Interactions × 100%. The interaction success rates of all elements are then aggregated to form the interaction success rate dataset for that area. For error handling mechanism data, the error types, error trigger frequencies, and error handling completion times (the time from error triggering to the interface returning to a normal interactive state) are extracted from the state change data during element interactions within the area. The average completion time for each type of error is calculated using the formula: Average Completion Time for Each Error = Sum of All Error Handling Times of That Type ÷ Number of Errors of That Type. This average completion time for each type of error, combined with the error type and trigger frequency, forms the error handling mechanism dataset for that area.

[0066] Step 402: Based on the interaction attribute data, generate test adaptation parameters for each functional area. Specifically, step 402a: Based on the user interface element response time data in the interaction attribute data, generate operation delay time parameters for the corresponding functional area. This includes: Based on the response time dataset determined in step 401, generating corresponding operation delay time parameters for each functional area. The specific calculation process unfolds in logical order. When calculating the average response time of an area, the average response time of all interactive elements within the functional area is summarized and divided by the number of elements. The formula is: Average response time of the area = (Sum of average response times of all elements) ÷ Number of elements. This value reflects the normal response level of most normal interactions within the area. When calculating the maximum average response time of an area, the maximum response time of all interactive elements within the functional area is summarized and divided by the number of elements. The formula is: Maximum average response time of the area = (Sum of maximum response times of all elements) ÷ Number of elements. This value covers a few special interaction scenarios with longer response times within the area.

[0067] When calculating the operation delay time parameter, the result is obtained by the formula: Operation delay time parameter = Average mean of regional response time × 1.2 + Maximum mean of regional response time × 0.3. Here, 1.2 and 0.3 are weighting coefficients set based on the adaptability of the interaction scenario: 1.2 is used to amplify the impact of the normal response level (because the average value can reflect most interaction characteristics), and 0.3 is used to take into account special time-consuming scenarios. The combination of the two makes the parameter both fit the normal needs and be compatible with extreme cases, ensuring that the response needs of most interaction scenarios are covered.

[0068] Step 402b: Based on the user interface element interaction success rate data in the interaction attribute data, generate the corresponding operation retry count parameter for the functional area. Specifically, this includes: based on the interaction success rate dataset determined in step 401, generating the corresponding operation retry count parameter for each functional area. The specific calculation process is as follows: When calculating the average interaction success rate of an area, summarize the interaction success rates of all interactive elements within the functional area and divide by the number of elements. The formula is: Average interaction success rate of an area = (Sum of the interaction success rates of all elements) ÷ Number of elements. This value reflects the overall reliability of interactive operations within the area. When calculating the operation retry count parameter, use the formula: Operation retry count parameter = The results show that the adjustment coefficient of 5 is a reasonable value based on statistics from a large number of test scenarios, which can make the number of retries and the success rate form a suitable linear relationship (the lower the success rate, the more retries). The rounding operation ensures that the number of retries is a non-negative integer, which conforms to the actual test execution logic. In special cases, if the above calculation result is 0, it means that the regional average interaction success rate is extremely high, but in order to ensure the fault tolerance of interaction failures caused by extreme cases, such as sudden network fluctuations, the operation retry parameter is set to 1.

[0069] Step 402c: Based on the user interface element error handling mechanism data in the interaction attribute data, generate operation timeout threshold parameters for the corresponding functional areas. Specifically, this includes: based on the user interface element error handling mechanism data in the interaction attribute data determined in step 401, combined with the maximum average regional response time obtained in step 402a, generating corresponding operation timeout threshold parameters for each functional area. The specific calculation process is as follows: first, calculate the sum of the average processing completion times for all error types within the functional area, then divide by the number of error types to obtain the average error processing time for the area. This value reflects the normal time consumption for error processing within the area. Then, calculate the result using the formula: operation timeout threshold parameter = average error processing time in the area × 1.5 + maximum average regional response time. The 1.5 multiplier is used to cover potential time fluctuations during error processing. Adding the maximum average regional response time can take into account the dual timeout requirements of normal interaction and error processing, ensuring that the parameters can comprehensively cover the timeout judgment of various interaction scenarios.

[0070] Step 403: Based on the test adaptation parameters and the context-dependent behavior characteristics of user interface elements, generate a conditional test script branch containing conditional judgment logic. Specifically, based on the test adaptation parameters generated in steps 402a, 402b, and 402c (i.e., operation delay time parameter, operation retry count parameter, and operation timeout threshold parameter), and combined with the context-dependent behavior characteristics of user interface elements, covering the pre-dependent conditions, post-related elements, and state switching logic of element interactions, generate a conditional test script branch containing conditional judgment logic. The specific implementation process proceeds sequentially as follows: First, extract the context-dependent behavior characteristics of user interface elements in each functional area, clarify the pre-conditions of element interaction, such as whether the pre-element has been loaded, whether the pre-interaction has been executed successfully, and specific... The system checks whether the data meets the requirements and establishes subsequent related logic, such as the related element interactions to be triggered after the current element interaction is successful, and the target state to be switched in the interface. Secondly, based on the test adaptation parameters, it designs corresponding conditional judgment logic. If the interaction response time exceeds the operation delay time parameter, a waiting mechanism is triggered (waiting time = operation delay time parameter - elapsed time, avoiding misjudgment due to normal time consumption). If the number of failed interactions reaches the operation retry count parameter, error recording and branch jump are triggered (recording the error type and context, jumping to an alternative interaction path or test termination process). If the interaction duration exceeds the operation timeout threshold parameter, a timeout termination and retry process is triggered (terminating the current invalid interaction, retrying according to the retry count parameter, and recording a timeout error if the retry fails).

[0071] Finally, the condition judgment logic is combined with the context-dependent behavior characteristics, and a fixed process of precondition judgment, interactive execution, parameter verification, and post-association triggering is used to generate condition test script branches for the corresponding functional areas. Each branch contains clear condition triggering rules, execution logic, and jump paths. Then, this branch is integrated with the basic test script fragment generated in step 102 and the supplementary test script fragment generated in step 300 to ensure that the script can adapt to the interactive characteristics and dependencies of different functional areas.

[0072] This embodiment extracts layout feature data from each functional area, achieving a correlation mapping between layout features and interactive behaviors, thus avoiding parameter deviations caused by undifferentiated analysis. Based on the layout feature data, it determines interactive attribute data, establishing a logical association between layout and interactive effects. This makes the interactive attribute data more closely match the functional characteristics of each area, providing a reliable basis for generating test adaptation parameters. Standardized calculations generate test adaptation parameters such as operation delay time, number of operation retries, and operation timeout thresholds, ensuring scenario adaptability and fault tolerance, effectively improving the stability and accuracy of the test execution process. Combining test adaptation parameters with context-dependent behavioral features to generate conditional test script branches enables test scripts to cover dynamic interaction scenarios and dependencies, improving the flexibility and targeting of test scripts and avoiding the problem of fixed scripts being unable to adapt to complex interactive logic. The overall process, through layer-by-layer data analysis and parameter generation, allows test scripts to adapt to the characteristics and interactive needs of different functional areas, improving the comprehensiveness, accuracy, and execution efficiency of the tests, providing strong support for stable testing of the user interface.

[0073] In a preferred embodiment of the present invention, step 5 includes:

[0074] Step 500: Construct a data-driven testing framework based on test adaptation parameters. This framework includes a parameterized test dataset and a test logic controller. Specifically, it involves constructing a data-driven testing framework based on the test adaptation parameters (operation delay time parameter, operation retry count parameter, operation timeout threshold parameter) generated in steps 402a, 402b, and 402c. The core of this framework consists of two parts: the parameterized test dataset and the test logic controller. The specific process is as follows: When constructing the parameterized test dataset, first, a unique identification system is defined with functional areas as the core dimension. The functional area ID adopts a standardized format of area type and sequence number, such as user operation area 01, content display area 02, and navigation function area 03, ensuring that the identifier is unique and strictly consistent with the functional area classification results determined in step 303. The element set identifier is associated with a unique ID list of all elements within that area. The unique element ID adopts a format of functional area ID, element type, and sequence number, such as user operation area 01, submit button 03, content display area 02, and list component 05, achieving strong binding between elements and functional areas. Based on this, structured data is constructed using JSON format. Each data record uniquely corresponds to a functional area and includes the following core fields: the functional area ID is used as a unique identifier field and is consistent with the functional area classification result; the operation delay time parameter is the parameter value corresponding to the area calculated in step 402a; the operation retry count parameter is the non-negative integer parameter calculated in step 402b; the operation timeout threshold parameter is the parameter value corresponding to the area calculated in step 402c; the associated element ID list stores the unique IDs of all interactive elements in the area in the form of an array, such as [user operation area 01, submit button 03, user operation area 01, input box 06]; the parameter effectiveness priority is set numerically according to user operation area (3) > content display area (2) > navigation function area (1), and the larger the value, the higher the priority of the framework call; after the data is entered, double verification is performed through the data verification tool, that is, the field integrity requirement is no missing parameters and no invalid ID, such as non-existent functional area ID or element ID; the logical consistency requirement is that all parameter values ​​are non-negative numbers and the priority value is strictly matched with the area type, such as the priority corresponding to the user operation area must be 3. After the verification is passed, the final callable parameterized test dataset is generated.

[0075] After constructing the parameterized test dataset, a modular development model was adopted to develop the test logic controller. Its core comprises three main functional modules, each with the following implementation logic: The parameter parsing module has a built-in JSON parsing engine, executing in the logical order of functional area ID matching, field extraction, parameter format conversion, and sequence binding. First, it matches the corresponding record in the parameterized dataset based on the functional area identifier at the beginning of the test sequence, extracts all test adaptation parameters, and converts them into a numerical format recognizable by the framework (e.g., converting string parameter values ​​to integers). Then, it binds each parameter name to a placeholder parameter in the test sequence. The sequence scheduling module presets basic scheduling rules such as initial sequence priority, dynamic sequence completion, and conditional sequence triggering as needed. It also embeds parameter effectiveness priority determination logic. When test sequences from multiple functional areas need to be loaded simultaneously, they are executed in descending order of parameter effectiveness priority, and the execution is recorded in real time. Record the execution status of each sequence (not executed, executing, completed) to avoid duplicate loading or execution omissions. For example, the sequence in the user operation area (priority 3) is executed before the sequence in the content display area (priority 2) to ensure that the interaction flow of the high-priority area is covered first. The condition judgment module has a built-in data comparison engine that collects actual response data in real time during the execution of each interactive operation, such as actual response time, number of interaction failures, and operation duration. The collected actual data is compared with the test adaptation parameters of the corresponding functional area in the parameterized dataset for threshold comparison, such as actual response time > operation delay time parameter, number of failures ≥ operation retry number parameter, duration > operation timeout threshold parameter. If any comparison condition is met, the associated condition test script branch is triggered, and a detailed trigger log including the trigger timestamp, parameter comparison result, trigger branch ID, and current operation context is recorded.

[0076] Step 501 involves loading basic test script fragments into the data-driven testing framework as initial test sequences, supplementary test script fragments into the data-driven testing framework as dynamic test sequences, and conditional test script branches into the data-driven testing framework as conditional test sequences. Specifically, after completing the core construction of the data-driven testing framework, different script fragments are loaded into the framework in an orderly manner according to the functional positioning of the test sequences, following a unified process of identifier binding, association verification, framework entry, and status marking. The specific process is as follows: First, the initial test sequences are loaded. The basic test script fragments generated in Step 1 are then split one by one according to the functional area ID. The splitting rule is based on the functional area to which the core operation of the script fragment belongs. The functional area IDs must be consistent with the corresponding areas. For example, if a page navigation operation belongs to the navigation functional area, it should be split into the corresponding segment of the navigation functional area; if a form submission operation belongs to the user operation area, it should be split into the corresponding segment of the user operation area. Then, a fixed-format functional area ID identifier field is added to the header of each split segment to ensure that the framework can accurately identify and match it. Then, the segments are loaded into the framework in ascending order of functional area IDs. After loading, they are automatically marked as the initial test sequence and set to the highest execution priority (executed first during scheduling). This sequence contains the basic interaction flow of each functional area, such as expanding / collapsed menus in the navigation functional area, scrolling / switching content in the content display area, and clicking basic buttons in the user operation area.

[0077] After loading the initial test sequence, the loading of the dynamic test sequence is carried out. First, the supplementary test script fragments generated in step 300 are extracted, and each fragment is labeled with the core adaptation scenario, such as repeated form submission, quick switching of drop-down menus, and abnormal data input. Then, the association between the fragments and the parameterized dataset is established through bidirectional mapping of functional area IDs. An adaptation functional area ID field is added to each fragment. For example, if a fragment adapts to the user operation area, it is labeled as user operation area 01. At the same time, a supplementary script fragment ID field is added to the record of the corresponding functional area in the parameterized dataset to clarify that each fragment only adapts to the parameter range of the corresponding functional area. Finally, the fragments are loaded into the framework and marked as dynamic test sequences, and their execution priority is set to be lower than that of the initial test sequence. Its core function is to complete the special interaction scenarios not covered by the initial sequence, such as interactions under extreme parameters, operation processes in edge scenarios, and abnormal feedback handling processes.

[0078] Finally, the conditional test sequence is loaded. First, the conditional test script branches generated in step 403 are divided into three categories according to the conditional trigger type (delay-triggered type corresponds to operation delay time parameter, retry-triggered type corresponds to operation retry count parameter, and timeout-triggered type corresponds to operation timeout threshold parameter). Then, trigger parameter type and associated parameter name fields are added to each type of branch. For example, the trigger parameter type of the delay-triggered type branch is marked with the operation delay time parameter; the associated parameter name is operationDelayTime. Then, through the one-to-one mapping relationship between parameter name and branch ID, the branch is bound to the corresponding parameter in the parameterized dataset. For example, the operation delay time parameter is bound to all delay-triggered type branch IDs, and the operation retry count parameter is bound to all retry-triggered type branch IDs. Finally, the branch is loaded into the framework and marked as a conditional test sequence, set to on-demand trigger state, and executed only when the threshold comparison logic of the condition judgment module is met.

[0079] Step 502: Integrate the initial test sequence, dynamic test sequence, and conditional test sequence through the test logic controller of the data-driven test framework to generate a complete automated test script. Specifically, after all test sequences are loaded into the framework, the test logic controller of the data-driven test framework gradually integrates the initial test sequence, dynamic test sequence, and conditional test sequence according to the progressive process of initialization, fusion, embedding, verification, and output, and finally generates a complete automated test script. The specific implementation process is as follows: First, sequence initialization is performed. The test logic controller first calls the parameterized test dataset, traverses all records in ascending order by functional area ID, and matches the corresponding initial test sequence one by one. After loading the sequence, three initialization tasks are completed: First, the execution order of each operation in the sequence is clarified, and the basic operations are sorted out before the complex operations, such as performing element loading detection first and then performing click / input operations. Second, default values ​​are assigned to the parameter placeholders in the sequence (the values ​​are taken from the test adaptation parameters of the corresponding functional area in the parameterized dataset). Third, the dependencies between operations are sorted out, such as the username input box operation needs to be executed after the input box element is loaded and the navigation function area menu is jumped. Finally, the initialized basic execution flow is generated.

[0080] After sequence initialization, the dynamic sequence fusion phase begins. The controller prioritizes dynamic test sequences for high-priority functional areas based on the parameter priority values ​​(3 > 2 > 1) in the parameterized dataset. Adaptation nodes are pre-set in the initial test sequence, and extension nodes are reserved and marked with dynamic sequence insertion points after each core interactive operation, such as button clicks, form submissions, and content switching. The controller determines the insertion position based on the dynamic sequence's adaptation scenario; for example, a repeated form submission segment is inserted into the adaptation node after the form submission operation, and a quick dropdown menu switching segment is inserted into the adaptation node after the menu expansion operation. Before insertion, the logical coherence between the dynamic sequence and the initial sequence must be verified, checking for conflicting operation sequences, consistent dependencies with the initial sequence, and no duplicate operation steps. After verification, insertion is completed, ensuring the fused sequence flow is free of redundancy and breakpoints.

[0081] After dynamic sequence fusion is completed, conditional branch embedding is performed: the controller configures a corresponding conditional branch ID list for each interactive operation in the initial sequence and dynamic sequence. The branch IDs in the list correspond one-to-one with the branches in the conditional test sequence. At the same time, a clear conditional triggering rule execution flow is set. When an interactive operation is executed, the condition judgment module first collects the actual response data in real time. Then, the controller calls the parameterized dataset to extract the corresponding test adaptation parameters of the functional area to which the operation belongs. Subsequently, the data comparison engine performs threshold judgment on the actual data and parameters. If the judgment condition is met, the corresponding branch is matched from the conditional branch ID list and embedded into the current execution flow. After embedding, the binding relationship between the branch and the operation is recorded. It supports the same operation triggering multiple different types of conditional branches. When multiple conditions are met at the same time, they are executed in the order of delay trigger > retry trigger > timeout trigger. For example, if an operation simultaneously meets the conditions of actual response time > delay parameter and failure count ≥ retry parameter, then the delay trigger type branch is executed first, and then the retry trigger type branch is executed.

[0082] After embedding conditional branches, the controller performs integration and verification from three dimensions: First, logical coherence, traversing the integrated sequence to check for reasonable operation order, no conflicting dependencies, and no logical breakpoints, such as executing operations without loading elements; second, parameter mapping accuracy, verifying that all parameter placeholders are bound to valid parameters in the parameterized dataset, and that parameter value types match, such as delay times being integers in milliseconds and retries being non-negative integers, with no mismatches or incorrect bindings; and third, branch triggering uniqueness, ensuring that only one corresponding conditional branch is triggered under the same condition, with no duplicate triggers, such as the same failure scenario for the same operation not triggering two retry branches simultaneously. After verification, the framework outputs a complete automated test script in an executable code format, such as a Python script. The script includes functional area identifiers, test adaptation parameter configurations, sequence execution logic, conditional triggering rules, and detailed comments, such as parameter descriptions for each functional area, operation dependency comments, and conditional branch triggering condition descriptions, ensuring that the script can be run directly.

[0083] This embodiment constructs a data-driven testing framework that separates test adaptation parameters from test logic, enabling centralized management and flexible adjustment of parameters. This avoids large-scale modifications to test scripts due to parameter changes and improves the maintainability of the testing framework. Different test sequences are loaded according to type, clarifying the functional positioning and applicable scenarios of each sequence, achieving layered coverage of basic scenarios, special scenarios, and conditional scenarios, and ensuring comprehensive test coverage. Multiple test sequences are automatically integrated through a test logic controller, and a correlation and triggering mechanism between sequences is established based on a parameterized dataset, reducing redundant operations and logical errors in manual integration and improving the efficiency of automated test script generation.

[0084] Embodiments of the present invention also provide a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0085] Embodiments of the present invention also provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0086] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. An automated script generation method, characterized in that, The method includes: Step 1: Extract the initial user interface elements and their corresponding element attributes to construct an initial UI model. The initial UI model includes the layout information and interaction attributes of the initial user interface elements. Generate basic test script fragments based on the initial UI model. Step 2: Execute the operation sequence in the basic test script fragment and set interaction behavior tracking points in key interactive areas of the user interface, including setting the first interaction behavior tracking point in the top navigation area, the second interaction behavior tracking point in the main content display area, and the third interaction behavior tracking point in the bottom operation area; record the user interface state change data in real time through the interaction behavior tracking points, and identify dynamically loaded user interface elements and their state changes based on the user interface state change data; update the initial UI model using the dynamically loaded user interface elements and their state changes to form the updated UI model; Step 3: Based on the updated UI model, identify dynamically loaded user interface elements and their corresponding attributes, and generate supplementary test script fragments based on these elements and attributes. Based on the updated UI model, analyze the spatial distribution characteristics of the user interface elements, construct a spatial segmentation graph structure, and establish the spatial influence areas of the user interface elements based on this graph structure. Based on these spatial influence areas, identify the boundaries of high-density clustering areas of the user interface elements, and determine the functional area division scheme. This scheme divides the user interface into a navigation function area, a content display area, and a user operation area. Based on the functional area division scheme, classify the user interface elements in the updated UI model according to their functional characteristics into the navigation function area, content display area, or user operation area. Step 4: Based on the user interface state change data, extract the layout feature data of the user interface elements in each functional area; based on the layout feature data, determine the interaction attribute data of the user interface elements in each functional area; based on the interaction attribute data, generate the test adaptation parameters corresponding to each functional area; based on the test adaptation parameters and the context-dependent behavior characteristics of the user interface elements, generate conditional test script branches containing conditional judgment logic. Step 5: Integrate the basic test script fragments, supplementary test script fragments, and conditional test script branches into the data-driven testing framework to form a complete automated test script.

2. The automated script generation method according to claim 1, characterized in that, Step 1 includes: Parse the target application's interface definition file and source code to identify and extract all initial user interface elements; Collect the element attributes of each initial user interface element, including position coordinates, size, element type, and interactive state; An initial UI model is constructed based on the initial user interface elements and their attributes. The hierarchical relationship between the initial user interface elements is established. Based on the layout information and interaction attributes of the initial user interface elements in the initial UI model, a basic test script fragment containing a complete operation sequence is generated.

3. The automated script generation method according to claim 2, characterized in that, Based on the interaction attribute data, test adaptation parameters for each functional area are generated, including: Based on the response time data of user interface elements in the interaction attribute data, generate operation delay time parameters for the corresponding functional areas; Based on the success rate data of user interface element interactions in the interaction attribute data, generate the operation retry count parameter for the corresponding functional area; Based on the error handling mechanism data of user interface elements in the interactive attribute data, the operation timeout threshold parameters of the corresponding functional areas are generated.

4. The automated script generation method according to claim 3, characterized in that, Step 5 includes: A data-driven testing framework is constructed based on test adaptation parameters. The data-driven testing framework includes a parameterized test dataset and a test logic controller. Load basic test script fragments into the data-driven testing framework as the initial test sequence, load supplementary test script fragments into the data-driven testing framework as the dynamic test sequence, and load conditional test script branches into the data-driven testing framework as the conditional test sequence. The test logic controller of the data-driven testing framework integrates the initial test sequence, dynamic test sequence, and conditional test sequence to generate a complete automated test script.

5. A computing device, characterized in that, include: One or more processors; A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method as described in any one of claims 1 to 4.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program that, when executed by a processor, implements the method as described in any one of claims 1 to 4.

Images