A consistency verification method and device, a storage medium and a processor

Abstract

The application discloses a consistency verification method and device, a storage medium and a processor. In the case, the original design data and the design system variable library of a webpage are obtained; the absolute value of the style information of the original design data is matched with the design system variable library through semantic reverse mapping, the absolute value of the successful matching is replaced with the reference form of the corresponding semantic variable to obtain target design data; the target design data is converted into a structured verification rule; an initial test script is generated according to the structured verification rule by a large language model, a syntax check is performed on the initial test script to generate an executable target test script; the target test script is executed to verify the consistency of the implementation style and the expected style of the webpage to generate a verification result. The application solves the problem of high design semantic consistency verification cost and low accuracy caused by code hard coding and lack of semantic perception ability in the prior art, and improves the consistency verification efficiency and accuracy.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a consistency verification method, apparatus, storage medium and processor. Background Technology

[0002] With the popularization of agile development models and the widespread use of AI-assisted programming tools (such as GitHub Copilot, Amazon CodeWhisperer, etc.), the efficiency of front-end user interface (UI) development has been significantly improved.

[0003] In the current development environment, while AI-assisted programming tools can visually approximate design drafts, achieving pixel-level visual similarity, they often use a large number of hard-coded approximations (i.e., Magic Numbers) instead of standard Design Tokens. This leads to a hidden disconnect between UI semantics and design specifications, compromising the consistency of UI semantics (i.e., design semantics). When design specifications change, manual modification of the scattered hard-coded values ​​is required, significantly increasing maintenance costs and the probability of errors. Existing design semantic consistency verification methods (such as pixel-level visual regression testing) rely on pixel-level comparisons, which are extremely sensitive to the rendering environment. Once the design specifications are slightly adjusted (e.g., changing the global rounded corner from 4px to 6px), not only will a large number of test cases become invalid, increasing maintenance costs, but the consistency verification process will also be unable to effectively distinguish between semantic deviations from specifications and harmless differences at the rendering level. Consequently, it is difficult to continuously support the needs of efficient development in agile iteration scenarios, severely restricting the semantic consistency and long-term maintainability of front-end code. Summary of the Invention

[0004] Based on the above problems, this application provides a consistency verification method, apparatus, storage medium, and processor. The purpose is to solve the technical problems of high cost and low accuracy of design semantic consistency verification caused by the proliferation of hard-coded code and lack of semantic awareness in the prior art, and to improve the efficiency and accuracy of design semantic consistency verification, thereby meeting the needs of agile development for high-quality and maintainable UI semantic consistency assurance.

[0005] The embodiments of this application disclose the following technical solutions: In a first aspect, this application provides a consistency verification method, the method comprising: Obtain the original design draft data of the webpage to be verified and the preset design system variable library; the original design draft data includes a node tree describing the user interface structure and style of the webpage, as well as the attribute information corresponding to the node tree; the design system variable library includes multiple semantic variables used to define the visual and interactive language of the webpage. The absolute values ​​in the style information of the original design draft data are semantically reverse mapped and matched with the variable library of the design system, and the matched absolute values ​​are replaced with the reference form of the corresponding semantic variables to obtain the target design draft data. The target design draft data is converted into a structured validation rule in a preset format. The structured validation rule includes a selector strategy and style attribute assertions. The selector strategy is used to locate the target user interface element to be validated in the webpage, and the style attribute assertions are used to define the expected values ​​of each style attribute of the target user interface element. An initial test script is generated using a large language model based on the structured verification rules, and the initial test script is subjected to syntax verification to generate an executable target test script. The target test script is executed in a browser environment to verify the consistency between the implemented style and the expected style of the webpage, and to generate verification results.

[0006] In an optional implementation, when the absolute values ​​in the style information include the absolute color values ​​of each component in the original design draft data, the absolute values ​​in the style information of the original design draft data are semantically reverse mapped and matched with the design system variable library, and the successfully matched absolute values ​​are replaced with references to the corresponding semantic variables to obtain the target design draft data, including: The original design draft data is cleaned, and the absolute color value is extracted from the cleaned design draft data. Calculate the color difference between the absolute color value and the standard color value in the design system variable library; If the color difference is greater than or equal to a preset threshold, it is determined that the absolute color value does not find a matching semantic variable in the design system variable library, and the corresponding component is marked as a non-standard style; the non-standard style is a style defined using hard-coded absolute values; If the color difference is less than the preset threshold, then the absolute color value is determined to match the semantic variable in the design system variable library, and the absolute color value is replaced with the reference form of the semantic variable corresponding to the design system variable library to generate the target design draft data.

[0007] In an optional implementation, when the absolute value in the style information also includes the spacing value between the sub-elements of the composite component in the original design draft data, generating the target design draft data includes: Identify the layout attribute information of the composite component from the cleaned design draft data; Extract the spacing values ​​between each of the child elements from the layout attribute information; If the spacing value is a preset spacing value, then the spacing value is replaced with a reference to the semantic variable corresponding to the design system variable library to obtain the target design draft data.

[0008] In an optional implementation, the step of generating an initial test script using a large language model based on the structured validation rules, and performing syntax validation on the initial test script to generate an executable target test script includes: Obtain the test framework syntax specification information and the component encapsulation structure information of the webpage; the test framework syntax specification information includes rules defining the format, structure and execution logic of the test script, and the component encapsulation structure information is used to describe the user interface elements, layout structure and interaction methods of the webpage; Based on the test framework syntax specification information, the component encapsulation structure information, and the structured verification rules, prompt words are constructed; The initial test script is generated based on the prompt words using the large language model, and the initial test script is parsed using an abstract syntax tree to obtain the parsed test script; The parsed test script is subjected to syntax compliance verification, and the target test script is generated after the parsed test script passes the syntax compliance verification.

[0009] In an optional implementation, executing the target test script in a browser environment to verify the consistency between the implemented style and the expected style of the webpage, and generating verification results, includes: The webpage to be verified is loaded in the browser environment, and the target test script is run in the webpage to perform DOM attribute verification. If the DOM attribute verification fails, visual similarity verification is performed to generate the verification result. The DOM attribute validation is used to verify whether the calculated values ​​of each style attribute of the target user interface element are consistent with the expected values. The visual similarity validation is used to verify whether the rendered image of the target user interface element is consistent with the corresponding design draft slice. The calculated value is the value obtained after parsing the style attributes of the target user interface element in the current rendering environment. The design draft slice is the image of the corresponding area of ​​the target user interface element in the original design draft.

[0010] In an optional implementation, performing DOM attribute validation includes: The position information of the target user interface element in the webpage is determined according to the selector strategy, and the calculated values ​​of each style attribute of the target user interface element are obtained through the browser interface based on the position information. Detect whether the style attributes of the target user interface element are consistent with the corresponding semantic variables; If the style attribute is inconsistent with the corresponding semantic variable, then the DOM attribute validation is determined to have failed. If each of the style attributes is consistent with its corresponding semantic variable, then check whether the calculated value of each style attribute is consistent with its corresponding expected value. If the calculated value of the style attribute is inconsistent with the corresponding expected value, then the DOM attribute validation is determined to have failed.

[0011] In an optional implementation, the step of performing a visual similarity check and generating the verification result when the DOM attribute validation fails includes: A screenshot is taken of the rendering area of ​​the target user interface element in the webpage to obtain a rendered image; The similarity between the rendered image and the design draft slices is calculated using a structural similarity algorithm; If the similarity is greater than the similarity threshold, then the rendered image is determined to be consistent with the corresponding design draft slice, and the corresponding verification result is generated; If the similarity is less than or equal to the similarity threshold, it is determined that the rendered image is inconsistent with the corresponding design draft slice, and a corresponding verification result is generated.

[0012] A second aspect of this application provides a conformance verification apparatus, the apparatus comprising: The acquisition module is used to acquire the original design draft data of the webpage to be verified and the preset design system variable library; the original design draft data includes a node tree describing the user interface structure and style of the webpage, as well as the attribute information corresponding to the node tree; the design system variable library includes multiple semantic variables used to define the visual and interactive language of the webpage. The reverse mapping module is used to perform semantic reverse mapping matching between the absolute values ​​in the style information of the original design draft data and the design system variable library, and replace the successfully matched absolute values ​​with the reference form of the corresponding semantic variables to obtain the target design draft data. The rule conversion module is used to convert the target design draft data into structured verification rules in a preset format. The structured verification rules include selector strategies and style attribute assertions. The selector strategies are used to locate the target user interface elements to be verified in the webpage, and the style attribute assertions are used to define the expected values ​​of each style attribute of the target user interface element. The generation module is used to generate an initial test script based on the structured verification rules using a large language model, and to perform syntax verification on the initial test script to generate an executable target test script. The verification module is used to execute the target test script in a browser environment to verify the consistency between the implemented style and the expected style of the webpage and generate verification results.

[0013] In a third aspect, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned consistency verification method.

[0014] In a fourth aspect, this application provides a processor for running a computer program, which executes the above-described consistency verification method during runtime.

[0015] Compared with the prior art, this application has the following beneficial effects: In this technical solution, the original design draft data of the webpage to be verified and a preset design system variable library are first obtained. The original design draft data integrates a node tree describing the user interface structure and style of the webpage and the corresponding attribute information of the node tree. The design system variable library integrates multiple semantic variables used to define the visual and interactive language of the webpage, thus providing a data foundation for establishing a semantic mapping bridge between design semantics and code. Then, the absolute values ​​in the style information of the original design draft data are semantically reverse mapped and matched with the design system variable library. The matched absolute values ​​are replaced with the reference form of the corresponding semantic variables to obtain the target design draft data. This achieves the binding of code and design system variables, solving the problem of difficulty in ensuring design semantic consistency caused by rampant hard coding. Therefore, when the design specifications change, only the variable library needs to be updated for global synchronization, without manual code modification, which greatly reduces maintenance costs and error probability, and ensures the consistency between design semantics and design specifications from the root. Then, the target design draft data is transformed into structured validation rules in a preset format. These structured validation rules can include selector strategies and style attribute assertions. The selector strategy is used to locate the target user interface elements to be validated on the webpage, and the style attribute assertions are used to define the expected values ​​of each style attribute of the target user interface element. This transforms subjective visual judgment into quantifiable semantic verification standards, solving the problem of existing semantic consistency verification relying on fuzzy visual comparison, which makes it difficult to distinguish between semantic and rendering differences. This effectively improves the accuracy and maintainability of semantic consistency verification. Then, an initial test script is generated based on the structured validation rules using a large language model, and the initial test script is subjected to syntax validation, automatically... Generating executable target test scripts solves the problems of tedious and error-prone hand-written test scripts, significantly improving the efficiency and reliability of test script development. Finally, automatically executing the target test scripts in the browser environment can accurately capture semantic deviations during actual runtime, enabling efficient consistency verification of the actual and expected styles of web pages and generating high-precision verification results. This solves the technical problems of high cost and low accuracy in design semantic consistency verification caused by rampant hard-coding and lack of semantic awareness in existing technologies, thereby improving the efficiency and accuracy of design semantic consistency verification, reducing code maintenance costs, and effectively meeting the needs of agile development for high-quality, maintainable UI semantic consistency assurance. Attached Figure Description

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

[0017] Figure 1 A flowchart illustrating a consistency verification method provided in this application embodiment; Figure 2 A flowchart of another consistency verification method provided in the embodiments of this application; Figure 3 A flowchart illustrating the execution process of semantic reverse mapping matching provided in this application embodiment; Figure 4 A flowchart illustrating another semantic reverse mapping matching execution process provided in this application embodiment; Figure 5 A flowchart illustrating the generation process of a target test script, as provided in an embodiment of this application; Figure 6 A flowchart illustrating the execution process of DOM attribute validation provided in this application embodiment; Figure 7 A flowchart illustrating the execution process of visual similarity verification provided in this application embodiment; Figure 8 This is a schematic diagram of a conformance verification device provided in an embodiment of this application. Detailed Implementation

[0018] As described earlier, in the current development environment, while AI-assisted programming tools can visually approximate design drafts, achieving pixel-level visual similarity, the underlying development often relies on a large number of hard-coded approximations (i.e., MagicNumbers) instead of standard Design Tokens (for example, using #0050D0 to replace the named BrandBlue variable, or simulating rounded corners, spacing, and other attributes in the design draft through approximations). This "formally similar but not semantically similar" code may pass traditional visual tests, but it actually severs the semantic connection between style values ​​and the design specification system, leading to a large accumulation of design liabilities in the codebase. Consequently, when design specifications change, the scattered hard-coded values ​​need to be manually corrected one by one, causing maintenance costs to rise exponentially, which runs counter to the rapid iteration and continuous delivery philosophy of agile development.

[0019] On the other hand, in the front-end development process, non-standard design drafts, manual overlay adjustments by developers, and the "illusion generation" of AI tools (i.e., generating code that deviates from the latest specifications based on limited context) all contribute to a hidden disconnect between code implementation and the design system. For example, the design specification clearly states that the button spacing is 16px (corresponding to the global variable $spacing-md), but the actual code may contain hard-coded values ​​such as 15.8px and 16.2px, or the corner radius may not follow the predefined $radius-base variable. This "specification drift" is difficult to detect in a timely manner due to the lack of a mandatory semantic-level verification mechanism, often requiring manual review or online issue feedback, resulting in prolonged repair cycles and wasted resources, severely weakening the consistency constraint effectiveness of the design system.

[0020] Existing design semantic consistency verification methods (such as pixel-level visual regression testing) rely on pixel-level comparison, which is extremely sensitive to the rendering environment. Once the design specifications are slightly adjusted (such as changing the global rounded corner from 4px to 6px), not only will a large number of test cases become invalid, increasing maintenance costs, but the consistency verification process will also be unable to effectively distinguish between semantic deviations from specifications and harmless differences at the rendering level. As a result, it is difficult to continuously support the needs of efficient development in agile iteration scenarios, which seriously restricts the semantic consistency guarantee and long-term maintainability of front-end code.

[0021] The inventors have proposed a consistency verification method, device, storage medium, and processor. This scheme first acquires the original design draft data of the webpage to be verified, along with a pre-defined design system variable library. The original design draft data integrates a node tree describing the webpage's user interface structure and style, along with corresponding attribute information. The design system variable library also integrates multiple semantic variables used to define the webpage's visual and interactive language, providing a data foundation for establishing a semantic mapping bridge between design semantics and code. Next, the absolute values ​​in the style information of the original design draft data are semantically reverse-mapped and matched with the design system variable library. Successfully matched absolute values ​​are replaced with references to the corresponding semantic variables, yielding the target design draft data. This achieves the binding of code and design system variables, solving the problem of difficulty in ensuring design semantic consistency caused by rampant hard coding. Therefore, when design specifications change, only the variable library needs to be updated for global synchronization, eliminating the need for manual code modification, significantly reducing maintenance costs and error probability, and fundamentally ensuring the consistency between design semantics and design specifications. Then, the target design draft data is transformed into structured validation rules in a preset format. These structured validation rules can include selector strategies and style attribute assertions. The selector strategy is used to locate the target user interface elements to be validated on the webpage, and the style attribute assertions are used to define the expected values ​​of each style attribute of the target user interface element. This transforms subjective visual judgment into quantifiable semantic verification standards, solving the problem of existing semantic consistency verification relying on fuzzy visual comparison, which makes it difficult to distinguish between semantic and rendering differences. This effectively improves the accuracy and maintainability of semantic consistency verification. Then, an initial test script is generated based on the structured validation rules using a large language model, and the initial test script is subjected to syntax validation, automatically... Generating executable target test scripts solves the problems of tedious and error-prone hand-written test scripts, significantly improving the efficiency and reliability of test script development. Finally, automatically executing the target test scripts in the browser environment can accurately capture semantic deviations during actual runtime, enabling efficient consistency verification of the actual and expected styles of web pages and generating high-precision verification results. This solves the technical problems of high cost and low accuracy in design semantic consistency verification caused by rampant hard-coding and lack of semantic awareness in existing technologies, thereby improving the efficiency and accuracy of design semantic consistency verification, reducing code maintenance costs, and effectively meeting the needs of agile development for high-quality, maintainable UI semantic consistency assurance.

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0023] Method Implementation Examples

[0024] This application provides an embodiment of a consistency verification method. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although the flowchart shows a logical order, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0025] See Figure 1 The figure is a flowchart of a consistency verification method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes the following steps: Step S101: Obtain the original design draft data of the webpage to be verified and the preset design system variable library.

[0026] In step S101, the original design draft data includes a node tree describing the user interface structure and style of the webpage, as well as the attribute information corresponding to the node tree. The design system variable library includes multiple semantic variables (such as standard semantic variables such as color, layout, and spacing) used to define the visual and interactive language of the webpage.

[0027] In this embodiment, the system can obtain the original design draft data of the webpage to be verified through the standard data interface of a design tool (such as Figma / Sketch). Taking the login button as an example, the original design draft data can be as follows:

[0028] The system can parse and traverse the abstract tree structure of the above code (i.e. Figure 2 The original design draft data shown can be used to extract structured semantic information of the user interface layer by layer, including component types, style attributes and content data, thereby providing a reliable data foundation for subsequent generation of test cases or high-accuracy semantic consistency verification.

[0029] The system can then load a pre-defined design system variable library (such as a variable library that includes standard semantic variables like color, layout, and spacing). By integrating the original design draft data, which describes the user interface structure and style of the webpage and the attribute information corresponding to the node tree, as well as the design system variable library that integrates multiple semantic variables used to define the visual and interactive language of the webpage, it can provide a data foundation for establishing a semantic mapping bridge between design semantics and code.

[0030] It's important to note that in design tools like Figma, to achieve efficient performance and storage management, data organization follows the principle of reference and separation: the main component serves as the core template, fully defining all style and structural attributes of the component; while instance nodes only store references to the corresponding main component, without storing any independent style information by default. The tool only records the corresponding attribute override values ​​under that node when certain attributes of an instance are explicitly modified by the user, thus ensuring lightweight data while supporting instance-level style customization.

[0031] Step S102: Perform semantic reverse mapping matching between the absolute values ​​in the style information of the original design draft data and the design system variable library, and replace the successfully matched absolute values ​​with the reference form of the corresponding semantic variables to obtain the target design draft data.

[0032] In this embodiment of the application, the system can Figure 2 The absolute values ​​(e.g., #D32F2F) in the style information (such as button colors) of the original design data shown are compared with... Figure 2 The design system variable library shown in the diagram performs semantic reverse mapping matching, and replaces the successfully matched absolute values ​​with the reference form of the corresponding semantic variable (e.g., if the successfully matched absolute value is #D32F2F, the corresponding semantic variable reference form is var(--color-danger), #D32F2F can be replaced with var(--color-danger) to establish semantic constraints), thus obtaining the target design draft data. This achieves the binding of code and design system variables, solving the problem of difficulty in ensuring design semantic consistency caused by rampant hard coding. Therefore, when the design specifications change, only the variable library needs to be updated for global synchronization, without the need for manual code modification, greatly reducing maintenance costs and error probability, and ensuring the consistency of design semantics and design specifications from the root.

[0033] Specifically, when the absolute values ​​in the style information include the absolute color values ​​of each component in the original design draft data, the system can perform semantic reverse mapping matching by comparing the absolute color values ​​of each component with the standard colors in the design system variable library.

[0034] See Figure 3The figure is a flowchart of the execution process of semantic reverse mapping matching provided in an embodiment of this application. The process includes the following steps: Step S1021: Clean the original design draft data and extract the absolute color values ​​from the cleaned design draft data.

[0035] In this embodiment, the system employs Depth-First Search (DFS) to traverse each node in the original design draft data. It automatically removes redundant nodes (such as invisible nodes (visible=false), purely auxiliary grouping nodes without style attributes, and metadata nodes carrying specific ignore tags) through built-in filters, thus focusing on interface elements with actual semantics and style definitions. During this traversal, when the system identifies a reference node, it automatically backtracks to its main component to obtain the basic style definition and simultaneously merges the attribute override values ​​set on that node, thereby restoring the complete style information ultimately presented by the node and obtaining the cleaned design draft data. The system can then extract the absolute color values ​​of each component from the cleaned design draft data, providing a data foundation for subsequent semantic reverse mapping and matching.

[0036] Step S1022: Calculate the color difference between the absolute color value and the standard color value in the design system variable library.

[0037] In this embodiment, the system can use a perceptual uniform color space (such as CIEDE2000) to calculate the color difference between the absolute color value and the standard color value in the design system variable library, and determine whether the color difference is greater than a preset threshold (such as a preset threshold set to 2.3) to determine whether the absolute color value matches the semantic variable in the design system variable library. Specifically, if the color difference is greater than or equal to the preset threshold, step S1023 is executed; if the color difference is less than the preset threshold, step S1024 is executed.

[0038] Taking button A as an example, the absolute color value of this button is #D32F2F. The standard color values ​​in the system variable library are #D33131 for color-error and #0056D2 for color-primary. The system can convert the absolute color value, color-error, and color-primary of button A to the CIEDE2000 color space respectively. Then, it calculates that the color difference between the converted absolute color value and the converted standard value of color-error is 0.5, and the color difference between the converted absolute color value and the converted standard value of color-primary is 38.2. Finally, the system determines that the color of button A visually matches color-error but does not match color-primary by judging that the color difference between the absolute color value of button A and the standard value of color-error is less than 2.3 and the color difference between the absolute color value of button A and the standard value of color-primary is greater than 2.3.

[0039] Step S1023: Determine that no matching semantic variable is found for the absolute color value in the design system variable library, and mark the corresponding component as a non-standard style.

[0040] In step S1023, the non-standard style is a style defined using hard-coded absolute values.

[0041] In this embodiment, when the system determines that the absolute color value of any component does not match the semantic variables in the design system variable library, the corresponding component can be marked as a non-standard style. For example, the corresponding component can be marked as Detached Style, which serves as the basis for subsequent compliance checks.

[0042] Step S1024: Determine that the absolute color value matches the semantic variable in the design system variable library, and replace the absolute color value with the reference form of the corresponding semantic variable in the design system variable library to generate the target design draft data.

[0043] In this embodiment of the application, when the system determines that the absolute color value of any component matches the semantic variable in the design system variable library, the absolute color value can be replaced with a reference to the corresponding semantic variable in the design system variable library.

[0044] Taking button A as an example, the absolute color value of the button is #D32F2F. When the system determines that it matches the semantic variable color-error in the system variable library, it can update the absolute color value of button A from #D32F2Fvar(--color-error) to var(--color-error).

[0045] Furthermore, when the absolute values ​​in the style information also include the spacing values ​​between the sub-elements of the composite component in the original design draft data, the system can also perform semantic reverse mapping matching by comparing the spacing values ​​between the sub-elements of the composite component with the preset spacing values.

[0046] See Figure 4 The figure is a flowchart of another semantic reverse mapping matching execution process provided in an embodiment of this application. The process includes the following steps: Step S1025: Identify the layout attribute information of the composite components from the cleaned design draft data.

[0047] Step S1026: Extract the spacing values ​​between each child element from the layout attribute information.

[0048] Step S1027: If the spacing value is a preset spacing value, then replace the spacing value with the reference form of the semantic variable corresponding to the design system variable library to obtain the target design draft data.

[0049] In this embodiment, the system can automatically identify the flexible layout structure of composite components (such as the Flex / Grid model converted from Figma automatic layout), extract the visual spacing between child elements (such as 16px), and automatically map it to the spacing semantic variable of the design system (such as --spacing-md). Thus, the hard-coded fixed values ​​are replaced with responsive CSS custom properties (such as gap: var(--spacing-md)), thereby achieving association with the design token (i.e., semantic variable) at the code level. This not only ensures the consistency of layout spacing with design specifications but also allows the interface to adapt to different screen sizes and scenarios without modifying the layout code itself, all through CSS variables.

[0050] Step S103: Convert the target design draft data into a structured verification rule in a preset format.

[0051] In step S103, the structured validation rules include selector strategies and style attribute assertions. The selector strategy is used to locate the target user interface element to be validated in the webpage, and the style attribute assertions are used to define the expected values ​​of each style attribute of the target user interface element.

[0052] In this embodiment, the system can convert target design draft data into structured validation rules in a preset format (such as JSON). These structured validation rules may include selector strategies and style attribute assertions. The selector strategy is used to locate the target user interface element to be validated on the webpage, and the style attribute assertions are used to define the expected values ​​(e.g., expect(actual value).to_equal(expected value)) of each style attribute of the target user interface element. This transforms subjective visual judgment into quantifiable semantic verification standards, solving the problem of existing semantic consistency verification relying on fuzzy visual comparison, which makes it difficult to distinguish between semantic and rendering differences. This effectively improves the accuracy and maintainability of semantic consistency verification. For example, the style attribute assertion is: expect(backgroundColor).toBe("var(--color-primary) At this point, the system no longer checks whether the login button is "displayed in blue" when verifying it. Instead, it asserts that its background color style must be a semantic variable var(--color-primary), thereby ensuring that the implementation is consistent with the design system at the semantic level.

[0053] Step S104: Use the large language model to generate an initial test script based on structured validation rules, and perform syntax validation on the initial test script to generate an executable target test script.

[0054] In this embodiment, the system can utilize the code generation and reasoning capabilities of a large language model to dynamically transform the above-mentioned structured verification rules into initial test scripts, and perform AST (Abstract Syntax Tree) level syntax verification on the initial test scripts to automatically generate executable target test scripts. This solves the problems of tedious and error-prone handwritten test scripts, and greatly improves the efficiency and reliability of test script development.

[0055] Specifically, see Figure 5 The figure is a flowchart of a target test script generation process provided in an embodiment of this application. The process includes the following steps: Step S1041: Obtain the test framework syntax specification information and the component encapsulation structure information of the webpage.

[0056] In step S1041, the test framework syntax specification information includes rules defining the format, structure, and execution logic of the test script, and component encapsulation structure information used to describe the user interface elements, layout structure, and interaction methods of the webpage.

[0057] In this embodiment, the component encapsulation structure information of the webpage can provide the LLM (Large Language Model) with the componentized encapsulation structure of the current webpage (such as the Page Object Model, or POM for short). This allows the LLM to generate element positioning logic based on existing, semantic component names (such as LoginModal.SubmitButton), significantly improving the readability and reusability of test code and avoiding the generation of fragile and verbose low-level CSS selectors. The test framework syntax specification information can be used to explicitly specify the syntax specification of the target test framework (such as Playwright or Cypress), ensuring that the test code generated by the LLM fully conforms to the framework's requirements in terms of syntax and API call style, eliminating the need for tedious manual syntax conversion.

[0058] Step S1042: Construct prompt words based on the test framework syntax specification information, component encapsulation structure information, and structured verification rules.

[0059] In this embodiment, the system can construct prompts that conform to design semantic constraints, page structure cognition, and framework syntax specifications based on test framework syntax specification information, component encapsulation structure information, and structured validation rules. Through the design semantic constraints in these prompts (i.e., the CSS variable mapping table in the structured validation rules used to map absolute values ​​to semantic variables in reference form, such as #0056D2 mapping to var(--brand-blue), #D32F2F mapping to var(--color-danger), and 16px mapping to var(--spacing-md)), the LLM can be instructed to prioritize generating assertions based on design semantic variables (such as var(--color-primary)) rather than hard-coded specific values ​​(such as #0056D2), thereby ensuring the consistency of design semantics at the code layer while verifying functional correctness. For example, telling the LLM, "Don't write specific color values ​​(such as #ff0000), write variable names (such as var(--color-danger))", ensures that the generated code not only runs but also checks semantic compliance.

[0060] In this embodiment, by recognizing the page structure in the aforementioned prompts, the LLM can be provided with a component-based encapsulation structure of the current webpage. This allows the LLM to generate element location logic based on existing, semantic component names, significantly improving the readability and reusability of test code and avoiding the generation of fragile and verbose low-level CSS selectors. For example, telling the LLM, "There is a login box called LoginModal on this page, and there is a button called SubmitButton," enables the generated code to accurately locate the elements on the page.

[0061] In this embodiment of the application, the syntax specification of the target testing framework (such as Playwright or Cypress) can be specified through the framework syntax specification in the above prompt words, so as to ensure that the code generated by LLM fully conforms to the requirements of the framework in terms of syntax and API calling style, without the need for tedious manual syntax conversion.

[0062] Step S1043: Generate an initial test script based on prompt words using a large language model, and parse the initial test script using an abstract syntax tree to obtain the parsed test script.

[0063] In this embodiment, the system utilizes a large language model based on the aforementioned prompts to automatically generate verification logic adapted to front-end rendering characteristics and best engineering practices. Based on this logic, an initial test script is generated, and then the generated initial test script is parsed using an Abstract Syntax Tree (AST) (e.g., by calling the TypeScript Compiler API) to obtain the parsed test script. Specifically, the aforementioned verification logic includes: (1) Numeric assertions. For numerical style properties such as width, height, and position, LLM will generate assertions with a reasonable tolerance range (such as expect(value).toBeCloseTo(expected, delta=0.5)) to accommodate sub-pixel rendering differences caused by different browsers, rendering engines, or screen resolutions, and avoid test failures due to harmless minor numerical deviations.

[0064] (2) Interactive state simulation verification. For interactive states defined in the design draft (such as :hover, :focus), LLM will generate corresponding interactive event simulation code (such as await element.hover()) and style assertions in the corresponding state, so that consistency verification can cover dynamic interactive effects and break through the limitation of traditional visual comparison that can only verify static default states.

[0065] (3) Element positioning strategy. LLM generates element selectors according to a preset priority strategy to maximize the stability of the test script. The priority order of the preset priority strategy (e.g., from high to low) is as follows: test-specific ID, text content, semantic tags, CSS path, ensuring that the test script can still run even if the page structure is slightly adjusted.

[0066] For example, button testing first uses the test-specific ID (e.g., data-testid="submit-btn"). Button testing second uses the text content (e.g., text="login"). Button testing third uses the semantic tag (e.g., role="button"). Button testing last uses the CSS path (e.g., div>div:nth-child(3)>button).

[0067] Step S1044: Perform syntax compliance verification on the parsed test script, and generate the target test script after the parsed test script passes the syntax compliance verification.

[0068] In this embodiment, the system can use the built-in type checker (such as TypeChecker) of the TypeScript Compiler API to perform symbol resolution, automatically verifying whether all identifiers are explicitly defined in the current scope and page object model (i.e., POM), thereby accurately intercepting errors caused by illusions such as referencing undefined variables during the compilation stage, and finally outputting a syntactically correct and compliant .spec.ts test file (i.e., the target test script).

[0069] Step S105: Execute the target test script in the browser environment to verify the consistency between the implemented style and the expected style of the webpage, and generate the verification result.

[0070] In this embodiment, the system can automatically execute the target test script in a browser environment and adopt a cascading strategy of DOM (Document Object Model) priority and visual fallback to verify the consistency between the implemented style and the expected style of the webpage. This enables accurate capture of semantic deviations during actual runtime, achieving efficient consistency verification between the implemented style and the expected style of the webpage. It solves the technical problems of high cost and low accuracy of design semantic consistency verification caused by rampant hard-coding and lack of semantic awareness in the prior art, thereby improving the efficiency and accuracy of design semantic consistency verification, reducing code maintenance costs, and effectively meeting the needs of agile development for high-quality and maintainable UI semantic consistency assurance.

[0071] Specifically, in this embodiment, during the process of loading the webpage to be verified in the browser environment and running the target test script in the webpage, the system first performs DOM attribute validation to verify whether the calculated values ​​of each style attribute of the target user interface element are consistent with the expected values. The calculated values ​​are the numerical values ​​obtained after parsing the style attributes of the target user interface element in the current rendering environment. For example, if a button's design width is 120px, the system will use getComputedStyle() to obtain its actual calculated value (e.g., "120px") after rendering in the browser and compare it with the expected value. If the developer mistakenly writes the style as min-width:120px; while the actual content width is 150px, the calculated value will be "150px". The validation will immediately detect this deviation from the specification, thereby effectively identifying code errors, compatibility issues, and unconventional rendering results.

[0072] See Figure 6 The figure is a flowchart of the execution process of DOM attribute validation provided in an embodiment of this application. The process includes the following steps: Step S1051: Determine the location information of the target user interface element in the webpage according to the selector strategy, and obtain the calculated values ​​of each style attribute of the target user interface element through the browser interface based on the location information.

[0073] For example, if it is necessary to verify the background color of a login button, the system will locate the button element according to the selector strategy (such as by data-testid="submit-btn"), and then call the browser interface getComputedStyle(buttonElement).backgroundColor to get the calculated value of its actual rendered background color (such as rgb(0,86,210)).

[0074] Step S1052: Detect whether the style attributes of the target user interface element are consistent with the corresponding semantic variables.

[0075] In this embodiment, the system can verify whether the implementation of style attributes is associated with corresponding design semantic variables, thereby ensuring that the code and the design system are consistent at the semantic level, not just the visual level. For example, in the scenario of verifying the background color of a login button, the system can detect whether the login button correctly references semantic variables (such as background-color:var(--color-primary)) or directly hardcodes color values ​​(such as background-color:#0056D2) to determine whether the above DOM attribute verification passes.

[0076] It's important to note that detecting the consistency between the style attributes and corresponding semantic variables of target user interface elements is not simply a visual comparison, but a deep verification of design semantic relevance at the code implementation level. This ensures that even if a style attribute renders visually in the browser exactly the same as the target value in the design specification, if it's not implemented in the code by referencing the corresponding semantic variable (e.g., using `var(--color-primary)`) but instead directly written as a hard-coded value (e.g., #0056D2), the system will still classify it as inconsistent. This effectively ensures that style attributes maintain the correct semantic association with the design system at the source code level, thus achieving deep consistency from surface visual matching to underlying code semantics.

[0077] Step S1053: If the style attribute is inconsistent with the corresponding semantic variable, then the DOM attribute validation is determined to have failed.

[0078] In this embodiment, when a style attribute does not correctly reference design semantic variables in its code implementation (e.g., directly hardcoding the color value #0056D2), even if its calculated value is visually consistent with the target value of the design specification, the system will still determine that its DOM attribute validation fails. For example, if the button background color is not associated with var(--color-primary) but is directly written as a color value, this implementation will be judged as a non-standard style. This ensures a strict binding between the style and the semantics of the design system at the code level, thus guaranteeing long-term consistency from the root.

[0079] Step S1054: If each style attribute is consistent with its corresponding semantic variable, then check whether the calculated value of each style attribute is consistent with its corresponding expected value.

[0080] In this embodiment, when all style attributes and their corresponding semantic variables are consistent, the system can also detect whether the calculated values ​​of each style attribute are consistent with their corresponding expected values ​​to determine whether the DOM attribute validation has passed. For example, if the button background color attribute does indeed reference var(--color-primary), the system will obtain the final calculated value of this variable parsed in the page (e.g., rgb(0,86,210) obtained through getComputedStyle()) and compare it with the standard value defined for this variable in the design system (e.g., #0056D2) to determine whether the DOM attribute validation has passed. Then, the system can determine that the DOM attribute validation has passed when it determines that the calculated values ​​of the style attributes are consistent with their corresponding expected values.

[0081] Step S1055: If the calculated value of the style attribute is inconsistent with the corresponding expected value, then it is determined that the DOM attribute validation has failed.

[0082] In this embodiment, the system can determine that the DOM attribute validation fails when the calculated value of a style attribute is inconsistent with its corresponding expected value; and determine that the DOM attribute validation passes when the calculated value of a style attribute is consistent with its corresponding expected value. For example, if the button background color has correctly referenced var(--color-primary), the system will obtain its actual parsed value (e.g., rgb(0,86,210) obtained through getComputedStyle()) and strictly compare it with the standard value of this semantic variable in the system (e.g., #0056D2). If they are consistent, the DOM attribute validation of the attribute is determined to have passed; if they are inconsistent (e.g., the variable is accidentally overridden and parsed as #FF0000), the validation is determined to have failed.

[0083] Secondly, if DOM attribute validation fails, the system can perform visual similarity validation (i.e., VisualFallback, referring to perception-based visual similarity validation) to generate a verification result. Visual similarity validation verifies whether the rendered image of the target user interface element matches the corresponding slice in the design draft. The design draft slice is the image of the corresponding area of ​​the target user interface element in the original design draft. For example, if the DOM validation of a button's background color fails due to a hard-coded color value (such as #0056D2), the system will still capture the rendered image of that button and compare it with the button slice marked "color-primary" in the design draft. If the two are visually consistent, it indicates that the current implementation only deviates from the semantic specifications, and the final visual effect still meets the design expectations. This ensures the accuracy of the final visual presentation even when the code fails to meet the semantic specifications of the design system.

[0084] See Figure 7 The figure is a flowchart of a visual similarity verification process provided in an embodiment of this application. The process includes the following steps: Step S1056: Take a screenshot of the rendering area of ​​the target user interface element in the webpage to obtain the rendering image.

[0085] Step S1057: Calculate the similarity between the rendered image and the design draft slices using a structural similarity algorithm.

[0086] In this embodiment of the application, the system can use a structural similarity algorithm (such as SSIM, which stands for Structural Similarity Index) to calculate the similarity between the rendered image and the design slide.

[0087] Step S1058: If the similarity is greater than the similarity threshold, then the rendered image is determined to be consistent with the corresponding design draft slice, and the corresponding verification result is generated.

[0088] In this embodiment of the application, when the similarity is greater than a set threshold (such as 0.98), the system can determine that the rendered image and the design draft slice are visually consistent. Such cases can usually be attributed to the slight deviation in DOM attribute calculation values ​​caused by differences in anti-aliasing, font rendering, etc. of different platforms or browsers, and generate corresponding verification results accordingly.

[0089] Step S1059: If the similarity is less than or equal to the similarity threshold, it is determined that the rendered image is inconsistent with the corresponding design draft slice, and the corresponding verification result is generated.

[0090] In this embodiment of the application, when the similarity is less than or equal to a set threshold (such as 0.98), the system can determine that the rendered image is inconsistent with the corresponding design slide and generate the corresponding verification result.

[0091] It should be noted that by adopting a cascading verification strategy that prioritizes DOM and provides visual fallback, the consistency between the webpage implementation and design expectations is verified. DOM verification ensures 100% style semantic coverage and rapid feedback, while the robustness of visual verification filters out harmless rendering differences. Thus, while maintaining comprehensive detection capabilities, the overall false alarm rate of consistency verification is minimized.

[0092] In one feasible implementation, such as Figure 2 As shown, for style items with inconsistent validation, the system can trace the complete source of its calculated styles with the help of browser developer tool protocols (such as Chrome DevTools Protocol), and use CSS Source Map to accurately map the runtime style rules back to source code files such as Less and Sass and specific line numbers. Finally, the analysis report provides a location link that can jump to the IDE with one click, which greatly shortens the troubleshooting path for developers.

[0093] The consistency verification method provided in this application binds code to design system variables, solving the problem of difficulty in ensuring semantic consistency in design caused by rampant hard coding. Therefore, when design specifications change, only the variable library needs to be updated for global synchronization, eliminating the need for manual code modification, significantly reducing maintenance costs and error probability, and fundamentally ensuring the consistency between design semantics and design specifications. It transforms subjective visual judgment into quantifiable semantic verification standards, solving the problem of existing semantic consistency verification relying on fuzzy visual comparison, which makes it difficult to distinguish between semantic and rendering differences, effectively improving the accuracy and maintainability of semantic consistency verification. It accurately captures semantic deviations during actual runtime, efficiently verifying the consistency between the implemented style and the expected style of the webpage, generating high-precision verification results. This solves the technical problems of high cost and low accuracy in design semantic consistency verification caused by rampant hard coding and lack of semantic awareness in existing technologies, thereby improving the efficiency and accuracy of design semantic consistency verification, reducing code maintenance costs, and effectively meeting the needs of agile development for high-quality, maintainable UI semantic consistency assurance.

[0094] In addition, this application also uses a cascading verification strategy of DOM priority and visual fallback to verify the consistency between the webpage implementation and design expectations. While maintaining comprehensive detection capabilities, it minimizes the overall false alarm rate of consistency verification.

[0095] Device Examples

[0096] This application provides a consistency verification device, wherein... Figure 8 This is a schematic diagram of the structure of a conformance verification device provided in an embodiment of this application, as shown below. Figure 8As shown, the device includes: an acquisition module 81, a reverse mapping module 82, a rule conversion module 83, a generation module 84, and a verification module 85. From Figure 8 You can see the connections between several modules.

[0097] The acquisition module 81 is used to acquire the original design draft data of the webpage to be verified and the preset design system variable library. The original design draft data includes a node tree describing the user interface structure and style of the webpage, as well as the attribute information corresponding to the node tree. The design system variable library includes multiple semantic variables used to define the visual and interactive language of the webpage. The reverse mapping module 82 is used to perform semantic reverse mapping matching between the absolute values ​​in the style information of the original design draft data and the design system variable library, and replace the successfully matched absolute values ​​with the reference form of the corresponding semantic variables to obtain the target design draft data. The rule conversion module 83 is used to convert the target design draft data into structured validation rules in a preset format. The structured validation rules include selector strategies and style attribute assertions. The selector strategies are used to locate the target user interface elements to be validated in the webpage, and the style attribute assertions are used to define the expected values ​​of each style attribute of the target user interface elements. The generation module 84 is used to generate an initial test script based on the structured validation rules using a large language model, and to perform syntax validation on the initial test script to generate an executable target test script. Verification module 85 is used to execute the target test script in the browser environment to verify the consistency between the implemented style and the expected style of the webpage and generate verification results.

[0098] Optionally, when the absolute values ​​in the style information include the absolute color values ​​of each component in the original design draft data, the reverse mapping module includes: The data cleaning unit is used to clean the original design draft data and extract absolute color values ​​from the cleaned design draft data. The color difference calculation unit is used to calculate the color difference between the absolute color value and the standard color value in the design system variable library; The first determining unit is used to determine that if the color difference is greater than or equal to a preset threshold, the absolute color value does not find a matching semantic variable in the design system variable library, and marks the corresponding component as a non-standard style; the non-standard style is a style defined by hard-coded absolute values. The second determining unit is used to determine if the color difference is less than a preset threshold, then match the absolute color value with the semantic variable in the design system variable library, and replace the absolute color value with the reference form of the corresponding semantic variable in the design system variable library to generate the target design draft data.

[0099] Optionally, when the absolute values ​​in the style information also include the spacing values ​​between the sub-elements of the composite component in the original design draft data, the second determining unit includes: The identification unit is used to identify the layout attribute information of composite components from the cleaned design draft data; The extraction unit is used to extract the spacing values ​​between each child element in the layout attribute information; The replacement unit is used to replace the spacing value with a reference to the semantic variable corresponding to the design system variable library if the spacing value is a preset spacing value, so as to obtain the target design draft data.

[0100] Optionally, the generation module includes: The acquisition unit is used to acquire test framework syntax specification information and webpage component encapsulation structure information. The test framework syntax specification information includes rules that define the format, structure and execution logic of test scripts, and the component encapsulation structure information is used to describe the user interface elements, layout structure and interaction methods of the webpage. The building unit is used to construct prompt words based on the test framework syntax specification information, component encapsulation structure information, and structured validation rules; The first generation unit is used to generate an initial test script based on prompt words using a large language model, and to parse the initial test script using an abstract syntax tree to obtain the parsed test script. The second generation unit is used to perform syntax compliance checks on the parsed test script, and generate the target test script after the parsed test script passes the syntax compliance check.

[0101] Optionally, the verification module includes: The execution unit loads the webpage to be verified in the browser environment and runs the target test script in the webpage to perform DOM attribute verification. If the DOM attribute verification fails, visual similarity verification is performed to generate verification results. DOM attribute verification is used to verify whether the calculated values ​​of each style attribute of the target user interface element are consistent with the expected values. Visual similarity verification is used to verify whether the rendered image of the target user interface element is consistent with the corresponding design draft slice. The calculated value is the value obtained after parsing the style attributes of the target user interface element in the current rendering environment. The design draft slice is the image of the corresponding area of ​​the target user interface element in the original design draft.

[0102] Optionally, the execution unit includes: The third determining unit is used to determine the position information of the target user interface element in the webpage according to the selector strategy, and obtain the calculated values ​​of each style attribute of the target user interface element through the browser interface based on the position information. The first detection unit is used to detect whether the style attributes of the target user interface element are consistent with the corresponding semantic variables; The fourth determining unit is used to determine that the DOM attribute validation has failed if the style attribute is inconsistent with the corresponding semantic variable. The second detection unit is used to detect whether the calculated value of each style attribute is consistent with the corresponding expected value if each style attribute is consistent with the corresponding semantic variable. The fifth determination unit is used to determine that the DOM attribute validation has failed if the calculated value of the style attribute is inconsistent with the corresponding expected value.

[0103] Optionally, the execution unit further includes: The screenshot unit is used to capture the rendered area of ​​the target user interface element in the webpage to obtain a rendered image; The similarity calculation unit is used to calculate the similarity between the rendered image and the design slide using a structural similarity algorithm; The sixth determining unit is used to determine that the rendered image is consistent with the corresponding design draft slice if the similarity is greater than the similarity threshold, and to generate the corresponding verification result; The seventh determination unit is used to determine that the rendered image is inconsistent with the corresponding design draft slice if the similarity is less than or equal to the similarity threshold, and to generate the corresponding verification result.

[0104] Storage Media Examples

[0105] This application provides a computer-readable storage medium storing a program, wherein when executed by a processor, the program implements some or all of the steps in the consistency verification method described in the foregoing method embodiments of this application. The storage medium can be any medium capable of storing program code, such as a USB flash drive, external hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0106] Processor Implementation

[0107] This application provides a processor for running a program, wherein some or all of the steps in the consistency verification method described in the foregoing method embodiments are executed during program execution.

[0108] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate. The components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment solution according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0109] The above is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A consistency verification method, characterized in that, include: Obtain the original design draft data of the webpage to be verified and the preset design system variable library; the original design draft data includes a node tree describing the user interface structure and style of the webpage, as well as the attribute information corresponding to the node tree; the design system variable library includes multiple semantic variables used to define the visual and interactive language of the webpage. The absolute values ​​in the style information of the original design draft data are semantically reverse mapped and matched with the design system variable library, and the successfully matched absolute values ​​are replaced with the reference form of the corresponding semantic variables to obtain the target design draft data. The target design draft data is converted into a structured validation rule in a preset format. The structured validation rule includes a selector strategy and style attribute assertions. The selector strategy is used to locate the target user interface element to be validated in the webpage, and the style attribute assertions are used to define the expected values ​​of each style attribute of the target user interface element. An initial test script is generated using a large language model based on the structured verification rules, and the initial test script is subjected to syntax verification to generate an executable target test script. The target test script is executed in a browser environment to verify the consistency between the implemented style and the expected style of the webpage, and to generate verification results.

2. The method according to claim 1, characterized in that, When the absolute values ​​in the style information include the absolute color values ​​of each component in the original design draft data, the absolute values ​​in the style information of the original design draft data are semantically reverse mapped and matched with the design system variable library, and the successfully matched absolute values ​​are replaced with the reference form of the corresponding semantic variables to obtain the target design draft data, including: The original design draft data is cleaned, and the absolute color value is extracted from the cleaned design draft data. Calculate the color difference between the absolute color value and the standard color value in the design system variable library; If the color difference is greater than or equal to a preset threshold, it is determined that the absolute color value does not find a matching semantic variable in the design system variable library, and the corresponding component is marked as a non-standard style; the non-standard style is a style defined using hard-coded absolute values. If the color difference is less than the preset threshold, then the absolute color value is determined to match the semantic variable in the design system variable library, and the absolute color value is replaced with the reference form of the semantic variable corresponding to the design system variable library to generate the target design draft data.

3. The method according to claim 2, characterized in that, When the absolute value in the style information also includes the spacing value between the sub-elements of the composite component in the original design draft data, generating the target design draft data includes: Identify the layout attribute information of the composite component from the cleaned design draft data; Extract the spacing values ​​between each of the child elements from the layout attribute information; If the spacing value is a preset spacing value, then the spacing value is replaced with a reference to the semantic variable corresponding to the design system variable library to obtain the target design draft data.

4. The method according to claim 1, characterized in that, The process of generating an initial test script using a large language model based on the structured validation rules, performing syntax validation on the initial test script, and generating an executable target test script includes: Obtain the test framework syntax specification information and the component encapsulation structure information of the webpage; the test framework syntax specification information includes rules defining the format, structure and execution logic of the test script, and the component encapsulation structure information is used to describe the user interface elements, layout structure and interaction methods of the webpage; Based on the test framework syntax specification information, the component encapsulation structure information, and the structured verification rules, prompt words are constructed; The initial test script is generated based on the prompt words using the large language model, and the initial test script is parsed using an abstract syntax tree to obtain the parsed test script; The parsed test script is subjected to syntax compliance verification, and the target test script is generated after the parsed test script passes the syntax compliance verification.

5. The method according to claim 1, characterized in that, The step of executing the target test script in a browser environment to verify the consistency between the implemented style and the expected style of the webpage and generating verification results includes: The webpage to be verified is loaded in the browser environment, and the target test script is run in the webpage to perform DOM attribute verification. If the DOM attribute verification fails, visual similarity verification is performed to generate the verification result. The DOM attribute verification is used to verify whether the calculated values ​​of each style attribute of the target user interface element are consistent with the expected values. The visual similarity verification is used to verify whether the rendered image of the target user interface element is consistent with the corresponding design draft slice. The calculated value is the value obtained after parsing the style attributes of the target user interface element in the current rendering environment. The design draft slice is the image of the corresponding area of ​​the target user interface element in the original design draft.

6. The method according to claim 5, characterized in that, The execution of DOM attribute validation includes: The position information of the target user interface element in the webpage is determined according to the selector strategy, and the calculated values ​​of each style attribute of the target user interface element are obtained through the browser interface based on the position information. Detect whether the style attributes of the target user interface element are consistent with the corresponding semantic variables; If the style attribute is inconsistent with the corresponding semantic variable, then the DOM attribute validation is determined to have failed. If each of the style attributes is consistent with its corresponding semantic variable, then check whether the calculated value of each style attribute is consistent with its corresponding expected value. If the calculated value of the style attribute is inconsistent with the corresponding expected value, then the DOM attribute validation is determined to have failed.

7. The method according to claim 6, characterized in that, If the DOM attribute validation fails, a visual similarity validation is performed to generate the validation result, including: A screenshot is taken of the rendering area of ​​the target user interface element in the webpage to obtain a rendered image; The similarity between the rendered image and the design draft slices is calculated using a structural similarity algorithm; If the similarity is greater than the similarity threshold, then the rendered image is determined to be consistent with the corresponding design draft slice, and the corresponding verification result is generated; If the similarity is less than or equal to the similarity threshold, it is determined that the rendered image is inconsistent with the corresponding design draft slice, and a corresponding verification result is generated.

8. A consistency verification device, characterized in that, include: The acquisition module is used to acquire the original design draft data of the webpage to be verified and the preset design system variable library; the original design draft data includes a node tree describing the user interface structure and style of the webpage, as well as the attribute information corresponding to the node tree; the design system variable library includes multiple semantic variables used to define the visual and interactive language of the webpage. The reverse mapping module is used to perform semantic reverse mapping matching between the absolute values ​​in the style information of the original design draft data and the design system variable library, and replace the successfully matched absolute values ​​with the reference form of the corresponding semantic variables to obtain the target design draft data. The rule conversion module is used to convert the target design draft data into structured verification rules in a preset format. The structured verification rules include selector strategies and style attribute assertions. The selector strategies are used to locate the target user interface elements to be verified in the webpage, and the style attribute assertions are used to define the expected values ​​of each style attribute of the target user interface element. The generation module is used to generate an initial test script based on the structured verification rules using a large language model, and to perform syntax verification on the initial test script to generate an executable target test script. The verification module is used to execute the target test script in a browser environment to verify the consistency between the implemented style and the expected style of the webpage and generate verification results.

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

10. A processor, characterized in that, Used to run a computer program, which, when running, performs the consistency verification method as described in any one of claims 1-7.

Images