Debugging control and execution management method based on UI automatic test platform

Abstract

The invention discloses a debugging control and execution management method based on a UI automatic test platform, and relates to the technical field of software testing, and the method comprises the following steps: providing flexible debugging starting point control capability, realizing strategy selection and scheduling by a front end, and sending an application case to a server executor; the method comprises the following steps: transplanting a UI automatic test platform executor to a local server, locally starting a special controlled browser instance by virtue of Playwright to realize real-time monitoring of case execution, and constructing a breakpoint mechanism based on a producer-consumer model, so that the server executor realizes queue execution control by depending on a front-end strategy; a dynamic breakpoint adding mechanism is provided, and breakpoints are allowed to be inserted when the use cases are executed, so that repeated operation of executed use case segments is avoided; in UI automatic testing, thread management supports checking and modifying of executor thread variables so that page data can be obtained and stored into the variables to be used in subsequent steps, and debugging is convenient. According to the invention, the efficiency of compiling and maintaining the test script by the UI automatic test platform can be improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and in particular to a debugging control and execution management method based on a UI automated testing platform. Background Art

[0002] UI automation testing platforms offer advantages such as fast entry and high efficiency in script writing and maintenance. However, because the root causes of test case failures vary, when a test case error occurs, the UI automation testing platform requires repeated modification and re-execution to locate the root cause. This reduces the efficiency of script writing and maintenance.

[0003] UI automation testing platforms offer advantages such as fast entry and high efficiency in writing and maintaining. Because UI automation testing platforms typically encapsulate underlying technical details such as basic libraries, element positioning mechanisms, waiting mechanisms, and judgment mechanisms into keywords, users can focus more on writing UI automation test cases without worrying about underlying implementation methods.

[0004] However, when test scripts fail, an efficient troubleshooting mechanism is crucial. The root causes of test case failures can be diverse, including unstable element positioning, imperfect wait mechanisms, logical errors in upstream steps, or improper data preparation. When script errors occur, unlike breakpoint debugging in an IDE, UI automated testing platforms may require repeated modification of test cases and re-execution of entire tests or parts of them to locate the root cause. This reduces the efficiency of script writing and maintenance. Summary of the Invention

[0005] In response to the needs and deficiencies of current technological development, the present invention provides a debugging control and execution management method based on a UI automation test platform to improve the efficiency of writing and maintaining test scripts on the UI automation test platform.

[0006] The present invention provides a debugging control and execution management method based on a UI automated testing platform, which solves the above technical problems by adopting the following technical solutions:

[0007] A debugging control and execution management method based on a UI automated testing platform includes four parts: debugging control, local breakpoint mechanism, breakpoint addition, and thread management:

[0008] (A) Debug Control: Provides flexible debugging starting point control capabilities that meet use case level, use case segment level, and exit debugging requirements. The front-end implements strategy selection and scheduling and sends corresponding use cases or control signals to the server-side executor.

[0009] (B) Local breakpoint mechanism: The UI automation test platform executor is transplanted to the local server, and a dedicated controlled browser instance is started locally by Playwright to realize real-time monitoring of use case execution, and a breakpoint mechanism is constructed based on the producer-consumer model to make the server executor rely on the front-end strategy to realize queue execution control;

[0010] (C) Breakpoint addition: A dynamic breakpoint addition mechanism is proposed to allow inserting breakpoints during use case execution to avoid repeatedly running executed use case segments;

[0011] (D) Thread management: In UI automation testing, thread management supports viewing and modifying executor thread variables to obtain page data and store it in variables for subsequent steps and facilitate debugging.

[0012] Optionally, (A) is performed, and for use case level debugging requirements, the following are provided: a) an execution strategy for repeating the current use case, under which the front-end sends the current use case to the server to help users quickly verify a single use case, fix a single use case error, or reproduce an occasional error; b) an execution strategy for executing the next use case, under which the front-end sends the next use case to the server to support step-by-step debugging and "write-debug-verify" cycles;

[0013] For use case segment level debugging requirements, an execution strategy for executing to the next breakpoint is provided, under which the front-end sends all use cases between the current use case and the next breakpoint to the server, and executes the necessary use case branches to locate the preset breakpoint;

[0014] For exit debugging requirements, the following are provided: a) an execution strategy for resuming execution ignoring breakpoints, under which the front-end sends all remaining use cases to the server and ignores all breakpoints to implement debugging mode exit and full use case running; b) an execution strategy for ending, under which the front-end sends a stop signal to the server to terminate the current debugging process.

[0015] Optionally, (B) specifically includes:

[0016] (B1) The UI automation test platform executor is transplanted to the local server; when starting debugging, the server starts and manages a dedicated controlled browser instance locally through Playwright to execute the use case selected by the user, allowing the user to intuitively monitor the use case running situation;

[0017] (B2) A breakpoint core implementation framework is constructed based on the producer-consumer model, and the local server contains producers and consumers; the server producer receives front-end information and adds it to the queue; the server consumer, which is the executor of the use case, is essentially dependent on and controlled by the front-end execution strategy and continuously listens to the queue:

[0018] i) When the queue is not empty, the executor gets the information in the queue in order, a) if the information is a use case, start executing the use case, and after execution, listen to the queue again, b) if the information is a stop signal, the executor exits the listening and closes the thread;

[0019] ii) When the queue is empty, enter a blocked waiting state to realize the execution pause at the breakpoint.

[0020] Optionally, the execution (C) involved in the proposed dynamic breakpoint adding mechanism includes adding a preset breakpoint to the use case in the queue, adding a real-time breakpoint to the running use case, and automatically adding a failure automatic breakpoint to the use case that fails to run.

[0021] Further optionally, in the execution of the test use case by the executor, a use case that has not yet been executed is marked as a preset breakpoint, and the use case information of the preset breakpoint is sent to the server. When the executor runs to the use case marked as a preset breakpoint, the execution is interrupted and enters a waiting state;

[0022] Marking a use case that has not yet been executed as a preset breakpoint has the following implementation principle: the server saves the breakpoint use case into a variable. The executor compares the use case obtained each time with the use case in the variable. When the comparison is consistent, all use cases in the queue are emptied. When the queue is empty, the executor enters a waiting state to realize the breakpoint function.

[0023] Further optionally, a preset shortcut key is set as a real-time breakpoint. When the user finds that the use case execution needs to be changed and optimized during monitoring of the test execution, the user can interrupt the use case being executed by pressing the preset shortcut key in the controlled browser, so that the executor enters a waiting state, thereby providing the function of interrupting the running at any time and debugging during the execution of the use case for the user;

[0024] The principle of adding a real-time breakpoint is as follows:

[0025] When starting the browser instance, the expose_function method of BrowserContext in Playwright is used to expose the Python end method to the browser context. When calling, the interrupt flag variable in Python is set to True;

[0026] The add_init_script method of BrowserContext is used to inject a JavaScript script into a new page. The script listens to the preset shortcut key when the page is initialized;

[0027] When the user presses the preset shortcut key in the browser page, the listening script is triggered, the Python end function exposed to the browser context is called, and the interrupt flag variable is set to True;

[0028] Before the executor executes each step of the use case, the interrupt flag is detected, if the interrupt flag is True, an exception is thrown and the execution is interrupted, the exception is captured in the loop body of the loop of the acquisition queue, the queue use case is emptied, and the executor enters the waiting state of the loop of the acquisition queue information, and the breakpoint function is realized.

[0029] Further, when the execution of the use case fails after the debugging mode is enabled, a failure automatic breakpoint is automatically added to the use case that fails to run, and the current test is interrupted.

[0030] The implementation principle of the failure automatic breakpoint is as follows:

[0031] When the use case fails to execute, the executor throws an exception of execution failure, and the exception is captured in the loop body of the loop of the acquisition queue of the executor, whether the debugging mode is enabled is judged, if the debugging mode is enabled, all use cases in the queue are emptied, so that the executor enters the waiting state, and the breakpoint function is realized.

[0032] Optionally, the execution (D) is performed, in the UI automation test execution process, when the use case stores data into a thread variable through a specified interface, the executor stores these variables into a thread-safe common storage area; the storage area adopts a key-value pair structure, and supports data sharing across use case steps;

[0033] When the user triggers the "view variable" operation in the debugging interface, the front end sends a query request to the server, the request carries a variable name or a full-quantity query identifier, the server obtains the corresponding variable value through a reading interface of the storage area, and returns the variable value to the front end in a JSON format, and finally displays the variable value in a tree structure or a table form in the debugging panel.

[0034] Further, the execution (D) is performed, in the UI automation test execution process, the thread management supports the user to directly edit the variable value in the front-end debugging interface; when the modification is submitted, the front end encapsulates the change content into a JSON request and sends it to the server;

[0035] After the server receives the request, it first verifies whether the variable exists and the modification authority, and then atomically updates the corresponding variable value through an updating interface of the common storage area;

[0036] After the updating succeeds, the server broadcasts the change notification to all clients that listen to the variable, and records the operation log in the common storage area, so as to ensure the traceability of the debugging process.

[0037] Compared with the prior art, the debugging control and execution management method based on the UI automation test platform has the beneficial effects that:

[0038] 1、The present application can improve the test efficiency of UI automation test platform, improve the convenience of writing debugging cases and enhance the controllability of testing by executing four part operations of debugging control, local breakpoint mechanism, breakpoint adding and thread management;

[0039] 2、The present application can make the user efficiently debug in more scenarios and obtain powerful case-level control through debugging control operation, realize real-time observation of the user on the execution process of the case, improve the efficiency of writing debugging cases through local breakpoint mechanism, allow the user to directly insert breakpoints during the execution of the case through breakpoint adding operation, avoid repeated running of the executed case segment, improve the debugging efficiency, support viewing and modifying the executor thread variable through thread management, so as to obtain page data stored in the variable for subsequent steps and facilitate debugging. BRIEF DESCRIPTION OF DRAWINGS

[0040] Figure 1 is a local breakpoint mechanism flowchart of an embodiment of the present application; Figure 1

[0041] Figure 2 is a dynamic breakpoint adding mechanism flowchart of an embodiment of the present application. Figure 2 DETAILED DESCRIPTION

[0042] In order to make the technical solutions, technical problems solved and technical effects of the present application clearer and more apparent, the technical solutions of the present application are described in detail below in combination with specific embodiments.

[0043] Embodiment:

[0044] The present embodiment proposes a debugging control and execution management method based on a UI automation test platform, which includes four parts of debugging control, local breakpoint mechanism, breakpoint adding and thread management:

[0045] (A) Debugging control: provide flexible debugging starting point control capability to meet the needs of case level, case segment level and exit debugging, realize strategy selection and scheduling by the front end and send the application case or control signal to the service end executor.

[0046] For the debugging needs of the case level, provide: a) the execution strategy of repeating the execution of the current case, under this execution strategy, the front end sends the current case to the service end, helps the user to quickly verify a single case, repair a single case error or reproduce an occasional error; b) the execution strategy of executing the next case, under this execution strategy, the front end sends the next case to the service end, supports step-by-step debugging of the case and "writing-debugging-verification" cycle;

[0047] ​​For the debugging needs of the use case segment level, an execution strategy of executing to the next breakpoint is provided, under which the front end sends all use cases between the current use case and the next breakpoint to the server, and executes the necessary use case branches to locate the preset breakpoint;

[0048] For the debugging needs of the use case segment level, an execution strategy of executing to the next breakpoint is provided, under which the front end sends all use cases between the current use case and the next breakpoint to the server, and executes the necessary use case branches to locate the preset breakpoint;

[0049] (B) Local breakpoint mechanism: transplant the UI automation test platform executor to the local server, start a special controlled browser instance on the local server with the help of Playwright to realize real-time monitoring of use case execution, and build a breakpoint mechanism based on the producer-consumer model to make the server executor rely on the front-end strategy to realize queue execution control. This content specifically includes:

[0050] (B1) Transplant the UI automation test platform executor to the local server; when starting debugging, the server starts and manages a special controlled browser instance on the local server through Playwright, which is used to execute the use cases selected by the user, so that the user can intuitively monitor the use case running situation;

[0051] (B2) Build a breakpoint core implementation framework based on the producer-consumer model, and the local server contains producers and consumers; refer to the attached Figure 1 , the server producer receives front-end information and adds it to the queue; the server consumer, which is the executor of the use case, is essentially dependent on and controlled by the execution strategy of the front end, and continuously listens to the queue:

[0052] i) When the queue is not empty, the executor obtains the information in the queue in order, a) if the information is a use case, start executing the use case, and listen to the queue again after execution, b) if the information is a stop signal, the executor exits the listening and closes the thread;

[0053] ii) When the queue is empty, enter a blocked waiting state to realize the execution pause at the breakpoint.

[0054] (C) Breakpoint addition: propose a dynamic breakpoint addition mechanism that allows inserting breakpoints during use case execution to avoid repeatedly running the executed use case segment.

[0055] The proposed dynamic breakpoint addition mechanism includes adding preset breakpoints to use cases in the queue, adding real-time breakpoints to running use cases, and automatically adding failure automatic breakpoints to running failed use cases. Refer to the attached Figure 2 .

[0056] (C1)In the execution of the test case by the executor, mark a certain still not executed use case as a preset breakpoint, and send the use case information of the preset breakpoint to the server. When the executor runs to the use case marked as the preset breakpoint, it will be interrupted and enter the waiting state;

[0057] Marking a certain still not executed use case as a preset breakpoint, the implementation principle is that the server saves the breakpoint use case into a variable. The executor compares the taken use case with the use case in the variable every time it gets a new use case. When they are consistent, it clears all use cases in the queue. When the queue is empty, the executor enters the waiting state, realizing the breakpoint function.

[0058] (C2)Pre-set a certain shortcut key as a real-time breakpoint. When the user finds that the use case execution needs to be changed and optimized during the monitoring of the test execution, he can interrupt the currently executing use case by pressing the pre-set shortcut key in the controlled browser, so that the executor enters the waiting state, providing the function of interrupting the running and debugging at any time during the execution of the use case for the user;

[0059] The principle of adding a real-time breakpoint is as follows:

[0060] When starting the browser instance, use the expose_function method of BrowserContext in Playwright to expose the Python end method to the browser context. When calling, set the Python internal interrupt flag variable to True;

[0061] Use the add_init_script method of BrowserContext to inject a JavaScript script into the new page. The script listens to the pre-set shortcut key when the page is initialized;

[0062] When the user presses the pre-set shortcut key in the browser page, the listening script is triggered, and the Python end function exposed to the browser context is called to set the interrupt flag variable to True;

[0063] Before the executor executes each step of the use case, it detects the interrupt flag. If the interrupt flag is True, it throws an exception and interrupts the execution. In the loop body of the loop that gets the queue, the exception is caught, the queue use case is cleared, and the executor enters the waiting state of the loop that gets the queue information, realizing the breakpoint function.

[0064] (C3)When the debugging mode is enabled, the executor automatically adds a failure automatic breakpoint to the use case that fails to run when the use case fails to execute, interrupting the current test;

[0065] The implementation principle of the failure automatic breakpoint is as follows:

[0066] When the use case execution fails, the executor throws an exception of execution failure, and the exception is captured in the loop body of the executor loop acquisition queue, it is judged whether the debugging mode is enabled, if the debugging mode is enabled, all use cases in the queue are emptied, the executor enters into a waiting state, and the breakpoint function is realized.

[0067] (D) Thread management: In UI automation testing, thread management supports viewing and modifying executor thread variables to obtain page data and store the data in variables for subsequent steps and facilitate debugging.

[0068] Specifically, in the UI automation testing execution process, when the use case stores data in the thread variable through the specified interface, the executor stores these variables in a thread-safe common storage area; the storage area adopts a key-value pair structure, and supports cross-use case step data sharing.

[0069] When the user triggers the "view variable" operation in the debugging interface, the front end sends a query request to the server, the request carries the variable name or full-quantity query identifier, the server obtains the corresponding variable value through the reading interface of the storage area, and returns the variable value to the front end in the JSON format, and finally displays the variable value in the debugging panel in the form of tree structure or table.

[0070] In the UI automation testing execution process, the thread management supports that the user directly edits the variable value in the front-end debugging interface; when the modification is submitted, the front end encapsulates the change content into a JSON request and sends the request to the server.

[0071] After the server receives the request, it first verifies whether the variable exists and the modification permission, and then atomically updates the corresponding variable value through the update interface of the common storage area.

[0072] After the update is successful, the server broadcasts the change notification to all clients listening to the variable, and records the operation log in the common storage area, so as to ensure the traceability of the debugging process.

[0073] As can be seen, by using the debugging control and execution management method based on the UI automation testing platform, through the four operations of execution debugging control, local breakpoint mechanism, breakpoint addition and thread management, the test efficiency of the UI automation testing platform can be improved, the convenience of writing and debugging use cases can be improved, and the controllability of the test can be improved.

[0074] The principles and implementation modes of the application are described in detail by using the above specific examples, and these examples are only used to help understand the core technical content of the application. Based on the above specific embodiments of the application, any improvement and modification of the application made by those skilled in the art without departing from the principles of the application shall fall within the patent protection scope of the application.

Claims

1. A debugging control and execution management method based on a UI automated testing platform, characterized in that: It includes four parts: debug control, local breakpoint mechanism, breakpoint addition and thread management: (A) Debug Control: Provides flexible debugging starting point control capabilities that meet use case level, use case segment level, and exit debugging requirements. The front-end implements strategy selection and scheduling and sends corresponding use cases or control signals to the server-side executor. (B) Local breakpoint mechanism: The UI automation test platform executor is ported to the local server. Playwright is used to launch a dedicated controlled browser instance locally to implement real-time monitoring of use case execution. A breakpoint mechanism is built based on the producer-consumer model, allowing the server-side executor to rely on front-end policies to implement queued execution control. (C) Breakpoint Adding: A dynamic breakpoint adding mechanism is proposed, which allows inserting breakpoints during use case execution to avoid repeatedly running the executed use case segment; (D) Thread Management: In UI automation testing, thread management supports viewing and modifying executor thread variables to obtain page data and store it in variables for use in subsequent steps and to facilitate debugging.

2. A debugging control and execution management method based on a UI automated testing platform according to claim 1, characterized in that: Execution (A) addresses use case-level debugging needs and provides: a) a strategy for repeatedly executing the current use case. Under this strategy, the frontend sends the current use case to the server, helping users quickly verify a single use case, fix single use case errors, or reproduce occasional errors; b) Execute the next use case execution strategy. Under this execution strategy, the front-end sends the next use case to the server, supporting step-by-step debugging of use cases and the "write-debug-verify" cycle; To meet the debugging needs at the use case segment level, an execution strategy of executing to the next breakpoint is provided. Under this execution strategy, the front-end sends all use cases between the current use case and the next breakpoint to the server, and executes the necessary use case branches to locate the preset breakpoint. To meet the needs of exiting debugging, we provide: a) Resume execution and ignore breakpoints execution strategy. Under this execution strategy, the front-end sends all remaining use cases to the server and ignores all breakpoints, thus exiting the debugging mode and running all use cases; b) End execution strategy. Under this execution strategy, the front-end sends a stop signal to the server to terminate the current debugging process.

3. The debugging control and execution management method based on the UI automated testing platform according to claim 1, characterized in that: Said (B) specifically includes: (B1) Port the UI automation test platform executor to the local server. When debugging is started, the server uses Playwright to launch and manage a dedicated controlled browser instance locally to execute the user-selected use case, allowing the user to intuitively monitor the use case's running status. (B2) Build a breakpoint core implementation framework based on the producer-consumer model. The local server includes producers and consumers. The server-side producer receives front-end information and adds it to the queue. The server-side consumer is the executor that executes the use case. It essentially depends on and is controlled by the front-end execution strategy and continuously monitors the queue: i) When the queue is not empty, the executor obtains information from the queue in order. a) If the information is a use case, it starts executing the use case and listens to the queue again after the execution is completed. b) If the information is a stop signal, the executor stops listening and closes the thread. ii) When the queue is empty, it enters a blocked waiting state to pause execution at the breakpoint.

4. The debugging control and execution management method based on the UI automated testing platform according to claim 1, characterized in that: Execution (C), the proposed dynamic breakpoint adding mechanism includes adding preset breakpoints to the use cases in the queue, adding real-time breakpoints to the running use cases, and automatically adding failure breakpoints to the use cases that failed to run.

5. A debugging control and execution management method based on a UI automated testing platform according to claim 4, characterized in that: When the executor is executing a test case, it marks a case that has not yet been executed as a preset breakpoint, and sends the case information of the preset breakpoint to the server. When the executor reaches the case marked as the preset breakpoint, it will interrupt the execution and enter the waiting state. Mark a use case that has not yet been executed as a preset breakpoint. The implementation principle is as follows: the server saves the breakpoint use case to a variable. Every time the executor obtains a new use case, it compares the obtained use case with the use case in the variable. When the comparison is consistent, all use cases in the queue are cleared. When the queue is empty, the executor enters the waiting state to implement the breakpoint function.

6. A debugging control and execution management method based on a UI automated testing platform according to claim 4, characterized in that: A shortcut key is preset as a real-time breakpoint. When users find that the use case execution needs to be modified and optimized during the monitoring test execution, they can interrupt the currently executing use case by pressing the preset shortcut key in the controlled browser, putting the executor into a waiting state, providing users with the function of interrupting and debugging the use case execution at any time. The principle of adding real-time breakpoints is as follows: When starting a browser instance, use the expose_function method of BrowserContext in Playwright to expose the Python-side method to the browser context. When calling, set the interrupt flag variable inside Python to True. Use the add_init_script method of BrowserContext to inject a JavaScript script into the new page. The script listens for the preset shortcut keys when the page is initialized. When the user presses the preset shortcut key on the browser page, the monitoring script is triggered, calling the Python function exposed to the browser context and setting the interrupt flag variable to True; Before executing each step of the use case, the executor checks the interrupt flag. If the interrupt flag is True, an exception is thrown and execution is interrupted. The exception is caught in the loop body of the loop to obtain the queue, the queue use case is cleared, and the executor enters the waiting state of the loop to obtain queue information, realizing the breakpoint function.

7. The debugging control and execution management method based on the UI automated testing platform according to claim 4, characterized in that: When the debug mode is enabled, if the executor fails to execute a test case, it will automatically add a failure breakpoint to the failed test case and interrupt the current test; The implementation principle of automatic breakpoint failure is: When the use case fails to execute, the executor throws an exception indicating execution failure and captures the exception in the loop body of the executor's loop to obtain the queue, and determines whether the debug mode is enabled. If the debug mode is enabled, all use cases in the queue are cleared, and the executor enters the waiting state to implement the breakpoint function.

8. The debugging control and execution management method based on the UI automated testing platform according to claim 1, characterized in that: Execution (D): During the execution of UI automated tests, when a use case stores data into thread variables through a specified interface, the executor stores these variables in a thread-safe public storage area. This storage area uses a key-value pair structure to support data sharing across use case steps. When a user triggers the "View Variables" operation in the debugging interface, the front-end sends a query request to the server, carrying the variable name or full query identifier. The server obtains the corresponding variable value through the storage area's read interface and returns it to the front-end in JSON format. The result is displayed in a tree structure or table in the debugging panel.

9. The debugging control and execution management method based on the UI automated testing platform according to claim 8, characterized in that: Execution (D): During the UI automated test execution process, thread management allows users to directly edit variable values ​​in the front-end debugging interface. When submitting changes, the front-end encapsulates the changes as a JSON request and sends it to the server. After receiving the request, the server first verifies whether the variable exists and the modification permission, and then atomically updates the corresponding variable value through the update interface of the public storage area; After the update is successful, the server broadcasts the change notification to all clients listening to the variable and records the operation log in the public storage area to ensure the traceability of the debugging process.

Images