A playwright-based web system permission function automatic testing method
By implementing multi-account concurrent testing through the Playwright framework, and combining multi-mode click and pop-up recognition models, the problems of low efficiency and poor adaptability in web system permission testing are solved, achieving efficient and reliable automated testing.
Patent Information
- Application Number
- CN202610578488.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-04-29
- Publication Date
- 2026-06-05
AI Technical Summary
Existing methods for testing permissions in web systems are inefficient, poorly adaptable, difficult to effectively identify and handle pop-ups, and complex to configure, making them unfriendly to non-technical personnel.
The Playwright framework is used to create multi-account concurrent browser contexts, identify concurrent page instances, use a multi-mode click mechanism and pop-up recognition model, and combine local repositories and machine learning optimizations to automate test configuration.
It enables concurrent testing across multiple accounts and interfaces, improving testing efficiency, enhancing the success rate of element operations and the accuracy of pop-up recognition, simplifying the configuration process, and lowering the barrier to entry.
Smart Images
Figure CN122152713A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of software automated testing technology, specifically a method for automated testing of web system permission functions based on Playwright. Background Technology
[0002] In the development and maintenance of web systems, permission function testing is a crucial step in ensuring system security. Existing permission testing often employs manual testing or relies on traditional automated tools like Selenium. However, these methods have significant drawbacks: When dealing with scenarios involving multiple accounts and multiple interfaces, a serial execution method is usually adopted, resulting in a lengthy testing cycle and low efficiency.
[0003] Element positioning and manipulation rely on preset scripts. When clickable elements are added or modified on the page, the scripts need to be updated manually, resulting in poor adaptability.
[0004] The success rate of element clicks is easily affected by the page loading status, element occlusion, or custom rendering methods.
[0005] Traditional tools have limited ability to identify various pop-up windows (especially those indicating insufficient permissions), making them easy to miss, and they lack an effective screenshot backtracking mechanism.
[0006] The test configuration is cumbersome, requiring manual sorting of the menu structure, which is not user-friendly for non-technical personnel.
[0007] While Playwright, as a next-generation automated testing framework, boasts advantages such as cross-browser compatibility, automatic waiting, and multi-context support, current technologies have not fully leveraged these features to address the specific pain points of permission testing mentioned above. Therefore, there is an urgent need for a targeted, efficient, reliable, and easy-to-use automated testing technology to overcome the shortcomings in current practical applications. Summary of the Invention
[0008] The purpose of this invention is to provide an automated testing method for web system permission functions based on Playwright, so as to solve the problems mentioned in the background art.
[0009] To achieve the above objectives, the present invention provides the following technical solution: An automated testing method for web system permission functions based on Playwright includes the following steps: Step S1: Based on the Playwright framework, create independent browser contexts for multiple test accounts, and launch multiple page instances concurrently for each test account to load different interfaces of the web system under test; Step S2: Identify clickable elements in the currently loaded page and perform click operations based on the locally stored clickable element library. The click operations adopt a multi-mode click mechanism. Step S3: After the click operation is triggered, monitor and identify the pop-up window that appears on the page, take a screenshot of the pop-up window and store it, and update the pop-up window recognition library based on the recognition result; Step S4: Summarize the test results of all test accounts and generate a test report. The test results include permission operation records, pop-up information, and screenshot storage paths.
[0010] As a further aspect of the present invention: in step S1, the browser context creation method provided by the Playwright framework is used to achieve isolation between cookies and local storage among multiple accounts; and multiple page instances under each account are managed through an asynchronous concurrency mechanism, wherein the number of page instances is a configurable positive integer.
[0011] As a further aspect of the present invention: in step S2, identifying clickable elements includes: identifying button labels or link labels, elements whose class names or identifiers contain preset keywords, and elements with clickable style attributes; and storing the selector, text, page path, and corresponding account permission status of the identified clickable elements into a local database to form or iteratively update the clickable element library.
[0012] As a further aspect of the present invention: the multi-mode click mechanism includes a combination of at least three click methods: native click method, native script click method, and coordinate positioning click method, which are tried in turn until the click is successful or all fail.
[0013] As a further aspect of the present invention: in step S3, identifying the pop-up includes: identifying the pop-up based on its DOM structure, style features, and text content, combined with a built-in pop-up identification model; the pop-up identification model at least supports the identification of Toast notification boxes, confirmation boxes, permission-insufficient notification boxes, and notification boxes.
[0014] As a further aspect of this invention: In step S3, the pop-up recognition is based on the features of the built-in front-end framework component library (such as Element UI, Ant Design, etc.), combined with DOM structure, CSS class names, and keywords for matching. The pop-up screenshot is stored in the path format of "date / account / page / pop-up type_timestamp.png", the pop-up text and triggering time are stored in the pop-up database, and the recognition model is continuously optimized using algorithms such as Naive Bayes.
[0015] As a further aspect of the present invention: before step S1, a simplified configuration step is included: the system automatically crawls the navigation bar or sidebar of the page (such as .menu, .sidebar).or (Structure) to generate a menu list; if automatic recognition fails, allow users to specify menu paths through a simple JSON configuration file, with the minimum configuration requiring only IP addresses and a list of accounts.
[0016] This invention also provides an automated testing system for web system permission functions based on Playwright, used to implement the method, including: The configuration module is used to receive test configuration information; The concurrent execution module is used to create independent browser contexts and multiple page instances for multiple accounts; The element recognition and manipulation module is used to identify clickable elements and perform multi-mode clicks. The pop-up recognition and storage module is used to monitor, recognize, and store pop-ups and screenshots. The results output module is used to summarize and output test reports.
[0017] Compared with the prior art, the beneficial effects of the present invention are: 1. High efficiency: Multiple accounts and multiple interfaces can execute concurrently, which can theoretically shorten the test cycle to 1 / N of the original (N is the number of concurrent processes).
[0018] 2. Strong adaptability: The clickable element library and pop-up recognition library have self-iterative capabilities. The more tests are conducted, the more accurate the recognition becomes, and it can smoothly adapt to system evolution.
[0019] 3. High reliability: The multi-mode click guarantee mechanism greatly improves the success rate of element operations and reduces test interruptions or omissions caused by operation failures.
[0020] 4. Easy backtracking: Force screenshots of pop-up windows and create indexes, providing intuitive on-site evidence for abnormal scenarios such as lack of permissions.
[0021] 5. Minimalist configuration: Automatic menu recognition and minimized input design significantly lower the barrier to entry for using the tool and facilitate continuous integration. Attached Figure Description
[0022] Figure 1 This is a schematic diagram of the overall testing process provided in an embodiment of the present invention.
[0023] Figure 2 This is a schematic diagram of the element identification and operation sub-process provided in an embodiment of the present invention.
[0024] Figure 3 This is a schematic diagram of the pop-up recognition and storage sub-process provided in an embodiment of the present invention. Detailed Implementation
[0025] The technical solution of this application will be further described in detail below with reference to specific embodiments.
[0026] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.
[0027]
Example 1
[0028] I. Overall Testing Process (corresponding to) Figure 1 ) like Figure 1 As shown, the overall testing process is as follows: Step 101: Start the test.
[0029] Step 102: Perform configuration input, including the IP address of the Web system, test account and password, concurrency N (the number of interfaces that each account can open at the same time), and menu configuration method (automatic recognition or manual specification).
[0030] Step 103: Based on the Playwright framework, create an independent browser context (browser.new_context()) for each test account to ensure complete isolation of data such as cookies and local storage between accounts.
[0031] Step 104: Under each account, open N interfaces simultaneously according to the configured concurrency level N, and load different directory menu pages of the web system under test. An asynchronous concurrency mechanism (such as Python's asyncio library) is used for management here.
[0032] Step 105: Determine if each page has finished loading. Use the `page.wait_for_load_state(state="networkidle")` method to monitor the page DOM and network resource loading status, ensuring the page is fully loaded before proceeding to the next step. If not, continue waiting; if completed, proceed to step 106.
[0033] Step 106: Identify clickable elements on the current page. This step calls the local clickable element library and combines it with real-time identification results to filter and update elements (see detailed process). Figure 2 ).
[0034] Step 107: For the identified clickable elements, perform click operations using a multi-mode click mechanism, specifically including native Playwright clicks, native JS clicks, and screen coordinate positioning clicks (see detailed process). Figure 2 ).
[0035] Step 108: Determine if the click operation was successful. If successful, proceed to step 109; if unsuccessful, proceed to step 111 and record the operation failure.
[0036] Step 109: Determine if a pop-up is detected after clicking. If a pop-up is detected, proceed to step 110; if not, record it as an authorized operation and continue to the next element.
[0037] Step 110: Execute the pop-up screenshot, information storage, and pop-up library update process (see detailed process). Figure 3 ).
[0038] Step 111: Record operation failures (such as elements being unclickable or having no response after clicking).
[0039] Step 112: Determine whether all interfaces and elements of the current account have been processed. If not, return to step 106 and continue processing the next element or the next interface; if completed, proceed to step 113.
[0040] Step 113: Determine if all test accounts have completed testing. If not, return to step 103 and process the next account; if completed, proceed to step 114.
[0041] Step 114: Generate a test report, which summarizes the permission operation records (with / without permission) of all accounts, pop-up information, and the corresponding screenshot storage paths.
[0042] Step 115: End the test.
[0043] II. Element Identification and Operation Sub-process (corresponding) Figure 2 ) like Figure 2 As shown, the element identification and operation sub-process (corresponding to) Figure 1 Steps 106, 107, and 108 in the text specifically include: Step 201: Load historical clickable element information from the local element library (such as an SQLite database), including element selectors, text, historical click success rates, etc.
[0044] Step 202: Use Playwright's Locator methods (such as page.locator() combined with CSS selectors or XPath) to identify all clickable elements on the current page in real time. The identification scope includes: <button>, Elements whose tags, class, or id contain keywords such as "btn", "link", or "click", as well as elements with the style attribute cursor:pointer.
[0045] Step 203: Compare the elements identified in step 202 with the historical element library loaded in step 201, and filter out newly appearing elements or elements whose status has changed (such as changing from clickable to non-clickable).
[0046] Step 204: Update the local element library, storing the newly added elements and their characteristics into the database, and marking elements with changed states. As the number of tests increases, the coverage of the element library gradually improves.
[0047] Step 205: For the elements that need to be operated on, activate the multi-mode parallel click mechanism.
[0048] Step 206: Prioritize using Playwright's native click method (page.click()), which automatically handles element scrolling, waiting to become visible, and interactive states.
[0049] Step 207: Determine if the native click was successful. If successful, proceed to step 213 and record the permission operation; if unsuccessful, proceed to step 208.
[0050] Step 208: Attempt native JavaScript clicks by directly executing the element.click() method in the browser context using page.evaluate(), thus bypassing Playwright's interaction validation.
[0051] Step 209: Determine if the JS click was successful. If successful, proceed to step 213; if unsuccessful, proceed to step 210.
[0052] Step 210: Attempt a mouse click using the screen coordinate positioning system. First, obtain the element's coordinates in the viewport using element.get_bounding_client_rect(), then simulate a mouse click based on the coordinates using page.mouse.click(x,y).
[0053] Step 211: Determine if the coordinate click was successful. If successful, proceed to step 213; if unsuccessful, proceed to step 212.
[0054] Step 212: Execute the retry mechanism. After a 1-second interval, repeat the above multi-mode click process, retrying a maximum of 1-2 times. If the retry is successful, proceed to step 213; if the retry fails, proceed to step 214 and record the operation failure.
[0055] Step 213: Record the authorized operations (including specific information about the authorized operations).
[0056] Step 214: Record the operation failure (including the reason for the failure and element information).
[0057] III. Pop-up Recognition and Storage Sub-process (corresponding) Figure 3 ) like Figure 3 As shown, the pop-up recognition and storage sub-process (corresponding to) Figure 1 Step 110 in the process specifically includes: Step 301: Detect whether a pop-up appears on the page. Real-time monitoring is performed using Playwright's event listener (page.on("dialog")) and polling specific DOM selectors (such as .toast, .el-message, .ant-modal, etc.).
[0058] Step 302: Upon detecting a pop-up, identify its specific type. Based on the built-in pop-up recognition model (which pre-defines pop-up features of common front-end frameworks such as ElementUI, AntDesign, and Bootstrap), and combined with the pop-up's DOM structure, CSS class name, style features (such as fixed positioning and z-index), and text keywords (such as "insufficient permissions," "no permissions," "confirm," "cancel," etc.), determine the pop-up type, which includes at least: Toast notifications, confirmation boxes, insufficient permissions notifications, notification boxes, and sidebar change prompts.
[0059] Step 303: Immediately call Playwright's page.screenshot() method to capture a complete screenshot of the current page, ensuring that the pop-up content is clearly visible.
[0060] Step 304: Extract key information from the pop-up, including: the text content of the pop-up, the element information that triggered the pop-up (such as element text, selector), the current test account information, and the timestamp of its appearance.
[0061] Step 305: Store the screenshot generated in Step 303 and the pop-up information extracted in Step 304 to the specified local directory and database. Example screenshot path format: . / screenshots / test date / account name / interface name / pop-up type_timestamp.png
[0062] Step 306: Update the pop-up recognition library. For new types of pop-ups identified this time (i.e., features not recorded in the existing recognition library), add their DOM structure, keywords, and style features to the pop-up library. Optionally, optimize the recognition model using machine learning algorithms such as Naive Bayes to gradually improve the accuracy of pop-up recognition in subsequent tests.
[0063] Step 307: Return to the main flow and continue to execute the operation of the next element.
[0064] Test example: Testers prepare an Excel file containing multiple test accounts (such as regular users, administrators, and auditors) and the IP address of the web system under test. In the configuration interface, they import the account file and set the concurrency N=3. After starting the test, the configuration module automatically crawls the system sidebar, identifying the top-level menus such as "Personal Center," "Order Management," and "System Settings," as well as their sub-menus.
[0065] On the "Order Management" page, for the "Batch Delete" button, the system first attempts to use `page.click()`. If this fails due to animation obscuring the button, it automatically downgrades to `page.evaluate()` to execute a JavaScript click. If a successful click results in a "Permission Insufficient" Toast message, the pop-up module immediately takes a screenshot and saves it. Finally, the test report marks the account as lacking permission for this operation. Throughout the process, multiple pages from three accounts were executed concurrently, significantly shortening the testing cycle.
[0066] This Playwright-based automated testing method for web system permission functions enables concurrent execution across multiple accounts and interfaces, significantly shortening the testing cycle and improving efficiency by N times compared to traditional serial testing (where N is the number of concurrent interfaces). It features dynamically iterating clickable element libraries and pop-up recognition libraries; the more tests executed, the higher the recognition accuracy, adapting to different types of web systems. A multi-mode click protection mechanism ensures the success rate of element clicks and dropdown operations, reducing test omissions. Pop-ups are automatically captured and relevant information is stored for easy identification of unauthorized operation scenarios. Testing can be started simply by entering an IP address, username, and password, and automatic menu recognition is supported, requiring no complex configuration and lowering the barrier to entry.
[0067] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of the present invention, and these should also be considered within the scope of protection of the present invention. These will not affect the effectiveness of the implementation of the present invention or the practicality of the patent.< / button>
Claims
1. An automated testing method for web system permission functions based on Playwright, characterized in that, Includes the following steps: Step S1: Based on the Playwright framework, create independent browser contexts for multiple test accounts, and launch multiple page instances concurrently for each test account to load different interfaces of the web system under test; Step S2: Identify clickable elements in the currently loaded page and perform click operations based on the locally stored clickable element library. The click operations adopt a multi-mode click mechanism. Step S3: After the click operation is triggered, monitor and identify the pop-up window that appears on the page, take a screenshot of the pop-up window and store it, and update the pop-up window recognition library based on the recognition result; Step S4: Summarize the test results of all test accounts and generate a test report. The test results include permission operation records, pop-up information, and screenshot storage paths.
2. The automated testing method for web system permission functions based on Playwright according to claim 1, characterized in that, In step S1, the browser context creation method provided by the Playwright framework is used to achieve isolation between cookies and local storage among multiple accounts; and multiple page instances under each account are managed through an asynchronous concurrency mechanism, wherein the number of page instances is a configurable positive integer.
3. The automated testing method for web system permission functions based on Playwright according to claim 1, characterized in that, In step S2, identifying clickable elements includes: identifying button labels or link labels, elements whose class names or identifiers contain preset keywords, and elements with clickable style attributes; and storing the selector, text, page path, and corresponding account permission status of the identified clickable elements into a local database to form or iteratively update the clickable element library.
4. The automated testing method for web system permission functions based on Playwright according to claim 1, characterized in that, The multi-mode click mechanism includes a combination of at least three click methods: native click method, native script click method, and coordinate positioning click method, which are tried in turn until the click is successful or all fail.
5. The automated testing method for web system permission functions based on Playwright according to claim 1, characterized in that, In step S3, identifying the pop-up includes: identifying the pop-up based on its DOM structure, style features, and text content, combined with a built-in pop-up identification model; the pop-up identification model at least supports the identification of Toast notifications, confirmation boxes, permission-insufficient notifications, and notification boxes.
6. The automated testing method for web system permission functions based on Playwright according to claim 5, characterized in that, In step S3, updating the pop-up recognition library includes adding the DOM structure, keywords, and style features of each newly recognized pop-up to the pop-up recognition library.
7. The automated testing method for web system permission functions based on Playwright according to claim 1, characterized in that, Before step S1, a configuration step is also included: receiving the web system IP address, test account list and concurrency number input by the user; and identifying the menu list by automatically crawling the system's navigation bar or sidebar DOM structure, or receiving the menu path configuration specified by the user in JSON format when automatic identification fails.
8. An automated testing system for web system permission functions based on Playwright, characterized in that, To implement the method according to any one of claims 1 to 7, comprising: The configuration module is used to receive test configuration information; The concurrent execution module is used to create independent browser contexts and multiple page instances for multiple accounts; The element recognition and manipulation module is used to identify clickable elements and perform multi-mode clicks. The pop-up recognition and storage module is used to monitor, recognize, and store pop-ups and screenshots. The results output module is used to summarize and output test reports.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method according to any one of claims 1 to 7.