Method and device for verifying cross-rendering engine interface consistency based on structural attribute tree

Abstract

The application discloses a cross-rendering engine interface consistency verification method and device based on a structure attribute tree, and relates to the technical field of user interface verification.The method comprises the following steps: receiving a verification instruction, constructing a design end attribute tree according to a design end identifier, and constructing a rendering end attribute tree according to a rendering interface address; performing node matching on the two attribute trees by using a cascading matching rule to obtain a matching result; determining the tolerance range of each node according to a tolerance comparison strategy and the matching result, and configuring an ignored field according to an ignoring rule; and finally comparing the attribute values based on the tolerance range and the ignored field to obtain a consistency verification result.The application can realize the transition from pixel-level comparison to semantic attribute comparison, eliminate rendering differences and dynamic content interference, and improve the accuracy and automation efficiency of interface verification.

Description

Technical Field

[0001] This invention relates to the field of user interface verification technology, and in particular to a method and apparatus for cross-rendering engine interface consistency verification based on a structural attribute tree. Background Technology

[0002] In the development process of mobile applications and multi-platform software, ensuring the visual fidelity from design drafts to code implementation is a core aspect of guaranteeing product quality. With the accelerating pace of product iteration and the diversification of terminal device screen specifications, automated verification of the user interface (UI) has become a crucial step in continuous integration systems.

[0003] Currently, the commonly used UI verification techniques in the industry mainly rely on manual searching or pixel-level screenshot comparison. Manual searching depends on testers comparing images visually, which is difficult to cover the entire page and is inefficient. Pixel-level screenshot comparison, on the other hand, calculates the difference between the design draft and the actual device rendering pixel by pixel and is widely used in various automated testing frameworks. These existing technical solutions constitute the current infrastructure for UI quality assurance, supporting the release verification of a large number of applications.

[0004] However, in complex native application development scenarios, existing UI verification technologies face long-standing technical bottlenecks. Due to differences in the sub-pixel processing mechanisms of different rendering engines for graphic elements, layout reordering caused by multi-screen size adaptation, and real-time content changes caused by dynamic data injection from the server, traditional verification methods are prone to generating a large number of false alarms, resulting in insufficient accuracy of verification results. Therefore, existing technologies for user interface verification suffer from inaccuracy. Summary of the Invention

[0005] This invention provides a method and apparatus for cross-rendering engine interface consistency verification based on a structural attribute tree, aiming to solve the problem of insufficient accuracy in existing technical methods for user interface verification.

[0006] In a first aspect, embodiments of the present invention provide a cross-rendering engine interface consistency verification method based on a structural attribute tree, the method comprising: Receive the input verification command, and obtain the design end attribute tree corresponding to the design end configuration attribute according to the design end identifier in the verification command; Obtain the rendering terminal attribute tree corresponding to the target rendering interface based on the rendering interface address in the verification instruction; According to the preset cascading matching rules, the design end attribute tree and the rendering end attribute tree are cascaded and matched to obtain the node matching status of each node as the corresponding matching result. The tolerance range for each node is determined based on the preset tolerance comparison strategy and the matching results. Configure the ignore fields of each node in the design-side attribute tree and the rendering-side attribute tree according to the preset ignore rules; The attribute values ​​of each node in the design-side attribute tree and the rendering-side attribute tree are compared according to the tolerance range and the ignored fields to obtain the corresponding consistency verification results.

[0007] Secondly, embodiments of the present invention provide a cross-rendering engine interface consistency verification device based on a structural attribute tree, the device comprising: The design-end attribute tree acquisition unit is used to receive the input verification command and acquire the design-end attribute tree corresponding to the design-end configuration attribute according to the design-end identifier in the verification command. The rendering-side attribute tree acquisition unit is used to acquire the rendering-side attribute tree corresponding to the target rendering interface based on the rendering interface address in the verification instruction. The matching result acquisition unit is used to perform cascade matching of the design end attribute tree and the rendering end attribute tree according to the preset cascade matching rules, and obtain the node matching status of each node as the corresponding matching result. The tolerance range acquisition unit is used to determine the tolerance range corresponding to each node based on the preset tolerance comparison strategy and the matching result. An ignore field configuration unit is used to configure the ignore fields of each node in the design-side attribute tree and the rendering-side attribute tree according to preset ignore rules; The verification result acquisition unit is used to compare the attribute values ​​of each node in the design-end attribute tree and the rendering-end attribute tree according to the tolerance range and the ignored fields, and obtain the corresponding consistency verification result.

[0008] Thirdly, embodiments of the present invention also provide a cross-rendering engine interface consistency verification device based on a structural attribute tree, wherein the device includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the cross-rendering engine interface consistency verification method based on the structured attribute tree as described in the first aspect above.

[0009] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the cross-rendering engine interface consistency verification method based on a structural attribute tree as described in the first aspect above.

[0010] This invention provides a method and apparatus for cross-rendering engine interface consistency verification based on a structural attribute tree. The method includes: receiving a verification instruction; constructing a design-end attribute tree based on a design-end identifier and a rendering-end attribute tree based on the rendering interface address; performing node matching on the two attribute trees using cascading matching rules to obtain matching results; determining the tolerance range of each node based on a tolerance comparison strategy and the matching results, and configuring an ignore field according to an ignore rule; finally, comparing attribute values ​​based on the tolerance range and the ignore field to obtain a consistency verification result. This application can effectively solve the problems of traditional verification methods easily generating a large number of false alarms and insufficient stability of verification results due to differences in sub-pixel processing mechanisms of different rendering engines for graphic elements, layout reordering caused by multi-screen size adaptation, and real-time changes in content caused by dynamic data injection from the server. It significantly improves the robustness, accuracy, and automated integration efficiency of interface verification in cross-platform and multi-state scenarios. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating the cross-rendering engine interface consistency verification method based on a structural attribute tree, as provided in an embodiment of the present invention. Figure 2 A schematic diagram of the cross-rendering engine interface consistency verification device based on structural attribute tree provided in an embodiment of the present invention; Figure 3 A schematic block diagram of a computer device provided for an embodiment of the present invention. Detailed Implementation

[0013] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0015] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0016] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0017] Please see Figure 1 , Figure 1 This is a flowchart illustrating a cross-rendering engine interface consistency verification method based on a structural attribute tree, as provided in an embodiment of the present invention. This cross-rendering engine interface consistency verification method based on a structural attribute tree is applied to a terminal device. The method is executed by application software installed on the terminal device. The terminal device is used to execute the cross-rendering engine interface consistency verification method based on a structural attribute tree to achieve interface consistency verification in cross-rendering engine scenarios. The terminal device can be a smart device such as a laptop, tablet, or mobile phone, or a server such as a management server or cluster server.

[0018] This application discloses a flowchart of a cross-rendering engine interface consistency verification method based on a structured attribute tree, as shown below. Figure 1 As shown, the method includes steps S110 to S160.

[0019] S110. Receive the input verification command and obtain the design end attribute tree corresponding to the design end configuration attribute according to the design end identifier in the verification command.

[0020] The verification command, acting as the input signal to trigger the consistency verification process, encapsulates key parameters for locating design resources and the target rendered interface. The design-side identifier is an index used to uniquely identify the design draft to be verified within the design resource library; examples include the Uniform Resource Identifier (URI), filename hash, or commit number from a version control system. The design-side attribute tree is a data structure extracted from design tools (such as Figma or Sketch) that represents the hierarchical structure and static configuration attributes of interface components. This tree structure uses the root node to represent the entire page or component, child nodes to represent internal view elements, and leaf nodes to carry specific attribute values ​​such as size, color, and font. Upon receiving the verification command, the system parses the design-side identifier and connects to the corresponding design-side data source via a pre-built interface adapter (such as the Figma REST API). The system reads the design node hierarchy under this identifier and its bound design token, transforming the visual parameters in the design draft into structured data objects, thereby constructing the design-side attribute tree. The generation process of the design-side attribute tree is independent of the rendering end, and its output serves as benchmark data for subsequent comparisons. By parsing the design-side identifiers and generating the design-side attribute tree, the verification system obtained a standard reference for visual fidelity, laying a data foundation for subsequent semantic-level comparisons.

[0021] In a more specific embodiment, step S110 specifically includes the following sub-steps: obtaining structured description information corresponding to the design end configuration attributes based on the design end identifier; generating a design end attribute tree corresponding to the structured description information based on a preset attribute tree specification.

[0022] Structured descriptive information, serving as the data foundation for constructing the attribute tree on the design side, originates directly from the raw design data held by the design tool. Utilizing the design-side identifier, the complete data representation of the target design object within its native environment can be accurately located and extracted. Compared to traditional pixel screenshots that only record visual appearance, structured descriptive information preserves the semantic hierarchy and parametric attributes of the design object, providing necessary support for subsequent semantic-level verification. In the specific execution process, data acquisition is achieved by calling standardized interfaces provided by the design side. For example, based on a communication mechanism similar to the Phase Measurement Unit (PMU), a network request can be initiated using the Figma Model Context Protocol or the Figma Representation State Transmission API. The design-side identifier is sent as a request parameter to the design server, which responds and returns node tree data organized in formats such as Extensible Markup Language (EXPLAIN) or JavaScript Object Notation. This data covers raw metadata such as node types (e.g., rectangle, text, canvas), geometric transformation attributes (e.g., rotation, scaling), layout constraints, and style attributes. Given the heterogeneity of data structures in different design tools, the information obtained here is usually raw data that has not been standardized. Its core value lies in faithfully mapping the current configuration state of the design end, ensuring that the subsequent verification process is strictly synchronized with the design source, thereby overcoming the limitations of unstructured image data in terms of accuracy and editability.

[0023] The attribute tree specification defines the topology and field constraints of the design-side attribute tree, acting as a blueprint to transform heterogeneous structured descriptive information into a unified, standardized data model. This step is essentially a modeling and mapping process, aiming to parse, clean, and reconstruct the previously acquired raw data according to predefined specifications, forming a standardized design-side attribute tree that can be directly called by the comparison engine. First, the attribute tree specification is read. This specification is usually represented as a configuration file, defining key constraints such as node class inheritance relationships, required field sets, data type mapping tables, and parent-child node nesting rules. Based on the parsing logic defined in the specification, each node in the structured descriptive information is traversed. For each node, its corresponding attribute item in the specification is extracted, and field mapping operations are performed. For example, the `fills` array in Figma is mapped to a unified `backgroundColor` field, and `strokeWeight` is mapped to `borderWidth`. Simultaneously, data type conversions are performed according to specification requirements, such as converting color objects to hexadecimal color value strings or converting size values ​​to standard point units. While processing attribute mapping, the hierarchical relationships between nodes are processed concurrently. Following the parent-child connection rules specified in the specifications, the original data, which is flat or has significant structural differences, is reorganized into a standardized tree-like hierarchical structure. Redundant fields not defined or unnecessary in the specifications are removed during the generation process to ensure that the generated attribute tree structure is compact and semantically clear. The generated node attribute tree includes node types (rectangle, text, group, component instance, etc.), layout attributes (frame, padding, gap, cornerRadius), fill attributes (fills->backgroundColor, strokeColor), text attributes (fontSize, fontWeight, fontFamily, textColor, textAlignment, lineHeight), and a recursive structure of child nodes.

[0024] This specification-based generation method ensures that the final output design-side attribute tree maintains a consistent interface format regardless of whether the upstream structured description information originates from Figma, Sketch, or other design tools. This standardization process eliminates the need to modify the core comparison logic of the verification method when changing design tools, significantly improving the universality and scalability of cross-rendering engine verification at the design-side access layer.

[0025] S120. Obtain the rendering terminal attribute tree corresponding to the target rendering interface according to the rendering interface address in the verification instruction.

[0026] The rendering interface address is the path information used to locate the target rendering interface at runtime. In mobile application testing scenarios, this could be, for example, the view controller class name in iOS UIKit, the interface route string, or the page element locator in an automated testing framework. The rendering-side attribute tree is a structured set of attributes recursively extracted from the actual running application's rendered views, reflecting the current interface's true rendering state. After locating the target interface based on the rendering interface address, the system starts the attribute extraction program to traverse the interface's view hierarchy. For each node in the view hierarchy, its calculated attribute values ​​are extracted, including but not limited to position coordinates, size, background color, corner radius, font style, and transparency. These attribute values ​​reflect the final state after layout engine calculations, stylesheet cascading, and data binding. The system reorganizes the extracted attributes according to the original parent-child hierarchy, generating a rendering-side attribute tree corresponding to the design-side attribute tree structure. The extraction of the rendering-side attribute tree is executed in parallel or sequentially with the design-side, and the generated data stream is fed into the element attribute tree comparison engine. By obtaining the attribute tree from the rendering end, the verification system transforms the runtime effect of the code implementation into a comparable, machine-readable format, realizing the transformation from pixel-level comparison to structured attribute comparison.

[0027] In a more specific embodiment, step S120 specifically includes the following sub-steps: traversing each view level in the target rendering interface corresponding to the rendering interface address to extract the attribute information of each node in the view level to obtain an attribute set; generating a rendering end attribute tree corresponding to the attribute set according to the attribute tree specification.

[0028] The rendering address is parsed to locate the target UI instance in the current runtime environment. In native frameworks such as iOS UIKit, the UI is represented as a recursively nested view hierarchy, so a depth-first or breadth-first traversal strategy is used to scan the entire view tree. During the traversal, for each node, a differential extraction is performed based on the actual class name of the node to construct a set of attributes. For example, for general UIView nodes, basic geometric and appearance properties such as className, frame, backgroundColor, and layer.cornerRadius are extracted; for UILabel-specific nodes, additional text layout properties such as font.pointSize, textColor, numberOfLines, and textAlignment are extracted; for UIButton nodes, the extraction process needs to cover the state attribute matrix under the UIControl.State dimension (including .normal, .highlighted, .disabled, .selected), obtaining the title, titleColor, and image information for the corresponding state to form a multi-dimensional attribute set; for UIImageView nodes, the extraction logic mainly focuses on the existence of image resources (e.g., image != nil) rather than pixel content; for UIActivityIndicatorView, the isAnimating boolean value is extracted to reflect the loading state. Through this type-based, fine-grained extraction mechanism, heterogeneous view objects can be transformed into a structurally unified attribute set, providing a data foundation for subsequently building a standardized attribute tree.

[0029] The attribute set containing the attribute information of each node is serialized and structurally assembled according to a predefined attribute tree specification to generate the rendering-side attribute tree. The attribute tree specification defines the node organization method, attribute field naming conventions, and nesting logic of parent and child nodes. Its purpose is to ensure that the generated rendering-side attribute tree has a homogeneous semantic space with the design-side attribute tree. This generation process can, for example, map the attribute set into a tree-shaped JSON data structure, where each node corresponds to a UI element, contains extracted attribute key-value pairs, and recursively attaches child view nodes through the `children` field. Through strict specification constraints, regardless of whether the underlying rendering framework is iOS UIKit, Android View, or Web DOM, the final output rendering-side attribute tree remains consistent in topology and attribute dimensions. This standardized rendering-side attribute tree not only eliminates implementation differences between different rendering engines but also allows subsequent comparisons with the design-side attribute tree to be performed at a unified semantic level, thus effectively supporting cross-rendering engine UI consistency verification. By traversing the view hierarchy of the target rendering interface and extracting attribute sets by node type, and then generating the rendering-side attribute tree according to a unified attribute tree specification, the unstructured and fragmented view states in the native rendering engine can be transformed into a computable and comparable structured data model. This process ensures that the rendering-side attribute tree is strictly aligned with the design end in terms of node granularity, attribute definition, and hierarchical relationships, eliminating semantic gaps caused by framework differences. This provides a high-quality input foundation for subsequent cascading matching and tolerance comparison, thereby guaranteeing the accuracy and robustness of cross-rendering engine interface consistency verification.

[0030] S130. Perform cascading matching on the design end attribute tree and the rendering end attribute tree according to the preset cascading matching rules, and obtain the node matching status of each node as the corresponding matching result.

[0031] Cascading matching rules are a set of logical strategies used to determine the correspondence between nodes in two attribute trees. Because the design and rendering ends may differ in node naming, hierarchy depth, or order, a single matching dimension is often insufficient for accurate pairing. Cascading matching rules employ a multi-dimensional combination judgment approach, comprehensively considering various node characteristics to improve the robustness of the matching. Node matching status refers to the correspondence established between a specific node in the design attribute tree and a specific node in the rendering attribute tree, including states such as complete match, partial match, no match, or redundant match. The matching result is a set recording all node correspondences, serving as an index for subsequent attribute comparisons. During matching, the system applies different matching dimensions sequentially according to a preset priority order. For example, it first compares the node's directory identifier (such as component type or class name); if the types do not match, it is directly determined as a mismatch; if the types match, it further compares the node's order information in the attribute tree (such as the relative order between sibling nodes) to filter out candidate nodes with incorrect positions; finally, it uses the node's unique identifier (such as an automated test ID or a specific content feature hash) for precise locking. When the judgment results of multiple dimensions meet the preset conditions, the system confirms that the two nodes are a matching pair and marks the corresponding node matching status. For controls that support multiple states (such as UIControl.State), the cascading matching process needs to cover all its defined state branches to ensure that the attribute matrix of each state can find the corresponding matching node. Through cascading matching, the system can accurately locate the correspondence between design elements and implementation elements in complex interface structures, effectively solving the problem of node misalignment caused by screen adaptation or layout fine-tuning, and ensuring the effectiveness of subsequent comparisons.

[0032] In a more specific embodiment, step S130 specifically includes the following sub-steps: performing node matching between the design-side attribute tree and the rendering-side attribute tree based on the node's directory identifier to obtain corresponding first matching information; performing node matching between the design-side attribute tree and the rendering-side attribute tree based on the node's sorting information in the attribute tree to obtain corresponding second matching information; performing node matching between the design-side attribute tree and the rendering-side attribute tree based on the node's unique identifier to obtain corresponding third matching information; and matching the first matching information, second matching information, and third matching information according to the cascading matching rules to mark the node matching status of each node.

[0033] Directory identifiers are key features used to characterize UI component categories. In this embodiment, the directory identifier is composed of component type (className) and text content (textContent), uniquely identifying the semantic identity of a node. This step aims to achieve high-precision node anchoring through semantic features. From the acquired design-side and rendering-side attribute trees, the directory identifiers of each node are parsed, and the directory identifiers of the design-side nodes are precisely compared with the directory identifiers of the corresponding levels in the rendering-side attribute tree. If the className of the design-side node matches the className of the rendering-side node, and the textContent of nodes containing text content also matches perfectly, then the pair of nodes is determined to have a corresponding relationship in the first matching information. This directory identifier-based matching method can effectively identify UI elements with clear semantic definitions, such as buttons or labels with specific titles. By transforming abstract component types and text semantics into computable feature vectors, the matching logic no longer relies on vague visual features but is based on structured metadata, thus providing an accurate pairing basis for subsequent attribute comparisons.

[0034] The sorting information reflects the relative position of a node within its parent container, typically expressed as an index in the list of sibling nodes. This step, supplementing directory identifier matching, primarily handles generic layout nodes that lack unique text content or custom identifiers. For the remaining nodes not covered by the first matching information, the current arrangement order of each node under its parent node is extracted. In both the design and rendering attribute trees, if nodes at the same index position within the same parent node hierarchy have the same component type, the matching pair is recorded in the second matching information. For example, in a horizontally arranged list of icons, even without text labels, matching can be achieved through sorting information as long as their relative order in the list remains consistent. This mechanism leverages the engineering fact that UI layouts typically follow a specific arrangement order, compensating for the lack of semantic information through positional topology, ensuring correct pairing based on the structural position of nodes in the view hierarchy tree, even if nodes lack explicit identifiers.

[0035] Unique identifiers can refer to identity tags explicitly configured by developers for specific UI components, such as the accessibilityIdentifier (unique element identifier) ​​commonly used in iOS development. This step aims to solve the node matching stability problem caused by cross-version iterations or dynamic content loading. It traverses the design-side attribute tree and the rendering-side attribute tree, extracting nodes marked with unique identifiers. Regardless of the specific position of these nodes in the attribute tree or whether their current text content has changed, as long as their unique identifier strings are the same, a successful match is determined, and third-party matching information is generated. This unique identifier-based matching strategy provides the highest matching robustness, especially in scenarios such as interface reconstruction, component hierarchy adjustments, or multi-language switching, enabling it to anchor core business components. By introducing explicit development conventions into the matching process, the verification system can identify key nodes that are difficult to distinguish based on appearance alone, thus maintaining stable correspondences even with minor structural changes.

[0036] Cascaded matching rules are used to fuse the matching results from the three dimensions mentioned above and output the final node matching status. This step is the core decision-making step in determining the correspondence between nodes, and its purpose is to resolve potential conflicts or incomplete coverage issues that may exist with a single matching dimension. In this embodiment, the cascaded matching rules pre-set a priority strategy, for example, prioritizing pairing based on the third matching information (unique identifier) ​​with the highest accuracy, followed by the first matching information (directory identifier), and finally the second matching information (sorting information). During the fusion process, it is checked whether the same node is matched by multiple matching dimensions simultaneously, and redundant low-priority matches are eliminated according to priority; at the same time, nodes that are not matched by any dimension are marked as unmatched. Finally, each node in the attribute tree is assigned a matching status label. These status labels can include, for example, complete match (unique identifier, directory identifier, and sorting information all match), identifier match (unique identifier and directory identifier match), partial match (unique identifier or directory identifier matches), sorting match (only sorting information matches), and no match. No match includes unmatched_from_design (redundant on the design side), unmatched_from_impl (redundant on the implementation side), and type_mismatch (inconsistent types). The node matching status of each node then serves as the matching result for that node. Through this multi-level fusion and conflict resolution mechanism, a complete and logically consistent node mapping relationship can be constructed, providing a precise state basis for subsequent implementation of differentiated tolerance comparison or ignore strategies for nodes with different matching statuses. The above steps, by combining matching information from three dimensions—directory identifier, sorting information, and unique identifier—to form a multi-dimensional cascading matching framework, ultimately obtaining the corresponding matching status label. This framework utilizes the semantic features, structural topology features, and development convention features of UI components, overcoming the limitations of a single matching strategy in complex interface scenarios. By making comprehensive decisions on multi-dimensional matching results according to preset cascading matching rules, the system can accurately locate the corresponding nodes between the design draft and the rendering interface in dynamic changes and complex layouts, thereby ensuring that subsequent consistency verification is based on the correct node correspondence and effectively reducing the false alarm rate caused by incorrect node pairing.

[0037] S140. Determine the tolerance range corresponding to each node based on the preset tolerance comparison strategy and the matching results.

[0038] Tolerance comparison strategies define a set of configurations that allow for fluctuations in the numerical values ​​or representations of different attribute fields. These strategies aim to eliminate minor deviations caused by non-design intentions, such as differences in rendering engines, floating-point precision, or sub-pixel rendering. A tolerance range can be defined as the effective interval calculated for a specific attribute field of each matched node. If the rendered attribute value falls within this interval, it is considered visually consistent. When determining the tolerance range, the system first retrieves tolerance comparison strategies to obtain tolerance grading rules associated with the current node's attribute field type (e.g., color, size, spacing, font size). These rules define tolerance levels for different matching qualities or attribute sensitivities. Based on the matching level of the node in the matching results (e.g., exact match, fuzzy match, or position-based approximate match), the system selects the corresponding tolerance level from the tolerance grading rules. Subsequently, based on the selected tolerance level and the physical dimensions of the attribute field (e.g., pixels, percentages, color difference units), the system calculates specific upper and lower thresholds, thus constituting the tolerance range for that node. For example, for color attributes, if the matching level is high, the tolerance range can be set to a range where Delta-E (CIEDE2000) is less than 2.0; for size attributes, if the matching level is low, the tolerance range may be widened to ±1 pixel or ±1%. By dynamically determining the tolerance range, this method can tolerate reasonable engineering implementation errors while strictly controlling design specifications, significantly reducing the false alarm rate of the verification system.

[0039] In a more specific embodiment, step S140 specifically includes the following sub-steps: obtaining the tolerance grading rules corresponding to the attribute fields of each node in the tolerance comparison strategy; obtaining the tolerance level that matches the matching level in the matching result of the node according to the tolerance grading rules of the attribute fields of the node; determining the tolerance interval corresponding to each attribute field according to the tolerance level that matches the attribute fields of the node, and obtaining the tolerance range of the node.

[0040] Tolerance grading rules, as the core strategy for defining the upper limit of allowable differences for different types of attribute fields during comparison, do not apply a uniform fixed threshold to all fields. Instead, they are categorized and constructed based on the physical characteristics of each attribute field and common precision errors in engineering implementation (such as floating-point calculation errors and sub-pixel rendering differences between different rendering engines). The construction process involves, for example, collecting the error distribution of each attribute field from historical verification data during system initialization or strategy configuration. This data is then combined with human visual psychology models (such as the CIEDE2000 standard for color differences) and industry standards (such as layout tolerance recommendations in the iOS Human Interface Guidelines) to establish a mapping table from attribute field types to tolerance parameters. The internal storage structure of this mapping table includes, for example, the attribute field name (or category, such as color, size, or text), baseline tolerance value, unit, and tolerance level associated with the matching level. For example, for color attributes such as backgroundColor or textColor, the tolerance grading rules are configured to use Delta-E (CIEDE2000) as the metric; for size attributes such as cornerRadius and fontSize, the absolute deviation range in points is configured; and for enumerated or count attributes such as fontWeight and numberOfLines, an exact match is required. Through this hierarchical configuration, the tolerance grading rules can accurately characterize the reasonable fluctuation range of each attribute field in actual engineering scenarios, laying the foundation for subsequent refined comparisons.

[0041] The matching results include the node matching status of each node. The node matching status corresponds to different matching levels, reflecting the degree of agreement between node pairs in the design-side attribute tree and the rendering-side attribute tree. For example, based on the degree of matching from high to low, matching levels can be divided into exact match (precise match), identifier match (high fuzzy match), partial match (medium fuzzy match), sorted match (low fuzzy match), and no match. When obtaining the tolerance level, the node matching level is used as a key basic parameter, combined with the tolerance grading rules of the attribute fields determined above for joint querying. Nodes with "no match" are excluded; only nodes with matching relationships are used to determine the tolerance range.

[0042] When the matching level is exact, it indicates a high degree of correspondence between the design intent and the implemented result. In this case, the lowest tolerance level defined in the tolerance grading rules is selected. When the matching level is medium-fuzzy matching, considering the structural uncertainties that may exist during the matching process, the system automatically selects a more lenient medium tolerance level. For node pairs with high matching degree, strict verification is performed; for node pairs with low matching degree, the tolerance is appropriately relaxed to reduce false alarms caused by matching deviations, thereby improving the robustness of the overall verification system.

[0043] After determining the specific tolerance level, the corresponding numerical range is further analyzed to generate the specific tolerance range for each attribute field under that node. For numerical attributes (such as size and transparency), the tolerance range is usually represented as a floating range based on the design-end attribute value. For example, for the cornerRadius attribute, if the design-end value corresponding to the basic range is 4pt, and the tolerance level is set to the lowest tolerance level with a standard tolerance of + / -1pt, then its tolerance range is [3pt, 5pt]. For color attributes, the basic range can be represented as a color space region with a Delta-E value less than 2.0; the tolerance level is set to a medium tolerance level, which is to multiply or add a relaxation factor corresponding to the medium tolerance level to the standard tolerance corresponding to the basic range, and then determine the corresponding tolerance range; for example, if the standard tolerance is 2 and the relaxation factor corresponding to the medium tolerance level is 3, the corresponding tolerance range is a color space region with a Delta-E value less than 6.0. For Boolean or enumerated values ​​(such as isEnabled and textAlignment), their tolerance range is strictly limited to being equal. Finally, the tolerance ranges corresponding to all attribute fields under a node are aggregated to form the complete tolerance range of that node in this consistency check.

[0044] This range will serve as the direct criterion for subsequent attribute value comparison steps. When the rendered attribute value falls within this tolerance range, it is considered passed; otherwise, it is considered failed. This multi-dimensional tolerance range determination mechanism, combining matching level and attribute characteristics, effectively shields minor errors caused by non-design intent factors such as screen adaptation, rendering engine differences, and dynamic data loading, ensuring that the verification results focus on genuine visual reproduction issues. The aforementioned method of dynamically adjusting the tolerance level based on the matching level and generating differentiated tolerance intervals based on attribute field characteristics allows the verification process to adapt to scenarios with different matching confidence levels. This ensures a high detection rate for critical design defects (such as obvious color or size errors) while significantly reducing the false alarm rate caused by differences in engineering implementation details, achieving an effective balance between verification accuracy and engineering practicality.

[0045] S150. Configure the ignore fields of each node in the design-side attribute tree and the rendering-side attribute tree according to the preset ignore rules.

[0046] Ignore rules are filtering criteria used to filter out dynamic content or non-critical attributes that do not need to be considered during the verification process. Their purpose is to eliminate inevitable differences caused by server-side data changes, timestamp updates, or personalized displays. Ignored fields can refer to attribute items marked as skipped in the attribute tree. When applying ignore rules, the system uses a multi-dimensional filtering mechanism to scan nodes in both the design and rendering attribute trees. First, the system determines whether each subtree branch in the attribute tree matches a known dynamic area defined in the ignore rules. Known dynamic areas can refer to interface modules whose content changes frequently, such as advertising banners or user avatar areas. If a subtree branch is determined to belong to a known dynamic area, the system sets all fields of all nodes within that subtree branch as ignored fields and adds an ignore tag to them, thus achieving batch filtering of the entire subtree. Second, for nodes that are not filtered out entirely, the system further traverses their internal fields to determine whether each field matches a target field defined in the ignore rules. Target fields can refer to specific type attribute names, such as text (text content), imageURL (image link), timestamp (timestamp), etc. If a node's field matches the target field, the system determines that the field belongs to the ignored fields and adds an ignored label. By configuring ignored fields, the validation process focuses on structural styles and static design attributes, effectively filtering out noise caused by dynamic changes in business data and avoiding the maintenance burden of frequently updating the base file (Golden File).

[0047] In a more specific embodiment, step S150 specifically includes the following sub-steps: determining whether each subtree branch in the design-end attribute tree and the rendering-end attribute tree matches the known dynamic region set in the ignore rule; if the subtree branch matches the known dynamic region, setting all fields of all nodes contained in the subtree branch as ignore fields and adding ignore tags; determining whether the fields of each node in the design-end attribute tree and the rendering-end attribute tree match the target field set in the ignore rule; if the field matches the target field, determining that the field belongs to the ignore field and adding ignore tags.

[0048] Before performing consistency checks, to eliminate false alarms caused by dynamic data (such as user avatars and advertising banner images) sent from the server, preprocessing operations need to be performed on the attribute trees to be compared. A subtree branch refers to a local tree structure with a complete parent-child hierarchical relationship in the design-side or rendering-side attribute tree, typically corresponding to an independent functional module or container component in the interface. Known dynamic regions are a set of specific region identifiers pre-set in the ignore rules; the content within these regions is considered to be subject to change and therefore not used as a basis for consistency checks. The specific matching logic includes: parsing the node paths of each subtree branch in the design-side and rendering-side attribute trees, extracting key identifier information on the paths, such as node resource identifiers, class names, or specific layout position characteristics; comparing the aforementioned key identifier information with the pre-set known dynamic region feature library in the ignore rules; if the path identifier of a subtree branch matches the feature library of known dynamic regions, or if the subtree branch is explicitly configured with an attribute marked as dynamic (e.g., accessibilityLabel contains the keyword dynamic), then the subtree branch is determined to match a known dynamic region.

[0049] After determining that a subtree branch belongs to a known dynamic region, to avoid interference from the massive differences within that region on the verification results, a subtree branch ignoring operation is performed. The ignoring label can be a flag bit or metadata attribute attached to the attribute tree node data structure, used to instruct the subsequent comparison engine to skip processing specific data. The specific setting process includes: starting from the root node of the successfully matched subtree branch, traversing all descendant nodes under that subtree branch using a depth-first search (DFS) or breadth-first search (BFS) algorithm; for each traversed node, regardless of its type (container view, such as UIView) or leaf view, such as UIImageView or UILabel), all its internally stored attribute fields (covering background color, text content, image address, rounded corner values, etc.) are uniformly marked as ignored, and an ignoring label is written into the node's metadata. In this way, while preserving the overall structure of the dynamic region, all its specific attribute values ​​are excluded from subsequent difference calculations, effectively shielding noise introduced by data changes.

[0050] Besides the dynamic content of the entire area, some specific attribute fields may naturally differ due to device variations or network environments, requiring fine-grained management at the field level. Target fields refer to a predefined set of specific attribute names that need to be ignored, such as imageUrl, textContent, and updateTime. The specific judgment logic includes: traversing each node in the design and rendering attribute trees, extracting the field names of all attribute fields contained in that node; comparing the extracted field names one by one with the target field list maintained in the ignore rules; supporting both exact match and wildcard match modes, where exact match requires field names to be completely identical, and wildcard match allows fuzzy matching using symbols such as * (e.g., *.url can match all fields ending in url). If any attribute field name of a node finds a corresponding match in the target field list, then that field is determined to meet the ignore condition.

[0051] To address dynamic interference at the field level, precise field marking operations are performed. For fields determined to be successfully matched in the above steps, only the specific field itself is marked, without affecting other fields in its node; in the node's data structure, an ignore label is added to the attribute item corresponding to the field, or the value of the field is modified to a specific placeholder (e.g., ...). <ignored>When the comparison engine reads attribute values ​​and performs differential calculations, it skips the numerical comparison of a field if it detects that the field has an ignore label, and directly considers the field to have passed the verification. This fine-grained control mechanism ensures strict verification of static style attributes (such as layout, color, and font) while being flexible and compatible with changes in dynamic business data. As a result, it significantly reduces the test case maintenance cost caused by changes in external data without sacrificing test coverage.

[0052] S160. Based on the tolerance range and the ignored fields, compare the attribute values ​​of each node in the design-side attribute tree and the rendering-side attribute tree to obtain the corresponding consistency verification result.

[0053] The consistency verification result is the final output used to quantitatively evaluate the visual fidelity between the design and rendering ends. It typically includes a pass / fail status and a detailed list of discrepancies. Before performing the comparison, the system first cleans the fields in the design and rendering attribute trees, excluding all fields marked as ignored, thus obtaining the valid comparison fields for each node. Valid comparison fields refer to attribute items that are neither masked by the ignore rules nor fail to establish a corresponding relationship in the matching results. Subsequently, the system reads the attribute values ​​corresponding to the valid comparison fields for each node from both the design and rendering attribute trees and performs a step-by-step comparison. For numerical attributes, the system calculates the absolute or relative deviation between the rendering attribute value and the design attribute value to obtain the attribute deviation for each valid comparison field. For complex attributes such as color and font, the system calls a specific difference algorithm (such as the Delta-E formula or font measurement comparison algorithm) to calculate the difference degree. After obtaining the attribute deviation, the system determines whether the attribute deviation of each valid comparison field is within the corresponding tolerance interval. If the attribute deviation falls within the tolerance range, the field is considered consistent; if it exceeds the tolerance range, it is considered inconsistent. The system summarizes the judgment results of all valid comparison fields and generates the corresponding consistency verification result. This result not only indicates the overall consistency status but also accurately marks the location of the difference, the attribute name, and the deviation value, forming a highly readable textual report. Through refined comparison based on tolerance range and ignored fields, this method achieves semantic-level precise verification, providing developers with clear remediation guidance and improving the practicality and integration efficiency of UI automation testing.

[0054] In a more specific embodiment, step S160 specifically includes the following sub-steps: excluding fields in the design-side attribute tree and the rendering-side attribute tree that correspond to the ignored fields to obtain valid comparison fields corresponding to each node; obtaining attribute values ​​corresponding to each node and valid comparison fields from the design-side attribute tree and the rendering-side attribute tree respectively and comparing them to obtain attribute deviations corresponding to each valid comparison field; determining whether the attribute deviations of each valid comparison field are within the tolerance interval corresponding to the tolerance range, and obtaining the determination results of each valid comparison field as the corresponding consistency verification results.

[0055] Using the ignored fields generated in the previous steps as filtering conditions, the attribute trees on both the design and rendering sides are preprocessed. Ignored fields can be specific fields in the attribute tree nodes that are marked as not requiring consistency checks, such as text content fields or image address fields in dynamic content scenarios, or all field attributes under an entire subtree specified by the ignore rule. Each node in the attribute tree is traversed, checking if all its field names exist in the ignored field set. If a field is marked as ignored, it will be directly removed in subsequent comparison logic and will not participate in attribute value acquisition or deviation calculation. By excluding these ignored fields, each node retains only the key attribute fields that need to be verified, thus forming the effective comparison field set for each node. The effective comparison fields constitute the substantial data range of this verification operation, ensuring that changes in dynamic data or non-critical visual features will not interfere with the consistency judgment of core style attributes.

[0056] For each valid comparison field, the corresponding attribute value is extracted from both the design-side attribute tree and the rendering-side attribute tree. The attribute values ​​in the design-side attribute tree typically originate from the configuration data of the design tool (such as Figma) and represent the target state in the design specifications; the attribute values ​​in the rendering-side attribute tree originate from the calculated attributes of the target rendering interface during actual runtime, reflecting the true state of the code implementation. For the same valid comparison field under the same node, the attribute values ​​from the two sources are compared, and the degree of difference between them is calculated. This degree of difference is the attribute deviation. The specific calculation method for the attribute deviation depends on the data type of the valid comparison field. For numeric attributes (such as font size, corner radius, spacing, and transparency), the attribute deviation is expressed as the absolute value of the difference between the design-side and rendering-side values. For color attributes (such as background color and text color), the attribute deviation is calculated based on a color space model, for example, calculating the Euclidean distance between two colors in the CIELAB color space, i.e., the Delta-E value. For enumerated or Boolean attributes (such as text alignment and whether to crop subviews), the attribute deviation is expressed as the binary result of whether the two are completely consistent (0 indicates consistency, 1 indicates inconsistency). For string attributes such as font names, the attribute deviation can be expressed as edit distance or by directly comparing string equality. Through the above difference calculation process, a quantified attribute deviation is generated for each valid comparison field, which objectively reflects the degree of deviation between the code implementation and the design draft.

[0057] The attribute deviations of each valid comparison field are then finalized based on the tolerance ranges determined in the preceding steps. The tolerance range includes pre-defined tolerance intervals for different attribute fields, each defining the maximum allowable deviation range for that attribute. For example, for the corner radius attribute, its tolerance range might be set to [-1pt, +1pt] or an absolute deviation less than 1pt; for color difference (Delta-E), its tolerance range might be set to less than 6.0; for certain attributes that require precise matching (such as font weight or line count), their tolerance range might be set to 0, requiring complete consistency. The attribute deviation of each valid comparison field is then matched against its corresponding tolerance interval within the tolerance range for determination. If the attribute deviation falls within the tolerance range (e.g., the numerical deviation is less than a preset threshold or the color Delta-E value is less than a preset threshold), the consistency check result for the valid comparison field is determined to be pass (PASS), indicating that although there are minor differences, they are within acceptable engineering errors or rendering tolerances. If the attribute deviation exceeds the tolerance range, the consistency check result for the valid comparison field is determined to be fail (FAIL), indicating that there is a substantial visual reproduction deviation between the code implementation and the design draft. Through the above judgment process, fine-grained verification results at the field level are output, enabling developers to accurately locate which specific attribute and by what magnitude the deviation caused the inconsistency. This provides precise guidance for subsequent code repair and also provides data support for quality gate control in the continuous integration (CI) process.

[0058] To ensure reliable recording of the verification process, step S160 includes recording path switching information and closed-loop feedback descriptions.

[0059] The aforementioned technical processes collaboratively address the technical problems of low efficiency in UI visual reproduction verification, severe interference from dynamic content, and lack of state coverage in existing technologies. By constructing attribute trees for both the design and rendering ends separately, the system elevates visual comparison from the pixel level to the semantic attribute level, naturally immunizing against noise caused by screen size adaptation and rendering engine differences. Cascading matching rules, combined with multi-dimensional features, achieve precise node alignment across engines, while the introduction of tolerance comparison strategies and ignore rules effectively filters out minor deviations and dynamic data interference that are not part of the design intent, while ensuring the rigor of design specifications. The final structured attribute comparison not only outputs highly accurate consistency verification results but also directly presents the differences in textual form, facilitating direct integration into the Continuous Integration (CI) process, thereby achieving a high-frequency, automated, and maintainable closed loop for interface consistency verification.

[0060] The cross-rendering engine interface consistency verification method based on structural attribute trees provided in this invention includes: receiving verification instructions and obtaining attribute trees from the design end and the rendering end, and performing fine-grained comparison through cascading matching, tolerance determination, and ignoring configurations. This application can effectively solve the problem of low efficiency in UI visual reproduction verification, realize automated verification of interface consistency across rendering engines, and significantly improve the practicality and integration efficiency of UI automated testing.

[0061] The cross-rendering engine interface consistency verification method based on structural attribute trees provided in this invention includes: receiving a verification instruction; constructing a design-end attribute tree based on the design-end identifier and a rendering-end attribute tree based on the rendering interface address; performing node matching on the two attribute trees using cascading matching rules to obtain matching results; determining the tolerance range of each node based on the tolerance comparison strategy and the matching results, and configuring ignored fields according to the ignored rules; and finally comparing attribute values ​​based on the tolerance range and the ignored fields to obtain a consistency verification result. This application can effectively solve the problems of traditional verification methods easily generating a large number of false alarms and insufficient stability of verification results due to differences in sub-pixel processing mechanisms of different rendering engines for graphic elements, layout reordering caused by multi-screen size adaptation, and real-time changes in content caused by dynamic data injection from the server. It significantly improves the robustness, accuracy, and automated integration efficiency of interface verification in cross-platform and multi-state scenarios.

[0062] This invention also provides a cross-rendering engine interface consistency verification device based on a structural attribute tree. This device is used to execute any embodiment of the aforementioned cross-rendering engine interface consistency verification method based on a structural attribute tree. Specifically, please refer to... Figure 2 , Figure 2 This is a schematic diagram of the cross-rendering engine interface consistency verification device based on a structural attribute tree, provided in an embodiment of the present invention.

[0063] like Figure 2 As shown, the cross-rendering engine interface consistency verification device 100 based on structural attribute tree includes a design-side attribute tree acquisition unit 110, a rendering-side attribute tree acquisition unit 120, a matching result acquisition unit 130, a tolerance range acquisition unit 140, an ignored field configuration unit 150, and a verification result acquisition unit 160.

[0064] The design-end attribute tree acquisition unit 110 is used to receive the input verification command and acquire the design-end attribute tree corresponding to the design-end configuration attribute according to the design-end identifier in the verification command; the rendering-end attribute tree acquisition unit 120 is used to acquire the rendering-end attribute tree corresponding to the target rendering interface according to the rendering interface address in the verification command; the matching result acquisition unit 130 is used to perform cascade matching of the design-end attribute tree and the rendering-end attribute tree according to the preset cascade matching rules, and obtain the node matching status of each node as the corresponding matching result; the tolerance range acquisition unit 140 is used to determine the tolerance range corresponding to each node according to the preset tolerance comparison strategy and the matching result; the ignore field configuration unit 150 is used to configure the ignore fields of each node in the design-end attribute tree and the rendering-end attribute tree according to the preset ignore rules; the verification result acquisition unit 160 is used to compare the attribute values ​​of each node in the design-end attribute tree and the rendering-end attribute tree according to the tolerance range and the ignore fields, and obtain the corresponding consistency verification result.

[0065] The cross-rendering engine interface consistency verification device based on structural attribute trees provided in this embodiment of the invention applies the aforementioned cross-rendering engine interface consistency verification method based on structural attribute trees. The method includes: receiving a verification instruction; constructing a design-end attribute tree based on the design-end identifier and constructing a rendering-end attribute tree based on the rendering interface address; performing node matching on the two attribute trees using cascading matching rules to obtain matching results; determining the tolerance range of each node based on the tolerance comparison strategy and matching results, and configuring an ignore field according to the ignore rule; finally, comparing the attribute values ​​based on the tolerance range and the ignore field to obtain a consistency verification result. This application can effectively solve the problem that traditional verification methods are prone to generating a large number of false alarms and have insufficient stability of verification results due to differences in the sub-pixel processing mechanisms of different rendering engines for graphic elements, layout reordering caused by multi-screen size adaptation, and real-time changes in content caused by dynamic data injection from the server. It significantly improves the robustness, accuracy, and automated integration efficiency of interface verification in cross-platform and multi-state scenarios.

[0066] The aforementioned cross-rendering engine interface consistency verification device based on structural attribute trees can be implemented as a computer program, which can be used in, for example... Figure 3 The computer device shown runs on the computer. The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor; when the computer device executes the computer program, it implements the cross-rendering engine interface consistency verification method based on a structural attribute tree as described in the above embodiments.

[0067] Please see Figure 3 , Figure 3 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. The computer device can be used to execute a cross-rendering engine interface consistency verification method based on a structured attribute tree, thereby enabling interface consistency verification in cross-rendering engine scenarios.

[0068] See Figure 3 The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a storage medium 503 and internal memory 504.

[0069] The storage medium 503 may store the operating system 5031 and the computer program 5032. When the computer program 5032 is executed, it enables the processor 502 to perform a cross-rendering engine interface consistency verification method based on a structured attribute tree. The storage medium 503 may be a volatile storage medium or a non-volatile storage medium.

[0070] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0071] The internal memory 504 provides an environment for the execution of the computer program 5032 in the storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a cross-rendering engine interface consistency verification method based on the structure attribute tree.

[0072] This network interface 505 is used for network communication, such as providing data transmission. Those skilled in the art will understand that... Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the computer device 500 to which the present invention is applied. The specific computer device 500 may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0073] The processor 502 is used to run the computer program 5032 stored in the memory to implement the corresponding functions in the cross-rendering engine interface consistency verification method based on the structure attribute tree described above.

[0074] Those skilled in the art will understand that Figure 3 The embodiments of the computer device shown do not constitute a limitation on the specific configuration of the computer device. In other embodiments, the computer device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. For example, in some embodiments, the computer device may include only memory and a processor. In such embodiments, the structure and function of the memory and processor are different from those shown. Figure 3 The embodiments shown are consistent and will not be repeated here.

[0075] It should be understood that, in this embodiment of the invention, the processor 502 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0076] In another embodiment of the invention, a computer-readable storage medium is provided. This computer-readable storage medium may be volatile or non-volatile. The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps included in the above-described method for cross-rendering engine interface consistency verification based on a structured attribute tree.

[0077] Those skilled in the art will readily understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention.

[0078] In the embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Units with the same function may be grouped into one unit. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, or it may be an electrical, mechanical, or other form of connection.

[0079] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention, depending on actual needs.

[0080] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0081] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a computer-readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned computer-readable storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks.

[0082] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.< / ignored>

Claims

1. A method for verifying cross-rendering engine interface consistency based on a structural attribute tree, characterized in that, The method includes: Receive the input verification command, and obtain the design end attribute tree corresponding to the design end configuration attribute according to the design end identifier in the verification command; Obtain the rendering terminal attribute tree corresponding to the target rendering interface based on the rendering interface address in the verification instruction; According to the preset cascading matching rules, the design end attribute tree and the rendering end attribute tree are cascaded and matched to obtain the node matching status of each node as the corresponding matching result. The tolerance range for each node is determined based on the preset tolerance comparison strategy and the matching results. Configure the ignore fields of each node in the design-side attribute tree and the rendering-side attribute tree according to the preset ignore rules; The attribute values ​​of each node in the design-side attribute tree and the rendering-side attribute tree are compared according to the tolerance range and the ignored fields to obtain the corresponding consistency verification results.

2. The method for cross-rendering engine interface consistency verification based on structural attribute tree according to claim 1, characterized in that, The step of obtaining the design-end attribute tree corresponding to the design-end configuration attributes based on the design-end identifier in the verification instruction includes: Obtain the structured description information corresponding to the design terminal configuration attributes based on the design terminal identifier; A design-side attribute tree corresponding to the structured description information is generated based on the preset attribute tree specifications.

3. The method for cross-rendering engine interface consistency verification based on structural attribute tree according to claim 2, characterized in that, The step of obtaining the rendering attribute tree corresponding to the target rendering interface based on the rendering interface address in the verification instruction includes: Traverse each view level in the target rendering interface corresponding to the rendering interface address to extract the attribute information of each node in the view level to obtain an attribute set; Generate a rendering-side attribute tree corresponding to the attribute set based on the attribute tree specification.

4. The method for cross-rendering engine interface consistency verification based on structural attribute tree according to any one of claims 1-3, characterized in that, The step of performing a cascaded matching of the design-side attribute tree and the rendering-side attribute tree according to a preset cascaded matching rule, and obtaining the node matching status of each node as the corresponding matching result, includes: Based on the directory identifier of the node, the design-side attribute tree and the rendering-side attribute tree are matched to obtain the corresponding first matching information; Based on the node sorting information in the attribute tree, the design-side attribute tree and the rendering-side attribute tree are matched to obtain the corresponding second matching information. Based on the unique identifier of each node, the design-side attribute tree and the rendering-side attribute tree are matched to obtain the corresponding third matching information. The first matching information, the second matching information, and the third matching information are matched according to the cascading matching rules to mark the node matching status of each node.

5. The method for cross-rendering engine interface consistency verification based on structural attribute tree according to claim 4, characterized in that, The step of determining the tolerance range for each node based on the preset tolerance comparison strategy and the matching results includes: Obtain the tolerance grading rules corresponding to the attribute fields of each node in the tolerance comparison strategy; Based on the tolerance grading rules of the node's attribute fields, obtain the tolerance level that matches the matching level in the matching results of the node; The tolerance range of the node is obtained by determining the tolerance range corresponding to each attribute field based on the tolerance level that matches the attribute field of the node.

6. The method for cross-rendering engine interface consistency verification based on structural attribute tree according to claim 5, characterized in that, The step of configuring the ignore fields of each node in the design-side attribute tree and the rendering-side attribute tree according to preset ignore rules includes: Determine whether each subtree branch in the design-side attribute tree and the rendering-side attribute tree matches the known dynamic region set in the ignore rule; If the subtree branch matches the known dynamic region, set all fields of all nodes contained in the subtree branch as ignored fields and add an ignore label; Determine whether the fields of each node in the design-side attribute tree and the rendering-side attribute tree match the target fields set in the ignore rules; If the field matches the target field, then the field is determined to be an ignored field and an ignore label is added.

7. The method for cross-rendering engine interface consistency verification based on structural attribute tree according to claim 6, characterized in that, The step of comparing the attribute values ​​of each node in the design-side attribute tree and the rendering-side attribute tree according to the tolerance range to obtain the corresponding consistency verification result includes: By excluding the fields in the design-side attribute tree and the rendering-side attribute tree that correspond to the ignored fields, the valid comparison fields corresponding to each node are obtained; The effective comparison field obtains the attribute values ​​corresponding to each node and the effective comparison field from the attribute tree of the design end and the attribute tree of the rendering end respectively, and compares them to obtain the attribute deviation corresponding to each effective comparison field; Determine whether the attribute deviation of each valid comparison field is within the corresponding tolerance interval of the tolerance range, and obtain the judgment result of each valid comparison field as the corresponding consistency verification result.

8. A cross-rendering engine interface consistency verification device based on a structural attribute tree, characterized in that, The apparatus is used to perform the cross-rendering engine interface consistency verification method based on a structural attribute tree as described in any one of claims 1-7, the apparatus comprising: The design-end attribute tree acquisition unit is used to receive the input verification command and acquire the design-end attribute tree corresponding to the design-end configuration attribute according to the design-end identifier in the verification command. The rendering-side attribute tree acquisition unit is used to acquire the rendering-side attribute tree corresponding to the target rendering interface based on the rendering interface address in the verification instruction. The matching result acquisition unit is used to perform cascade matching of the design end attribute tree and the rendering end attribute tree according to the preset cascade matching rules, and obtain the node matching status of each node as the corresponding matching result. The tolerance range acquisition unit is used to determine the tolerance range corresponding to each node based on the preset tolerance comparison strategy and the matching result. An ignore field configuration unit is used to configure the ignore fields of each node in the design-side attribute tree and the rendering-side attribute tree according to preset ignore rules; The verification result acquisition unit is used to compare the attribute values ​​of each node in the design-end attribute tree and the rendering-end attribute tree according to the tolerance range and the ignored fields, and obtain the corresponding consistency verification result.

9. A computer device, characterized in that, The computer device includes a processor, a network interface, a memory, and a communication bus, wherein the processor, network interface, and memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the steps of the cross-rendering engine interface consistency verification method based on a structural attribute tree as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the cross-rendering engine interface consistency verification method based on the structural attribute tree as described in any one of claims 1-7.

Images