Front-end test method, device, equipment, medium and program product

Abstract

The invention provides a front-end testing method which can be applied to the technical field of artificial intelligence and software testing. The front-end testing method comprises the following steps: in response to operation of a first automatic testing script, acquiring loading index data of a front-end page in real time; wherein a pre-trained long-short-term memory network model is integrated in the first automatic test script; on the basis of the loading index data, predicting page loading time in real time by utilizing a pre-trained long-short-term memory network model; and dynamically determining a first waiting strategy according to the currently predicted page loading time, and performing front-end testing on the to-be-tested application based on the first waiting strategy. The invention further provides a front-end testing device and equipment, a storage medium and a program product.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and software testing technology, and more specifically to a front-end testing method, apparatus, device, medium, and program product. Background Technology

[0002] In front-end automated testing, automated testing tools can simulate user operations and perform end-to-end testing of applications. Automated test scripts can be used to verify the application's page elements, form submissions, user interactions, navigation flows, and other functions, ensuring that the application works properly in different browsers and environments. Among these, page loading is a crucial step in ensuring the successful execution of automated test scripts. Page loading wait ensures that page elements are loaded completely, avoiding test failures due to missing elements.

[0003] However, the page loading wait strategy of traditional automated testing tools has certain limitations. This wait strategy cannot adapt to dynamic and complex front-end pages, increases the performance overhead of front-end automated testing, and may also result in inaccurate or unstable page loading wait, leading to inaccurate test results and affecting the overall efficiency of testing. Summary of the Invention

[0004] In view of the above problems, this application provides front-end testing methods, apparatus, equipment, media and program products to improve testing efficiency.

[0005] According to a first aspect of this application, a front-end testing method is provided, comprising: in response to running a first automated test script, acquiring loading indicator data of a front-end page in real time; wherein the first automated test script integrates a pre-trained long short-term memory network model; based on the loading indicator data, using the pre-trained long short-term memory network model to predict the page loading time in real time; and dynamically determining a first waiting strategy based on the currently predicted page loading time, and performing front-end testing on the application to be tested based on the first waiting strategy.

[0006] According to an embodiment of this application, the method further includes: in the event of an abnormality in the execution of the pre-trained long short-term memory network model, performing front-end testing on the application under test based on a second waiting strategy; wherein the second waiting strategy includes one or more of fixed-duration waiting, rule waiting, event listening waiting, and element state waiting.

[0007] According to an embodiment of this application, the first waiting strategy includes: determining a current waiting time based on the currently predicted page load time; and waiting for the front-end page to load page elements based on the current waiting time, so as to resume front-end testing of the application under test.

[0008] According to an embodiment of this application, the step of predicting page load time in real time using the pre-trained Long Short-Term Memory network model based on the loading index data includes: cleaning the loading index data; the cleaning includes one or more of missing value processing, outlier processing, and noise processing; processing the cleaned loading index data using a sliding window technique to obtain current time series data; and inputting the current time series data into the pre-trained Long Short-Term Memory network model to output the currently predicted page load time.

[0009] According to an embodiment of this application, the step of processing the cleaned loading indicator data using sliding window technology to obtain the current time series data includes: performing sliding processing on the cleaned loading indicator data corresponding to the front-end page based on a preset sliding window size and sliding interval to extract the current window data corresponding to the preset sliding window; and aggregating the current window data corresponding to the preset sliding window to obtain the current time series data.

[0010] According to an embodiment of this application, the method further includes: collecting test result logs of front-end testing; updating the training dataset of the long short-term memory network model based on the test result logs; and training the pre-trained long short-term memory network model based on the updated training dataset.

[0011] According to an embodiment of this application, the training process of the Long Short-Term Memory Network model includes: collecting historical indicator data for different pages; cleaning the historical indicator data; the cleaning includes one or more of missing value processing, outlier processing, and noise processing; processing the cleaned historical indicator data using a sliding window technique to obtain historical time series data; and training the Long Short-Term Memory Network model based on the historical time series data through online learning to predict the page loading time corresponding to the different pages.

[0012] According to an embodiment of this application, the collection of historical indicator data for different pages includes: monitoring the currently loaded page in response to running a second automated test script; marking the current page based on a Uniform Resource Locator (URL); and collecting historical indicator data corresponding to the marked current page based on feature indicators to obtain historical indicator data for the different pages.

[0013] According to an embodiment of this application, the step of processing the cleaned historical indicator data using sliding window technology to obtain historical time series data includes: grouping the different pages based on page tags; wherein, one group corresponds to one sliding window; performing sliding processing on the cleaned historical indicator data corresponding to the pages of the current group based on the sliding window of the current group to extract the current window data corresponding to the sliding window of the current group; and aggregating the current window data corresponding to the sliding window of the current group to obtain the historical time series data.

[0014] A second aspect of this application provides a front-end testing apparatus, comprising: a data acquisition module, configured to acquire loading index data of a front-end page in real time in response to running a first automated test script; wherein the first automated test script integrates a pre-trained long short-term memory network model; a time prediction module, configured to predict the page loading time in real time based on the loading index data using the pre-trained long short-term memory network model; and a first testing module, configured to dynamically determine a first waiting strategy based on the currently predicted page loading time, and perform front-end testing on the application under test based on the first waiting strategy.

[0015] According to an embodiment of this application, the apparatus further includes: a second testing module, configured to perform front-end testing on the application under test based on a second waiting strategy in the event of an execution anomaly in the pre-trained long short-term memory network model; wherein the second waiting strategy includes one or more of fixed-duration waiting, rule-based waiting, event listening waiting, and element state waiting.

[0016] According to an embodiment of this application, the first test module includes: a first waiting unit, configured to determine a current waiting time based on the currently predicted page load time; and based on the current waiting time, wait for the front-end page to load page elements in order to resume front-end testing of the application under test.

[0017] According to an embodiment of this application, the time prediction module includes: a cleaning unit for cleaning the loading indicator data; the cleaning includes one or more of missing value processing, outlier processing, and noise processing; a sliding window unit for processing the cleaned loading indicator data using sliding window technology to obtain current time series data; and a time prediction unit for inputting the current time series data into the pre-trained long short-term memory network model and outputting the currently predicted page load time.

[0018] According to an embodiment of this application, the sliding window unit includes: a data extraction unit, used to perform sliding processing on the cleaned loading indicator data corresponding to the front-end page based on a preset sliding window size and sliding interval, so as to extract the current window data corresponding to the preset sliding window; and a data aggregation unit, used to aggregate the current window data corresponding to the preset sliding window to obtain the current time series data.

[0019] According to an embodiment of this application, the apparatus further includes: a model update module, configured to collect test result logs of front-end testing; update the training dataset of the long short-term memory network model according to the test result logs; and train the pre-trained long short-term memory network model based on the updated training dataset.

[0020] According to an embodiment of this application, the apparatus further includes: a model training module, used to collect historical indicator data of different pages; clean the historical indicator data; the cleaning includes one or more of missing value processing, outlier processing, and noise processing; process the cleaned historical indicator data using a sliding window technique to obtain historical time series data; and based on the historical time series data, train the Long Short-Term Memory network model through online learning to predict the page loading time corresponding to the different pages.

[0021] According to an embodiment of this application, the model training module includes: a historical data acquisition unit, configured to monitor the currently loaded page in response to running a second automated test script; mark the current page based on a Uniform Resource Locator (URL); and collect historical indicator data corresponding to the marked current page based on feature indicators to obtain historical indicator data for the different pages.

[0022] According to an embodiment of this application, the model training module further includes: a time series data acquisition unit, used to group the different pages based on page tags; wherein, one group corresponds to one sliding window; based on the sliding window of the current group, performing sliding processing on the cleaned historical indicator data corresponding to the pages of the current group to extract the current window data corresponding to the sliding window of the current group; and aggregating the current window data corresponding to the sliding window of the current group to obtain the historical time series data.

[0023] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0024] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0025] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0026] In the embodiments of this application, by introducing the temporal prediction capability and real-time feedback mechanism of the Long Short-Term Memory Network model, the invalid waiting of front-end page loading is eliminated, resource consumption and operation and maintenance costs are reduced, testing efficiency is improved, and the adaptability to complex dynamic scenarios is enhanced. Attached Figure Description

[0027] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0028] Figure 1 The illustration shows an application scenario diagram of the front-end testing method, apparatus, device, medium, and program product according to embodiments of this application;

[0029] Figure 2 A flowchart illustrating a front-end testing method according to an embodiment of this application is shown schematically;

[0030] Figure 3 Another flowchart of a front-end testing method according to an embodiment of this application is illustrated schematically;

[0031] Figure 4 A flowchart illustrating the time prediction process of a front-end testing method according to an embodiment of this application is shown in the schematic diagram.

[0032] Figure 5 This illustration schematically shows a model training flowchart of a front-end testing method according to an embodiment of this application;

[0033] Figure 6 A schematic diagram illustrating the structure of a front-end testing apparatus according to an embodiment of this application is shown; and

[0034] Figure 7 A block diagram schematically illustrates an electronic device suitable for implementing a front-end testing method according to an embodiment of this application. Detailed Implementation

[0035] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0036] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0037] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0038] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0039] Waiting for page elements to load is a fundamental step in front-end automated testing, directly impacting the stability and efficiency of the test. Traditional automated testing tools have limitations in their waiting strategies, primarily manifested in the following ways:

[0040] (1) Fixed waiting time leads to low test efficiency (excessive waiting) or elements not being fully loaded (insufficient waiting).

[0041] (2) Waiting strategies based on simple rules (such as periodic active polling) cannot adapt to dynamic and complex front-end pages, such as asynchronous loading, dynamic rendering, network latency fluctuations, etc.

[0042] (3) It does not take into account the dynamic features of the front-end page, such as changes in the DOM (Document Object Model) tree, event queues, and network request status.

[0043] (4) Lack of ability to learn from and predict historical waiting data.

[0044] The above issues increase the performance overhead of front-end automated testing and can also cause inaccurate or unstable page loading times for automated testing tools on different platforms, resulting in inaccurate test results and affecting the overall efficiency of testing.

[0045] This application provides a front-end testing method, comprising: in response to running a first automated test script, acquiring real-time loading metric data of the front-end page; wherein the first automated test script integrates a pre-trained Long Short-Term Memory (LSTM) network model; based on the loading metric data, using the pre-trained LTM network model to predict the page loading time in real time; and dynamically determining a first waiting strategy based on the currently predicted page loading time, and performing front-end testing on the application under test based on the first waiting strategy. By introducing the temporal prediction capability and real-time feedback mechanism of the LTM network model, invalid waiting for front-end page loading is eliminated, resource consumption and maintenance costs are reduced, testing efficiency is improved, and adaptability to complex dynamic scenarios is enhanced.

[0046] Figure 1 The illustration shows an application scenario diagram of the front-end testing method, apparatus, device, medium, and program product according to embodiments of this application.

[0047] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0048] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0049] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0050] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0051] It should be noted that the front-end testing method provided in this application embodiment can generally be executed by server 105. Correspondingly, the front-end testing device provided in this application embodiment can generally be located in server 105. The front-end testing method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the front-end testing device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0052] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0053] The following will be based on Figure 1 The described scene, through Figures 2-5 The front-end testing method according to the embodiments of this application will be described in detail.

[0054] Figure 2 A flowchart illustrating a front-end testing method according to an embodiment of this application is shown.

[0055] like Figure 2 As shown, the front-end testing method of this embodiment includes operations S210 to S230. This front-end testing method is not limited to a specific execution subject. The execution subject can be any electronic device, such as a terminal device or a server device, etc. The execution subject can also be any software application or client.

[0056] During operation S210, in response to running the first automated test script, the loading metric data of the front-end page is obtained in real time; wherein, the first automated test script integrates a pre-trained long short-term memory network model.

[0057] The first automated test script is the front-end test script for the application under test. When this first automated test script is run, operations S210 to S230 are executed automatically. A pre-trained Long Short-Term Memory (LSTM) network model is integrated and loaded into the automated test script. The waiting logic of the automated test tool is modified, and the LSTM model is called to dynamically determine the waiting time. The LSTM model is a special type of Recurrent Neural Network (RNN). By introducing gating mechanisms (forget gate, input gate, output gate) and memory cells, it effectively solves the gradient vanishing problem of traditional RNNs when processing long sequences, and can retain important information for a long time.

[0058] Automated test scripts are programs written using the application programming interfaces (APIs) of automated testing tools. They are used to automatically execute test scenarios for web applications. These scripts can verify page elements, form submissions, user interactions, navigation flows, and other functionalities, ensuring the application functions correctly across different browsers and environments. Automated testing tools are programs, frameworks, or platforms used to automate software testing tasks. They can simulate user operations, verify expected results, and generate test reports. They can significantly improve testing efficiency, reduce human error, and are particularly suitable for regression testing and cross-environment compatibility testing that require frequent execution. They help software development teams improve testing efficiency, shorten testing cycles, and ensure software quality.

[0059] Loading metrics data include, but are not limited to, network request (such as HTTP (Hypertext Transfer Protocol) response time and resource loading order), DOM tree structure changes (such as node addition, deletion and attribute modification), performance metrics (such as memory usage, DOM content loading completion event and loading event triggering status), element attributes (such as visibility, disabled status, loading status), and operation behaviors (such as click, swipe and input).

[0060] When operating the S220, page load time is predicted in real time using a pre-trained long short-term memory network model based on loading metric data.

[0061] When the first automated test script runs, it acquires real-time page load metric data for the relevant front-end pages running under that script and inputs it into a pre-trained LSTM model. Based on the learned patterns, the model predicts page load time, which includes the time when page elements appear and the time when the page is fully loaded. The time when page elements appear includes, but is not limited to, the time when elements become visible and the time when elements are rendered.

[0062] When operating S230, the first waiting strategy is dynamically determined based on the currently predicted page load time, and the front-end test of the application under test is performed based on the first waiting strategy.

[0063] Page load time will affect the waiting strategy. The first waiting strategy is based on the page load time predicted by the model. Since the predicted page load time varies at different times, the first waiting strategy will be dynamically adjusted accordingly. For example, if the model predicts that the price of a certain product will appear within 5-7 seconds after the page starts loading, the first automated test script will intelligently wait within this time period, and then continue the automated test application after the intelligent wait is completed.

[0064] In the embodiments of this application, intelligent waiting is performed based on model prediction results, rather than blindly waiting for a long time or frequently querying irregularly. This avoids wasting time due to excessive waiting and prevents test failures caused by performing subsequent operations before the elements are ready due to insufficient waiting, significantly improving the efficiency and accuracy of automated testing. By introducing the temporal prediction capability and real-time feedback mechanism of the Long Short-Term Memory network model, invalid waiting for front-end page loading is eliminated, reducing resource consumption and maintenance costs, improving testing efficiency, and enhancing adaptability to complex dynamic scenarios.

[0065] Waiting for page loading is a core action in front-end automated testing, ensuring that test operations are synchronized with the page state. The core logic of the first waiting strategy is to wait for page elements to load based on predicted results, covering the entire process from page initialization and interactive operations to result verification. This ensures that the test script executes according to the actual page loading rhythm, avoiding misjudgments or failures due to elements not being ready. Applications under test include, but are not limited to, general front-end applications, financial trading platforms, investment and wealth management applications, financial analysis applications, and insurance product applications. For example, the process of implementing front-end testing for an insurance product application using automated test scripts is as follows:

[0066] Test preparation and environment initialization: Launch your browser and open the target webpage of the insurance product application. Wait for the basic elements of the homepage (such as the navigation bar) to finish loading (based on the time the elements are first visible) to ensure that the basic framework of the page is ready.

[0067] Test case execution and pre-interaction wait times: Before an operation is triggered (e.g., clicking a button / link), wait for the target button element to become visible and clickable (based on element rendering completion time). Before entering data into a form, wait for the DOM node of the input box element to be generated (to avoid operations on non-existent elements). After page navigation, such as after clicking the login button, wait for the homepage elements (e.g., user avatar, welcome message) to appear after successful login to confirm that the page has switched.

[0068] Asynchronous operations and dynamic content processing: After triggering an asynchronous request (such as loading more data or pull-to-refresh), wait for the list items, cards, and other elements corresponding to the new data to become visible (based on element rendering time) to ensure that the content loading is complete.

[0069] Handling dynamic components: Wait for all modal boxes, buttons, etc. of the pop-up element to render (based on the element rendering time) to avoid operation failure due to incomplete animation.

[0070] Assertion validation and result checking: Validate element existence, such as waiting for the "error message text" element to appear after submitting a form (based on the element's visibility time) to confirm the message logic is correct. Validate content updates, such as waiting for the total price element to refresh and display the new value after adding an insurance product to the shopping cart (based on data rendering completion time).

[0071] The front-end testing process is based on the time of element appearance. The element is rendered before the operation, and the result element is updated after the interaction. During verification, the target element is ensured to be visible. The test is dynamically waited for the page element to load instead of a fixed delay, so as to realize the automated operation of synchronizing the test action with the page loading rhythm.

[0072] According to an embodiment of this application, the first waiting strategy includes: determining a current waiting time based on the currently predicted page load time; and waiting for the front-end page to load page elements based on the current waiting time in order to resume front-end testing of the application under test.

[0073] Based on the current waiting time, wait for the front-end page to load page elements, that is, pause the execution of the first automated test script. When the current waiting time ends, resume the execution of the automated test script to perform front-end testing on the application under test.

[0074] In the embodiments of this application, the automated test script waits intelligently during this time period and continues front-end testing after the wait ends, instead of blindly waiting for a long time or frequently querying irregularly. This avoids wasting time caused by waiting too long and prevents test failures caused by performing subsequent operations before the page elements are ready due to waiting too short a time, thus significantly improving the efficiency and accuracy of automated testing.

[0075] Figure 3 Another flowchart of a front-end testing method according to an embodiment of this application is illustrated schematically.

[0076] like Figure 3 As shown, the front-end testing method of this embodiment includes operations S310 to S340.

[0077] In operation S310, in response to the execution of the first automated test script, the loading metric data of the front-end page is obtained in real time; wherein, the first automated test script integrates a pre-trained long short-term memory network model. The method of operating S310 is the same as that of operating S210 described above, and will not be repeated here.

[0078] In operation S320, based on loading metric data, a pre-trained Long Short-Term Memory (LSTM) network model is used to predict page load time in real time. The method for operating S320 is the same as that for operating S220 described earlier, and will not be repeated here.

[0079] The system detects in real time whether the pre-trained long short-term memory network model is executing normally. If it is, operation S330 is executed; otherwise, operation S340 is executed.

[0080] When operating S330, assuming the pre-trained Long Short-Term Memory (LSTM) network model is functioning normally, a first waiting strategy is dynamically determined based on the currently predicted page load time. Then, front-end testing of the application under test is performed based on this first waiting strategy. The operation of S330 is the same as that described earlier for S230, and will not be repeated here.

[0081] When operating the S340, in the event of an anomaly in the execution of the pre-trained Long Short-Term Memory network model, front-end testing of the application under test is performed based on a second waiting strategy; wherein, the second waiting strategy includes one or more of fixed-duration waiting, rule waiting, event listening waiting, and element state waiting.

[0082] The system monitors in real time whether the pre-trained Long Short-Term Memory (LSTM) network model is executing normally. When LSTM model execution abnormalities are detected, such as interruption of data flow, abnormal metrics (e.g., CPU utilization > 95%), or failure of LSTM model to return results within the expected time, the system automatically reverts to the traditional waiting mechanism of the automated testing tool, i.e., the second waiting strategy. The second waiting strategy includes fixed-duration waiting, rule-based waiting, event listening waiting, and element state waiting. Fixed-duration waiting: forces a wait for a specified number of milliseconds; rule-based waiting: a simple rule-based waiting strategy (e.g., periodic active polling); event listening waiting: listens for page events (e.g., pop-ups, animation endings) and waits for them to be triggered; element state waiting: waits for elements to meet specific states (e.g., visible, interactive, existent).

[0083] In the embodiments of this application, when an abnormal situation occurs in the Long Short-Term Memory network model, conventional second waiting strategies such as fixed-duration waiting, rule waiting, event listening waiting, and element state waiting are used to automatically fall back to the traditional waiting mechanism of the automated testing framework to ensure that the testing process is not interrupted.

[0084] According to an embodiment of this application, after performing front-end testing on the application under test and completing the front-end testing, the front-end testing method further includes: collecting test result logs of the front-end testing; updating the training dataset of the long short-term memory network model according to the test result logs; and training the pre-trained long short-term memory network model based on the updated training dataset.

[0085] During the execution of the first automated test script, logs of scripts that run successfully or fail are collected and used for real-time feedback analysis. Based on the test result log set, the LSTM model training dataset is updated to form a closed-loop optimization.

[0086] In the embodiments of this application, real-time feedback analysis is performed to collect test result log sets, update the training long short-term memory network model, and form a closed-loop optimization.

[0087] Figure 4 A flowchart illustrating the time prediction process of a front-end testing method according to an embodiment of this application is shown.

[0088] like Figure 4 As shown, operation S220, which uses a pre-trained long short-term memory network model to predict page loading time in real time based on loading index data, includes operations S410 to S430.

[0089] In operation S410, the loaded indicator data is cleaned; cleaning includes one or more of the following: missing value handling, outlier handling, and noise handling.

[0090] Through data cleaning and sliding window processing, the loaded indicator data is uniformly converted into a time series format usable by the LSTM model. During the data cleaning phase, because the loaded indicator data may contain missing values, noise, or outliers—for example, data from certain time points may be lost due to collection errors, or some indicator values ​​may be obviously unreasonable (such as negative response times), or some values ​​may lack timestamps—different measures are taken to address these issues. For missing values, if the missing value is transient, linear interpolation is used to fill it; if the missing value is for a long period, the data for that period is directly removed. For outliers, abnormal records can be removed based on statistical methods or business rules (such as considering a response time > 30 seconds as a timeout). For noise, an exponentially weighted moving average (EMA) smoothing method can be used.

[0091] When operating the S420, the sliding window technique is used to process the cleaned loaded index data to obtain the current time series data.

[0092] According to an embodiment of this application, in operation S420, the cleaned loading index data is processed using sliding window technology to obtain the current time series data, including the following steps:

[0093] First, based on the preset size and sliding interval of the sliding window, sliding processing is performed on the cleaned loading indicator data of the front-end page to extract the current window data corresponding to the preset sliding window.

[0094] The preset sliding window is a pre-determined appropriate window size (e.g., 5 minutes) and sliding interval (e.g., 1 minute), which corresponds to the value of the next 1 minute time window based on the data of the past 5 minutes on the page.

[0095] Secondly, the data of the current window corresponding to the preset sliding window is aggregated to obtain the current time series data.

[0096] A queue is used to store the data within each window. After each window slides, the current window is aggregated. The aggregated data after the sliding window includes dimension identifiers, time windows, and aggregation metrics. The time window includes the window start and end times, and the aggregation metrics can include multiple indicators, such as resource quantity and access count. The aggregation results of each window constitute the time series data input to the LSTM model. Simultaneously, the statistical results of each window are stored as time series data. Finally, each group, after sliding window processing, outputs three-dimensional time series data: (number of samples, time steps, number of features), corresponding to (dimensional identifiers, time windows, aggregation metrics), respectively. For example, the output of a financial product details page is (90, 5, 2), indicating 90 samples (windows), each sample containing 5 time steps (5 minutes), and each time step containing 2 features.

[0097] In the embodiments of this application, data is extracted through a sliding window to achieve dynamic analysis of loading indicator data, thereby improving the real-time performance and accuracy of loading indicator data processing, so as to accurately predict the current predicted page loading time.

[0098] In operation S430, the current time series data is input into a pre-trained Long Short-Term Memory (LSTM) network model, and the current predicted page load time is output. Here, the current predicted page load time is the current predicted value within the current predicted page load time.

[0099] The pre-trained Long Short-Term Memory (LSTM) network model takes as input time-series data in a three-dimensional tensor format: (number of samples, time step, number of features), and outputs the current predicted page load time for the corresponding front-end page.

[0100] In the embodiments of this application, a sliding window is used to load the time series data corresponding to the indicator data from the extracted page, which facilitates the Long Short-Term Memory Network to quickly predict the page loading time and lays a good data foundation for front-end testing.

[0101] Figure 5The diagram illustrates a model training flowchart in a front-end testing method according to an embodiment of this application.

[0102] like Figure 5 As shown, the training process of the Long Short-Term Memory Network model includes operations S510 to S540.

[0103] When operating the S510, historical indicator data is collected from different pages.

[0104] According to an embodiment of this application, the process of collecting historical indicator data from different pages in operation S510 includes the following steps:

[0105] First, in response to running the second automated test script, monitor the currently loaded page.

[0106] The second automated test script is used during the LSTM model training phase. It automatically collects dynamic indicator feature data from front-end page loading and converts it into time-series data suitable for LSTM model training. This second automated test script can utilize existing or newly written automated testing tools to collect historical indicator data from different pages. When this script starts running, monitoring begins upon page loading.

[0107] Secondly, the current page is marked based on the Uniform Resource Locator.

[0108] Different URLs are used to label pages with tags. For example, the URL of a login page is tagged as "login," and the URL of a financial product details page is tagged as "product." A URL is a standard address format used to identify and locate resources (such as web pages, images, and videos) on the internet; different URLs correspond to different pages or resources.

[0109] Finally, based on the feature indicators, historical indicator data corresponding to the current marked page is collected to obtain historical indicator data for different pages.

[0110] The system collects characteristic metrics for the marked pages. These metrics include: network requests (such as HTTP response time and resource loading order), DOM tree structure changes (such as node addition, deletion, and attribute modification), performance metrics (such as memory usage, DOM content loading completion events, and loading event trigger states), element attributes (such as visibility, disabled state, and loading state), and user actions (such as clicks, swipes, and input). User actions from the moment the page loads until a specific element appears, such as clicks, swipes, and input, are also included in the data collection. Page loading time is recorded, including the time from when a page element starts loading to when it appears, and the actual time from when navigation begins to when loading is complete. Each collected data point is saved in JSON format, i.e., metric data. Metric data represents the raw data of the collected page, while historical metric data represents all metric data that appeared during the current page loading process. For example, for an e-commerce product details page, the characteristic metrics collected might include the number and size of images, the number of scripts, file size, network latency from when the user clicks a link to when the page starts loading, and page elements (such as product titles, price information, and detailed parameters).

[0111] In the embodiments of this application, by collecting historical indicator data, a comprehensive indicator data foundation is provided, which can accurately predict page loading time and improve the accuracy and efficiency of front-end testing.

[0112] When operating S520, historical indicator data is cleaned; cleaning includes one or more of the following: missing value processing, outlier processing, and noise processing.

[0113] During the data cleaning phase, historical indicator data may contain missing values, noise, or outliers. For example, data from certain time points may be lost due to collection errors, or some indicator values ​​may be obviously unreasonable (such as negative response times), or some values ​​may lack timestamps. Therefore, different measures are taken to address these issues. For missing values, if the missing value is temporary, linear interpolation is used to fill it in; if the missing value is for a long period, the data for that period is directly removed. For outliers, outlier records can be removed based on statistical methods or business rules (such as considering a response time > 30 seconds as a timeout). For noise, exponentially weighted moving average (EMA) smoothing can be used.

[0114] When operating the S530, the historical indicator data after cleaning is processed using the sliding window technique to obtain historical time series data.

[0115] According to an embodiment of this application, in operation S530, the historical indicator data after cleaning is processed using sliding window technology to obtain historical time series data, the following steps are included:

[0116] First, based on page tags, different pages are grouped; each group corresponds to a sliding window.

[0117] The sliding window technique is used to process the cleaned data. The first step is to group the data according to page tags. For example, the login page and the product details page are in different groups. The sliding window is applied independently to each group.

[0118] Secondly, based on the sliding window of the current group, sliding processing is performed on the cleaned historical indicator data corresponding to the page of the current group to extract the current window data corresponding to the sliding window of the current group.

[0119] The appropriate window size (e.g., 5 minutes) and sliding interval (e.g., 1 minute) can be determined for each group, representing the value of the time window for predicting the next 1 minute based on the data from the past 5 minutes on the corresponding page.

[0120] Finally, the data of the current window corresponding to the sliding window of the current group is aggregated to obtain historical time series data.

[0121] A queue is used to store the data within each group window. Each time a window slides, the current window is aggregated. The aggregated data after the sliding window includes dimension identifiers, time windows, and aggregation metrics. The time window includes the window start and end times, and the aggregation metrics can include multiple indicators, such as average page load time, number of resources, and number of visits. The aggregation result for each window constitutes a sample data set for training the LSTM model. Simultaneously, the statistical results for each group and each window are stored as time series data. Finally, each group, after sliding window processing, outputs three-dimensional time series data: (number of samples, time steps, number of features), corresponding to (dimensional identifiers, time windows, and aggregation metrics), respectively. For example, the login page output is (100, 5, 3), indicating 100 samples (windows), each sample containing 5 time steps (5 minutes), and each time step containing 3 features.

[0122] In the embodiments of this application, by aggregating sliding window data and extracting aggregated features from the input long short-term memory network model, the input of the long short-term memory network model can be optimized, which can simplify data, reduce noise, improve model training efficiency and prediction accuracy, and enhance generalization ability.

[0123] When operating the S540, a long short-term memory network model is trained online based on historical time series data to predict the page load time for different pages.

[0124] Historical time-series data is used as the training dataset for the LSTM model. The LSTM model training input must be a three-dimensional tensor in the format (number of samples, time step, number of features), consistent with the data format after sliding window transformation. Therefore, the data format after sliding window transformation is converted to historical time-series data, which is then used as the training data for the LSTM model. The training data is input into the LSTM model in batches, and the weights are automatically adjusted through backpropagation. Simultaneously, network jitter and DOM mutation noise are injected to minimize prediction errors. After repeated training of the LSTM model, the final model output is the page load time of the corresponding front-end page, which includes the time of page element appearance and the time of complete page loading.

[0125] Because the front-end automated scripts run every day and generate new data, the LSTM model needs to be trained online. The model can be set to start incremental training every day at midnight, loading the previous day's new data (triggered when >1000 data entries), while freezing the underlying weights of the LSTM model and enabling online fine-tuning to achieve accurate and fast prediction of page load completion time.

[0126] In the embodiments of this application, an online learning mechanism is introduced, enabling the model to adjust according to real-time data, maintain high accuracy, adapt to page changes, and improve the success rate of automated script testing.

[0127] Based on the aforementioned front-end testing method, this application also provides a front-end testing apparatus. The following will combine... Figure 6 The device is described in detail.

[0128] Figure 6 A schematic block diagram of a front-end testing apparatus according to an embodiment of this application is shown.

[0129] like Figure 6 As shown, the front-end testing device 600 of this embodiment includes a data acquisition module 610, a time prediction module 620, and a first testing module 630.

[0130] The data acquisition module 610 is used to acquire the loading index data of the front-end page in real time in response to the execution of the first automated test script; wherein, the first automated test script integrates a pre-trained long short-term memory network model. In one embodiment, the data acquisition module 610 can be used to perform the operation S210 described above, which will not be repeated here.

[0131] The time prediction module 620 is used to predict page load time in real time based on loading metric data using a pre-trained long short-term memory network model. In one embodiment, the time prediction module 620 can be used to perform the operation S220 described above, which will not be repeated here.

[0132] The first testing module 630 is used to dynamically determine a first waiting strategy based on the currently predicted page load time, and to perform front-end testing on the application under test based on the first waiting strategy. In one embodiment, the first testing module 630 can be used to execute the operation S230 described above, which will not be repeated here.

[0133] According to an embodiment of this application, the apparatus 600 further includes: a second testing module, configured to perform front-end testing on the application under test based on a second waiting strategy in the event of an execution anomaly in the pre-trained long short-term memory network model; wherein the second waiting strategy includes one or more of fixed-duration waiting, rule-based waiting, event listening waiting, and element state waiting.

[0134] According to an embodiment of this application, the first test module 630 includes: a first waiting unit, configured to determine a current waiting time based on the currently predicted page load time; and based on the current waiting time, wait for the front-end page to load page elements in order to resume front-end testing of the application under test.

[0135] According to an embodiment of this application, the time prediction module 620 includes: a cleaning unit for cleaning loading indicator data; cleaning includes one or more of missing value processing, outlier processing, and noise processing; a sliding window unit for processing the cleaned loading indicator data using sliding window technology to obtain current time series data; and a time prediction unit for inputting the current time series data into a pre-trained long short-term memory network model and outputting the currently predicted page load time.

[0136] According to an embodiment of this application, a sliding window unit includes: a data extraction unit, used to perform sliding processing on the cleaned loading indicator data corresponding to the front-end page based on a preset sliding window size and sliding interval, so as to extract the current window data corresponding to the preset sliding window; and a data aggregation unit, used to aggregate the current window data corresponding to the preset sliding window to obtain the current time series data.

[0137] According to an embodiment of this application, the apparatus 600 further includes: a model update module, configured to collect test result logs of front-end testing; update the training dataset of the long short-term memory network model according to the test result logs; and train the pre-trained long short-term memory network model based on the updated training dataset.

[0138] According to an embodiment of this application, the device 600 further includes: a model training module for collecting historical indicator data of different pages; cleaning the historical indicator data; cleaning including one or more of missing value processing, outlier processing, and noise processing; processing the cleaned historical indicator data using a sliding window technique to obtain historical time series data; and training a long short-term memory network model based on the historical time series data through online learning to predict the page loading time corresponding to different pages.

[0139] According to an embodiment of this application, the model training module includes: a historical data acquisition unit, configured to monitor the currently loaded page in response to running a second automated test script; mark the current page based on a Uniform Resource Locator (URL); and collect historical indicator data corresponding to the marked current page based on feature indicators to obtain historical indicator data for different pages.

[0140] According to an embodiment of this application, the model training module further includes: a time series data acquisition unit, used to group different pages based on page tags; wherein, one group corresponds to one sliding window; based on the sliding window of the current group, performing sliding processing on the cleaned historical indicator data corresponding to the pages of the current group to extract the current window data corresponding to the sliding window of the current group; and aggregating the current window data corresponding to the sliding window of the current group to obtain historical time series data.

[0141] According to embodiments of this application, any multiple modules among the data acquisition module 610, time prediction module 620, and first test module 630 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the data acquisition module 610, time prediction module 620, and first test module 630 can be at least partially implemented as a hardware circuit, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented by any other reasonable means of integrating or packaging the circuit, or implemented in software, hardware, or firmware, or in any appropriate combination of any of these three implementation methods. Alternatively, at least one of the data acquisition module 610, time prediction module 620, and first test module 630 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0142] Figure 7A block diagram schematically illustrates an electronic device suitable for implementing a front-end testing method according to an embodiment of this application.

[0143] like Figure 7 As shown, an electronic device 900 according to an embodiment of this application includes a processor 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage portion 908 into a random access memory (RAM) 903. The processor 901 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 901 may also include onboard memory for caching purposes. The processor 901 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0144] RAM 903 stores various programs and data required for the operation of electronic device 900. Processor 901, ROM 902, and RAM 903 are interconnected via bus 904. Processor 901 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 902 and / or RAM 903. It should be noted that programs may also be stored in one or more memories other than ROM 902 and RAM 903. Processor 901 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0145] According to embodiments of this application, the electronic device 900 may further include an input / output (I / O) interface 905, which is also connected to a bus 904. The electronic device 900 may also include one or more of the following components connected to the input / output (I / O) interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the input / output (I / O) interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 910 as needed so that computer programs read from it can be installed into the storage section 908 as needed.

[0146] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0147] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 902 and / or RAM 903 and / or one or more memories other than ROM 902 and RAM 903 described above.

[0148] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the front-end testing method provided in the embodiments of this application.

[0149] When the computer program is executed by the processor 901, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0150] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 909, and / or installed from a removable medium 911. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0151] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 909, and / or installed from the removable medium 911. When the computer program is executed by the processor 901, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0152] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0153] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0154] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A front-end testing method, characterized in that, The method includes: In response to the execution of the first automated test script, the loading metric data of the front-end page is obtained in real time; wherein, the first automated test script integrates a pre-trained long short-term memory network model; Based on the loading metric data, the pre-trained Long Short-Term Memory (LSTM) network model is used to predict page load time in real time; and Based on the currently predicted page load time, a first waiting strategy is dynamically determined, and front-end testing of the application under test is performed based on the first waiting strategy.

2. The method according to claim 1, characterized in that, The method further includes: In the event of an anomaly in the pre-trained long short-term memory network model, front-end testing of the application under test is performed based on a second waiting strategy. The second waiting strategy includes one or more of the following: fixed-duration waiting, rule-based waiting, event-listening waiting, and element state waiting.

3. The method according to claim 1, characterized in that, The first waiting strategy includes: Based on the currently predicted page load time, determine the current waiting time; and Based on the current waiting time, wait for the front-end page to load page elements in order to resume front-end testing of the application under test.

4. The method according to claim 1, characterized in that, The step of predicting page load time in real time using the pre-trained Long Short-Term Memory network model based on the loading metric data includes: Clean the loaded index data; the cleaning includes one or more of missing value processing, outlier processing, and noise processing. The cleaned loading index data is processed using the sliding window technique to obtain the current time series data; and The current time series data is input into the pre-trained Long Short-Term Memory network model, and the currently predicted page load time is output.

5. The method according to claim 4, characterized in that, The process of using sliding window technology to process the cleaned loading index data to obtain the current time series data includes: Based on a preset sliding window size and sliding interval, sliding processing is performed on the cleaned loading indicator data corresponding to the front-end page to extract the current window data corresponding to the preset sliding window; and The current window data corresponding to the preset sliding window is aggregated and processed to obtain the current time series data.

6. The method according to claim 1, characterized in that, The method further includes: Collect test result logs from front-end tests; Based on the test result log, update the training dataset of the Long Short-Term Memory network model; and The pre-trained Long Short-Term Memory network model is trained based on the updated training dataset.

7. The method according to claim 1, characterized in that, The training process of the Long Short-Term Memory (LSTM) network model includes: Collect historical metrics data from different pages; Clean the historical indicator data; the cleaning includes one or more of missing value processing, outlier processing, and noise processing. The historical indicator data after cleaning is processed using the sliding window technique to obtain historical time series data; and Based on the historical time series data, the Long Short-Term Memory network model is trained through online learning to predict the page loading time corresponding to different pages.

8. The method according to claim 7, characterized in that, The historical metrics data collected from different pages include: In response to running the second automated test script, monitor the currently loaded page; The current page is marked based on the Uniform Resource Locator; and Based on the feature indicators, historical indicator data corresponding to the current marked page is collected to obtain historical indicator data for the different pages.

9. The method according to claim 7, characterized in that, The process of using sliding window technology to process and clean historical indicator data to obtain historical time series data includes: Based on page tags, the different pages are grouped; each group corresponds to a sliding window. Based on the sliding window of the current group, sliding processing is performed on the cleaned historical indicator data corresponding to the page of the current group to extract the current window data corresponding to the sliding window of the current group; and The historical time series data is obtained by aggregating and processing the current window data corresponding to the sliding window of the current group.

10. A front-end testing device, characterized in that, The device includes: The data acquisition module is used to acquire the loading index data of the front-end page in real time in response to the execution of the first automated test script; wherein, the first automated test script integrates a pre-trained long short-term memory network model. The time prediction module is used to predict page loading time in real time based on the loading metric data using the pre-trained Long Short-Term Memory network model; and The first testing module is used to dynamically determine the first waiting strategy based on the currently predicted page load time, and to perform front-end testing on the application under test based on the first waiting strategy.

11. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 9.

13. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 9.

Images