Interface consistency checking method and device based on heterogeneous data, equipment and medium

Abstract

The application discloses a kind of interface consistency checking methods, device and medium based on heterogeneous data, it is related to interface test and front-end engineering technical field.The method includes: obtaining the front-end document object model data of the page to be checked and user interface design draft data;Front-end document object model data and user interface design draft data are standardized structure mapping processing, to convert it into virtual node tree structure of uniform format respectively;Based on the hierarchical relationship and node attribute of virtual node tree structure, document object virtual node and design draft virtual node are matched, and the node pair that matching is successful is determined;The attribute comparison of the node pair that matching is successful is carried out, and interface consistency checking result is generated according to the difference value obtained by comparison.The whole scheme is standardized mapping and node accurate matching by heterogeneous data, realizes the quantification, automation checking of interface consistency, improves the automation level of interface acceptance, reduces artificial checking cost.

Description

Technical Field

[0001] The present application relates to the technical field of interface testing and front-end engineering, and in particular, relates to a heterogeneous data-based interface consistency verification method, apparatus, device and medium. Background

[0002] With the rapid development of computer application technology and the Internet industry, the interface presentation of various web pages and application programs has become increasingly diverse, and high-fidelity restoration of interfaces has become a core requirement for ensuring product user experience and enhancing product competitiveness. In the whole process of front-end development, software testing and product acceptance, consistency verification between the interface design scheme and the actually rendered interface is a key link, whose verification efficiency and accuracy directly affect the project development cycle, testing cost and final delivery quality. At present, interface design data and front-end actual rendering data often present heterogeneous characteristics. How to realize efficient and accurate interface consistency verification based on such heterogeneous data has become a technical problem to be urgently solved by those skilled in the art.

[0003] Currently, in the industry, for the difference comparison between an interface and a design scheme, two main methods are adopted to realize interface consistency verification. One is the interface image overlay comparison method, which inserts the interface design draft in the form of an image into the actually rendered interface, adjusts the transparency of the design draft image to display the design draft and the actual interface content in a superimposed manner, and relevant staff observe the superimposed effect with naked eyes to identify the visual difference between the two, so as to complete the consistency verification. However, this method completely relies on manual naked eye observation, which not only has low verification efficiency and strong subjectivity, but also cannot perform quantitative analysis on differences and generate standardized quantitative reports, and cannot adapt to large-scale and high-frequency interface verification scenarios. The other is the pixel-by-pixel comparison method, which first obtains the image of the interface design draft and the screenshot of the actually rendered interface respectively, then calculates the color value difference of the two images pixel by pixel, and obtains the difference result between the interface design draft and the actual interface by counting the number and distribution of pixels with mismatched color values, so as to realize the consistency verification. However, this method can only identify pixel differences at the image level. When there are situations such as element addition or deletion and layout fine-tuning in the actual interface, a large number of irrelevant differences will appear at the image level, resulting in batch false difference reports, greatly reducing verification accuracy and increasing the cost of manual troubleshooting of false reports. Meanwhile, it cannot accurately adapt to the heterogeneous characteristics of interface design data and front-end rendering data, and cannot reflect the real difference between the two.

[0004] In conclusion, the existing interface consistency verification technologies all have certain limitations in practical applications, are difficult to meet the current industry's requirements for high efficiency, accuracy and automation of interface verification, and cannot adapt to the verification requirements in heterogeneous data scenarios. Summary of the Invention

[0005] In view of this, this application provides a method, apparatus, device and medium for interface consistency verification based on heterogeneous data. The main purpose is to solve the problem that existing interface consistency verification technologies are unable to meet the current industry's requirements for efficiency, accuracy and automation of interface verification, and are also unable to adapt to the verification requirements in heterogeneous data scenarios.

[0006] The first aspect provides a method for verifying interface consistency based on heterogeneous data, which includes: Obtain the front-end document object model data and user interface design draft data of the page to be verified. The front-end document object model data is the hierarchical nesting data of the page to be verified when it is rendered in the browser, and the user interface design draft data is the multi-level nested structure data exported by the design platform. The front-end document object model data and the user interface design draft data are subjected to standardized structure mapping processing to convert them into virtual node tree structures in a unified format. Each node in the virtual node tree structure contains a unique identifier, hierarchical relationship and style attribute information. The converted front-end document object model data corresponds to the document object virtual node, and the converted user interface design draft data corresponds to the design draft virtual node. Based on the hierarchical relationship and node attributes of the virtual node tree structure, the virtual nodes of the document object are matched with the virtual nodes of the design draft to determine the successfully matched node pairs; The successfully matched node pairs are compared for attributes, and the interface consistency verification result is generated based on the differences obtained from the comparison.

[0007] Secondly, an interface consistency verification device based on heterogeneous data is provided, the device comprising: The acquisition unit is used to acquire the front-end document object model data and user interface design draft data of the page to be verified. The front-end document object model data is the hierarchical nesting data of the page to be verified when it is rendered in the browser, and the user interface design draft data is the multi-level nested structure data exported by the design platform. The processing unit is used to perform standardized structure mapping processing on the front-end document object model data and the user interface design draft data, so as to convert them into virtual node tree structures in a unified format. Each node in the virtual node tree structure contains a unique identifier, hierarchical relationship and style attribute information. The converted front-end document object model data corresponds to the document object virtual node, and the converted user interface design draft data corresponds to the design draft virtual node. The matching unit is used to match the virtual nodes of the document object with the virtual nodes of the design draft based on the hierarchical relationship and node attributes of the virtual node tree structure, and to determine the successfully matched node pairs; The generation unit is used to perform attribute comparison on the successfully matched node pairs and generate an interface consistency verification result based on the difference values ​​obtained from the comparison.

[0008] Thirdly, an interface consistency verification device based on heterogeneous data is provided, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor. When the processor executes the program, it implements the above-mentioned interface consistency verification method based on heterogeneous data.

[0009] Fourthly, a storage medium is provided on which a computer program is stored, which, when executed by a processor, implements the above-described interface consistency verification method based on heterogeneous data.

[0010] By employing the above technical solution, this application provides a method, apparatus, device, and medium for interface consistency verification based on heterogeneous data. Compared with existing methods that use interface diagram overlay comparison or pixel-by-pixel comparison to achieve interface consistency verification, this application obtains the front-end document object model data and user interface design draft data of the page to be verified. The front-end document object model data is the hierarchical nested data of the page to be verified when rendered in the browser, and the user interface design draft data is the multi-layered nested structure data exported from the design platform. The front-end document object model data and user interface design draft data are subjected to standardized structural mapping processing to convert them into virtual node tree structures in a unified format. Each node in the virtual node tree structure contains a unique identifier, hierarchical relationship, and style attribute information. The converted front-end document object model data corresponds to a document object virtual node, and the converted user interface design draft data corresponds to a design draft virtual node. Based on the hierarchical relationship and node attributes of the virtual node tree structure, the document object virtual nodes and design draft virtual nodes are matched to determine the successfully matched node pairs. The successfully matched node pairs are then compared for attributes, and the interface consistency verification result is generated based on the difference values ​​obtained from the comparison. The entire process standardizes the structure mapping between front-end document object model data and user interface design draft data, transforming these two types of heterogeneous data into a virtual node tree structure containing unique identifiers, hierarchical relationships, and style attribute information. This effectively solves the problem of direct comparison between design data and page rendering data due to structural differences. Furthermore, by combining hierarchical and attribute matching methods based on the virtual node tree, precise matching between nodes is achieved, avoiding the batch false alarms that easily occur in traditional pixel comparison. By comparing attribute differences between matched node pairs and generating quantitative verification results, not only is a quantitative assessment of interface fidelity and automatic output of comparison results realized, but the accuracy and efficiency of interface consistency verification are also improved. This allows for easy integration into automated workflows, significantly improving the automation level of interface acceptance and reducing manual verification costs.

[0011] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0012] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of an interface consistency verification method based on heterogeneous data in one embodiment of this application; Figure 2 yes Figure 1 A flowchart illustrating a specific implementation method for step 102; Figure 3 yes Figure 2 A flowchart illustrating another specific implementation of the method provided after step 201; Figure 4 yes Figure 2 A flowchart illustrating another specific implementation of the method provided after step 202; Figure 5 yes Figure 1 A flowchart illustrating another specific implementation of the method provided after step 103; Figure 6 yes Figure 1 A flowchart illustrating a specific implementation method for step 104; Figure 7 This is an interactive flowchart of an interface consistency verification system based on developer tools provided in an embodiment of this application; Figure 8 This is a schematic diagram of the interface consistency verification process provided in an embodiment of this application; Figure 9 This is a schematic diagram of the interface consistency verification process provided in another embodiment of this application; Figure 10 This is a structural diagram of an interface consistency verification device based on heterogeneous data in one embodiment of this application; Figure 11 This is a schematic diagram of the device structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0013] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.

[0014] In existing technologies, interface consistency verification mainly employs two methods: interface image overlay comparison and pixel-by-pixel comparison. The former relies on manual visual observation of the overlay effect, which suffers from low efficiency, high subjectivity, and the inability to quantify and analyze; the latter calculates pixel color differences, which is prone to generating numerous false alarms due to element additions, deletions, or layout fine-tuning, and cannot accurately adapt to the characteristics of heterogeneous data. Both methods have certain limitations in practical applications, making it difficult to meet the current industry's demands for high efficiency, accuracy, and automation in interface verification, and also unable to adapt to the verification needs in heterogeneous data scenarios.

[0015] To address this issue, this embodiment provides a method for verifying interface consistency based on heterogeneous data, such as... Figure 1 As shown, it includes the following steps: 101. Obtain the front-end document object model data and user interface design draft data of the page to be verified.

[0016] When implementing the verification process, two basic data sources need to be obtained first: the front-end document object model data of the page to be verified and the corresponding user interface design draft data. These two sets of data are the foundation for interface consistency comparison; without either set of data, a complete quantitative verification process cannot be completed. The front-end document object model data is the hierarchical nesting data of the page to be verified when rendered in the browser, representing the actual structure of the page after rendering. The user interface design draft data is the multi-level nested structure data exported from the design platform, representing the expected visual standards of the product.

[0017] For a page to be validated, the system needs to obtain the front-end Document Object Model (DOM) data corresponding to its rendering in the browser. The DOM is a programming language-independent interface that maps the entire page to a tree structure. In practice, the DOM structure of the page can be traversed using the browser's developer tools interface or an automated testing framework. For example, when testers need to validate a product details page on an e-commerce website, the system will use a script to drive the browser to open the page and capture the hierarchical relationships, tag names, CSS class names, inline styles, and text content of all HTML elements on the page. This captured data constitutes a complete snapshot of the actual front-end page, reflecting the structural form of the code actually rendered in the browser.

[0018] Then, the corresponding user interface design draft data for that page is retrieved synchronously. This data typically comes from a professional design platform. The design draft data is not simply a screenshot, but a multi-layered nested structure file containing metadata such as layer information, coordinate positions, color values, and font sizes. For example, in the e-commerce website example mentioned above, the latest product page design draft completed by the designer on the design platform will be exported as a specific structured data file. This file records in detail the type of each layer in the design draft, whether it is a text layer, a shape layer, or an image layer, the absolute or relative position of the layers, the style attributes of the layers, and the parent-child nesting relationships between the layers.

[0019] It should be noted that although the above sets of data describe the same page, they often suffer from heterogeneous data structures and asynchronous description methods. For example, the Document Object Model (DOM) data may contain numerous empty div containers for layout purposes or dynamically generated class names based on business logic, while the design draft data may contain hidden reference layers or decorative elements unrelated to business logic. After acquiring these two sets of data, the system can proceed to the subsequent standardized structure mapping process, uniformly converting these two types of data from different sources and with different structures into a virtual node tree structure that facilitates comparison, thereby solving the problem of direct comparison of heterogeneous data.

[0020] 102. Perform standardized structure mapping processing on the front-end document object model data and the user interface design draft data to convert them into virtual node tree structures in a unified format.

[0021] After successfully obtaining the front-end document object model data and user interface design draft data of the page to be verified, in order to eliminate the differences in data structure between the two and establish a unified comparison benchmark, it is necessary to perform standardized structure mapping processing on these two sets of data. This process requires converting the original data from different sources and with different formats into virtual node tree structures with unified data field definitions.

[0022] Specifically, the transformed front-end Document Object Model (DOM) data corresponds to Document Object Virtual Nodes. That is, after mapping, the DOM data is reconstructed into Document Object Virtual Nodes containing complete hierarchical and attribute information. The mapping process assigns a unique identifier to each node to distinguish them and avoid matching confusion. Simultaneously, it organizes the hierarchical relationships between nodes to form a clear hierarchical structure and extracts the corresponding style attribute information to standardize and encapsulate the node content. Taking a container node in a page as an example, after processing, it forms a complete virtual node containing its own identifier, the identifier of its parent node, the set of child nodes, and its own layout style. Multiple related nodes are combined according to rendering relationships to form a Document Object Virtual Node Tree.

[0023] The converted user interface design draft data corresponds to virtual nodes in the design draft. That is, after processing the user interface design draft data using the same standardized mapping rules, it will be converted into virtual nodes in the design draft with the same format as the front-end data. The mapping process will parse each visual element in the design draft according to a unified node definition method, assign a unique identifier to each element, clarify its hierarchical relationship, and extract its corresponding style attributes. For example, image elements, text elements, and container elements in the design draft will all be processed into virtual nodes with a unified structure, combined according to the arrangement relationship in the design to form a virtual node tree in the design draft. After this step, the virtual node tree in the design draft is completely consistent with the virtual node tree in the document object in terms of data format, and can directly proceed to the subsequent node matching stage.

[0024] 103. Based on the hierarchical relationship and node attributes of the virtual node tree structure, match the virtual nodes of the document object with the virtual nodes of the design draft to determine the successfully matched node pairs.

[0025] After constructing the two types of virtual node trees, it is necessary to match the virtual nodes of the document object with the virtual nodes of the design draft one by one, based on the hierarchical relationship and node attributes of the virtual node trees themselves. The purpose of node matching is to find corresponding elements in the two sets of virtual node trees, ensuring that subsequent comparisons are conducted between nodes that are of the same origin and avoiding erroneous comparisons between unrelated nodes. This step, with the hierarchical structure as the overall framework and node attributes as the basis for judgment, is a key step in achieving accurate verification.

[0026] The specific matching process begins with an initial screening based on the hierarchical relationship of the virtual node tree. Only nodes at the same level have a chance of matching; nodes at different levels are directly excluded from the matching process. In actual validation scenarios, nodes in the top navigation area of ​​the page will only be matched with nodes at the corresponding level of the navigation area in the design draft, and nodes in the main content area of ​​the page will only be matched with nodes at the corresponding level of the main content area in the design draft. Hierarchical constraints can significantly narrow down the matching range, improving matching efficiency and accuracy.

[0027] Based on hierarchical filtering, precise matching is performed by combining node attributes. Node attributes include node type, size information, layout features, and text style, etc. By comprehensively comparing various attributes, the correspondence between nodes can be determined. After the comparison is completed, nodes with attribute similarity reaching a set threshold are judged as successfully matched and form corresponding node pairs. For example, the title node in the page will match the title node in the design draft, and the image container node in the page will match the image carrying node in the design draft. After confirming all successfully matched node pairs, the subsequent attribute difference comparison step can be performed.

[0028] To illustrate this process more clearly, consider a specific scenario: in the virtual node tree of a webpage, there exists a text node with the content "Buy Now," displayed as a red background with white text. In the virtual node tree of the design draft, there is also a node with the content "Buy Now." When traversing these two nodes, it's first confirmed that they are both located within the button container's hierarchy, satisfying the hierarchy constraint. Next, the system compares them and finds that their text is completely identical, and their color values ​​are highly consistent, resulting in a very high similarity score. Based on this evidence, the system determines that these two nodes represent the same interface element, thus marking them as a successfully matched node pair. Nodes that exist in one but are missing in the other are categorized as newly added or missing elements, to be processed later. Through this dual-verification matching based on hierarchy and attributes, the system can efficiently and accurately find the true correspondence among massive numbers of nodes, ensuring accurate verification results.

[0029] 104. Perform attribute comparison on the successfully matched node pairs, and generate interface consistency verification results based on the differences obtained from the comparison.

[0030] To accurately quantify the specific deviations between the actual rendered interface and the design draft, after identifying the successfully matched node pairs, the attributes of the successfully matched node pairs can be compared. Based on the difference values ​​obtained from the comparison, a structured interface consistency verification result is generated, thereby converting the abstract visual differences into a readable data report.

[0031] The specific comparison process employs a multi-dimensional attribute verification mechanism. For each successfully matched node pair, the key attributes encapsulated in the virtual node tree are extracted and compared. These attributes typically cover three main categories: geometric attributes, style attributes, and content attributes. Regarding geometric attributes, the differences in the nodes' coordinate positions and width / height dimensions on the page are calculated. For style attributes, font size, color values, corner radius, and border styles are compared. For content attributes, the consistency of the text characters is verified. For example, when comparing a login button node pair, if the actual front-end button height is 40 pixels, while the height defined in the design draft is 44 pixels, the height difference will be recorded as 4 pixels. Similarly, if the actual text on the front-end has an extra space, or if there is a slight color difference, these subtle differences will be captured and their specific numerical values ​​calculated.

[0032] After completing the attribute comparison of all node pairs, the system enters the verification result generation stage. At this point, the system's built-in reporting engine performs cluster analysis and severity classification on these scattered difference values ​​according to preset rules. For node pairs with zero difference values, the system marks them as consistent; for node pairs with differences, the system marks them as warnings or critical errors based on the magnitude of the difference and the importance of the attribute. Finally, the system automatically generates a standardized interface consistency verification result that includes screenshots of the differences, highlighted locations of the differences, specific numerical comparisons, and repair suggestions. In this way, developers can directly locate pixel-level deviations without manual inspection, greatly improving the efficiency and accuracy of interface repair.

[0033] The interface consistency verification method based on heterogeneous data provided in this application, compared with existing interface consistency verification methods using interface diagram overlay comparison or pixel-by-pixel comparison, obtains the front-end document object model data and user interface design draft data of the page to be verified. The front-end document object model data is the hierarchical nested data of the page to be verified when rendered in the browser, and the user interface design draft data is the multi-layered nested structure data exported by the design platform. The front-end document object model data and user interface design draft data are subjected to standardized structural mapping processing to convert them into virtual node tree structures of a unified format. Each node in the virtual node tree structure contains a unique identifier, hierarchical relationship, and style attribute information. The converted front-end document object model data corresponds to document object virtual nodes, and the converted user interface design draft data corresponds to design draft virtual nodes. Based on the hierarchical relationship and node attributes of the virtual node tree structure, the document object virtual nodes and design draft virtual nodes are matched to determine the successfully matched node pairs. The successfully matched node pairs are then compared for attributes, and the interface consistency verification result is generated based on the difference values ​​obtained from the comparison. The entire process standardizes the structure mapping between front-end document object model data and user interface design draft data, transforming these two types of heterogeneous data into a virtual node tree structure containing unique identifiers, hierarchical relationships, and style attribute information. This effectively solves the problem of direct comparison between design data and page rendering data due to structural differences. Furthermore, by combining hierarchical and attribute matching methods based on the virtual node tree, precise matching between nodes is achieved, avoiding the batch false alarms that easily occur in traditional pixel comparison. By comparing attribute differences between matched node pairs and generating quantitative verification results, not only is a quantitative assessment of interface fidelity and automatic output of comparison results realized, but the accuracy and efficiency of interface consistency verification are also improved. This allows for easy integration into automated workflows, significantly improving the automation level of interface acceptance and reducing manual verification costs.

[0034] In interface consistency verification methods based on heterogeneous data, standardizing the structure mapping of front-end document object model data and user interface design draft data is crucial for connecting data acquisition and difference comparison. To enable accurate quantitative comparison, this embodiment proposes converting these two types of data into a unified format virtual node tree structure with the same data field definitions, i.e., constructing a standardized first virtual node tree structure and a standardized second virtual node tree structure. Specifically, Figure 2 As shown, step 102 above includes the following steps: 201. Traverse each node in the front-end document object model data, extract the feature information and layout style information of the current node, and construct a standardized first virtual node tree structure.

[0035] 202. Parse the hierarchical structure of the user interface design draft data, remove invalid nodes and extract the smallest content layer nodes, map the extracted node attributes to a preset standard format, and construct a standardized second virtual node tree structure.

[0036] It should be noted that both steps 201 and 202 are standardized processes that convert the corresponding heterogeneous data into a virtual node tree structure in a unified format. The first virtual node tree and the second virtual node tree are required to have the same data field definitions. Therefore, these two steps are parallel and have no order. In practical applications, these two steps can be executed simultaneously or sequentially.

[0037] For processing front-end Document Object Model (DOM) data, this embodiment employs a real-time acquisition and conversion mechanism based on a browser plugin. The browser plugin's architecture can be divided into three parts: an interface comparison panel, a background script, and a content script. When the user selects the element to be verified in the browser's built-in interface debugging tool panel, the panel script of the interface comparison panel obtains the style selector of the current element through an element selector function and forwards the selector to the background script. The background script then passes the message to the content script for specific processing. Upon receiving the instruction, the content script traverses each node in the front-end DOM data, extracts its feature information and layout style information, thereby constructing a standardized first virtual node tree structure.

[0038] In the process of traversing each node in the front-end document object model (DOM) data and extracting its feature information and layout style information, since the DOM data exists in a hierarchical nested form in the browser, each node contains its own key information such as identifier, style, and type. The traversal process will obtain the relevant data of each node one by one to ensure that no node that can be used for comparison is missed. Among them, the extraction of feature information revolves around the core identifier and type of the node. Specifically, when traversing each node in the DOM data, the tag name and Cascading Style Sheet (CSS) class name of the current node are read. According to the preset business keyword matching rules, the node name is determined from the CSS class name, and a globally unique identifier is generated. Based on the hierarchical relationship during the traversal process, the parent node identifier of the current element node is determined, and a node object containing the globally unique identifier, parent node identifier, node name, tag name, and a list of direct child elements is constructed. The browser rendering interface is called to obtain the box model data of the current element node, and the outer margin value, inner margin value, and border value are encapsulated and stored in the node object to form a standardized first virtual node tree structure.

[0039] In other words, during the construction of the first virtual node tree structure, the system performs in-depth attribute extraction and encapsulation for each node. First, the system reads the node's tag name and Cascading Style Sheet (CSS) class name, and determines the node name with business meaning from the class name according to preset rules, while generating a unique identifier to distinguish different nodes. To accurately describe the layout, the system extracts the current node's margin, padding, and border information, and encapsulates them into independent fields. Furthermore, the constructed virtual nodes also include fields such as parent node identifier, array of direct child nodes, text style information, and layout information. Through this processing method, the originally complex Document Object Model (DOM) elements are transformed into standardized objects containing unified fields such as parent node identifier, unique identifier, margin data, padding data, border data, tag name, and text information.

[0040] The extraction of layout style information focuses on the visual layout-related data of nodes, including margin, padding, and border information, corresponding to the margin, padding, and border data of the nodes, respectively. It also extracts the layout information and text style information of the nodes. In practical applications, taking the validation of a company's official website homepage as an example, when traversing the front-end document object model data of the page, information for each node, such as the homepage navigation bar, carousel container, and news list container, is extracted one by one. A unique identifier is assigned to the navigation bar node, and the Cascading Style Sheet (CSS) class name with business meaning is used as the node name. Its margin, padding, border, and other layout style information are extracted, and its tag name and text style information are recorded. After integrating this information, it is assembled according to the hierarchical relationship of the nodes to form a standardized first virtual node tree structure, which corresponds to the converted document object virtual node tree.

[0041] Simultaneously, the system performs parallel standardization processing on the user interface design draft data. Since the design draft data often contains numerous layers used for design assistance but with no actual impact on front-end rendering, the system first parses the hierarchical structure of the design draft data and, based on preset invalid node rules, removes invalid nodes such as overlays, status bars, or tiny nodes that are too small. After cleaning, the system extracts the smallest content layer nodes, such as shapes, text, and images, from the remaining layers. Subsequently, the system maps the attribute information of these design draft nodes to a standard format completely consistent with the aforementioned first virtual node tree structure, thereby constructing a standardized second virtual node tree structure. Specifically, the system parses the hierarchical structure of the user interface design draft data to identify the root node and child nodes in the hierarchical structure; it traverses all nodes and, according to preset invalid node rules, removes overlay nodes, status bar nodes, and tiny nodes smaller than a preset threshold; it extracts the shape nodes, text nodes, and image nodes from the remaining layers after removal as the smallest content layer nodes, and maps the attribute information of the smallest content layer nodes to a format consistent with the node object structure, forming a standardized second virtual node tree structure.

[0042] Understandably, the extraction of the smallest content layer nodes is to ensure a refined comparison. The smallest content layer nodes are the basic visual element nodes in the design draft that cannot be further divided, such as single text nodes, single image nodes, and single shape nodes. These nodes are the core units for visually reproducing the interface. After extraction, the attributes of these nodes are mapped according to a preset standard format to ensure consistency with the attribute definitions of the first virtual node tree structure. This includes data fields such as node name, unique identifier, label name, margin information, padding information, and border information, all of which correspond and are consistent with the first virtual node tree structure.

[0043] For example, after exporting the design draft data of the official website homepage from the Blue Lake platform, its multi-layered nested hierarchical structure is first parsed, and overlays and small-sized auxiliary nodes are removed. The smallest content layer nodes, such as text nodes in the navigation bar, image nodes in the carousel, and container nodes in the news list, are extracted. The attributes of these nodes are mapped to the same standard format as the first virtual node tree, and then assembled according to the hierarchical relationship of the design draft to form a standardized second virtual node tree structure, which corresponds to the virtual node tree of the converted design draft.

[0044] The first and second virtual node tree structures share the same data field definitions, a crucial prerequisite for subsequent node matching. Whether derived from the front-end document object model data or the user interface design draft data, the fields of each node are completely identical, including node name, unique identifier, tag name, margin information, padding information, border information, layout information, and text style information. This ensures that nodes in both types of node trees can be compared one-to-one. For example, each node in the first virtual node tree contains fields such as unique identifier, margin information, and text style information, while each node in the second virtual node tree also contains fields with the same names and definitions. When performing node matching, comparisons can be made based on the attribute values ​​of the same fields, quickly finding corresponding node pairs. This lays the foundation for subsequent attribute difference quantification comparisons and completely solves the problem of heterogeneous data being unable to be directly compared.

[0045] After constructing the first virtual node tree structure, further optimization of the text-related nodes within the tree is required. The way text is displayed on the front-end page and the design platform has inherent structural differences. Direct comparison will result in size deviations that are not visually realistic, thus affecting the accuracy of the verification results. On the front-end page, text content is usually wrapped inside container nodes, which have their own independent box model dimensions. On the design platform, text exists as independent nodes, with their size naturally determined by the text content. This structural difference leads to significant size discrepancies for the same text in the two types of virtual nodes. Therefore, it is necessary to minimize the text node boundaries of the first virtual node tree structure to ensure consistency between the front-end node size and the design platform text node size definitions. Furthermore, after step 201, as... Figure 3 As shown, the above method also includes the following steps: 301. Traverse the first virtual node tree structure and identify node pairs whose parent nodes contain only a single text child node.

[0046] 302. If the parent node does not have background color, border, or shadow style attributes, calculate the actual rendering size of the single text child node, and correct the box model data of the parent node to the actual rendering size to eliminate the size difference between the document object model container and the text node defined in the user interface design.

[0047] Specifically, during the traversal of the first virtual node tree structure and the identification of node pairs where the parent node contains only a single text child node, the composition of each node's child nodes is determined one by one. When a node has only one text child node and no other child nodes, that node and its corresponding text child node are marked as a node pair to be processed. Taking a prompt text node on the page as an example, if the text is wrapped by an outer container node and the container node contains only one text child node, it can be identified as the target node pair. This filtering method can accurately locate text-related nodes with size differences due to container wrapping, avoiding misprocessing of complex combined nodes.

[0048] The selected node pairs are further evaluated for style attributes. If the parent node lacks style attributes such as background color, border, or shadow, it indicates that the parent node only serves to carry text and does not have independent visual display significance. In this case, the actual rendering size of the single text child node is calculated, and the original box model data of the parent node is corrected to match the actual rendering size of the text child node. After correction, the width and height data of the parent node perfectly match the text content, eliminating any extra space occupied. This processing method effectively eliminates the size differences caused by the front-end document object model container and the text node definitions in the user interface design draft, ensuring that subsequent comparison results only reflect true visual deviations and avoiding invalid differences interfering with the verification conclusions.

[0049] After completing the construction of the second virtual node tree structure, the layer structure on the design draft side needs to be streamlined and optimized. Design draft data often contains multi-level nested grouping structures, with some grouping nodes only serving a hierarchical classification function and lacking actual visual attributes. These nodes make the virtual node tree structure overly complex and incompatible with the flattened node structure of the front-end page, easily leading to node mismatches and misjudgments. Therefore, layer parsing and hierarchical optimization of the second virtual node tree structure are necessary to ensure alignment between the node structure on the design draft side and the front-end side, improving node matching success rate and verification accuracy. Furthermore, after step 202, as... Figure 4 As shown, the above method also includes the following steps: 401. Parse the layer grouping hierarchy nodes in the second virtual node tree structure, and extract the nested shape nodes, text nodes, and bitmap nodes within the layer group.

[0050] 402. If the layer group node is only used as a container and has no independent visual attributes, then the layer group node is removed, the extracted shape node, text node and bitmap node are promoted to the parent of the layer group node, and the layout information of the shape node is mapped to the standard format corresponding to the block-level elements in the document object model.

[0051] Specifically, during the analysis of the layer grouping hierarchy nodes in the second virtual node tree structure, and the extraction of nested shape nodes, text nodes, and bitmap nodes within the layer groups, the exported design data forms a multi-level grouping structure. Each group can contain various basic visual elements. During the analysis, the grouping nodes are traversed layer by layer, extracting each of the contained shape nodes, text nodes, and bitmap nodes. Shape nodes correspond to block-level containers in the front-end page, bitmap nodes correspond to image elements, and text nodes correspond to text content. After extraction, the attributes and arrangement relationships of each basic element can be clearly defined.

[0052] Further validity checks are performed on layer group nodes. If a layer group node is only used as a container and has no independent visual attributes, it is removed. The extracted shape nodes, text nodes, and bitmap nodes are directly elevated to the parent level of the original layer group node, simplifying the overall node tree structure. Simultaneously, the layout information of shape nodes is mapped to the standard format corresponding to block-level elements in the Document Object Model, ensuring that the margins, paddings, and dimensions of shape nodes are consistent with the definitions of front-end virtual nodes. Taking the button area on the page as an example, in the design draft, the button consists of an outer group node enclosing an inner shape and text node. After removing meaningless group nodes and elevating the child node hierarchy, the structure becomes more consistent with the node composition of the button on the front-end page, significantly improving the accuracy of subsequent node matching and attribute comparison.

[0053] After processing the document object model data and design draft data into a standardized virtual node tree structure and completing hierarchical optimization, this embodiment introduces a node type-based differential matching strategy to achieve high-precision element comparison. Since different types of nodes have drastically different attribute characteristics and functional positioning in actual user interface construction, this embodiment designs dedicated matching processes for shape nodes and text nodes respectively to ensure accurate node alignment even in complex scenarios.

[0054] For shape nodes in the virtual nodes of the design draft, this embodiment executes a structural matching process. Shape nodes typically correspond to layout containers or visual decorative elements in the user interface, characterized by their appearance rather than their specific content. Therefore, this process first traverses all candidate nodes at the same layer grouping level in the virtual node tree structure of the design draft based on visual attributes such as the shape node's size, border style, corner radius, and background color. During the traversal, the document object virtual nodes and each design node are comprehensively calculated based on key geometric data such as width, height, and corner radius, and weighted evaluation is performed in conjunction with the similarity of the border and background color. Through this multi-dimensional weighted calculation, the degree of visual structural similarity between two nodes can be quantified, and the shape node with the highest matching degree is marked as a successfully matched node pair. For example, in a card-style layout, even if there are slight differences in the internal nesting level between the div element in the front-end code and the shape element in the design draft, as long as their width-to-height ratio, corner radius, and background color value are consistent, the system can accurately identify and mark this pair of nodes through the structural matching process.

[0055] Specifically, for shape nodes in the virtual nodes of the design draft, a structural matching process is executed: based on the shape node's size, border style, corner radius, and background color attributes, each shape node in the same layer grouping level of the virtual node tree structure of the design draft is traversed, and the comprehensive data weighted matching degree between the virtual node of the document object and each shape node in terms of width, height, and corner radius is calculated. The shape node with the highest matching degree is marked as a successfully matched node pair.

[0056] During the matching calculation, a comprehensive weighted matching degree is calculated for the width, height, and corner radius of the document object virtual nodes and each shape node. Different weights are assigned based on the degree of influence of each attribute on the visual presentation of the interface. For example, size and corner radius have a greater impact on the visual consistency of shape nodes and are assigned higher weights, while border style and background color are assigned relatively lower weights. The matching degree between each shape node and the document object virtual node is obtained through weighted calculation, and finally, the shape node with the highest matching degree and the document object virtual node are marked as a successfully matched node pair. Taking the button container in the page as an example, the shape node corresponding to the button in the design draft has a specific width, height, corner radius, and background color. The corresponding document object virtual node in the front-end page also has corresponding structural attributes. By traversing the shape nodes under the same layer group, the comprehensive weighted matching degree of the two is calculated, and the shape node with the highest matching degree is matched with the document object virtual node to ensure that the structural comparison of the button container corresponds accurately.

[0057] For fixed text nodes within the virtual nodes of the design draft, this embodiment executes a content matching process. The core value of a text node lies in its information content and visual presentation style, rather than its simple geometric shape. Therefore, this process first extracts key information such as the text content, color, font type, font size, and dimensions of the fixed text node. Then, it calculates the weighted difference values ​​between the virtual node of the document object and the fixed text node in the design draft in terms of text content and style attributes. This weighted difference calculation prioritizes complete consistency of text content while also considering the visual fidelity of font, color, and size. After comparing all candidate nodes, the fixed text node with the smallest difference value is marked as the successfully matched node pair. For example, in an interface containing a title and explanatory text, even if the positions of two text nodes are swapped or the label type used by the front end is slightly different from the design draft, as long as their text strings are exactly the same and their font styles are consistent, the content matching process can ensure that these two nodes are correctly associated, thereby effectively avoiding misjudgment of text content caused by minor structural adjustments.

[0058] Specifically, for fixed text nodes in the virtual nodes of the design draft, a content matching process is performed: extract the text content, color, font type, font size and size attributes of the fixed text node, calculate the weighted difference value between the virtual node of the document object and the fixed text node in terms of text content and style, and mark the fixed text node with the smallest difference value as a successfully matched node pair.

[0059] During the matching calculation, a weighted difference value is calculated between the virtual node of the document object and the fixed text node in terms of text content and style. Weights are assigned according to the importance of each attribute, with the accuracy of the text content being the most critical and receiving the highest weight, followed by font type, font size, and color, while size is assigned a relatively lower weight. The difference value is obtained through weighted calculation; the smaller the difference value, the closer the text content and style are. Finally, the fixed text node with the smallest difference value is marked as a successfully matched node pair with the corresponding virtual node of the document object. Taking the title text on the page as an example, the fixed text node corresponding to the title in the design draft has specific text content, font, font size, color, and size. The corresponding virtual node of the document object on the front-end page also contains corresponding text attributes. By calculating the weighted difference value, the fixed text node with the smallest difference value is matched with the virtual node of the document object, ensuring accurate matching of the title text's content and style.

[0060] After constructing and initially matching the virtual node tree structure, this embodiment introduces a dynamic verification and position correction mechanism for structure-matching nodes to address node misalignment issues caused by layout calculation differences, dynamic scrolling, or nested hierarchy during front-end rendering. This step is added after successful virtual node matching because simple attribute similarity matching cannot completely eliminate systematic biases caused by different page layout contexts. Especially in complex responsive pages, the actual position of front-end DOM nodes is often affected by parent container scrolling, CSS transformations, or flexible layouts. Without targeted correction, this will directly lead to misjudgments in the comparison results. Furthermore, as... Figure 5 As shown, after step 103, the above method further includes the following steps: 501. Perform structural consistency verification and re-matching for structural matching nodes: calculate the position deviation value of the node; if the position deviation value exceeds the preset structural consistency threshold, it is determined that the currently successfully matched node pair has structural inconsistencies, the current matching mark is cleared, and the process of matching the virtual node of the document object with the virtual node of the design draft is re-executed based on the node name matching rule or the automatic matching rule based on the size.

[0061] 502. For structural matching node pairs that have passed structural consistency verification or re-matching, obtain the scroll offset distance of the page container in the document object model, and correct the absolute position data of the virtual node of the document object based on the scroll offset distance.

[0062] 503. Based on the corrected absolute position data and the boundary rectangle data of the virtual nodes in the design draft, calculate the final position deviation value by comparison.

[0063] For structural matching nodes, this embodiment first performs a structural consistency verification and re-matching process. After initially identifying successfully matched node pairs, the system immediately calculates the positional deviation value of the node pair, i.e., the displacement difference between the virtual node of the front-end document object and the virtual node of the design draft in the absolute coordinate system. If this positional deviation value exceeds a preset structural consistency threshold, the system will determine that the current matching result has a structural risk, which may be due to mismatch caused by node name conflicts, size similarity misleading, or hierarchical misunderstanding. At this time, the system will automatically clear the current matching mark and trigger a secondary matching mechanism. At this time, the system will no longer rely on the initial weighted matching algorithm, but instead adopts a matching rule based on node name or an automatic matching rule based on size to search for the best matching object in the virtual node tree again. For example, when the front-end implementation code of a button is refactored, causing its class name to change but its size to be similar to another decorative icon in the design draft, the initial matching may produce a mismatch. Through this verification and re-matching mechanism, the system can identify excessive positional deviations and then use the semantic association of names or strict consistency of sizes to correct the matching relationship, thereby improving the robustness of the matching.

[0064] After passing structural consistency checks or completing rematching, for confirmed structurally matching node pairs, the system further obtains the scroll offset distance of the page container in the Document Object Model (DOM). In the front-end page, if the content area scrolls, the geometric position properties of DOM nodes typically only reflect their original coordinates in the document flow, without including the visual displacement caused by scrolling. To ensure that the front-end data and design draft data are in the same coordinate system, the system must correct the absolute position data of the DOM virtual nodes based on the obtained scroll offset distance. Specifically, the system adds the scroll distance to the node's coordinate values ​​to restore the node's true visual position in the current viewport. For example, in a long list, after the user scrolls down 200 pixels, a card element originally located at (50, 300) visually moves to (50, 100). Through this correction, the system ensures that subsequent comparisons are based on the actual visual presentation position.

[0065] After correcting the position data, a final comparison calculation is performed based on the corrected absolute position data and the boundary rectangle data of the virtual nodes in the design draft. The boundary rectangle data includes the width and height of the node and its overall positioning information on the page, and is a key basis for measuring structural consistency. By comparing the corrected position information with the boundary rectangle information of the nodes in the design draft item by item, the final accurate position deviation value is calculated. This deviation value eliminates the influence of scrolling interference and mismatch, and can truly reflect the differences in structural layout between the front-end page and the design draft, providing accurate data support for generating quantitative and reliable interface consistency verification results.

[0066] After completing the precise matching and position correction of virtual nodes, this embodiment introduces a differential comparison and marking mechanism to quantify the specific differences between the front-end implementation and the design draft and generate a guiding verification report. Specifically, such as... Figure 6 As shown, step 104 includes the following steps: 601. For content-matching node pairs, directly compare the text style information attributes of the virtual node in the document object and the virtual node in the design draft, and calculate the difference value of the text content and style.

[0067] 602. Compare the final position deviation value, the difference value of the text content and style with the preset tolerance threshold respectively, mark the nodes that exceed the tolerance threshold as difference items, and generate the interface consistency verification result based on the difference items.

[0068] For content-matching node pairs, this embodiment performs text style consistency comparison. The system directly compares the text style information attributes of the document object's virtual nodes with those of the design draft's virtual nodes. These attributes cover font type, font size, font weight, line height, color value, and the text content itself. The system calculates the comprehensive difference value between the two across these dimensions. This difference value includes not only a Boolean "equality" judgment but also a numerical "degree of deviation" quantification. For example, for a product price tag, if the font color implemented on the front end differs from the design draft, or if the font size differs by 1 pixel, the system will convert these subtle differences into specific numerical differences. This refined calculation method can accurately capture any distortion in text presentation, ensuring the visual fidelity of the interface copy.

[0069] After obtaining the final positional deviation values ​​of structure-matching nodes and the text style difference values ​​of content-matching nodes, the system compares these values ​​with preset tolerance thresholds. These tolerance thresholds are reasonable ranges set based on the sensitivity of human visual perception and the technical limitations in actual development. If the positional deviation value of a node exceeds the preset structure tolerance threshold, or the text style difference value exceeds the preset style tolerance threshold, the system will determine that the node as unqualified and automatically mark it as a difference. For example, if a button's position is offset by 5 pixels, exceeding the set 2-pixel tolerance, or if the font thickness of a piece of descriptive text is inconsistent, the system will immediately detect this anomaly and label it "Position Out of Tolerance" or "Style Inconsistent" in the virtual node tree.

[0070] Finally, based on all the marked discrepancies, a structured interface consistency verification result is automatically generated. This result not only summarizes the number and type of discrepancies but also details the specific deviation data, screenshot location, and corresponding node path for each item. This generation mechanism, based on numerical differences and tolerance judgment, transforms abstract visual differences into concrete, quantifiable digital evidence, significantly reducing the cost of manual review and providing precise remediation guidance for front-end developers.

[0071] Furthermore, as a specific implementation of the above method, this application embodiment also provides an interaction flowchart of an interface consistency verification system based on developer tools, such as... Figure 7 As shown, this interaction flowchart is a sequence diagram used to illustrate in detail the complete workflow of an interface consistency verification system from initialization to the generation of the final result. Figure 7 The process involves multiple participants, from left to right: the user, the developer tools comparison panel, the backend script, the content script, the page to be compared, and the user interface platform. The initial stage is system initialization. The user first opens the browser's built-in developer tools. This action triggers the launch of the developer tools comparison panel. The panel then sends a connection request to the backend script. After the connection is established and registration is successful, the backend script injects the content script into the current webpage environment, preparing for subsequent data collection. In the data collection stage, the user selects a UI element to be verified by clicking on the page to be compared. This click event is captured by the developer tools comparison panel, which temporarily stores the element's document object model (DOM) reference using a special variable. Next, the panel generates a Cascading Style Sheets (CSS) selector based on this reference and forwards it to the content script via the backend script. Within the context of the page to be compared, the content script uses the received selector to precisely locate the element and obtain its complete DOM node information. Simultaneously, the content script also sends a request to the user interface platform to obtain the design draft data corresponding to the element. The subsequent stage is data processing and comparison. After obtaining the Document Object Model (DOM) data from the front end and the design draft data from the back end, the content script internally performs three key processes in sequence: First, user interface data processing, cleaning and standardizing the design draft data; second, DOM data processing, extracting the layout and style information of elements; and finally, data comparison, precisely comparing the two types of data and calculating the differences. The final stage of the process is result display. The content script returns the generated result data after comparison to the backend script, which then forwards it to the comparison panel in the developer tools. Finally, the comparison panel presents the verification results to the user in a visual format, clearly showing the differences between the front-end implementation and the design draft, thus completing the entire interaction process.

[0072] Furthermore, as a specific implementation of the above method, this application embodiment also provides a flowchart of interface consistency verification, such as... Figure 8 As shown in the diagram, this illustrates the technical process for comparing user interface differences between the design platform system and the browser page. Its core is the interface comparison plugin. This process acquires user interface data and document object model data from both the design platform system and the browser page, respectively. Then, within the plugin, data processing, node matching, and data comparison are performed sequentially, ultimately generating a visual comparison result to verify the consistency between the design draft and the online page.

[0073] Furthermore, as a specific implementation of the above method, this application embodiment also provides another flowchart for interface consistency verification, such as... Figure 9 As shown in the diagram, this illustrates the detailed processing flow for comparing user interface data with document object model (DOM) data. Its core lies in generating the final comparison result through data preprocessing and hierarchical matching. The process begins with acquiring user interface and DOM data, followed by noise node filtering and text node boundary minimization to clean and standardize the raw data. Next, the preprocessed data undergoes data consistency processing, and the data is divided into different logical regions using a layer group data partitioning module. Based on this, the process is divided into two parallel paths: one path focuses on structural node matching, followed by positional and layout information comparison; the other path focuses on fixed text node matching, followed by positional and text information comparison. Finally, the comparison results from both paths are aggregated to generate the final comparison result, comprehensively evaluating the consistency between the user interface and the DOM in terms of structure, layout, position, and text content.

[0074] Furthermore, as a specific implementation of the above method, embodiments of this application provide an interface consistency verification device based on heterogeneous data, such as... Figure 10 As shown, the device includes: an acquisition unit 71, a processing unit 72, a matching unit 73, and a generation unit 74.

[0075] The acquisition unit 71 is used to acquire the front-end document object model data and user interface design draft data of the page to be verified. The front-end document object model data is the hierarchical nesting data of the page to be verified when it is rendered in the browser, and the user interface design draft data is the multi-level nested structure data exported by the design platform. Processing unit 72 is used to perform standardized structure mapping processing on the front-end document object model data and the user interface design draft data, so as to convert them into virtual node tree structures in a unified format. Each node in the virtual node tree structure contains a unique identifier, hierarchical relationship and style attribute information. The converted front-end document object model data corresponds to a document object virtual node, and the converted user interface design draft data corresponds to a design draft virtual node. Matching unit 73 is used to match the virtual nodes of the document object with the virtual nodes of the design draft based on the hierarchical relationship and node attributes of the virtual node tree structure, and to determine the successfully matched node pairs; The generation unit 74 is used to perform attribute comparison on the successfully matched node pairs and generate an interface consistency verification result based on the difference values ​​obtained from the comparison.

[0076] The interface consistency verification device based on heterogeneous data provided in this invention, compared with existing interface consistency verification methods using interface diagram overlay comparison or pixel-by-pixel comparison, obtains the front-end document object model data and user interface design draft data of the page to be verified. The front-end document object model data is the hierarchical nested data of the page to be verified when rendered in the browser, and the user interface design draft data is the multi-layered nested structure data exported by the design platform. The front-end document object model data and user interface design draft data are subjected to standardized structural mapping processing to convert them into a unified format of virtual node tree structure. Each node in the virtual node tree structure contains a unique identifier, hierarchical relationship, and style attribute information. The converted front-end document object model data corresponds to a document object virtual node, and the converted user interface design draft data corresponds to a design draft virtual node. Based on the hierarchical relationship and node attributes of the virtual node tree structure, the document object virtual nodes and design draft virtual nodes are matched to determine successfully matched node pairs. The successfully matched node pairs are then compared for attributes, and the interface consistency verification result is generated based on the differences obtained from the comparison. The entire process standardizes the structure mapping between front-end document object model data and user interface design draft data, transforming these two types of heterogeneous data into a virtual node tree structure containing unique identifiers, hierarchical relationships, and style attribute information. This effectively solves the problem of direct comparison between design data and page rendering data due to structural differences. Furthermore, by combining hierarchical and attribute matching methods based on the virtual node tree, precise matching between nodes is achieved, avoiding the batch false alarms that easily occur in traditional pixel comparison. By comparing attribute differences between matched node pairs and generating quantitative verification results, not only is a quantitative assessment of interface fidelity and automatic output of comparison results realized, but the accuracy and efficiency of interface consistency verification are also improved. This allows for easy integration into automated workflows, significantly improving the automation level of interface acceptance and reducing manual verification costs.

[0077] In specific application scenarios, the processing unit includes: The first construction module is used to traverse each node in the front-end document object model data, extract the feature information and layout style information of the current node, and construct a standardized first virtual node tree structure; wherein, the feature information includes the node name, tag name and unique identifier determined based on the Cascading Style Sheet class name, and the layout style information includes the outer margin information, inner margin information and border information; The second construction module is used to parse the hierarchical structure of the user interface design draft data, remove invalid nodes and extract the smallest content layer nodes, map the extracted node attributes to a preset standard format, and construct a standardized second virtual node tree structure. The first virtual node tree structure and the second virtual node tree structure have the same data field definitions to facilitate subsequent node matching.

[0078] In specific application scenarios, the first construction module is specifically used for: Iterate through each node in the front-end document object model data, read the tag name and cascading style sheet class name of the current node, determine the node name from the cascading style sheet class name according to the preset business keyword matching rules, and generate a globally unique identifier; Based on the hierarchical relationship during the traversal process, determine the parent node identifier of the current element node, and construct a node object containing the globally unique identifier, parent node identifier, node name, tag name, and list of direct child elements; Call the browser rendering interface to obtain the box model data of the current element node, encapsulate the outer margin value, inner margin value and border value and store them in the node object to form a standardized first virtual node tree structure. The second building module is specifically used for: The hierarchical structure of the user interface design draft data is parsed to identify the root node and child nodes in the hierarchical structure; Traverse all nodes and, according to the preset invalid node rules, remove overlay nodes, status bar nodes, and tiny nodes whose size is smaller than a preset threshold. Shape nodes, text nodes, and image nodes are extracted from the remaining layers after removal as minimum content layer nodes. The attribute information of the minimum content layer nodes is mapped to a format consistent with the node object structure to form a standardized second virtual node tree structure.

[0079] In specific application scenarios, the processing unit further includes: The identification module is used to traverse the first virtual node tree structure after extracting the feature information and layout style information of the current node from each node in the front-end document object model data and constructing a standardized first virtual node tree structure, and then to identify node pairs whose parent nodes contain only a single text child node. The calculation module is used to calculate the actual rendering size of a single text child node if the parent node does not have background color, border or shadow style attributes, and correct the box model data of the parent node to the actual rendering size to eliminate the size difference between the document object model container and the text node defined in the user interface design draft. The parsing module is used to parse the hierarchical structure of the user interface design draft data, remove invalid nodes and extract the minimum content layer nodes, map the extracted node attributes to a preset standard format, and construct a standardized second virtual node tree structure. Then, it parses the layer grouping level nodes in the second virtual node tree structure and extracts the shape nodes, text nodes and bitmap nodes nested inside the layer group. The mapping module is used to remove the layer grouping node if it is only used as a container and has no independent visual attributes, promote the extracted shape node, text node and bitmap node to the parent of the layer grouping node, and map the layout information of the shape node to the standard format corresponding to the block-level element in the document object model.

[0080] In specific application scenarios, the matching unit is specifically used for: For the shape nodes in the virtual nodes of the design draft, a structural matching process is performed: based on the shape node's size, border style, corner radius, and background color attributes, each shape node in the same layer grouping level of the virtual node tree structure of the design draft is traversed, and the comprehensive data weighted matching degree between the virtual node of the document object and each shape node in terms of width, height, and corner radius is calculated. The shape node with the highest matching degree is marked as a successfully matched node pair. For the fixed text nodes in the virtual nodes of the design draft, the content matching process is performed: extract the text content, color, font type, font size and size attributes of the fixed text nodes, calculate the weighted difference value between the virtual nodes of the document object and the fixed text nodes in terms of text content and style, and mark the fixed text node with the smallest difference value as a successfully matched node pair.

[0081] In specific application scenarios, the device further includes: The verification unit is used to match the virtual nodes of the document object with the virtual nodes of the design draft based on the hierarchical relationship and node attributes of the virtual node tree structure. After determining the successfully matched node pairs, it performs structural consistency verification and re-matching for structural matching nodes: calculating the position deviation value of the node; if the position deviation value exceeds the preset structural consistency threshold, it determines that the currently successfully matched node pairs have structural inconsistencies, clears the current matching mark, and re-executes the process of matching the virtual nodes of the document object with the virtual nodes of the design draft based on the node name matching rule or the automatic matching rule based on the size. The acquisition unit is used to acquire the scroll offset distance of the page container in the document object model for the structural matching class node pairs after passing the structural consistency check or rematch, and to correct the absolute position data of the virtual node of the document object based on the scroll offset distance; The comparison unit is used to compare and calculate the final position deviation value based on the corrected absolute position data and the boundary rectangle data of the virtual nodes in the design draft.

[0082] In specific application scenarios, the generation unit is specifically used for: For content-matching node pairs, the text style information attributes of the virtual nodes in the document object and the virtual nodes in the design draft are directly compared to calculate the difference value of the text content and style. The final position deviation value, the difference value of the text content and style are compared with the preset tolerance threshold. Nodes that exceed the tolerance threshold are marked as difference items, and an interface consistency verification result is generated based on the difference items.

[0083] Based on the above-described interface consistency verification method based on heterogeneous data, this application also provides a storage medium storing a computer program that, when executed by a processor, implements the above-described interface consistency verification method based on heterogeneous data.

[0084] Based on this understanding, the technical solution of this application can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, or portable hard drive), and includes several instructions to cause a computer device (such as a personal computer, server, or network device) to execute the methods described in the various implementation scenarios of this application.

[0085] Based on the above-described interface consistency verification method based on heterogeneous data and the corresponding virtual device embodiments, in order to achieve the above objectives, this application embodiment also provides a physical device for the interface consistency verification method based on heterogeneous data. Specifically, it can be a computer, smartphone, tablet computer, smartwatch, server, or network device, etc. The physical device includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to implement the above-described interface consistency verification method based on heterogeneous data.

[0086] Optionally, the physical device may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0087] In an exemplary embodiment, see Figure 11 The aforementioned physical device includes a communication bus, a processor, a memory, and a communication interface. It may also include an input / output interface and a display device. The various functional units can communicate with each other via the bus. The memory stores a computer program, and the processor executes the program stored in the memory to perform the interface consistency verification method based on heterogeneous data in the above embodiments.

[0088] Those skilled in the art will understand that the physical device structure of the interface consistency verification method based on heterogeneous data provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0089] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the physical device using the aforementioned interface consistency verification method based on heterogeneous data, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.

[0090] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented using hardware. By applying the technical solution of this application, compared with the existing methods, this application can standardize the structure mapping processing of front-end document object model data and user interface design draft data, and uniformly convert the two types of heterogeneous data into a virtual node tree structure containing unique identifiers, hierarchical relationships and style attribute information. This effectively solves the problem that design data and page rendering data are difficult to directly compare due to structural differences. At the same time, combined with the hierarchical and attribute matching method based on the virtual node tree, accurate matching between nodes is achieved, avoiding the batch false alarm phenomenon that is easy to occur in traditional pixel comparison. Furthermore, by comparing the attribute differences of the matched node pairs and generating quantitative verification results, not only is the quantitative evaluation of interface fidelity and the automatic output of comparison results achieved, but the accuracy and efficiency of interface consistency verification are also improved. It can be easily integrated into automated integration processes, significantly improving the automation level of interface acceptance and reducing the cost of manual verification.

[0091] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application. Those skilled in the art will understand that the modules in the apparatus of the embodiment can be distributed within the apparatus of the embodiment as described, or can be modified to be located in one or more apparatuses different from this embodiment. The modules of the above-described embodiment can be combined into one module, or further divided into multiple sub-modules.

[0092] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of any particular implementation scenario. The above disclosures are merely a few specific implementation scenarios of this application; however, this application is not limited thereto, and any variations conceived by those skilled in the art should fall within the protection scope of this application.

Claims

1. A method for verifying interface consistency based on heterogeneous data, characterized in that, include: Obtain the front-end document object model data and user interface design draft data of the page to be verified. The front-end document object model data is the hierarchical nesting data of the page to be verified when it is rendered in the browser, and the user interface design draft data is the multi-level nested structure data exported by the design platform. The front-end document object model data and the user interface design draft data are subjected to standardized structure mapping processing to convert them into virtual node tree structures in a unified format. Each node in the virtual node tree structure contains a unique identifier, hierarchical relationship and style attribute information. The converted front-end document object model data corresponds to the document object virtual node, and the converted user interface design draft data corresponds to the design draft virtual node. Based on the hierarchical relationship and node attributes of the virtual node tree structure, the virtual nodes of the document object are matched with the virtual nodes of the design draft to determine the successfully matched node pairs. Specifically, this includes: preliminary screening based on the hierarchical relationship of the virtual node tree; only nodes at the same level have the possibility of being matched. Based on hierarchical filtering, precise matching is performed by combining node attributes; node attributes include node type, size information, layout features, and text style; nodes with attribute similarity reaching a set threshold are judged as successful matches and form corresponding node pairs; The successfully matched node pairs are compared for attributes, and the interface consistency verification result is generated based on the differences obtained from the comparison.

2. The method according to claim 1, characterized in that, The standardization and structural mapping process for the front-end document object model data and the user interface design draft data, to convert them into a unified format virtual node tree structure, includes: Traverse each node in the front-end document object model data, extract the feature information and layout style information of the current node, and construct a standardized first virtual node tree structure; wherein, the feature information includes the node name, tag name and unique identifier determined based on the Cascading Style Sheet class name, and the layout style information includes margin information, padding information and border information; The hierarchical structure of the user interface design draft data is analyzed, invalid nodes are removed and the smallest content layer nodes are extracted. The extracted node attributes are mapped to a preset standard format to construct a standardized second virtual node tree structure. The first virtual node tree structure and the second virtual node tree structure have the same data field definitions to facilitate subsequent node matching.

3. The method according to claim 2, characterized in that, The process of traversing each node in the front-end document object model data, extracting the node's feature information and layout style information, and constructing a standardized first virtual node tree structure includes: Iterate through each node in the front-end document object model data, read the tag name and cascading style sheet class name of the current node, determine the node name from the cascading style sheet class name according to the preset business keyword matching rules, and generate a globally unique identifier; Based on the hierarchical relationship during the traversal process, determine the parent node identifier of the current element node, and construct a node object containing the globally unique identifier, parent node identifier, node name, tag name, and list of direct child elements; Call the browser rendering interface to obtain the box model data of the current element node, encapsulate the outer margin value, inner margin value and border value and store them in the node object to form a standardized first virtual node tree structure. The process of parsing the hierarchical structure of the user interface design draft data, removing invalid nodes and extracting the smallest content layer nodes, mapping the extracted node attributes to a preset standard format, and constructing a standardized second virtual node tree structure includes: The hierarchical structure of the user interface design draft data is parsed to identify the root node and child nodes in the hierarchical structure; Traverse all nodes and, according to the preset invalid node rules, remove overlay nodes, status bar nodes, and tiny nodes whose size is smaller than a preset threshold. Shape nodes, text nodes, and image nodes are extracted from the remaining layers after removal as minimum content layer nodes. The attribute information of the minimum content layer nodes is mapped to a format consistent with the node object structure to form a standardized second virtual node tree structure.

4. The method according to claim 2, characterized in that, After traversing each node in the front-end document object model data, extracting the feature information and layout style information of the current node, and constructing a standardized first virtual node tree structure, the method further includes: Traverse the first virtual node tree structure and identify node pairs whose parent nodes contain only a single text child node; If the parent node does not have background color, border, or shadow style attributes, the actual rendering size of the single text child node is calculated, and the box model data of the parent node is corrected to the actual rendering size to eliminate the size difference between the document object model container and the text node defined in the user interface design draft. After parsing the hierarchical structure of the user interface design draft data, removing invalid nodes and extracting the smallest content layer nodes, mapping the extracted node attributes to a preset standard format, and constructing a standardized second virtual node tree structure, the method further includes: Parse the layer group nodes in the second virtual node tree structure, and extract the nested shape nodes, text nodes, and bitmap nodes within the layer group; If the layer group node is only used as a container and has no independent visual attributes, then the layer group node is removed, the extracted shape node, text node and bitmap node are promoted to the parent of the layer group node, and the layout information of the shape node is mapped to the standard format corresponding to the block-level elements in the document object model.

5. The method according to any one of claims 1-4, characterized in that, The process of matching virtual nodes of the document object with virtual nodes of the design draft based on the hierarchical relationship and node attributes of the virtual node tree structure to determine successfully matched node pairs includes: For the shape nodes in the virtual nodes of the design draft, a structural matching process is performed: based on the shape node's size, border style, corner radius, and background color attributes, each shape node in the same layer grouping level of the virtual node tree structure of the design draft is traversed, and the comprehensive data weighted matching degree between the virtual node of the document object and each shape node in terms of width, height, and corner radius is calculated. The shape node with the highest matching degree is marked as a successfully matched node pair. For the fixed text nodes in the virtual nodes of the design draft, the content matching process is performed: extract the text content, color, font type, font size and size attributes of the fixed text nodes, calculate the weighted difference value between the virtual nodes of the document object and the fixed text nodes in terms of text content and style, and mark the fixed text node with the smallest difference value as a successfully matched node pair.

6. The method according to any one of claims 1-4, characterized in that, After matching the virtual nodes of the document object with the virtual nodes of the design draft based on the hierarchical relationship and node attributes of the virtual node tree structure, and determining the successfully matched node pairs, the method further includes: For structural matching nodes, perform structural consistency verification and rematching: calculate the positional deviation value of the node; if the positional deviation value exceeds the preset structural consistency threshold, it is determined that the currently successfully matched node pair has structural inconsistencies, the current matching mark is cleared, and the process of matching the virtual nodes of the document object with the virtual nodes of the design draft is re-executed based on the node name matching rule or the automatic matching rule based on the size. For structural matching node pairs that have passed structural consistency verification or re-matching, obtain the scroll offset distance of the page container in the document object model, and correct the absolute position data of the virtual node of the document object based on the scroll offset distance; The final position deviation value is calculated by comparing the corrected absolute position data with the boundary rectangle data of the virtual nodes in the design draft.

7. The method according to claim 6, characterized in that, The step of comparing the attributes of the successfully matched node pairs and generating an interface consistency verification result based on the differences obtained from the comparison includes: For content-matching node pairs, the text style information attributes of the virtual nodes in the document object and the virtual nodes in the design draft are directly compared to calculate the difference value of the text content and style. The final position deviation value, the difference value of the text content and style are compared with the preset tolerance threshold. Nodes that exceed the tolerance threshold are marked as difference items, and an interface consistency verification result is generated based on the difference items.

8. A device for verifying interface consistency based on heterogeneous data, characterized in that, include: The acquisition unit is used to acquire the front-end document object model data and user interface design draft data of the page to be verified. The front-end document object model data is the hierarchical nesting data of the page to be verified when it is rendered in the browser, and the user interface design draft data is the multi-level nested structure data exported by the design platform. The processing unit is used to perform standardized structure mapping processing on the front-end document object model data and the user interface design draft data, so as to convert them into virtual node tree structures in a unified format. Each node in the virtual node tree structure contains a unique identifier, hierarchical relationship and style attribute information. The converted front-end document object model data corresponds to the document object virtual node, and the converted user interface design draft data corresponds to the design draft virtual node. The matching unit is used to match the virtual nodes of the document object with the virtual nodes of the design draft based on the hierarchical relationship and node attributes of the virtual node tree structure, and to determine the successfully matched node pairs. Specifically, this includes: preliminary screening based on the hierarchical relationship of the virtual node tree; only nodes at the same level have the possibility of matching; based on the hierarchical screening, precise matching is performed by combining node attributes; node attributes include node type, size information, layout features, and text style; nodes with attribute similarity reaching a set threshold are determined to be successfully matched and form corresponding node pairs. The generation unit is used to perform attribute comparison on the successfully matched node pairs and generate an interface consistency verification result based on the difference values ​​obtained from the comparison.

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

10. A computer storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images