CN121009004A

CN121009004A - Automated test script generation methods and apparatus, storage media and electronic devices

Info

Publication number: CN121009004A
Application number: CN202510832248.2A
Authority: CN
Inventors: 陶应
Original assignee: Hunan MgtvCom Interactive Entertainment Media Co Ltd
Current assignee: Hunan MgtvCom Interactive Entertainment Media Co Ltd
Priority date: 2025-06-19
Filing date: 2025-06-19
Publication date: 2025-11-25

Abstract

The application discloses an automatic test script generation method and device, a storage medium and electronic equipment. The method comprises the steps of identifying a current project file, generating a target document structure and a target style structure based on the current project file under the condition that the project file is changed, wherein the target document structure is used for indicating the content of the current project file, the target style structure is used for indicating the style of the current project file, comparing the target document structure with a reference document structure, the target style structure and the reference style structure respectively, and updating a test script corresponding to the project file based on the changed front-end element under the condition that the front-end element is changed between the target document structure and the reference document structure and/or between the target style structure and the reference style structure, wherein the front-end element is used for indicating interactable or visible elements in the project file. The application solves the technical problem of low updating efficiency of the automatic test script generation method provided by the related technology.

Description

Automatic test script generation method and device, storage medium and electronic equipment

Technical Field

The application relates to the technical field of automatic test script generation, in particular to an automatic test script generation method and device, a storage medium and electronic equipment.

Background

In testing items, automated test scripts that simulate the operation and behavior of a user in a software application are typically utilized in place of the repeated manual testing process.

In the related art, a tester typically writes a script manually before using the automation script, and in the event that a developer modifies a project, the tester needs to maintain the automation script. Once multiple consecutive urgent versions are not updated, a partial automation script may not be updated in time resulting in erroneous test results. Namely, the problem of low updating efficiency exists in the automatic test script generation method provided by the related technology.

In view of the above problems, no effective solution has been proposed at present.

Disclosure of Invention

The embodiment of the application provides an automatic test script generation method and device, a storage medium and electronic equipment, which at least solve the technical problem that the automatic test script generation method provided by the related technology has low update efficiency.

According to one aspect of the embodiment of the application, an automatic test script generation method is provided, and the method comprises the steps of identifying a current project file, generating a target document structure and a target style structure based on the current project file under the condition that the project file is changed, wherein the target document structure is used for indicating the content of the current project file, the target style structure is used for indicating the style of the current project file, comparing the target document structure with a reference document structure, the target style structure and the reference style structure respectively, and updating a test script corresponding to the project file based on the changed front-end element under the condition that the changed front-end element exists between the target document structure and the reference document structure and/or between the target style structure and the reference style structure, wherein the front-end element is used for indicating interactable or visible elements in the project file.

According to another aspect of the embodiment of the application, an automatic test script generating device is further provided, which comprises a structure generating unit, a script updating unit and a script updating unit, wherein the structure generating unit is used for identifying a current project file, generating a target document structure and a target style structure based on the current project file in the case that the project file is changed, the target document structure is used for indicating the content of the current project file, the target style structure is used for indicating the style of the current project file, the structure comparing unit is used for respectively comparing the target document structure with a reference document structure, the target style structure and the reference style structure, and the script updating unit is used for updating a test script corresponding to the project file based on the changed front-end element in the case that the front-end element is changed between the target document structure and the reference document structure and/or between the target style structure and the reference style structure.

Optionally, the script updating unit comprises a first script updating module, a second script updating module and a second script updating module, wherein the first script updating module is used for updating the test script based on the changed front-end element when the structure change exists between the target document structure and the reference document structure, the target style structure and the reference style structure or the changed front-end element is a key element, the key element is used for indicating a core function in a project file, and the second script updating module is used for updating the test script based on the changed front-end element when the changed front-end element exists between the target document structure and the reference document structure, the target style structure and the reference style structure is a common element, and the common element is used for indicating an auxiliary function in the project file.

Optionally, the script updating unit comprises a test instruction generating module, an interface script generating module and a mixed script updating module, wherein the test instruction generating module is used for determining a corresponding test instruction based on element information included in the front-end element, the interface script generating module is used for determining a corresponding interface script based on interface information of an interface when the front-end element comprises the interface, and the mixed script updating module is used for updating the test script corresponding to the project file according to the test instruction and the interface script.

Optionally, the interface script generating module is further configured to determine a database corresponding to the interface, associate the operation of the interface with the database based on table information of the database, and determine information of the interface based on an interface file in the project file.

The structure generation unit comprises a structure generation module and a structure updating module, wherein the structure generation module is used for generating a candidate document structure and a candidate style structure based on a content file of a project file, and the structure updating module is used for determining information of a front end element in the project file and updating the candidate document structure and the candidate style structure into a target document structure and a target style structure according to the information of the front end element.

Optionally, the above structure updating module is further configured to determine that the front-end element is static data and determine a preset value corresponding to the front-end element as an input of the test script when the attribute value of the front-end element is defined by the project file, and determine that the front-end element is dynamic data and read a database corresponding to the front-end element when the attribute value of the front-end element is acquired by the interface.

Optionally, the structure generating unit further comprises a file identifying module, wherein the file identifying module is used for determining a storage address of the project file and reading a log file of the storage address, and determining that the project file has change under the condition that the version of the project file is recorded in the log file.

According to yet another aspect of embodiments of the present application, there is also provided a computer-readable storage medium having a computer program stored therein, wherein the computer program is configured to perform the above-described automated test script generation method when run.

According to yet another aspect of embodiments of the present application, there is provided a computer program product comprising a computer program/instructions stored in a computer readable storage medium. The computer program/instructions are read from the computer readable storage medium by a processor of a computer device, and executed by the processor, to cause the computer device to perform an automated test script generation method as above.

According to yet another aspect of an embodiment of the present application, there is also provided an electronic device including a memory, in which a computer program is stored, and a processor configured to execute the automated test script generation method described above by the computer program.

In the embodiment of the application, a current project file is identified, a target document structure and a target style structure are generated based on the current project file under the condition that the project file is changed, wherein the target document structure is used for indicating the content of the current project file, the target style structure is used for indicating the style of the current project file, the target document structure and a reference document structure, the target style structure and the reference style structure are respectively compared, and under the condition that a changed front-end element exists between the target document structure and the reference document structure, the target style structure and the reference style structure, a test script corresponding to the project file is updated based on the changed front-end element, wherein the front-end element is used for indicating an interactable or visible element in the project file. By monitoring the change of the project file in real time, the automatic test system can automatically identify and update the test script without manual intervention. When the project file is changed, the system generates a new target document structure and a new target style structure, and the new target document structure and the new target style structure are intelligently compared with the reference structure to automatically identify the changed front-end element. The process greatly saves script maintenance time of testers after code iteration, reduces human errors and improves accuracy and timeliness of test scripts. Therefore, the technical problem that the update efficiency is low in the automatic test script generation method provided by the related technology is solved by using the method.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute a limitation on the application. In the drawings:

FIG. 1 is a schematic diagram of a hardware environment of an alternative automated test script generation method in accordance with an embodiment of the present application;

FIG. 2 is a flow chart of an alternative automated test script generation method in accordance with embodiments of the present application;

FIG. 3 is a schematic diagram of an alternative automated test script generating device in accordance with embodiments of the present application;

fig. 4 is a schematic diagram of an alternative electronic device according to an embodiment of the application.

Detailed Description

In order that those skilled in the art will better understand the present application, a technical solution in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in which it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present application without making any inventive effort, shall fall within the scope of the present application.

It should be noted that the terms "first," "second," and the like in the description and the claims of the present application and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the application described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

According to an aspect of the embodiment of the present application, there is provided an automated test script generating method, which may be applied, but not limited to, to an automated test script generating system in a hardware environment as shown in fig. 1, as an alternative implementation manner. The automated test script generation system may include, but is not limited to, terminal device 102, network 110, server 112, database 114, among others. The terminal device 102 runs a target program (as shown in fig. 1, this target program is taken as an example of a program that can automatically test items). The terminal device 102 includes a display 108, a processor 106, and a memory 104. The display 108 may be used for displaying pages under different working conditions, and the like, and also for providing a man-machine interaction interface to receive man-machine interaction operations for touch control of different information. The processor is used for responding to the man-machine interaction operation to generate an interaction instruction and sending the interaction instruction to the server so as to acquire project files and the like. The memory is used for storing image data, text data and other data of a target page displayed by the running client.

In addition, a processing engine 116 is included in the server 112, the processing engine 116 being configured to perform a store or read operation on the database 114. Specifically, processing engine 116 reads project files from database 114.

Assuming that the terminal device 102 in fig. 1 runs a program for performing automatic testing on the UI, the specific process of this embodiment includes the steps of, as in step S102, requesting, by the terminal device 102, a project file to be tested from the server 112 through the network 110, where the terminal device 102 may be one or more devices, and after receiving the request sent by the terminal device 102, the server 112 obtaining the project file from the database 114 and sending the project file to the terminal device 102, so as to automatically test the project file.

After the project file to be tested is received by the terminal device 102, steps S104-S108 are executed in the terminal device 102, the current project file is identified, a target document structure and a target style structure are generated based on the current project file under the condition that the project file is changed, the target document structure is used for indicating the content of the current project file, the target style structure is used for indicating the style of the current project file, the target document structure and the reference document structure, the target style structure and the reference style structure are respectively compared, and under the condition that front-end elements which are changed between the target document structure and the reference document structure and/or between the target style structure and the reference style structure exist, test scripts corresponding to the project file are updated based on the changed front-end elements.

Alternatively, in this embodiment, the terminal device 102 may be a terminal device configured with a target program, and may include, but is not limited to, at least one of a Mobile phone (such as iOS, android Mobile phones, etc.), a notebook computer, a tablet computer, a palm computer, a MID (Mobile INTERNET DEVICES, mobile internet device), a PAD, a desktop computer, a smart tv, etc. The client may be a video client, a test client, or the like that supports providing automated test script generation tasks or may access a target page. Such networks may include, but are not limited to, wired networks including local area networks, metropolitan area networks, and wide area networks, wireless networks including bluetooth, WIFI, and other networks that enable wireless communications. The server may be a single server, a server cluster composed of a plurality of servers, or a cloud server. The above is merely an example, and is not limited in any way in the present embodiment.

Alternatively, in the present embodiment, the above-described automated test script generation method may be applied to, but is not limited to, a test client. The UI automatic script can be dynamically generated from the analysis of the source codes, the updating of codes is continuously monitored, and the UI change is automatically identified and adapted, so that the comprehensiveness and the effectiveness of the automatic test script are ensured. Not only can the script writing and maintenance cost of the tester be obviously reduced, but also the test coverage rate and the test efficiency can be improved. By the method, a test team can concentrate on high-value test design and defect analysis, and the script generation and update work with high repeatability is processed by an automatic test device, so that the period of software development and deployment is accelerated. The automatic script generation method applied to the test client not only covers the range of the traditional function test, but also goes deep into the dynamic change and visual effect test of the user interface, and provides a comprehensive test solution for ensuring high-quality video application programs. The method is particularly suitable for the development of modern mobile application requiring frequent iteration and optimizing the user interface, and can greatly improve the test efficiency, shorten the development period and enhance the user satisfaction without sacrificing the test precision.

As an alternative embodiment, as shown in fig. 2, the automatic test script generating method includes the following steps:

S202, identifying a current project file, and generating a target document structure and a target style structure based on the current project file under the condition that the project file is changed, wherein the target document structure is used for indicating the content of the current project file, and the target style structure is used for indicating the style of the current project file;

The project file refers to all relevant files constituting the front-end application program, including HTML, CSS, javaScript, vue/React component files, etc. The automation system first needs to identify these files and analyze the composition, function modules and style definitions of each page. For some modern front-end frameworks (e.g., vue, act) that use templates (templates) and components, the system needs to parse not only a single HTML file, but also understand complex logic inside the components and referencing relationships between the components, so that an accurate DOM/CSSOM structure can be generated.

The target document structure, which may be a target DOM structure, is a tree structure of HTML tag hierarchical relationships generated by the automation system based on the current project file. This structure reflects the location and hierarchy of all visual elements on the page, including text, images, buttons, forms, and the like. For simple pages that directly generate DOM structures, the system can directly parse the HTML file to generate the DOM tree. For complex pages based on templates and components, the system needs to analyze the component files and templates in multiple steps, namely, an initial frame of the DOM tree is constructed, then the details of the DOM tree are gradually perfected according to actual reference and nesting conditions of the components, and it is ensured that the real-time state of the page is accurately reflected by each layer of DOM nodes.

The target style structure, which may be a target CSSOM structure, is a structure of selector hierarchies generated by the automation system based on CSS rules in the project file. The CSSOM tree shows how the CSS rules apply to specific DOM nodes, including inheritance, overrides, and priority relationships. For complex front-end items, the styles are typically defined in a decentralized manner in inline styles within multiple CSS files or components, and the automation system must be able to merge these different style rules to create a global CSSOM tree that ensures that the styles of each element can be correctly identified and applied. This means that the system is to be able to identify which CSS rules a particular element is affected by and how these rules are applied.

In an alternative embodiment, when a change occurs to the project file (HTML, CSS, or JS file), the automation system will immediately re-execute step S202. It again identifies and parses all affected files, generating new target document structures and target style structures. The process can automatically detect newly added, modified or deleted elements and styles, and ensures that the test script always keeps consistent with the latest state of the project. For example, if a change in color or position of a button occurs, the automation system will detect a corresponding change in CSSOM, update the element positioning and style verification rules in the test script.

Through the steps, the automatic test system can generate a document and a style structure which accurately reflect the current state of the project, and the validity and the accuracy of the test script are ensured, so that the overall efficiency and the quality of the test are improved. The method is particularly suitable for front-end projects with frequent iteration and rapid change, can effectively reduce test maintenance cost caused by code change, and improves the working efficiency of development teams.

S204, comparing the target document structure with the reference document structure, the target pattern structure and the reference pattern structure respectively;

As previously described, the target document structure is a DOM tree structure that the automated test system generates based on the current project file, reflecting the latest state of all visual elements in the current project, including the type, ID, class name, location of the elements, and the hierarchical relationship between them. The reference document structure may be a DOM tree generated based on a previous version of the project file, storing the previous state of the project.

In step S204, the system compares the two structures layer by layer, and detects any newly added, modified or deleted elements in the DOM tree. This comparison is not limited to the elements themselves, but also includes the attributes and hierarchical relationships of the elements. For example, the system may check whether new elements are added to the page, whether existing elements have properties changed (e.g., class, style, or data properties), or whether the hierarchical relationship of the elements has been adjusted. These changes will be marked by the system as a basis for test script updates.

As previously described, the target style structure is CSSOM tree of the current project file, which describes the application of all CSS rules and their selectors to the DOM tree, including inline styles, external style sheets, and component internal styles. The reference style structure may be CSSOM trees based on a previous version of the project file. In comparing these two structures, the system will check for changes to the style rules, including new rule additions, modifications to the rules (e.g., changes in color, size, location), and deletion of the rules. In addition, the system verifies whether the priority and inheritance relationships of the style rules have changed, as these changes may affect the final style presentation of the element.

Through the structural comparison, the automatic test system can intelligently identify which front-end elements and styles are subjected to modification. For the changed front-end elements, the system updates the corresponding test script to ensure that the test case can accurately locate and operate the elements, for example, if the ID of one element is changed, the system updates the old ID-based locating statement in the script. For style changes, the system updates the style verification points in the script to ensure that the test cases can correctly verify the appearance and layout of the elements. And the comparison process is automatic, and when the system detects that the project file is changed, the system immediately executes structural comparison and automatically updates the test script based on the comparison result. The mechanism ensures the instantaneity and accuracy of the test script, avoids errors and delays caused by manually updating the script, and thus, the test efficiency and quality are remarkably improved.

S206, in the case that a changed front-end element exists between the target document structure and the reference document structure and/or between the target style structure and the reference style structure, updating the test script corresponding to the project file based on the changed front-end element, wherein the front-end element is used for indicating an interactable or visible element in the project file.

It should be noted that any change of the interactive or visual front-end element in the project file is identified by comparing the target document structure (DOM tree) and the target style structure (CSSOM tree) with the reference structure in S204. These changes may include additions and deletions of elements, attribute modifications, style changes or hierarchy adjustments, etc. The automation system records these update points, including updated element IDs, class names, attributes, styles, and their position changes in the DOM/CSSOM structure.

In an alternative embodiment, the system matches the detected update points with existing automated test scripts and analyzes how the update affects the execution of the scripts. If the updated points can be matched with the positioning statements or operation instructions in the test script, the system automatically adjusts the relevant parts in the script to ensure that the script can still correctly position and operate the updated elements. For example, if the ID of a button changes, the system will update the click operation in the script to point to the new ID. In addition, the system may perform more detailed processing for the delta (i.e., newly added element or function) in the updated content. The method analyzes the attribute, style and function of the new element and generates corresponding test cases to test whether the behavior and appearance of the new element meet the expectations.

In an alternative embodiment, the system automatically optimizes test scripts, including UI automation scripts and API automation scripts, based on analysis of the changing front-end elements. It updates the element locator (e.g., XPath, CSS selector), the operation instructions (e.g., click, fill out form data), and assertions (verify element status or backend interface response) in the script. For UI automation scripts, the system ensures that the script can accurately identify and manipulate updated elements, e.g., update the XPath path or Class attributes of the elements to accommodate changes in DOM structure. For an API automation script, if the logic or data model of the back-end interface changes, the system will adjust the test data and expected results in the script accordingly to ensure the validity and accuracy of the test.

In an alternative embodiment, if the updated content is a newly added element or function, the system may implement an incremental update mechanism. This means that the system will generate a new set of test cases, dedicated to testing these new additions. The generation of these new use cases is based on in-depth analysis of the new elements, including their functional logic, data interactions, and associations with the user interface. Through the increment updating mechanism, the system can be quickly adapted to the change of projects, ensures the test coverage, and simultaneously avoids unnecessary changes to the existing test cases, thereby improving the efficiency and the accuracy of the test.

In an alternative embodiment, updating the test script corresponding to the project file based on the changed front-end element comprises updating the test script based on the target document structure and the target style structure when there is a structural change between the target document structure and the reference document structure, the target style structure and the reference style structure, or when there is a changed front-end element as a key element, wherein the key element is used for indicating a core function in the project file, and updating the test script based on the changed front-end element when there is a common element between the target document structure and the reference document structure, the target style structure and the reference style structure, wherein the common element is used for indicating an auxiliary function in the project file.

It should be noted that, in the update policy of the automated test script, global update and incremental update are two methods for updating the test script corresponding to the project file based on the changed front-end element. The following is a detailed description of this strategy:

Global updates are update policies that are performed when there is a significant structural change between the target document structure (DOM tree) and the reference document structure and/or between the target style structure (CSSOM tree) and the reference style structure, or when the front-end element of the change is a key element. Key elements are those elements that have a significant impact on page functionality, user interaction, or important business logic. If such elements are changed, execution of multiple test cases may be affected, and thus global-scope script updates are required.

In an alternative embodiment, in performing the global update, the automation system first identifies structural changes in the DOM tree and CSSOM tree, including additions and deletions of elements, position movements, property changes, and the like. If the structural change is found to be significant, or the key element has a change, a global update flow is initiated. Then, based on the new target document structure and target style structure, the system will re-evaluate the element positioning policies, operational instructions, and assertion conditions in the test script, possibly requiring adjustment or reconstruction of the entire script to ensure that the script correctly reflects the latest front-end state. For the change of key elements, the system can generate or update a series of test cases, so that all key functions and interaction points can be covered by the test.

Incremental updates are update policies that are performed if there are front-end elements of variation between the target document structure and the reference document structure and/or between the target style structure and the reference style structure, but these elements are common elements. Common elements are those elements that have little impact on page function or are not critical paths in the test. If only these elements change, the execution flow of the whole test script is not affected, so that more local script updating can be performed.

In an alternative embodiment, the system automatically recognizes common elements of changes in the DOM tree and CSSOM tree, including their property changes, position adjustments, etc., during execution of the incremental update, but without involving comprehensive structural reorganization. Then, based on the front-end elements of the changes, the system only updates the portions of the test script that are relevant to those changes. For example, if the class name of a common element changes, the system will update the CSS selector in the script to accommodate the new class name without affecting the rest of the script. For test cases involving common element changes, the system can be fine-tuned to ensure that the test cases are still valid. This may involve updating the input data, expected output, or predicate conditions in the use case to accommodate the latest state of the element.

It should be noted that global updates typically involve more comprehensive and deep script modifications and are therefore more time consuming, while incremental updates are only adjusted to changing local areas, which is more efficient. The global update has a larger influence on the whole test framework, and the test environment may need to be recompiled or constructed, and the incremental update has a smaller influence range, and only relates to specific test cases or script parts. The global updating strategy is more suitable for the scene of front-end reconstruction or key function change, and the incremental updating strategy is more suitable for the scene of small-range correction or optimization.

By combining the global updating and incremental updating strategies, the automatic testing system can respond to the change of the project file more flexibly and efficiently, ensure the accuracy of the testing script and the continuity of the testing process, reduce the cost of testing and maintenance and improve the productivity of a testing team. The strategy is particularly suitable for a agile iteration mode common in modern software development, and can be quickly adapted to a rapidly-changing front-end environment.

In an alternative embodiment, the test script corresponding to the project file is updated based on the changed front-end element, and the method comprises the steps of determining a corresponding test instruction based on element information included in the front-end element, determining a corresponding interface script based on interface information of an interface when the front-end element includes the interface, and updating the test script corresponding to the project file according to the test instruction and the interface script.

When elements having changes in the front-end interface are found, all that is needed is to analyze the attributes of the elements and the modules or methods to which the elements belong. For example, if the ID of an input box is changed or the position of a button is moved, the automated system will determine the corresponding test instruction based on the changed element information. The test instructions may include, but are not limited to, clicking on an element, populating an input box, selecting a drop down menu option, verifying whether the element is present or visible, and the like. These instructions form the basis of a test script for simulating user interactions and verifying element states.

While the operation of some front-end elements may involve interaction with an interface of the back-end, such as clicking a search button to initiate a search request. The automation system needs to identify the association between the elements and the back-end interface, analyze the information such as parameters, methods, URLs and the like of the interface, and further generate a corresponding interface automation script. The interface script is responsible for simulating service communication with the back end, sending a request and verifying a response, and ensuring the correctness of the cooperative work of the front end and the back end.

In an alternative embodiment, when a DOM/CSSOM structural change or element attribute change is detected, the automation system first generates updated test instructions based on the new element information and the modular approach. This may mean a modification to an existing instruction, or a new addition of an instruction associated with a new element, to accommodate the latest state of the front-end interface. If the changed front-end element relates to a back-end interface, the system may generate or update a corresponding interface script, including a data format of the interface request, verification of the expected response, and the like. For example, when the source of option data for a drop-down menu changes from static to dynamic (i.e., is retrieved from a backend interface), the system will automatically generate an interface request script to retrieve the latest list of options. And reconstructing the affected test cases by using the updated test instructions and the interface script. This includes the integrated processing of UI automation scripts and API automation scripts. For example, for test cases of search functionality, the system may generate 5 UI automation scripts (corresponding to input box processing, drop-down box processing, and click operations, respectively), one interface automation script (processing search interface queries), and one combined test case, covering verification of all UI operations and interface calls. When the DOM/CSSOM structure changes, the relevant test patterns are regenerated to ensure compatibility and coverage with the new structure.

Through the embodiment of the application, the automatic test system can intelligently identify the change of the front-end element and generate and update the test script in a targeted manner, so that the automatic test system not only comprises the interactive test of the user interface, but also covers the interface automatic test related to the interactive test. The method ensures that the test can immediately follow the development pace in the process of rapid iteration of the project, and can timely discover and prevent potential problems caused by interfaces or interface changes, thereby improving the test efficiency and the quality control level of software.

In an alternative embodiment, before determining the corresponding interface script based on the interface information of the interface, the method comprises the steps of determining a database corresponding to the interface, associating the operation of the interface with the database based on the table information of the database, and determining the information of the interface based on the interface file in the project file.

In the automated test system, it is noted that determining the database corresponding to the interface is the basis for constructing the interface script. This step involves understanding how the interface interacts with the backend database and how data is transferred between the interface and the database. When the system parses the interface source code, it will recognize the SQL statements and entity class information that interact with the database, thereby being able to determine which interfaces are database dependent and their corresponding database tables.

After determining the database corresponding to the interface, the system further analyzes the table structure of the database, including the table name, field name, data type and other information. By identifying the table information, the system is able to establish a connection between the interface operations and the database tables. For example, if an interface is responsible for querying user information, the system may determine that this operation is associated with a user table in the database, thereby ensuring that the script properly performs the database operation and validates the results, taking into account the table structure information when generating the interface script.

It should be noted that, the interface file in the project file is a main source for the automated test system to obtain the detailed information of the interface. These files contain information such as definitions of interfaces, parameters, return values, request paths and methods. By analyzing the files, the automation system can extract all necessary information of the interface and construct a complete model of the interface. This process typically includes identifying the URL of the interface, HTTP methods (GET, POST, PUT, etc.), the data structures of the request and response (JSON, XML, etc. formats), and any necessary authentication or API key information.

In an alternative embodiment, after determining the database associations and interface information for the interfaces, the automated test system will perform association analysis to match the operation of the interfaces to the specific functions of the database tables.

The system can identify which interfaces are involved in the query operation of the database, and generates script fragments for verifying the consistency of the query results of the database according to SQL information and entity class definitions. And analyzing the business logic of the interface, and understanding the rule and flow of the data processed by the interface to ensure that the generated script can accurately simulate and verify the logic. The system can detect data interaction between the interface and the database, identify the flow direction and change of the data, and generate test cases for verifying the correct transmission and processing of the data. Based on the definition of the interface and the database table structure, the system generates an assertion script for verifying whether the content returned by the interface is consistent with the data in the database. For interfaces involving database operations, the system may also generate SQL statements for performing database operations.

According to the embodiment of the application, the automatic test system can generate a comprehensive and accurate interface automatic script based on the interface file and the database information, and ensure that the test can cover all back-end logic and data interaction points, thereby improving the integrity and the effectiveness of the test. Such a mechanism is particularly well suited to projects that are highly dependent on database operations, and can help test teams discover and repair problems in data processing or interface logic in a timely manner. Meanwhile, by associating the interface operation with the database table information, the system can also automatically detect whether the change of the data in the database is correctly processed by the interface, thereby enhancing the depth and breadth of the test and improving the stability and performance of the software.

In an alternative embodiment, generating the target document structure and the target style structure based on the current project file comprises generating a candidate document structure and a candidate style structure based on the content file of the project file, determining information of a front end element in the project file, and updating the candidate document structure and the candidate style structure into the target document structure and the target style structure according to the information of the front end element.

It should be noted that when the automated test system begins to process a project file, it first generates candidate document structures and candidate style structures based on the content files in the project file. The content file typically contains all the HTML, CSS, and JavaScript code that make up the page. The system parses the code to generate preliminary DOM trees (Document Object Model ) and CSSOM trees (CSS Object Model), i.e., candidate document structures and candidate style structures.

The DOM tree describes the HTML structure of the page, the hierarchical relationship and the attribute among the elements are represented by a tree structure, and the CSSOM tree represents the style information of the page, including style rules and the application condition thereof. Candidate structures are generated based on static parsing, and dynamic changes or interaction behaviors of elements are not considered yet.

In an alternative embodiment, the system would identify all front-end elements on the page, including buttons, text boxes, drop-down menus, visual or interactive components such as images, and information whether they call an interface.

It should be noted that the system extracts various attributes of the element, such as ID, class, style, from the DOM/CSSOM tree, and the position and hierarchical relationship of the element in the page. This information is used to generate XPath, a query language used to locate and extract elements and values in an XML document, which is equally applicable in an HTML document. The XPath is a common method for locating page elements in UI automation test, and can ensure the accuracy and stability of test cases.

In alternative embodiments, the system may also recognize the dynamic behavior of the element, e.g., a button may trigger an interface call or page jump. For such elements, the system will further analyze their functional logic and data interactions to ensure that the generated test scripts can cover these behaviors. The system may also identify the role of an element in a particular method or function block, such as searching, logging in, submitting a form, etc.

In an alternative embodiment, based on in-depth analysis of the front-end elements, the system updates the candidate document structure and the candidate style structure to more accurately reflect the actual state and interaction logic of the page. If the attributes of the elements are corrected in the parsing process, for example, the class attribute of an element is found to be misread, the system can correct class information in the DOM tree, and the accuracy of XPath paths and other positioning strategies is ensured. For interactable elements, the system can supplement dynamic behavior information of the interactable elements, such as click events of buttons, change events of input boxes and the like, and the information can be added into a DOM tree as the basis for generating test scripts. If there is dynamically loaded content or layout in the page, the system will recognize these changes and update the DOM and CSSOM structures, ensuring that the structures can reflect the final state of the page, rather than the initial loaded state. Finally, the system generates a "target document structure" and a "target style structure" which contain not only the static content of the page, but also integrate the dynamic behavior and functional logic of the elements. The method is a basic stone generated by an automatic test script, and ensures that the test script can accurately and comprehensively test all the functional points of the page.

Through the embodiment of the application, the automatic test system can intelligently generate the target document structure and the target style structure reflecting the latest state of the project file, provides accurate element information and page structure for subsequent test script generation, and greatly improves the efficiency and accuracy of automatic test. The mechanism is particularly suitable for projects relying on complex front-end interactions, and can help a test team to quickly adapt to the changes of the front-end interface and ensure test coverage and test quality.

In an alternative embodiment, the step of determining the information of the front-end element in the project file comprises the steps of determining that the front-end element is static data and determining a preset value corresponding to the front-end element as input of a test script when the attribute value of the front-end element is defined by the project file, and determining that the front-end element is dynamic data and reading a database corresponding to the front-end element when the attribute value of the front-end element is acquired by an interface.

It should be noted that, when the automation system parses the project file, it will check the attribute value source of each front-end element. If the attribute values (e.g., content, status, options, etc.) of the elements are defined directly in the project file, the system will determine that the elements are static data. Static data means that the presentation content of the element is determined already in the development stage and does not change with the operation of the user or the change of the back-end data. Such as a title or descriptive text fixed on the page. Conversely, if the attribute values of the elements originate from the backend interface, the system may determine that the elements are dynamic data. Dynamic data elements rely on real-time data acquisition, whose presentation content dynamically changes based on the data returned by the backend. Such as article titles in news listings, prompt information in user input boxes, and so forth.

For static data elements, the automation system will extract their preset values in the project file and determine these values as inputs to the test script. For example, a dead-written input box prompt, please enter mailbox, will be recorded by the system as a test input for verifying that the initial status of the input box is correct in the UI automation test. This approach simplifies the preparation of test data because the values of static elements do not require an additional dynamic data source.

For dynamic data elements, the system will read the backend interface information associated therewith. This includes the URL of the interface, request parameters, returned data structures, etc. The system can acquire the processing logic of the interface and the associated database table information by analyzing the content of the back-end interface. For example, a drop-down menu of options may originate from an enumerated type field of the database, which the system recognizes, and then further parses the background code to learn about the table structure and field meaning of the database.

In an alternative embodiment, after determining the interface information for the dynamic data element, the automation system may understand the type and expected value of the data through a table note or back-end entity class note. Such information typically contains descriptions of fields, data formats, valid value ranges, etc., which are critical to generating accurate interface automation scripts. The system may use this information to generate test data that simulates different user scenarios and data states to fully test the display and processing logic of the dynamic data elements. For example, for a form that obtains a list of users from the back-end, the system may generate a combination of various user data, including normal data, abnormal data, boundary condition data, etc., for testing the display logic and data processing capabilities of the form.

Through the process, the automation system can obtain detailed information of all elements on one page, wherein the detailed information comprises preset values of static data elements, interfaces of dynamic data elements and database association. The system integrates this information into a complete page analysis result, including the DOM/CSSOM structure of the element, element attributes, element functions (e.g., click, fill, drop down selections, etc.), data sources (static/dynamic), and back-end interfaces and database information for the dynamic data element.

In an alternative embodiment, the automation system can obtain all element locations on the page directly from the source code (i.e., project file) and can know the source of the data acquisition (static or dynamic data). If it is detected that a certain element is dynamic data, the system further analyzes the related back-end interface to know the logic and data structure of the interface, so as to generate more detailed test cases.

Through the embodiment of the application, the UI automation script can accurately position and operate each element, and the interface automation script can accurately simulate and verify the logic of the back-end data interaction. By the method, the automatic test system can provide highly-covered and highly-targeted test cases for a test team, so that the test quality and efficiency are effectively improved, human errors are reduced, and the period of software development and deployment is shortened.

In an alternative embodiment, the identification of the current project file comprises determining a storage address of the project file, reading a log file of the storage address, and determining that the project file has a change in the condition that the version of the project file is changed in the log file.

It should be noted that the automated test system needs to know the exact storage location of the project file (i.e., front-end and back-end source code), typically the URL of the Git repository. In setting up a test device, the Git address of an item must be entered in order for the device to be able to access and download the source code. This step ensures that the testing device has direct access to the latest code base of the project, providing the basis for subsequent code downloads and analysis.

When the device runs for the first time, the latest snapshot of the project source codes is automatically downloaded. At the same time, it will read the log file of the Git repository, which is commonly referred to as the Git's commit history. The log file contains the time stamp, submitter, submission message and change content of each code submission, which is an important tool for tracking the version change of the project file. To continuously monitor the dynamics of project files, the test equipment periodically checks the log files of the Git warehouse. It compares the time stamp recorded at the last check with the current time stamp and the corresponding warehouse status. If there is a new commit record in this period of time, i.e. additional version information is present in the log file, this means that there may be a change to the project file.

In an alternative embodiment, after detecting a version change in the log file, the test device may go deep into checking for specific changes, including the addition or deletion of the file. It downloads or takes a snapshot of these altered code and then compares it to the previously saved "benchmark" code. If the code is found to have an actual change, such as a function overwrite, a variable addition or deletion, or an interface layout adjustment, the device can confirm that the project file has indeed changed.

Once the system determines that there is a change to the project file, it will immediately initiate the update flow of the automation script. This includes re-downloading the source code, parsing the altered code to generate a new DOM/CSSOM structure, identifying newly added or modified elements and interface calls, and then generating or updating an automation test script based on this information to reflect the latest project state. At the same time, the device will record the time to update the script for subsequent version control and timeline tracking.

By the above embodiment of the application, the integrity and accuracy of the test can be ensured even under the conditions of frequent iteration of the project and fast-paced updating of the code. The test system effectively reduces the workload of manually updating scripts by a tester, improves the test efficiency, reduces the risk of test omission caused by code change, and provides a reliable test support mechanism for continuous integration and continuous delivery (CI/CD) of software.

After the automated test script is obtained, the script needs to be executed and the result is verified. The automated test system first executes the automation scripts generated in the process described above, including UI automation scripts and API automation scripts. The UI automation script simulates interaction between a user and an interface, such as clicking a button, filling in a form and the like, and the API automation script directly calls a back-end interface, sends a request and receives a response, and detects whether logic and data processing of the interface are correct.

In an alternative embodiment, the system may parse the background code data obtained in the project file, particularly those related to the test case, while the automation script is executing. This may include information such as records read from the database, data formats returned by the interface, expected response codes, etc. After the automated script is executed, the system compares the output result of the script with the parsed background code data. For example, if an automated script simulates a user logging in and querying the balance of an account, the system will verify that the returned balance value matches the balance of the corresponding account in the database. If the data comparison is consistent, the result is considered to be passed, i.e., the test case was successfully executed. If the data contrast is inconsistent, the result is considered a failure, suggesting a potential back-end logic error or data processing exception.

If all of the aligned data points are expected, the test case will be marked as successful, which means that the execution of the automation script remains consistent with the data processing of the back-end code, and the behavior of the software is correct within the test scope. Conversely, if any data mismatch is found, the test case will be marked as failed, requiring further investigation, repair of code or update of automation scripts to ensure the reliability and stability of the software.

It should be noted that after the test result is obtained, the test result may also be stored and displayed.

In an alternative embodiment, the automated test system saves the execution results, including passing test cases and failed test cases, as well as specific failure causes and log information, to a local database. This not only records the history of the test, but also provides a data base for subsequent data analysis and problem tracking. The system may store and display these test results via a visual interface. The information in the database may be collated and formatted for presentation to test teams and developers in the form of charts, lists, or detailed reports. Therefore, a user can quickly know the testing state of the software, including overall testing coverage rate, passing rate, detailed information of failed use cases and the like, so that team can quickly locate and solve problems, and meanwhile, data support and decision basis are provided for continuous improvement of projects.

Through the embodiment, the automatic test system not only can automatically execute the test to verify the functions and logic of the software, but also can store and display the test result in a structured way, thereby providing an efficient and accurate software quality control method and effectively supporting the continuous integration and continuous delivery flow in the software development.

It should be noted that, for simplicity of description, the foregoing method embodiments are all described as a series of acts, but it should be understood by those skilled in the art that the present application is not limited by the order of acts described, as some steps may be performed in other orders or concurrently in accordance with the present application. Further, those skilled in the art will also appreciate that the embodiments described in the specification are all preferred embodiments, and that the acts and modules referred to are not necessarily required for the present application.

According to another aspect of the embodiment of the present application, there is also provided an automated test script generating apparatus for implementing the above-described automated test script generating method. As shown in fig. 3, the apparatus includes:

A structure generating unit 302, configured to identify a current project file, and generate, based on the current project file, a target document structure and a target style structure in the event that there is a change in the project file, where the target document structure is used to indicate the content of the current project file, and the target style structure is used to indicate the style of the current project file;

a structure comparing unit 304 for comparing the target document structure with the reference document structure, the target pattern structure and the reference pattern structure, respectively;

and a script updating unit 306, configured to update, when there is a changed front-end element between the target document structure and the reference document structure and/or between the target style structure and the reference style structure, a test script corresponding to the project file based on the changed front-end element, where the front-end element is used to indicate an element that can be interacted or visible in the project file.

Optionally, the script updating unit 306 includes a first script updating module configured to update the test script based on the target document structure and the target style structure when there is a structural change between the target document structure and the reference document structure, the target style structure, and the reference style structure, or when there is a changed front-end element as a key element, where the key element is used to indicate a core function in the project file, and a second script updating module configured to update the test script based on the changed front-end element when there is a changed front-end element as a normal element between the target document structure and the reference document structure, the target style structure, and the reference style structure, where the normal element is used to indicate an auxiliary function in the project file.

Optionally, the script updating unit 306 includes a test instruction generating module for determining a corresponding test instruction based on element information included in the front-end element, an interface script generating module for determining a corresponding interface script based on interface information of the interface when the front-end element includes the interface, and a hybrid script updating module for updating the test script corresponding to the project file according to the test instruction and the interface script.

Alternatively, the structure generating unit 302 includes a structure generating module for generating a candidate document structure and a candidate style structure based on a content file of a project file, and a structure updating module for determining information of a front element in the project file and updating the candidate document structure and the candidate style structure into a target document structure and a target style structure according to the information of the front element.

Optionally, the structure generating unit 302 further includes a file identifying module, configured to determine a storage address of the project file, and read a log file of the storage address, and determine that there is a change in the project file if a change in the version of the project file is recorded in the log file.

Alternatively, in this embodiment, the embodiments to be implemented by each unit module may refer to the embodiments of each method described above, which are not described herein again.

According to still another aspect of the embodiment of the present application, there is also provided an electronic device for implementing the above-mentioned automated test script generating method, which may be a terminal device or a server as shown in fig. 4. The present embodiment is described taking the electronic device as a terminal device as an example. As shown in fig. 4, the electronic device comprises a memory 402 and a processor 404, the memory 402 having stored therein a computer program, the processor 404 being arranged to perform the steps of any of the method embodiments described above by means of the computer program.

Alternatively, in this embodiment, the electronic device may be located in at least one network device of a plurality of network devices of the computer network.

Alternatively, in the present embodiment, the above-described processor may be configured to execute the following steps by a computer program:

S1, identifying a current project file, and generating a target document structure and a target style structure based on the current project file under the condition that the project file is changed, wherein the target document structure is used for indicating the content of the current project file, and the target style structure is used for indicating the style of the current project file;

s2, respectively comparing the target document structure with the reference document structure, the target pattern structure and the reference pattern structure;

And S3, under the condition that a changed front-end element exists between the target document structure and the reference document structure and/or between the target style structure and the reference style structure, updating the test script corresponding to the project file based on the changed front-end element, wherein the front-end element is used for indicating an interactable or visible element in the project file.

Alternatively, it will be understood by those skilled in the art that the structure shown in fig. 4 is only schematic, and the electronic device may also be a terminal device such as a smart phone (such as iOS, android phones, etc.), a tablet computer, a palm computer, and a Mobile internet device (Mobile INTERNET DEVICES, MID), a PAD, etc. Fig. 4 is not limited to the structure of the electronic device and the electronic apparatus described above. For example, the electronics can also include more or fewer components (e.g., network interfaces, etc.) than shown in FIG. 4, or have a different configuration than shown in FIG. 4.

The memory 402 may be used to store software programs and modules, such as program instructions/modules corresponding to the method and apparatus for generating an automated test script in the embodiments of the present application, and the processor 404 executes the software programs and modules stored in the memory 402 to perform various functional applications and data processing, that is, implement the method for generating an automated test script. Memory 402 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 402 may further include memory located remotely from processor 404, which may be connected to the terminal via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof. The memory 402 may be used to store project files, test scripts, etc. in particular, but not limited to. As an example, as shown in fig. 4, the memory 402 may include, but is not limited to, the structure generating unit 302, the structure comparing unit 304, and the script updating unit 306 in the automated test script generating apparatus. In addition, other module units in the automatic test script generating apparatus may be included, but are not limited to, and are not described in detail in this example.

Optionally, the transmission device 406 is used to receive or transmit data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission means 406 includes a network adapter (Network Interface Controller, NIC) that can be connected to other network devices and routers via a network cable to communicate with the internet or a local area network. In one example, the transmission device 406 is a Radio Frequency (RF) module for communicating with the internet wirelessly.

The electronic device further includes a display 408 for displaying test results and the like, and a connection bus 410 for connecting the respective module parts in the electronic device.

In other embodiments, the terminal device or the server may be a node in a distributed system, where the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting the plurality of nodes through a network communication. Among them, the nodes may form a Peer-To-Peer (P2P) network, and any type of computing device, such as a server, a terminal, etc., may become a node in the blockchain system by joining the Peer-To-Peer network.

According to one aspect of the present application, there is provided a computer program product comprising a computer program/instruction containing program code for executing the method shown in the flow chart. In such embodiments, the computer program may be downloaded and installed from a network via a communication portion, and/or installed from a removable medium. When executed by a central processing unit, performs various functions provided by embodiments of the present application.

The foregoing embodiment numbers of the present application are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments.

According to one aspect of the present application, there is provided a computer-readable storage medium, from which a processor of a computer device reads the computer instructions, the processor executing the computer instructions, causing the computer device to perform the above-described automated test script generation method.

Alternatively, in the present embodiment, the above-described computer-readable storage medium may be configured to store a computer program for performing the steps of:

Alternatively, in this embodiment, all or part of the steps in the various methods of the above embodiments may be implemented by a program for instructing the terminal device related hardware, and the program may be stored in a computer readable storage medium, where the storage medium may include a flash disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk.

The integrated units in the above embodiments may be stored in the above-described computer-readable storage medium if implemented in the form of software functional units and sold or used as separate products. Based on such understanding, the technical solution of the present application may be embodied in essence or a part contributing to the prior art or all or part of the technical solution in the form of a software product stored in a storage medium, comprising several instructions for causing one or more computer devices (which may be personal computers, servers or network devices, etc.) to perform all or part of the steps of the above-described method of the various embodiments of the present application.

In the foregoing embodiments of the present application, the descriptions of the embodiments are emphasized, and for a portion of this disclosure that is not described in detail in this embodiment, reference is made to the related descriptions of other embodiments.

In several embodiments provided by the present application, it should be understood that the disclosed client may be implemented in other manners. The above-described embodiments of the apparatus are merely exemplary, and the division of the units, such as the above, is merely a logical function division, and may be implemented in another manner, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be through some interfaces, units or modules, or may be in electrical or other forms.

The units described above as separate components may or may not be physically separate, and components shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

While the foregoing is directed to the preferred embodiments of the present application, it will be appreciated by those skilled in the art that changes and modifications may be made without departing from the principles of the application, and such changes and modifications are intended to be included within the scope of the application.

Claims

1. A method for generating automated test scripts, characterized in that it includes:

The current project file is identified. If the project file has been changed, a target document structure and a target style structure are generated based on the current project file. The target document structure is used to indicate the content of the current project file, and the target style structure is used to indicate the style of the current project file.

Compare the target document structure with the reference document structure, and the target style structure with the reference style structure respectively;

In the event that there are changing front-end elements between the target document structure and the reference document structure and/or between the target style structure and the reference style structure, the test script corresponding to the project file is updated based on the changing front-end elements, wherein the front-end elements are used to indicate interactive or visual elements in the project file.

2. The method according to claim 1, wherein updating the test script corresponding to the project file based on the changed front-end elements includes:

If there are structural changes between the target document structure and the reference document structure, or between the target style structure and the reference style structure, or if the changed front-end element is a key element, the test script is updated based on the target document structure and the target style structure, wherein the key element is used to indicate the core function in the project file;

If the front-end element that changes between the target document structure and the reference document structure, and between the target style structure and the reference style structure, is a normal element, the test script is updated based on the changed front-end element, wherein the normal element is used to indicate the accessibility functions in the project file.

3. The method according to claim 2, wherein updating the test script corresponding to the project file based on the changed front-end elements includes:

The corresponding test instructions are determined based on the element information included in the front-end elements;

If the front-end element includes an interface, the corresponding interface script is determined based on the interface information of the interface.

Update the test scripts corresponding to the project files according to the test instructions and interface scripts.

4. The method according to claim 3, characterized in that, before determining the corresponding interface script based on the interface information of the interface, it includes:

Determine the database corresponding to the interface, and associate the operation of the interface with the database based on the table information of the database;

Based on the interface file in the project file, determine the information of the interface.

5. The method according to claim 1, characterized in that, generating the target document structure and target style structure based on the current project file includes:

Based on the content file of the project file, generate candidate document structure and candidate style structure;

Determine the information of the front-end elements in the project file, and update the candidate document structure and candidate style structure to the target document structure and target style structure based on the information of the front-end elements.

6. The method according to claim 5, wherein determining the information of the front-end elements in the project file includes:

If the attribute value of the front-end element is defined in the project file, the front-end element is determined to be static data, and the preset value corresponding to the front-end element is determined as the input of the test script.

If the attribute value of the front-end element is obtained from the interface, the front-end element is determined to be dynamic data, and the database corresponding to the front-end element is read.

7. The method according to any one of claims 1 to 6, characterized in that, the step of identifying the current project file includes:

Determine the storage location of the project files and read the log file at that storage location;

If the log file records a version change of the project file, it is determined that the project file has been modified.

8. An automated test script generation device, characterized in that it comprises:

The structure generation unit is used to identify the current project file, and, if the project file has been changed, to generate a target document structure and a target style structure based on the current project file. The target document structure is used to indicate the content of the current project file, and the target style structure is used to indicate the style of the current project file.

The structural comparison unit is used to compare the target document structure with the reference document structure, and the target style structure with the reference style structure, respectively.

The script update unit is used to update the test script corresponding to the project file based on the changed front-end elements when there are changed front-end elements between the target document structure and the reference document structure and/or between the target style structure and the reference style structure, wherein the front-end elements are used to indicate interactive or visual elements in the project file.

9. A computer program product comprising a computer program/instructions, characterized in that, when executed by a processor, the computer program/instructions implement the method described in any one of claims 1 to 7.

10. An electronic device comprising a memory and a processor, characterized in that the memory stores a computer program, and the processor is configured to perform the method of any one of claims 1 to 7 via the computer program.