Page adaptive test method and device and electronic equipment

Abstract

The embodiment of the invention provides a page self-adaption testing method and device and electronic device.According to the method, current interface data of a to-be-tested dynamic page are monitored in real time, and under the condition that the current interface data are different from historical interface data, the current interface data are updated according to the interface updating content of the current interface data relative to the historical interface data; and automatically updating page content of the to-be-tested dynamic page and automatically updating execution logic and verification logic associated with the interface updating content in the test case, namely, automatically adjusting an execution path and a verification point in the test case based on the interface updating content to ensure that the test process is matched with the latest data and page state, so that the test efficiency is improved. And a dynamic self-adaptive test strategy is realized, the technical problem of poor adaptability when interface data and UI layout are frequently changed in related technologies is solved, and the test quality and the test efficiency are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of video playback software, and more specifically, to a page adaptive testing method, apparatus, and electronic device. Background Technology

[0002] When software versions are rapidly iterated, UI automation testing methods require frequent manual modification of test scripts to adapt to new interface definitions and UI layout changes. This process is not only time-consuming and labor-intensive, but also prone to introducing new script errors, which seriously affects testing efficiency and software delivery speed. Summary of the Invention

[0003] This application provides a page adaptive testing method, apparatus, and electronic device to at least solve the technical problem of poor adaptability when interface data and UI layout change frequently in related technologies.

[0004] According to one aspect of the embodiments of this application, a page adaptive testing method is provided, including:

[0005] Monitor the current interface data of the dynamic page under test; the dynamic page under test refers to the page that obtains data and updates its content in real time through network requests; the current interface data refers to the latest response data of the network requests of the dynamic page under test; the current interface data includes the page information required to load the dynamic page under test;

[0006] If the current interface data is different from the historical interface data, determine the interface update content of the current interface data relative to the historical interface data, and update the page content of the dynamic page to be tested according to the current interface data to obtain the rendered dynamic page to be tested.

[0007] Update the execution logic and verification logic associated with the updated interface content in the test cases corresponding to the dynamic page to be tested, and obtain the updated test cases. Use the updated test cases to test the rendered dynamic page to be tested.

[0008] According to another aspect of the embodiments of this application, a page adaptive testing apparatus is also provided, comprising:

[0009] The monitoring module is used to monitor the current interface data of the dynamic page under test; the dynamic page under test refers to the page that obtains data and updates its content in real time through network requests; the current interface data refers to the latest response data of the network requests of the dynamic page under test; the current interface data includes the page information required to load the dynamic page under test.

[0010] The page update module is used to determine the interface update content of the current interface data relative to the historical interface data when the current interface data is different from the historical interface data, and update the page content of the dynamic page to be tested according to the current interface data to obtain the rendered dynamic page to be tested.

[0011] The script update module is used to update the execution logic and verification logic associated with the interface update content in the test cases corresponding to the dynamic page under test, so as to obtain the updated test cases. The updated test cases are then used to test the rendered dynamic page under test.

[0012] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed by a processor.

[0013] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the steps in any of the method embodiments described above.

[0014] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to perform the steps of any of the above method embodiments through the computer program.

[0015] This application enables real-time monitoring of the current interface data of the dynamic page under test. When the current interface data differs from the historical interface data, the page content of the dynamic page under test is automatically updated based on the interface update content of the current interface data relative to the historical interface data. The execution logic and verification logic in the test cases associated with the interface update content are also automatically updated. In other words, based on the interface update content, the execution path and verification points in the test cases are automatically adjusted to ensure that the test process matches the latest data and page state. This achieves a dynamic and adaptive test strategy, overcoming the technical problem of poor adaptability when interface data and UI layout change frequently in related technologies, and significantly improving test quality and test efficiency. Attached Figure Description

[0016] Figure 1 This is a schematic diagram illustrating an application scenario of a page adaptive testing method according to an embodiment of this application;

[0017] Figure 2This is a flowchart illustrating an optional page adaptive testing method according to an embodiment of this application;

[0018] Figure 3 This is a flowchart of an optional method for determining a dynamic page according to an embodiment of this application;

[0019] Figure 4 This is a complete flowchart of an optional page adaptation testing method according to an embodiment of this application;

[0020] Figure 5 This is a flowchart of an optional assertion update according to an embodiment of this application;

[0021] Figure 6 This is a structural block diagram of an optional page adaptation testing device according to an embodiment of this application. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] According to one aspect of the embodiments of this application, a page adaptation testing method is provided. Optionally, in this embodiment, the above-described page adaptation testing method may be applied to, but is not limited to, [examples of applications]. Figure 1The hardware environment shown includes terminal device 102 and server 104. Server 104 can be connected to terminal device 102 via a network and can be used to provide services (e.g., application services, etc.) to terminal device 102 or clients installed on terminal device 102. A database can be set up on server 104 or independently of server 104 to provide data storage services for server 104.

[0025] The aforementioned network may include, but is not limited to, at least one of the following: wired network and wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network (WAN), metropolitan area network (MAN), and local area network (LAN). The aforementioned wireless network may include, but is not limited to, at least one of the following: Wireless Fidelity (WIFI) and Bluetooth. Terminal device 102 may be, but is not limited to, a personal computer (PC), mobile phone, tablet computer, etc. Server 104 may be, but is not limited to, a cloud server, server cluster, or other server types.

[0026] The page adaptation testing method of this application embodiment can be executed by server 104, terminal device 102, or jointly by server 104 and terminal device 102. Alternatively, the page adaptation testing method of this application embodiment can be executed by a client installed on the terminal device 102.

[0027] Taking the page adaptation test method in this embodiment executed by terminal device 102 as an example, Figure 2 This is a flowchart illustrating an optional page adaptive testing method according to an embodiment of this application, as shown below. Figure 2 As shown, the process of this method may include the following steps:

[0028] Step S202: Monitor the current interface data of the dynamic page under test; the dynamic page under test refers to the page that obtains data and updates its content in real time through network requests; the current interface data refers to the latest response data of the network requests of the dynamic page under test; the current interface data includes the page information required to load the dynamic page under test.

[0029] Step S204: If the current interface data is different from the historical interface data, determine the interface update content of the current interface data relative to the historical interface data, and update the page content of the dynamic page to be tested according to the current interface data to obtain the rendered dynamic page to be tested.

[0030] Step S206: Update the execution logic and verification logic associated with the interface update content in the test cases corresponding to the dynamic page to be tested, and obtain the updated test cases. Use the updated test cases to test the rendered dynamic page to be tested.

[0031] The page adaptation testing method in this embodiment can be applied to the field of video playback software, specifically to scenarios involving dynamic UI testing of video playback software. For example, this method can be used to perform page adaptation testing in scenarios such as player interface updates, changes to user-personalized recommendation modules, and cross-platform compatibility verification across multiple devices.

[0032] Traditional UI automated test scripts typically pre-set fixed test data or rely on local static data files (such as Excel or JSON). When the data returned by the backend interface changes (such as adding / deleting fields or adjusting the value range), or when facing rapid software version iterations (such as daily builds in agile development models), and when interface definitions or UI layouts change frequently, the test scripts need to be manually modified one by one. This results in extremely low adaptation efficiency and easily introduces new script errors during maintenance. At the same time, existing UI automated testing systems cannot automatically adjust the test case execution logic according to changes in interface data, requiring manual intervention, which leads to low testing efficiency and makes it difficult to meet the needs of rapid software delivery.

[0033] To at least partially solve the aforementioned technical problems, this embodiment monitors the current interface data of the dynamic page under test in real time. When the current interface data differs from the historical interface data, the page content of the dynamic page under test is automatically updated based on the interface update content of the current interface data relative to the historical interface data. The execution logic and verification logic associated with the interface update content in the test cases are also automatically updated. The updated test cases are used to test the rendered dynamic page under test. By deeply coupling interface data with UI automated testing and implementing a dynamic adaptive testing strategy, the technical problem of poor adaptability when interface data and UI layout change frequently in related technologies is overcome, significantly improving test quality and test efficiency.

[0034] The dynamic page under test refers to a page that relies on network requests to obtain data in real time and dynamically updates its displayed content based on the returned data. These pages are commonly found in video playback software, such as video lists and personalized recommendation interfaces. Their content is not statically displayed but changes with the data. The current interface data of the dynamic page under test refers to the latest response data obtained when the dynamic page under test sends a network request to the backend during testing. The historical interface data of the dynamic page under test refers to the interface response data obtained by the same dynamic page under test in previous test cycles or executions. It is used to compare with the current interface data to identify changes in the interface data. Interface update content refers to the differences in data structure, field values, or field attributes found after comparing the current interface data with historical interface data. For example, the addition or deletion of fields, adjustments to numerical ranges, or changes in data types are all part of the interface update content and directly affect the content presentation and functionality of the dynamic page under test.

[0035] A test case is a set of test steps and expected results executed under specific conditions to verify whether software functions as expected; it is the basic unit of software testing. Execution logic specifically refers to the sequence of steps in a test case used to simulate user operations and trigger updates to dynamic page content, including but not limited to clicking buttons, filling out forms, and swiping the screen. Its purpose is to verify whether the dynamic page under test functions correctly and responds to user operations as expected. Verification logic is the set of rules in a test case used to check whether the page state or output meets expectations, primarily implemented through assertions. An updated test case refers to a test case whose execution and verification logic has been automatically adjusted after identifying interface updates and analyzing their impact on page functionality and UI elements, making it adaptable to the latest interface data and page state.

[0036] Updating the execution and verification logic associated with the updated interface content in test cases for the dynamic page under test can employ various methods. For example, when the interface update includes changes to element attributes (such as class and id), regular expressions or data-driven methods can be used to automatically parse and update the element locator statements in the UI test cases, ensuring that the latest element instance is located. The updated element locator statements are then used to locate the target element instance associated with the updated interface content. Using the updated interface content (such as data type changes), UI operation parameters in the target element instance are intelligently adjusted, such as data format conversion in input functions, to ensure data and element matching. Secondly, the addition, deletion, and modification of fields in the current interface data are identified, and the UI verification process is dynamically adjusted, adding or removing verification steps related to field changes to maintain the comprehensiveness and accuracy of the test. For example, after the current interface data is updated, the system automatically identifies the new UI behaviors, dynamically completes the operation steps in the test cases, such as clicking or swiping new elements, and dynamically optimizes the assertion logic. For example, when the data type changes from string to number, the assertion function is updated to match the new data type. Based on the dynamic changes in the interface data, the system intelligently adjusts the selection of UI verification points to ensure that the verification points are consistent with the updated data fields, thereby improving the effectiveness of the test.

[0037] This application also provides a page adaptive testing system, including an interface data parsing module and a UI automation driving module, to achieve deep coupling between interface data and UI automation. Specifically, the structured data dictionary generated by the interface data parsing module is synchronized to the UI automation driving module as dynamic test data for UI operations (e.g., automatically filling the "verifyCode" field value returned by the interface into the UI's "verification code input box"); simultaneously, the UI element data collected by the UI automation driving module is synchronized to the interface data parsing module to verify the consistency between UI data and interface data, thereby achieving bidirectional data synchronization. Then, a correspondence between UI operations and interface requests is established (e.g., the "click login button" operation corresponds to the " / api / user / login" interface request). When a UI operation is executed, the interface data parsing module is automatically triggered to listen to and parse the associated interface, ensuring that each UI operation is linked with the interface data; finally, the UI automation testing process is adjusted according to changes in interface data. For example, when the interface returns a "user not registered" status code, the UI automation process is automatically triggered to jump to the "user registration page" instead of executing the preset "redirect to the homepage after successful login" step.

[0038] The embodiments provided in this application enable real-time monitoring of the current interface data of the dynamic page under test. When the current interface data differs from the historical interface data, the page content of the dynamic page under test is automatically updated based on the interface update content of the current interface data relative to the historical interface data. The execution logic and verification logic associated with the interface update content in the test cases are also automatically updated. In other words, the execution path and verification points in the test cases are automatically adjusted based on the interface update content to ensure that the test process matches the latest data and page state. This achieves a dynamic and adaptive test strategy, overcoming the technical problem of poor adaptability when interface data and UI layout change frequently in related technologies, and significantly improving test quality and test efficiency.

[0039] In one exemplary embodiment, before monitoring the current interface data of the dynamic page under test, the above method further includes:

[0040] Load multiple pages in an offline environment and obtain a snapshot of the first page after the initial loading of the multiple pages; load multiple pages in an online environment and obtain a snapshot of the second page after rendering the multiple pages; compare the first page snapshots and the second page snapshots of the multiple pages, and determine the pages that meet the preset conditions as the dynamic pages to be tested; the preset conditions refer to the condition that the difference between the first page snapshot and the second page snapshot of the same page is greater than a preset threshold.

[0041] The first page snapshot refers to a static snapshot of the page at the moment of its initial load, obtained after loading the dynamic page under test in an offline or simulated offline environment. The first page snapshot includes information such as the initial control structure, position, and visibility of the page, but does not include dynamically loaded content.

[0042] The second page snapshot refers to a complete snapshot of the dynamic page under test after data loading and rendering, under network conditions. Compared to the first page snapshot, the second page snapshot includes dynamically loaded text, images, controls, and other elements, and can comprehensively reflect the true visual state of the page.

[0043] Preset conditions refer to the standards used to determine whether a page is dynamically rendered. Specifically, preset conditions are set when the difference between two snapshots (the first page snapshot and the second page snapshot) exceeds a preset threshold. For example, if the rate of change of page content, the rate of change of images, or the fluctuation of the number of controls exceeds a set percentage, it is considered to meet the preset conditions, and the page is identified as a dynamically rendered page, requiring further automated testing. Preset thresholds refer to the quantitative standards used to evaluate whether a page is dynamic. Preset thresholds set the minimum standard for changes in page state, used to determine whether changes in page content are sufficient to be considered dynamic rendering. Preset thresholds can be set for the rate of change of text, images, and the number of controls; once the change exceeds this threshold, the page is considered to meet the conditions to become a "dynamic page under test."

[0044] By comparing snapshots of the page in offline and online environments, and comparing the differences between the initial page state and the rendered page state, this embodiment can intuitively and accurately identify which pages rely on network requests to update data in real time. This effectively determines whether a page is dynamically rendered, reduces false judgments, and automatically completes snapshot capture and comparison without manual intervention. This simplifies the dynamic page identification process and improves the efficiency of test preparation.

[0045] In one exemplary embodiment, determining a page that meets preset conditions from a plurality of pages as the dynamic page to be tested includes:

[0046] Pages meeting the following criteria are identified as dynamic pages to be tested: text content change exceeds a first preset threshold, image content change exceeds a second preset threshold, control quantity change exceeds a third preset threshold, and unique identifier control quantity change exceeds a fourth preset threshold. Specifically, text content change refers to the change in text content in the second page snapshot relative to the text content in the first page snapshot of the same page; image content change refers to the change in image content in the second page snapshot relative to the image content in the first page snapshot of the same page; control quantity change refers to the change in the number of controls in the second page snapshot relative to the number of controls in the first page snapshot of the same page; and unique identifier control quantity change refers to the change in the number of unique identifier controls in the second page snapshot relative to the number of unique identifier controls in the first page snapshot of the same page.

[0047] The text content change refers to the degree of difference between the text information in the second page snapshot (i.e., the content snapshot after the page has been loaded and rendered in a network environment) and the text information in the first page snapshot of the same page (i.e., the content snapshot when the page is first loaded in a network-free environment). The text content change is determined by calculating the proportion of newly added words or the percentage difference in text content, and is used to measure the magnitude of page text updates. A first preset threshold is the standard for the text content change. When the text content change exceeds the first preset threshold, the page is considered to meet one of the conditions for becoming a dynamic page under test.

[0048] Image content change refers to the difference between the image content in the second page snapshot and the image content in the first page snapshot of the same page. Image content change is measured by comparing changes in attributes such as the image's URL, size, and location, aiming to capture the impact range of page image updates. The second preset threshold is a quantitative standard for image content change. If the image update exceeds the second preset threshold, it indicates a significant difference in page rendering under network conditions, suggesting that the page may be dynamically rendered.

[0049] The change in the number of controls measures the difference between the total number of controls in the second page snapshot and the total number of controls in the first page snapshot. This change reflects the increase or decrease in the number of controls on a page when there is a network connection, and is one of the important indicators for identifying dynamically rendered pages. The third preset threshold is used to determine whether the change in the number of controls is significant. When the change rate in the number of controls exceeds the third preset threshold, the change in the number of controls is identified as one of the characteristics of a dynamically rendered page.

[0050] Unique identifier controls are controls with a unique identifier in the user interface (UI). Typically, a unique identifier is a resource-id attribute (on the Android platform) or other similar attribute (such as a specific identifier on the iOS platform) assigned to the control when building the page. The purpose of a unique identifier is to allow controls to be uniquely identified in a complex view hierarchy, distinguishing and locating multiple similar controls on a page through their specific resource-id. The change in the number of unique identifier controls refers to the change between the number of controls with unique identifiers (such as resource-id) in the second page snapshot and the number of corresponding controls in the first page snapshot. This change in the number of unique identifier controls is particularly crucial for tracking changes to controls with specific functions, revealing significant adjustments to page layout or functional elements. The fourth preset threshold is a quantitative standard specifically for measuring changes in the number of unique identifier controls. If the change in the number of unique identifier controls exceeds the fourth preset threshold, it indicates a significant change in important, function-related controls on the page, providing another key basis for identifying dynamic pages.

[0051] For example, Figure 3 A flowchart for determining a dynamic page is provided in this embodiment, such as... Figure 3 As shown, for each page to be tested, firstly, the page is simulated to load in an environment without a network connection until the initial load is complete. The initial state of the page is recorded, including but not limited to the following:

[0052] a) Text content: Identified by the text or content-desc attribute (Android platform); or label or value attribute (iOS platform).

[0053] b) Image content: Locate the image element using its className (e.g., android.widget.ImageView) or src attribute.

[0054] c) Number of subviews: Recorded by the android.view.ViewGroup property (Android) or the subviews property (iOS).

[0055] d) Unique Identifier Control: A control that specifically records the resource-id.

[0056] Save the information from a)-d) as part of the first page snapshot, including a list and number of key information items.

[0057] Next, restore the network connection, load the same page, and wait for the page to fully render. Repeat the recording process in a)-d) to obtain a second page snapshot, including the same control structure and content information.

[0058] Then, by comparing the first page snapshot and the second page snapshot, the following multi-dimensional analysis is performed:

[0059] Text content change rate: Calculates the proportion of newly added words in the text content.

[0060] Image content change rate: Statistics on the differences and changes in the quantity of image content.

[0061] Control quantity change rate: Analyzes the percentage change in the total number of controls.

[0062] Unique Identifier Control Changes: Track the addition and removal of the resource-id control.

[0063] Finally, a preset threshold is used to determine whether the page is dynamically rendered. That is, if the following conditions are met, it is judged to be a dynamic page to be tested:

[0064] If the change in text content exceeds the first preset threshold (e.g., 30%).

[0065] Or the change in image content exceeds the second preset threshold (e.g., set to 30% to maintain consistency).

[0066] Or the change in the number of controls exceeds the third preset threshold (e.g., 40%).

[0067] Or the change in the number of unique identifier controls exceeds the fourth preset threshold (e.g., 50%).

[0068] When all these metrics reach their corresponding thresholds, the page is determined to be a dynamically rendered page. For pages confirmed as dynamically rendered, the page name, page activity, and all page changes are stored, especially information about differing subviews and their subordinate views. The above process is executed repeatedly for all pages to ensure that all page types are accurately identified and recorded.

[0069] This embodiment comprehensively considers the differences in the number of text, images, controls, and unique identifier controls, providing a more comprehensive and accurate basis for the identification of dynamic pages. Through multi-dimensional comparison, the system can more accurately identify dynamic pages.

[0070] In one exemplary embodiment, the execution logic and verification logic associated with the interface update content in the test cases corresponding to the dynamic page under test are updated to obtain the updated test cases, including:

[0071] 1. Based on the preset association relationship, parse the target interface and page change content associated with the interface update content; the preset association relationship refers to the association relationship between the network request interface, response data and page content of the dynamic page under test;

[0072] 2. Based on the page changes, update the location rules in the test cases used to locate the page changes, and update the execution logic and verification logic in the test cases associated with the target interface and the page changes. Based on the interface update, update the assertions in the verification logic of the test cases associated with the target interface and the page changes to obtain the updated test cases.

[0073] The pre-defined relationships refer to the pre-established mapping between the dynamic page to be tested and the backend network request interface, interface response data, and page content. These pre-defined relationships are determined through systematic analysis of network requests generated during page loading and the direct or indirect connections between these requests and page element updates. This provides a basis for the execution and verification logic related to interface changes in subsequent update test cases.

[0074] The target interface specifically refers to the backend interface directly related to the updates of visible content on the dynamic page under test. Identifying the "pre-defined association" allows us to determine which interface requests and responses affect the dynamic rendering of the page, which is crucial for updating the execution logic of the test cases. In this embodiment, the test cases are associated with the target interface, meaning that the execution and verification of the test cases depend on the data or behavior of the backend interface. It can be understood that the execution logic is a series of operational steps defined in the test case. These steps typically include sending requests to a specific interface, processing the returned data, and performing corresponding operations on the UI (such as filling out a form or clicking a button). The verification logic is the part of the test case used to verify the consistency between the expected and actual results. It is usually based on the data returned by the interface or the UI status. For example, assuming a test case for a login function, the execution logic might include sending a POST request with a username and password to the login interface, parsing the returned JSON data to obtain the login status, and then performing the next operation on the UI, such as redirecting to the user's homepage. The verification logic might include checking whether the login status code returned by the interface indicates a successful login operation, whether the login status flag field in the response body is "true," and whether the user's personal information is correctly displayed on the UI.

[0075] Page changes refer to visible and interactive UI elements or information on the dynamic page under test, driven by specific interface request or response data. For example, page changes include updates to page fields, changes to interface elements, and updates to interface element attributes. In this embodiment, page changes include at least one of the following: page fields and interface elements. Page fields refer to data-driven text or numeric fields on the dynamic page, such as product names and prices. Their updates depend on changes in data returned by the backend interface and are a key component of the test case execution and verification logic. Interface elements refer to visual controls on the dynamic page, including buttons, text boxes, and images. Their display or behavior may be updated due to changes in interface data, directly affecting the user's interactive experience and requiring location and manipulation in the test case. It should be noted that page fields refer to elements that carry data input or display functions; for example, changes to input boxes or field names directly affect the keywords for data interaction in the script. Interface elements, on the other hand, broadly cover all visible or operable components in the user interface, including but not limited to buttons, links, and images. Changes to these (such as position adjustments or style changes) may involve adjustments to the positioning strategy in the UI automation script.

[0076] Positioning rules refer to the rules or methods used in test cases to locate specific elements (such as input boxes, buttons, etc.) on a page. When changes to page content affect the positioning of these elements, the positioning rules need to be updated to ensure that the test cases can accurately find and manipulate these elements. For example, when locating elements using XPath, CSS selectors, or IDs, the positioning rules need to be adjusted accordingly when the element attributes change.

[0077] An assertion is a specific condition or rule in a test case used to verify whether the data returned by an interface or the actual displayed value of a page element meets expectations. Assertions typically exist in the form of conditional statements, used to compare actual results with expected results and determine whether the test case passes or fails based on the comparison result. For example, an assertion can be an equation comparing the value of a field returned by an interface with the expected value, or a regular expression verifying whether the text content of a page element conforms to a specific format. Verification logic includes the design and execution process of assertions; that is, how to set assertion conditions based on expected results and actually execute these assertions during test execution to verify the test objective. In a test case, verification logic uses assertions to specifically verify interface data or page content. When the assertion condition is met, the verification passes; otherwise, the verification fails, and the test case is marked as failed and related error information is logged. Verification logic is a broader concept, encompassing all steps and rules in a test case used to verify the test objective, including data preparation, assertion design, and execution flow. An assertion, on the other hand, is the specific condition in the verification logic used to directly compare actual results with expected results. Assertions are specific, executable conditional statements that directly verify the actual values ​​of data returned by an API or page elements.

[0078] Optionally, the client automatically loads the first page snapshot (in a network-free environment) and the second page snapshot (in a network environment) of all dynamic pages under test. The client captures and records all network requests and their responses related to the dynamic pages under test using a pre-defined network request interceptor, establishing a pre-defined relational database. The client analyzes the differences between the second and first page snapshots to identify the page elements or information affected by the interface update. Based on the pre-defined relational database, the client parses the target interface (i.e., the interface related to the page content update) and the changed page content (the specific page elements affected by the interface update). The client updates the execution logic in the test cases based on the changed page content, adjusting the operation steps for interacting with the target interface, such as parameter passing and request methods, to ensure that the test cases can correctly trigger the content update of the dynamic page. The client updates the verification logic in the test cases, generating or adjusting assertion conditions based on the latest state of the changed page content to ensure accurate verification of whether the page content is consistent with the interface response data. The client stores the updated test cases as the basis for subsequent automated testing, completing the dynamic evolution of the test cases.

[0079] Figure 4 This is a complete flowchart of a page adaptive testing method provided in this embodiment, as follows: Figure 4As shown, dynamic UI pages are identified, and the association between dynamic UI pages and corresponding interfaces is established. When interface data changes, the UI elements are dynamically located in the automation process, and dynamic assertion updates are implemented to obtain updated test cases. The updated test cases are then used to execute UI automation tests, obtain test results analysis, and dynamically optimize test cases based on the test results analysis.

[0080] This embodiment, based on the pre-defined association between the deep coupling between dynamic pages and network request interfaces, analyzes the updated interface content and can automatically identify the affected page changes and the underlying target interface. This enables precise test case adjustments. According to the update of the target interface, the execution logic of data input, control operations, etc., involved in the test cases is automatically adjusted, allowing the test scripts to seamlessly connect to the new interface definition without manual intervention. Combined with the changes in page content, the verification logic points (such as assertion conditions) in the test cases are dynamically updated, ensuring that automated testing can accurately reflect the latest UI performance and business logic, improving the robustness and accuracy of the tests.

[0081] In one exemplary embodiment, after monitoring the current interface data of the dynamic page under test, the above method further includes the following steps:

[0082] 1. Obtain multiple network requests from the dynamic page under test, filter out invalid requests from the multiple network requests, and obtain the response data of the filtered multiple network requests.

[0083] Among them, multiple network requests refer to multiple HTTP / HTTPS requests initiated by the dynamic page under test to the backend server during loading or user interaction, including but not limited to GET, POST and other types. These requests are usually used to obtain data, submit forms or trigger page updates.

[0084] Invalid requests refer to network requests that do not directly lead to page content updates. Examples include, but are not limited to, loading static resources (such as images, CSS, and JS files), requests with unsuccessful status codes (such as 404 and 500 errors), and duplicate requests (such as polling requests). Invalid requests are filtered out in the initial screening stage to reduce data processing volume and improve efficiency. In this embodiment, invalid requests are filtered according to preset filtering rules. For example, static resources (static resource filtering supports dynamic configuration, such as images (.png / .jpg), CSS (.css), JS (.js), fonts (.woff), etc.) determined by URL suffix or response header Content-Type) can be excluded from a list of multiple network requests, along with unsuccessful responses (abnormal response status codes such as 404 and 500, requests with empty or incorrect response bodies), and duplicate requests (repeated calls to the same URL (such as polling requests), where the first or last valid request can be retained), resulting in a "list of valid dynamic rendering requests" (containing only interfaces that may affect page content).

[0085] Response data refers to the HTTP / HTTPS response content returned by the backend server for each valid network request. It is usually in JSON or XML format and contains the data required for the dynamic page update under test.

[0086] Second, based on the page content before each network request and the page content after each network request, obtain the page update content corresponding to each network request, and establish the first association between the network request interface and the page update content.

[0087] Among them, the page update content refers to the UI elements or information that change on the dynamic page under test before and after each network request, including text, images or control states, which is the core part that needs to be verified in dynamic page testing.

[0088] The first association refers to the mapping relationship between the network request interface and the page update content it causes. It is established by comparing the changes in page content before and after the request, and is used to determine which interface requests directly affect the dynamic rendering of the page.

[0089] Third, parse the response data corresponding to each network request to obtain the data field tree of the response data for each network request.

[0090] A data field tree refers to a tree-shaped data structure obtained after structured parsing of response data. It is used to intuitively display the hierarchical relationship and field composition of the data, facilitating subsequent field extraction and relationship generation.

[0091] Fourth, extract fields from the page update content corresponding to each network request, match the fields in the page update content corresponding to each network request with the data field tree of the response data corresponding to each network request, and generate a second association relationship between the page update content and the response data based on the matching structure.

[0092] Among them, element features refer to specific attributes or content of UI elements extracted from the page update content, such as product name text, price value, etc., which are used to compare and match with fields in the response data to ensure the accuracy of dynamic rendering page testing.

[0093] The second relationship refers to the mapping relationship established by the client between the "element features in the updated page content" and the "data field tree corresponding to the response data", which ensures that every change on the dynamic page can accurately correspond to the response data of the backend interface.

[0094] V. Generate preset associations based on the first and second associations.

[0095] Optionally, the client first uses a network request interceptor to obtain all network requests and corresponding response data for each dynamic page under test. Specifically, tools such as mitmproxy are used to capture HTTPS traffic in proxy mode. The client records detailed information for each network request, including URL, method (GET / POST), request headers, response headers, response body (JSON / HTML format), request timestamp, and response completion timestamp. Based on preset filtering rules, the client excludes static resource requests (such as images, CSS, JS files, etc.), unsuccessful responses (status codes other than 200), and duplicate requests, obtaining a "list of valid dynamic rendering requests." In the filtered request list, the client further obtains the response data for each valid request, providing a foundation for establishing subsequent preset relationships. By comparing page snapshots before and after each network request, changes in the number of text, images, and controls on the page are automatically identified, yielding the updated page content corresponding to each valid request. The client associates the identified page update content with the captured valid network requests, clarifying the primary association between the interface of each network request and the rendered content of a specific area of ​​the page (i.e., the page update content), namely the "interface URL → rendering area" mapping, such as " / api / goods interface corresponds to the product list area on the page", or / api / user / profile → user information div#user-info. The client further analyzes to confirm the uniqueness of the mapping between each request URL and the page area, avoiding confusion caused by multiple requests pointing to the same area. When multiple requests are associated with the same content area, different rendering logic scenarios are distinguished by comparing request parameters (such as pagination identifiers ?page=1 and ?page=2), ensuring comprehensive test case coverage. The client extracts the response data structure corresponding to each network request, parses the response body (JSON / XML) of each valid network request, and generates a data field tree (such as { goods: [{ id: 1, name: "mobile phone"}, ...]}) for subsequent field matching. The client extracts element features (text, attribute values, etc.) from the updated page content, such as the product name "mobile phone" and the price "¥3999". Using string matching and rule matching, the extracted element features are matched against the data field tree. Based on the matching results, a second association relationship is recorded between the response data and the updated page content. According to the first and second association relationships, the mapping relationship between the interface URL, response fields, and the page DOM path is recorded, forming a preset association relationship of "interface URL → response field → rendering DOM path", ensuring that each data field accurately corresponds to its corresponding display position on the UI interface.By repeatedly executing the above steps, a complete pre-defined relational database is established through the process of obtaining requests → filtering valid requests → snapshot comparison → field mapping. This clarifies the precise correspondence between each dynamic request and the page changes it causes, achieving deep coupling and dynamic adaptation between the interface and UI automation.

[0096] This embodiment proactively filters invalid network requests, avoiding the need to focus on static resources and invalid requests, significantly reducing testing and maintenance costs and improving testing efficiency. It establishes a one-to-one mapping (i.e., the first association) between network request interfaces and page update content, matching element features in the page update content with fields in the response data to generate a precise mapping (i.e., the second association) between the page update content and the response data. This ensures that changes in elements on dynamic pages can directly correspond to specific fields in the interface data, solving the blind spot problem of test scripts regarding data changes. This allows automated testing to automatically adjust with data changes, greatly reducing maintenance workload.

[0097] In one exemplary embodiment, the positioning rules used to locate the page changes in the test cases are updated according to the page changes, including:

[0098] Identify the original location rule template used to locate the original page content corresponding to historical interface data, and replace the target placeholder in the original location rule template that matches the page change content with the page change content.

[0099] The client continuously monitors the API metadata storage unit (such as a database or cache) of the dynamic page under test, comparing historical API data with the latest current API data in real time to accurately identify the type of API data change. The change type can include: adding elements, removing elements, and changing attributes. For example, when a new returned field is detected, the change details are automatically recorded; when the field data type changes from integer to string, or the field value range changes from a fixed value to a dynamic range, the association rule update is triggered. Before each automated test execution, this awareness step is performed first to dynamically refresh the preset association relationships between page elements and API returned fields, ensuring data consistency.

[0100] In the automated testing framework, multiple location rule templates are pre-created. Each template contains placeholders to adapt to dynamic changes in the attributes of different UI elements, and each template is associated with a UI element of a specified type. The client monitors the current interface data of the dynamic page under test in real time. When the current interface data changes, the updated interface content is determined, the original location rule template corresponding to the most recent historical interface data is obtained, the target placeholder in the original location rule template corresponding to the updated interface content is identified, and the target placeholder is replaced with the updated page content in the updated interface content. For example, when the client detects that the field "buttonText" of a UI element attribute changes from "Submit" to "Confirm", it triggers a front-end button text update. The client automatically analyzes the element location rules and changes "Submit" in the original location rule template to "Confirm". For example, the XPath location condition will be updated in real time from " / / button[text()='Submit']" to " / / button[text()='Confirm']"; adaptive optimization of CSS selectors or ID locators is also supported.

[0101] In this embodiment, the updated location rules are used to locate page elements in the automated testing process. Specifically, the updated location rules are used to locate the target of the execution logic on the page, and the corresponding test operations are performed on the target according to the execution logic. Then, the page execution result after the test operations on the target is obtained using the updated location rules, and the page execution result is verified based on the verification logic to obtain the test result.

[0102] In some embodiments, during test execution, when the interface returns an exception status code (such as 500 Internal Server Error, 403 Insufficient Permissions, 404 Resource Not Found, or 502 Gateway Error), the client automatically activates a preset exception handling process. This includes retrying the interface request (up to 3 retries with a 2-second interval), recording detailed error logs to a specified file (including timestamps and error context), and intelligently skipping subsequent dependency steps to prevent the test script from crashing. Simultaneously, the client dynamically adjusts the test strategy based on the exception type; for example, it automatically rolls back to a low-privilege test scenario in case of permission errors, improving fault tolerance.

[0103] Optionally, extract the original location rule template from the test case (e.g., XPath / / button[text()='Submit']), and identify dynamic placeholders in the original location rule template (e.g., ...). {buttonText}); Based on the preset association (such as the button text on the page corresponding to the buttonText field returned by the interface), the changed content on the page (such as "Submit" → "Confirm") is mapped to the target placeholder, and the target placeholder in the original positioning rule template is replaced with the changed content (such as generating a new XPath / / button[text()='Confirm']).

[0104] This embodiment identifies the original positioning rule template used to locate the original page content corresponding to historical interface data. Based on the latest data returned by the interface or page changes (such as the new button text "Confirm"), the target placeholder in the original positioning rule template that matches the page changes is replaced with the page changes. The placeholders in the original positioning rule template are automatically replaced, and positioning rules adapted to the new page are generated. This adapts to UI changes without manual intervention, reducing maintenance costs. It enables automatic adjustment of test case execution logic and UI element positioning rules based on changes in interface data, achieving dynamic self-adaptation of the testing system and solving the rigidity problem caused by strong coupling between data and UI positioning.

[0105] In one exemplary embodiment, updating the execution logic and verification logic associated with the target interface and page change content in the test case includes:

[0106] When the page changes include adding new UI elements, generate verification test cases corresponding to the new UI elements and insert them into the test cases. Verification test cases include execution logic and verification logic associated with the target interface and specific to the new UI elements. When the page changes include removing UI elements, identify the sub-test cases associated with the removed UI elements in the test cases, mark the sub-test cases as obsolete, and remove the obsolete test cases from the test cases. Obsolete test cases include execution logic and verification logic associated with the target interface and specific to the removed UI elements. When the page changes include updating the attributes of UI elements, identify the original attributes of the UI elements in the test cases before the update, and replace the original attributes in the test cases with the target attributes of the UI elements after the update.

[0107] Verification test cases are automated test logic units generated for newly added UI elements on a page. They include execution logic associated with the target interface (such as calling the interface to retrieve data of the new element) and verification logic (such as asserting whether the displayed text, status, or interactive behavior of the new element meets expectations). For example, after adding a "Submit" button, the verification test case will call the associated interface to retrieve the button text and assert that it is displayed as "Submit".

[0108] Deprecated test cases are sub-test cases associated with removed UI elements. They contain execution logic (such as clicks or input actions) and validation logic (such as assertions about the element's existence or correct attributes) for that element. Because the element is removed, they lose their execution meaning and must be removed from the test case. For example, a deprecated test case might contain the step of "clicking the save button." After the element is removed, this test case is removed to prevent test errors.

[0109] The original attribute is the attribute value (such as text, ID, style) of the interface element recorded in the test case before the update. It is used to compare with the updated target attribute to guide the attribute replacement in the test case. The target attribute is the latest attribute value (such as text, ID, style) of the interface element after the update. It is used to replace the original attribute in the test case to ensure that the test logic is consistent with the current page. For example, when the button text changes from "OK" to "Confirm", the system recognizes the original attribute "OK" recorded in the test case and replaces it with the updated target attribute "Confirm".

[0110] In this embodiment, the use case evolution strategies for different scenarios are shown in Table 1:

[0111] Table 1

[0112]

[0113] In this embodiment, upon detecting a new element, a complete test case containing execution and verification logic is automatically generated and inserted into the existing test case set without manual intervention. Sub-test cases are automatically marked as obsolete and removed from the test process, while the reason for obsolescence is recorded for subsequent auditing, avoiding false alarms and interruptions caused by executing obsolete test cases. Based on the latest data returned by the page or interface, the original attributes are replaced with the target attributes, and the positioning rules and assertion conditions are updated synchronously. This allows for adaptation to attribute changes without rewriting test cases, improving maintenance efficiency and supporting efficient regression testing under rapid iteration.

[0114] In one exemplary embodiment, the assertions associated with the target interface and the changed page content in the verification logic of a test case based on interface-based content updates include:

[0115] The updated content of the interface is parsed, and the fields of the parsed interface response data are extracted to obtain the target fields. The expected values ​​of the assertions in the verification logic of the test cases that are associated with the target interface and the page changes are updated to the target fields.

[0116] The target field is a field extracted from the response data of the updated interface content and directly related to the changed page content. It is used to replace the old expected value in the test case verification logic to ensure that the assertion is consistent with the latest interface data. For example, after parsing the interface response data, key fields (such as text: "Confirm", id: "submitBtn") are extracted as target fields and replaced with the corresponding original expected values ​​(such as the old text "OK") in the verification logic. For example, after the button text is updated, the target field text: "Confirm" will overwrite the original assertion value, allowing the test to pass.

[0117] In this embodiment, the assertions associated with the target interface and page changes in the test cases are not hard-coded, but should be dynamically generated or selected based on the interface response. The core of the assertions in this embodiment lies in parsing the interface update content, extracting the target fields, and dynamically generating verification points to replace hard-coded expected values.

[0118] Optionally, Figure 5 A flowchart of an assertion update provided for an embodiment of this application is shown below. Figure 5 As shown, firstly, an intelligent assertion engine is built. The intelligent assertion engine achieves adaptability through the following steps: It performs structured parsing of the interface response (e.g., JSONPath extraction), identifies fields associated with page changes (e.g., the text of the "Add" button, user status), directly maps the parsed target field (e.g., user_status: "VIP") to the expected value of the assertion, avoiding manual maintenance of static values, and binds the generated expected value to the actual value of the UI element (e.g., text, attributes) to form an executable assertion condition. Secondly, it obtains and parses the current interface data (as explained in the above embodiments and will not be repeated here).

[0119] Next, design dynamic assertion rules. For example, for conditional assertions (which refer to performing different validations based on a specific state returned by the API), the code example for conditional assertions is as follows:

[0120] # Assume the API response includes user status

[0121] user_status = jsonpath.jsonpath(response_data, ' .data.userInfo.status')[0]

[0122] if user_status == "VIP":

[0123] expected_credit_line = 10000 # Expected credit limit for VIP users

[0124] else:

[0125] expected_credit_line = 5000 # Expected credit limit for regular users

[0126] actual_credit_line = jsonpath.jsonpath(response_data, ' .data.userInfo.creditLine')[0]

[0127] assert actual_credit_line == expected_credit_line, f"Credit limit mismatch, expected: {expected_credit_line}, actual: {actual_credit_line}"

[0128] For example, in assertions based on fuzzy matching and pattern recognition, regular expressions are used for assertions rather than exact matching for dynamically changing data (such as order IDs and timestamps). The corresponding code example is as follows:

[0129] import re

[0130] order_id = jsonpath.jsonpath(response_data, ' .data.orderId')[0]

[0131] # Verify that the order ID conforms to a specific format (e.g., starting with ORD followed by 10 digits).

[0132] assert re.match(r'^ORD\d{10} (, order_id), f"Order ID format error: {order_id}"

[0133] - Extract expected values ​​from the response: Extract data directly from the API response as the expected result of the UI assertion. This is key to achieving "adaptive" behavior.

[0134] # Expected value of username obtained from API response

[0135] expected_username = jsonpath.jsonpath(response_data, ' .data.userInfo.name')[0]

[0136] # This expected_username will be used for subsequent UI assertions.

[0137] Finally, the assertions are adaptively updated based on the current interface data. The assertion logic and positioning method need to be able to automatically adjust as the interface data or UI changes. The adjustment method for the positioning rules has been explained in the above embodiments and will not be repeated here. Automatic updating of assertions includes using the data returned by the interface as input for UI operations to dynamically generate element locators. A corresponding code example is as follows:

[0138] # Extract the search box positioning method from the configuration information obtained from the front-end interface

[0139] search_input_locator=jsonpath.jsonpath(config_response, ' .ui_locators.search_input')[0]

[0140] # Use dynamically obtained positioning to find and manipulate elements.

[0141] search_input = driver.find_element(By.XPATH, search_input_locator)

[0142] search_input.send_keys("search keyword")

[0143] Next, obtain the actual UI value (i.e., the target field), compare the actual UI value with the expected value extracted from the interface, replace the expected value of the associated assertion in the test case with the target field, and use the updated expected value to verify the UI state. The corresponding code example is as follows:

[0144] # Retrieve the expected username from the API

[0145] expected_username = jsonpath.jsonpath(response_data, ' .data.userInfo.name')[0]

[0146] # Get the actual username displayed from the UI

[0147] actual_username = driver.find_element(By.ID, "user-name-label").text

[0148] # Perform assertion comparison

[0149] assert actual_username == expected_username, f"The username displayed in the UI does not match; expected: {expected_username}, actual: {actual_username}"

[0150] In some embodiments, the automatic update process of assertions in this embodiment achieves precise assertions, focusing only on core business fields and avoiding assertions on frequently changing irrelevant fields (such as timestamps and dynamic IDs). It also implements data-driven testing, separating test data from test logic; expected values ​​can be read from external files (such as JSON, CSV) or configuration management for easy maintenance. Furthermore, it implements fault tolerance and logging, providing clear error messages when assertions fail, such as `assert response.status_code == 200, f"Expected 200, got {response.status_code}"`. Detailed interface responses and UI status are recorded for troubleshooting in case of failure. It also balances verification granularity: in smoke testing, only key fields are verified to ensure basic functionality. In full regression testing, more detailed verification is performed, including data consistency and business state transitions.

[0151] In some embodiments, this embodiment can also establish a UI automated testing system capable of automatically sensing changes, intelligently analyzing, and self-optimizing, realizing a dynamic evolution loop of test cases from "data collection - multi-dimensional analysis - intelligent completion - baseline solidification." The goal is to enable the UI test case library to evolve collaboratively with product iterations, like a "living organism," continuously ensuring product quality. Optionally, such as... Figure 5 As shown, it includes the following steps:

[0152] I. Data Collection: Collect "feedback signals" that reflect testing gaps. This includes test execution result analysis: pass / fail results of automated tests, error logs and screenshots of failed test cases. UI Change Execution Anomaly Test Case Capture: Identify test cases that cause execution anomalies due to UI changes from failed test cases based on error log information. The key is to transform UI changes into structured data to provide input for subsequent analysis. Human Feedback Monitoring: Monitor execution logs and human feedback channels to collect relevant data.

[0153] II. Intelligent Decision Center: Based on the analysis results, automatically or semi-automatically optimize test cases, incorporate changed test cases into the baseline, improve the success rate of UI automated test case execution and reduce maintenance costs.

[0154] This embodiment implements an adaptive verification strategy that combines "intelligent assertions based on interface responses" with "automatic UI assertion updates," improving the robustness and maintainability of automated testing. By using interface data as the sole source of information, it drives the dynamic generation and adjustment of UI verification logic, effectively addressing frequently changing data and UI.

[0155] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0156] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0157] According to another aspect of the embodiments of this application, a page adaptation testing apparatus is also provided. This page adaptation testing apparatus can be used to implement the page adaptation testing method provided in the above embodiments, and details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0158] Figure 6 This is a structural block diagram of an optional page adaptation testing device according to an embodiment of this application, such as... Figure 6 As shown, the page adaptation testing device includes:

[0159] The monitoring module 602 is used to monitor the current interface data of the dynamic page under test; the dynamic page under test refers to the page that obtains data and updates its content in real time through network requests; the current interface data refers to the latest response data of the network requests of the dynamic page under test; the current interface data includes the page information required to load the dynamic page under test.

[0160] The page update module 604 is used to determine the interface update content of the current interface data relative to the historical interface data when the current interface data is different from the historical interface data, and update the page content of the dynamic page to be tested according to the current interface data to obtain the rendered dynamic page to be tested.

[0161] The script update module 606 is used to update the execution logic and verification logic associated with the interface update content in the test cases corresponding to the dynamic page under test, so as to obtain the updated test cases. The updated test cases are then used to test the rendered dynamic page under test.

[0162] It should be noted that the monitoring module 602 in this embodiment can be used to execute the above step S202, the page update module 604 in this embodiment can be used to execute the above step S204, and the script update module 606 in this embodiment can be used to execute the above step S206.

[0163] In an exemplary embodiment, before monitoring the current interface data of the dynamic page to be tested, the monitoring module 602 is further configured to load multiple pages in a network-free environment and obtain a first page snapshot after the initial loading of the multiple pages; load multiple pages in a network-connected environment and obtain a second page snapshot after the multiple pages are rendered; compare the first page snapshots and the second page snapshots of the multiple pages, and determine the page that meets the preset conditions among the multiple pages as the dynamic page to be tested; the preset conditions refer to the condition that the difference between the first page snapshot and the second page snapshot belonging to the same page is greater than a preset threshold.

[0164] In an exemplary embodiment, the monitoring module 602 is further configured to identify pages among multiple pages that meet the following conditions as dynamic pages to be tested: the change in text content is greater than a first preset threshold, the change in image content is greater than a second preset threshold, the change in the number of controls is greater than a third preset threshold, and the change in the number of unique identifier controls is greater than a fourth preset threshold; wherein, the change in text content refers to the change in text content in the second page snapshot relative to the change in text content in the first page snapshot of the same page; the change in image content refers to the change in image content in the second page snapshot relative to the change in image content in the first page snapshot of the same page; the change in the number of controls refers to the change in the number of controls in the second page snapshot relative to the change in the number of controls in the first page snapshot of the same page; and the change in the number of unique identifier controls refers to the change in the number of unique identifier controls in the second page snapshot relative to the change in the number of unique identifier controls in the first page snapshot of the same page.

[0165] In an exemplary embodiment, the script update module 606 is further configured to parse the target interface and page change content associated with the interface update content based on a preset association relationship; the preset association relationship refers to the association relationship between the network request interface, response data and page content of the dynamic page under test; according to the page change content, update the positioning rules used to locate the page change content in the test case, and update the execution logic and verification logic associated with the target interface and page change content in the test case, and update the assertions associated with the target interface and page change content in the verification logic of the test case based on the interface update content, so as to obtain the updated test case.

[0166] In an exemplary embodiment, after monitoring the current interface data of the dynamic page under test, the script update module 606 is further configured to acquire multiple network requests under the dynamic page under test, filter invalid requests among the multiple network requests, and acquire the response data of the filtered multiple network requests; based on the page content before each network request and the page content after each network request, acquire the page update content corresponding to each network request, and establish a first association relationship between the interface of the network request and the page update content; parse the response data corresponding to each network request to obtain the data field tree of the response data corresponding to each network request; extract element features from the page update content corresponding to each network request, match the element features in the page update content corresponding to each network request with the data field tree of the response data corresponding to each network request, and generate a second association relationship between the page update content and the response data based on the matching structure; and generate a preset association relationship based on the first association relationship and the second association relationship.

[0167] In an exemplary embodiment, the script update module 606 is further configured to identify an original positioning rule template for locating the original page content corresponding to the historical interface data, and replace the target placeholder in the original positioning rule template that matches the page change content with the page change content.

[0168] In an exemplary embodiment, the script update module 606 is further configured to: generate verification test cases corresponding to the newly added interface elements when the page change content includes new interface elements, and insert the verification test cases into the test cases; the verification test cases include execution logic and verification logic associated with the target interface and for the newly added interface elements; when the page change content includes removed interface elements, determine the sub-test cases associated with the removed interface elements in the test cases, mark the sub-test cases as obsolete test cases, and remove the obsolete test cases from the test cases; the obsolete test cases include execution logic and verification logic associated with the target interface and for the removed interface elements; when the page change content includes attribute updates of interface elements, identify the original attributes of the interface elements in the test cases before the update, and replace the original attributes in the test cases with the target attributes of the interface elements after the update.

[0169] In an exemplary embodiment, the script update module 606 is further configured to parse the interface update content, extract fields from the parsed interface response data to obtain the target field, and update the expected value of the assertion associated with the target interface and page change content in the verification logic of the test case to the target field.

[0170] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0171] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein the program executes the steps in any of the above method embodiments when it is run.

[0172] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0173] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor is configured to perform the steps of any of the method embodiments described above via the computer program. In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0174] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0175] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0176] The above are merely preferred embodiments of this application and are not intended to limit 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 principles of this application should be included within the protection scope of this application.

Claims

1. A method for testing page adaptiveness, characterized in that, include: Monitor the current interface data of the dynamic page under test; The dynamic page to be tested refers to a page that obtains data and updates its content in real time through network requests; The current interface data refers to the latest response data of the network request to the dynamic page under test; The current interface data includes the page information required to load the dynamic page to be tested; If the current interface data is different from the historical interface data, determine the interface update content of the current interface data relative to the historical interface data, and update the page content of the dynamic page to be tested according to the current interface data to obtain the rendered dynamic page to be tested. Update the execution logic and verification logic associated with the updated interface content in the test cases corresponding to the dynamic page to be tested, and obtain the updated test cases. Use the updated test cases to test the rendered dynamic page to be tested.

2. The method according to claim 1, characterized in that, Before monitoring the current interface data of the dynamic page under test, the method further includes: Load multiple pages in an offline environment and obtain a snapshot of the first page after the initial loading of the multiple pages; Load the multiple pages in a network environment and obtain a second snapshot of the rendered multiple pages; By comparing the first page snapshot and the second page snapshot of the plurality of pages, the page that meets the preset conditions is determined as the dynamic page to be tested; the preset conditions refer to the condition that the difference between the first page snapshot and the second page snapshot of the same page is greater than a preset threshold.

3. The method according to claim 2, characterized in that, The step of determining the page that meets the preset conditions from the plurality of pages as the dynamic page to be tested includes: The page that meets the following conditions among the multiple pages is identified as the dynamic page to be tested: the change in text content is greater than a first preset threshold, the change in image content is greater than a second preset threshold, the change in the number of controls is greater than a third preset threshold, and the change in the number of unique identifier controls is greater than a fourth preset threshold; wherein, the change in text content refers to the change in text content in the second page snapshot relative to the change in text content in the first page snapshot of the same page; the change in image content refers to the change in image content in the second page snapshot relative to the change in image content in the first page snapshot of the same page; the change in the number of controls refers to the change in the number of controls in the second page snapshot relative to the change in the number of controls in the first page snapshot of the same page; and the change in the number of unique identifier controls refers to the change in the number of unique identifier controls in the second page snapshot relative to the change in the number of unique identifier controls in the first page snapshot of the same page.

4. The method according to claim 1, characterized in that, The updated test cases are obtained by updating the execution logic and verification logic associated with the interface update content in the test cases corresponding to the dynamic page under test, including: Based on the preset association relationship, the target interface and page change content associated with the interface update content are analyzed; the preset association relationship refers to the association relationship between the network request interface, response data and page content of the dynamic page under test; Based on the page change content, update the location rules in the test case used to locate the page change content, and update the execution logic and verification logic in the test case associated with the target interface and the page change content. Based on the interface update content, update the assertions in the verification logic of the test case associated with the target interface and the page change content, and obtain the updated test case.

5. The method according to claim 4, characterized in that, After monitoring the current interface data of the dynamic page under test, the method further includes: Obtain multiple network requests from the dynamic page under the test, filter out invalid requests from the multiple network requests, and obtain the response data of the filtered multiple network requests; Based on the page content before each network request and the page content after each network request, obtain the page update content corresponding to each network request, and establish a first association between the network request interface and the page update content. Parse the response data corresponding to each network request to obtain a data field tree of the response data corresponding to each network request; Extract element features from the page update content corresponding to each network request, match the element features in the page update content corresponding to each network request with the data field tree of the response data corresponding to each network request, and generate a second association relationship between the page update content and the response data based on the matching structure. The preset association relationship is generated based on the first association relationship and the second association relationship.

6. The method according to claim 4, characterized in that, The step of updating the location rules in the test case for locating the page changes based on the page changes includes: Identify the original location rule template used to locate the original page content corresponding to the historical interface data, and replace the target placeholder in the original location rule template that matches the page change content with the page change content.

7. The method according to claim 4, characterized in that, The update of the execution logic and verification logic associated with the target interface and the page change content in the test case includes: If the page changes include new interface elements, a verification test case corresponding to the new interface element is generated, and the verification test case is inserted into the test case; the verification test case includes execution logic and verification logic associated with the target interface and for the new interface element. If the page changes include the removal of interface elements, identify the sub-test cases associated with the removed interface elements in the test cases, mark the sub-test cases as obsolete test cases, and remove the obsolete test cases from the test cases; the obsolete test cases include execution logic and verification logic associated with the target interface and targeting the removed interface elements; When the page changes include updating the attributes of interface elements, identify the original attributes of the interface elements in the test case before the update, and replace the original attributes in the test case with the target attributes of the interface elements after the update.

8. The method according to claim 4, characterized in that, The assertions associated with the target interface and the page change content in the verification logic for updating the test case based on the updated content of the interface include: The updated content of the interface is parsed, and the fields of the parsed interface response data are extracted to obtain the target field. The expected value of the assertion associated with the target interface and the page change content in the verification logic of the test case is updated to the target field.

9. A page adaptive testing device, characterized in that, include: The monitoring module is used to monitor the current interface data of the dynamic page under test; The dynamic page under test refers to a page that obtains data and updates its content in real time through network requests; the current interface data refers to the latest response data of the network requests to the dynamic page under test. The current interface data includes the page information required to load the dynamic page to be tested; The page update module is used to determine the interface update content of the current interface data relative to the historical interface data when the current interface data is different from the historical interface data, and update the page content of the dynamic page to be tested according to the current interface data to obtain the rendered dynamic page to be tested. The script update module is used to update the execution logic and verification logic associated with the interface update content in the test cases corresponding to the dynamic page under test, so as to obtain the updated test cases. The updated test cases are then used to test the rendered dynamic page under test.

10. 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 computer program, it implements the steps of the method according to any one of claims 1 to 8.

Images