Web automatic test and report generation method and device supporting multi-site switching

Abstract

The invention relates to the technical field of software testing, and provides a Web automatic testing and report generating method and device supporting multi-site switchover, and the method comprises the steps: reading a configuration file containing a plurality of site definitions and a test step sequence, and initializing a browser driving engine and a screenshot storage directory; traversing all sites defined in the configuration file, creating an independent browser context for each site, and navigating to an initial uniform resource locator address of the site; for each site, executing each operation step defined in the test step sequence in sequence, after each step is executed, performing screenshot on the current page, and storing a screenshot file according to a preset unified naming rule; after all site tests are executed, all screenshot files generated in the execution process are compressed into archived files, and a test completion report containing execution statistical information and archived file paths is output. According to the invention, the efficiency and reliability of multi-environment regression testing can be improved.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a method and device for web automated testing and report generation that supports multi-site switching. Background Technology

[0002] As software systems become more complex and enterprises adopt multi-environment deployment models (such as development, testing, pre-release, and production environments), testing teams need to frequently execute the same or similar regression test cases in different environments.

[0003] Currently, commonly used automated testing solutions in the industry can be mainly divided into three categories: script-based testing based on underlying frameworks such as Selenium and Playwright; test result aggregation platforms based on reporting tools such as Allure and ExtendReport; and recording and playback tools based on browser plugins. While existing automated testing tools can perform operations, they still have the following shortcomings and deficiencies in areas such as multi-environment test management, step-by-step visual evidence collection, exception handling mechanisms, and one-click report generation:

[0004] First, multi-environment testing lacks a unified and automated process control mechanism. In multi-site testing scenarios, traditional methods require writing independent scripts for each environment or manually maintaining environment variables, which is prone to errors during switching. At the same time, the isolation of browser sessions and cookie states usually relies on manual cleanup or the use of different browser configuration files, which is complex to manage, prone to cross-contamination between environments, affects the accuracy of test results, and significantly increases script maintenance costs.

[0005] Second, there is a lack of effective bridging between the code generated by recording tools and configuration-driven test modes. Existing recording tools (such as Playwright Codegen) can generate automated scripts in specific languages, but they cannot be directly converted into structured configuration files. If the recording results need to be converted into a configurable JSON list of steps, manual parsing and conversion are required, which is cumbersome, error-prone, and detrimental to the accumulation of test assets and reuse across multiple environments.

[0006] Third, the step-by-step screenshot mechanism is inadequate, lacking unified naming and archiving management. It only supports manual invocation of the screenshot interface at key steps, failing to guarantee corresponding screenshot evidence for every operation. The generated screenshot files have scattered and inconsistent naming conventions, lacking a unified naming logic that includes the environment, step number, operation description, and timestamp. This makes later organization difficult, hindering the formation of an intuitive, visually appealing chain of evidence, and impacting the efficiency of problem identification and report preparation.

[0007] Fourth, the exception handling mechanism is weak, and the support for task continuity is insufficient. If traditional scripts encounter exceptions such as element location failure during execution, they often directly throw an error and terminate the entire test process. This makes it impossible to obtain context information after the failure, which is not conducive to a comprehensive analysis of the scope of the failure's impact. They generally lack flexible and controllable exception handling strategies and the ability to record error information in a structured manner.

[0008] Fifth, the test execution and report generation processes are fragmented and have low integration. Existing solutions typically require the combined use of multiple tools: an automation framework handles execution, a reporting framework handles result display, additional scripts handle screenshot packaging, and then manual insertion of screenshots into the report template. This process is costly and disjointed, hindering small and medium-sized teams from quickly implementing an integrated automated testing and reporting workflow.

[0009] Chinese patent CN109446105A discloses a web application testing method. This method achieves lightweight multi-browser compatibility testing on a single device, with advantages including saving hardware resources and supporting parallel testing and basic result recording. However, this solution has significant shortcomings in multi-environment support, step-by-step visual evidence chain construction, recording and configuration conversion, anomaly handling flexibility, and integrated report generation. It has not yet formed an automated testing and report generation system that is multi-environmental, end-to-end, and highly available for enterprises.

[0010] Therefore, how to provide a systematic solution that integrates configuration management, automatic switching between multiple sites, step-level screenshot archiving, reversible execution of exceptions, and one-click report generation has become an urgent technical problem to be solved. Summary of the Invention

[0011] In view of this, in order to overcome the shortcomings of the prior art, the present invention aims to provide a method and device for web automation testing and report generation that supports multi-site switching.

[0012] According to a first aspect of the present invention, a method for web automation testing and report generation supporting multi-site switching is provided, the method comprising:

[0013] Step S1: Read the configuration file containing multiple site definitions and test step sequences, and initialize the browser driver engine and screenshot storage directory;

[0014] Step S2: Iterate through all the sites defined in the configuration file, create an independent browser context for each site, and navigate to the starting Uniform Resource Locator (URL) address of that site;

[0015] Step S3: For each site, execute each operation step defined in the test step sequence in sequence. After each step is completed, take a screenshot of the current page and save the screenshot file according to the preset unified naming rules.

[0016] Step S4: After all site tests are completed, compress all screenshot files generated during this execution into an archive file and output a test completion report containing execution statistics and the archive file path.

[0017] Optionally, in the Web automation testing and report generation method supporting multi-site switching of the present invention, the configuration file in step S1 is a structured data file, which includes:

[0018] A list of sites that defines multiple test environments, each consisting of an environment name and an initial Uniform Resource Locator (URL).

[0019] A list of steps that defines a sequence of test steps to be executed sequentially. Each step sequence includes a step type, an element locator, optional input values, optional wait times, and step description information.

[0020] And at least one execution control parameter, which defines whether to continue execution when a step fails and the root directory path for storing screenshot files.

[0021] Optionally, in the Web automation testing and report generation method supporting multi-site switching of the present invention, in step S1, during the initialization of the browser driver engine, the browser startup parameters are set to ignore Secure Sockets Layer Transport Layer security certificate errors in the following manner: the browser driver engine's ignore certificate error parameter is set to true, so that the test system can normally access and use the internal test environment site with self-signed certificates or untrusted certificates.

[0022] Optionally, the Web automation testing and report generation method supporting multi-site switching of the present invention converts the operation code generated by the graphical recording tool into a structured list of steps in the configuration file before step S1 in the following manner:

[0023] Complete the business operation process on the target webpage and generate script code containing page operation instructions using the browser frame's recording tool;

[0024] Extract the operation statements from the script code and input them into the conversion script. The conversion script parses the operation statements to identify the operation instructions, including the operation function type, element selector, and input text content.

[0025] Each parsed operation instruction is converted into a step object with standardized fields, and the sequence of all step objects is written into the step list field of the configuration file.

[0026] Optionally, in the Web automation testing and report generation method supporting multi-site switching of the present invention, in step S2, an independent browser context is created for each site in the following manner: by calling the application interface of the browser driver engine, a new browser context object or page object is created for the site currently being traversed. The newly created browser context object or page object has independent session storage, local storage and cookie storage mechanisms.

[0027] Optionally, in the Web automation testing and report generation method supporting multi-site switching of the present invention, step S3 involves executing each operation step defined in the test step sequence in the following manner:

[0028] Based on the step type field in the current step object, identify the browser operation category corresponding to the step. This operation category includes clicking an element, entering text, waiting for a specified time or for an element to appear, and jumping to a new page.

[0029] Based on the element locator information defined in the current step object, locate the target element on the page and call the application interface in the browser driver engine that matches the operation category to perform the corresponding action;

[0030] During the execution of each step, exceptions are captured. When an element location fails, an operation times out, or other execution exceptions occur, error information is recorded. Based on the execution control parameters defined in the configuration file, it is decided to skip the current step and continue to execute subsequent steps or terminate the remaining test process of the current site.

[0031] Optionally, in the Web automation testing and report generation method supporting multi-site switching of the present invention, step S3 presets a unified naming rule as follows: the screenshot file name is combined with a specific order and a connector, and its format includes an environment name part, a step number part, an operation description part, and a timestamp part. The environment name part is taken from the environment identifier of the current execution site, the step number part is the sequential number of the step in the step list, the operation description part is taken from the step description information field of the step, and the timestamp part is the system time when the step is completed.

[0032] Optionally, in the Web automation testing and report generation method supporting multi-site switching of the present invention, in step S4, all screenshot files generated during this execution process are compressed into an archive file in the following manner:

[0033] Traverse and collect all screenshot files generated in the screenshot storage directory and their respective site subdirectories during this test execution;

[0034] The program calls a built-in or third-party compression library to package all collected screenshot files and directory structures into a compressed archive file. The internal directory hierarchy of the compressed archive file is consistent with the original screenshot storage structure, and the file arrangement order corresponds to the time order of the test execution.

[0035] Optionally, in the Web automation testing and report generation method supporting multi-site switching of the present invention, in step S4, the execution statistics information of the test completion report includes the total number of sites that have performed the test, the total number of steps that have been executed at each site, the number of steps that have been successfully executed at all sites, the number of steps that have failed to be executed at all sites, and a summary of the main abnormal events recorded during the test execution. The archive file path of the test completion report is the complete location address of the generated compressed archive file in the storage system.

[0036] According to a second aspect of the present invention, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first aspect of the present invention.

[0037] This invention supports a method and device for web automation testing and report generation that supports multi-site switching. It effectively solves the accuracy problems and script maintenance complexity issues caused by state crosstalk in traditional multi-environment testing, improving the efficiency and reliability of multi-environment regression testing. It achieves a seamless transition from rapidly recorded exploratory testing to maintainable and reusable configuration-driven testing, reducing the technical threshold and maintenance costs of automated testing. It provides intuitive and traceable graphic evidence for test reports, greatly facilitating problem localization, result verification, and cross-team communication. It avoids the limitation of traditional scripts where "single point of failure means total interruption," improving the fault tolerance and information collection integrity of testing. It significantly reduces the manual cost of test result organization and report compilation. It enhances adaptability to complex enterprise testing environments, adapting to testing needs of different scales and complexities. Attached Figure Description

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

[0039] Figure 1 This is a flowchart illustrating a web automation testing and report generation method supporting multi-site switching according to an exemplary embodiment 1 of the present invention;

[0040] Figure 2This is a schematic diagram illustrating multi-site switching and state isolation in a Web automation testing and report generation method supporting multi-site switching according to an exemplary embodiment 1 of the present invention.

[0041] Figure 3 This is a schematic diagram illustrating the action replay and screenshot naming of the Web automation testing and report generation method supporting multi-site switching according to an exemplary embodiment 2 of the present invention;

[0042] Figure 4 This is a schematic diagram of the structure of the device provided by the present invention. Detailed Implementation

[0043] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0044] It should be noted that, in the absence of conflict, the following embodiments and features can be combined with each other; and, based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0045] It should be noted that various aspects of the embodiments described below are within the scope of the appended claims. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0046] Example 1

[0047] Exemplary embodiment 1 of the present invention provides a method for web automation testing and report generation that supports multi-site switching. Figure 1 This is a flowchart illustrating a web automation testing and report generation method supporting multi-site switching according to an exemplary embodiment 1 of the present invention, as shown below. Figure 1 As shown, the method of this embodiment is implemented in the following manner:

[0048] Step S1: Read the configuration file containing multiple site definitions and test step sequences, and initialize the browser driver engine and screenshot storage directory.

[0049] In this embodiment, the configuration file is a structured data file, which includes:

[0050] A list of sites that defines multiple test environments, each consisting of an environment name and an initial Uniform Resource Locator (URL).

[0051] A list of steps that defines a sequence of test steps to be executed sequentially. Each step sequence includes a step type, an element locator, optional input values, optional wait times, and step description information.

[0052] And at least one execution control parameter, which defines whether to continue execution when a step fails and the root directory path for storing screenshot files.

[0053] In this embodiment, the operation code generated by the graphical recording tool is converted into a structured list of steps in the configuration file in the following manner:

[0054] The business operation process is completed on the target webpage, and the browser frame's recording tool generates script code containing page operation instructions. The operation statements in the script code are extracted and input into the conversion script. The conversion script parses the operation statements and identifies the operation instructions, including the operation function type, element selector, and input text content. Each parsed operation instruction is converted into a step object with standardized fields, and the sequence of all step objects is written into the step list field of the configuration file.

[0055] In this embodiment, Playwright can be used as the browser driver, or other browser automation frameworks such as Selenium and Puppeteer can be used, as long as the corresponding API is adapted in the step execution module; the ignore_https_errors mechanism can be implemented in other frameworks by customizing browser startup parameters.

[0056] In a specific scenario, the method of this embodiment converts recorded code into a list of steps. In this scenario, the code generated by Playwright codegen is converted into a list of steps in config.json. Specifically, this is implemented as follows:

[0057] 1. Recording Operation

[0058] Users use playwright codegen <url>Turn on recording mode and complete the entire business process in the browser; the recording tool will automatically generate operation code in the corresponding language (such as Python), including statements such as page.goto, page.click, and page.fill.

[0059] 2. Copy the core code

[0060] Users copy code snippets (which can be in text format) of key business paths from the recording results; then paste these snippets into the Python conversion script provided by this invention.

[0061] 3. Parse operation statements

[0062] Python scripts can parse input code snippets using simple string matching and regular expressions to identify statements such as page.click("selector") and page.fill("selector", "text").

[0063] 4. Generate step objects

[0064] For each parsed operation statement, construct a standardized step object, for example:

[0065] {"type": "click", "selector": "...", "description": "Click the login button"}

[0066] {"type": "fill", "selector": "...", "value": "username", "description": "Enter username"}

[0067] If you encounter a time.sleep or explicit wait, you can convert it to a wait type step.

[0068] 5. Write to config.json

[0069] The generated list of steps is written to or updates the step fields in config.json. At this point, the recording results are transformed into a configuration-driven format, and subsequent test execution is entirely determined by config.json, eliminating the need to directly modify the execution script. It should be noted that in practical applications, besides JSON, the method in this embodiment can also use YAML, XML, database tables, etc., as configuration data storage formats, as long as they can express the structure of the site list and step list.

[0070] It should be noted that in this embodiment, during the initialization of the browser driver engine, the browser startup parameters are set in the following way to ignore Secure Sockets Layer Transport Layer security certificate errors: the browser driver engine's ignore certificate error parameter is set to true, so that the test system can normally access and use the internal test environment site with self-signed certificates or untrusted certificates.

[0071] Step S2: Iterate through all the sites defined in the configuration file, create an independent browser context for each site, and navigate to the starting Uniform Resource Locator (URL) of that site.

[0072] In this embodiment, an independent browser context is created for each site in the following way: by calling the application programming interface of the browser driver engine, a new browser context object or page object is created for the site currently being traversed. The newly created browser context object or page object has independent session storage, local storage and cookie storage mechanisms, thereby ensuring that the user session state and page browsing state between each site are completely isolated, effectively preventing state interference between different test environments. Figure 2 This is a schematic diagram illustrating multi-site switching and state isolation in a web automation testing and report generation method supporting multi-site switching according to an exemplary embodiment 1 of the present invention.

[0073] Step S3: For each site, execute each operation step defined in the test step sequence in sequence. After each step is completed, take a screenshot of the current page and save the screenshot file according to the preset unified naming rules.

[0074] In this embodiment, each operation step defined in the test step sequence is executed sequentially in the following manner:

[0075] Based on the step type field in the current step object, identify the browser operation category corresponding to the step. This operation category includes clicking an element, entering text, waiting for a specified time or for an element to appear, and jumping to a new page.

[0076] Based on the element locator information defined in the current step object, locate the target element on the page and call the application interface in the browser driver engine that matches the operation category to perform the corresponding action;

[0077] During the execution of each step, exceptions are captured. When an element location fails, an operation times out, or other execution exceptions occur, error information is recorded. Based on the execution control parameters defined in the configuration file, it is decided to skip the current step and continue to execute subsequent steps or terminate the remaining test process of the current site.

[0078] In practical applications, the execution control strategy in this exception capture mechanism supports extended configuration. This extended configuration allows for more granular exception handling behavior to be defined for individual steps or globally in the step list in the configuration file. For example, it can define the number of automatic retries after a failure of a specific step, define a specific recovery operation sequence to be executed after a failure of a specific step, and define a unified response mode for the entire test process when encountering different types of exceptions.

[0079] For example, in addition to the "continue execution" and "terminate execution" modes, the method in this embodiment can achieve: automatically retrying a certain step a certain number of times; executing specific recovery steps (such as refreshing the page or logging in again) after failure; the configuration of such strategies can be added to config.json, for example, defining retry_times and on_fail_action for each step.

[0080] In this embodiment, a unified naming rule is preset as follows: the screenshot file name is combined with a specific order and a connector. Its format includes an environment name part, a step number part, an operation description part, and a timestamp part. The environment name part is taken from the environment identifier of the current execution site, the step number part is the sequential number of the step in the step list, the operation description part is taken from the step description information field of the step, and the timestamp part is the system time when the step is completed.

[0081] Step S4: After all site tests are completed, compress all screenshot files generated during this execution into an archive file and output a test completion report containing execution statistics and the archive file path.

[0082] In this embodiment, all screenshot files generated during this execution process are compressed into an archive file in the following manner:

[0083] Iterate through and collect all screenshot files generated in the screenshot storage directory and their respective site subdirectories during this test execution; call the compression library built into the programming language or provided by a third party to package all collected screenshot files and directory structures into a compressed archive file. The internal directory hierarchy of this compressed archive file is consistent with the original screenshot storage structure, and the file arrangement order corresponds to the time order of the test execution.

[0084] In this embodiment, the execution statistics of the test completion report include the total number of sites that have performed the test, the total number of steps executed at each site, the number of steps successfully executed at all sites, the number of steps that failed to execute at all sites, and a summary of the main abnormal events recorded during the test execution. The archive file path of the test completion report is the complete location address of the generated compressed archive file in the storage system.

[0085] Example 2

[0086] An exemplary embodiment of the present invention provides a method for web automation testing and report generation that supports multi-site switching. The method of this embodiment is implemented in the following manner:

[0087] I. Initialization Phase

[0088] 1. Read configuration

[0089] Load the configuration file config.json from the preset path. The configuration file must include at least the following:

[0090] The sites list: Each element contains the environment name (e.g., env_name), the starting URL (e.g., base_url), etc.

[0091] The steps list: Each element is a step object, which contains step type (e.g., type), locator (e.g., selector), input value (e.g., value), wait time, description information, etc.

[0092] Execution parameters: such as whether to continue execution in case of an error (continue_on_error), screenshot directory path (screenshot_dir), etc.

[0093] 2. Start the engine

[0094] Start the Playwright engine, create a browser instance (e.g., Chromium), and set the parameter ignore_https_errors=True to ignore HTTPS errors that may be caused by internal testing environments or self-signed certificates; you can choose whether to enable headless mode or visual mode depending on the configuration.

[0095] 3. Clean up the old screenshot directory

[0096] Check if the screenshot directory exists. If it does, delete the old screenshot directory and its contents. Create a clean new screenshot root directory to store the results of this execution. You can also initialize a log file to record the execution process.

[0097] II. Environmental Cycle Stage

[0098] 1. Traverse the list of URLs

[0099] Read the list of sites from config.json; perform the following operations on each site object in the list: retrieve the environment name env_name and the initial URL base_url from the site object; and record the current environment information in the log.

[0100] 2. Create an independent browser context for each site.

[0101] Create a new browser context or page for the current site, ensuring that: states such as cookies, localStorage, and sessionStorage are not shared between different sites; and that multiple sites do not interfere with each other even if they use the same domain name or path.

[0102] 3. Navigate to the site homepage

[0103] Use Playwright's page.goto(base_url) to navigate to the current site's starting page; if necessary, you can take a screenshot to record the initial state after successful loading.

[0104] III. Action Cycle Phase

[0105] For each site, the action loop is executed after the environment loop phase:

[0106] 1. List of traversal steps

[0107] Read the list of steps from config.json; for each step, identify its operation type based on its type field, such as:

[0108] click: Click operation;

[0109] fill: Input operation;

[0110] wait: wait for an operation (fixed time or wait for an element to appear);

[0111] navigate: navigates to a specific URL;

[0112] Other interactive actions such as check / uncheck / select (optional extensions).

[0113] 2. Perform the operation

[0114] The execution logic is as follows, depending on the different types of steps:

[0115] For the click step: Use Playwright to locate the element based on the selector field (such as CSS selectors, XPath, text selectors, etc.); call page.click(selector) to complete the click operation.

[0116] For the fill step: locate the input box element based on the selector; use page.fill(selector, value) to fill in the content of the value field in the configuration.

[0117] For the wait step: if configured to wait for a fixed time, call page.wait_for_timeout(ms); if configured to wait for a specific element to appear, call page.wait_for_selector(selector).

[0118] For other step types, the corresponding Playwright operation is executed according to the configuration definition.

[0119] 3. Secure evidence (screenshots)

[0120] Take a screenshot after each step is completed (regardless of success or failure):

[0121] Construct the screenshot file name, following the naming convention: environment_step_description_timestamp.png. Where:

[0122] The environment name is the current env_name;

[0123] The step number is the sequential number of the current step in the list of steps;

[0124] The operation description can be obtained from the description field of steps;

[0125] The timestamp is the system time (to the second or to the millisecond) at which this step was performed.

[0126] Call page.screenshot(path=filename, full_page=True) or an equivalent command to save the file to a subdirectory corresponding to the current environment, such as screenshot_dir / env_name / .

[0127] 4. Exception Detection and Handling

[0128] Use an exception handling structure when executing each step:

[0129] If exceptions such as element non-existence, location failure, or timeout are detected, then: record the error log (including error type, step information, etc.); generate an error status screenshot and identify the error type in the filename (e.g., append '_error' to the description); determine subsequent actions based on the configuration option `continue_on_error`.

[0130] If true, skip the current step and continue to the next step;

[0131] If false, the remaining steps in the current environment will be terminated, and the process will proceed to the closing stage or switch to the next environment.

[0132] 5. Write back the results of each step

[0133] The execution results of each step (success / failure, time taken, screenshot path, etc.) are written back to an in-memory structure or log file to provide a data source for generating higher-level reports later. Figure 3 This is a schematic diagram illustrating the action replay and screenshot naming for the Web automation testing and report generation method supporting multi-site switching according to an exemplary embodiment 2 of the present invention.

[0134] IV. Final Stage

[0135] 1. Close the browser

[0136] After completing the action loop for all sites, close all pages and browser contexts; close the Playwright browser instance and release resources.

[0137] 2. The package screenshot is in ZIP format.

[0138] In the root directory of the screenshot, collect all image files generated during this execution according to directory structure and time order; use a compression library (such as Python's zipfile) to compress the screenshot directory into a ZIP file, for example, named:

[0139] Test timestamps_multi-site automated test results.zip;

[0140] The original order of the environment subdirectory and screenshot files is maintained in the compressed package structure.

[0141] In practical applications, other compression formats such as tar, gz, and 7z can also be used. Alternatively, an automatically generated HTML index file can be included in the compressed package, referencing screenshots in chronological order so that the expanded file becomes a viewable text and image report.

[0142] 3. Output a task completion report

[0143] Print task completion information to the console or log, including: the number of sites executed, the number of steps for each site; the number of successful steps, the number of failed steps; and the ZIP file output path.

[0144] Users can unzip the ZIP file to view a "comic strip" sequence of screenshots of each environment in chronological order, which can be directly used to write manual test reports or inserted into automated reporting systems.

[0145] The web automation testing and report generation method supporting multi-site switching according to embodiments of the present invention has the following beneficial technical effects:

[0146] I. Achieve unified and configurable management of multi-environment testing processes

[0147] By using structured configuration files to centrally define multiple test sites and their execution steps, combined with an automated script-driven multi-site loop execution mechanism, the same test process can be reused in different environments with a single click. An independent browser context is created for each test environment, ensuring complete isolation of session states. This effectively solves the accuracy problems and script maintenance complexity issues caused by state crosstalk in traditional multi-environment testing, improving the efficiency and reliability of multi-environment regression testing.

[0148] II. Building an efficient bridge between recording tools and configuration-based testing

[0149] By designing an automated parsing and conversion process from graphical code recording to structured step lists, testers can quickly build test cases with low-code capabilities. The recorded operation code can be automatically parsed and transformed into standardized configuration entries, achieving a seamless transition from rapidly recorded exploratory tests to maintainable and reusable configuration-driven tests, thus reducing the technical barriers and maintenance costs of automated testing.

[0150] III. Forming a complete chain of visual test evidence

[0151] By forcing automatic screenshotting after each operation and using a unified naming convention that includes environment identifiers, step numbers, operation descriptions, and timestamps, a complete operation record arranged in chronological order can be generated. The structured screenshot files, after being packaged, form a "comic strip"-like visual evidence chain, providing intuitive and traceable graphic evidence for test reports, greatly facilitating problem localization, result verification, and cross-team communication.

[0152] IV. Enhance the robustness and information integrity of test execution

[0153] By introducing a fine-grained exception capture mechanism and configurable exception handling strategies, the system can record the error context (including error screenshots and logs) when a step fails, and determine whether to continue executing subsequent steps based on preset strategies. This allows the testing process to collect test information to the maximum extent even when facing unstable factors such as page changes and network fluctuations, avoiding the limitations of traditional scripts where "single point of failure means total interruption," and improving the fault tolerance and completeness of information collection in testing.

[0154] V. Provide an integrated test report generation solution

[0155] After the test execution is complete, all screenshot files are automatically compressed and packaged according to the directory structure, and a test report containing execution statistics is output, realizing full automation from test execution to report generation. Users do not need to write additional packaging scripts or manually organize test results. After decompression, they can obtain a complete test record with a clear structure and in sequence, which significantly reduces the manual cost of test result organization and report preparation.

[0156] VI. Improve adaptability to complex enterprise testing environments

[0157] By supporting browser startup parameter configurations such as ignoring HTTPS certificate errors, it can adapt to common self-signed certificate scenarios in enterprise internal testing environments, avoiding test interruptions caused by certificate issues.

[0158] VII. Possesses good scalability and flexibility

[0159] The configuration-driven architecture makes the system easily extendable to new operation types, support different browser-driven engines, or integrate additional report formats. The structured nature of the step list provides a clear technical path for iterative optimization of the test process and expansion into complex scenarios, adapting to testing needs of varying scales and complexities.

[0160] like Figure 4 As shown, the present invention also provides a device including a processor 310, a communication interface 320, a memory 330 for storing processor-executable computer programs, and a communication bus 340. The processor 310, communication interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 executes the executable computer program to implement the aforementioned method for web automation testing and report generation supporting multi-site switching.

[0161] The computer program in memory 330, when implemented as a software functional unit and sold or used as an independent product, 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 a portion 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 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, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0162] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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 modules can be selected based on actual needs to achieve the purpose of this embodiment. Those skilled in the art can understand and implement this without any creative effort.

[0163] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0164] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.< / url>

Claims

1. A method for web automation testing and report generation that supports multi-site switching, characterized in that, The method includes: Step S1: Read the configuration file containing multiple site definitions and test step sequences, and initialize the browser driver engine and screenshot storage directory; Step S2: Iterate through all the sites defined in the configuration file, create an independent browser context for each site, and navigate to the starting Uniform Resource Locator (URL) address of that site; Step S3: For each site, execute each operation step defined in the test step sequence in sequence. After each step is completed, take a screenshot of the current page and save the screenshot file according to the preset unified naming rules. Step S4: After all site tests are completed, compress all screenshot files generated during this execution into an archive file and output a test completion report containing execution statistics and the archive file path.

2. The Web automation testing and report generation method supporting multi-site switching according to claim 1, characterized in that, The configuration file in step S1 is a structured data file, which includes: A list of sites that defines multiple test environments, each consisting of an environment name and an initial Uniform Resource Locator (URL). A list of steps that defines a sequence of test steps to be executed sequentially. Each step sequence includes a step type, an element locator, optional input values, optional wait times, and step description information. And at least one execution control parameter, which defines whether to continue execution when a step fails and the root directory path for storing screenshot files.

3. The Web automation testing and report generation method supporting multi-site switching according to claim 1, characterized in that, In step S1, during the initialization of the browser driver engine, the browser startup parameters are set to ignore Secure Sockets Layer Transport Layer security certificate errors in the following way: the browser driver engine's ignore certificate error parameter is set to true, so that the test system can normally access and use the internal test environment site with self-signed certificates or untrusted certificates.

4. The Web automation testing and report generation method supporting multi-site switching according to claim 1, characterized in that, Before step S1, convert the operation code generated by the graphical recording tool into a structured list of steps in the configuration file as follows: Complete the business operation process on the target webpage and generate script code containing page operation instructions using the browser frame's recording tool; Extract the operation statements from the script code and input them into the conversion script. The conversion script parses the operation statements to identify the operation instructions, including the operation function type, element selector, and input text content. Each parsed operation instruction is converted into a step object with standardized fields, and the sequence of all step objects is written into the step list field of the configuration file.

5. The Web automation testing and report generation method supporting multi-site switching according to claim 1, characterized in that, In step S2, an independent browser context is created for each site in the following way: by calling the application programming interface of the browser driver engine, a new browser context object or page object is created for the site currently being traversed. The newly created browser context object or page object has independent session storage, local storage and cookie storage mechanisms.

6. The Web automation testing and report generation method supporting multi-site switching according to claim 1, characterized in that, In step S3, each operation step defined in the test step sequence is executed sequentially as follows: Based on the step type field in the current step object, identify the browser operation category corresponding to the step. This operation category includes clicking an element, entering text, waiting for a specified time or for an element to appear, and jumping to a new page. Based on the element locator information defined in the current step object, locate the target element on the page and call the application interface in the browser driver engine that matches the operation category to perform the corresponding action; During the execution of each step, exceptions are captured. When an element location fails, an operation times out, or other execution exceptions occur, error information is recorded. Based on the execution control parameters defined in the configuration file, it is decided to skip the current step and continue to execute subsequent steps or terminate the remaining test process of the current site.

7. The Web automation testing and report generation method supporting multi-site switching according to claim 1, characterized in that, In step S3, a unified naming rule is preset as follows: the screenshot file name is combined in a specific order and with a connector. Its format includes an environment name part, a step number part, an operation description part, and a timestamp part. The environment name part is taken from the environment identifier of the current execution site, the step number part is the sequential number of the step in the step list, the operation description part is taken from the step description information field of the step, and the timestamp part is the system time when the step is completed.

8. The Web automation testing and report generation method supporting multi-site switching according to claim 1, characterized in that, In step S4, all screenshot files generated during this execution process are compressed into an archive file as follows: Traverse and collect all screenshot files generated in the screenshot storage directory and their corresponding site subdirectories during this test execution; The program calls a built-in or third-party compression library to package all collected screenshot files and directory structures into a compressed archive file. The internal directory hierarchy of the compressed archive file is consistent with the original screenshot storage structure, and the file arrangement order corresponds to the time order of the test execution.

9. The Web automation testing and report generation method supporting multi-site switching according to claim 1, characterized in that, In step S4, the execution statistics of the test completion report include the total number of sites that have performed the test, the total number of steps executed at each site, the number of steps successfully executed at all sites, the number of steps that failed to execute at all sites, and a summary of the main abnormal events recorded during the test execution. The archive file path of the test completion report is the complete location address of the generated compressed archive file in the storage system.

10. A computer device, characterized in that, The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method according to any one of claims 1-9.

Images