Automatic browser testing method and device, program product, medium and equipment
By monitoring connection status and obtaining metadata in real time during browser automated testing, the problem of interruption in the browser automated testing process was solved, thereby improving the stability and efficiency of automated testing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHONGQING JINKANG NEW ENERGY VEHICLE CO LTD
- Filing Date
- 2025-12-29
- Publication Date
- 2026-04-21
AI Technical Summary
Browser automated testing processes are prone to interruption due to failed attempts to initialize the driver, requiring manual intervention or external monitoring scripts to restart the browser process, which affects testing efficiency.
During browser automated testing, a connection is attempted to be established based on the target tab identifier, and the connection status is monitored in real time. Metadata is obtained from the browser's debug information interface, the connection context information is refreshed, and the connection is retried.
With built-in exception handling and recovery retry mechanisms, connection disconnection issues are automatically handled, preventing test task interruptions and improving test efficiency and stability.
Smart Images

Figure CN121901104A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software testing technology, and more specifically, to a browser automated testing method, apparatus, program product, medium, and device. Background Technology
[0002] In the field of software testing, automated testing based on headless browsers or remote browser instances has become standard practice. In related technologies, testing frameworks typically establish connections with the browser's debug port via WebSocket (a protocol for full-duplex communication over a single TCP connection) and connect to a specific tab. They control browser behavior by sending and receiving CDP (Chrome DevTools Protocol, a remote debugging protocol that allows developers to communicate with a running Chrome browser) commands. Specifically, when initializing a driver instance, the testing framework directly attempts to connect to the specified tab. However, browser environments are unstable; tabs can easily close unexpectedly or become unresponsive due to network fluctuations, resource overload, etc. In such cases, the attempt to initialize the driver will fail, and the automated testing process will be interrupted. After the process is interrupted, manual intervention or an external monitoring script is usually required to restart the entire browser process and test tasks, thus reducing the efficiency of automated testing. Summary of the Invention
[0003] The purpose of this application is to provide a browser automated testing method, apparatus, program product, medium and device, which aims to solve the problem that the browser automated testing process is easily interrupted due to the failure of the attempt to initialize the driver, requiring manual intervention or external monitoring scripts to restart the entire browser process and test tasks, thus affecting the testing efficiency.
[0004] Firstly, this application provides a browser automated testing method, comprising: during browser automated testing, attempting to establish a connection with a corresponding target tab based on a target tab identifier, and monitoring the connection status in real time; when a connection anomaly is detected, obtaining the metadata of the target tab by sending an information query request to the browser's debugging information interface; and retrying to establish a connection with the target tab based on the metadata.
[0005] In the above implementation process, during browser automated testing, an attempt is made to establish a connection with the corresponding target tab based on the target tab identifier, and the connection status is monitored in real time to capture possible connection anomalies. When a connection anomaly is captured, an information query request is sent to the browser's debug information interface to obtain the target tab's metadata, thereby refreshing the connection context information and obtaining the latest tab status. Then, based on the metadata, the connection with the target tab is retried. In this way, through the built-in exception capture and recovery retry mechanism, connection drop issues can be automatically handled, avoiding the interruption of the entire automated testing task due to the unexpected closure of a single tab, reducing reliance on external system monitoring and manual restarts, and effectively improving testing efficiency.
[0006] Furthermore, in some examples, the real-time monitoring of connection status includes: activating a try-except exception handling mechanism; the try-except exception handling mechanism is used to catch at least one of the following connection exceptions: connection rejection exception, request timeout exception, HTTP response error exception, and invalid target tab exception.
[0007] In the above implementation process, a try-except exception handling mechanism is used to capture possible connection exceptions, including at least one of the following: connection rejection exception, request timeout exception, HTTP response error exception, and target tab invalid exception. In this way, by automatically handling common connection opening and closing issues, the success rate and stability of the testing process can be effectively improved.
[0008] Furthermore, in some examples, obtaining the metadata of the target tab by sending an information query request to the browser's debugging information interface includes: sending an information query request to the browser's debugging information interface; receiving the return result of the debugging information interface; parsing the return result and extracting the metadata of the target tab based on the parsing result; the debugging information interface is a JSON interface; the information query request is an HTTP GET request sent to the debugging information interface; and the return result is JSON data containing the metadata of all available tabs in the browser.
[0009] In the above implementation process, when a connection exception is captured, the browser's debugging information interface is used to interact with the browser to query the detailed information of the target tab. Then, the required metadata is extracted from the data returned by the interface. Through this operation, the connection context information can be refreshed to ensure that the latest tab status is obtained.
[0010] Furthermore, in some examples, the steps include: if retrying the connection fails, determining whether the number of retries is greater than or equal to the preset maximum number of retries; if the determination result is negative, re-executing the steps of sending an information query request to the browser's debugging information interface to obtain the metadata of the target tab, and retrying to establish a connection with the target tab based on the metadata.
[0011] In the above implementation process, when a connection exception is detected, a recovery reconnection process is initiated. If the retry fails, the recovery reconnection process is executed again until the retry succeeds or the preset maximum number of retries is reached. This improves the success rate and stability of the testing process.
[0012] Furthermore, in some examples, this also includes: setting a connection disconnection monitoring callback upon successful connection establishment with the target tab; the connection disconnection monitoring callback is used to automatically trigger a predefined connection recovery process when a connection disconnection event is detected between the debugger and the browser.
[0013] In the above implementation process, when the driver initialization is successful, a connection disconnection monitoring callback is set to realize timely detection and automated processing of connection disconnection events between the debugger and the browser, thereby improving testing efficiency and reducing operation and maintenance costs.
[0014] Furthermore, in some examples, this also includes: setting a page frame unloading monitoring callback upon successful connection to the target tab; the page frame unloading monitoring callback is used to automatically trigger a predefined recovery process when an unloading event of the page frame is detected.
[0015] In the above implementation process, when the driver initialization is successful, a page frame unloading monitoring callback is set to achieve fine-grained awareness of page structure changes, thereby enhancing system stability.
[0016] Secondly, this application provides a browser automated testing device, comprising: a monitoring module, used to attempt to establish a connection with a corresponding target tab based on a target tab identifier during browser automated testing, and to monitor the connection status in real time; an acquisition module, used to acquire the metadata of the target tab by sending an information query request to the browser's debugging information interface when a connection abnormality is detected; and a retry module, used to retry establishing a connection with the target tab based on the metadata.
[0017] Thirdly, this application provides an electronic device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the method described in any of the first aspects.
[0018] Fourthly, this application provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described in any of the first aspects.
[0019] Fifthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the method described in any of the first aspects.
[0020] Other features and advantages disclosed in this application will be set forth in the following description, or some features and advantages may be inferred from the description or determined without doubt, or may be learned by practicing the above-described technology disclosed in this application.
[0021] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0022] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0023] Figure 1 A flowchart illustrating a browser automated testing method provided in this application embodiment; Figure 2 A schematic diagram illustrating the workflow of a tab connection recovery scheme for browser automated testing provided in this application embodiment; Figure 3 A block diagram of a browser automated testing device provided in an embodiment of this application; Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation
[0024] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.
[0025] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.
[0026] In the field of software testing, automated testing based on headless browsers or remote browser instances has become standard practice. In related technologies, testing frameworks typically establish connections with the browser's debug port via the WebSocket protocol and attach to a specific tab, controlling browser behavior by sending and receiving CDP commands. In implementation, when initializing a driver instance, the testing framework directly attempts to connect to the specific tab specified by the target tab identifier `tab_id`. However, the browser environment is unstable; tabs may unexpectedly close or become unresponsive due to various reasons such as page crashes, network fluctuations, or resource overload. When the specific tab disconnects due to an anomaly, the direct driver initialization operation fails, causing the entire automated process to be interrupted. After the process is interrupted, manual intervention or an external monitoring script is usually required to restart the entire browser process and test tasks, thus reducing the efficiency of automated testing.
[0027] To address the aforementioned issues, this application provides a browser automated testing solution. During browser automated testing, an attempt is made to establish a connection with the corresponding target tab based on the target tab identifier, and the connection status is monitored in real time to capture potential connection anomalies. When a connection anomaly is captured, an information query request is sent to the browser's debug information interface to obtain the target tab's metadata, thereby refreshing the connection context information and obtaining the latest tab status. Then, based on the metadata, the connection with the target tab is retried. Thus, through the built-in anomaly capture and recovery retry mechanism, connection drop issues can be automatically handled, avoiding the interruption of the entire automated testing task due to the unexpected closure of a single tab, effectively improving testing efficiency.
[0028] The embodiments of this application will be described below: like Figure 1 As shown, Figure 1 This is a flowchart illustrating a browser automated testing method provided in an embodiment of this application. The method can be applied to automated testing systems.
[0029] The method includes: Step 101: During the browser automated testing process, attempt to establish a connection with the corresponding target tab based on the target tab identifier, and monitor the connection status in real time; The target tab identifier mentioned in this step can be a tab_id, which is a unique identifier for the target tab. During driver instance initialization, the test system receives the tab_id from the browser and uses it as an input parameter to call the standard driver initialization method, attempting to establish a connection with the target tab. Traditional solutions assume success during driver initialization, without pre-checking the health of the target tab or handling connection failures. In this embodiment, however, the test system incorporates an exception handling mechanism. During initialization, it monitors the connection status in real time and captures potential connection anomalies, laying the foundation for automatically handling connection drops.
[0030] In some embodiments, real-time monitoring of connection status mentioned in this step may include: activating a try-except exception handling mechanism; the try-except exception handling mechanism is used to capture at least one of the following connection exceptions: connection rejection exception, request timeout exception, HTTP (Hypertext Transfer Protocol) response error exception, and invalid target tab exception. That is, during initialization, the test system can use the try-except exception handling mechanism to capture possible connection exceptions. This try-except exception handling mechanism is a core mechanism in Python for capturing and handling runtime exceptions. It executes code that might cause an exception through a try block (a code block that may throw an exception), and handles specific exceptions through an except block (a code block that handles the exception type). This mechanism allows specifying the types of connection exceptions to be captured. In this embodiment, the connection exceptions that this mechanism can capture include at least one of connection rejection exception, request timeout exception, HTTP response error exception, and invalid target tab exception. These are common connection disconnection problems. Thus, by automatically handling common connection disconnection problems, the success rate and stability of the testing process can be effectively improved.
[0031] Step 102: When a connection anomaly is detected, obtain the metadata of the target tab by sending an information query request to the browser's debugging information interface; When a connection exception is detected, it indicates that the connection between the test system and the browser is broken. At this time, the test system sends an information query request to the browser's debug information interface. The debug information interface returns the metadata of the target tab. This operation updates the client's connection context information to ensure that the latest tab status is obtained.
[0032] In some embodiments, obtaining the metadata of the target tab by sending an information query request to the browser's debug information interface, as mentioned in this step, may include: sending an information query request to the browser's debug information interface; receiving the return result from the debug information interface; parsing the return result; and extracting the metadata of the target tab based on the parsing result. In other words, when a connection anomaly is detected, the test system interacts with the browser using the debug information interface provided by the browser to query the detailed information of the target tab, and then extracts the required metadata from the data returned by the interface, such as the tab ID (Identity), URL (Uniform Resource Locator) link address, title, etc. This operation refreshes the connection context information, ensuring that the latest tab status is obtained.
[0033] Optionally, the aforementioned debugging information interface can be a JSON (JavaScript Object Notation) interface; accordingly, the information query request is an HTTP GET request sent to the debugging information interface; the returned result is JSON data containing metadata of all available tabs in the browser. In other words, when the debugging information interface provided by the browser is a JSON interface, the testing system can send an HTTP GET request to this interface to obtain a list of all currently available debugging targets in the browser. This interface returns JSON data containing detailed information about each tab, from which the testing system can extract the metadata of the target tab.
[0034] Step 103: Based on the metadata, retry establishing a connection with the target tab.
[0035] In this embodiment, after refreshing the connection context information, the test system calls the driver initialization method again to attempt to establish a connection with the target tab corresponding to the target tab identifier. This initialization is based on the updated connection context information, which effectively solves the connection failure problem caused by state asynchrony.
[0036] In some embodiments, the method may further include: if a retry connection fails, determining whether the number of retries is greater than or equal to a preset maximum number of retries; if the determination result is negative, re-executing the steps of sending an information query request to the browser's debugging information interface to obtain the metadata of the target tab, and retrying to establish a connection with the target tab based on the metadata. In other words, when a connection exception is detected, a recovery reconnection process is initiated, including refreshing the connection context information and retry driver initialization. If a retry connection fails, it checks whether the number of retries is greater than or equal to a preset maximum number of retries. If the number of retries is greater than or equal to the preset maximum number of retries, an error is recorded or an exception is thrown. If the number of retries is less than the preset maximum number of retries, the recovery reconnection process is executed again. This improves the success rate and stability of the testing process.
[0037] Furthermore, in some embodiments, the method may also include: setting a connection disconnection monitoring callback upon successful connection establishment with the target tab; the connection disconnection monitoring callback is used to automatically trigger a predefined connection restoration process when a connection disconnection event is detected between the debugger and the browser. That is, after successful driver initialization, a connection disconnection monitoring callback can be set. In implementation, the callback function for the Inspector.detached event (an error event indicating that the connection between the browser and the debugging tool has been disconnected) can be registered as the self._onInspectorDetached method, with the immediate=True parameter set. This callback is used to monitor connection disconnection events between the debugger and the browser. Once a disconnection is detected, the corresponding processing flow is immediately triggered, such as reconnection or restarting the browser instance. This achieves timely detection and automated processing of connection disconnection events between the debugger and the browser, thereby improving testing efficiency and reducing operational costs.
[0038] Additionally, some embodiments may include: setting a page frame unloading monitoring callback upon successful connection to the target tab; the page frame unloading monitoring callback is used to automatically trigger a predefined recovery process when a page frame unloading event is detected. That is, after successful driver initialization, a page frame unloading monitoring callback can be set. In implementation, the callback function for the Page.frameDetached event (an event in the Chromium browser, typically triggered when a child frame is removed or its document is destroyed) can be registered as the self._onFrameDetached method, with the immediate=True parameter also set. This callback is used to monitor page frame unloading events and respond quickly, achieving fine-grained awareness of page structure changes, thereby enhancing system stability.
[0039] In this embodiment of the application, during browser automated testing, an attempt is made to establish a connection with the corresponding target tab based on the target tab identifier, and the connection status is monitored in real time to capture possible connection anomalies. When a connection anomaly is captured, an information query request is sent to the browser's debugging information interface to obtain the target tab's metadata, thereby refreshing the connection context information and obtaining the latest tab status. Then, based on the metadata, the connection with the target tab is retried. In this way, through the built-in anomaly capture and recovery retry mechanism, connection drop issues can be automatically handled, avoiding the interruption of the entire automated testing task due to the unexpected closure of a single tab, reducing reliance on external system monitoring and manual restarts, and effectively improving testing efficiency.
[0040] To provide a more detailed explanation of the solution in this application, a specific embodiment is described below: This embodiment provides a tab connection recovery solution for browser automated testing. The workflow of this solution is shown in the figure, including: S201. Receive the target tab identifier and attempt an initial connection; Specifically, it receives tab_id as an input parameter, calls the driver initialization method, and attempts to establish a connection with the target tab specified by tab_id; S202. Real-time monitoring of connection status; Specifically, during the initialization process, a try-except exception handling mechanism is used to monitor the connection status in real time and capture possible connection exceptions, including but not limited to: connection rejection exception, request timeout exception, HTTP response error exception, and invalid target tab exception. S203. Determine whether the connection is successful. If yes, execute S209; otherwise, execute S204. S204. Refresh connection context information; Specifically, when a connection exception is detected, an HTTP GET request is sent to the browser's debugging information interface to obtain a list of all currently available debugging targets in the browser. This interface returns JSON data containing detailed information about each tab, including metadata such as tab ID, URL link address, and title. This operation updates the client's connection context information. S205, Retry driver initialization; Specifically, after refreshing the connection context information, the driver initialization method is called again to attempt to establish a connection with the target tab specified by tab_id; S206. Determine whether the retry connection was successful. If yes, execute S209; otherwise, execute S207. S207. Check if the number of retries is greater than or equal to the preset maximum number of retries. If yes, execute S208; otherwise, return to S204. S208. Confirm that the test task has failed and end the process; S209. Set up an event callback monitoring mechanism; Specifically, after successful driver initialization, the following event callbacks are immediately set to enhance system stability: The callback function for the `Inspector.detached` event is registered as the `self._onInspectorDetached` method with the `immediate=True` parameter set. This callback monitors for disconnection events between the debugger and the browser, and triggers the corresponding processing flow immediately upon detection of a disconnection. The callback function for the `Page.frameDetached` event is also registered as the `self._onFrameDetached` method with the `immediate=True` parameter set. This callback monitors and quickly responds to page frame unloading events, enabling fine-grained awareness of page structure changes.
[0041] In addition, the solution in this embodiment can be applied not only to browser automated testing, but also to web crawler development scenarios.
[0042] This embodiment has at least the following advantages: First, through the built-in exception capture and recovery retry mechanism, it can automatically handle common connection disconnection problems, avoiding the interruption of the entire automated test script or crawler task due to the accidental closing of a single tab, effectively improving the success rate and stability of the test process; Second, it realizes automated handling of connection disconnection problems, reducing the dependence on external system monitoring and manual restart, enabling automated testing to run more reliably in an unattended environment, and reducing operation and maintenance costs; Third, by setting callback functions for the Inspector.detached event and Page.frameDetached event, it changes from passive response to active monitoring, enabling the system to detect disconnection events as soon as they occur, and providing the possibility of executing more complex recovery strategies, thus forming a complete fault response system.
[0043] Corresponding to the embodiments of the aforementioned methods, this application also provides embodiments of a browser automated testing device and its application terminal: like Figure 3 As shown, Figure 3 This is a block diagram of a browser automated testing device provided in an embodiment of this application. The device includes: The monitoring module 31 is used to attempt to establish a connection with the corresponding target tab based on the target tab identifier during browser automated testing, and to monitor the connection status in real time. The acquisition module 32 is used to obtain the metadata of the target tab page by sending an information query request to the browser's debugging information interface when a connection abnormality is detected. The retry module 33 is used to retry establishing a connection with the target tab page based on the metadata.
[0044] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.
[0045] This application also provides an electronic device, please refer to [link to application]. Figure 4 , Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of this application. The electronic device may include a processor 410, a communication interface 420, a memory 430, and at least one communication bus 440. The communication bus 440 is used to enable direct communication between these components. In this embodiment, the communication interface 420 of the electronic device is used for signaling or data communication with other node devices. The processor 410 may be an integrated circuit chip with signal processing capabilities.
[0046] The processor 410 described above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor, or the processor 410 can be any conventional processor.
[0047] The memory 430 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc. The memory 430 stores computer-readable instructions. When these computer-readable instructions are executed by the processor 410, the electronic device can perform the aforementioned operations. Figure 1 The various steps involved in the method implementation examples.
[0048] Alternatively, the electronic device may also include a storage controller and an input / output unit.
[0049] The memory 430, storage controller, processor 410, peripheral interface, and input / output unit are electrically connected directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses 440. The processor 410 is used to execute executable modules stored in the memory 430, such as software function modules or computer programs included in electronic devices.
[0050] The input / output unit is used to provide users with the ability to create tasks and to set optional start periods or preset execution times for those tasks, thereby enabling user-server interaction. The input / output unit may be, but is not limited to, a mouse and keyboard.
[0051] Understandable. Figure 4 The structure shown is for illustrative purposes only; the electronic device may also include components that are more advanced than those shown. Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown. Figure 4 The components shown can be implemented using hardware, software, or a combination thereof.
[0052] This application also provides a storage medium storing instructions. When the instructions are run on a computer, the computer program is executed by a processor to implement the method described in the method embodiment. To avoid repetition, the method will not be described again here.
[0053] This application also provides a computer program product that, when run on a computer, causes the computer to perform the method described in the method embodiment.
[0054] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0055] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.
[0056] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they 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 described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0057] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.
[0058] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
[0059] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
Claims
1. A browser automated testing method, characterized in that, include: During browser automated testing, attempts are made to establish a connection with the corresponding target tab based on the target tab identifier, and the connection status is monitored in real time. When a connection anomaly is detected, the metadata of the target tab is obtained by sending an information query request to the browser's debugging information interface. Based on the metadata, retry establishing a connection with the target tab.
2. The method according to claim 1, characterized in that, The real-time monitoring of connection status includes: Initiate a try-except exception handling mechanism; the try-except exception handling mechanism is used to catch at least one of the following connection exceptions: connection refused exception, request timeout exception, HTTP response error exception, and invalid target tab exception.
3. The method according to claim 1, characterized in that, The step of obtaining the metadata of the target tab by sending an information query request to the browser's debugging information interface includes: Send an information query request to the browser's debug information interface; Receive the return result from the debugging information interface; The returned results are parsed, and the metadata of the target tab page is extracted based on the parsing results; The debugging information interface is a JSON interface; the information query request is an HTTP GET request sent to the debugging information interface; the returned result is JSON data containing metadata of all available tabs in the browser.
4. The method according to claim 1, characterized in that, Also includes: If the connection retry fails, check if the number of retries is greater than or equal to the preset maximum number of retries; If the determination result is negative, the steps of sending an information query request to the browser's debugging information interface to obtain the metadata of the target tab page, and retrying to establish a connection with the target tab page based on the metadata are executed again.
5. The method according to claim 1, characterized in that, Also includes: If a connection is successfully established with the target tab, a connection disconnection monitoring callback is set; the connection disconnection monitoring callback is used to automatically trigger a predefined connection recovery process when a connection disconnection event is detected between the debugger and the browser.
6. The method according to claim 1, characterized in that, Also includes: If a connection is successfully established with the target tab, a page frame unloading monitoring callback is set; the page frame unloading monitoring callback is used to automatically trigger a predefined recovery process when an unloading event of a page frame is detected.
7. A browser automated testing device, characterized in that, include: The monitoring module is used to attempt to establish a connection with the corresponding target tab based on the target tab identifier during browser automated testing, and to monitor the connection status in real time. The acquisition module is used to obtain the metadata of the target tab page by sending an information query request to the browser's debugging information interface when a connection abnormality is detected. The retry module is used to retry establishing a connection with the target tab based on the metadata.
8. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, It stores a computer program thereon, which, when executed by a processor, implements the method as described in any one of claims 1 to 6.
10. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method as described in any one of claims 1 to 6.