Dynamic configuration page empty hole detection method, platform, device and product

Abstract

This application discloses a method, platform, device, and product for detecting voids in dynamic configuration pages. The method includes: executing a planning agent to generate an operation instruction set and sending it to the target inspection device; collecting screenshots, document object model tree structure, interface return data, and end-to-end operation logs of the dynamic configuration page during the inspection process; generating void detection rules for the dynamic configuration page adapted to the target inspection device using a detection rule generation agent; performing image, log, and data anomaly detection on the dynamic configuration page based on the collected inspection data and according to the void detection rules, obtaining multi-dimensional void detection results; identifying voids in the dynamic configuration page and performing root cause localization based on the multi-dimensional void detection results, and generating a void inspection report. This application can improve the efficiency and accuracy of void detection in dynamic configuration pages.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and page detection technology, and in particular to a method, platform, electronic device, computer-readable storage medium, and computer program product for detecting voids in dynamically configured pages. Background Technology

[0002] In the operation of internet products, such as recruitment platforms, page content needs to be configured in real time according to different scenarios such as peak recruitment seasons, industry-specific events, and regional recruitment. This involves the dynamic adjustment of page elements such as job recommendation modules, salary display areas, industry category floors, advertising materials, and / or multilingual copywriting. The flexibility and real-time requirements of page configuration are high. As business complexity increases, anomalies can easily occur in the configuration distribution, API calls, data parsing, resource loading, and page rendering stages of dynamically configured pages. This can lead to problems such as blank areas with no content displayed, missing modules, unfilled placeholders, and failed image loading. These abnormal display areas are collectively referred to as "empty pits." Empty pits not only damage the overall visual effect of the page but also directly prevent key information from reaching users, reducing the user's browsing experience and willingness to use the page.

[0003] Current methods for detecting pitfalls in dynamic configuration pages have significant limitations and fail to meet actual operational needs. Existing detection methods generally suffer from incomplete coverage and poor adaptability. They either rely on manual inspection, which is limited by labor costs and efficiency, leading to missed or false positives, and is difficult to handle the multi-terminal inspection requirements of massive configuration scenarios. Or they adopt fixed automated detection modes, which can only detect anomalies in a single link or type, failing to comprehensively verify page rendering effects, underlying data interaction, and the overall operational status, making it difficult to fully capture pitfall anomalies in various complex scenarios. Furthermore, different terminal devices differ in rendering mechanisms, display parameters, and compatibility, making it difficult for existing detection solutions to cover pitfall anomaly scenarios on multiple terminal devices, further increasing the probability of missed or false positives.

[0004] In addition, existing detection solutions can usually only achieve preliminary identification of pit void anomalies. When pit void problems occur, existing solutions cannot quickly identify the root cause of the anomaly, which requires maintenance personnel to spend a lot of time troubleshooting the problem, prolonging the anomaly handling cycle and thus hindering the rapid repair of pit void problems. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method, platform, electronic device, computer-readable storage medium, and computer program product for detecting voids in dynamically configured pages, to solve at least one technical problem.

[0006] Firstly, embodiments of this application provide a method for detecting voids in a dynamic configuration page, comprising: generating a set of executable operation instructions for the device based on the inspection object and inspection operation steps, and sending them to the target inspection device by executing a planning agent; and collecting screenshots, document object model tree structures, interface return data, and end-to-end operation logs of the dynamic configuration page during the inspection process; generating void detection rules for the dynamic configuration page adapted to the target inspection device by a detection rule generation agent, wherein the void detection rules include image-based void detection rules, log-based void detection rules, and data-based void detection rules; and based on screenshots and document object model tree structures... The system performs image anomaly detection on the dynamic configuration page according to image-based anomaly detection rules, and obtains image anomaly detection results. Based on the full-link operation logs, and according to log-based anomaly detection rules, the system performs log-based anomaly detection on the dynamic configuration page, and obtains log-based anomaly detection results. Based on the interface return data, and according to data-based anomaly detection rules, the system performs data-based anomaly detection on the dynamic configuration page, and obtains data-based anomaly detection results. Based on the image-based anomaly detection results, log-based anomaly detection results, and data-based anomaly detection results, the system identifies anomalies in the dynamic configuration page, performs root cause localization, and generates an anomaly inspection report.

[0007] Secondly, embodiments of this application provide a pitfall detection platform for a dynamic configuration page, comprising: an execution planning agent, used to generate a set of executable operation instructions for the device based on the inspection object and inspection operation steps, and send them to the target inspection device, and collect screenshots of the dynamic configuration page, document object model tree structure, interface return data, and full-link operation logs during the inspection process; a detection rule generation agent, used to generate pitfall detection rules for the dynamic configuration page adapted to the target inspection device, including image-based pitfall detection rules, log-based pitfall detection rules, and data-based pitfall detection rules; and an algorithm detection module, used to detect pitfalls based on screenshots and document objects. The system uses a model tree structure and performs image anomaly detection on the dynamic configuration page according to image-based anomaly detection rules, obtaining image anomaly detection results. Based on the full-link runtime logs and following log-based anomaly detection rules, the system also performs log-based anomaly detection on the dynamic configuration page, obtaining log anomaly detection results. Based on the API return data and following data-based anomaly detection rules, the system performs data-based anomaly detection on the dynamic configuration page, obtaining data anomaly detection results. Based on the image, log, and data anomaly detection results, the system identifies anomalies in the dynamic configuration page, performs root cause localization, and generates an anomaly inspection report.

[0008] Thirdly, embodiments of this application provide an electronic device, which includes a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the steps of the pit detection method for dynamically configuring pages as described above.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the steps of the pit detection method for dynamically configured pages as described above.

[0010] Fifthly, embodiments of this application provide a computer program product, which includes computer program instructions that, when executed by a processor, implement the steps of the pit detection method for dynamically configured pages as described above.

[0011] The embodiments of this application provide a method, platform, electronic device, computer-readable storage medium, and computer program product for detecting voids in dynamic configuration pages. On the one hand, it utilizes an execution planning agent to generate a set of executable operation instructions for the device based on the inspection object and operation steps, and sends them to the target inspection device. Combined with a detection rule generation agent, it adapts and generates void detection rules that match the target inspection device. This can adapt to the differences in rendering mechanisms and display parameters of different terminal devices, effectively solving the problems of incomplete coverage and easy omissions and false detections in existing detection solutions in multi-terminal scenarios. At the same time, it replaces manual inspection, improves the efficiency of void detection, and can efficiently cope with the void inspection needs in massive configuration scenarios. It ensures the flexibility and real-time performance of dynamic configuration pages and reduces the negative impact of void problems on page visual effects and user experience. On the other hand, by collecting screenshots of the dynamic configuration page, the DOM tree structure, API return data, and end-to-end operation logs, and performing void anomaly detection according to image, log, and data detection rules respectively, this overcomes the limitations of existing technologies that can only detect voids in a single stage or of a single type. It achieves integrated verification of page rendering effects, underlying data interaction, and end-to-end operational status, enabling more comprehensive capture of void anomalies caused by each stage, such as blank areas, missing modules, unfilled placeholders, and image loading failures, thus improving the comprehensiveness and accuracy of void anomaly detection. Furthermore, while identifying void anomalies, root cause localization is performed based on the image, log, and data anomaly detection results, and a void inspection report is generated. This helps operations and maintenance personnel directly locate the root cause of voids based on the void inspection report, reducing manual troubleshooting time and thus shortening the void problem repair cycle and improving operations and maintenance response speed. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings of the embodiments of this application will be briefly described below.

[0013] Figure 1 This is a flowchart illustrating a method for detecting pits in a dynamically configured page, as provided in an embodiment of this application.

[0014] Figure 2 This is a schematic flowchart of step S101 in the method for detecting voids in a dynamically configured page provided in this application embodiment.

[0015] Figure 3 This is a schematic diagram of an operation of an execution planning agent provided in an embodiment of this application.

[0016] Figure 4 This is a schematic flowchart of step S102 in the method for detecting voids in a dynamically configured page provided in this application embodiment.

[0017] Figure 5 This is a schematic flowchart of step S103 in the method for detecting voids in a dynamically configured page provided in an embodiment of this application.

[0018] Figure 6 This is a schematic flowchart of step S104 in the method for detecting voids in a dynamically configured page provided in an embodiment of this application.

[0019] Figure 7 This is a structural block diagram of a pit detection platform with a dynamically configured page provided in an embodiment of this application.

[0020] Figure 8 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0021] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0022] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0023] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0024] Various modifications and variations can be made to this application without departing from its spirit or scope, which will be apparent to those skilled in the art. Therefore, this application is intended to cover modifications and variations falling within the scope of the corresponding claims (the claimed technical solutions) and their equivalents. It should be noted that the implementation methods provided in the embodiments of this application can be combined with each other without contradiction.

[0025] Before describing the technical solutions provided in the embodiments of this application, in order to facilitate understanding of the embodiments of this application, this application first specifically explains the problems existing in the prior art: In the operation of internet products, such as recruitment platforms, page content needs to be configured in real time according to different scenarios such as peak recruitment seasons, industry-specific events, and regional recruitment. This involves the dynamic adjustment of page elements such as job recommendation modules, salary display areas, industry category floors, advertising materials, and / or multilingual copywriting. The flexibility and real-time requirements of page configuration are high. As business complexity increases, anomalies can easily occur in the configuration distribution, API calls, data parsing, resource loading, and page rendering stages of dynamically configured pages. This can lead to problems such as blank areas with no content displayed, missing modules, unfilled placeholders, and failed image loading. These abnormal display areas are collectively referred to as "empty pits." Empty pits not only damage the overall visual effect of the page but also directly prevent key information from reaching users, reducing the user's browsing experience and willingness to use the page.

[0026] Current methods for detecting pitfalls in dynamic configuration pages have significant limitations and fail to meet actual operational needs. Existing detection methods generally suffer from incomplete coverage and poor adaptability. They either rely on manual inspection, which is limited by labor costs and efficiency, leading to missed or false positives, and is difficult to handle the multi-terminal inspection requirements of massive configuration scenarios. Or they adopt fixed automated detection modes, which can only detect anomalies in a single link or type, failing to comprehensively verify page rendering effects, underlying data interaction, and the overall operational status, making it difficult to fully capture pitfall anomalies in various complex scenarios. Furthermore, different terminal devices differ in rendering mechanisms, display parameters, and compatibility, making it difficult for existing detection solutions to cover pitfall anomaly scenarios on multiple terminal devices, further increasing the probability of missed or false positives.

[0027] In addition, existing detection solutions can usually only achieve preliminary identification of pit void anomalies. When pit void problems occur, existing solutions cannot quickly identify the root cause of the anomaly, which requires maintenance personnel to spend a lot of time troubleshooting the problem, prolonging the anomaly handling cycle and thus hindering the rapid repair of pit void problems.

[0028] To address at least one of the aforementioned technical problems, embodiments of this application provide a method, platform, electronic device, computer-readable storage medium, and computer program product for detecting voids in dynamically configured pages.

[0029] The method for detecting voids in the dynamic configuration page provided in this application embodiment will be introduced first.

[0030] Dynamically configured pages refer to pages whose content is not fixed through hard coding, but rather dynamically assembled and generated by operations personnel or the system based on factors such as business scenarios, user attributes, and time nodes. This is achieved through visual drag-and-drop, component combination, and configuration item distribution. Taking a recruitment platform as an example, in different scenarios such as peak recruitment seasons, industry-specific events, or regional recruitment, operations personnel can flexibly adjust the style, content, and layout of page elements such as job recommendation modules, salary display areas, industry category floors, advertising materials, and multilingual copy through the backend configuration system. This enables rapid page iteration and scenario-based adaptation. Such pages typically feature high real-time performance and high flexibility, allowing for content updates and replacements without requiring a new version release.

[0031] The dynamic configuration page in this application embodiment can be a recruitment platform's dynamic configuration page, or it can be a dynamic configuration page of other types of internet platforms, such as e-commerce platforms, social platforms, etc. This application does not limit it. For ease of understanding, this application uses the dynamic configuration page of a recruitment platform as an example to introduce the method for detecting voids in dynamic configuration pages.

[0032] Figure 1 This is a flowchart illustrating a method for detecting pitfalls in a dynamically configured page, as provided in an embodiment of this application. Figure 1 As shown, the method for detecting voids in the dynamic configuration page provided in this application embodiment may include the following steps S101 to S106.

[0033] S101: By executing the planning agent, it generates a set of executable operation instructions for the equipment based on the inspection object and inspection operation steps, and sends them to the target inspection equipment. It also collects screenshots of the dynamic configuration page, the document object model tree structure, interface return data, and full-link operation logs during the inspection process.

[0034] Specifically, users can create inspection tasks for dynamically configured pages through the front-end, specifically, tasks to detect empty spaces on dynamically configured pages. Upon receiving an inspection task, the execution planning agent can invoke a natural language processing (NLP) model to semantically parse the inspection requirements. For example, this NLP model can employ a pre-trained language model based on the Transformer architecture (such as BERT or RoBERTa), fine-tuned in the field of page inspection, enabling it to accurately identify key semantic elements in the inspection requirements. During parsing, the execution planning agent can extract inspection objects, such as page elements or modules like job listings, job details, search boxes, popular job floors, industry category floors, and advertising areas. The execution planning agent can also identify inspection operation steps, such as swiping the screen, clicking buttons, entering keywords, returning to the previous page, pull-to-refresh, and long-pressing. Through this semantic parsing process, the execution planning agent can transform the inspection requirements described in natural language into structured inspection requirement data.

[0035] After semantic parsing, the execution planning agent can combine the screenshot of the target inspection device with image recognition algorithms to locate the specific position of the inspection object on the screen, and dynamically generate a set of executable operation instructions based on the inspection operation steps. For example, when the inspection requirement is to swipe to the popular job postings section on the job posting homepage and take a screenshot of that section, the execution planning agent parses the inspection object as the popular job postings section, and the inspection operation steps are swiping and taking a screenshot. Then, combining the screenshot of the target inspection device, it uses image recognition algorithms to locate the specific coordinate area of ​​the popular job postings section on the screen, generates a set of operation instructions containing a series of specific instructions such as swiping to the specified coordinate area and performing the screenshot operation, and sends this set of operation instructions to the target inspection device.

[0036] The target inspection device can be any type of smartphone, tablet, personal computer, smartwatch, or other wearable device, and this application does not limit it. Furthermore, the execution planning agent can control the target inspection device to complete the inspection operation on the dynamic configuration page according to the operation instruction set, while simultaneously collecting screenshots of the dynamic configuration page, the Document Object Model Tree (DOM tree) structure, interface return data, and end-to-end operation logs during the inspection process.

[0037] S102: Generates dynamic configuration page void detection rules adapted to the target inspection equipment by generating intelligent agents based on detection rules. Void detection rules include image-based void detection rules, log-based void detection rules, and data-based void detection rules.

[0038] In practical applications, such as recruitment platforms where dynamic configuration pages need to be displayed on various terminal devices, including mobile phones and tablets of different brands and applications on different operating systems, such as Android apps, iOS apps, HarmonyOS apps, mini-programs, and H5 pages. Different devices have varying screen sizes, resolutions, operating system versions, and operating environments. When the same set of operation instructions is executed on different devices, the detection results may be distorted or invalid due to differences in display parameters, compatibility issues, or inconsistent interaction logic. Therefore, this application embodiment sets up a detection rule generation intelligent agent. This detection rule generation intelligent agent is an intelligent rule generation unit based on a large language model, capable of adaptively generating matching pit detection rules based on information such as the type, system version, and resolution of the target inspection device.

[0039] In step S102, a detection rule generation agent generates dynamic configuration page pitfall detection rules adapted to the target inspection equipment. For example, the detection rule generation agent can generate dynamic configuration page pitfall detection rules adapted to the target inspection equipment based on information such as the type, system version, and resolution of the target inspection equipment. Pitfall detection rules can include image-based pitfall detection rules, log-based pitfall detection rules, and data-based pitfall detection rules.

[0040] For example, image-based void detection rules can include rules for detecting the percentage of blank areas and missing image materials, which can be used to detect void anomalies in dynamic configuration pages from a visual presentation perspective. Log-based void detection rules can include rules for detecting data recall volume, API call status, resource loading status, software development kit (SDK) runtime status, page rendering status, and / or execution error detection, which can be used to detect void anomalies in dynamic configuration pages from a runtime status perspective. Data-based void detection rules can include rules for detecting empty API return data, missing core data fields, and data entry quantity thresholds, which can be used to detect void anomalies in dynamic configuration pages from a data content perspective.

[0041] S103: Based on the screenshot and document object model tree structure, and in accordance with the image-type void detection rules, perform image-type anomaly detection on the dynamic configuration page to obtain the image-type anomaly detection results.

[0042] In S103, a screenshot of the dynamic configuration page and the DOM tree structure can be used as input information. Following the image-type void detection rules generated in step S102, image-type anomaly detection is performed on the dynamic configuration page to obtain the image-type anomaly detection results. This allows for the identification of voids in the dynamic configuration page from a visual presentation perspective, such as identifying visual void problems like blank areas, missing modules, unfilled placeholders, and failed image loading.

[0043] S104: Based on the full-link operation logs and in accordance with the log-type pitfall detection rules, perform log-type anomaly detection on the dynamic configuration page and obtain the log-type anomaly detection results.

[0044] In S104, the full-link operation log can be used as input information, and the log-type pitfall detection rules generated in step S102 can be used to perform log-type anomaly detection on the dynamic configuration page to obtain the log-type anomaly detection results. This allows for the identification of pitfalls in the dynamic configuration page from the perspective of the running status, such as identifying pitfall problems caused by anomalies in the underlying data interaction, resource loading, rendering execution, and other links.

[0045] S105: Based on the data returned by the interface, and in accordance with the data-related void detection rules, perform data-related anomaly detection on the dynamic configuration page to obtain the data-related anomaly detection results.

[0046] In S105, the interface return data can be used as input information, and the data-related void detection rules generated in step S102 can be used to perform data-related anomaly detection on the dynamic configuration page to obtain the data-related anomaly detection results. This allows for the identification of voids in the dynamic configuration page from the data content level, such as identifying void problems caused by data retrieval failure, missing data fields, or invalid business data.

[0047] S106: Based on the results of image anomaly detection, log anomaly detection, and data anomaly detection, identify pitfalls in the dynamic configuration page, locate the root cause, and generate a pitfall inspection report.

[0048] In S106, the results of image, log, and data anomaly detections can be comprehensively analyzed to determine whether pitfalls exist in the dynamic configuration page, their location, and type. Furthermore, by performing correlation analysis and causal reasoning on various anomaly detection results, the root cause of the pitfall can be determined. For example, if image detection finds that the popular job postings section is blank, log detection finds that the API returning job data has a 200 status code but returns empty data, and data detection confirms that the data list returned by the interface is empty, then a comprehensive analysis can conclude that the root cause of the pitfall is the absence of data source return. Finally, based on the pitfall identification results and root cause location results, a pitfall inspection report is generated, allowing operations personnel to directly locate the root cause of the pitfall and quickly repair it.

[0049] The method for detecting voids in a dynamic configuration page provided in this application, on the one hand, utilizes an execution planning agent to generate a set of executable operation instructions for the device based on the inspection object and operation steps, and sends them to the target inspection device. On the other hand, it combines a detection rule generation agent to adapt and generate void detection rules that match the target inspection device. This method can adapt to the differences in rendering mechanisms and display parameters of different terminal devices, effectively solving the problems of incomplete coverage and easy omissions and false detections in existing detection solutions in multi-terminal scenarios. At the same time, it replaces manual inspection, improves the efficiency of void detection, and can efficiently cope with the void inspection needs in massive configuration scenarios. This ensures the flexibility and real-time performance of the dynamic configuration page and reduces the negative impact of void problems on the page's visual effects and user experience.

[0050] On the other hand, by collecting screenshots of the dynamic configuration page, the DOM tree structure, API return data, and end-to-end operation logs, and performing void anomaly detection according to image, log, and data detection rules respectively, this overcomes the limitations of existing technologies that can only detect voids in a single stage or of a single type. It achieves integrated verification of page rendering effects, underlying data interaction, and end-to-end operational status, enabling more comprehensive capture of void anomalies caused by each stage, such as blank areas, missing modules, unfilled placeholders, and image loading failures, thus improving the comprehensiveness and accuracy of void anomaly detection. Furthermore, while identifying void anomalies, root cause localization is performed based on the image, log, and data anomaly detection results, and a void inspection report is generated. This helps operations and maintenance personnel directly locate the root cause of voids based on the void inspection report, reducing manual troubleshooting time and thus shortening the void problem repair cycle and improving operations and maintenance response speed.

[0051] To facilitate understanding, the following detailed description of the pitfall detection method for dynamic configuration pages will be provided with reference to some specific embodiments.

[0052] Figure 2This is a flowchart illustrating step S101 of the pit detection method for a dynamic configuration page provided in this application embodiment. Figure 2 As shown, according to some embodiments of this application, optionally, S101: by executing the planning agent, generating a set of executable operation instructions for the device based on the inspection object and inspection operation steps and sending them to the target inspection device, the following steps S201 to S202 may be included.

[0053] S201: The screenshot of the dynamic configuration page is identified by an image recognition algorithm to obtain the screenshot recognition result, which includes the current page type, the position of interface elements and operation node information.

[0054] Figure 3 This is a schematic diagram illustrating the operation of an execution planning agent provided in an embodiment of this application. (In conjunction with...) Figure 3 As shown in S201, the execution planning agent can acquire the current screenshot returned by the target inspection equipment in real time, and can identify the screenshot of the target inspection equipment through image recognition algorithms to obtain the screenshot recognition result. Specifically, the execution planning agent first uses image recognition algorithms to locate interactive elements in the screenshot, such as buttons, input boxes, cards, list items, and other interface components, and obtains the coordinate position, size, and type label of each element on the screen. Then, it extracts the text content in the screenshot, such as page title, button text, job name, company information, etc., and associates the text content with the corresponding interface elements. Based on this, the execution planning agent can combine the page layout rules and operation logic in the business knowledge base to determine the current page type, such as identifying the current page scenario, such as the homepage - recommended job floor, job list page, job details page, or search filter page, and marking the key operation nodes in the current page, such as the more job buttons, filter options, and clickable areas of job cards, which are interactive elements that can trigger subsequent operations.

[0055] S202: Combine the inspection object, inspection operation steps and screen screenshot recognition results to generate an operation instruction set and send the operation instruction set to the target inspection equipment; the operation instruction set includes operation type, operation coordinates and execution order.

[0056] The execution planning agent can plan a series of operation steps required to complete the inspection based on the position and state of the current page elements. When generating operation instructions, the execution planning agent first determines the operation type, such as click, swipe, long press, text input, or wait. Then, based on the element position coordinates in the screenshot recognition results, it assigns specific execution coordinates or operation areas to each operation. Next, it sorts the instructions according to the logical order of the inspection operation steps, forming a complete operation sequence. Finally, it encapsulates the generated operation instruction set into a standardized format recognizable by the device and sends it to the target inspection device for execution. For example, in response to the inspection requirement of finding and clicking the "More Jobs" button by swiping down the screen, the execution planning agent combines the current page's scroll position and the expected position of the "More Jobs" button from the screenshot recognition results to generate an operation instruction set containing "swipe up (swipe up, start coordinates (520, 1000), end coordinates (520, 500))" and "tap (tap, coordinates (x, y))". The instruction set is arranged in the order of swiping first and then tapping to ensure that the operation instructions can accurately simulate user behavior and complete the inspection task.

[0057] Thus, by executing steps S201 to S202 through the planning agent, a fully intelligent process is achieved, from semantic understanding of inspection needs to visual perception of the screen, and then to the dynamic generation of operation instructions. By integrating the inspection object, inspection operation steps, and screen screenshot recognition results, an operation instruction set adapted to the current page state is dynamically generated. This allows the operation instruction set to be flexibly adjusted according to the actual rendering of the page, improving the accuracy and success rate of instruction execution. Simultaneously, this operation instruction set can include multi-dimensional information such as operation type, coordinates, and execution order, accurately simulating user operation behavior and achieving automated and intelligent inspection of dynamically configured pages, thus improving the execution efficiency and coverage of inspection tasks.

[0058] According to some embodiments of this application, optionally, S202: Sending the operation instruction set to the target inspection equipment may include the following steps: The execution planning agent performs cross-device and / or cross-environment adaptation processing on the generated operation instruction set based on the inspection equipment information, and then sends the adapted operation instruction set to the target inspection equipment, so that the operation instruction set is adapted to different inspection equipment and / or different inspection environments.

[0059] As mentioned earlier, in practical applications, the dynamic configuration page of the recruitment platform needs to be displayed on various terminal devices, such as mobile phones and tablets of different brands, and applications with different operating systems, such as Android Apps, iOS Apps, HarmonyOS Apps, mini-programs, and H5 pages. Different devices have different screen sizes, resolutions, operating system versions, and operating environments. When the same set of operation instructions is executed on different devices, it may fail or produce distorted detection results due to coordinate offsets, differences in operation logic, or different environment configurations. To solve this problem, the execution planning agent in this embodiment has cross-device and cross-environment adaptability, and can dynamically adjust the generated set of operation instructions based on the inspection equipment information to ensure that the instructions can be executed accurately on different terminals.

[0060] Specifically, the inspection equipment information can include the type of the target inspection equipment (e.g., a mobile phone / computer of a certain brand and model), system version (e.g., Android 13, iOS 17), and resolution (e.g., 1080p). 2400, etc.) and inspection environment labels (such as test environment, pre-release environment or production environment, etc.).

[0061] The execution planning agent can be used to match the corresponding operation logic of the target inspection device based on its type and system version; and to adjust the operation coordinates and action execution parameters in the operation instruction set according to the resolution of the target inspection device, i.e., cross-device adaptation processing. In some embodiments, the execution planning agent can also be used to load the application runtime configuration of the corresponding inspection environment based on the inspection environment identifier, i.e., cross-environment adaptation processing. In this way, the operation instruction set under the same inspection requirement can be adapted to different target inspection devices and / or different inspection environments.

[0062] In some examples, the execution planning agent has a built-in cross-platform operation logic mapping table, which can automatically match the corresponding operation logic according to the device type and system version, and convert common operation instructions (such as returning to the previous page) into operation sequences adapted to the current device. For example, sending a KEYCODE_BACK event on an Android device and executing a click operation at the coordinates of the top left corner back button on an iOS device, ensuring semantic consistency of operation instructions on different systems.

[0063] Secondly, different devices have significantly different screen resolutions. Directly using fixed coordinates generated on one device may result in issues like click position misalignment, insufficient or excessive swipe distance on another device with a different resolution. Therefore, when generating the operation instruction set, the execution planning agent can record the relative position coordinates of each operation element in the original screenshot. After receiving the resolution information of the target inspection device, it converts the relative coordinates to absolute pixel coordinates based on the target device's screen width and height, achieving precise mapping of the click position. Simultaneously, for swipe operations, the execution planning agent dynamically adjusts the swipe start point, end point, and swipe distance based on the target device's screen size, ensuring that the swipe action covers the intended operation area. For example, on devices with smaller screens, the swipe distance is appropriately shortened to avoid excessive swipes that miss the target element.

[0064] Furthermore, inspection tasks can be executed in different environments, such as testing environments, pre-production environments (for pre-launch acceptance), and production environments. The application runtime configurations may differ between these environments. For example, a testing environment might use mock data or test accounts, a pre-production environment requires connection to a pre-production server, and a production environment requires real user accounts and online data. Therefore, in some examples, the execution planning agent can load the corresponding environment's runtime configuration parameters, such as API request domain names, account information, and data isolation rules, based on the inspection environment identifier. It can also embed environment-related initialization instructions into the operation instruction set, such as logging in with a test account or switching to the pre-production environment, ensuring that the inspection task runs correctly in the specified environment and effectively avoiding detection failures or data contamination caused by incorrect environment configuration.

[0065] In this way, by executing the planning intelligent agent to adapt the operation instruction set across devices and environments, the same inspection requirement can be uniformly executed on different terminals and in different environments. This effectively solves the problems of difficult cross-terminal adaptation and cumbersome environment configuration, improving the execution efficiency and coverage of inspection tasks. Adaptation of device type and system version resolves the issue of inconsistent cross-platform operation logic, ensuring that operation instructions accurately reproduce user behavior on different operating systems. Resolution adaptation solves the problems of click offset and swipe failure caused by differences in screen size, improving the accuracy of instruction execution. Environment identifier adaptation enables task isolation and configuration switching in multiple environments, meeting the testing needs of different stages such as development testing, online acceptance, and online inspection.

[0066] Figure 4 This is a schematic flowchart of step S102 in the method for detecting pits in a dynamically configured page provided in this application embodiment. Figure 4As shown, according to some embodiments of this application, optionally, S102: generating a dynamic configuration page for pit detection rules adapted to the target inspection equipment by generating a detection rule intelligent agent may include the following steps S401 to S404.

[0067] S401: Extract multi-dimensional feature vectors based on screenshots of the dynamic configuration page, inspection operation steps, and document object model tree structure.

[0068] The multi-dimensional feature vector can include the visual features of the screenshot, the process features of the inspection operation, and the hierarchical features of the document object model tree structure.

[0069] Specifically, the detection rule-generating agent can extract visual features such as the position coordinates, size, color parameters, and / or texture features of page elements from screenshots of dynamically configured pages, obtaining a visual feature vector. For example, for a screenshot of popular job postings on a recruitment platform, it can extract the coordinate range of the job card, the grayscale values ​​of the text area within the job card, and the loading status indicators of image resources, forming a visual feature vector.

[0070] The detection rule generation agent can extract process features such as operation sequence, operation triggering method, corresponding page module, operation execution time, and / or operation feedback result from the inspection operation steps, thus obtaining a process feature vector. The detection rule generation agent can also extract hierarchical features from the DOM tree structure, such as node level, node type (e.g., div, span, img), node attributes (e.g., class, id, src), nesting relationships between nodes, and / or the existence identifier of key nodes, thus obtaining a DOM tree hierarchical feature vector.

[0071] Then, the visual feature vector, process feature vector, and DOM tree level feature vector are fused to obtain a multi-dimensional feature vector. In some embodiments, different weights can be assigned during feature fusion based on the influence of each feature vector on pit detection. For example, the weight of the visual feature vector is set to 0.4, the weight of the process feature vector is set to 0.3, and the weight of the DOM tree level feature vector is set to 0.3. The final multi-dimensional feature vector is obtained by weighted summation, so that the fused feature vector can comprehensively reflect the inspection scenario, page characteristics, and operation process.

[0072] For example, taking the inspection scenario of popular job floors on a recruitment platform as an example, the visual feature vector can include: the coordinates of the popular job floor (100, 200, 800, 600), the size of the job card (180, 220), the grayscale value of the card text (120-180), and the percentage of pixels with successful image loading (95%). The process feature vector can include: the operation sequence (homepage → popular job floor → details page → homepage), the operation triggering method (click), the corresponding module ID of the operation (hot-job-floor), and the operation execution time (5s). The DOM tree level feature vector can include: the node level (3 levels), the number of child nodes (10), and the existence identifier of key nodes (the job name node exists, the salary node exists). For example, the multi-dimensional feature vector can be [100, 200, 800, 600, 180, 220, 120-180, 95%, 1, 0, 3, 10, 1, 1], where 1 represents click triggering and 0 represents non-swipe triggering for the operation triggering method; and 1 represents the existence of the key node and 0 represents the non-existence of the key node for the key node. The specific values ​​can be flexibly adjusted according to the actual situation. The multi-dimensional feature vector integrates the core features of page visuals, inspection processes, and DOM structure.

[0073] S402: Select target pit verification point templates that match the multi-dimensional feature vectors from the vector knowledge base.

[0074] The vector knowledge base stores multiple pre-built pit detection templates. Each template corresponds to a specific pit detection scenario and is associated with a corresponding feature vector index. In S402, the detection rule generation agent calculates the similarity between the multi-dimensional feature vector and the feature vectors of each pit detection template in the vector knowledge base, such as calculating cosine similarity or Euclidean distance. It then selects one or more pit detection templates with similarity scores higher than a similarity threshold as target pit detection templates.

[0075] The target void checkpoint template can include image-based void checkpoint templates, log-based void checkpoint templates, and data-based void checkpoint templates, which can be used to guide the generation of different types of void detection rules.

[0076] For example, taking the scenario of floor inspection for popular positions on a recruitment platform as an example, image-related void checkpoint templates can include image loading failure checkpoints (such as pixel features of image placeholders, error indicators of image loading failure), page blank area checkpoints (such as size thresholds of blank areas, position ranges of blank areas), and element missing checkpoints (such as visual features of missing job cards or missing image elements). Log-related void checkpoint templates can include API call failure log checkpoints (such as API return codes other than 200, API timeout log features), resource loading exception log checkpoints (such as log indicators of image resource loading timeout or CSS file loading failure), and rendering exception log checkpoints (such as log information of DOM node rendering failure). Data-related void checkpoint templates can include API return data missing checkpoints (such as missing key data fields such as job name and salary), data format exception checkpoints (such as incorrect salary data format or abnormal date field format), and data matching failure checkpoints (such as mismatch between the mapping relationship between DOM nodes and API return data).

[0077] S403: Construct prompt words based on multi-dimensional feature vectors and inspection equipment information.

[0078] In S403, the core logic of the detection rule generation agent in constructing prompt words is to integrate the core information reflected by the multi-dimensional feature vector, such as the inspection scenario, page characteristics, and operation process, with the hardware, software, and environmental information of the target inspection device. According to the preset prompt word template, it generates targeted and executable prompt words, thereby providing clear guidance for the subsequent generation of pit detection rules adapted to the target device. This ensures that the generated detection rules can accurately adapt to the current inspection scenario and target device, preventing problems such as incompatibility between the detection rules and the device or mismatch between the detection rules and the scenario.

[0079] Specifically, the detection rule generation agent first parses multi-dimensional feature vectors, extracts key information, and converts it into natural language. The key information extracted from these multi-dimensional feature vectors includes, but is not limited to: inspection page modules (such as popular job postings on the job homepage), core page elements (such as job cards, salary display areas, and image resources), page visual parameters (such as element coordinates, size, and color characteristics), inspection operation processes (such as operation sequences and triggering methods), and DOM tree structure features (such as node levels and key node identifiers). Simultaneously, it acquires device information for the target inspection equipment, which may include device type, system version, screen parameters (such as resolution 1080×2400, screen size 6.7 inches, and pixel density 320dpi), rendering engine type, inspection environment identifiers (such as test environment, production environment, and intranet environment), and device compatibility information (such as supported image formats, CSS style compatibility, and API request protocol support).

[0080] After extracting key information from multi-dimensional feature vectors and collecting inspection equipment information, the detection rule generation agent structurally fuses the two types of information according to a preset prompt word template to construct standardized and parsable prompt words. For example, the preset prompt word template may include the following core modules: an inspection scenario description module, a target equipment information module, a detection rule type requirement module, a detection accuracy requirement module, and / or an output format requirement module. In some embodiments, the prompt word template may also include an abnormal scenario description module, such as common pit types or key detection areas.

[0081] The inspection scenario description module is mainly used to describe the specific scenario, page module and core inspection requirements of the current inspection. For example, the current inspection scenario is the popular job postings floor on the homepage of a recruitment platform. This floor contains 10 job cards. Each card contains core elements such as job title, salary, company name and image resources. The inspection operation process is to enter the homepage → click on the popular job postings floor → view job details → return to the homepage. In the page DOM tree structure, the node level corresponding to this floor is 3 levels. The key child nodes include job title node, salary node and image node.

[0082] The target device information module is mainly used to describe the device information of the target inspection device. For example, the target inspection device is a mobile phone with the device model number xx, the system version is Android 13, the screen resolution is 1080×2400, the screen size is 6.36 inches, the pixel density is 395dpi, the rendering engine is WebView 114.0.5735.198, the inspection environment is a production environment, the supported image formats are JPG and PNG, the WebP format is not supported, and the HTTP / HTTPS protocol is supported.

[0083] The detection rule type requirement module is mainly used to describe the detection scenario, image-based void detection rules, log-based void detection rules, and data-based void detection rules. For example, generating three types of void detection rules: image-based void detection rules, log-based void detection rules, and data-based void detection rules. Image-based void detection rules mainly target abnormal loading of job card images and blank areas; log-based void detection rules mainly target abnormal logs related to API calls, resource loading, and page rendering; and data-based void detection rules mainly target missing key data and abnormal formatting in API responses.

[0084] The detection accuracy requirement module is mainly used to describe the error range, false negative rate, and false positive rate requirements of the detection rules. For example, the detection accuracy requirements are: for image-type void detection, the false negative rate should be ≤1% and the false positive rate should be ≤0.5%, and it should be able to identify blank areas with a size ≥10×10 pixels; for log-type void detection, it should accurately identify logs related to interface return codes other than 200, resource loading timeouts, and rendering failures; for data-type void detection, it should accurately identify missing and formatted abnormalities in key fields such as job titles and salaries.

[0085] The output format requirements module is mainly used to describe the output format of the detection rules. For example, the output format of the detection rules is JSON. Each type of detection rule includes fields such as rule ID, rule name, detection logic, detection threshold, adapted device parameters, and anomaly judgment criteria. The detection threshold needs to be set in conjunction with the target device parameters.

[0086] S404: Input the constructed prompt words and target void verification point template into the detection rule big language model, and generate the void detection rules for the dynamic configuration page of the target inspection equipment through the detection rule big language model.

[0087] In S404, the detection rule generation agent takes the prompt word and the target void checkpoint template as joint inputs and simultaneously inputs them into the preset detection rule large language model.

[0088] After receiving the prompt words and the target pitfall verification point template, the detection rule big language model will generate pitfall detection rules for the dynamic configuration page adapted to the target inspection device based on its own trained pitfall detection rule generation logic, combined with the device adaptation requirements and scenario needs in the prompt words, and the verification standards of the target pitfall verification point template. During the generation process, the detection rule big language model can prioritize the device parameters in the prompt words, such as rendering engine, resolution, and compatibility characteristics, and adjust the adaptation logic of the detection rules accordingly. For example, for the WebView rendering engine of Android phones, it can optimize the pixel recognition threshold and DOM node verification logic of image-type detection rules to ensure that the rules can be executed normally on the target inspection device. At the same time, it can improve the detection details of various rules by referring to the target pitfall verification point template. For example, it can improve the judgment threshold and recognition logic of blank areas in image-type pitfall detection rules by combining the blank area verification standards in the image-type verification point template. It can improve the log filtering conditions and anomaly judgment standards of log-type detection rules by combining the interface abnormal log characteristics in the log-type verification point template.

[0089] The generated dynamic configuration page's vulnerability detection rules can include three categories: image-based, log-based, and data-based. Image-based vulnerability detection rules are primarily used for anomaly detection in page screenshots and the DOM tree structure, and can include detection logic, thresholds, and adaptation parameters for visual vulnerabilities (such as blank areas, image loading failures, missing elements, etc.). Log-based vulnerability detection rules mainly target anomaly detection in the entire runtime log, and can include filtering conditions, anomaly characteristics, and judgment criteria for logs related to API calls, resource loading, and rendering anomalies. Data-based vulnerability detection rules mainly target anomaly detection in API-returned data, and can include detection logic for issues such as missing key data, formatting errors, and data matching failures.

[0090] Thus, by extracting multi-dimensional feature vectors and fusing page visual information, inspection operation processes, and DOM tree structure features, a comprehensive digital representation of the inspection scenario is achieved. Based on these feature vectors, matching target void verification point templates are selected from the vector knowledge base. This allows for the reuse of historically accumulated detection experience and verification standards, avoiding the need to build detection rules from scratch each time, thus improving the efficiency and accuracy of rule generation. On the other hand, by integrating inspection equipment information into the construction process of prompt words, the detection rule language model can specifically adjust the adaptation logic of the detection rules according to the hardware parameters, software environment, and compatibility characteristics of the target device. This effectively solves the problems of missed and false detections caused by device differences, improving the cross-terminal adaptability and detection accuracy of void detection.

[0091] By combining multi-dimensional feature vectors, inspection equipment information, and target void verification point templates to construct prompt words, and inputting them into the detection rule big language model, the semantic understanding and generation capabilities of the big language model can be fully utilized. The generated void detection rules cover three categories: image-based, log-based, and data-based rules, which detect voids from three dimensions: visual presentation, operating status, and data content, respectively, forming a complete detection rule system.

[0092] According to some embodiments of this application, image anomaly detection, log anomaly detection, and data anomaly detection can optionally be executed in parallel and independently, and the results of multiple anomaly detections can complement each other.

[0093] Specifically, the three detection sub-processes—image anomaly detection, log anomaly detection, and data anomaly detection—execute independently and in parallel within the algorithm detection module, without interfering with each other. Each sub-process can use its corresponding data source as input and perform anomaly analysis according to its respective pitfall detection rules. The image anomaly detection sub-process identifies pitfalls at the visual level based on screenshots and the DOM tree structure; the log anomaly detection sub-process identifies pitfalls at the runtime status level based on end-to-end runtime logs; and the data anomaly detection sub-process identifies pitfalls at the data content level based on API return data. The three detection sub-processes can execute simultaneously without waiting for each other to complete, and each outputs its corresponding anomaly detection results.

[0094] Because the three detection methods are based on different data sources and detection principles, their results are naturally complementary. Image anomaly detection can identify problems at the visual presentation level, but it is difficult to determine the root cause of the problem; log anomaly detection can locate the execution anomaly, but it is difficult to confirm whether it caused the visual void; data anomaly detection can identify missing data, but it is difficult to verify whether the data is rendered correctly. The results of the three detection methods corroborate and complement each other, and can cover complex void anomalies that are difficult to detect by a single detection method. For example, image detection may find that a certain floor is blank, log detection may find that the data retrieval is normal but the rendering process is faulty, and data detection may confirm that the data fields are complete. A comprehensive judgment can be made that the root cause of the void is an abnormal rendering.

[0095] Thus, by setting image anomaly detection, log anomaly detection, and data anomaly detection to be executed in parallel and independently, multiple dimensions of void scanning can be performed simultaneously on the dynamic configuration page. Compared to a serial execution method, this improves detection efficiency and shortens the overall time spent on void detection. Furthermore, the three detection methods are based on different data sources and detection principles, and their results are naturally complementary. They can comprehensively capture various void anomalies from three dimensions: visual presentation, operational status, and data content, avoiding the limitations of a single detection method. By comprehensively analyzing and cross-verifying multiple detection results, the existence, type, and possible causes of voids can be more accurately identified, improving the comprehensiveness and accuracy of void detection.

[0096] Figure 5 This is a schematic flowchart of step S103 in the pit detection method for a dynamic configuration page provided in this application embodiment. Figure 5 As shown, according to some embodiments of this application, optionally, S103: Based on the screenshot and document object model tree structure, and in accordance with the image-type void detection rules, perform image-type anomaly detection on the dynamic configuration page to obtain the image-type anomaly detection result, which may include the following steps S501 to S504.

[0097] S501: Perform node parsing, hierarchy parsing, and attribute parsing on the Document Object Model (DOM) tree structure. Detect whether there are missing preset container nodes, whether the arrangement of child elements within the container node is misaligned, whether the element visibility attribute of the container node is abnormal, whether the content filling state of the container node is empty, and whether the size of the container node meets at least one of the preset standards, and obtain the UI structure detection results.

[0098] In this context, container nodes are DOM elements on the page that hold content areas, such as the div container for popular job listings or the section container for industry category listings. Child elements are the various content elements contained within the container node, such as job cards, title text, and image assets. Element visibility properties are CSS properties that control whether an element is visible on the page, such as display, visibility, and opacity.

[0099] During node parsing, the DOM tree can be traversed, and the target container node can be located based on preset container node identifiers, such as the container node's class name, ID, or data attributes. The existence of this container node in the DOM tree can then be checked. If a preset container node is missing, it is determined to be a container node missing anomaly, which may result in the corresponding content area being completely blank.

[0100] During the hierarchical relationship resolution process, the structural relationship between container nodes and their child elements can be analyzed, the index order and position information of each child element within the container can be extracted, and compared with the expected arrangement order. If the arrangement position of child elements is misaligned, such as a job card appearing before the floor title, or the order of multiple cards not conforming to the design draft, it is determined to be an abnormal misalignment of child element positions.

[0101] During attribute parsing, the visibility attribute values ​​of container nodes and their child elements can be extracted to detect whether elements are hidden. For example, if the container node's display property is none, its visibility property is hidden, or its opacity property is close to 0, it is determined that the element's visibility property is abnormal; although the content area exists in the DOM tree, it is not actually visible. Simultaneously, the size attributes (such as width and height) of the container node can be detected; if the size is 0 or much smaller than expected, it is determined that the container node's size is abnormal.

[0102] In addition, the content filling status of container nodes can be detected, that is, checking whether there is actual content inside the container node. For example, for text elements, it checks whether their text content (textContent) or inner text (innerText) is an empty string or contains only whitespace characters. For image elements, it checks whether their resource address is empty or points to an invalid resource, or whether the actual rendered size of the image is 0. For list elements, it checks whether the number of their child nodes is 0. If a container node exists but its internal content is empty, it is determined that the content filling status is abnormal.

[0103] The UI structure detection results are generated through the multi-dimensional DOM structure analysis described above. For example, the UI structure detection results may include the location of elements with anomalies, the type of anomaly, and details of the anomaly.

[0104] S502: Extract the text information from the screenshot and input the text information into the large language model. The large language model detects whether the text in the content display area is truncated or missing, and whether the text filling amount meets at least one of the preset thresholds, and obtains the text detection result of the large language model.

[0105] Specifically, text regions in a screenshot can be identified and extracted to obtain the text content and contextual information of the text regions (such as the module they belong to and adjacent elements). After text extraction, the identified text content and contextual information of the text regions are input into the large language model.

[0106] The large language model performs semantic-level analysis on the input text information to detect whether there are truncations or omissions in the text displayed within the content area. For example, if a job description is displayed as "Job Responsibilities: Responsible for..." but the latter part is truncated, or a company name is displayed as "XXX Technology Co., Ltd." but the word "Company" is missing, or a welfare label is displayed as "Five Insurances and One Benefit" but the word "Gold" is missing, the large language model can identify these abnormal situations of text truncation or omissions through semantic understanding and contextual inference.

[0107] Simultaneously, the large language model can also detect whether the amount of text filled meets a preset threshold. For example, a popular job posting section is expected to display at least three job cards, each containing three core text fields: job title, company name, and salary range. If the large language model detects that fewer than three job cards are actually filled, or that a card is missing the salary range field, it determines that the text filling does not meet the preset threshold. The large language model can dynamically adjust the filling threshold based on business rules; for example, in scenarios with insufficient data, it allows triggering fallback data filling.

[0108] The large language model outputs text detection results based on the aforementioned detection dimensions. For example, the large language model text detection results may include information such as the location and type of abnormal text.

[0109] S503: Compare the visual features of the screenshot with the visual features of the standard design draft, detect whether the image or icon material in the content display area is missing, and whether the proportion of blank area in the content display area exceeds the preset void judgment threshold, and obtain the image algorithm feature detection result.

[0110] The standard design draft is provided by the UI designer and serves as a benchmark reference for the page's visual effects. In S503, following the visual feature detection rules in the image-based void detection rules, the image feature extraction model is invoked to extract visual features from both the inspection screenshot and the standard design draft. For example, the image feature extraction model can employ a convolutional neural network architecture, capable of extracting multi-scale visual features of the image, such as texture features, edge features, color distribution features, and semantic features.

[0111] After feature extraction is complete, the two sets of features can be compared and analyzed. When detecting whether image or icon assets are missing, indicators such as the clarity, resolution, and compression artifacts of the asset area can be identified to determine if there is a problem with missing assets. For example, if the asset area is displayed as blank, a cracked icon, or a placeholder, or if the actual rendered size of the image is 0, it is determined that the image or icon asset is missing or abnormal.

[0112] When detecting whether the proportion of blank areas exceeds a preset threshold for identifying empty spaces, the screenshot can be segmented to identify blank areas on the page, and the proportion of blank areas to the entire content display area or a specific module area can be calculated. If the proportion of blank areas exceeds the preset threshold for identifying empty spaces, it is determined to be an abnormal empty space issue. For example, the popular job posting section is expected to have a high content fill rate. If the proportion of blank areas in this section exceeds the preset threshold, it indicates that there may be a serious empty space problem in this section.

[0113] The image algorithm feature detection results are output based on the above detection dimensions. For example, the image algorithm feature detection results may include information such as the location and type of missing material, the proportion of blank areas, and the similarity score with the standard design draft.

[0114] S504: Based on the UI structure detection results, the large language model text detection results, and the image algorithm feature detection results, the image anomaly detection results are obtained.

[0115] The UI structure detection results, large language model text detection results, and image algorithm feature detection results are fused and summarized to obtain image-related anomaly detection results. During the fusion process, information involving the same page element or the same anomaly in different detection results can be correlated and aligned to avoid duplicate and contradictory reports.

[0116] Thus, UI structure detection can accurately identify structural voids such as missing container nodes, misaligned child elements, hidden elements, and empty content at the code structure level, overcoming the limitations of pure visual detection in addressing code-level issues. On the other hand, large language model text detection can identify text-related voids such as truncated or missing text at the semantic understanding level, overcoming the limitation of traditional OCR technology that can only recognize text content but not understand semantics. Furthermore, image algorithm feature comparison can quantitatively assess the differences between the page and the design draft at the visual presentation level, accurately identifying visual voids such as missing materials and excessive blank areas. Through this multi-dimensional fusion detection mechanism, various void anomalies in the visual presentation of dynamically configured pages can be comprehensively covered, effectively improving the comprehensiveness and accuracy of image-related void detection.

[0117] According to some embodiments of this application, optionally, S104: Based on the full-link operation logs and in accordance with the log-type pitfall detection rules, performing log-type anomaly detection on the dynamic configuration page to obtain the log-type anomaly detection result may include the following steps: According to the log-type pitfall detection rules, the entire chain operation log is analyzed step by step to detect whether there are execution abnormalities in at least one of the following links: data retrieval, interface call, resource loading, software development kit operation and page rendering, and to obtain the log-type anomaly detection results.

[0118] In some specific embodiments, the end-to-end runtime log may optionally include at least one of the following: data retrieval log, resource loading log, software development kit (SDK) runtime log, and page rendering log. The data retrieval log records information about the process of obtaining data from the data source, such as the amount of data retrieved, retrieval time, and retrieval result status. The resource loading log records information about the loading process of static resources required by the page, such as resource URLs, loading status, and loading time. The SMD runtime log records the runtime status information of various SDKs integrated into the page (such as event tracking SDK, push SDK, login SDK, etc.), such as SDK initialization status, method call results, and error codes. The page rendering log records information about the entire process of the page from receiving data to completing rendering, such as rendering start time, rendering completion time, and rendering exception information.

[0119] Figure 6This is a flowchart illustrating step S104 of the pit detection method for a dynamic configuration page provided in this application embodiment. Figure 6 As shown, S104: Detecting whether there is an execution exception in at least one of the following steps: data retrieval, interface call, resource loading, software development kit operation, and page rendering, may include the following steps: S601 to S604.

[0120] S601: Analyze the data recall log and check at least one of the following: whether the data recall quantity is zero, whether the data recall result is empty, or whether there is an error in the data recall process.

[0121] Specifically, the data recall log records information about the process of a page module requesting data from a data source, such as the type of data source being recalled, request parameters, the amount of data recalled, the recall result, the recall time, and error messages. In S601, the recalled data quantity field in the data recall log can be extracted to determine if its value is zero. If it is zero, it means no data items were recalled, resulting in no content being displayed in the corresponding module, creating a void. The recall result field can also be extracted to determine if its content is an empty object, empty array, or empty string. If it is empty, it means that although the data quantity is not zero, the actual data content is invalid. Error codes or exception stack traces in the data recall log can also be extracted to determine if there were any errors during the recall process, such as connection timeouts, unavailable data sources, or query syntax errors. If errors are present, it indicates that an abnormality occurred in the data recall process, affecting the normal retrieval of data.

[0122] S602: Analyze the resource loading log and check at least one of the following: whether the material resource corresponding to the content display area failed to load, whether the resource loading timed out, or whether the resource loading address is abnormal.

[0123] The resource loading log records information about the loading process of various material resources required for the page, such as resource type (e.g., images, icons, font files), resource URL address, loading status, loading time, and error codes. In S602, the loading status field in the resource loading log can be extracted to determine if the material resource failed to load. If the status code is 404, 500, or displays a failure status, it indicates that the resource failed to load successfully, resulting in blank areas or placeholders in the image area. The loading time field can also be extracted to determine if the resource loading exceeds a preset timeout threshold. If it times out, it may cause slow or failed resource loading, affecting content display. The resource URL address field can also be extracted to check if the address format is standardized, the domain name is valid, and the protocol is correct. If the resource address is abnormal, the resource cannot be loaded correctly. Based on the above detection results, anomaly detection results for the resource loading process are generated. These results can include a list of failed-loading resources, a list of timed-out resources, and / or a list of resources with abnormal addresses.

[0124] S603: Parse the software development kit (SDK) runtime logs and detect at least one of the following: whether the SSD starts abnormally, whether there are errors during runtime, or whether data parsing fails.

[0125] The SDK runtime log records the runtime status information of various SDKs integrated into the page, such as SDK name, version number, initialization status, method call results, returned data, error codes, and exception stacks. In S603, the initialization status field in the SDK runtime log can be extracted to determine if the SDK started successfully. If initialization fails or an error code is returned, it indicates an SDK startup exception, affecting the normal operation of functional modules that depend on this SDK. The method call results and error code fields in the SDK runtime log can also be extracted to determine if errors occurred during SDK operation. If errors exist, they affect data acquisition or function execution. The data parsing status field in the SDK runtime log can also be extracted to determine if the data returned by the SDK was successfully parsed. If parsing fails, the data cannot be used correctly, resulting in a pitfall. Based on the above detection results, anomaly detection results for the SDK runtime phase are generated. These results can include startup exception information, runtime error details, and / or reasons for data parsing failure.

[0126] S604: Analyze the page rendering log and check at least one of the following: whether the document object model tree node failed to render, whether the content display area was not rendered, or whether the rendering result is empty.

[0127] The page rendering log records the entire process of a page from receiving data to final rendering, including rendering start time, rendering completion time, rendering exception information, rendering completion status, and rendering result. In S604, rendering exception information can be extracted from the page rendering log to determine if there are any DOM node rendering failures, such as node creation failure, node mounting failure, or node style application failure. The rendering completion status field can also be extracted to determine if the content display area has been rendered. If the rendering process is incomplete or interrupted, some areas of the page will remain unrendered, resulting in blank spaces. The rendering result field can also be extracted to determine if the rendering result is empty, i.e., whether any actual content has been rendered onto the page. An empty rendering result indicates that the page failed to render any content correctly. Based on the above detection results, anomaly detection results for the page rendering process are generated. These results can include information such as rendering failure node information, identifiers of areas where rendering was incomplete, and / or the reasons for empty rendering results.

[0128] Thus, by analyzing logs from data retrieval, resource loading, SDK execution, and page rendering, potential execution anomalies in each stage can be accurately identified, covering the entire chain of failures from data acquisition to final presentation. This effectively prevents the omission of pitfalls caused by anomalies in a single stage. Furthermore, the detection results for each stage are independent yet complementary. For example, data retrieval anomalies may result in no data to render subsequently, resource loading failures may lead to blank image areas, SDK execution anomalies may cause functional modules to malfunction, and page rendering failures may result in content areas not displaying. Comprehensive detection of anomalies in these stages facilitates accurate root cause localization, helping operations personnel quickly determine the specific stage and root cause of the pitfall, thereby shortening the investigation and repair cycle.

[0129] According to some embodiments of this application, optionally, S105: Based on the data returned by the interface, and in accordance with the data-type void detection rules, perform data-type anomaly detection on the dynamic configuration page to obtain the data-type anomaly detection result, which may include the following steps: The API return data is validated according to the data anomaly detection rules. The checks include whether the returned data is empty, whether the data field is missing, and whether the business data corresponding to the content display area is invalid or blank. The results of the data anomaly detection are obtained.

[0130] The API returned data can be business data obtained from the server by various modules of the dynamically configured page via API interfaces, such as job list data corresponding to the popular job postings section, salary range data corresponding to the salary display area, or industry category data corresponding to the industry category section. In S105, the API returned data can be validated item by item according to the data-related void detection rules.

[0131] When checking if the data returned by the API is empty, the data body of the returned data can be extracted to determine if it is null, an empty object, an empty array, or an empty string. If the API returns empty data, it indicates that the data required by the module could not be obtained normally from the server, resulting in empty spaces in the corresponding content display area due to lack of data.

[0132] When detecting missing data fields, you can check the list of required fields defined in the data field missing detection rules to see if the API returned data contains these fields and whether their values ​​are valid. For example, for popular job postings, required fields may include job ID, job name, company name, salary range, and redirect link. If any of these required fields is missing or its value is empty, it is considered a data field missing anomaly, resulting in incomplete page display.

[0133] When checking whether the business data corresponding to the content display area is invalid or blank, a validity check can be performed on the business data. For example, check whether the job title contains garbled characters, special characters, or placeholder text; check whether the salary range is in a valid numeric format and within a reasonable range; check whether the company name is a null or undefined string; and / or check whether the image address is a valid URL format and points to an existing resource. If the business data corresponding to the content display area has any of the above invalid or blank conditions, it is determined to be invalid business data, resulting in the page displaying error messages or blank areas.

[0134] Therefore, by detecting whether the data returned by the interface is empty, problems at the data source level can be identified in a timely manner, such as no data returned by the server or data not being sent correctly. By detecting whether data fields are missing, problems at the data structure level can be identified, such as incomplete data structure returned by the interface or required fields not being filled. By detecting whether the business data is invalid or blank, problems at the data quality level can be identified, such as incomplete data cleaning or incorrect data format. Through the above multi-dimensional data void detection, void scenarios caused by various data problems can be comprehensively covered, which helps to quickly determine whether the void is caused by server-side data problems, interface protocol problems, or data quality problems, thereby shortening the investigation and repair cycle of void problems.

[0135] In some specific embodiments, optionally, returning empty data from the interface may include having zero data entries corresponding to the content display area.

[0136] Specifically, for list-type content display areas, such as the job list in a popular job posting section or the industry tag list in an industry category section, when checking if the API return data is empty, it can check if the number of data entries corresponding to the list-type content display area is zero. For example, if the length of the job list array in the API return data for the popular job posting section is 0, it means that there is no job data to display, and the section area will be empty. When detecting empty API return data, it not only checks whether the overall returned data is empty, but also checks whether the number of entries in the list-type data is zero, thus more accurately identifying the "empty pit" problem caused by insufficient data.

[0137] In some specific embodiments, optionally, missing data fields may include empty text fields in the content display area and / or missing image or material resource addresses.

[0138] When detecting missing data fields, check if the text fields within the content display area are empty and / or if image or resource URLs are missing. Missing text fields typically manifest as empty text content within the display area, such as an empty string for the job title field, null for the company name field, or a missing salary range field. These missing text fields will cause the corresponding text areas on the page to display as blank or placeholders. Missing image or resource URLs typically manifest as an empty string for the image field, a missing resource URL field, or an invalid link to the resource URL. These missing resource URLs will prevent the image or resource area from loading any content, displaying as a blank space, a broken image, or a placeholder icon.

[0139] Thus, by including zero data entries in the detection scope for empty data, we can effectively identify empty list modules caused by insufficient data, avoiding scenarios where insufficient data is overlooked by only judging the overall return value of the interface. On the other hand, including empty text fields and missing image or material resource addresses in the detection scope for missing fields allows us to accurately locate local page empty problems caused by specific missing fields, rather than simply reporting incomplete data. This helps to quickly locate the specific data fields and content areas that cause the empty problem, improving the accuracy of empty problem detection and the efficiency of root cause localization.

[0140] According to some embodiments of this application, optionally, S106: Based on the image anomaly detection results, log anomaly detection results, and data anomaly detection results, identify the pits in the dynamic configuration page and perform root cause localization, and generate a pit inspection report, which may include the following steps one and two.

[0141] Step 1: When the image anomaly detection result indicates that there is a visual blank in the content display area, the log anomaly detection result indicates that there is an execution anomaly in at least one link, and / or the data anomaly detection result indicates that the interface returned data is missing or empty, it is determined that there is a pit in the dynamic configuration page.

[0142] When image anomaly detection results indicate visual blank areas in the content display area, it can be determined that the content display area contains gaps. Visual blank areas can manifest in various forms, such as missing container nodes, misaligned child elements, abnormal element visibility, and empty content fill status found in UI structure detection; or text truncation and missing text found in large language model text detection; or missing materials and blank areas exceeding a preset threshold found in image algorithm feature detection. For example, if image anomaly detection results show that the blank area in the popular job postings floor area exceeds 20%, it is determined that the floor contains gaps.

[0143] When log-based anomaly detection results indicate that at least one step has an execution exception, it can also be determined that there is a vulnerability in the dynamic configuration page. For example, execution exceptions can manifest as zero data retrieval in the data retrieval stage, failed API calls, failed material loading in the resource loading stage, startup exceptions in the SDK running stage, and rendering failures in the page rendering stage. For instance, if the log-based anomaly detection results show that the popular job data API returns a status code of 500, it can be determined that an API exception has caused a vulnerability in the relevant module.

[0144] When data anomaly detection results indicate that the interface returns missing or empty data, it can also be determined that there is a gap in the dynamic configuration page. Missing or empty data can manifest as the interface returning completely empty data, zero data entries, missing data fields, invalid business data, etc. For example, if the data anomaly detection results show that the number of data entries in the job list for the popular job section is zero, then it is determined that there is a gap in that section due to empty data.

[0145] The three judgment conditions mentioned above can be triggered independently; that is, as long as any one of them is met, it can be determined that a void exists in the dynamic configuration page. The three judgment conditions can also be used in combination; when multiple conditions are met simultaneously, a void is determined to exist in the dynamic configuration page, thus making the judgment result more accurate. Through the above comprehensive judgment logic, the existence of voids can be identified from three dimensions: visual presentation, operational status, and data content.

[0146] Step 2: Conduct a comprehensive analysis of the results of various anomaly detections to determine the root cause of the page pit.

[0147] After determining that a void exists, further correlation analysis and causal reasoning can be performed on the detection results of image anomalies, log anomalies, and data anomalies to determine the root cause of the void.

[0148] During correlation analysis, anomalies detected by different detection dimensions can be spatiotemporally aligned to determine whether they occurred within the same page module, the same operation step, or the same time window. For example, if image anomaly detection finds that the popular job posting section is blank, log anomaly detection finds an anomaly in the data interface call log corresponding to that section, and data anomaly detection finds that the interface returned empty data, then these three anomalies can be associated with the same page module and the same point in time.

[0149] In causal reasoning, pre-defined anomaly association rules can be used to analyze the causal relationships between different anomalies. These rules can be pre-built based on business logic and historical failure experience. For example, empty API return data can lead to log-related anomalies (such as zero data recall) and image-related anomalies (such as blank content display areas). Log-related anomalies (such as resource loading failure) can lead to image-related anomalies (such as missing image materials). By matching the actual detected anomalies with these association rules, it can be determined which anomalies are causes and which are effects, thereby tracing the root cause of the pitfall.

[0150] For example, during an inspection task, image anomaly detection revealed that the popular job posting section was blank. Log anomaly detection showed that the API interface for retrieving popular job posting data returned a 200 status code but no data. The API response time was normal, with no error messages. Data anomaly detection confirmed that the API returned an empty data list. Through correlation analysis, these three anomalies were linked to the popular job posting section module. Causal reasoning determined that the empty data list was the cause of the data anomaly, the blank posting section in the image anomaly was the effect, and the normal API response in the log anomaly ruled out network and server-side anomalies. Ultimately, the root cause of the empty section was determined to be the lack of data return from the data source, meaning the recommendation engine service did not return valid data.

[0151] For example, during an inspection task, image anomaly detection revealed that a certain ad slot was blank. Log anomaly detection showed that the image resource failed to load in the resource loading log for that ad slot. Data anomaly detection confirmed that the image address field returned by the interface was normal, but the resource corresponding to that address did not exist. Through causal reasoning, the log anomaly indicating the resource loading failure was the cause, the blank ad slot in the image anomaly was the effect, and the normal image address in the data anomaly ruled out interface data errors. Ultimately, the root cause of the void was determined to be that the image resource was missing or had been deleted on the Content Delivery Network (CDN).

[0152] Based on the void detection results and root cause localization results, a void inspection report can be generated, which includes the void location, void type, root cause analysis conclusion, abnormal link nodes and / or repair suggestions, so that operation and maintenance personnel can quickly locate and repair void problems.

[0153] Thus, by comprehensively analyzing the results of image, log, and data anomalies for void detection, the existence of voids can be cross-verified from multiple dimensions, including visual presentation, operational status, and data content. This effectively avoids misjudgments or omissions that may occur with a single detection method, improving the accuracy and reliability of void identification. Furthermore, by performing correlation analysis and causal reasoning on multiple anomaly detection results, the inherent relationships between different anomalies can be uncovered, accurately pinpointing the root cause of voids, such as no data source response, resource loading failure, or rendering anomalies, rather than simply focusing on the void phenomenon itself. This helps operations and maintenance personnel quickly understand the root cause of void problems and directly address it without spending a lot of time manually troubleshooting, thereby shortening the void problem repair cycle and improving the operational efficiency and user experience of dynamic configuration pages.

[0154] Based on the same technical concept as the pit detection method for dynamic configuration pages provided in the above embodiments, this application also provides a pit detection platform for dynamic configuration pages. This pit detection platform for dynamic configuration pages can execute the pit detection method for dynamic configuration pages provided in any of the above embodiments.

[0155] Figure 7 This is a structural block diagram of a pit detection platform with a dynamically configured page provided in an embodiment of this application. Figure 7 As shown, the pit detection platform 70 with a dynamic configuration page provided in this application embodiment may include: The execution planning intelligent agent 701 is used to generate a set of executable operation instructions for the equipment based on the inspection object and inspection operation steps, and send them to the target inspection equipment. It also collects screenshots of the dynamic configuration page, the document object model tree structure, interface return data, and full-link operation logs during the inspection process. The detection rule generation intelligent agent 702 is used to generate dynamic configuration page void detection rules adapted to the target inspection equipment. The void detection rules include image-based void detection rules, log-based void detection rules, and data-based void detection rules. The algorithm detection module 703 is used to perform image anomaly detection on the dynamic configuration page based on screenshots and the document object model tree structure, and according to image anomaly detection rules, to obtain image anomaly detection results; based on the full-link operation logs, and according to log anomaly detection rules, to perform log anomaly detection results; based on the interface returned data, and according to data anomaly detection rules, to perform data anomaly detection results; based on the image anomaly detection results, log anomaly detection results, and data anomaly detection results, to identify anomalies in the dynamic configuration page, perform root cause localization, and generate an anomaly inspection report.

[0156] The specific implementation methods of the aforementioned intelligent agents and modules have been described in detail above and will not be repeated here.

[0157] The embodiment of this application provides a void detection platform for a dynamic configuration page. On the one hand, it utilizes an execution planning agent to generate a set of executable operation instructions for the device based on the inspection object and operation steps, and sends them to the target inspection device. On the other hand, it combines a detection rule generation agent to adapt and generate void detection rules that match the target inspection device. This can adapt to the differences in rendering mechanisms and display parameters of different terminal devices, effectively solving the problems of incomplete coverage and easy missed detection and false detection in existing detection solutions in multi-terminal scenarios. At the same time, it replaces manual inspection, improves the efficiency of void detection, and can efficiently cope with the void inspection needs in massive configuration scenarios. It ensures the flexibility and real-time performance of the dynamic configuration page and reduces the negative impact of void problems on the page's visual effects and user experience.

[0158] On the other hand, by collecting screenshots of the dynamic configuration page, the DOM tree structure, API return data, and end-to-end operation logs, and performing void anomaly detection according to image, log, and data detection rules respectively, this overcomes the limitations of existing technologies that can only detect voids in a single stage or of a single type. It achieves integrated verification of page rendering effects, underlying data interaction, and end-to-end operational status, enabling more comprehensive capture of void anomalies caused by each stage, such as blank areas, missing modules, unfilled placeholders, and image loading failures, thus improving the comprehensiveness and accuracy of void anomaly detection. Furthermore, while identifying void anomalies, root cause localization is performed based on the image, log, and data anomaly detection results, and a void inspection report is generated. This helps operations and maintenance personnel directly locate the root cause of voids based on the void inspection report, reducing manual troubleshooting time and thus shortening the void problem repair cycle and improving operations and maintenance response speed.

[0159] It should be noted that the pit detection platform for the dynamic configuration page provided in this application has the same or corresponding technical features as the pit detection method for the dynamic configuration page provided in any of the above embodiments, and produces the same technical effect. For the sake of brevity, it will not be elaborated further here.

[0160] Based on the same technical concept as the pit detection method for the dynamic configuration page provided in the above embodiments, this application also provides an electronic device.

[0161] The electronic device in this application embodiment may be a user terminal device, a server, other computing devices, or a cloud server. Figure 8This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. The electronic device may include a processor 801 and a memory 802 storing computer program instructions. When the processor 801 executes the computer program instructions, it implements the process or function of any of the methods described above.

[0162] Specifically, processor 801 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. Memory 802 may include mass storage for data or instructions. For example, memory 802 may be at least one of the following: hard disk drive (HDD), read-only memory (ROM), random access memory (RAM), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, universal serial bus (USB) drive, or other physical / tangible memory storage device. Alternatively, memory 802 may include removable or non-removable (or fixed) media. Furthermore, memory 802 may be internal or external to the integrated gateway disaster recovery device. Memory 802 may be non-volatile solid-state memory. In other words, typically memory 802 includes a tangible (non-transitory) computer-readable storage medium (such as a memory device) encoded with computer-executable instructions, and when the software is executed (e.g., by one or more processors), it can perform the operations described in the methods of the embodiments of this application. The processor 801 implements the process or function of any of the methods described in the above embodiments by reading and executing computer program instructions stored in the memory 802.

[0163] In one example Figure 8The illustrated electronic device may also include a communication interface 803 and a bus 810. The processor 801, memory 802, and communication interface 803 are connected via bus 810 and communicate with each other. Communication interface 803 is primarily used to enable communication between modules, devices, units, and / or equipment in the embodiments of this application. Bus 810 may include hardware, software, or both, and can couple components of the online data traffic billing device together. For example, the bus may include at least one of the following: Accelerated Graphics Port (AGP) or other graphics bus, Enhanced Industry Standard Architecture (EISA) bus, Front Side Bus (FSB), HyperTransport (HT) Interconnect, Industry Standard Architecture (ISA) bus, Infinite Bandwidth Interconnect, Low Pin Count (LPC) bus, memory bus, Microchannel Architecture (MCA) bus, Peripheral Component Interconnect (PCI) bus, PCI-Express (PCI-X) bus, Serial Advanced Technology Attachment (SATA) bus, Video Electronics Standards Association Local (VLB) bus, or other suitable buses. Bus 810 may include one or more buses. Although specific buses are described or illustrated in the embodiments of this application, any suitable bus or interconnection method may be considered in the embodiments of this application.

[0164] In conjunction with the methods in the above embodiments, this application also provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the process or function of any of the methods in the above embodiments.

[0165] In addition, this application also provides a computer program product that stores computer program instructions, which, when executed by a processor, implement the process or function of any of the methods described above.

[0166] The flowcharts and / or block diagrams of methods, apparatuses, systems, and computer program products according to embodiments of this application have been exemplarily described above, and related aspects have been described. It should be understood that each block or combination thereof in the flowcharts and / or block diagrams may be implemented by computer program instructions, by dedicated hardware performing a specified function or action, or by a combination of dedicated hardware and computer instructions. For example, these computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to form a machine that enables the implementation of the function / action specified in each block or combination thereof in the flowcharts and / or block diagrams, executable via such processor. Such a processor may be a general-purpose processor, a dedicated processor, a special-purpose application processor, or a field-programmable logic circuit.

[0167] The functional blocks shown in the structural block diagrams of this application can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc.; when implemented in software, they are programs or code segments used to perform the required tasks. Programs or code segments can be stored in memory or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. Code segments can be downloaded via computer networks such as the Internet or intranets.

[0168] It should be noted that this application is not limited to the specific configurations and processes described above or shown in the figures. The above descriptions are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the described systems, devices, modules, or units can be referred to the corresponding processes in the method embodiments, and need not be repeated here. It should be understood that the scope of protection of this application is not limited thereto. Any person skilled in the art can conceive of various equivalent modifications or substitutions within the scope of the technology disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application.

Claims

1. A method for detecting pitfalls in a dynamically configured page, characterized in that, include: By executing the planning agent, the system generates a set of executable operation instructions for the equipment based on the inspection object and the inspection operation steps, and sends them to the target inspection equipment. It also collects screenshots of the dynamic configuration page, the document object model tree structure, the interface return data, and the full-link operation log during the inspection process. The detection rule generation agent generates dynamic configuration page void detection rules adapted to the target inspection equipment by generating a void detection rule. The void detection rule includes image-based void detection rule, log-based void detection rule, and data-based void detection rule. Based on the screenshot and document object model tree structure, and in accordance with the image-type void detection rules, image-type anomaly detection is performed on the dynamic configuration page to obtain the image-type anomaly detection results; Based on the full-link operation logs and in accordance with the log-type pitfall detection rules, log-type anomaly detection is performed on the dynamic configuration page to obtain the log-type anomaly detection results; Based on the data returned by the interface, and in accordance with the data-related void detection rules, data-related anomaly detection is performed on the dynamic configuration page to obtain the data-related anomaly detection results; Based on the image anomaly detection results, log anomaly detection results, and data anomaly detection results, identify the pitfalls in the dynamic configuration page, locate the root cause, and generate a pitfall inspection report.

2. The method according to claim 1, characterized in that, By executing the planning agent, a set of executable operation instructions for the equipment is generated based on the inspection object and inspection operation steps, and then sent to the target inspection equipment, including: The screenshot of the dynamically configured page is identified by an image recognition algorithm to obtain the screenshot recognition result, which includes the current page type, the position of interface elements and operation node information. By combining the inspection object, inspection operation steps, and the screenshot recognition results, an operation instruction set is generated and sent to the target inspection equipment; wherein, the operation instruction set includes operation type, operation coordinates, and execution order.

3. The method according to claim 2, characterized in that, The set of operating instructions is sent to the target inspection equipment, including: The execution planning agent performs cross-device and / or cross-environment adaptation processing on the generated operation instruction set based on the inspection equipment information, and then sends the adapted operation instruction set to the target inspection equipment, so that the operation instruction set can be adapted to different inspection equipment and / or different inspection environments. The inspection equipment information includes the type, system version, resolution, and inspection environment identifier of the target inspection equipment; cross-device adaptation processing includes: matching the operation logic corresponding to the target inspection equipment according to the type and system version of the target inspection equipment; adjusting the operation coordinates and action execution parameters in the operation instruction set according to the resolution of the target inspection equipment; cross-environment adaptation processing includes: loading the application running configuration of the corresponding inspection environment according to the inspection environment identifier.

4. The method according to claim 1, characterized in that, The detection rule generation agent generates a dynamic configuration page for the target inspection equipment, including pit detection rules, which are adapted to the target inspection equipment. Based on the screenshots of the dynamic configuration page, the inspection operation steps, and the document object model tree structure, multi-dimensional feature vectors are extracted. The multi-dimensional feature vectors include the visual features of the screenshots, the process features of the inspection operation, and the hierarchical features of the document object model tree structure. Select target pit verification point templates that match multi-dimensional feature vectors from the vector knowledge base; Based on multi-dimensional feature vectors and inspection equipment information, prompt words are constructed; The constructed prompt words and target void verification point template are input into the detection rule big language model, and the target inspection equipment's dynamic configuration page void detection rules are generated through the detection rule big language model.

5. The method according to claim 1, characterized in that, The image anomaly detection, log anomaly detection, and data anomaly detection are executed in parallel and independently, and the results of the various anomaly detections complement each other.

6. The method according to claim 1, characterized in that, Based on the screenshot and document object model tree structure, and according to the image-related pitfall detection rules, image-related anomaly detection is performed on the dynamic configuration page to obtain the image-related anomaly detection results, including: The document object model tree structure is parsed for nodes, hierarchical relationships, and attributes. The system detects whether there are missing container nodes, whether the arrangement of child elements within the container nodes is misaligned, whether the element visibility attribute of the container nodes is abnormal, whether the content filling state of the container nodes is empty, and whether the size of the container nodes meets at least one of the preset standards, and obtains the UI structure detection results. Extract the text information from the screenshot and input the text information into the large language model. The large language model detects at least one of the following: whether the text in the content display area is truncated or missing, and whether the text filling amount meets the preset threshold. The text detection result of the large language model is obtained. The visual features of the screenshot are compared with the visual features of the standard design draft to detect whether the image or icon material in the content display area is missing, and whether the proportion of blank area in the content display area exceeds the preset void judgment threshold, so as to obtain the image algorithm feature detection result. Based on the UI structure detection results, the large language model text detection results, and the image algorithm feature detection results, the image anomaly detection results are obtained.

7. The method according to claim 1, characterized in that, Based on the end-to-end runtime logs and in accordance with log-related pitfall detection rules, log-related anomaly detection is performed on the dynamic configuration page, and the log-related anomaly detection results are obtained, including: According to the log-type pitfall detection rules, the entire chain operation log is analyzed step by step to detect whether there are execution abnormalities in at least one of the following links: data retrieval, interface call, resource loading, software development kit operation and page rendering, and to obtain the log-type anomaly detection results.

8. The method according to claim 7, characterized in that, The end-to-end operation log includes at least one of the following: data retrieval log, resource loading log, software development kit operation log, and page rendering log. The system detects whether there are any execution anomalies in at least one of the following stages: data retrieval, API calls, resource loading, software development kit (SDK) operation, and page rendering. Analyze the data recall logs to check if the data recall quantity is zero, if the data recall result is empty, or if there are any errors in the data recall process; Analyze the resource loading logs and check at least one of the following: whether the material resources corresponding to the content display area failed to load, whether the resource loading timed out, or whether the resource loading address is abnormal. Analyze the software development kit (SDK) runtime logs to detect at least one of the following: abnormal startup, error during runtime, or data parsing failure. The page rendering log is parsed to check at least one of the following: whether the document object model tree node failed to render, whether the content display area was not rendered, or whether the rendering result is empty.

9. The method according to claim 1, characterized in that, Based on the data returned by the API, and in accordance with the data-related vulnerability detection rules, data-related anomaly detection is performed on the dynamic configuration page to obtain the data-related anomaly detection results, including: The API return data is validated according to the data anomaly detection rules. The checks include whether the returned data is empty, whether the data field is missing, and whether the business data corresponding to the content display area is invalid or blank. The results of the data anomaly detection are obtained.

10. The method according to claim 9, characterized in that, The absence of data returned by the interface includes zero data entries corresponding to the content display area; the absence of data fields includes empty text fields within the content display area and / or missing image or material resource addresses.

11. The method according to claim 1, characterized in that, Based on the image anomaly detection results, log anomaly detection results, and data anomaly detection results, vulnerabilities in the dynamic configuration page are identified and root cause analysis is performed. A vulnerability inspection report is then generated, including: When the image anomaly detection result indicates that there is a visual blank in the content display area, the log anomaly detection result indicates that at least one link has an execution anomaly, and / or the data anomaly detection result indicates that the interface returned data is missing or empty, it is determined that there is a pit in the dynamic configuration page. By comprehensively analyzing the results of various anomaly detections, the root cause of the page pits can be determined.

12. A pit detection platform with dynamically configured pages, characterized in that, include: The execution planning intelligent agent is used to generate a set of executable operation instructions for the equipment based on the inspection object and inspection operation steps, and send them to the target inspection equipment. It also collects screenshots of the dynamic configuration page, the document object model tree structure, interface return data, and full-link operation logs during the inspection process. A detection rule generation intelligent agent is used to generate dynamic configuration page void detection rules adapted to the target inspection equipment. The void detection rules include image-based void detection rules, log-based void detection rules, and data-based void detection rules. The algorithm detection module is used to perform image anomaly detection on the dynamic configuration page based on the screenshot and document object model tree structure and according to the image anomaly detection rules, and obtain the image anomaly detection results. Based on the full-link operation logs and in accordance with the log-type pitfall detection rules, log-type anomaly detection is performed on the dynamic configuration page to obtain the log-type anomaly detection results; Based on the data returned by the interface, and in accordance with the data-related void detection rules, data-related anomaly detection is performed on the dynamic configuration page to obtain the data-related anomaly detection results; Based on the image anomaly detection results, log anomaly detection results, and data anomaly detection results, identify the pitfalls in the dynamic configuration page, locate the root cause, and generate a pitfall inspection report.

13. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing computer program instructions; when the electronic device executes the computer program instructions, it implements the pit detection method for dynamically configured pages as described in any one of claims 1-11.

14. A computer program product, characterized in that, It includes computer program instructions that, when executed by a processor, implement the pit detection method for dynamically configured pages as described in any one of claims 1-11.

Images