Front-end code testing method and device, program product and electronic equipment
By constructing an abstract syntax tree of the front-end code and simulating testing in a sandbox environment, the problem of low accuracy in front-end code testing in existing technologies is solved, achieving efficient cross-platform compatibility testing and user experience optimization.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-30
- Publication Date
- 2026-04-07
AI Technical Summary
Existing technologies have low accuracy in front-end code testing, especially in cross-platform compatibility testing, where they suffer from low efficiency, insufficient coverage, and static code detection defects, failing to meet the needs of agile development.
Generates an abstract syntax tree of front-end code, detects browser compatibility based on node-based preset rules, simulates dynamic code segments in a sandbox environment, and generates a test report by combining compatibility and simulation test results.
It enables accurate testing of the dynamic characteristics of front-end code in different browser environments, improving testing accuracy and efficiency, and ensuring cross-platform compatibility and user experience.
Smart Images

Figure CN121807722A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of financial technology or other related technical fields, and more specifically, to a method, apparatus, program product, and electronic device for testing front-end code. Background Technology
[0002] In recent years, the rapid development of Web (World Wide Web) technology and the surge in the diversity of user terminal devices have brought unprecedented challenges to front-end development, especially in ensuring cross-platform compatibility of code. Most websites have encountered browser compatibility issues, which have affected the user experience and functionality of front-end applications. In existing technologies, front-end code compatibility testing usually relies on manual testing or rudimentary automated tools. However, existing technologies have the following technical bottlenecks:
[0003] (1) Traditional manual testing methods rely on the developer’s experience and require manual verification for different browsers and devices, which is inefficient and difficult to cover all usage scenarios.
[0004] (2) Although automated testing tools can achieve cross-browser testing, they have problems such as high maintenance cost and long execution time of automated test cases, which cannot meet the needs of agile development.
[0005] (3) Existing detection schemes mostly focus on errors in front-end code runtime, lacking pre-release detection of static code aspects such as CSS (Cascading Style Sheets) feature compatibility and API (Application Programming Interface) support.
[0006] In summary, testing front-end code using existing technologies suffers from low accuracy, and no effective solution has yet been proposed to address this issue. Summary of the Invention
[0007] This application provides a method, apparatus, program product, and electronic device for testing front-end code, to at least solve the technical problem of low accuracy of test results obtained from testing front-end code based on existing technologies.
[0008] According to one aspect of this application, a method for testing front-end code is provided, comprising: generating an abstract syntax tree (AST) corresponding to the front-end code, wherein the AST includes L nodes, where L is a positive integer, and the L nodes are used to characterize the code features of the front-end code; detecting the compatibility relationship between the front-end code corresponding to each node and the browser based on preset rules corresponding to each of the L nodes, and obtaining a first test result corresponding to each node; obtaining target nodes from the L nodes to obtain M target nodes, where M is a positive integer less than or equal to L, and the front-end code corresponding to each target node is allowed to be dynamically modified during webpage loading / running; performing simulated testing on the front-end code corresponding to each target node in a preset sandbox environment, and obtaining a second test result corresponding to each target node; and generating a test report for the front-end code based on the first test results corresponding to the L nodes and the second test results corresponding to the M target nodes.
[0009] Optionally, generating an abstract syntax tree corresponding to the front-end code includes: performing lexical analysis on the front-end code to obtain P words corresponding to the front-end code, where P is a positive integer; performing syntactic analysis on the P words to obtain syntactic parsing results corresponding to the P words, where the syntactic parsing results are used to represent the syntactic association logic between the P words; and generating an abstract syntax tree based on the P words and the syntactic parsing results corresponding to the P words.
[0010] Optionally, before detecting the compatibility relationship between the front-end code corresponding to each node and the browser based on the preset rules corresponding to each of the L nodes, the front-end code testing method further includes: obtaining the node tag corresponding to each node, wherein the node tag is used to characterize the code type of the front-end code corresponding to each node; and searching in the preset browser compatibility database based on the node tag to obtain the preset rules corresponding to each node, wherein the preset rules are used to record the compatibility relationship between front-end code of different code types and different versions of browsers.
[0011] Optionally, based on the preset rules corresponding to each of the L nodes, the compatibility relationship between the front-end code corresponding to each node and the browser is detected to obtain the first test result corresponding to each node, including: obtaining the version range of all browsers recorded by the preset rules corresponding to each node; if the front-end code corresponding to the i-th node in the L nodes is incompatible with the j-th version of the browser recorded by the preset rules corresponding to the i-th node, the code position, feature name and version identifier of the j-th version of the browser of the front-end code corresponding to the i-th node are used as the first test result corresponding to the i-th node.
[0012] Optionally, obtaining the target node among L nodes includes: if the front-end code of the kth node among L nodes is used to implement interface calls / to determine the rendering effect of page elements in the front-end page, then the kth node is taken as the target node.
[0013] Optionally, in a preset sandbox environment, the front-end code corresponding to each target node is simulated and tested to obtain a second test result for each target node. This includes: running the front-end code corresponding to each target node in the preset sandbox environment to obtain the actual page rendering effect of each target node; if the actual page rendering effect of the qth target node among the M target nodes is different from the preset page rendering effect of the qth target node, the code location, feature name, and device identifier of the terminal device simulated in the preset sandbox environment of the qth target node are used as the second test result for the qth target node.
[0014] Optionally, based on the first test results corresponding to L nodes and the second test results corresponding to M target nodes, a test report for the front-end code is generated, including: determining an initial problem list based on the first test results corresponding to L nodes and the second test results corresponding to M target nodes, wherein the initial problem list includes at least a first test problem and a second test problem, the first test problem being used to characterize incompatibility between the front-end code corresponding to the node and the corresponding browser version, and the second test problem being used to characterize errors in the page rendering effect of the front-end code corresponding to the node; determining the priority of each test problem based on the impact range of each test problem in the initial problem list; sorting all test problems in the initial problem list based on the priority of each test problem to obtain a target problem list, and generating a repair suggestion for each test problem in the target problem list; generating a target chart based on the first test results corresponding to L nodes and the second test results corresponding to M target nodes, wherein the target chart is used to visually display the browser version information compatible with the front-end code; and generating a test report for the front-end code based on the target problem list, the repair suggestion for each test problem, and the target chart.
[0015] According to another aspect of this application, a testing apparatus for front-end code is also provided, comprising: a syntax tree generation unit, used to generate an abstract syntax tree corresponding to the front-end code, wherein the abstract syntax tree includes L nodes, where L is a positive integer, and the L nodes are used to characterize the code features of the front-end code; a compatibility testing unit, used to detect the compatibility relationship between the front-end code corresponding to each node and the browser based on preset rules corresponding to each of the L nodes, and obtain a first test result corresponding to each node; a target node acquisition unit, used to acquire target nodes from the L nodes, obtaining M target nodes, where M is a positive integer less than or equal to L, and the front-end code corresponding to each target node is allowed to be dynamically modified during webpage loading / running; a simulation testing unit, used to perform simulation testing on the front-end code corresponding to each target node in a preset sandbox environment, and obtain a second test result corresponding to each target node; and a test report generation unit, used to generate a test report for the front-end code based on the first test results corresponding to the L nodes and the second test results corresponding to the M target nodes.
[0016] According to another aspect of this application, a computer program product is also provided, which stores a computer program, wherein a test method is provided to control the computer program product to execute the front-end code of any of the above when the computer program is running.
[0017] According to another aspect of this application, an electronic device is also provided, wherein the electronic device includes one or more processors and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, a test method is provided that causes the one or more processors to implement the front-end code of any of the above.
[0018] In this application, an abstract syntax tree (AST) corresponding to the front-end code is first generated. The AST includes L nodes, where L is a positive integer. The L nodes represent the code characteristics of the front-end code. Then, based on the preset rules corresponding to each of the L nodes, this application detects the compatibility relationship between the front-end code corresponding to each node and the browser, obtaining a first test result for each node. Next, this application obtains the target nodes from the L nodes, resulting in M target nodes, where M is a positive integer less than or equal to L. The front-end code corresponding to each target node is allowed to be dynamically modified during webpage loading / running. Subsequently, in a preset sandbox environment, a simulation test is performed on the front-end code corresponding to each target node, obtaining a second test result for each target node. Finally, based on the first test results corresponding to the L nodes and the second test results corresponding to the M target nodes, this application generates a test report for the front-end code.
[0019] As described above, this application first constructs an abstract syntax tree corresponding to the front-end code, thus obtaining a standardized and analyzable code form. Subsequently, based on prediction rules that can be updated synchronously with Web standards, this application performs compatibility testing on each node in the abstract syntax tree, achieving the goal of instantly discovering potential browser incompatibility defects in the front-end code. Simultaneously, for code segments that can be dynamically modified during runtime (i.e., the code segments corresponding to the target nodes), this application introduces a sandbox environment for simulation testing, thereby achieving accurate testing of the rendering effects of the dynamic characteristics of the front-end code in different browser environments. Afterwards, this application combines the test results of compatibility testing and simulation testing to generate a test report, thus achieving the technical effect of improving the testing accuracy of the front-end code, and thereby solving the technical problem of low accuracy in test results obtained from testing front-end code based on existing technologies. Attached Figure Description
[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:
[0021] Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a testing method for front-end code, according to an embodiment of this application.
[0022] Figure 2 This is a flowchart of an optional front-end code testing method according to an embodiment of this application;
[0023] Figure 3 This is a schematic diagram of an optional front-end code testing apparatus according to an embodiment of this application;
[0024] Figure 4 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation
[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.
[0026] 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.
[0027] It should also be noted that all information and data involved in this application (including but not limited to information used for display and analysis) and data (including but not limited to front-end code data to be analyzed) are information and data authorized by the user or fully authorized by all parties. For example, if there is an interface between this system and the relevant user or organization, before obtaining the relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain the relevant information after receiving the consent information from the aforementioned user or organization.
[0028] Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of relevant information and data involved in this application all comply with the relevant laws, regulations, and standards of the relevant regions, and necessary confidentiality measures have been taken. This application does not violate public order and good morals. In addition, this application provides a corresponding operation entry point for users to choose to agree to or refuse authorization. If the user chooses to refuse authorization, the corresponding expert decision-making process will be initiated.
[0029] The present invention will now be described in detail with reference to various embodiments.
[0030] Example 1
[0031] According to an embodiment of this application, an embodiment of a testing method for front-end code is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0032] The methods and embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a testing method for front-end code, according to an embodiment of this application. Figure 1As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.
[0033] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).
[0034] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the front-end code testing method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned front-end code testing method. The memory 104 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 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 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.
[0035] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.
[0036] The display can be configured as a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).
[0037] Under the aforementioned operating environment, this application provides a front-end code testing system (hereinafter referred to as the testing system) for executing the testing method of the front-end code in this application. Figure 2 This is a flowchart of an optional front-end code testing method according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:
[0038] Step S201: Generate an abstract syntax tree corresponding to the front-end code. The abstract syntax tree includes L nodes, where L is a positive integer, and the L nodes are used to represent the code features of the front-end code.
[0039] Optionally, the front-end code can be written in a variety of front-end programming languages, such as HTML, CSS, and JavaScript.
[0040] Optionally, the testing system performs lexical analysis and syntax analysis on the front-end code through the front-end code parsing layer. Then, based on the analysis results, a syntax tree is constructed to obtain a standardized, hierarchical intermediate code representation, namely an abstract syntax tree.
[0041] Optionally, the testing system converts the front-end code into an abstract syntax tree (AST), facilitating subsequent structured analysis of the front-end code. The testing system can then perform predefined rule matching and compatibility testing by traversing all nodes in the AST. This code-to-AST conversion process enables the testing system to accurately and quickly capture the syntactic features and logical structure of the front-end code, laying a data foundation for subsequent code compatibility testing, simplifying the complexity of subsequent code analysis, and thus improving testing efficiency.
[0042] Step S202: Based on the preset rules corresponding to each of the L nodes, detect the compatibility relationship between the front-end code corresponding to each node and the browser, and obtain the first test result corresponding to each node.
[0043] Optionally, preset rules refer to the rules stored in the preset browser compatibility database. The preset rules are used to record the compatibility relationship between front-end code of different code types and different versions of browsers. The rule data stored in the preset browser compatibility database is updated synchronously with the Web standards, and the preset browser compatibility database covers feature support information between the Web standards and all browser versions.
[0044] Optionally, the testing system compares the compatibility between the front-end code features and the browser version by traversing the nodes one by one. For the incompatible nodes detected, the testing system records the specific location of the front-end code corresponding to the node, the feature name, and the range of incompatible browser versions, and obtains the first test result.
[0045] Optionally, by matching nodes in the abstract syntax tree with preset rules, the testing system can automatically identify the compatibility status between the front-end code elements corresponding to each node and different browser versions, thereby improving the efficiency of front-end code compatibility testing. At the same time, since the preset browser compatibility database covers feature support information between Web standards and all browser versions, and the preset rules can be updated synchronously with Web standards, the scenario coverage of compatibility testing based on preset rules is improved, avoiding the subjectivity of manual testing and the omission of test scenarios, thereby improving the accuracy of the obtained test results.
[0046] Step S203: Obtain the target node from L nodes to get M target nodes, where M is a positive integer less than or equal to L. The front-end code corresponding to each target node is allowed to be dynamically modified during the webpage loading / running process.
[0047] Optionally, the target node refers to an object that can be dynamically modified by JavaScript (a lightweight programming language) code during the loading / running of a webpage, i.e., the dynamic DOM (Document Object Model).
[0048] Optionally, by filtering target nodes, the testing system can subsequently test the rendering effect of the dynamic DOM corresponding to the front-end code in a preset sandbox environment. This allows the system to capture compatibility issues in the front-end page during page interaction and promptly identify defects in the page rendering effect of the front-end code, thus filling the gap in existing technologies where static analysis tools cannot detect dynamic page rendering effects.
[0049] Step S204: In a preset sandbox environment, simulate the testing of the front-end code corresponding to each target node to obtain the second test result for each target node.
[0050] Optionally, a preset sandbox environment is used to simulate the operating status of different user terminal devices.
[0051] Optionally, the testing system tests the front-end code corresponding to each target node, i.e., the dynamic DOM, in a preset sandbox environment. This allows the system to discover differences in page rendering effects of the front-end code corresponding to the target node on different user terminal devices, including differences in page layout and page display effects. This testing method improves the coverage of test scenarios, enhances the credibility of simulated test results, and reduces the probability of unexpected failures caused by compatibility issues of user terminal devices in the online environment, thereby improving the user experience.
[0052] Step S205: Based on the first test results corresponding to L nodes and the second test results corresponding to M target nodes, generate a test report for the front-end code.
[0053] Optionally, the data in the test report includes at least one of the following:
[0054] The target issue list is sorted by priority and used to record browser version compatibility issues and page rendering error issues found during testing.
[0055] Recommended fixes for each test issue in the target issue list;
[0056] The target chart is a comparison chart showing the features supported by different browser versions.
[0057] Optionally, the testing system combines the test results from compatibility testing and simulation testing to generate a comprehensive test report, providing developers with intuitive test issues. Developers can quickly locate and resolve code defects in the front-end code based on the problem fixing suggestions in the test report, thereby improving the code quality of the front-end code and increasing the support of the application for different user terminal devices and different versions of browsers.
[0058] As described above, this application first constructs an abstract syntax tree corresponding to the front-end code, thus obtaining a standardized and analyzable code form. Subsequently, based on prediction rules that can be updated synchronously with Web standards, this application performs compatibility testing on each node in the abstract syntax tree, achieving the goal of instantly discovering potential browser incompatibility defects in the front-end code. Simultaneously, for code segments that can be dynamically modified during runtime (i.e., the code segments corresponding to the target nodes), this application introduces a sandbox environment for simulation testing, thereby achieving accurate testing of the rendering effects of the dynamic characteristics of the front-end code in different browser environments. Afterwards, this application combines the test results of compatibility testing and simulation testing to generate a test report, thus achieving the technical effect of improving the testing accuracy of the front-end code, and thereby solving the technical problem of low accuracy in test results obtained from testing front-end code based on existing technologies.
[0059] In one optional embodiment, in order to accurately create the abstract syntax tree corresponding to the front-end code, the testing system first performs lexical analysis on the front-end code to obtain P words corresponding to the front-end code, where P is a positive integer. Then, the testing system performs syntactic analysis on the P words to obtain the syntactic parsing results corresponding to the P words. The syntactic parsing results are used to represent the syntactic association logic between the P words. Finally, the testing system generates the abstract syntax tree based on the P words and the syntactic parsing results corresponding to the P words.
[0060] Optionally, the testing system can perform lexical analysis on the front-end code using preset tools, decomposing the front-end code string into a series of lexical units, namely P words. The P words include keywords, identifiers, numbers, and characters, which are the basic elements that constitute the front-end code.
[0061] Optionally, the testing system can perform lexical analysis on the front-end code to eliminate non-core content such as whitespace and comments in the source code, thereby extracting the core semantics of the front-end code. This provides concise word data for subsequent syntax analysis and the creation of abstract syntax trees, thereby improving the accuracy and efficiency of subsequent syntax tree creation and analysis.
[0062] Optionally, syntax analysis refers to further analyzing the syntactic relationships between different words based on the word sequence obtained from lexical analysis in order to identify the code structure corresponding to the front-end code, such as function definitions, loop structures, and selection statements, and thus organize them into a tree structure to obtain an abstract syntax tree.
[0063] Optionally, the testing system provides a logical framework for constructing an abstract syntax tree through syntax analysis, enabling the subsequent testing system to accurately identify the code structure corresponding to the front-end code, avoiding the problem of misunderstanding the logic of the front-end code, and avoiding false positives or false negatives caused by syntax analysis errors, thereby improving the accuracy of subsequent compatibility testing and simulation testing.
[0064] Alternatively, an Abstract Syntax Tree (AST) is a tree-like data structure that can represent the code features of source code in the form of nodes, where each node in the tree corresponds to a syntax element or code snippet in the front-end code.
[0065] Optionally, the testing system generates an abstract syntax tree based on P words and their corresponding syntax parsing results. This presents the syntactic logic of the front-end code in a structured and hierarchical manner, making the code characteristics, functions, and structure of the front-end code clearer. As the data foundation for subsequent compatibility testing and simulation testing, the abstract syntax tree helps the testing system accurately identify the web features used in the front-end code (such as HTML tags, CSS properties, and JavaScript APIs). This structured representation simplifies the matching process of preset rules and improves testing efficiency.
[0066] In summary, the testing system, through the aforementioned steps of lexical analysis, syntax analysis, and abstract syntax tree generation, transforms continuous front-end code into a well-structured and logically coherent abstract syntax tree, providing a data foundation for subsequent testing processes and improving the speed of generating subsequent test results.
[0067] In one optional embodiment, in order to accurately obtain the preset rules matching each node, the testing system first obtains the node tag corresponding to each node, wherein the node tag is used to characterize the code type of the front-end code corresponding to each node. Then, the testing system searches in a preset browser compatibility database based on the node tag to obtain the preset rules corresponding to each node, wherein the preset rules are used to record the compatibility relationship between front-end code of different code types and different versions of browsers.
[0068] Optionally, a node label refers to the node tag carried by each node in the abstract syntax tree, used to identify the web features of the front-end code that the node represents.
[0069] Optionally, by acquiring the tags of each node, the testing system can quickly identify the code type (i.e., Web feature) of the code element corresponding to that node. Since the front-end code of different code types has different compatibility effects with different browser versions, the testing system can search in a preset browser compatibility database based on the node tags of each node to find preset rules for code type matching, so as to perform browser version compatibility testing on that node.
[0070] For example, the default browser compatibility database can be set to the CanIUse dataset, which provides compatibility information for web technologies across different browsers and versions, covering the support of web features such as HTML (HyperText Markup Language), CSS, and JavaScript for different browsers and versions.
[0071] Optionally, the testing system, based on a pre-set browser compatibility database, can quickly determine the compatibility status of the front-end code corresponding to a node across different browsers and browser versions. This mechanism transforms the dynamic detection of front-end code features into a static process of database rule lookup, improving the speed of compatibility assessment. Simultaneously, the real-time updating of the rule database enhances the timeliness and accuracy of front-end code compatibility test results, effectively avoiding the compatibility misjudgments caused by outdated rule databases in traditional detection methods, further improving the accuracy of compatibility testing.
[0072] In summary, the testing system achieves fast and accurate compatibility testing by accurately identifying node types and using a compatibility database to match compatibility rules. This approach improves testing speed and accuracy, thereby ensuring the comprehensiveness and reliability of test results.
[0073] In one optional embodiment, in order to accurately obtain the first test result corresponding to each node, the test system first obtains the version range of all browsers recorded by the preset rules corresponding to each node. Then, if the front-end code corresponding to the i-th node among the L nodes is incompatible with the j-th version of the browser recorded by the preset rules corresponding to the i-th node, the test system uses the code location, feature name, and version identifier of the j-th version of the browser in the front-end code corresponding to the i-th node as the first test result corresponding to the i-th node.
[0074] Optionally, when testers need to determine the front-end code's support for different browsers and browser versions, the testing system can obtain all browser version ranges recorded by the preset rules corresponding to each node. This allows for a comprehensive and systematic identification of the front-end code's compatibility status across all different browsers and browser versions, avoiding compatibility testing omissions caused by missing version information.
[0075] Optionally, during actual testing, the testing system can record only the first test result corresponding to the node that fails the compatibility test, thereby reducing the workload of testers and speeding up the testing process.
[0076] Optionally, the first test result refers to the specific information detected by the test system during the current test analysis phase regarding compatibility issues between the front-end code and a specific browser version. This includes the location of the problematic code (file path, line number, column number), the names of the features involved, and the version identifier of the incompatible browser. The generation of the first test result serves the following purposes:
[0077] (1) Precise problem location: Developers can quickly locate the line number and column number of the problematic code, which speeds up the efficiency of problem investigation.
[0078] (2) Provide repair guidance: clearly list the feature name and incompatible browser version to help developers understand the cause of the problem and choose the appropriate repair solution.
[0079] In summary, by collecting and analyzing compatibility information between the front-end code and the browser version, the testing system has achieved accurate detection and localization of compatibility issues, providing a data foundation for subsequent front-end code repair work. At the same time, it has improved the efficiency and accuracy of front-end code compatibility testing.
[0080] In an optional embodiment, in order to accurately obtain the target node in the abstract syntax tree, the test system uses the kth node out of L nodes as the target node when the front-end code is used to implement interface calls / to determine the rendering effect of page elements in the front-end page.
[0081] Optionally, the rendering effect of page elements includes the application effect of CSS styles, the display effect of animation elements, and the display effect of page layout in the front-end page. The accuracy of the rendering effect of page elements directly affects the user's visual experience and page interaction experience.
[0082] Optionally, the testing system marks the nodes that implement interface calls and affect page rendering as target nodes. This allows subsequent testing processes to focus on code snippets that impact the user's visual and interactive experience. For target nodes, the testing system can perform more in-depth simulation testing. For example, it can dynamically simulate the real user terminal device environment through a preset sandbox environment to detect the consistency between the actual page rendering effect and the expected rendering effect of the front-end code. This reduces the defects caused by ignoring the dynamic DOM rendering effect test of the front-end code, resulting in missed compatibility issues and improving the overall detection accuracy.
[0083] In one optional embodiment, in order to accurately obtain the second test result corresponding to each target node, the test system first runs the front-end code corresponding to each target node in a preset sandbox environment to obtain the actual page rendering effect of each target node. Then, if the actual page rendering effect of the qth target node among the M target nodes is different from the preset page rendering effect of the qth target node, the test system uses the code location, feature name, and device identifier of the terminal device simulated in the preset sandbox environment of the qth target node as the second test result corresponding to the qth target node.
[0084] Optionally, a preset sandbox environment is used to simulate the operating status of different user terminal devices.
[0085] Optionally, the actual page rendering effect refers to the page display result obtained after executing the front-end code in the sandbox environment, including visual features such as element layout, style application, and animation effects.
[0086] Optionally, the testing system can achieve the following by running the front-end code of the target node in a preset sandbox environment:
[0087] (1) Ensuring security and isolation: The sandbox environment ensures that code execution will not interfere with the real system, avoids potential security risks, and provides a controllable testing environment, making it easier for developers to analyze code behavior.
[0088] (2) Dynamic verification of rendering effects: For code execution effects that are difficult to detect in static analysis, such as dynamically generated DOM elements and page interaction effects related to the characteristics of user terminal devices, the sandbox environment can provide dynamic verification at runtime, thereby improving the accuracy of test results.
[0089] (3) Simulate multiple environment scenarios: The sandbox environment simulates different browser versions, operating systems and resolutions of different user terminal devices, thereby achieving the purpose of full testing of the page rendering effect of the front-end code in different user terminal environments, improving the coverage of test scenarios and solving the problem of detection failure of dynamic rendering pages in the existing technology.
[0090] Optionally, the testing system uses the code location, feature name, and device identifier of the terminal device simulated in the preset sandbox environment of the q-th target node, which contains the intentional error in the page rendering effect, as the second test result corresponding to the q-th target node. This has the following functions:
[0091] (1) Accurately identify rendering differences: By comparing the actual and preset page rendering effects, the compatibility issues of the front-end code in a specific simulated environment can be accurately identified, providing direct evidence for the location of test problems.
[0092] (2) Provide specific repair clues: The code location, feature name and device identifier contained in the second test results provide developers with clear code repair directions and improve the efficiency of solving test problems.
[0093] (3) Optimize multi-device compatibility: By testing compatibility with various user terminal devices, the consistency of the application performance corresponding to the front-end code on different user terminal devices is ensured, thereby improving the user experience.
[0094] In summary, by simulating the device environment of user terminal devices, the testing system further improves the accuracy and comprehensiveness of front-end code compatibility testing, and enhances the cross-platform performance and user experience of the applications corresponding to the front-end code.
[0095] In one optional embodiment, to accurately obtain the test report of the front-end code, the testing system first determines an initial problem list based on the first test results corresponding to L nodes and the second test results corresponding to M target nodes. The initial problem list includes at least a first test problem and a second test problem. The first test problem characterizes incompatibility between the front-end code corresponding to a node and the corresponding browser version, while the second test problem characterizes errors in the page rendering effect of the front-end code corresponding to a node. Then, based on the impact range of each test problem in the initial problem list, the testing system determines the priority of each test problem. Based on the priority of each test problem, all test problems in the initial problem list are sorted to obtain a target problem list. Repair suggestions are generated for each test problem in the target problem list. Next, based on the first test results corresponding to L nodes and the second test results corresponding to M target nodes, the testing system generates a target chart. The target chart is used to visually display the browser version information compatible with the front-end code. Finally, based on the target problem list, the repair suggestions for each test problem, and the target chart, the testing system generates a test report for the front-end code.
[0096] In one optional embodiment, by combining the first test issues recorded in the first test results and the second test issues recorded in the second test results, the testing system can comprehensively evaluate the compatibility level of the front-end code from two dimensions: syntax features and actual page rendering effect. This results in an initial issue list that can fully reflect the code problems of the front-end code. The formation of the initial issue list lays the foundation for subsequent priority determination and repair suggestion generation, making it easier for the testing system to conduct more in-depth problem analysis and generate repair suggestions.
[0097] Optionally, the testing system determines the priority of each test issue, sorts all test issues in the initial issue list based on the priority, and then generates fix suggestions in order of priority. This allows developers to prioritize and resolve critical issues that have a greater impact on application stability and user experience, thereby improving the usability of the front-end code application and optimizing the user experience.
[0098] Optionally, the testing system generates a target chart based on the first test results corresponding to L nodes and the second test results corresponding to M target nodes to visualize the browser version information compatible with the front-end code. This allows developers to quickly understand the front-end code's support for different browser versions through a single chart. The chart-based compatibility report helps developers quickly assess the severity of browser compatibility issues and provides a basis for decision-making regarding whether emergency repairs or repair resources are needed for the front-end code.
[0099] In one optional embodiment, a front-end code compatibility detection and problem-solving system is also provided, which includes four main modules: a front-end code parsing layer, a compatibility rule matching layer, a detection engine, and a result output layer.
[0100] Optionally, the front-end code parsing layer constructs a syntax tree from the input front-end code to obtain a standardized intermediate representation, namely an abstract syntax tree. The compatibility rule matching layer traverses and checks the nodes in the abstract syntax tree based on preset rules built into a preset browser compatibility database. The preset rules are dynamically updated based on W3C standards, mainstream browser feature support tables, and preset development specifications of financial institutions. The detection engine tests the compatibility of dynamic DOM code elements with the operating environment of different user terminal devices by combining static analysis and dynamic simulation in a preset sandbox environment. The result output layer generates a structured report containing problem code location, compatibility score, and test problem repair suggestions. The test report supports both visual display and API interface call output modes. The four modules communicate through standardized data interfaces and adopt a plug-in design to ensure scalability, thereby adapting to the detection needs of front-end code of different sizes.
[0101] Optionally, the entire workflow of the front-end code compatibility detection and problem fixing system adopts an automated pipeline design, with the average code processing time controlled within 0.2 seconds per thousand lines of code, and supports integration into developers' continuous code delivery and code integration processes via API.
[0102] As described above, this application first constructs an abstract syntax tree corresponding to the front-end code, thus obtaining a standardized and analyzable code form. Subsequently, based on prediction rules that can be updated synchronously with Web standards, this application performs compatibility testing on each node in the abstract syntax tree, achieving the goal of instantly discovering potential browser incompatibility defects in the front-end code. Simultaneously, for code segments that can be dynamically modified during runtime (i.e., the code segments corresponding to the target nodes), this application introduces a sandbox environment for simulation testing, thereby achieving accurate testing of the rendering effects of the dynamic characteristics of the front-end code in different browser environments. Afterwards, this application combines the test results of compatibility testing and simulation testing to generate a test report, thus achieving the technical effect of improving the testing accuracy of the front-end code, and thereby solving the technical problem of low accuracy in test results obtained from testing front-end code based on existing technologies.
[0103] Example 2
[0104] This application embodiment can also provide a front-end code testing device. It should be noted that the front-end code testing device of this application embodiment can be used to execute the front-end code testing method provided in this application embodiment. The front-end code testing device provided in this application embodiment will be described below.
[0105] According to an embodiment of this application, an apparatus for implementing the testing method for the aforementioned front-end code is also provided. Figure 3 This is a schematic diagram of an optional front-end code testing apparatus according to an embodiment of this application, such as... Figure 3 As shown, the device includes: a syntax tree generation unit 301, a compatibility testing unit 302, a target node acquisition unit 303, a simulation testing unit 304, and a test report generation unit 305.
[0106] Optionally, the syntax tree generation unit 301 is used to generate an abstract syntax tree corresponding to the front-end code, wherein the abstract syntax tree includes L nodes, where L is a positive integer, and the L nodes are used to represent the code characteristics of the front-end code; the compatibility testing unit 302 is used to detect the compatibility relationship between the front-end code corresponding to each node and the browser based on the preset rules corresponding to each of the L nodes, and obtain the first test result corresponding to each node; the target node acquisition unit 303 is used to acquire the target nodes among the L nodes, and obtain M target nodes, where M is a positive integer less than or equal to L, and the front-end code corresponding to each target node is allowed to be dynamically modified during the webpage loading / running process; the simulation testing unit 304 is used to perform simulation testing on the front-end code corresponding to each target node in a preset sandbox environment, and obtain the second test result corresponding to each target node; the test report generation unit 305 is used to generate a test report for the front-end code based on the first test results corresponding to the L nodes and the second test results corresponding to the M target nodes.
[0107] As described above, this device first constructs an abstract syntax tree corresponding to the front-end code, thus obtaining a standardized and analyzable code form. Subsequently, based on prediction rules that can be updated synchronously with Web standards, the device performs compatibility testing on each node in the abstract syntax tree, achieving the goal of instantly discovering potential browser incompatibility defects in the front-end code. Simultaneously, for code segments that can be dynamically modified during runtime (i.e., the code segments corresponding to the target nodes), the device introduces a sandbox environment for simulation testing, thereby achieving accurate testing of the rendering effects of the dynamic characteristics of the front-end code in different browser environments. Afterwards, the device combines the test results of compatibility testing and simulation testing to generate a test report, thus achieving the technical effect of improving the testing accuracy of the front-end code and solving the technical problem of low accuracy in test results obtained based on existing technologies for testing front-end code.
[0108] In one optional embodiment, the syntax tree generation unit 301 includes: a lexical parsing subunit, a syntax analysis subunit, and a syntax tree generation subunit.
[0109] Optionally, the lexical analysis subunit is used to perform lexical analysis on the front-end code to obtain P words corresponding to the front-end code, where P is a positive integer; the syntax analysis subunit is used to perform syntax analysis on the P words to obtain the syntax analysis results corresponding to the P words, where the syntax analysis results are used to represent the syntax association logic between the P words; and the syntax tree generation subunit is used to generate an abstract syntax tree based on the P words and the syntax analysis results corresponding to the P words.
[0110] In an optional embodiment, the testing apparatus for the front-end code further includes a node label acquisition unit and a rule search unit.
[0111] Optionally, the node tag acquisition unit is used to acquire the node tag corresponding to each node, wherein the node tag is used to represent the code type of the front-end code corresponding to each node; the rule search unit is used to search in the preset browser compatibility database based on the node tag to obtain the preset rule corresponding to each node, wherein the preset rule is used to record the compatibility relationship between front-end code of different code types and different versions of browsers.
[0112] In one optional embodiment, the compatibility testing unit 302 includes: a version acquisition subunit and a first test result determination subunit.
[0113] Optionally, the version acquisition subunit is used to acquire the version range of all browsers recorded by the preset rules corresponding to each node; the first test result determination subunit is used to take the code location, feature name and version identifier of the front-end code corresponding to the i-th node as the first test result corresponding to the i-th node when the front-end code corresponding to the i-th node is incompatible with the browser version j recorded by the preset rules corresponding to the i-th node.
[0114] In one optional embodiment, the target node acquisition unit 303 includes a target node determination subunit.
[0115] Optionally, the target node determines the sub-unit, which is used as the target node when the front-end code of the kth node in L nodes is used to implement interface calls / to determine the rendering effect of page elements in the front-end page.
[0116] In one optional embodiment, the simulation test unit 304 includes: a front-end code execution subunit and a second test result determination subunit.
[0117] Optionally, the front-end code execution subunit is used to run the front-end code corresponding to each target node in a preset sandbox environment to obtain the actual page rendering effect of each target node; the second test result determination subunit is used to take the code location, feature name and device identifier of the terminal device simulated in the preset sandbox environment of the qth target node as the second test result corresponding to the qth target node when the actual page rendering effect of the qth target node among the M target nodes is different from the preset page rendering effect of the qth target node.
[0118] In one optional embodiment, the test report generation unit 305 includes: an initial problem list determination subunit, a repair suggestion generation subunit, a target chart generation subunit, and a test report generation subunit.
[0119] Optionally, the initial issue list determination subunit is used to determine the initial issue list based on the first test results corresponding to L nodes and the second test results corresponding to M target nodes. The initial issue list includes at least a first test issue and a second test issue. The first test issue characterizes incompatibility between the front-end code corresponding to a node and the corresponding browser version, and the second test issue characterizes errors in the page rendering effect of the front-end code corresponding to a node. The repair suggestion generation subunit is used to determine the priority of each test issue based on its impact range in the initial issue list, sort all test issues in the initial issue list based on their priority, obtain the target issue list, and generate repair suggestions for each test issue in the target issue list. The target chart generation subunit is used to generate a target chart based on the first test results corresponding to L nodes and the second test results corresponding to M target nodes. The target chart is used to visually display the browser version information compatible with the front-end code. The test report generation subunit is used to generate a test report for the front-end code based on the target issue list, the repair suggestions for each test issue, and the target chart.
[0120] It should be noted that the syntax tree generation unit 301, compatibility testing unit 302, target node acquisition unit 303, simulation testing unit 304, and test report generation unit 305 mentioned above correspond to steps S201 to S205 in the method embodiment. The instances and application scenarios implemented by the above units and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of the device and run in the computer terminal 10 provided in the embodiment.
[0121] Example 3
[0122] Embodiments of this application can also provide an electronic device. Figure 4 This is a structural block diagram of an electronic device according to an embodiment of this application, such as... Figure 4 As shown, the electronic device includes: one or more ( Figure 4 (Only one is shown) Processor 402, memory 404, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.
[0123] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and devices in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, to implement the aforementioned front-end code testing method.
[0124] The memory may include high-speed random access memory (RAM), 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 may further include memory remotely located relative to the processor, which can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks (LANs), mobile communication networks, and combinations thereof.
[0125] The processor can access information and applications stored in memory via a transmission device to perform the following steps: generating an abstract syntax tree (AST) corresponding to the front-end code, wherein the AST includes L nodes, where L is a positive integer, and the L nodes represent the code characteristics of the front-end code; based on the preset rules corresponding to each of the L nodes, detecting the compatibility relationship between the front-end code corresponding to each node and the browser, and obtaining a first test result for each node; obtaining target nodes from the L nodes, resulting in M target nodes, where M is a positive integer less than or equal to L, and the front-end code corresponding to each target node is allowed to be dynamically modified during webpage loading / running; performing simulated testing on the front-end code corresponding to each target node in a preset sandbox environment, and obtaining a second test result for each target node; and generating a test report for the front-end code based on the first test results corresponding to the L nodes and the second test results corresponding to the M target nodes.
[0126] The processor can access the information and application stored in the memory via the transmission device to perform the following steps: perform lexical analysis on the front-end code to obtain P words corresponding to the front-end code, where P is a positive integer; perform syntactic analysis on the P words to obtain the syntactic analysis results corresponding to the P words, where the syntactic analysis results are used to represent the syntactic association logic between the P words; and generate an abstract syntax tree based on the P words and the syntactic analysis results corresponding to the P words.
[0127] The processor can access the information and application stored in the memory via the transmission device to perform the following steps: obtain the node tag corresponding to each node, wherein the node tag is used to characterize the code type of the front-end code corresponding to each node; search in a preset browser compatibility database based on the node tag to obtain the preset rule corresponding to each node, wherein the preset rule is used to record the compatibility relationship between front-end code of different code types and different versions of browsers.
[0128] The processor can access the information and application stored in the memory via the transmission device to perform the following steps: obtain the version range of all browsers recorded by the preset rules corresponding to each node; if the front-end code corresponding to the i-th node in L nodes is incompatible with the j-th version of the browser recorded by the preset rules corresponding to the i-th node, use the code location, feature name, and version identifier of the j-th version of the browser of the front-end code corresponding to the i-th node as the first test result corresponding to the i-th node.
[0129] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: In the case that the front-end code of the kth node in L nodes is used to implement interface calls / to determine the rendering effect of page elements in the front-end page, the kth node is taken as the target node.
[0130] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: In a preset sandbox environment, run the front-end code corresponding to each target node to obtain the actual page rendering effect of each target node; If the actual page rendering effect of the qth target node among the M target nodes is different from the preset page rendering effect of the qth target node, take the code location, feature name and device identifier of the terminal device simulated by the preset sandbox environment of the qth target node as the second test result corresponding to the qth target node.
[0131] The processor can access information and applications stored in memory via a transmission device to perform the following steps: Based on the first test results corresponding to L nodes and the second test results corresponding to M target nodes, determine an initial problem list. The initial problem list includes at least a first test problem and a second test problem. The first test problem characterizes incompatibility between the front-end code corresponding to a node and the corresponding browser version, while the second test problem characterizes errors in the page rendering effect of the front-end code corresponding to the node. Based on the impact range of each test problem in the initial problem list, determine the priority of each test problem. Based on the priority of each test problem, sort all test problems in the initial problem list to obtain a target problem list, and generate repair suggestions for each test problem in the target problem list. Based on the first test results corresponding to L nodes and the second test results corresponding to M target nodes, generate a target chart, which visually displays the browser version information compatible with the front-end code. Based on the target problem list, the repair suggestions for each test problem, and the target chart, generate a test report for the front-end code.
[0132] This application provides a testing scheme for front-end code. First, it constructs an abstract syntax tree (AST) corresponding to the front-end code, resulting in a standardized and analyzable code form. Then, based on prediction rules that can be updated synchronously with Web standards, it performs compatibility checks on each node in the AST, achieving the goal of instantly discovering potential browser incompatibility defects in the front-end code. Simultaneously, for code segments that can be dynamically modified during runtime (i.e., the code segments corresponding to target nodes), it introduces a sandbox environment for simulation testing, thereby achieving accurate testing of the rendering effects of the dynamic characteristics of the front-end code in different browser environments. Finally, it combines the test results of compatibility testing and simulation testing to generate a test report, thus improving the technical accuracy of front-end code testing and solving the technical problem of low accuracy in test results obtained from existing front-end code testing methods.
[0133] Those skilled in the art will understand that Figure 4 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, PDAs, mobile internet devices, PADs, and other terminal devices. Figure 4 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 4 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 4 The different configurations shown.
[0134] 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.
[0135] Example 4
[0136] Embodiments of this application may also provide a storage medium.
[0137] Optionally, in this embodiment of the application, the storage medium can be used to store the program code executed by the test method of the front-end code provided in the above method embodiment.
[0138] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.
[0139] This application also provides a computer program product, which, when executed on a data processing device, is suitable for performing test method steps of front-end code.
[0140] 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.
[0141] 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.
[0142] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units 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 displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.
[0143] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0144] 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.
[0145] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of 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 a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.
[0146] 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 testing front-end code, characterized in that, include: Generate an abstract syntax tree corresponding to the front-end code, wherein the abstract syntax tree includes L nodes, where L is a positive integer, and the L nodes are used to represent the code features of the front-end code; Based on the preset rules corresponding to each of the L nodes, the compatibility relationship between the front-end code corresponding to each node and the browser is detected, and the first test result corresponding to each node is obtained. Obtain the target node from the L nodes to get M target nodes, where M is a positive integer less than or equal to L. The front-end code corresponding to each target node is allowed to be dynamically modified during the webpage loading / running process. In a preset sandbox environment, the front-end code corresponding to each target node is simulated and tested to obtain a second test result for each target node. Based on the first test results corresponding to the L nodes and the second test results corresponding to the M target nodes, a test report for the front-end code is generated.
2. The front-end code testing method according to claim 1, characterized in that, Generate the abstract syntax tree corresponding to the front-end code, including: Lexical analysis is performed on the front-end code to obtain P words corresponding to the front-end code, where P is a positive integer; Syntactic analysis is performed on the P words to obtain the syntactic parsing results corresponding to the P words, wherein the syntactic parsing results are used to characterize the syntactic association logic between the P words; The abstract syntax tree is generated based on the P words and the corresponding syntax parsing results of the P words.
3. The testing method for front-end code according to claim 1, characterized in that, Before detecting the compatibility relationship between the front-end code corresponding to each of the L nodes and the browser based on the preset rules corresponding to each node, the testing method for the front-end code further includes: Obtain the node label corresponding to each node, wherein the node label is used to characterize the code type of the front-end code corresponding to each node; Based on the node tags, a search is performed in a preset browser compatibility database to obtain preset rules corresponding to each node. The preset rules are used to record the compatibility relationship between front-end code of different code types and different versions of browsers.
4. The testing method for front-end code according to claim 1, characterized in that, Based on the preset rules corresponding to each of the L nodes, the compatibility relationship between the front-end code corresponding to each node and the browser is detected to obtain the first test result corresponding to each node, including: Obtain the version range of all browsers recorded by the preset rules corresponding to each node; If the front-end code corresponding to the i-th node among the L nodes is incompatible with the j-th version of the browser recorded by the preset rule corresponding to the i-th node, the code location, feature name, and version identifier of the j-th version of the browser corresponding to the front-end code of the i-th node shall be used as the first test result corresponding to the i-th node.
5. The testing method for front-end code according to claim 1, characterized in that, Obtaining the target node from the L nodes includes: When the front-end code of the kth node among the L nodes is used to implement interface calls or to determine the rendering effect of page elements in the front-end page, the kth node is taken as the target node.
6. The testing method for front-end code according to claim 1, characterized in that, In a preset sandbox environment, the front-end code corresponding to each target node is simulated and tested to obtain a second test result for each target node, including: In the preset sandbox environment, the front-end code corresponding to each target node is run to obtain the actual page rendering effect of each target node; If the actual page rendering effect of the qth target node among the M target nodes is different from the preset page rendering effect of the qth target node, the code location, feature name, and device identifier of the terminal device simulated by the preset sandbox environment of the qth target node shall be used as the second test result corresponding to the qth target node.
7. The testing method for front-end code according to claim 1, characterized in that, Based on the first test results corresponding to the L nodes and the second test results corresponding to the M target nodes, a test report for the front-end code is generated, including: Based on the first test results corresponding to the L nodes and the second test results corresponding to the M target nodes, an initial problem list is determined. The initial problem list includes at least a first test problem and a second test problem. The first test problem is used to characterize the incompatibility between the front-end code corresponding to the node and the corresponding browser version. The second test problem is used to characterize the page rendering effect of the front-end code corresponding to the node has errors. Based on the impact range of each test issue in the initial issue list, the priority of each test issue is determined. Based on the priority of each test issue, all test issues in the initial issue list are sorted to obtain a target issue list, and a repair suggestion is generated for each test issue in the target issue list. Based on the first test results corresponding to the L nodes and the second test results corresponding to the M target nodes, a target chart is generated, wherein the target chart is used to visually display the browser version information compatible with the front-end code; Based on the target issue list, the suggested fixes for each test issue, and the target chart, a test report for the front-end code is generated.
8. A testing device for front-end code, characterized in that, include: A syntax tree generation unit is used to generate an abstract syntax tree corresponding to the front-end code, wherein the abstract syntax tree includes L nodes, where L is a positive integer, and the L nodes are used to characterize the code features of the front-end code; The compatibility testing unit is used to detect the compatibility relationship between the front-end code corresponding to each of the L nodes and the browser based on the preset rules corresponding to each node, and to obtain the first test result corresponding to each node. The target node acquisition unit is used to acquire the target node among the L nodes to obtain M target nodes, where M is a positive integer less than or equal to L, and the front-end code corresponding to each target node is allowed to be dynamically modified during the webpage loading / running process; The simulation test unit is used to simulate the testing of the front-end code corresponding to each target node in a preset sandbox environment, and obtain the second test result corresponding to each target node. The test report generation unit is used to generate a test report for the front-end code based on the first test results corresponding to the L nodes and the second test results corresponding to the M target nodes.
9. A computer program product, characterized in that, The computer program product includes a computer program, wherein, when the computer program is run, it controls the computer program product to execute the testing method of the front-end code according to any one of claims 1 to 7.
10. An electronic device, characterized in that, It includes one or more processors and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the testing method of the front-end code according to any one of claims 1 to 7.