Multi-environment adaptive front-end automatic test method, equipment and medium

Abstract

The embodiment of the invention discloses a multi-environment adaptive front-end automatic testing method and device and a medium, and relates to the technical field of automatic testing, and the method comprises the steps: receiving an automatic testing request, obtaining environment configuration data from a multi-environment configuration center according to the automatic testing request, so as to generate a multi-environment adaptive testing matrix, the test matrix comprises a plurality of test scenes, and each test scene is associated with a scene identifier, a test step and an expected result; for each test scene in the test matrix, obtaining DOM structural features of the current test environment through a test script adaptive engine, and dynamically adjusting the test script according to the DOM structural features and environment type parameters of the current test environment to determine an adjusted test script; and executing a test by using the adjustment test script, comparing the environment consistency verification data of the same operation in different test environments, and generating a cross-environment difference report based on the environment consistency verification data.

Description

TECHNICAL FIELD

[0001] The present specification relates to the technical field of automated testing, and in particular to a multi-environment adaptive front-end automated testing method, device and medium. BACKGROUND

[0002] In the field of software testing, front-end automated testing is a key link to ensure the quality of web applications, mobile H5 and cross-end projects. With the complication of software development and deployment processes, front-end applications often need to be verified in multiple environments such as development environments, user acceptance environments and production environments to ensure functional consistency, interface compatibility and user experience stability.

[0003] In the prior art, front-end automated testing schemes are mostly based on fixed test scripts and static environment configurations. Testers usually need to write or modify test scripts for different environments (such as DEV, UAT, PROD) to adapt to the differences between environments, such as user interface element positioning methods, interface request addresses, and assertion thresholds. At the same time, in order to cover the compatibility scenarios of multiple terminal devices and browser combinations, test cases need to be manually designed, which is difficult to systematically cover all scenarios of environment, device and browser combinations. However, the test scripts of such prior art solutions are heavily dependent on the page structure and interface configuration of a specific environment, resulting in low script reuse rate across environments, and a large amount of manual work is required for script adjustment every time the environment is switched, which is not only inefficient, but also prone to human errors. Secondly, the design of test cases cannot fully cover the complex combination scenarios of multiple environments, multiple terminals and multiple browsers, resulting in test blind spots and missed compatibility problems. In the existing test process, user interface testing and interface testing are usually executed independently, and cannot effectively find interface and data inconsistency problems caused by environmental differences.

[0004] Therefore, in the process of executing multi-environment front-end automated testing in the prior art solution, there are problems of lack of environmental adaptability of test scripts and incomplete coverage of test scenario combinations, resulting in high risk of missed testing across environments and unsatisfactory testing results. SUMMARY

[0005] One or more embodiments of the present specification provide a multi-environment adaptive front-end automated testing method, device and medium to solve the technical problem that in the process of executing multi-environment front-end automated testing in the prior art solution, there are problems of lack of environmental adaptability of test scripts and incomplete coverage of test scenario combinations, resulting in high risk of missed testing across environments and unsatisfactory testing results.

[0006] One or more embodiments of the present specification adopt the following technical solutions: The one or more embodiments of the specification provide a multi-environment adapted front-end automated testing method, the method comprising: receiving an automated testing request, obtaining environment configuration data from a multi-environment configuration center with the automated testing request, and generating a multi-environment adapted testing matrix, wherein the testing matrix comprises a plurality of testing scenarios, each testing scenario being associated with a scenario identifier, a testing step, and an expected result; for each testing scenario in the testing matrix, obtaining a DOM structure feature of a current testing environment through a testing script adaptive engine, dynamically adjusting a testing script according to the DOM structure feature and an environment type parameter of the current testing environment to determine an adjusted testing script; executing a test using the adjusted testing script, and comparing environment consistency verification data of the same operation in different testing environments, and generating a cross-environment difference report based on the environment consistency verification data, wherein the environment consistency verification data comprises a user interface screenshot and interface return data.

[0007] The one or more embodiments of the specification provide a multi-environment adapted front-end automated testing device, comprising: at least one processor; and, a memory connected in communication with the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the above method.

[0008] The one or more embodiments of the specification provide a non-volatile computer storage medium, which stores computer executable instructions configured to perform the above method.

[0009] The at least one technical scheme adopted by the embodiments of the present specification can achieve the following beneficial effects: Through the technical scheme of the embodiments of the present specification, in the test preparation stage, a test matrix is constructed based on a multi-dimensional parameter space, and through a three-dimensional combination algorithm of environment types, device parameters and browser configurations, the problem of incomplete scene coverage in traditional test case design is fundamentally solved, discrete environmental elements are systematically mapped into a coordinate space, and then the mathematical completeness of the test scene is ensured through Cartesian product operation, thereby eliminating the compatibility leakage hidden danger caused by artificial design blind area; at the execution optimization level, the test script adaptive engine establishes a dynamic response of environment perception and script adjustment through real-time extraction and difference comparison of DOM structure characteristics, converts the traditional static positioning strategy into a dynamic selection algorithm based on feature vectors, and through quantitative analysis of the DOM difference feature vector, the intelligent switching of the positioning strategy is driven, so that the test script has cross-environment adaptability, effectively solving the script failure problem caused by environmental differences; at the quality verification level, a comprehensive quality evaluation system is established through two-dimensional consistency verification of UI and interface, pixel matrix analysis of the visual layer and structure metadata analysis of the data layer are combined, and through the mapping relationship between interface elements and interface data, end-to-end collaborative verification is realized, and this multi-modal verification mechanism can find the interface data asynchronization problem that is difficult to detect in traditional single-dimensional testing, and ensures the comprehensive verification of function consistency; through the deep cooperation of the three links of test preparation, execution optimization and quality verification, a self-improving test ecology is formed, the test efficiency and coverage rate are significantly improved, and through the systematic adaptive mechanism, the technical threshold of test maintenance is reduced, providing a reliable quality guarantee basis for continuous delivery. BRIEF DESCRIPTION OF DRAWINGS

[0010] In order to more clearly illustrate the technical schemes in the embodiments of the present specification or the prior art, the drawings needed to be used in the embodiment or prior art description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments described in the present specification, and those skilled in the art can also obtain other drawings according to these drawings without creative labor. In the drawings: Figure 1 A flowchart of a multi-environment adaptive front-end automated testing method provided by an embodiment of the present specification; Figure 2 A structural schematic diagram of a multi-environment adaptive front-end automated testing device provided by an embodiment of the present specification. DETAILED DESCRIPTION

[0011] In order for those skilled in the art to better understand the technical solutions in the specification, the technical solutions in the specification will be clearly and completely described in the specification below in conjunction with the drawings in the specification. Obviously, the described embodiments are only part of the embodiments of the specification, not all. Based on the embodiments of the specification, all other embodiments obtained by those skilled in the art without creative labor should be within the scope of protection of the specification.

[0012] The embodiments of the specification provide a multi-environment adaptive front-end automated testing method. It should be noted that the execution subject in the embodiments of the specification can be a server or any device with data processing capability. Figure 1 A flowchart of a multi-environment adaptive front-end automated testing method provided by the embodiments of the specification is shown in Figure 1 As shown, the method mainly includes the following steps: Step S101, receiving an automated testing request, obtaining environment configuration data from a multi-environment configuration center based on the automated testing request, and generating a multi-environment adaptive testing matrix.

[0013] The testing matrix includes a plurality of test scenarios, each test scenario is associated with a scene identifier, a test step and an expected result. The environment configuration data is obtained from the multi-environment configuration center based on the automated testing request, specifically including: parsing the test range identifier in the automated testing request, reading the environment type parameter from the multi-environment configuration center based on the test range identifier, wherein the environment type parameter includes an environment identifier and a corresponding interface domain name configuration; querying the corresponding device configuration parameter from the device parameter library according to the environment identifier in the environment type parameter, wherein the device configuration parameter includes screen resolution, device type and operating system version; obtaining the corresponding browser configuration parameter from the browser library based on the environment identifier in the environment type parameter, wherein the browser configuration parameter includes browser type and kernel version; integrating the environment type parameter, the device configuration parameter and the browser configuration parameter into an environment configuration data set, and storing the environment configuration data set to a test cache area.

[0014] In an embodiment of the specification, when the automated testing request is received, the test range identifier carried in the request is first parsed. The identifier usually exists in the form of a string or an enumeration value, which is used to specify the environment range to be covered in this test, for example, it can be specified to test only the development environment and the user acceptance environment, or it needs to cover all environment types. Based on the test range identifier, the multi-environment configuration center is accessed. The configuration center is essentially a centralized parameter management system, which stores the basic configuration information of various environments.

[0015] The system reads environment type parameters from the configuration center. These parameters are stored in key-value pairs or structured documents, containing environment identifiers and their corresponding interface domain name configurations. The environment identifiers uniquely distinguish different test environments, while the interface domain name configurations record detailed network location information such as API service addresses and resource paths for each environment. Then, based on the obtained environment identifiers, a query request is sent to the device parameter database. This database contains specifications for various terminal devices, and its data structure has been standardized. Each record includes fields such as device type, screen resolution, and operating system version. By mapping the environment identifiers to the device parameters, the system obtains the device configuration parameters supported by the current test environment. Simultaneously, based on the same environment identifier, a query request is sent to the browser database. This database stores configuration information for various browsers, including browser type, kernel version, and user agent strings. By matching the environment identifiers with the browser support list, the corresponding browser configuration parameters are obtained. After collecting all parameters, a data integration operation is performed. The data from the three dimensions—environment type parameters, device configuration parameters, and browser configuration parameters—are combined according to a predefined structure to form a complete environment configuration dataset. This dataset is organized using a unified JSON or XML format to ensure the standardization and parsability of the data fields. Finally, this environment configuration dataset is temporarily stored in a test cache. The test cache is typically implemented using an in-memory database or temporary file storage, possessing high-speed read / write capabilities to provide fast data access support for subsequent test matrix generation operations.

[0016] By constructing a multi-environment configuration center and a standardized parameter library, the system achieves systematic management and automated acquisition of test parameters, effectively solving the problems of inefficiency and error-proneness caused by manual configuration of environment parameters in traditional testing. Introducing test scope identifiers enables intelligent identification of test requirement ranges, achieving precise location and on-demand loading of test environments, avoiding unnecessary waste of test resources. Establishing a mapping between environment identifiers and device parameter libraries and browser libraries enables automatic acquisition of multi-dimensional test parameters, ensuring the consistency and integrity of test data and overcoming version inconsistencies and configuration omissions caused by manual maintenance of multiple parameter configuration files in traditional testing. Integrating scattered environment parameters, device parameters, and browser parameters into a unified environment configuration dataset achieves standardized and structured processing of test data, significantly improving its manageability and maintainability. The use of a test cache to temporarily store environment configuration data not only improves data access efficiency but also ensures data consistency and stability during testing, avoiding performance bottlenecks and data inconsistency risks that may arise from real-time queries of external data sources.

[0017] The process of generating a multi-environment adaptation test matrix includes: extracting environment type parameters, device configuration parameters, and browser configuration parameters from the environment configuration dataset and mapping these parameters to a three-dimensional coordinate space; performing a Cartesian product operation on the parameters in the three-dimensional coordinate space using a three-dimensional combination algorithm to generate an initial set of test scenarios; assigning a unique scenario identifier to each test scenario in the initial set of test scenarios and generating a corresponding test step sequence based on a pre-set test step template; obtaining the corresponding expected result template from the assertion rule base according to the environment identifier in the environment type parameter and generating expected result data for each test scenario; combining the scenario identifier, test step sequence, and expected result data into a multi-environment adaptation test matrix and storing the test matrix in the test execution queue.

[0018] In one embodiment of this specification, during the generation of the multi-environment adaptation test matrix, three key parameters are first extracted from the stored environment configuration dataset: environment type parameters, device configuration parameters, and browser configuration parameters. Environment type parameters include environment identifiers and corresponding interface domain name configurations. These parameters are stored in a structured data format and are read and converted into an internal data structure by a data parser. Device configuration parameters include detailed information such as screen resolution, device type, and operating system version. A complete list of these parameters is obtained by querying a device parameter library. Browser configuration parameters cover characteristic data such as browser type and kernel version. A complete set of these parameters is obtained by accessing a browser library.

[0019] Next, these parameters are mapped to a three-dimensional coordinate space. This process is achieved by establishing conversion rules between parameters and spatial coordinates. Environment type parameters are mapped to X-axis coordinates, with each environment type corresponding to a specific X-coordinate value; device configuration parameters are mapped to Y-axis coordinates, with different device types assigned different Y-coordinate values ​​based on their characteristics; and browser configuration parameters are mapped to Z-axis coordinates, with various browser versions assigned corresponding Z-coordinate values ​​according to their kernel type and version number. This mapping method constructs a complete three-dimensional parameter space model. Subsequently, a three-dimensional combination algorithm is used to perform a Cartesian product operation on the parameters in this three-dimensional coordinate space. This operation is achieved by traversing all parameter combinations across the three dimensions. The system first selects an environment type parameter on the X-axis, then a device configuration parameter on the Y-axis, and finally a browser configuration parameter on the Z-axis, combining these three parameters to form a test scenario. This process is repeated until all possible parameter combinations are traversed, thereby generating an initial test scenario set containing all possible combinations.

[0020] After generating the initial set of test scenarios, a unique scenario identifier is assigned to each test scenario. This process is achieved through an identifier generator, which uses specific encoding rules to encode the environment type, device characteristics, and browser information into a unique string identifier, ensuring that each test scenario has a recognizable and unique identifier. Based on pre-set test step templates, a corresponding test step sequence is generated for each test scenario. The test step templates are stored in a template library and contain standardized descriptions of various typical test operations. A suitable template is selected from the template library based on the specific characteristics of the test scenario, and parameterized replacement is performed to generate the specific test step sequence. Based on the environment identifier in the environment type parameter, the corresponding expected result template is retrieved from the assertion rule library. The assertion rule library stores the expected result standards for each environment. Through the mapping relationship between environment identifiers and assertion rules, an expected result template suitable for the current test environment is obtained. Finally, expected result data for each test scenario is generated through data population and rule application.

[0021] Finally, the scenario identifiers, test step sequences, and expected result data are combined according to a predefined structure to form a complete test scenario description. All test scenario descriptions are then organized into a multi-environment adaptation test matrix in a specific order. This test matrix uses a table or tree structure for data organization to ensure that the logical relationships and execution order between test scenarios are clear and unambiguous. Finally, the generated test matrix is ​​stored in the test execution queue, which uses a first-in-first-out data structure to provide orderly scenario scheduling support for subsequent test execution.

[0022] By establishing a parameter mapping mechanism in a three-dimensional coordinate space, the systematization and visualization management of test parameters are achieved, making the generation process of complex multi-environment test scenarios clear and controllable. By introducing a three-dimensional combination algorithm and Cartesian product operations, test scenarios covering all possible parameter combinations can be automatically generated, solving the problem of incomplete coverage caused by manually designed test cases in traditional testing. A unique scenario identifier allocation mechanism establishes a traceable identity for each test scenario, which not only facilitates the management and monitoring of the testing process but also provides convenience for attribution analysis of test results. A sequence generation method based on pre-set test step templates ensures the standardization and consistency of test steps, while significantly improving the generation efficiency of test scenarios through template processing. By establishing a correlation mechanism between environment identifiers and assertion rule bases, the expected result standards corresponding to each environment can be intelligently obtained, achieving automated generation of expected results and effectively avoiding the problem of incorrect expected result settings due to environmental differences in traditional testing. The use of a test execution queue to store the test matrix ensures the orderly execution of test scenarios, realizing batch processing and parallel execution of the testing process, significantly improving the coverage quality and generation efficiency of test scenarios.

[0023] Step S102: For each test scenario in the test matrix, the DOM structure features of the current test environment are obtained through the test script adaptive engine. Based on the DOM structure features and the environment type parameters of the current test environment, the test script is dynamically adjusted to determine the adjusted test script.

[0024] In one embodiment of this specification, each test scenario in the test execution queue is traversed, and a test script adaptive engine is launched to handle environment adaptation issues. The test script adaptive engine first obtains basic information about the current test environment through an environment detector, including environment type identifier, device characteristic parameters, and browser configuration information. Next, the engine launches a DOM parser to load the page content of the current test environment. The DOM parser accesses the target URL through the browser driver interface and obtains the complete Document Object Model (DOM) tree. After obtaining the DOM tree, a DOM structure feature extraction process is performed. This process is implemented through a feature extractor component, which traverses key interactive elements in the DOM tree, including but not limited to form input boxes, button controls, navigation elements, and data display areas, extracting a feature dataset for each element. This dataset contains structured information such as element tag name, class attribute set, ID attribute value, parent node path sequence, element hierarchy position, and visibility state. The element tag name refers to the type identifier of the HTML element; the class attribute set contains an ordered list of all CSS class names of the element; and the parent node path sequence records the complete DOM path from the root node to the current element. These feature data collectively constitute the DOM structure feature fingerprint of the current test environment. The feature extractor uses a depth-first traversal algorithm to scan the DOM tree, identify key elements with interactive functions, and generate feature description objects for each element. These objects are organized into a feature tree structure according to the logical relationship of the elements on the page.

[0025] Based on the DOM structure characteristics and the environment type parameters of the current test environment, the test script is dynamically adjusted to determine the adjusted test script. Specifically, this includes: obtaining the Document Object Model (DOM) tree structure of the current test environment through the DOM parser; extracting the DOM structure characteristics of key elements from this DOM tree structure, where the DOM structure characteristics include element tag names, class attribute sets, and parent node path sequences; comparing the DOM structure characteristics of this DOM structure with those of the baseline environment to generate a DOM difference feature vector; selecting a corresponding element positioning adjustment strategy from the positioning strategy library based on this DOM difference feature vector, where the element positioning adjustment strategy includes positioning method switching rules and positioning parameter correction rules; obtaining the corresponding interface domain name mapping rules from the environment configuration center based on the environment type parameters of the current test environment; correcting the interface request address in the test script based on this interface domain name mapping rule; and rewriting the original test script based on the element positioning adjustment strategy and the corrected interface request address to generate the adjusted test script and verify its executability.

[0026] In one embodiment of this specification, during the dynamic adjustment phase of the test script, the Document Object Model (DOM) tree structure of the current test environment is first obtained through a DOM parser. The DOM parser connects to the target test environment via a remote debugging protocol using the developer tools interface provided by the browser to obtain complete page DOM tree data. After obtaining the DOM tree structure, a depth-first traversal algorithm is used to scan the DOM tree, identifying key elements with interactive functions, including form input boxes, buttons, links, data display areas, etc., and extracting detailed DOM structure features for each key element. These features include element tag names, class attribute sets, and parent node path sequences. The element tag name records the element's HTML tag type, the class attribute set contains an ordered list of all CSS class names of the element, and the parent node path sequence records the complete hierarchical path from the root node to the current element, forming precise positioning information of the element in the DOM tree. After feature extraction is completed, the DOM structure features of the current environment are compared with the pre-stored baseline environment DOM structure features. This comparison process is implemented by a feature comparison engine, which uses a feature vector-based similarity calculation algorithm to convert the DOM structure features of the two environments into numerical vector representations. The degree of difference between the environments is quantified by calculating the cosine similarity between the vectors, and a DOM difference feature vector containing specific difference details is generated. This vector records in detail the identifier of the changed element, the changed attribute type, and the difference degree score.

[0027] Based on the generated DOM difference feature vector, the corresponding element positioning adjustment strategy is selected from the positioning strategy library. The positioning strategy library is a knowledge base containing strategies for handling various positioning scenarios, storing the mapping relationship between different difference types and positioning strategies. The rule engine analyzes the key indicators in the DOM difference feature vector, including changes in element identifiers, attribute change types, and structural change degrees, and matches the most suitable element positioning adjustment strategy from the strategy library. These strategies include positioning method switching rules and positioning parameter correction rules. The positioning method switching rules define how to dynamically switch the element positioning method under different difference scenarios, such as switching from ID positioning to CSS selector positioning, or using a composite positioning method based on text content and parent node path. The positioning parameter correction rules specify how to adjust the generation logic of positioning parameters according to specific environmental differences.

[0028] Meanwhile, based on the environment type parameters of the current test environment, the corresponding interface domain name mapping rules are obtained from the environment configuration center. The environment configuration center stores the interface service configuration information for each environment. By querying the environment identifier, the interface domain name mapping rules corresponding to the current environment are found. These rules clarify the conversion logic of the interface request address in the test script, including domain name replacement rules, path mapping relationships, and parameter adjustment strategies. Based on the obtained interface domain name mapping rules, the interface request addresses in the test script are corrected. This correction process is implemented through the address rewriter component. This component parses the interface call statements in the original test script, identifies the domain name and path parts that need to be replaced, and performs precise replacement according to the mapping rules to ensure that the interface request can correctly point to the service address of the current test environment. Finally, based on the selected element location adjustment strategy and the corrected interface request address, the original test script is rewritten. The code rewriting process is completed by the script refactoring engine. The engine first parses the abstract syntax tree of the original test script, identifies the code segments that need to be adjusted, including element location statements and interface call statements, and then refactors the corresponding code according to the determined adjustment strategy to generate an adjusted test script that meets the requirements of the current test environment. After the script is generated, the syntax correctness of the script is checked by a syntax validator, and the logical integrity of the script is verified by simulated execution to ensure that the adjusted test script is executable. Finally, the verified adjusted test script is stored in the test script library for subsequent test execution.

[0029] Compared to traditional test script maintenance methods, this approach achieves intelligent adjustment of test script element location strategies through systematic DOM structure feature analysis and difference comparison mechanisms, effectively solving the problem of element location failure caused by environmental differences. Difference quantification analysis based on feature vectors makes the selection of location strategies more accurate and reliable, overcoming the limitations of relying on manual experience in traditional methods. By establishing a linkage mechanism between the location strategy library and the environment configuration center, it can comprehensively consider the environmental differences of interface structure and interface services, achieving two-dimensional adaptive adjustment of test scripts. This ensures the complete usability of test scripts in different environments and avoids the fragmented problem often seen in traditional methods where interface tests pass but interface tests fail. Syntax verification and logic checks during code rewriting ensure the quality and reliability of the adjusted scripts, significantly reducing the risk of test interruption due to script errors. It achieves automation and intelligence in test script environment adaptation, greatly improving the reusability and maintenance efficiency of test scripts. Simultaneously, the systematic adjustment strategy ensures the consistency and accuracy of the testing process.

[0030] Step S103: Execute the test using the adjusted test script, compare the environmental consistency verification data of the same operation under different test environments, and generate a cross-environment difference report based on the environmental consistency verification data.

[0031] The environmental consistency verification data includes user interface screenshots and interface return data.

[0032] The process of executing tests using this adjusted test script includes: retrieving the test scenario to be executed from the test execution queue; loading the corresponding adjusted test script into the test execution engine; running the adjusted test script through the test execution engine; intercepting interface request and response data during execution and storing the interface request and response data in a temporary data buffer; monitoring user interface interaction events during test execution and recording interaction response time sequences and interface state change records; capturing performance indicator data during test execution, including page load time and script execution efficiency metrics; and generating a raw test result dataset when the test script execution is detected to be complete, and performing consistency verification on the raw test result dataset.

[0033] In one embodiment of this specification, during the test execution phase, test scenarios to be executed are first retrieved from the test execution queue in a first-in, first-out (FIFO) order. The test execution queue is a task queue managed based on a priority scheduling algorithm. The queue manager reads the test scenario description information from the head of the queue, including the scenario identifier, test step sequence, and expected result data. After retrieving the test scenario, the corresponding adjustment test script is retrieved from the test script library based on the scenario identifier. The adjustment test script is an executable code file that has undergone environment adaptation processing and is stored in a standard test script format. The script loader reads the code content of the adjustment test script into memory and performs syntax parsing and semantic analysis to ensure the integrity and correctness of the script. Next, the parsed adjustment test script is loaded into the test execution engine, which is an event-driven script interpreter that initializes the test runtime environment, including creating a browser instance, setting the test context, allocating system resources, and establishing a connection channel with the target test environment. During the test execution engine's operation and adjustment of test scripts, the interface interceptor component monitors network requests initiated by the scripts in real time. The interface interceptor is integrated into the network stack of the test execution engine and uses hook technology to capture all outbound and inbound HTTP / HTTPS requests, recording complete request and response data, including request URL, request header information, request body content, response status code, response header information, and response body data. These interface interaction data are stored in a temporary data buffer in chronological order. The temporary data buffer is implemented using a circular buffer data structure, which has efficient data read and write capabilities and an automatic overwrite management mechanism.

[0034] Simultaneously, user interface interaction events during test execution are monitored through event listeners. These listeners are registered in the test execution engine's DOM event system, capturing various events triggered by user actions, including click events, input events, scroll events, focus events, etc., and recording detailed information for each event, including event type, trigger timestamp, target element, and event parameters, forming a complete interaction response time sequence. A state observer also records interface state changes. This observer periodically snapshots the page DOM structure, monitoring changes in element visibility, style attributes, and content text, and associates state change information with corresponding events. For performance monitoring, a performance collector captures performance metrics during test execution. This collector utilizes the browser's performance measurement API to collect various time-series data during the page loading phase, including DOM parsing time, resource loading time, and first-screen rendering time. Simultaneously, a script execution monitor records JavaScript execution performance data, including function call time, memory usage, and garbage collection frequency. When the test execution engine detects that the test script has finished executing, whether it ends normally or abnormally, it will trigger the result collection process. This process integrates the interface request and response data scattered in the temporary data buffer, the interaction response time sequence and interface state change records recorded by the event listener, and the performance index data collected by the performance collector. The data is then standardized according to a unified data structure to generate a complete raw test result dataset.

[0035] This dataset employs a hierarchical data organization approach, classifying and storing raw test data according to multiple perspectives such as functional modules, test steps, and time dimensions to ensure data integrity and traceability. Finally, the generated raw test result dataset is transmitted to the consistency verification module, providing a data foundation for subsequent cross-environment consistency comparison and analysis. Throughout the test execution process, various runtime anomalies can be captured and handled, including network timeouts, element not found, and script execution errors, ensuring the stability and continuity of the testing process.

[0036] Compared to traditional test execution methods, this system achieves comprehensive monitoring and data collection throughout the testing process through a systematic test execution management mechanism. A first-in, first-out (FIFO) queue scheduling strategy ensures orderly execution of test scenarios, avoiding resource contention and data corruption issues caused by concurrent execution in traditional testing. An integrated test execution engine and script loading mechanism efficiently execute environment-adapted test scripts, significantly improving the stability and reliability of test execution. The application of interface interception technology comprehensively captures network interaction data during the test process, providing complete data support for subsequent interface consistency verification and overcoming the limitation of traditional testing, which can only verify interface effects but cannot monitor underlying data interactions. Simultaneously, through a dual mechanism of event listening and state observation, the correspondence between user operations and interface responses can be accurately recorded, providing detailed process data for verifying interaction logic. This integrated test execution monitoring system achieves transparent management and refined control of the testing process, significantly improving the reliability and observability of test execution, while providing ample data support for test result analysis and problem localization.

[0037] The process of comparing the consistency verification data of the same operation under different test environments includes: extracting user interface screenshots of the same operation under different test environments from the original test result dataset, converting these screenshots into pixel matrix data, performing region segmentation on the pixel matrix data to generate a set of regions to be compared, and calculating the pixel deviation rate of each region to be compared; extracting interface return data of the same operation under different test environments from the original test result dataset, parsing the structural metadata and numerical sequence of the interface return data, comparing the structural consistency and numerical consistency of the interface return data under different test environments, and generating interface difference indicators; establishing a mapping relationship table between user interface elements and interface return data, and performing collaborative consistency verification between interface data and interface data based on this mapping relationship table.

[0038] In one embodiment of this specification, user interface screenshots of the same operation under different test environments are first extracted from the original test result dataset. These screenshots are bitmap images captured by the screenshot component according to a unified standard during test execution. The image retrieval module locates and loads the corresponding screenshot files from the distributed file storage system based on the operation sequence identifier and timestamp information. After acquiring the user interface screenshots, the image processing engine converts the screenshots into pixel matrix data. This conversion process uses the standard RGB color model to quantize the color information of each pixel into a three-dimensional vector, forming a complete digital image representation. Color space standardization is applied during the conversion process to ensure that the images captured under different environments are comparable in color representation. Next, the pixel matrix data is processed for region segmentation. The region segmentation algorithm is based on computer vision technology. First, edge detection is used to identify the boundaries of interface elements in the image. Then, a region growing algorithm is used to aggregate pixels with similar visual features into continuous regions. At the same time, DOM structure information is combined to assist in region division, ensuring that the segmentation results correspond to the actual functional areas of the page. Finally, a set of comparison regions containing multiple independent regions is generated, and each region is labeled with region type, location coordinates, and size information. After completing the region segmentation, the pixel deviation rate of each region to be compared is calculated. The calculation process adopts a pixel-level comparison algorithm, which accurately registers the corresponding regions of the same operation in different environments, and then compares the differences in color values ​​pixel by pixel. The ratio of the number of mismatched pixels to the total number of pixels is counted. At the same time, the color differences are weighted to take into account the characteristics of human visual perception, so as to ensure that the calculation result of the deviation rate is consistent with the importance of visual perception.

[0039] Meanwhile, interface return data for the same operation under different test environments is extracted from the original test result dataset. This data is stored in a temporary data buffer in a structured format. The original messages returned by the interface are read by a data parser. The parsing process first identifies the data encoding format and serialization method, and then extracts structural metadata and numerical sequences according to a predefined data pattern. The structural metadata includes schema information such as field names, data types, and nesting relationships, while the numerical sequences contain the specific values ​​of each field and their standardized representations after data type conversion. Based on the parsed data, the structural consistency and numerical consistency of the interface return data under different test environments are compared. Structural consistency comparison is performed by constructing a field mapping relationship graph to check the completeness and compatibility of field definitions, including the existence of required fields, the consistency of optional fields, and the degree of matching of type definitions. Numerical consistency comparison uses a data similarity-based calculation model. The relative error is calculated for numerical data, the edit distance algorithm is used for text data, and a recursive comparison strategy is used for complex nested structure data. Finally, a comprehensive interface difference index is generated, which includes quantitative scores for both structural difference and numerical difference.

[0040] To establish a comprehensive verification system, a mapping table between user interface elements and API-returned data was constructed. This mapping is based on predefined UI-data binding rules. By analyzing the correspondence between data display elements in the user interface and API-returned fields, the association paths between interface elements and data fields are identified, forming a complete mapping table. This table records the data field identifier, data conversion rules, and display format requirements for each interface element. Based on this mapping table, a co-consistency verification of interface data and API data is performed. This verification process employs a two-way verification mechanism. On one hand, it verifies whether the data returned by the API is accurately reflected in the user interface, including the correctness of data values, the conformity of display formats, and the timeliness of data updates. On the other hand, it verifies whether the data displayed in the user interface is consistent with the data returned by the API, including the traceability of data sources and the completeness of data display. This two-way verification mechanism ensures complete synchronization between the interface display and data services, ultimately generating a comprehensive verification report encompassing three dimensions: UI consistency, API consistency, and interface data co-consistency.

[0041] Compared to traditional testing and verification methods, this approach achieves comprehensive comparison and analysis of user interface and interface data through systematic multi-dimensional consistency verification. Region segmentation based on pixel matrices and deviation rate calculation provides accurate visual consistency assessment, overcoming the subjectivity and instability of traditional manual visual inspection. Quantitative UI verification methods can detect subtle visual differences, ensuring consistent user experience across different environments. Regarding interface data verification, systematic structural metadata and numerical sequence analysis provide in-depth data consistency assurance. By establishing complete field mapping relationships and type checking mechanisms, interface compatibility issues can be identified promptly, preventing functional anomalies caused by data structure changes. Multi-level numerical comparison strategies ensure comprehensive verification of data accuracy. Through collaborative consistency verification of interface and interface data, the traditional isolation between UI testing and interface testing is broken, establishing an end-to-end data flow verification system. Two-way verification ensures complete synchronization between data display and data source, resolving interface data inconsistencies caused by data binding errors or display logic problems.

[0042] Based on the environmental consistency verification data, a cross-environment difference report is generated, which specifically includes: aggregating the pixel deviation rate and interface difference index for each test environment, and calculating the overall environmental consistency score through a weighted algorithm; identifying interface areas where the pixel deviation rate exceeds a preset threshold, and generating screenshots of the difference areas with highlights; extracting abnormal data fields from the interface difference index, and generating structured interface difference description information; and generating a cross-environment difference report based on the overall environmental consistency score, the screenshots of the difference areas, and the structured interface difference description information.

[0043] In one embodiment of this specification, detailed verification data for each test environment is collected from the environmental consistency verification results. By accessing a distributed data storage system, the corresponding pixel deviation rate and interface difference index are retrieved according to the environment identifier and time range. The pixel deviation rate originates from the region comparison results of the UI consistency verification module and is recorded as a floating-point number representing the degree of visual difference for each interface region. The interface difference index is derived from the structured and numerical analysis results of the interface consistency verification module, including scoring data for both structural and numerical differences.

[0044] The overall environmental consistency score is calculated using a weighted algorithm. The weighted algorithm is based on a multi-factor decision model. First, an evaluation index system is established, with pixel deviation rate, structural difference, and numerical difference as three basic evaluation dimensions. Then, appropriate weight coefficients are assigned to each dimension. The determination of the weight coefficients is based on historical data analysis of the impact of each dimension on user experience. Finally, the overall environmental consistency score is calculated by linear weighted summation. This score is expressed in percentage form, which intuitively reflects the overall consistency level between test environments.

[0045] After calculating the overall score, each interface area is filtered based on a preset pixel deviation rate threshold. The threshold setting takes into account human visual perception characteristics and business importance. The pixel deviation rate data of all areas to be compared is traversed to identify interface areas exceeding the preset threshold. Detailed area description information is generated for each exceeding the threshold, including area location coordinates, size, deviation rate value, and difference type classification. Based on the identified difference area information, an image labeling engine is invoked to generate highlighted screenshots of the difference areas. The image labeling engine first loads the original user interface screenshot, then draws highlighted borders on the corresponding areas according to the location coordinates of the difference areas. Different colors are used for differences of different severity. A legend is added next to the screenshot, indicating the specific deviation rate and problem description for each difference area, ultimately generating screenshots of the difference areas with clear visual indications. Meanwhile, the data anomaly detection module processes the interface difference indicators and extracts abnormal data fields from them. Anomaly detection adopts a combination of rule-based and statistical analysis methods. First, it identifies obvious abnormal fields based on predefined business rules, such as incorrect data types, missing fields, and out-of-bounds values. Then, it detects abnormal value distribution through statistical analysis methods, such as data fluctuations exceeding the normal range and imbalanced value ratios. Finally, it generates structured interface difference description information, which is organized in a standardized JSON format and includes structured fields such as abnormal field path, anomaly type, expected value, actual value, and severity level.

[0046] Finally, all analysis results are integrated through a report generator. The report generator first creates a report template, organizing the overall environment consistency score, screenshots of the difference areas, and structured interface difference descriptions in a logical order. Then, it adds background information such as basic test environment information, test time range, and execution configuration parameters. Next, it generates an execution summary section, briefly describing the overall test situation and main findings. Then, it displays the specific results of each inspection dimension in detail, including detailed analysis of UI consistency, detailed analysis of interface consistency, and results of collaborative consistency analysis. Finally, it forms a conclusion and recommendation section, pointing out issues that need to be prioritized and improvement suggestions. The final output is a complete cross-environment difference report. The report supports multiple formats such as HTML and PDF and can be viewed and filtered interactively through a web interface. All generated reports are stored in the report management system, supporting version management and historical traceability.

[0047] Compared to traditional test report generation methods, this system achieves intelligent processing and visual display of test results through systematic data aggregation and analysis. The overall environment consistency scoring based on a weighted algorithm provides an intuitive quality assessment standard, making test results comparable and traceable, helping teams quickly grasp the overall quality status. The difference area identification and marking mechanism can accurately locate interface display issues, and the visual highlighting significantly improves the efficiency of problem localization, reducing the time cost of manual troubleshooting. In terms of interface data analysis, structured anomaly descriptions provide clear diagnostic criteria, enabling developers to quickly understand the root causes of interface differences. By establishing a complete report generation system, scattered test results are integrated into a unified evaluation report, avoiding the information fragmentation problem in traditional testing. Multi-format output and interactive viewing functions enhance the practicality and operability of the reports, meeting the needs of different roles.

[0048] The method further includes: extracting test failure cases from the cross-environment difference report, analyzing the reasons for test failures and generating failure reason classification data; matching the corresponding adaptation rule update template from the rule template library based on the failure reason classification data, so as to generate adaptation rule entries according to the adaptation rule update template and the test failure cases; adding the new adaptation rule entries to the adaptation rule library and updating the rule version identifier, so as to perform backtesting on historical test failure cases based on the updated adaptation rule library and verify the effectiveness of the rule update.

[0049] In one embodiment of this specification, during the continuous optimization of the testing process, test failure cases are first extracted from the generated cross-environment difference reports. This process is implemented through a case extraction engine, which parses the structured data of the cross-environment difference reports and identifies test failure cases according to preset failure judgment rules. The failure judgment rules are comprehensively formulated based on multiple dimensions such as overall environment consistency score, pixel deviation rate threshold, and interface difference index. The data filtering module retrieves test records that meet the conditions from the report database. The extracted test failure cases contain complete test environment information, execution process data, and difference analysis results.

[0050] After acquiring test failure cases, the failure cause analysis module is activated. This module employs a combination of rule-based reasoning and machine learning. First, the test failure cases undergo data preprocessing, including cleaning invalid data, standardizing data formats, and extracting key features. Then, a predefined analysis rule library is applied through the rule reasoning engine. This rule library contains cause mapping relationships for various common failure scenarios; for example, element location failure may be caused by changes in DOM structure, attribute value modifications, or page layout adjustments. Simultaneously, a machine learning model is integrated. This model, trained on historical failure cases, can identify complex failure patterns and provide cause inferences. The analysis process comprehensively considers multiple information sources, including test execution logs, differences in screenshots, and abnormal API return data. Finally, structured failure cause classification data is generated. This data is organized according to dimensions such as failure type, root cause, and scope of impact, and each cause is labeled with a confidence score.

[0051] Based on the generated failure cause classification data, the system matches the corresponding adaptation rule update template from the rule template library. The rule template library is a knowledge base that stores various adaptation scenario response strategies. Each template is designed with corresponding rule update logic for a specific type of failure cause. The system matches the failure types in the failure cause classification data with the templates in the rule template library through a template matching algorithm. The matching process considers factors such as the similarity of failure features, historical processing effect evaluation, and environmental characteristics to ensure that the most suitable adaptation rule update template is selected.

[0052] Based on the matched adaptation rule update template and specific test failure cases, a new adaptation rule entry is created through the rule generator. The rule generator first parses the structure of the adaptation rule update template, identifies the parameters that need to be filled and the logic parts that need to be adjusted, and then extracts specific environmental parameters, element characteristics, interface configurations and other actual data from the test failure cases. This data is formatted according to the template requirements and injected into the corresponding position in the template. At the same time, the applicable conditions and execution parameters of the rules are adjusted according to the specific situation of the failure cases. Finally, a complete adaptation rule entry is generated, which contains complete information such as rule identifier, rule type, triggering conditions, execution actions, priority settings and so on.

[0053] Newly generated adaptation rule entries are added to the adaptation rule base using versioned database transactions, ensuring the atomicity and consistency of data operations. Simultaneously, rule version identifiers are updated. Semantic version management is employed, using major, minor, and revision numbers to indicate the extent of changes to the rule base. The version management module automatically records the changes, update time, and associated failure cases for each rule update, forming a complete change history. Based on the updated adaptation rule base, a backtracking test verification mechanism is initiated. This mechanism first retrieves test scenarios similar to current failure cases from the historical test case library, then re-executes these test cases using the updated rules. During backtracking testing, detailed records are kept of rule application, test execution results, and performance metric changes. The effectiveness of the rule update is verified by comparing the pass rate, execution efficiency, and problem-solving effectiveness before and after the update. A detailed verification report is generated, including indicators such as rule application success rate, problem-solving rate, and performance impact assessment, providing data support for subsequent rule optimization. A continuous rule effectiveness monitoring mechanism is also established to periodically evaluate rule performance in real-world testing environments, ensuring continuous optimization and improvement of the rule base.

[0054] Through the technical solutions of the embodiments in this specification, in the test preparation stage, a test matrix is ​​constructed based on a multi-dimensional parameter space. A three-dimensional combination algorithm of environment type, device parameters, and browser configuration fundamentally solves the problem of incomplete scenario coverage in traditional test case design. Discrete environmental elements are systematically mapped into coordinate space, and Cartesian product operations ensure the mathematical completeness of the test scenario, thereby eliminating the potential for compatibility omissions caused by blind spots in manual design. At the execution optimization level, the test script adaptive engine establishes a dynamic response of environmental awareness and script adjustment through real-time extraction and difference comparison of DOM structure features. This transforms the traditional static positioning strategy into a dynamic selection algorithm based on feature vectors. Quantitative analysis of DOM difference feature vectors drives intelligent switching of positioning strategies, enabling the test script to possess… Cross-environment adaptability effectively solves the problem of script failure caused by environmental differences. At the quality verification level, a comprehensive quality assessment system is established through dual-dimensional consistency verification of UI and interface. It combines pixel matrix analysis of the visual layer with structural metadata parsing of the data layer, and achieves end-to-end collaborative verification by establishing a mapping relationship between interface elements and interface data. This multimodal verification mechanism can discover interface data inconsistencies that are difficult to detect in traditional single-dimensional testing, ensuring comprehensive verification of functional consistency. Through deep collaboration among the three stages of test preparation, execution optimization, and quality verification, a self-improving test ecosystem is formed, which significantly improves test efficiency and coverage. The systematic adaptive mechanism lowers the technical threshold for test maintenance and provides a reliable quality assurance foundation for continuous delivery.

[0055] This specification also provides an automated front-end testing device that adapts to multiple environments, such as... Figure 2 As shown, the device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the above-described method.

[0056] This specification also provides a non-volatile computer storage medium storing computer-executable instructions configured to perform the above-described method.

[0057] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0058] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A multi-environment adaptable front-end automated testing method, characterized in that, The method includes: Receive an automated test request, and obtain environment configuration data from a multi-environment configuration center based on the automated test request to generate a multi-environment adaptation test matrix. The test matrix includes multiple test scenarios, and each test scenario is associated with a scenario identifier, test steps, and expected results. For each test scenario in the test matrix, the DOM structure features of the current test environment are obtained through the test script adaptive engine. Based on the DOM structure features and the environment type parameters of the current test environment, the test script is dynamically adjusted to determine the adjusted test script. The test is executed using the adjusted test script, and the environmental consistency verification data of the same operation in different test environments is compared. Based on the environmental consistency verification data, a cross-environment difference report is generated, wherein the environmental consistency verification data includes user interface screenshots and interface return data.

2. The multi-environment adaptable front-end automated testing method according to claim 1, characterized in that, The automated test request retrieves environment configuration data from the multi-environment configuration center, specifically including: The test scope identifier in the automated test request is parsed, and the environment type parameter is read from the multi-environment configuration center based on the test scope identifier. The environment type parameter includes an environment identifier and the corresponding interface domain name configuration. Based on the environment identifier in the environment type parameter, the corresponding device configuration parameters are queried from the device parameter library, wherein the device configuration parameters include screen resolution, device type and operating system version; Based on the environment identifier in the environment type parameter, the corresponding browser configuration parameters are obtained from the browser library, wherein the browser configuration parameters include browser type and kernel version; The environment type parameters, device configuration parameters, and browser configuration parameters are integrated into an environment configuration dataset, and the environment configuration dataset is stored in the test cache area.

3. The multi-environment adaptable front-end automated testing method according to claim 1, characterized in that, Generate a multi-environment adaptation test matrix, specifically including: Extract environment type parameters, device configuration parameters, and browser configuration parameters from the environment configuration dataset, and map the parameters to a three-dimensional coordinate space; The parameters in the three-dimensional coordinate space are subjected to Cartesian product operation by a three-dimensional combination algorithm to generate an initial test scene set. Assign a unique scenario identifier to each test scenario in the initial test scenario set, and generate a corresponding test step sequence based on a preset test step template; Based on the environment identifier in the environment type parameter, the corresponding expected result template is obtained from the assertion rule base to generate expected result data for each test scenario; The scenario identifier, test step sequence, and expected result data are combined into a multi-environment adaptation test matrix, and the test matrix is ​​stored in the test execution queue.

4. The multi-environment adaptable front-end automated testing method according to claim 1, characterized in that, Based on the DOM structure characteristics and the environment type parameter of the current test environment, the test script is dynamically adjusted to determine the adjusted test script, specifically including: The document object model tree structure of the current test environment is obtained through the DOM parser, and the DOM structure features of key elements are extracted from the document object model tree structure. The DOM structure features include element tag names, class attribute sets and parent node path sequences. The DOM structure features are compared with the DOM structure features of the baseline environment to generate a DOM difference feature vector; Based on the DOM difference feature vector, a corresponding element positioning adjustment strategy is selected from the positioning strategy library, wherein the element positioning adjustment strategy includes positioning mode switching rules and positioning parameter correction rules; Based on the environment type parameters of the current test environment, obtain the corresponding interface domain name mapping rules from the environment configuration center, and correct the interface request address in the test script based on the interface domain name mapping rules; Based on the element location adjustment strategy and the corrected interface request address, the original test script is rewritten to generate an adjusted test script and verify its executability.

5. The multi-environment adaptable front-end automated testing method according to claim 1, characterized in that, Executing tests using the adjusted test script specifically includes: The test scenario to be executed is obtained from the test execution queue, and the corresponding adjustment test script is loaded into the test execution engine so that the adjustment test script can be run through the test execution engine. During the execution process, interface request and response data are intercepted and the interface request and response data are stored in a temporary data buffer. Monitor user interface interaction events during test execution, and record the interaction response time sequence and interface state change records; Capture performance metrics data during test execution, including page load time and script execution efficiency metrics. When the test script is detected to have completed execution, a raw test result dataset is generated to perform a consistency check on the raw test result dataset.

6. The multi-environment adaptable front-end automated testing method according to claim 1, characterized in that, Comparing the environmental consistency verification data of the same operation under different test environments, specifically including: Extract user interface screenshots of the same operation under different test environments from the original test result dataset, convert the user interface screenshots into pixel matrix data, perform region segmentation processing on the pixel matrix data, generate a set of regions to be compared, and calculate the pixel deviation rate of each region to be compared. Extract the interface return data of the same operation in different test environments from the original test result dataset, parse the structural metadata and numerical sequence of the interface return data, compare the structural consistency and numerical consistency of the interface return data in different test environments, and generate interface difference indicators. Establish a mapping table between user interface elements and interface returned data, and perform collaborative consistency verification between interface data and interface data based on the mapping table.

7. The multi-environment adaptable front-end automated testing method according to claim 6, characterized in that, Based on the aforementioned environment consistency verification data, a cross-environment difference report is generated, specifically including: The pixel deviation rate and interface difference index of each test environment are aggregated, and the overall environment consistency score is calculated by weighting algorithm; Identify interface areas where the pixel deviation rate exceeds a preset threshold and generate a screenshot of the difference area with highlights; Extract abnormal data fields from the interface difference metrics and generate structured interface difference description information; Based on the overall environment consistency score, screenshots of the differences, and structured interface difference descriptions, a cross-environment difference report is generated.

8. The multi-environment adaptable front-end automated testing method according to claim 1, characterized in that, The method further includes: Extract test failure cases from the cross-environmental difference report, analyze the reasons for test failures, and generate failure reason classification data; Based on the failure reason classification data, the corresponding adaptation rule update template is matched from the rule template library to generate adaptation rule entries according to the adaptation rule update template and the test failure cases. The aforementioned adaptation rule entries are added to the adaptation rule library, and the rule version identifier is updated. Based on the updated adaptation rule library, backtesting is performed on historical test failure cases to verify the effectiveness of the rule update.

9. A multi-environment adaptable front-end automated testing device, characterized in that, The device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1-8.

10. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are configured to perform the method as described in any one of claims 1-8.

Images