A web page testing method, an electronic device, and a computer readable medium

Abstract

The application discloses a webpage testing method, an electronic device and a computer readable medium, and relates to the technical field of webpage testing, and comprises the following steps: acquiring a first webpage address and a first test prompt corresponding to a webpage to be tested; inputting the first webpage address and the first test prompt into a target closed-source large model to obtain a first test report output by the target closed-source large model; fine-tuning training an initial webpage testing model by using the first test report, the first webpage address and the first test prompt to obtain a webpage testing model; acquiring a second webpage address and a second test prompt corresponding to a webpage to be released; inputting the second webpage address and the second test prompt into the webpage testing model to obtain a second test report output by the webpage testing model, and outputting the second test report. The application can discover potential problems caused by release in a timely manner, and avoid problems such as online failure or user experience degradation.

Description

Technical Field

[0001] This invention relates to the field of web page testing technology, and more specifically to a web page testing method, electronic device, and computer-readable medium. Background Technology

[0002] With the widespread adoption of internet applications, websites and online products are becoming increasingly complex, leading to higher demands from users for website access experience and product stability. When releasing a new version or undergoing an update, it is necessary to conduct a thorough inspection of the updated website to prevent delays or other malfunctions in front-end and back-end interactions and product functionality.

[0003] The common inspection method involves manually clicking on the website's UI to confirm page feedback. If the page feedback does not meet expectations or there is no feedback at all, an inspection report is generated.

[0004] Traditional manual inspection methods are not only inefficient, but also fail to detect potential problems caused by releases in a timely manner, which can easily lead to online failures or a decline in user experience, increasing the risks and maintenance costs of website operation. Summary of the Invention

[0005] This invention aims to address, to a certain extent, one of the technical problems in related technologies. To this end, this invention provides a webpage testing method, an electronic device, and a computer-readable medium, which have the advantage of being able to promptly detect potential problems caused by webpage releases, thus avoiding online failures or a decline in user experience.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] A webpage testing method, comprising:

[0008] Obtain the URL of the first webpage and the first test prompt corresponding to the webpage to be tested;

[0009] Input the first webpage URL and the first test prompt into the target closed-source large model to obtain the first test report output by the target closed-source large model; wherein, the target closed-source large model is a closed-source large model with an automated inspection function for webpage URLs;

[0010] The initial webpage test model is fine-tuned and trained using the first test report, the first webpage URL, and the first test prompt to obtain the webpage test model.

[0011] Obtain the URL of the second webpage and the second test prompt corresponding to the webpage to be released;

[0012] Input the second webpage URL and the second test prompt into the webpage test model to obtain the second test report output by the webpage test model, and output the second test report.

[0013] Optionally, the step of fine-tuning the initial webpage test model using the first test report, the first webpage URL, and the first test prompt to obtain the webpage test model includes:

[0014] Input the first webpage URL and the first test prompt into the initial webpage test model to obtain the third test report output by the initial webpage test model;

[0015] Using the third test report, the first test report, and the first test prompt, verifiable reward reinforcement learning is performed on the initial webpage test model to obtain the webpage test model.

[0016] Optionally, the step of performing verifiable reward reinforcement learning on the initial webpage test model using the third test report, the first test report, and the first test prompt to obtain the webpage test model includes:

[0017] The third test report is used as the response generated by the model, the first test report is used as the reference answer, and the first test prompt is used as the preset question. These are input into the reward model to obtain the decision signal output by the reward model. The decision signal includes a reward decision, which is either a positive reward decision or a negative reward decision.

[0018] Based on the reward decision, the model parameters of the initial webpage test model are adjusted to obtain a fine-tuned initial webpage test model;

[0019] Input the third webpage URL and the third test prompt into the fine-tuned initial webpage test model and the target closed-source large model, respectively, to obtain the fourth test report output by the fine-tuned initial webpage test model and the fifth test report output by the target closed-source large model;

[0020] Using the fourth test report, the fifth test report, and the third test prompt as a test dataset, the fine-tuned initial webpage test model is tested until the positive reward ratio of the fine-tuned initial webpage test model on the test dataset is greater than a preset ratio, thus obtaining the webpage test model.

[0021] Optionally, the step of adjusting the model parameters of the initial webpage testing model based on the reward decision includes:

[0022] If the reward decision is a positive reward decision, the model parameters of the initial webpage test model are updated using positive gradients.

[0023] If the reward decision is a positive reward decision, the model parameters of the initial webpage test model are updated using a reverse gradient.

[0024] Optionally, the step of inputting the second webpage URL and the second test prompt into the webpage test model to obtain the second test report output by the webpage test model includes:

[0025] The second webpage URL and the second test prompt are input into the webpage test model, so that the webpage test model generates a second test path based on the second test prompt, tests the webpage corresponding to the second webpage URL based on the second test path, obtains a second test result, and outputs the second test report as the second test report, using the second test result and the second test path as the second test report.

[0026] Optionally, after outputting the second test report, the method further includes:

[0027] If the second test result is unsuccessful, a mapping link corresponding to the second webpage URL is determined; wherein, the mapping link includes the correspondence between the page screenshot and the webpage front-end code, the correspondence between the webpage front-end code and the back-end interface, and the correspondence between the back-end interface and the database;

[0028] Based on the mapped link and the preset mapped link, the error information is determined;

[0029] The error message is output so that relevant personnel can adjust the webpage corresponding to the second webpage URL based on the error message.

[0030] Optionally, the step of determining the mapping link corresponding to the second webpage URL when the second test result is unsuccessful includes:

[0031] If the second test result is unsuccessful, a second mapping relationship corresponding to the second test result is determined; wherein, the second mapping relationship includes the correspondence between the front-end code of the target webpage and the target back-end interface corresponding to the webpage to be published, and the correspondence between the target back-end interface and the target database;

[0032] Based on the front-end code of the target webpage, a first mapping relationship is found to determine the target webpage screenshot corresponding to the front-end code of the target webpage; wherein, the first mapping relationship is the correspondence between the page screenshot and the webpage front-end code generated by the target closed-source large model during the process of testing the webpage corresponding to the first webpage URL based on the first test prompt;

[0033] The mapping link is generated based on the target page screenshot and the second mapping relationship.

[0034] Optionally, the target closed-source large model includes the GPT5 model, and the initial webpage test model includes the qwen32B model.

[0035] In a second aspect, the present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the webpage testing method described in any of the preceding claims.

[0036] Thirdly, the present invention also provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the webpage testing method described in any of the preceding claims.

[0037] In this invention, for a webpage to be released, the second webpage URL and second test prompts of the webpage to be released can be periodically input into the webpage testing model. The webpage testing model can automatically verify the front-end and back-end interactions and product functions of the webpage to be released based on the second test prompts. Compared with related technologies that verify the reliability of a webpage to be released through manual inspection when a new version of the website is released or updated, this invention can conduct a comprehensive inspection of the webpage to be released through precise webpage testing before release. It can promptly discover potential problems in the webpage to be released and output potential problems in a timely manner to prompt developers to fix potential problems. This effectively avoids delays caused by internal and external website and product interactions after launch, thereby improving the quality of the webpage and the user experience.

[0038] In addition, the target closed-source large model in this invention is a closed-source large model with the function of automatically inspecting web pages for URLs. It already has relatively mature automated web page inspection capabilities. Using its output first test report as one of the training samples to fine-tune the web page test model can not only accelerate the learning process of the web page test model, but also transfer the knowledge and experience of the target closed-source large model to the web page test model, so that the web page test model has the same automated web page inspection capabilities as the target closed-source large model. This can not only avoid the web page test model from getting stuck in local optima or even looping, but also shorten the training cycle and improve the test results.

[0039] These features and advantages of the present invention will be disclosed in detail in the following specific embodiments and accompanying drawings. The preferred embodiments or means of the present invention will be shown in detail in conjunction with the accompanying drawings, but are not intended to limit the technical solutions of the present invention. In addition, each of these features, elements and components appearing in the following text and drawings is a plurality of, and different symbols or numbers are used for convenience of representation, but all represent parts with the same or similar construction or function. Attached Figure Description

[0040] The present invention will be further described below with reference to the accompanying drawings:

[0041] Figure 1 A flowchart illustrating one embodiment of the webpage testing method provided by the present invention;

[0042] Figure 2 This is a schematic diagram illustrating the testing of a target closed-source large model of the webpage to be tested by inputting the first webpage URL and the first test prompt, as provided by the present invention.

[0043] Figure 3 This is a schematic diagram of a screenshot of a successful login webpage provided by the present invention;

[0044] Figure 4 This is a schematic diagram of a webpage screenshot after interaction with the foreign exchange trading control provided by the present invention;

[0045] Figure 5 The flowchart provided by the present invention illustrates the process of fine-tuning and training an initial webpage test model using a first test report, a first webpage URL, and a first test prompt to obtain a webpage test model.

[0046] Figure 6 This is a schematic diagram of the process of obtaining a webpage test model by performing verifiable reward reinforcement learning on an initial webpage test model, as provided by the present invention.

[0047] Figure 7 A schematic diagram illustrating the technical solution for locating web page elements using XPath technology provided by this invention;

[0048] Figure 8 This is a flowchart illustrating the process of determining webpage error information using a second test report, as provided by the present invention.

[0049] Figure 9 This is a flowchart illustrating the process of determining the mapping link corresponding to the second webpage URL provided by the present invention.

[0050] Figure 10 A block diagram illustrating one embodiment of the electronic device provided by the present invention;

[0051] Figure 11This is a schematic diagram of a computer-readable medium provided by the present invention.

[0052] Explanation of reference numerals in the attached figures:

[0053] 101: Processor; 102: Memory; 103: I / O interface; 104: Bus. Detailed Implementation

[0054] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described are intended to explain the present invention and should not be construed as limiting the invention.

[0055] The terms "an embodiment," "example," or "trademark" used in this specification refer to a particular feature, structure, or characteristic described in connection with the embodiment itself that may be included in at least one embodiment disclosed in this invention. The phrase "in an embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment.

[0056] As a first aspect of the present invention, a webpage testing method is provided, such as... Figure 1 As shown, the method includes:

[0057] In step S110, the URL of the first webpage and the first test prompt corresponding to the webpage to be tested are obtained.

[0058] In step S120, the first webpage URL and the first test prompt are input into the target closed-source large model to obtain the first test report output by the target closed-source large model.

[0059] The target closed-source large model is a closed-source large model with the function of automatically inspecting web pages based on their URLs.

[0060] In step S130, the initial webpage test model is fine-tuned and trained using the first test report, the first webpage URL, and the first test prompt to obtain the webpage test model.

[0061] In this embodiment, the target closed-source large model includes the GPT5 model, and the initial webpage test model includes the qwen32B model. The first webpage URL and the first test prompt corresponding to the webpage to be tested can be simulation data in the test environment.

[0062] For the GPT5 model, the Chrome browser's functions such as closing webpages, forward, back, and clicking can be encapsulated as function calls within the Model Context Protocol (MCP). Unlike HTTP or TCP / IP, which are widely, publicly available, and enforced internet standards, the MCP is a set of specifications, conventions, or data formats for the structured and standardized organization and transmission of context information when interacting with Large Language Models (LLMs). Before inputting the first webpage URL and the first test prompt into the GPT5 model, the model can learn the various functions within the MCP, enabling it to automatically inspect webpages containing URLs.

[0063] The qwen32B model is the language model in the Qwen series, which includes both language and multimodal models. It is pre-trained on large-scale multilingual and multimodal data and then fine-tuned using high-quality data to better reflect human preferences. This series of models possesses various capabilities, such as natural language understanding, text generation, visual understanding, audio understanding, tool usage, role-playing, and interaction as an AI agent.

[0064] Specifically, users can upload the first webpage URL and the first test prompt corresponding to the webpage to be tested to the electronic device through interaction with the device's human-computer interface. Alternatively, the first webpage URL and the first test prompt corresponding to the webpage to be tested can be stored locally on the electronic device, and the electronic device can directly read the first webpage URL and the first test prompt corresponding to the webpage to be tested from the local storage when executing step S110.

[0065] After obtaining the URL of the first webpage and the first test prompt corresponding to the webpage to be tested, the electronic device can input the URL and the first test prompt into the target closed-source large model. Upon receiving the URL and the first test prompt, the target closed-source large model first performs semantic analysis on the first test prompt to extract key operations and expected results. For example, if the first test prompt is "Test the website login function to ensure users can successfully register, log in, and access their personal accounts," the semantic analysis reveals the key operation steps as follows: access the login page → enter a valid username and password → click the login button → verify successful login and redirection to the personal page. The expected result is successful login and redirection to the personal page. After obtaining the key operation steps, a test path can be generated based on the arrangement of these steps to simulate user interaction with the website. (See reference...) Figure 2 As shown, Figure 2This diagram illustrates how the target closed-source large-scale model tests the webpage by inputting the first webpage URL and the first test prompt. After learning the functions of Chrome MCP, the target closed-source large-scale model has the ability to automatically test webpages. The first test prompt input into the target closed-source large-scale model can be "You are a professional AI test inspection expert. Use the Chrome MCP tool to autonomously operate the browser and complete the automated inspection of the entire process or a single functional page." For example, "You are a professional AI test inspection expert. Use the Chrome MCP tool to autonomously operate the browser and complete the automated inspection of the login function of the website 'https: / / business.XXXXXXXXx.com / seal / personal / main'." Based on this, the generated first test path is: access the login page → enter a valid username and password → click the login button → verify whether the login is successful and whether it is redirected to the personal page. The expected result is successful login and redirection to the personal page. After obtaining the initial test path, you can use the `Chrome_navigate` function in Chrome MCP to navigate to the test page corresponding to the initial webpage URL, i.e., open the webpage at `https: / / business.XXXXXXXXx.com / seal / personal / main`, and determine if you are currently logged in. If you are already logged in, do nothing further. If you are not logged in, use the `Chrome_get_interactive_elements` function in Chrome MCP to determine the login control. After determining the login control, you can use the `Chrome_fill_or_select` function in Chrome MCP to fill in the username and password, and then use the `Chrome_click_element` function in Chrome MCP to click the login control, i.e., enter the username and password and log in to the system. After successfully logging in, you can use the `Chrome_screenshot` function in Chrome MCP to capture the webpage after logging in. Correspondingly, if the first test prompt includes more critical operations, such as "Test the website login function, ensure that users can successfully register, log in and access their personal accounts, and verify whether the product can be successfully added to the user's favorites after the user clicks the 'favorite' button on the product details page," then you can perform the corresponding operations according to the input first test prompt. If there is no response, close the test webpage using the Chrome_close_tabs function in Chrome MCP. That is, perform the relevant operations according to the input instructions. If you still cannot continue the operation after multiple attempts, please end the task and close the page.

[0066] It is worth mentioning that the target closed-source large model in this embodiment is a multimodal model, which can handle both text and non-text data. Therefore, as an optional implementation, during the testing of the webpage at the first webpage URL based on the first test prompt, after the target closed-source large model completes an interaction with a certain interactive control, it can use the Chrome_screenshot function in Chrome MCP to capture the webpage after interacting with the interactive control, obtaining a webpage screenshot. For example, after interacting with the login control, the Chrome_screenshot function in Chrome MCP can be used to capture the webpage after interacting with the login control, such as the login success page, as shown in the reference. Figure 3 As shown, Figure 3 Take a screenshot of the webpage showing the successful login. Alternatively, after clicking the forex trading control, use the Chrome_screenshot function in Chrome MCP to capture the webpage after interacting with the forex trading control, such as... Figure 4 As shown, Figure 4 This is a screenshot of the webpage after interacting with the forex trading controls. After obtaining the screenshot, a first mapping relationship between the webpage screenshot and the webpage front-end code can be generated based on the correspondence between interactive controls and the webpage front-end code.

[0067] After testing the webpage to be tested according to the first test path, the target closed-source large model compares the actual test results of the webpage to be tested based on the first test path with the corresponding expected test results to obtain the first test result. That is, the first test result is whether the actual test result is consistent with or inconsistent with the expected test result. The first test result and the first test path are used as the first test report and the first test report is output.

[0068] To avoid the risk of data leakage, in the test environment, the first webpage URL and the first test prompt can be input into the target closed-source large model, so that the target closed-source large model can plan the first test path according to the first test prompt, and test the webpage to be tested corresponding to the first webpage URL based on the first test path.

[0069] After obtaining the first test report, the first test report, the first webpage URL, and the first test prompt can be used as training samples to fine-tune the initial webpage test model, thus obtaining the webpage test model. During the fine-tuning of the initial webpage test model, to ensure that the obtained webpage test model possesses the same webpage inspection function as the target closed-source large model, further, as an optional implementation method, refer to... Figure 5 As shown, Figure 5 To fine-tune the initial webpage testing model using the first test report, the first webpage URL, and the first test prompts, a flowchart illustrating the process of obtaining the webpage testing model is provided. Step S130 specifically includes:

[0070] In step S510, the first webpage URL and the first test prompt are input into the initial webpage test model to obtain the third test report output by the initial webpage test model.

[0071] In step S520, the initial webpage test model is subjected to verifiable reward reinforcement learning using the third test report, the first test report, and the first test prompt to obtain the webpage test model.

[0072] Specifically, the initial webpage testing model can be fine-tuned using verifiable reinforcement learning. This involves inputting the first webpage URL and the first test prompt into the initial model. The initial model then generates a third test path through operations similar to those used in the target closed-source large model. Based on this third test path, the model tests the webpage corresponding to the first webpage URL. In other words, the initial model performs semantic analysis on the first test prompt to extract key operations and expected results. After obtaining the key operation steps, it generates the third test path based on their arrangement. Once the third test path is obtained, the webpage corresponding to the first webpage URL is tested, yielding actual test results. These results are then compared with the corresponding expected test results to obtain the third test result. The third test result is either consistent with the expected test result or inconsistent with it. The third test result and the third test path together form the third test report.

[0073] After obtaining the third test report, the initial webpage test model can be subjected to verifiable reward reinforcement learning using the third test report, the first test report, and the first test prompt. Verifiable reward reinforcement learning (RLVR) is a training paradigm based on a reference standard. Its core idea is to directly evaluate the model output using a verification function, unlike traditional human feedback reinforcement learning (RLHF) which relies on a separate reward model trained according to human preferences. During RLVR training, the preset question q, the model's output r, and the reference answer a are used as the model's generated response, respectively. The reward model outputs a binary decision signal y∈{YES,NO}, used to evaluate whether the model's generated response r is consistent with the reference answer a under the conditions of the preset question q. A YES decision corresponds to a positive reward decision (R=1), and a NO decision corresponds to a negative reward decision (R=0). Therefore, further, referring to... Figure 6 As shown, Figure 6 A flowchart illustrating the process of performing verifiable reward reinforcement learning on the initial webpage test model to obtain the webpage test model is provided. Step S220 specifically includes:

[0074] In step S610, the third test report is used as the response generated by the model, the first test report is used as the reference answer, and the first test prompt is used as the preset question. These are input into the reward model to obtain the decision signal output by the reward model.

[0075] The judgment signal includes a reward decision, which can be a positive reward decision or a negative reward decision.

[0076] In step S620, based on the reward decision, the model parameters of the initial webpage test model are adjusted to obtain a fine-tuned initial webpage test model.

[0077] In step S630, the third webpage URL and the third test prompt are respectively input into the fine-tuned initial webpage test model and the target closed-source large model to obtain the fourth test report output by the fine-tuned initial webpage test model and the fifth test report output by the target closed-source large model.

[0078] In step S640, the fourth test report, the fifth test report, and the third test prompt are used as test datasets. The fine-tuned initial webpage test model is tested using the test datasets until the positive reward ratio of the fine-tuned initial webpage test model on the test datasets is greater than a preset ratio, thus obtaining the webpage test model.

[0079] Specifically, after obtaining the third test report, a fine-tuning training sample set can be constructed using the third test report, the first test report, and the first test prompt. This fine-tuning training sample set includes multiple fine-tuning training samples. A fine-tuning training sample can be defined as a single third test report and a single first test prompt corresponding to the same first webpage URL and first test prompt. In other words, a fine-tuning training sample includes one first test report, one first test prompt, and one third test report.

[0080] After obtaining the fine-tuned training sample set, the third test report from each fine-tuned training sample can be used as the model response generated by the initial webpage test model, i.e., the model-generated response r. The first test report is used as the reference answer a, and the first test prompt is used as the preset question q. The third test report, the first test report, and the first test prompt are then input into the reward model. Since the evaluation logic of the reward model is based on the single-sample comparison principle, the fine-tuned training samples are input into the reward model one by one. After receiving each fine-tuned training sample, the reward model can use a verification function to determine whether the first test report and the third test report are consistent under the first test prompt condition. If the first test report and the third test report are consistent, the reward decision in the decision signal output by the reward model is a positive reward decision; if the first test report and the third test report are inconsistent, the reward decision in the decision signal output by the reward model is a negative reward decision.

[0081] The consistency between the first test report and the third test report includes consistency between the first test results and the third test results, as well as consistency between the first test path and the third test path.

[0082] When adjusting the model parameters of the initial webpage test model based on the reward decision, stochastic gradient descent (SGD) is used. Specifically, for each fine-tuning training sample output by the reward model, the reward decision corresponding to each fine-tuning training sample is converted into a loss value using binary discrete loss or continuous quantization loss. The gradient of this loss value with respect to the model parameters in the initial webpage test model is then calculated using the backpropagation algorithm. Finally, the model parameters of the initial webpage test model are updated using the SGD calculation formula, the gradient of the model parameters, and the learning rate. In other words, if the reward decision is positive, the model parameters of the initial webpage test model are updated using a forward gradient; otherwise, they are updated using a backward gradient.

[0083] To verify the reliability of the fine-tuned initial webpage test model and ensure it possesses the knowledge and experience of the target closed-source large model, along with strong automated webpage inspection capabilities, a test dataset can be used to test its capabilities. Specifically, the third webpage URL and third test prompts are input into both the fine-tuned initial webpage test model and the target closed-source large model, respectively. The fine-tuned initial webpage test model generates a fourth test path through operations similar to those used with the target closed-source large model. Based on this fourth test path, the webpage at the third webpage URL is tested, resulting in a fourth test report. This report includes the fourth test results and the fourth test path. The target closed-source large model generates a fifth test path through the same operations, and based on this fifth test path, the third webpage URL is tested, resulting in a fifth test report. After obtaining the fourth and fifth test reports, a test dataset can be constructed using these reports and the third test prompt. This dataset is then input into the reward model to obtain the reward decisions output by the model. This process continues until the proportion of positive reward decisions in the test dataset for the fine-tuned initial webpage test model exceeds a preset proportion, at which point the webpage test model is obtained. The third webpage URL and the third test prompt are real data from a production environment.

[0084] In this embodiment, the initial webpage testing model often suffers from problems such as "incomplete testing, inaccurate steps, and logical flaws." The target closed-source large model, as an advanced model with automated inspection capabilities, generates a first test report that is equivalent to an expert-level standard answer, containing a complete test scenario and precise operational steps. Through RLVR, the third test report generated by the initial webpage testing model can be directly compared with the first test report of the target closed-source large model, clearly identifying the current deficiencies of the initial webpage testing model and quickly adjusting parameters under clear reward signals. This expert-benchmarked targeted learning is far more efficient than the initial webpage testing model exploring from scratch or random trial and error. It not only shortens the training time of the webpage testing model but also allows the initial webpage model to quickly learn the advantages of the target closed-source large model, enabling the resulting webpage testing model to possess webpage testing capabilities comparable to the target closed-source large model.

[0085] In addition, by fine-tuning the initial webpage testing model using RLVR technology, a new webpage testing model is obtained. This model, when testing the webpage to be released, possesses the same ability to recognize interactive controls as the target closed-source large model, as well as the ability to identify the corresponding webpage front-end code. This is superior to related technologies that rely on XPath technology for webpage element localization, i.e., using XPath to identify corresponding interactive controls from the webpage. Figure 7 As shown, Figure 7This is a schematic diagram of a technical solution that relies on XPath technology to locate web page elements. The web page testing model in this embodiment has the ability to automatically identify element features, that is, to identify interactive controls and the corresponding web page front-end code from the web page to be released. It does not require manual intervention to locate a web page element, thereby reducing reliance on manual labor and improving testing efficiency.

[0086] Furthermore, during the fine-tuning training of the initial webpage test model, firstly, in the test environment, simulation data corresponding to the first webpage URL and the first test prompt are used to construct fine-tuning training samples. This not only avoids affecting real data in the production environment during the development and adjustment phases, preventing the leakage of real data, but also allows the model to be exposed to various data scenarios, as simulation data typically covers more boundary and anomaly situations. This helps improve the model's generalization ability, making it more adaptable to real data. Secondly, when testing the fine-tuned initial webpage test model, a test dataset is constructed using real data from the third webpage URL and the third test prompt in the production environment. Since the data in the production environment is closest to the actual user needs, using real data to construct test samples can more accurately reflect the model's performance in real-world scenarios, ensuring that it can effectively process customer data and make accurate predictions or decisions. This ensures that the subsequent webpage test model can run stably in the real environment.

[0087] In step S140, the URL of the second webpage and the second test prompt corresponding to the webpage to be published are obtained.

[0088] In step S150, the second webpage URL and the second test prompt are input into the webpage test model to obtain the second test report output by the webpage test model, and the second test report is output.

[0089] After obtaining the webpage test model, the user can input the second webpage URL and the second test prompt into the electronic device through the human-computer interaction interface. Alternatively, the second webpage URL and the second test prompt can be stored locally on the electronic device, and the electronic device can directly retrieve the second webpage URL and the second test prompt from the local storage during step S140.

[0090] After obtaining the second webpage URL and the second test hint for the webpage to be published, these can be input into the webpage testing model. Upon receiving the second webpage URL and the second test hint, the webpage testing model can generate a second test path through operations similar to those described for the target closed-source large model. Based on this second test path, the webpage to be published corresponding to the second webpage URL is tested. Specifically, semantic analysis is performed on the second test hint to extract key operations and expected results, and a second test path is generated based on the arrangement of the key operation steps. After obtaining the second test path, the webpage corresponding to the second webpage URL is tested, yielding actual test results. These results are then compared with the corresponding expected test results to obtain the second test result. The second test result is either consistent with the expected test result or inconsistent with it. Finally, the second test result and the second test path are used as a second test report, which is then output. That is, step S150 is adapted to become: step S151: input the second webpage URL and the second test prompt into the webpage test model, so that the webpage test model generates a second test path based on the second test prompt, tests the webpage corresponding to the second webpage URL based on the second test path, obtains a second test result, and outputs the second test report as the second test report using the second test result and the second test path.

[0091] After receiving the second test report, the results of the second test can be used to determine whether the webpage to be released has any faults, and if faults are found, they can be addressed promptly. Furthermore, as an optional implementation method, refer to... Figure 8 As shown, Figure 8 To illustrate the flowchart for determining webpage error information using the second test report, after step S150, the following is included:

[0092] In step S810, if the second test result is unsuccessful, a mapping link corresponding to the second webpage URL is determined.

[0093] The mapping link includes the correspondence between page screenshots and webpage front-end code, the correspondence between webpage front-end code and back-end interfaces, and the correspondence between back-end interfaces and databases.

[0094] It should be noted that the webpage testing model in this embodiment is a language model, which can only process text-based data and cannot process non-text data such as images. For example, the webpage testing model can analyze the HTML code of the login button on the webpage to be released, but cannot understand the screenshot of the login interface. In this case, when using the webpage testing model to test the webpage to be released based on the second test prompt, it can only generate mapping relationships between text-based data, such as the correspondence between the webpage front-end code → back-end interface → database, but cannot generate mapping relationships between text-based and non-text-based data, such as the mapping relationship between page screenshots and webpage front-end code.

[0095] In the actual operation of a webpage awaiting release, users or testers first perceive the visual interface. For example, a login button might not respond, or the order amount might be displayed incorrectly. The root cause of such problems often lies in the underlying technology, such as errors in front-end code logic, exceptions returned by back-end interfaces, or incorrect database table data. Therefore, if the mapping chain only includes webpage front-end code → back-end interface → database table, it lacks a direct connection between the user's actual observations and the technical implementation. This lack of a direct connection leads to a disconnect between the description of the phenomenon and the technical location, as well as a lack of clarity regarding the state of the interaction process. Specifically, regarding the disconnect between the description of the phenomenon and the technical location, when feedback indicates a problem with the webpage interface, a textual description may be vague, making it difficult for technical personnel to quickly locate the corresponding front-end code. For example, a textual description might state that a blue button is unclickable, but it's unclear which page and location the blue button is on. Regarding the lack of clarity regarding the state of the interaction process, since the front-end and back-end interactions of a webpage awaiting release are dynamic (e.g., user input → front-end validation → back-end processing → page feedback), it's difficult to fully reconstruct the webpage interface state at a specific moment using only code and interface logs. For example, when a user enters an incorrect password, does the interface display the expected error message?

[0096] Therefore, to avoid a disconnect between phenomenon description and technical positioning, and to prevent the absence of state information in the interaction process, so as to quickly locate the fault when a webpage to be published malfunctions, further, as an optional implementation method, refer to... Figure 9 As shown, Figure 9 To determine the flowchart of the mapping link corresponding to the second webpage URL, step S410 specifically includes:

[0097] In step S910, if the second test result is a failure, a second mapping relationship corresponding to the second test result is determined.

[0098] The second mapping relationship includes the correspondence between the front-end code of the target webpage and the target back-end interface corresponding to the webpage to be published, as well as the correspondence between the target back-end interface and the target database.

[0099] In step S920, based on the front-end code of the target webpage, a first mapping relationship is found to determine the screenshot of the target webpage corresponding to the front-end code of the target webpage.

[0100] Wherein, the first mapping relationship is the correspondence between the page screenshot generated and the webpage front-end code generated by the target closed-source large model during the process of testing the webpage corresponding to the first webpage URL based on the first test prompt.

[0101] In step S930, the mapping link is generated based on the target page screenshot and the second mapping relationship.

[0102] Specifically, if the second test fails—that is, after testing the webpage corresponding to the second webpage URL based on the second test path, the actual test result is inconsistent with the expected test result—the second mapping relationship corresponding to the second test result can be quickly determined based on the test records. For example, let's take the failure of the payment function test on the webpage to be released as an example. Suppose the payment function test fails, i.e., after clicking the "Confirm Payment" button, the page does not respond and no payment record is generated. In this case, the test records clearly show that the operation was clicking the "Confirm Payment" button on the payment page, and the error symptom is that the "Confirm Payment" button has no effect after being clicked, and no payment record is generated. Based on the operation of the "Confirm Payment" button, the front-end code of the webpage implementing this button function can be found, i.e., the front-end code of the target webpage. After determining the front-end code of the target webpage, the specific back-end interface corresponding to this front-end function can be confirmed through the interaction records between the front-end and back-end, such as interface call logs, forming a correspondence between the target webpage front-end code and the target back-end interface. After obtaining the target back-end interface, the specific data table corresponding to the target back-end interface can be determined through database access logs, forming a correspondence between the target back-end interface and the target database table. Finally, these are summarized to form the second mapping relationship.

[0103] After obtaining the second mapping relationship, features that identify the corresponding interface can be extracted from the front-end code of the target webpage. For example, the interface corresponding to the function name in the front-end code can be determined. After extracting the features of the front-end code, the first mapping relationship can be queried using the features corresponding to the front-end code to determine the screenshot of the target webpage corresponding to the front-end code. For example, if the function name of the front-end code is a "confirm payment" button, the screenshot of the target webpage corresponding to the front-end code can be determined to be a screenshot of the payment confirmation interface.

[0104] Finally, based on the target webpage screenshot and the second mapping relationship, a mapping link is generated from the target webpage screenshot to the target webpage front-end code, the target back-end interface, and the target database table, forming a complete and traceable link from vision to technology.

[0105] In this embodiment, the webpage functionality involves a linked response: user interface → front-end processing → back-end response → database storage. Test failures can occur at any of these stages. If only the second mapping relationship exists, technicians only know the back-end interface corresponding to the target webpage's front-end code, but not the corresponding webpage interface. This prevents the user's perspective from being linked to the technical chain, resulting in a loss of state in the interaction process. If only the first mapping relationship exists, technicians only know the correspondence between the webpage interface and the front-end code, but not which interface the front-end code will subsequently call or which database it will operate on. This makes it impossible to trace the underlying cause, leading to a disconnect between the phenomenon description and the technical identification. Therefore, this embodiment generates a complete mapping chain through the first and second mapping relationships. This strongly correlates the front-end code-back-end interface-database table link, which originally only existed in the technical field, with the user's actual perceived interface experience. When a webpage malfunctions, the mapping chain allows for rapid problem location, leading to more accurate problem identification, lower communication costs, and more complete automation processes. This ensures the consistency and reliability of the webpage from both technical and user perspectives.

[0106] In addition, when generating the mapping chain, for webpage screenshots in the mapping chain, the target closed-source large model is a multimodal model. Therefore, the target closed-source large model can be used to handle cross-modal mapping between webpage screenshots and webpage front-end code, thus avoiding the limitation of the webpage test model in handling images. Based on this, the webpage test model, leveraging its familiarity with internal business, generates a business-oriented mapping of webpage front-end code, back-end interface, and database tables. Through the collaboration of the two models, the full-scenario correlation requirements from vision to data are covered, providing a technical foundation for subsequent problem localization.

[0107] In step S820, error information is determined based on the mapped link and the preset mapped link.

[0108] In step S830, the error information is output so that relevant personnel can adjust the webpage corresponding to the second webpage URL based on the error information.

[0109] After identifying the mapping link, the standard link (i.e., the preset mapping link) when the webpage to be released functions normally can be retrieved. Differences between the mapped link and the preset mapping link can be determined by comparing each node and its relationships item by item, thus identifying error messages. For example, by comparing each node and its relationships item by item, the difference might be determined to be that "the front-end code of the 'Confirm Payment' button in the mapping link did not correctly call the 'Create Payment Order' interface, causing subsequent processes to fail." After obtaining the error message, it can be output so that relevant personnel can adjust the webpage corresponding to the second webpage URL based on the error message until the test passes. For example, based on the error message "the front-end code of the 'Confirm Payment' button in the mapping link did not correctly call the 'Create Payment Order' interface, causing subsequent processes to fail," relevant personnel can correct the interface call logic of the front-end code.

[0110] In this embodiment, compared to the vague result of a traditional webpage test failing and indicating that a certain function is unusable, this embodiment, when the second test fails, can precisely pinpoint the problem's location within the link by comparing the mapped link with a preset mapped link. For example, comparing the mapped link with the preset mapped link might determine that the problem is that the front-end code of the "confirm payment" button is not correctly calling the correct back-end interface. This transforms the abstract result of a webpage test failing into a specific, locatable, understandable, and fixable problem, thus solving the pain points of traditional webpage testing, such as difficulty in locating the issue, chaotic communication, and slow repair. It turns the problem from a black box into a transparent bottleneck.

[0111] In this embodiment, for a webpage to be released, the second webpage URL and second test prompt can be periodically input into the webpage testing model. The webpage testing model can automatically verify the front-end and back-end interactions and product functions of the webpage to be released based on the second test prompt. Compared with related technologies that verify the reliability of a webpage to be released through manual inspection when a new version of the website is released or updated, this invention can conduct a comprehensive inspection of the webpage to be released through precise webpage testing before release. It can promptly discover potential problems in the webpage to be released and output potential problems in a timely manner to prompt developers to fix potential problems. This effectively avoids delays caused by internal and external website and product interactions after launch, thereby improving the quality of the webpage and the user experience.

[0112] In addition, the target closed-source large model in this invention is a closed-source large model with the function of automatically inspecting web pages for URLs. It already has relatively mature automated web page inspection capabilities. Using its output first test report as one of the training samples to fine-tune the web page test model can not only accelerate the learning process of the web page test model, but also transfer the knowledge and experience of the target closed-source large model to the web page test model, so that the web page test model has the same automated web page inspection capabilities as the target closed-source large model. This can not only avoid the web page test model from getting stuck in local optima or even looping, but also shorten the training cycle and improve the test results.

[0113] It's worth noting that for frequently used and crucial interactive controls in web pages awaiting release or testing, such as login and navigation controls, atomic encapsulation can be performed. By decomposing these controls into independent and stable modules, their efficient and stable operation can be guaranteed. Furthermore, subsequent updates to some interactive controls can be controlled and updated via natural language, eliminating the need for complex programming or technical intervention. For example, "update the left navigation bar" can be achieved through natural language commands, significantly improving development efficiency and user experience stability.

[0114] Meanwhile, this embodiment also provides an electronic device, referring to Figure 10 As shown, Figure 10 This is a block diagram of an electronic device, which includes:

[0115] One or more processors 101;

[0116] The memory 102 stores one or more computer programs that, when executed by the one or more processors 101, cause the one or more processors 101 to implement the webpage testing method according to the first aspect of the invention.

[0117] The electronic device may also include one or more I / O interfaces 103 connected between the processor 101 and the memory 102, configured to enable information interaction between the processor 101 and the memory 102.

[0118] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the first memory is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface 103 (read-write interface) is connected between the processor 101 and the memory 102, enabling information exchange between the processor 101 and the memory 102, including but not limited to a data bus 104 (Bus).

[0119] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0120] As a third aspect of the present invention, this embodiment also provides a computer-readable medium, referring to... Figure 11 As shown, Figure 11 This is a schematic diagram of a computer-readable medium on which a computer program is stored, which, when executed by a processor, implements the webpage testing method provided in the first aspect of this disclosure.

[0121] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. Accordingly, the computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can implement the methods of any of the above embodiments. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0122] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Those skilled in the art should understand that the present invention includes, but is not limited to, the contents described in the accompanying drawings and the specific embodiments above. Any modifications that do not depart from the functional and structural principles of the present invention will be included within the scope of the claims.

Claims

1. A method of testing a web page, characterized by, The method comprises the following steps: acquiring a first webpage address and a first test prompt corresponding to a webpage to be tested; inputting the first webpage address and the first test prompt into a target closed-source large model to obtain a first test report output by the target closed-source large model; wherein the target closed-source large model is a closed-source large model having an automatic inspection function for a webpage of a webpage address; fine-tuning training an initial webpage test model by using the first test report, the first webpage address and the first test prompt to obtain a webpage test model; acquiring a second webpage address and a second test prompt corresponding to a webpage to be issued; inputting the second webpage address and the second test prompt into the webpage test model to obtain a second test report output by the webpage test model, and outputting the second test report; the step of inputting the second webpage address and the second test prompt into the webpage test model to obtain a second test report output by the webpage test model comprises: inputting the second webpage address and the second test prompt into the webpage test model to enable the webpage test model to generate a second test path based on the second test prompt, test a webpage corresponding to the second webpage address based on the second test path, obtain a second test result, and output the second test result and the second test path as the second test report. after outputting the second test report, the method further comprises: in the case that the second test result is not passed, determining a mapping link corresponding to the second webpage address; wherein the mapping link comprises a corresponding relationship between a webpage screenshot and a webpage front-end code, a corresponding relationship between a webpage front-end code and a backend interface, and a corresponding relationship between a backend interface and a database; determining error information based on the mapping link and a preset mapping link; outputting the error information to enable relevant personnel to adjust the webpage corresponding to the second webpage address based on the error information.

2. The web page testing method of claim 1, wherein, the step of fine-tuning training an initial webpage test model by using the first test report, the first webpage address and the first test prompt to obtain a webpage test model comprises: inputting the first webpage address and the first test prompt into the initial webpage test model to obtain a third test report output by the initial webpage test model; verifiable reward reinforcement learning is performed on the initial webpage test model by using the third test report, the first test report and the first test prompt to obtain the webpage test model.

3. The web page testing method of claim 2, wherein, the step of performing verifiable reward reinforcement learning on the initial webpage test model by using the third test report, the first test report and the first test prompt to obtain the webpage test model comprises: inputting the third test report as a response generated by a model, the first test report as a reference answer, and the first test prompt as a preset question into a reward model to obtain a decision signal output by the reward model; wherein the decision signal comprises a reward decision, and the reward decision is a positive reward decision or a negative reward decision. adjust model parameters of the initial webpage test model based on the reward decision, to obtain a fine-tuned initial webpage test model; input a third webpage address and a third test prompt into the fine-tuned initial webpage test model and the target closed-source large model respectively, to obtain a fourth test report output by the fine-tuned initial webpage test model and a fifth test report output by the target closed-source large model; use the fourth test report, the fifth test report, and the third test prompt as a test data set, and test the fine-tuned initial webpage test model using the test data set until a proportion of positive rewards of the fine-tuned initial webpage test model on the test data set is greater than a preset proportion, to obtain the webpage test model.

4. The web page testing method of claim 3, wherein, The step of adjusting the model parameters of the initial webpage test model based on the reward decision comprises: in a case where the reward decision is a positive reward decision, performing positive gradient update on the model parameters of the initial webpage test model; in a case where the reward decision is a positive reward decision, performing negative gradient update on the model parameters of the initial webpage test model.

5. The web page testing method of claim 1, wherein, The step of determining the mapping link corresponding to the second webpage address in a case where the second test result is a failure comprises: in a case where the second test result is a failure, determining a second mapping relationship corresponding to the second test result; wherein the second mapping relationship comprises a corresponding relationship between a target webpage front-end code corresponding to a webpage to be issued and a target back-end interface, and a corresponding relationship between the target back-end interface and a target database; based on the target webpage front-end code, finding a first mapping relationship to determine a target webpage screenshot corresponding to the target webpage front-end code; wherein the first mapping relationship is a corresponding relationship between a webpage screenshot and a webpage front-end code generated by the target closed-source large model in a process of testing a webpage corresponding to the first webpage address based on the first test prompt; based on the target webpage screenshot and the second mapping relationship, generating the mapping link.

6. The Web page testing method of claim 1, wherein, The target closed-source large model comprises a GPT5 model, and the initial webpage test model comprises a qwen32B model.

7. An electronic device, comprising: comprise: one or more processors; a memory having one or more computer programs stored thereon, wherein when the one or more computer programs are executed by the one or more processors, the one or more processors implement the webpage test method according to any one of claims 1 to 6.

8. A computer readable medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the webpage test method of any one of claims 1 to 6.

Images