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

Abstract

The invention discloses an automatic test script generation method and device, a storage medium and electronic equipment. Comprising the steps that a current project file is recognized, under the condition that the project file is changed, a target document structure and a target style structure are generated based on the current project file, 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; comparing the target document structure with the reference document structure, and comparing the target style structure with the reference style structure; under the condition that changed front-end elements exist 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 changed front-end elements, and the front-end elements are used for indicating interactive or visual elements in the project file. The technical problem that an automatic test script generation method provided by the related technology is low in updating efficiency is solved.

Description

Technical Field

[0001] This application relates to the technical field of automated test script generation, and more specifically, to an automated test script generation method and apparatus, storage medium and electronic device. Background Technology

[0002] During the testing of a project, automated test scripts that simulate user operations and behaviors in the software application are often used to replace repetitive manual testing processes.

[0003] In related technologies, testers typically write scripts manually before using automated scripts, and these scripts need to be maintained when developers modify the project. If multiple consecutive urgent releases are not updated, some automated scripts may not be updated in time, leading to incorrect test results. In other words, the automated test script generation methods provided by related technologies suffer from low update efficiency.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides an automated test script generation method and apparatus, storage medium and electronic device, to at least solve the technical problem of low update efficiency in the automated test script generation methods provided by related technologies.

[0006] According to one aspect of the embodiments of this application, an automated test script generation method is provided, comprising: identifying a current project file; generating a target document structure and a target style structure based on the current project file when the project file has been changed, wherein 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; comparing the target document structure with a reference document structure and the target style structure with a reference style structure respectively; and updating 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.

[0007] According to another aspect of the embodiments of this application, an automated test script generation apparatus is also provided, comprising: a structure generation unit, configured to identify a current project file, and, in the event of changes to the project file, generate a target document structure and a target style structure based on the current project file, wherein the target document structure indicates the content of the current project file and the target style structure indicates the style of the current project file; a structure comparison unit, configured to compare the target document structure with a reference document structure and the target style structure with a reference style structure respectively; and a script update unit, configured to update the test script corresponding to the project file based on the changed front-end elements in the event of changes 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 indicate interactive or visual elements in the project file.

[0008] Optionally, the above-mentioned script update unit includes: a first script update module, used to update the test script based on the target document structure and target style structure when 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 when the changed front-end element is a key element, wherein the key element is used to indicate the core function in the project file; and a second script update module, used to update the test script based on the changed front-end element when there are changed front-end elements between the target document structure and the reference document structure, or between the target style structure and the reference style structure, and the changed front-end element is a regular element, wherein the regular element is used to indicate auxiliary functions in the project file.

[0009] Optionally, the script update unit includes: a test instruction generation module, used to determine the corresponding test instruction based on the element information included in the front-end element; an interface script generation module, used to determine the corresponding interface script based on the interface information when the front-end element includes an interface; and a hybrid script update module, used to update the test script corresponding to the project file according to the test instruction and the interface script.

[0010] Optionally, the above-mentioned interface script generation module is also used to: 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; and determine the information of the interface based on the interface file in the project file.

[0011] Optionally, the above-mentioned structure generation unit includes: a structure generation module, used to generate candidate document structures and candidate style structures based on the content files of the project file; and a structure update module, used to determine the information of the front-end elements in the project file, and update the candidate document structures and candidate style structures to the target document structure and target style structure according to the information of the front-end elements.

[0012] Optionally, the aforementioned structure update module is also used to determine that the front-end element is static data when the attribute value of the front-end element is defined in the project file, and to determine the preset value corresponding to the front-end element as the input of the test script; and to determine that the front-end element is dynamic data when the attribute value of the front-end element is obtained from the interface, and to read the database corresponding to the front-end element.

[0013] Optionally, the above-mentioned structure generation unit further includes: a file recognition module, used to determine the storage address of the project file and read the log file of the storage address; if the log file records changes to the project file version, it is determined that the project file has been changed.

[0014] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, and the computer program is configured to execute the above-described automated test script generation method at runtime.

[0015] According to another aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program / instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer program / instructions from the computer-readable storage medium, and executes the computer program / instructions, causing the computer device to perform the automated test script generation method described above.

[0016] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-described automated test script generation method through the computer program.

[0017] In this embodiment, the current project file is identified. If the project file has changed, a target document structure and a target style structure are generated based on the current project file. The target document structure indicates the content of the current project file, and the target style structure indicates the style of the current project file. The target document structure is compared with the reference document structure, and the target style structure is compared with the reference style structure. If there are changed front-end elements between the target document structure and the reference document structure, or between the target style structure and the reference style structure, the test script corresponding to the project file is updated based on the changed front-end elements. Front-end elements indicate interactive or visual elements in the project file. By monitoring changes to the project file in real time, the automated testing system can automatically identify and update the test script without manual intervention. When the project file changes, the system generates a new target document structure and a target style structure, intelligently compares them with the reference structure, and automatically identifies the changed front-end elements. This process significantly saves testers' script maintenance time after code iteration, reduces human error, and improves the accuracy and timeliness of the test script. Therefore, the above method solves the technical problem of low update efficiency in automated test script generation methods provided by related technologies. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0019] Figure 1 This is a schematic diagram of the hardware environment for an optional automated test script generation method according to an embodiment of this application;

[0020] Figure 2 This is a flowchart of an optional automated test script generation method according to an embodiment of this application;

[0021] Figure 3 This is a schematic diagram of an optional automated test script generation device according to an embodiment of this application;

[0022] Figure 4 This is a schematic diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0023] 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 skilled in the art without creative effort should fall within the scope of protection of the present application.

[0024] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] According to one aspect of the embodiments of this application, an automated test script generation method is provided. As an optional implementation, the above-described automated test script generation method can be applied to, but is not limited to, [examples of other methods]. Figure 1 The hardware environment shown includes an automated test script generation system. This automated test script generation system may include, but is not limited to, terminal device 102, network 110, server 112, and database 114. Terminal device 102 runs a target program (such as...). Figure 1 As shown, taking the target program as an example of a program that can automatically test projects. The terminal device 102 includes a display 108, a processor 106, and a memory 104. The display 108 can be used to display pages under different working conditions, and also to provide a human-computer interaction interface to receive human-computer interaction operations such as touch input for different information. The processor is used to generate interaction instructions in response to the above-mentioned human-computer interaction operations, and send the interaction instructions to the server to obtain project files, etc. The memory is used to store image data and text data, etc., of the target page displayed by the running client.

[0026] In addition, server 112 includes a processing engine 116, which is used to perform store or read operations on database 114. Specifically, processing engine 116 reads project files from database 114.

[0027] Assumption Figure 1The terminal device 102 runs a program for automating UI testing. The specific process in this embodiment is as follows: As in step S102, the terminal device 102 requests the project file to be tested from the server 112 through the network 110. The terminal device 102 may be one or more devices. After receiving the request from the terminal device 102, the server 112 retrieves the project file from the database 114 and sends the project file to the terminal device 102 to automatically test the project file.

[0028] After receiving the project file to be tested, the terminal device 102 executes steps S104-S108 to identify the current project file. 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 indicates the content of the current project file, and the target style structure indicates the style of the current project file. The target document structure is compared with the reference document structure, and the target style structure is compared with the reference style structure. If 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, the test script corresponding to the project file is updated based on the changed front-end elements.

[0029] Optionally, in this embodiment, the terminal device 102 can be a terminal device configured with a target program, which may include, but is not limited to, at least one of the following: mobile phone (such as iOS, Android phone, etc.), laptop computer, tablet computer, PDA, MID (Mobile Internet Devices), PAD, desktop computer, smart TV, etc. The client can be a video client, a testing client, or a client that supports providing automated test script generation tasks or can access the target page. The network may include, but is not limited to, wired networks and wireless networks. The wired network includes local area networks (LANs), metropolitan area networks (MANs), and wide area networks (WANs). The wireless network includes Bluetooth, Wi-Fi, and other networks that enable wireless communication. The server can be a single server, a server cluster consisting of multiple servers, or a cloud server. The above is merely an example, and no limitations are imposed in this embodiment.

[0030] Optionally, in this embodiment, the above-described automated test script generation method can be applied to, but is not limited to, the test client. Starting from source code analysis, it can dynamically generate UI automation scripts, continuously monitor code updates, and automatically identify and adapt to UI changes, thereby ensuring the comprehensiveness and effectiveness of the automated test scripts. This not only significantly reduces the script writing and maintenance costs for testers but also improves test coverage and efficiency. Using the method of this application, the testing team can focus more on high-value test design and defect analysis, while delegating the highly repetitive script generation and updating work to automated testing devices, thereby accelerating the software development and deployment cycle. The automated script generation method applied to the test client not only covers the scope of traditional functional testing but also delves into the dynamic changes and visual effects testing of the user interface, providing a comprehensive testing solution for ensuring high-quality video applications. This method is particularly suitable for the development of modern mobile applications that require frequent iteration and optimization of the user interface, significantly improving testing efficiency, shortening the development cycle, and enhancing user satisfaction without sacrificing testing accuracy.

[0031] In this embodiment, the current project file is identified. If the project file has changed, a target document structure and a target style structure are generated based on the current project file. The target document structure indicates the content of the current project file, and the target style structure indicates the style of the current project file. The target document structure is compared with the reference document structure, and the target style structure is compared with the reference style structure. If there are changed front-end elements between the target document structure and the reference document structure, or between the target style structure and the reference style structure, the test script corresponding to the project file is updated based on the changed front-end elements. Front-end elements indicate interactive or visual elements in the project file. By monitoring changes to the project file in real time, the automated testing system can automatically identify and update the test script without manual intervention. When the project file changes, the system generates a new target document structure and a target style structure, intelligently compares them with the reference structure, and automatically identifies the changed front-end elements. This process significantly saves testers' script maintenance time after code iteration, reduces human error, and improves the accuracy and timeliness of the test script. Therefore, the above method solves the technical problem of low update efficiency in automated test script generation methods provided by related technologies.

[0032] As an optional implementation method, such as Figure 2 As shown, the above-mentioned automated test script generation method includes the following steps:

[0033] S202, Identify the current project file, and if the project file has been changed, 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.

[0034] It's important to note that project files refer to all relevant files that make up the front-end application, including HTML, CSS, JavaScript, and Vue / React component files. The automated system first needs to identify these files, analyzing the structure, functional modules, and style definitions of each page. For some modern front-end frameworks that use templates and components (such as Vue and React), the system not only needs to parse individual HTML files but also understand the complex logic within components and the reference relationships between components in order to generate an accurate DOM / CSSOM structure.

[0035] The target document structure, which can be the target DOM structure, is a tree-like structure representing the hierarchical relationship of HTML tags generated by the automated system based on the current project file. This structure reflects the position and hierarchy of all visible elements on the page, including text, images, buttons, forms, etc. For simple pages that directly generate the DOM structure, the system can directly parse the HTML file to generate the DOM tree. However, for complex pages based on templates and components, the system needs to perform multi-step parsing. First, it parses the component files and templates to construct the initial framework of the DOM tree. Then, based on the actual references and nesting of components, it gradually refines the details of the DOM tree to ensure that each level of DOM node accurately reflects the real-time state of the page.

[0036] The target style structure, or target CSSOM structure, is a hierarchical structure of selectors generated by the automation system based on CSS rules in the project files. The CSSOM tree shows how CSS rules are applied to specific DOM nodes, including inheritance, overriding, and priority relationships. For complex front-end projects, styles are often scattered across multiple CSS files or inline styles within components. The automation system must be able to merge these different style rules to create a global CSSOM tree, ensuring that the styles of each element are correctly identified and applied. This means the system must be able to identify which CSS rules affect a specific element and how those rules are applied.

[0037] In an optional implementation, when project files (HTML, CSS, or JS files) change, the automation system immediately re-executes step S202. It re-identifies and parses all affected files, generating a new target document structure and target style structure. This process automatically detects added, modified, or deleted elements and styles, ensuring the test scripts remain consistent with the latest state of the project. For example, if the color or position of a button changes, the automation system will detect the corresponding change in the CSSOM and update the element positioning and style validation rules in the test script.

[0038] Through the above steps, the automated testing system can generate documents and style structures that accurately reflect the current state of the project, ensuring the effectiveness and accuracy of test scripts, thereby improving the overall efficiency and quality of testing. This method is particularly suitable for front-end projects that iterate frequently and change rapidly, effectively reducing the test maintenance costs caused by code changes and improving the work efficiency of the development team.

[0039] S204, compare the target document structure with the reference document structure, and the target style structure with the reference style structure respectively;

[0040] As mentioned earlier, the target document structure is a DOM tree structure generated by the automated testing system based on the current project files. It reflects the latest state of all visible elements in the current project, including the element type, ID, class name, position, and hierarchical relationship between them. The reference document structure can be a DOM tree generated based on a previous version of the project files, storing the previous state of the project.

[0041] In step S204, the system compares these two structures layer by layer, detecting any added, modified, or deleted elements in the DOM tree. This comparison is not limited to the elements themselves, but also includes the elements' attributes and hierarchical relationships. For example, the system checks whether new elements have been added to the page, whether existing elements have changed attributes (such as class, style, or data attributes), or whether the element hierarchy has been adjusted. These changes are marked by the system as a basis for testing script updates.

[0042] As mentioned earlier, the target style structure is the CSSOM tree of the current project file. It describes the application of all CSS rules and their selectors on the DOM tree, including inline styles, external stylesheets, and component-level styles. The reference style structure can be the CSSOM tree of a previous version of the project file. When comparing these two structures, the system checks for changes to style rules, including the addition of new rules, modifications to rules (such as changes to color, size, and position), and the deletion of rules. Furthermore, the system verifies whether the priority and inheritance relationships of style rules have changed, as these changes can affect the final rendering of elements' styles.

[0043] Through the above structural comparison, the automated testing system can intelligently identify which front-end elements and styles have undergone changes. For front-end elements that have changed, the system updates the corresponding test scripts to ensure that test cases can accurately locate and manipulate these elements. For example, if an element's ID changes, the system updates the location statements in the script based on the old ID. For style changes, the system updates the style verification points in the script to ensure that test cases can correctly verify the appearance and layout of the elements. This comparison process is automated; when the system detects changes in the project files, it immediately performs a structural comparison and automatically updates the test scripts based on the comparison results. This mechanism ensures the real-time performance and accuracy of the test scripts, avoiding errors and delays caused by manual script updates, thereby significantly improving testing efficiency and quality.

[0044] S206, In the case where 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.

[0045] It's important to note that S204 identifies any changes to interactive or visual front-end elements in the project file by comparing the target document structure (DOM tree) and target style structure (CSSOM tree) with the reference structure. These changes may include adding or deleting elements, modifying attributes, changing styles, or adjusting hierarchy. The automated system records these update points, including updated element IDs, class names, attributes, styles, and their positions within the DOM / CSSOM structure.

[0046] In an optional implementation, the system matches detected update points with existing automated test scripts to analyze how the update affects script execution. If the update point matches a location statement or operation instruction in the test script, the system automatically adjusts the relevant parts of the script to ensure that the script can still correctly locate and operate the updated elements. For example, if a button's ID changes, the system updates the click operation in the script to point to the new ID. Furthermore, for incremental updates (i.e., newly added elements or functions), the system performs more detailed processing. It analyzes the attributes, styles, and functions of the new element, generating corresponding test cases to test whether the behavior and appearance of the new element meet expectations.

[0047] In an optional implementation, based on the analysis of changed front-end elements, the system automatically optimizes test scripts, including UI automation scripts and API automation scripts. It updates element locators (such as XPath and CSS selectors), operation instructions (such as clicking or filling in form data), and assertions (verifying element states or backend API responses) in the scripts. For UI automation scripts, the system ensures that the scripts can accurately identify and manipulate updated elements; for example, updating the element's XPath path or Class attribute to adapt to changes in the DOM structure. For API automation scripts, if the logic or data model of the backend API changes, the system adjusts the test data and expected results in the scripts accordingly to ensure the effectiveness and accuracy of the tests.

[0048] In an optional implementation, if the update involves new elements or functionalities, the system will execute an incremental update mechanism. This means the system will generate a new set of test cases specifically for testing these new additions. The generation of these new test cases is based on an in-depth analysis of the new elements, including their functional logic, data interactions, and their relationship with the user interface. Through the incremental update mechanism, the system can quickly adapt to project changes, ensuring test coverage while avoiding unnecessary modifications to existing test cases, thereby improving testing efficiency and accuracy.

[0049] In this embodiment, the current project file is identified. If the project file has changed, a target document structure and a target style structure are generated based on the current project file. The target document structure indicates the content of the current project file, and the target style structure indicates the style of the current project file. The target document structure is compared with the reference document structure, and the target style structure is compared with the reference style structure. If there are changed front-end elements between the target document structure and the reference document structure, or between the target style structure and the reference style structure, the test script corresponding to the project file is updated based on the changed front-end elements. Front-end elements indicate interactive or visual elements in the project file. By monitoring changes to the project file in real time, the automated testing system can automatically identify and update the test script without manual intervention. When the project file changes, the system generates a new target document structure and a target style structure, intelligently compares them with the reference structure, and automatically identifies the changed front-end elements. This process significantly saves testers' script maintenance time after code iteration, reduces human error, and improves the accuracy and timeliness of the test script. Therefore, the above method solves the technical problem of low update efficiency in automated test script generation methods provided by related technologies.

[0050] In an optional implementation, updating the test script corresponding to the project file based on the changed front-end elements includes: updating the test script based on the target document structure and target style structure when 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 when the changed front-end element is a key element, wherein the key element is used to indicate the core functions in the project file; and updating the test script based on the changed front-end element when the changed front-end element between the target document structure and the reference document structure, or between the target style structure and the reference style structure, is a regular element, wherein the regular element is used to indicate auxiliary functions in the project file.

[0051] It's important to note that in the update strategy for automated test scripts, global updates and incremental updates are two methods for updating the test scripts corresponding to the project files based on changes in front-end elements. The following is a detailed explanation of this strategy:

[0052] A global update is an update strategy executed when there are significant structural changes 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 changed front-end element is a critical element. Critical elements are those that have a significant impact on page functionality, user interaction, or important business logic. Changes to these elements may affect the execution of multiple test cases, thus requiring a global script update.

[0053] In an optional implementation, during the global update process, the automated system first identifies structural changes in the DOM tree and CSSOM tree, including the addition, deletion, repositioning, and attribute changes of elements. If significant structural changes are detected, or key elements are altered, the global update process is initiated. Then, based on the new target document structure and target style structure, the system re-evaluates the element positioning strategies, operation instructions, and assertion conditions in the test script. This may require adjusting or refactoring the entire script to ensure it correctly reflects the latest front-end state. For changes to key elements, the system generates or updates a series of test cases to ensure that all critical functions and interaction points are covered by the tests.

[0054] Incremental updates are an update strategy performed when changes occur between front-end elements in the target and reference document structures and / or the target and reference style structures, but these elements are considered ordinary elements. Ordinary elements refer to those that have a minimal impact on page functionality or are not critical paths in the test. If only these elements change, it usually will not affect the execution flow of the entire test script, thus allowing for more localized script updates.

[0055] In an optional implementation, during incremental updates, the system automatically identifies common elements that have changed in the DOM tree and CSSOM tree, including attribute changes, position adjustments, etc., but without involving a complete structural reorganization. Then, based on the changed front-end elements, the system only updates the parts of the test script relevant to these changes. For example, if the class name of a common element changes, the system updates the CSS selectors in the script to accommodate the new class name without affecting other parts of the script. For test cases involving changes to common elements, the system fine-tunes to ensure the test cases remain valid. This may involve updating the input data, expected output, or assertions in the test cases to reflect the latest state of the elements.

[0056] It's important to note that global updates typically involve more comprehensive and in-depth script modifications, making them more time-consuming, while incremental updates only adjust the changed parts, resulting in higher efficiency. Furthermore, global updates have a significant impact on the entire testing framework, potentially requiring recompilation or a rebuild of the testing environment; incremental updates have a smaller impact, affecting only specific test cases or script sections. Global update strategies are more suitable for front-end refactoring or critical feature changes; incremental update strategies are better suited for minor fixes or optimizations.

[0057] Through the above-described embodiments of this application, combining global update and incremental update strategies, the automated testing system can respond more flexibly and efficiently to changes in project files, ensuring the accuracy of test scripts and the continuity of the testing process, while reducing test maintenance costs and improving the productivity of the testing team. This strategy is particularly suitable for the agile iteration model common in modern software development, and can quickly adapt to rapidly changing front-end environments.

[0058] In an optional implementation, updating the test script corresponding to the project file based on the changed front-end elements includes: determining the corresponding test instructions based on the element information included in the front-end elements; determining the corresponding interface script based on the interface information when the front-end elements include interfaces; and updating the test script corresponding to the project file according to the test instructions and the interface script.

[0059] It's important to note that when changes are detected in the front-end interface, the first step is to analyze the attributes of these elements and the modules or methods they belong to. For example, if an input field's ID changes, or a button's position moves, the automation system will determine the corresponding test instructions based on this changed element information. Test instructions may include, but are not limited to: clicking an element, filling an input field, selecting a dropdown menu option, verifying the existence or visibility of an element, etc. These instructions form the basis of the test script, used to simulate user interaction and verify element states.

[0060] Some front-end element operations may involve interaction with back-end interfaces, such as clicking a search button to initiate a search request. The automation system needs to identify the association between these elements and the back-end interfaces, parse the interface parameters, methods, URLs, and other information, and then generate corresponding interface automation scripts. These scripts are responsible for simulating communication with the back-end service, sending requests, and verifying responses to ensure the correctness of front-end and back-end collaboration.

[0061] In an optional implementation, when a change in the DOM / CSSOM structure or element attributes is detected, the automation system first generates updated test instructions based on the new element information and module methods. This may mean modifying existing instructions or adding new instructions related to the new element to adapt to the latest state of the front-end interface. If the changed front-end element involves a back-end interface, the system generates or updates the corresponding interface scripts, including the data format of the interface request and the verification of the expected response. For example, when the data source for a dropdown menu's options changes from static to dynamic (i.e., obtained from a back-end interface), the system will automatically generate an interface request script to obtain the latest option list. Using the updated test instructions and interface scripts, the system refactors the affected test cases. This includes the integrated processing of UI automation scripts and API automation scripts. For example, for test cases of the search function, the system can generate five UI automation scripts (corresponding to input box processing, dropdown box processing, and click operations, respectively), one interface automation script (handling search interface queries), and one combined test case covering the verification of all UI operations and interface calls. When the DOM / CSSOM structure changes, the relevant test cases are regenerated to ensure compatibility and coverage with the new structure.

[0062] Through the embodiments described above in this application, the automated testing system can intelligently identify changes in front-end elements and generate and update test scripts accordingly. This includes not only interactive testing of the user interface but also automated testing of related interfaces. This approach ensures that testing keeps pace with development during rapid project iterations, promptly identifying and preventing potential problems caused by interface or API changes, thereby improving testing efficiency and software quality control.

[0063] In an optional implementation, before determining the corresponding interface script based on the interface information, the process includes: determining the database corresponding to the interface, and associating the interface operation with the database based on the table information of the database; and determining the interface information based on the interface file in the project file.

[0064] It's important to note that in automated testing systems, identifying the database corresponding to an API is fundamental to building the API script. This step involves understanding how the API interacts with the backend database and how data is transferred between the API and the database. When the system parses the API source code, it identifies the SQL statements and entity class information that interact with the database, thus determining which APIs are database-related and their corresponding database tables.

[0065] After identifying the database corresponding to the interface, the system will further parse the database table structure, including table names, field names, data types, and other information. By identifying the table information, the system can establish the connection between the interface operation and the database table. For example, if an interface is responsible for querying user information, the system will determine that this operation is associated with the user table in the database, and thus take this table structure information into account when generating the interface script, ensuring that the script can correctly execute the database operation and verify the results.

[0066] It's important to note that the interface files within the project are the primary source of detailed interface information for automated testing systems. These files contain information such as the interface definition, parameters, return values, request paths, and methods. By parsing these files, the automated system can extract all the necessary information about the interface and construct a complete model of it. This process typically includes identifying the interface's URL, HTTP methods (GET, POST, PUT, etc.), request and response data structures (JSON, XML, etc.), and any necessary authentication or API key information.

[0067] In an optional implementation, after determining the database association and interface information of the interface, the automated testing system will perform association analysis to match the interface operations with the specific functions of the database tables.

[0068] The system identifies which interfaces involve database query operations and generates script snippets to verify the consistency of database query results based on SQL information and entity class definitions. It analyzes the business logic of the interfaces, understands the rules and processes by which the interfaces process data, and ensures that the generated scripts accurately simulate and verify this logic. The system detects data interactions between the interfaces and the database, identifies the flow and changes of data, and generates test cases to verify the correct transmission and processing of data. Based on the interface definitions and database table structures, the system generates assertion scripts to verify whether the content returned by the interfaces is consistent with the data in the database. For interfaces involving database operations, the system also generates SQL statements to execute the database operations.

[0069] Through the embodiments described above in this application, the automated testing system can generate comprehensive and accurate interface automation scripts based on interface files and database information, ensuring that testing covers all backend logic and data interaction points, thereby improving the completeness and effectiveness of testing. This mechanism is particularly suitable for projects that heavily rely on database operations, helping testing teams to promptly identify and fix problems in data processing or interface logic. Furthermore, by associating interface operations with database table information, the system can automatically detect whether changes to data in the database are correctly processed by the interface, enhancing the depth and breadth of testing and improving software stability and performance.

[0070] In an optional implementation, generating a target document structure and a target style structure based on the current project file includes: generating a candidate document structure and a candidate style structure based on the content file of the project file; determining the information of the front-end elements in the project file, and updating the candidate document structure and candidate style structure to the target document structure and target style structure according to the information of the front-end elements.

[0071] It's important to note that when an automated testing system begins processing a project file, it first generates candidate document structures and candidate style structures based on the content files within the project file. These content files typically contain all the HTML, CSS, and JavaScript code that makes up the page. The system parses this code, generating preliminary DOM (Document Object Model) and CSSOM (CSS Object Model) trees—that is, the candidate document structures and candidate style structures.

[0072] The DOM tree describes the HTML structure of a page, representing the hierarchical relationships and attributes between elements through a tree structure; while the CSSOM tree represents the page's style information, including style rules and their application. The candidate structure is generated based on static parsing and does not yet take into account dynamic changes or interactive behaviors of elements.

[0073] In an optional implementation, the system will identify all front-end elements on the page, including visual or interactive components such as buttons, text boxes, drop-down menus, and images, as well as information on whether they call APIs.

[0074] It's important to note that the system extracts various element attributes from the DOM / CSSOM tree, such as ID, class, and style, as well as the element's position and hierarchical relationship on the page. This information is used to generate XPath paths. XPath is a query language used to locate and extract elements and values ​​in XML documents, and it is also applicable to HTML documents. XPath paths are a common method for locating page elements in UI automation testing, ensuring the accuracy and stability of test cases.

[0075] In optional implementations, the system also identifies the dynamic behavior of elements; for example, a button might trigger an API call or page redirection. For such elements, the system further analyzes their functional logic and data interactions to ensure that the generated test scripts cover these behaviors. The system can also identify the role of elements in specific methods or functional blocks, such as search, login, and form submission.

[0076] In an optional implementation, based on in-depth analysis of front-end elements, the system updates the candidate document structure and candidate style structure to more accurately reflect the actual state and interaction logic of the page. If an element's attributes are corrected during parsing—for example, if a misreading of an element's class attribute is found—the system corrects the class information in the DOM tree to ensure the accuracy of XPath paths and other positioning strategies. For interactive elements, the system supplements their dynamic behavior information, such as button click events and input box change events. This information is added to the DOM tree as the basis for generating test scripts. If there is dynamically loaded content or layout on the page, the system identifies these changes and updates the DOM and CSSOM structures to ensure that the structure reflects the final state of the page, not the initial loading state. Finally, the system generates the "target document structure" and "target style structure," which not only contain the page's static content but also integrate the dynamic behavior and functional logic of elements. These structures are the cornerstone of automated test script generation, ensuring that the test scripts can accurately and comprehensively test all functionalities of the page.

[0077] Through the embodiments described above in this application, the automated testing system can intelligently generate a "target document structure" and a "target style structure" that reflect the latest state of the project files, providing accurate element information and page structure for subsequent test script generation, greatly improving the efficiency and accuracy of automated testing. This mechanism is particularly suitable for projects that rely on complex front-end interactions, helping testing teams quickly adapt to changes in the front-end interface and ensuring test coverage and quality.

[0078] In an optional implementation, 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, determining that the front-end element is static data and determining the preset value corresponding to the front-end element as the input of the test script; if the attribute value of the front-end element is obtained from an interface, determining that the front-end element is dynamic data and reading the database corresponding to the front-end element.

[0079] It's important to note that when parsing project files, the automated system checks the source of each front-end element's attribute values. If an element's attribute values ​​(such as content, status, options, etc.) are directly defined in the project file, the system classifies these elements as static data. Static data means that the element's displayed content is determined during the development phase and will not change with user actions or backend data changes. Examples include fixed titles or descriptive text on a page. Conversely, if an element's attribute values ​​originate from a backend API, the system classifies these elements as dynamic data. Dynamic data elements rely on real-time data acquisition, and their displayed content changes dynamically based on the data returned from the backend. Examples include article titles in a news list and prompts in user input boxes.

[0080] For static data elements, the automation system extracts their pre-defined values ​​from the project file and uses these values ​​as input for the test scripts. For example, a hard-coded input field with the message "Please enter your email address" will be recorded as test input to verify the initial state of the input field in UI automation testing. This approach simplifies test data preparation because the values ​​of static elements do not require additional dynamic data sources.

[0081] For dynamic data elements, the system reads the relevant backend interface information. This includes the interface URL, request parameters, and returned data structure. By parsing the backend interface content, the system can obtain the interface's processing logic and the associated database table information. For example, a dropdown menu option might originate from an enumeration type field in the database. The system will identify this interface and then further parse the backend code to understand the database table structure and field meanings.

[0082] In an optional implementation, after determining the interface information of dynamic data elements, the automation system understands the data type and expected values ​​through table comments or backend entity class comments. This information typically includes field descriptions, data formats, and valid value ranges, which are crucial for generating accurate interface automation scripts. The system uses this information to generate test data, simulating different user scenarios and data states to comprehensively test the display and processing logic of dynamic data elements. For example, for a table retrieving a user list from the backend, the system generates various combinations of user data, including normal data, abnormal data, and boundary condition data, to test the table's display logic and data processing capabilities.

[0083] Through the above process, the automated system can obtain detailed information about all elements on a page, including the preset values ​​of static data elements and the interfaces and database connections of dynamic data elements. The system will integrate this information into a complete page analysis result, which includes the element's DOM / CSSOM structure, element attributes, element functions (such as click, fill, dropdown selection, etc.), data source (static / dynamic), and the backend interface and database information of dynamic data elements.

[0084] In an optional implementation, the automated system can directly obtain the location of all elements on the page from the source code (i.e., project files) and know the source of the data (static or dynamic data). If a dynamic element is detected, the system will further parse its related backend interface to understand the interface's logic and data structure, thereby generating more detailed test cases.

[0085] The embodiments described above in this application ensure that UI automation scripts can accurately locate and manipulate each element, while interface automation scripts can correctly simulate and verify the logic of backend data interaction. Through this method, the automated testing system can provide testing teams with highly comprehensive and targeted test cases, thereby effectively improving testing quality and efficiency, reducing human error, and accelerating the software development and deployment cycle.

[0086] In an optional implementation, identifying the current project file includes: determining the storage address of the project file and reading the log file at the storage address; if the log file records a change in the project file version, determining that the project file has been modified.

[0087] It's important to note that automated testing systems need to know the precise storage location of the project files (i.e., the front-end and back-end source code), typically the URL of the Git repository. During the test setup process, the project's Git address must be entered so that the system can access and download the source code. This step ensures that the test system has direct access to the latest codebase, laying the foundation for subsequent code downloading and parsing.

[0088] Upon initial runtime, the device automatically downloads the latest snapshot of the project's source code. Simultaneously, it reads the Git repository's log files, which typically represent Git's commit history. These log files contain the timestamp, committer, commit message, and changes for each code commit, making them crucial for tracking project file version changes. To continuously monitor project file dynamics, the test device periodically checks the Git repository's log files. It compares the timestamp recorded at the last check with the current timestamp and the corresponding repository status. If new commit records are found within this timeframe—meaning additional version information appears in the log files—it indicates potential changes to the project files.

[0089] In an optional implementation, after detecting a version change in the log file, the testing device will conduct a thorough examination of the specific changes, including any additions, deletions, or modifications to the files. It will download or obtain a snapshot of the changed code and then compare it with the previously saved "baseline" code. If actual code modifications are found, such as function rewriting, variable addition or deletion, or interface layout adjustments, the device can confirm that the project files have indeed been changed.

[0090] Once the system detects changes to project files, it immediately initiates an automated script update process. This includes re-downloading the source code, parsing the changed code to generate a new DOM / CSSOM structure, identifying newly added or modified elements and API calls, and then generating or updating automated test scripts based on this information to reflect the latest project status. Simultaneously, the device records the time of the script update for subsequent version control and timeline tracking.

[0091] Through the implementation methods described above in this application, the integrity and accuracy of testing can be ensured even under conditions of frequent project iterations and rapid code updates. The testing system effectively reduces the workload of testers manually updating scripts, improves testing efficiency, and also reduces the risk of test omissions due to code changes, providing a reliable testing support mechanism for continuous integration and continuous delivery (CI / CD) of software.

[0092] It's important to note that after obtaining the automated test scripts, they need to be executed and the results verified. The automated testing system first executes the automated scripts generated in the above process, including UI automated scripts and API automated scripts. UI automated scripts simulate user interactions with the interface, such as clicking buttons and filling out forms, while API automated scripts directly call backend interfaces, sending requests and receiving responses to check the correctness of the interface logic and data processing.

[0093] In an optional implementation, while the automated script is executing, the system also parses the backend code data obtained from the project files, especially data related to the test cases. This may include records read from the database, the data format returned by the interface, the expected response code, and other information. After executing the automated script, the system compares the script's output with the parsed backend code data. For example, if an automated script simulates a user logging in and querying an account's balance, the system will verify whether the returned balance value matches the corresponding account balance in the database. If the data matches, the result is considered a pass, meaning the test case was successfully executed. If the data does not match, the result is considered a failure, indicating a potential backend logic error or data processing anomaly.

[0094] If all compared data points meet expectations, the test case will be marked as successful. This means that the execution of the automated script and the data processing of the backend code are consistent, and the software's behavior is correct within the test scope. Conversely, if any data mismatch is found, the test case will be marked as failed, requiring further investigation, code fixes, or updates to the automated script to ensure the software's reliability and stability.

[0095] It should be noted that after obtaining the test results, you can also save and display the test results.

[0096] In an optional implementation, the automated testing system saves the execution results, including passed and failed test cases, along with specific reasons for failure and log information, to a local database. This not only records the testing history but also provides a data foundation for subsequent data analysis and issue tracking. The system can store and display these test results through a visual interface. The information in the database is organized and formatted, presented to the testing team and developers in the form of charts, lists, or detailed reports. This allows users to quickly understand the software's testing status, including overall test coverage, pass rate, and detailed information on failed test cases, helping the team quickly locate and resolve problems. It also provides data support and decision-making basis for continuous project improvement.

[0097] Through the above implementation methods, the automated testing system can not only automatically execute tests to verify the functionality and logic of the software, but also save and display the test results in a structured manner, providing an efficient and accurate software quality control method that effectively supports the continuous integration and continuous delivery process in software development.

[0098] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0099] According to another aspect of the embodiments of this application, an automated test script generation apparatus for implementing the above-described automated test script generation method is also provided. For example... Figure 3 As shown, the device includes:

[0100] The structure generation unit 302 is used to identify the current project file. When the project file has been changed, it generates 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.

[0101] The structural comparison unit 304 is used to compare the target document structure with the reference document structure and the target style structure with the reference style structure respectively.

[0102] The script update unit 306 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. The front-end elements are used to indicate interactive or visual elements in the project file.

[0103] Optionally, the script update unit 306 includes: a first script update module, used to update the test script based on the target document structure and target style structure when 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 when the changed front-end element is a key element, wherein the key element is used to indicate the core function in the project file; and a second script update module, used to update the test script based on the changed front-end element when there are changed front-end elements between the target document structure and the reference document structure, or between the target style structure and the reference style structure, and when the changed front-end element is a regular element, wherein the regular element is used to indicate auxiliary functions in the project file.

[0104] Optionally, the script update unit 306 includes: a test instruction generation module, used to determine the corresponding test instruction based on the element information included in the front-end element; an interface script generation module, used to determine the corresponding interface script based on the interface information when the front-end element includes an interface; and a hybrid script update module, used to update the test script corresponding to the project file according to the test instruction and the interface script.

[0105] Optionally, the above-mentioned interface script generation module is also used to: 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; and determine the information of the interface based on the interface file in the project file.

[0106] Optionally, the structure generation unit 302 includes: a structure generation module, used to generate candidate document structures and candidate style structures based on the content files of the project file; and a structure update module, used to determine the information of the front-end elements in the project file, and update the candidate document structures and candidate style structures to the target document structure and target style structure according to the information of the front-end elements.

[0107] Optionally, the aforementioned structure update module is also used to determine that the front-end element is static data when the attribute value of the front-end element is defined in the project file, and to determine the preset value corresponding to the front-end element as the input of the test script; and to determine that the front-end element is dynamic data when the attribute value of the front-end element is obtained from the interface, and to read the database corresponding to the front-end element.

[0108] Optionally, the above-mentioned structure generation unit 302 further includes: a file recognition module, used to determine the storage address of the project file and read the log file of the storage address; if the log file records changes to the project file version, it is determined that the project file has been changed.

[0109] Optionally, in this embodiment, the implementation of each of the above-mentioned unit modules can be referred to the above-mentioned method embodiments, which will not be repeated here.

[0110] According to another aspect of the embodiments of this application, an electronic device for implementing the above-described automated test script generation method is also provided. This electronic device may be... Figure 4 The terminal device or server shown. This embodiment uses this electronic device as an example for illustration. Figure 4 As shown, the electronic device includes a memory 402 and a processor 404. The memory 402 stores a computer program, and the processor 404 is configured to execute the steps in any of the above method embodiments via the computer program.

[0111] Optionally, in this embodiment, the aforementioned electronic device may be located in at least one of a plurality of network devices in a computer network.

[0112] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0113] S1. Identify the current project file. If the project file has been changed, 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.

[0114] S2, compare the target document structure with the reference document structure, and the target style structure with the reference style structure respectively;

[0115] S3, in the case of 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, update the test script corresponding to the project file based on the changing front-end elements, wherein the front-end elements are used to indicate interactive or visual elements in the project file.

[0116] Alternatively, as those skilled in the art will understand, Figure 4 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones (such as iOS and Android phones), tablets, PDAs, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 4 This does not limit the structure of the aforementioned electronic devices or electronic equipment. For example, electronic devices or electronic equipment may also include components that are more... Figure 4 The more or fewer components shown (such as network interfaces, etc.), or having the same Figure 4 The different configurations shown.

[0117] The memory 402 can be used to store software programs and modules, such as the program instructions / modules corresponding to the automated test script generation method and apparatus in this embodiment. The processor 404 executes various functional applications and data processing by running the software programs and modules stored in the memory 402, thereby realizing the aforementioned automated test script generation method. The 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 instances, the memory 402 may further include memory remotely located relative to the processor 404, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Specifically, the memory 402 may be used, but is not limited to, to store project files, test scripts, and other information. As an example, such as... Figure 4 As shown, the memory 402 may include, but is not limited to, the structure generation unit 302, the structure comparison unit 304, and the script update unit 306 in the automated test script generation device. Furthermore, it may include, but is not limited to, other module units in the automated test script generation device, which will not be elaborated upon in this example.

[0118] Optionally, the transmission device 406 described above is used to receive or send data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 406 includes a Network Interface Controller (NIC), which can be connected to other network devices and a router via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 406 is a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0119] In addition, the aforementioned electronic device also includes: a display 408 for displaying test results, etc.; and a connection bus 410 for connecting various module components in the aforementioned electronic device.

[0120] In other embodiments, the aforementioned terminal device or server can be a node in a distributed system, wherein the distributed system can be a blockchain system, which is a distributed system formed by connecting multiple nodes through network communication. The nodes can form a peer-to-peer (P2P) network, and any form of computing device, such as a server, terminal, or other electronic device, can become a node in the blockchain system by joining this peer-to-peer network.

[0121] According to one aspect of this application, a computer program product is provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by a central processing unit, it performs various functions provided in embodiments of this application.

[0122] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0123] According to one aspect of this application, a computer-readable storage medium is provided, wherein a processor of a computer device reads computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the above-described automated test script generation method.

[0124] Optionally, in this embodiment, the computer-readable storage medium may be configured to store a computer program for performing the following steps:

[0125] S1. Identify the current project file. If the project file has been changed, 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.

[0126] S2, compare the target document structure with the reference document structure, and the target style structure with the reference style structure respectively;

[0127] S3, in the case of 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, update the test script corresponding to the project file based on the changing front-end elements, wherein the front-end elements are used to indicate interactive or visual elements in the project file.

[0128] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0129] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0130] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0131] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between units or modules, and may be electrical or other forms.

[0132] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

[0134] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for generating automated test scripts, characterized in that, include: 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, characterized in that, The update of 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, characterized in that, The update of 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, the process 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, The generation of 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, characterized in that, The process of 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 identification of the current project files 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, include: 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 the computer program / instructions are executed by the processor, they 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 execute the method described in any one of claims 1 to 7 through the computer program.

Images