Page coverage detection method and device, electronic equipment, medium and product

Abstract

This application discloses a page coverage detection method, apparatus, electronic device, medium, and product. The method includes: during testing of a page to be evaluated through a development platform, when the rendering engine of the development platform reaches a critical node, acquiring multi-dimensional coverage detection data of the page to be evaluated; preprocessing the multi-dimensional coverage detection data to obtain preprocessed data; calculating the coverage result based on the preprocessed data; and outputting the coverage result. This method can solve the problem that existing technologies cannot quantitatively evaluate the coverage of multiple dimensions in a page.

Description

Technical Field

[0001] This application relates to the field of testing technology, specifically to a page coverage detection method, apparatus, electronic device, readable storage medium, and computer program product. Background Technology

[0002] With the acceleration of digital transformation, code platforms, as an important tool for application development, have been widely used by enterprises and organizations.

[0003] Currently, existing code platforms typically use static analysis tools based on code instrumentation to statistically analyze code execution. However, this method can only perform instrumentation analysis at the code level and cannot quantitatively evaluate the coverage across multiple dimensions of the page. Summary of the Invention

[0004] In view of the above problems, this application provides a page coverage detection method, apparatus, electronic device, readable storage medium and computer program product, which can solve the problem that the prior art cannot quantitatively evaluate the coverage of multiple dimensions in a page.

[0005] Firstly, this application provides a page coverage detection method, including: During the testing of the page to be evaluated through the development platform, when the rendering engine of the development platform reaches a key node, it acquires the multidimensional coverage detection data of the page to be evaluated. The multidimensional coverage detection data is preprocessed to obtain preprocessed data; The coverage result is calculated based on the preprocessed data and then output.

[0006] In the above technical solution, the method can achieve a comprehensive quantitative evaluation of page coverage by acquiring multi-dimensional detection data and performing preprocessing calculations at key test nodes, thereby helping testers to more accurately grasp the degree of test coverage and improve the integrity and effectiveness of page testing.

[0007] In some embodiments, the method further includes: Before testing the page to be evaluated through the development platform, configure one-to-one data collection strategies for multiple key nodes of the rendering engine in the development platform; The key nodes include at least component rendering nodes, event triggering nodes, interface request nodes, and form item change nodes.

[0008] In the above technical solution, this method can accurately capture multi-dimensional detection data such as component rendering, event triggering, interface requests, and form item changes by configuring dedicated data collection strategies for key nodes of the rendering engine in advance. This lays a data foundation for subsequent comprehensive quantitative evaluation of page coverage, making coverage detection more targeted and complete.

[0009] In some implementations, obtaining the multidimensional coverage detection data of the page to be evaluated includes: Based on the data acquisition strategy corresponding to the key nodes, multidimensional coverage detection data is obtained; The multidimensional coverage detection data includes component rendering detection data, event triggering detection data, interface request detection data, and form change detection data.

[0010] In the above technical solution, the method can accurately obtain multi-dimensional detection data such as component rendering, event triggering, interface requests, and form changes based on the data collection strategy of key nodes, thereby realizing a multi-dimensional quantitative evaluation of page coverage and making coverage detection more comprehensive and more in line with actual testing scenarios.

[0011] In some implementations, acquiring multidimensional coverage detection data according to the data acquisition strategy corresponding to the key node includes: When the key node is a component rendering node, according to the data acquisition strategy corresponding to the component rendering node, pre-rendering component data is acquired before component rendering, and post-rendering component data is acquired after component rendering is completed; wherein, the component rendering detection data includes the pre-rendering component data and the post-rendering component data; When the key node is an event triggering node, the event binding stage data and the event execution stage data are obtained according to the data collection strategy corresponding to the event triggering node; wherein, the event triggering detection data includes the event binding stage data and the event execution stage data; When the key node is an interface request node, according to the data collection strategy corresponding to the interface request node, interface information is obtained during the interface configuration parsing phase, and interface request data is obtained after the interface request is triggered; wherein, the interface request detection data includes the interface information and the interface request data, and the interface request data includes the request address, request parameters, request time and associated components; When the key node is a form item change node, the form component initialization data is obtained according to the data collection strategy corresponding to the form item change node, and a value change event is detected when the form change is executed. The form input data is obtained according to the value change event and the form component initialization data. The form change detection data includes the form component initialization data and the form input data.

[0012] In the above technical solution, the method can accurately capture the full-process detection data of each node for different key nodes such as component rendering, event triggering, interface request, and form item change, and refine the granularity of data collection in each dimension to ensure the comprehensiveness and accuracy of multi-dimensional coverage detection data.

[0013] In some implementations, the preprocessing of the multidimensional coverage detection data to obtain preprocessed data includes: The multidimensional coverage detection data is standardized to obtain standardized data; Key fields are extracted from the standardized data to obtain key field data; The association data is deduplicated to obtain deduplicated data; Based on the deduplication data, establish association data including the relationships between components, events, interfaces, and form items; The associated data is subjected to time window-based data splicing to obtain preprocessed data.

[0014] In the above technical solution, the method can perform a complete preprocessing process of standardization, key field extraction, deduplication, relationship establishment and time window splicing, and standardize and optimize the multidimensional coverage detection data, eliminate redundant data, clarify the relationship between data in each dimension, and obtain standardized, complete and relevant preprocessed data.

[0015] In some implementations, calculating the coverage result based on the preprocessed data includes: Based on the preprocessed data, multiple components in the page to be evaluated and associated items corresponding to each component are determined; wherein, the associated items include associated events and associated interfaces; Based on the preprocessed data and the associated items corresponding to each component, the multidimensional coverage of each component is calculated; wherein, the multidimensional coverage includes component rendering coverage, event execution coverage, interface request coverage, and form item change coverage; Calculate component runtime coverage and page runtime coverage based on the multidimensional coverage; The coverage results include the component runtime coverage and the page runtime coverage.

[0016] In the above technical solution, the method can decompose the page structure from the dimensions of components, related events and related interfaces based on preprocessed data, accurately calculate the coverage of multiple dimensions such as component rendering, event execution, interface requests and form item changes, and then summarize the component running coverage and page running coverage to achieve a layered and quantitative evaluation of page coverage, so that testers can clearly grasp the test completeness of each level of the page.

[0017] In some implementations, calculating the multidimensional coverage of each component based on the preprocessed data and the associated items corresponding to each component includes: The rendering status and form input status of each component are determined based on the preprocessed data; wherein, the rendering status is whether the component has been rendered or not, and the form input status includes whether the component is a form component and whether the input has changed; The component rendering coverage rate of each component is determined based on the rendering status, and the form item change coverage rate of each component is determined based on the form input status. Based on the preprocessed data, obtain the associated item data for each component's corresponding associated item; wherein, the associated item data includes associated event data and associated interface data; The event execution coverage and interface request coverage of each component are calculated based on the associated item data of the associated items corresponding to each component.

[0018] In the above technical solution, the method can accurately calculate the component rendering coverage and form item change coverage by clearly defining the judgment criteria for component rendering and form input. At the same time, it can extract related item data based on preprocessed data, scientifically quantify the event execution coverage and interface request coverage, and realize the fine calculation of multi-dimensional coverage for each component, making the coverage results more targeted and accurate.

[0019] In some implementations, calculating component runtime coverage and page runtime coverage based on the multidimensional coverage includes: The component rendering coverage, event execution coverage, interface request coverage, and form item change coverage of each component are averaged to obtain the component runtime coverage of each component. The average component runtime coverage of all components is calculated to obtain the page runtime coverage.

[0020] In the above technical solution, the method can integrate the coverage of each dimension of the component into the component running coverage by means of the average calculation, and then summarize the running coverage of all components to obtain the page running coverage, so as to realize the layered quantitative evaluation from the component to the page, thereby clearly presenting the test completeness of the entire page while clarifying the running coverage of individual components.

[0021] Secondly, this application provides a page coverage detection device, comprising: The acquisition unit is used to acquire multidimensional coverage detection data of the page to be evaluated when the rendering engine of the development platform reaches a key node during the testing process of the page to be evaluated through the development platform. The preprocessing unit is used to preprocess the multidimensional coverage detection data to obtain preprocessed data; A calculation unit is used to calculate the coverage result based on the preprocessed data; The display unit is used to output the coverage results.

[0022] In the above technical solution, the device can acquire multi-dimensional detection data at key test nodes and perform preprocessing calculations to achieve a comprehensive quantitative evaluation of page coverage, thereby helping testers to more accurately grasp the test coverage and improve the integrity and effectiveness of page testing.

[0023] Thirdly, this application provides an electronic device, the electronic device including a memory and a processor, the memory for storing a computer program, the processor running the computer program to cause the electronic device to perform the page coverage detection method described in any one of the first aspects.

[0024] Fourthly, this application provides a readable storage medium storing a computer program, which, when executed by a processor, performs the page coverage detection method described in any one of the first aspects.

[0025] Fifthly, this application provides a computer program product, which includes a computer program that, when executed by a processor, performs the page coverage detection method described in any one of the first aspects.

[0026] The beneficial effects of this application are as follows: By constructing a complete page coverage detection system, it achieves multi-dimensional, refined, and quantifiable evaluation of page test coverage, effectively overcoming the shortcomings of traditional detection methods that cannot comprehensively quantify page coverage. This enables precise identification of testing blind spots and missed scenarios, and provides clear target guidance and optimization directions for testing work. Simultaneously, its lightweight design ensures low performance impact during the detection process and allows it to adapt to complex scenario testing needs. Furthermore, the deep integration of coverage data with the development and testing processes to form a closed-loop workflow supports historical data traceability and analysis, thereby effectively improving the completeness, accuracy, and delivery quality of page testing. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a flowchart illustrating the page coverage detection method in some embodiments of this application; Figure 2 This is a schematic diagram illustrating the definition and usage of four-dimensional coverage in some embodiments of this application; Figure 3 This is a schematic diagram of a data capture mechanism based on rendering engine hooks in some embodiments of this application; Figure 4 This is a timing diagram of data processing in the coverage cleaning service in some embodiments of this application; Figure 5 This is a schematic diagram of the visual coverage results in some embodiments of this application; Figure 6 This is a system architecture diagram of the page coverage detection method in some embodiments of this application; Figure 7 This is a schematic diagram of the structure of the page coverage detection device in some embodiments of this application; Figure 8 This is a schematic diagram of the structure of an electronic device in some embodiments of this application. Detailed Implementation

[0029] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0030] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0031] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more (including two), similarly, "multiple sets" refers to two or more sets (including two sets), and "multiple pieces" refers to two or more pieces (including two pieces) unless otherwise explicitly defined.

[0032] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0033] In the description of the embodiments in this application, the term "and / or" 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 document generally indicates that the preceding and following related objects have an "or" relationship.

[0034] In existing technologies, page coverage detection can only record the execution path of test scripts, and cannot quantitatively evaluate the multi-dimensional coverage of pages. Furthermore, it lacks a refined and quantifiable evaluation system, making it difficult to accurately locate test blind spots and clarify test optimization directions.

[0035] To address the aforementioned technical issues, this application provides a page coverage detection method. This method can capture multi-dimensional coverage detection data of key nodes in the rendering engine during the development platform testing process, and after preprocessing such as standardization, deduplication, and relationship establishment, calculate and output coverage results including component running coverage and page running coverage, thereby achieving a multi-dimensional, refined, and quantifiable evaluation of page test coverage.

[0036] like Figure 1 As shown, some embodiments of this application provide a page coverage detection method, which includes: S100 Configure one-to-one data acquisition strategies for multiple key nodes of the rendering engine in the development platform; among which, key nodes include at least component rendering nodes, event triggering nodes, interface request nodes, and form item change nodes.

[0037] In this embodiment, the data acquisition strategy is the hook function, which is one of the core protection points of this application. Due to the characteristics of low-code platforms, page rendering almost always involves feeding the saved schema (JSON schema) to the low-code platform's component rendering engine. Therefore, this application makes minor modifications to the component rendering engine by adding hook functions at key execution nodes.

[0038] Implementing this method enables non-intrusive data capture by embedding hooks at key nodes of the rendering engine. This allows for adaptation to the detection needs of low-code platform configurable pages without modifying page configurations, thus solving the problem that traditional code coverage tools cannot be applied to low-code platforms, while also laying the foundation for multi-dimensional data collection.

[0039] S200. During the testing of the page to be evaluated through the development platform, when the rendering engine of the development platform reaches a critical node, it obtains the multi-dimensional coverage detection data of the page to be evaluated.

[0040] In this embodiment, the development platform can be a low-code development platform. This platform is driven by Schema (JSONSchema) configuration as its core, and uses a rendering engine to parse the configuration and render page components. Therefore, it should be understood that this platform differs from traditional code development platforms.

[0041] In this embodiment, the low-code platform's rendering engine is responsible for parsing the schema configuration and rendering page components, and also triggers coverage detection events at the aforementioned key nodes. The coverage SDK can be embedded in this rendering engine, specifically responsible for collecting and reporting coverage data.

[0042] In this embodiment, based on the cooperation between the rendering engine and the SDK, this method can trigger data collection by relying on rendering engine hooks to capture multi-dimensional detection data during page runtime in real time. While adapting to the architectural characteristics of low-code platform schema-configurable rendering, it can also identify and statistically analyze the coverage of configurable components, events, and interfaces. It is easy to understand that this data collection method is the core manifestation of the four-dimensional data capture based on rendering engine hooks in this application.

[0043] As an optional implementation method, multidimensional coverage detection data of the page to be evaluated is obtained, including: Based on the data acquisition strategy corresponding to the key nodes, obtain multi-dimensional coverage detection data; The multidimensional coverage detection data includes component rendering detection data, event triggering detection data, interface request detection data, and form change detection data.

[0044] In this embodiment, unified collection of data across four dimensions—component rendering, event execution, interface requests, and form item changes—is achieved, covering core page testing scenarios and thus overcoming the shortcomings of existing testing tools that only focus on functionality and lack multi-dimensional coverage statistics.

[0045] In this embodiment, the complementarity of the four dimensions can uncover testing blind spots that cannot be found by a single dimension, as well as problems such as untested dynamically hidden components, components that are displayed but not operated, missed interface tests, and missing form inputs.

[0046] In this embodiment, for the conditional rendering component, it is only recorded as covered when the display conditions are met and actual rendering is performed, thus correctly handling the coverage status of complex scenes.

[0047] Please refer to Figure 2 , Figure 2 This document illustrates the definition and usage of a four-dimensional coverage method.

[0048] S300: Preprocess the multidimensional coverage detection data to obtain preprocessed data.

[0049] In this embodiment, the preprocessing process can be flexibly adjusted according to the actual detection scenario, data type and detection requirements, and is not limited to a fixed processing order and a single processing method. Its core purpose is to standardize and optimize the collected multidimensional coverage detection data, remove invalid information, unify data standards, and sort out data correlations, so as to provide reliable data support for the accurate calculation of subsequent coverage results.

[0050] For example, preprocessing can include, but is not limited to, one or more processing operations such as data standardization, key field extraction, deduplication of duplicate data, establishment of multi-dimensional data association, data concatenation, data compression, and abnormal data filtering. Furthermore, depending on the architecture characteristics, data volume, and actual application needs of the low-code platform, a suitable preprocessing method can be flexibly selected without strictly following a fixed process. This allows for meeting the needs of rapid data processing in simple scenarios while adapting to the needs of multi-dimensional data integration in complex scenarios.

[0051] In this embodiment, the method can perform standardization, deduplication, association establishment, and time window splicing on the original detection data, thereby eliminating redundant information, standardizing data format, clarifying the relationship between data in various dimensions, and thus ensuring the accuracy and efficiency of subsequent calculations.

[0052] In this embodiment, the method employs a lightweight SDK for data deduplication, compression, and batch reporting, minimizing the impact on page performance while being adaptable to testing and preview environments. Furthermore, this method can also be used in a sampling manner in a production environment. This is the core of the lightweight SDK data reporting mechanism in this application.

[0053] In this embodiment, the application also provides a coverage cleaning service, which can verify and clean the raw data reported by the SDK, remove invalid data, duplicate data and abnormal data, and standardize the data format; at the same time, the service can also perform data assembly, data integration and data persistence, thereby supporting the query and analysis of historical data, coverage trend analysis and cumulative statistics of multiple rounds of test data.

[0054] S400: Calculate the coverage result based on the preprocessed data and output the coverage result.

[0055] In this embodiment, the coverage results can be displayed in real time through a low-code platform visualization interface, realizing an intuitive association between coverage data and UI components, and supporting a WYSIWYG viewing experience.

[0056] In this embodiment, detailed coverage information is displayed when a user selects a component, and the data is updated in real time. The coverage report is integrated with the intelligent configuration panel of the low-code platform, forming a closed-loop "development, testing, and configuration optimization" workflow. This allows users to view the component's coverage status in real time while configuring component properties, events, and interfaces in the visual interface. Simultaneously, users can improve their tests based on the coverage report to increase coverage. The coverage data can guide users in optimizing component configuration and testing strategies.

[0057] In the above embodiments, the method can achieve a comprehensive quantitative evaluation of page coverage by acquiring multi-dimensional detection data and performing preprocessing calculations at key test nodes. This provides the testing team with clear test objectives and optimization directions, accurately locates test blind spots and missed scenarios, effectively reduces the missed test rate, improves the completeness, accuracy and delivery quality of page testing, and reduces the burden of later operation and maintenance.

[0058] In some embodiments, step S200 may include the following four branch steps, which are triggered for execution based on corresponding conditions. That is, the sub-steps in step S200 are parallel, unlike other steps which are sequential. Step S200 includes: S210. When the key node is a component rendering node, according to the data acquisition strategy corresponding to the component rendering node, obtain the component data before rendering and obtain the component data after rendering after rendering; wherein, the component rendering detection data includes the component data before rendering and the component data after rendering.

[0059] In this embodiment, the component rendering hook records component configuration information, including component ID, component type, rendering conditions, etc., before the component is rendered.

[0060] In this embodiment, after the component is rendered, the method can determine whether the component has been successfully rendered and record the rendering result; for conditionally rendered components, it can also check whether the rendering conditions are met.

[0061] In this embodiment, the method can accurately capture the entire rendering process data of a component, thereby effectively identifying the actual rendering state of a conditionally rendered component. For components that do not meet the display conditions, the method can correctly record them as being in an uncovered state, simplifying the statistical process without special processing, thus solving the problem that existing technologies cannot correctly handle the coverage state of conditionally rendered components.

[0062] In this embodiment, the formula for calculating component rendering coverage is: Component rendering coverage = (Number of rendered components / Total number of components on the page) × 100%; The detection granularity is at the component level, with each component independently calculating rendering coverage, supporting complex scenarios such as dynamic components and conditionally rendered components.

[0063] S220. When the key node is an event triggering node, acquire event binding phase data and event execution phase data according to the data acquisition strategy corresponding to the event triggering node; wherein, the event trigger detection data includes event binding phase data and event execution phase data.

[0064] In this embodiment, the event trigger hook records event configuration information during the event binding phase, including event type, event target, event action chain, etc.

[0065] In this embodiment, the method can intercept event handling functions during the event execution phase, record event execution status, and support traversal and statistics of event action chains.

[0066] For example, this method can support fine-grained capture of event action chains, accurately identify the execution status of individual event actions such as onEvent.click.actions[0] and onEvent.click.actions[1], realize fine-grained event execution coverage statistics, and provide developers with accurate modification guidance.

[0067] In this embodiment, the formula for calculating event action coverage is: Event action coverage = (Number of executed event actions / Total number of event actions on the page) × 100%; Among them, the detection granularity can identify multiple actions in an event and calculate the coverage rate for each.

[0068] S230. When the key node is an interface request node, according to the data collection strategy corresponding to the interface request node, the interface information is obtained in the interface configuration parsing stage, and the interface request data is obtained after the interface request is triggered; wherein, the interface request detection data includes interface information and interface request data, and the interface request data includes request address, request parameters, request time and associated components.

[0069] In this embodiment, the method can obtain interface information during the interface configuration parsing phase and obtain interface request data after triggering the interface request; wherein, the interface request detection data includes interface information and interface request data.

[0070] In this embodiment, the interface request data should also include associated component information to reflect the relationship between the interface and the component, thus meeting the requirement for fine-grained statistics on interface request coverage. During the interface configuration parsing phase, the interface request hook extracts all interface information configured in the schema.

[0071] In this embodiment, the method can intercept HTTP requests, record interface call information, and associate interface requests with triggering components and events during the interface request phase.

[0072] For example, this method can establish associations between interface requests and components / events to accurately locate uncalled interface configurations, such as onEvent.click.actions[0].api. This enables fine-grained coverage statistics at the interface level and effectively identifies interface testing omissions.

[0073] In this embodiment, the formula for calculating the interface request coverage is: Interface request coverage = (Number of interfaces requested / Total number of interfaces on the page) × 100%; The detection granularity is at the interface level. Each interface independently calculates the request coverage, which can specifically point out the uncovered interfaces, such as onEvent.click.actions[0].api.

[0074] S240. When the key node is a form item change node, obtain the form component initialization data according to the data collection strategy corresponding to the form item change node, detect the value change event when executing the form change, and obtain the form input data according to the value change event and the form component initialization data; wherein, the form change detection data includes the form component initialization data and the form input data.

[0075] In this embodiment, the form item change hook records the initial value of the form component during the form component initialization phase.

[0076] In this embodiment, the method can capture value change events and record the changes during the form item change phase to determine whether it is an actual input operation (whether the value has changed). Specifically, this method can accurately determine whether an actual input operation has occurred for a form item by comparing the initial value and the changed value, thereby avoiding statistical errors of invalid operations, improving the detection logic of form item change coverage, and covering the core scenarios of form input testing.

[0077] In this embodiment, the formula for calculating the form input coverage rate is: Form input coverage = (Number of entered form items / Total number of form items on the page) × 100%; The detection granularity is at the form item level, with each form item having its input coverage counted independently, enabling the identification of the initial and changed states of the form items.

[0078] In the above embodiments, the method can accurately capture the full-process detection data of each node for different key nodes such as component rendering, event triggering, interface request, and form item change, and refine the granularity of data collection in each dimension to ensure the comprehensiveness and accuracy of multi-dimensional coverage detection data. At the same time, it can quickly locate test omissions through fine-grained statistics and improve test efficiency.

[0079] In some embodiments, please refer to Figure 3 , Figure 3 A data capture mechanism based on rendering engine hooks is illustrated. Step S300 may include: S310. Standardize the multidimensional coverage detection data to obtain standardized data.

[0080] In this embodiment, the method can unify the format and encoding specifications of different types of detection data, eliminate computational interference caused by differences in data format, and provide a unified standard for subsequent data processing.

[0081] In this embodiment, standardization is also an important part of data cleaning in the coverage cleaning service. At the same time, the coverage SDK will also standardize the captured raw data to remove redundant information and lay the foundation for subsequent data processing.

[0082] S320. Extract key fields from standardized data to obtain key field data.

[0083] In this embodiment, the method can extract core key fields such as component ID, interface address, and event type, and filter redundant non-key information, thereby simplifying the data processing flow and improving data processing efficiency.

[0084] In this embodiment, key field extraction is one of the core steps in coverage SDK data organization. Extracting key fields facilitates the establishment of relationships between components, events, interfaces, and form items.

[0085] S330. Perform deduplication on the associated data to obtain deduplicated data.

[0086] In this embodiment, the method can deduplicate data such as multiple renderings of the same component, multiple requests to the same interface, and multiple executions of the same event, ensuring the authenticity of the statistical results and reducing the impact of invalid data on coverage calculation.

[0087] In this embodiment, the deduplication process follows these rules: For multiple renderings of the same component, only the first rendering is recorded; For multiple executions of the same event, the number of executions is recorded, but it is counted as one in the statistics; For multiple requests to the same interface, the number of requests is recorded, but it is counted as one request in the statistics. For multiple changes to the same form item, the number of changes is recorded but counted as one in the statistics.

[0088] In this embodiment, the deduplication rule is the core of the data deduplication algorithm in the SDK of this application.

[0089] S340. Based on the deduplicated data, establish association data including the relationships between components, events, interfaces, and form items.

[0090] In this embodiment, a multi-dimensional data association model is constructed, which can clearly present the mapping relationship between various detection objects, provide a basis for the calculation of layered coverage, and support unified query and analysis of multi-dimensional data.

[0091] In this embodiment, establishing relationships is the core of data assembly in the coverage cleaning service. By establishing these relationships, scattered coverage data can be integrated according to components and pages to form a complete coverage data model; at the same time, it is also possible to integrate multiple test data from the same page and merge multiple coverage records from the same component, thereby calculating the cumulative coverage metric.

[0092] S350. Perform time-window-based data splicing on the relational data to obtain preprocessed data.

[0093] In this embodiment, using batch splicing can reduce the number of data reports and improve reporting efficiency.

[0094] In this embodiment, data stitching is a crucial step in the coverage SDK's data collection mechanism, which batches data within the same time window. Simultaneously, to minimize the impact on page performance, this solution employs an asynchronous reporting mechanism to avoid blocking page rendering and supports both batch and real-time reporting modes. Retrying is also performed in case of uplink failure.

[0095] In this embodiment, the lightweight design reduces the impact on page rendering performance, thereby adapting to data processing needs in complex scenarios.

[0096] In the above embodiments, the method can standardize and optimize multidimensional coverage detection data through a complete preprocessing process of standardization, key field extraction, deduplication, relationship establishment and time window splicing. It eliminates redundant data, clarifies the relationship between data in each dimension, and obtains standardized, complete and relevant preprocessed data. At the same time, it ensures low performance impact of data processing and improves the practicality of the detection scheme.

[0097] In some embodiments, please refer to Figure 4 , Figure 4 A data processing sequence diagram in a coverage cleaning service is shown. Step S400 may include: S410. Based on the preprocessed data, determine multiple components in the page to be evaluated and the associated items corresponding to each component; wherein, the associated items include associated events and associated interfaces.

[0098] In this embodiment, the method decomposes the page structure based on preprocessed data, clarifies the event and interface associations corresponding to each component, and realizes component-level granular statistics, thereby providing a basis for component runtime coverage calculation.

[0099] In this embodiment, during the process of parsing the schema configuration, the rendering engine can extract the configuration information of all components, events, interfaces, and form items, assign a unique ID to each component, and establish a component registry; at the same time, it will further construct a relationship graph between components, events, interfaces, and form items.

[0100] S420. Based on the preprocessed data and the associated items corresponding to each component, calculate the multidimensional coverage of each component; where the multidimensional coverage includes component rendering coverage, event execution coverage, interface request coverage, and form item change coverage.

[0101] In this embodiment, the form item change coverage rate is the same as the form input coverage rate. The coverage rates for each dimension are calculated independently, accurately reflecting the component's coverage across different testing dimensions, forming a multi-dimensional, complementary testing system to comprehensively evaluate the page's test coverage.

[0102] In this embodiment, the above-mentioned method of independently statistically analyzing multiple dimensions and taking the average value is the core embodiment of the component-level "four-dimensional coverage" determination algorithm of this application, which supports fine-grained coverage statistics at the component level.

[0103] To make the coverage results more targeted and accurate, step S420 may also include: S421. Determine the rendering status and form input status of each component based on the preprocessed data; wherein, the rendering status is whether the component has been rendered or not, and the form input status includes whether the component is a form component and whether the input has changed.

[0104] In this embodiment, the method uses the actual running state of the component as the basis for judgment, objectively distinguishes between rendered / unrendered and input / uninputted component states, and ensures the accuracy of coverage determination.

[0105] In this embodiment, for conditional rendering components, if the display conditions are not met, the component will not be actually rendered on the page, and the component rendering coverage is recorded as 0%. Since the component is not rendered, the associated events, interfaces, and form items cannot be triggered, so the corresponding coverage is also 0%. The component's running coverage is 0%, and no special processing is required.

[0106] S422. Determine the component rendering coverage of each component based on the rendering status, and determine the form item change coverage of each component based on the form input status.

[0107] In this embodiment, the component rendering coverage rate is judged by whether the component is successfully rendered, and the form item change coverage rate is judged by whether the form component has undergone a valid value change. Clarifying the judgment rules for coverage of each dimension is the core protection content of the component-level four-dimensional coverage judgment algorithm of this application.

[0108] In this embodiment, the criteria for determining the component rendering coverage is: 100% if the component has been rendered, otherwise 0%; the criteria for determining the form item change coverage is: 100% if the component is a form component and the input has changed, otherwise 0%.

[0109] S423. Obtain the associated item data for each component based on the preprocessed data; wherein, the associated item data includes associated event data and associated interface data.

[0110] In this embodiment, the method can accurately extract the event actions and interface configurations associated with the components, providing data support for the calculation of event execution coverage and interface request coverage, and realizing fine-grained statistics of interfaces and events.

[0111] In this embodiment, the criteria for determining event execution coverage are: the number of executed events / the total number of events × 100% of the events associated with the component; the criteria for determining interface request coverage are: the number of requested interfaces / the total number of interfaces associated with the component × 100%.

[0112] S424. Calculate the event execution coverage and interface request coverage of each component based on the associated item data of each component's corresponding associated item.

[0113] In this embodiment, event execution coverage is used to calculate the execution ratio of event actions associated with a component, and interface request coverage is used to calculate the call ratio of interface associated with a component. These two fine-grained coverage calculation methods allow for the precise identification of uncovered event actions and interfaces.

[0114] For example, this method can specifically point out the uncovered interfaces, such as onEvent.click.actions[0].api, and can also specifically point out the uncovered event actions, such as onEvent.click.actions[0] and onEvent.click.actions[1], thereby providing developers with accurate modification guidance and improving testing efficiency.

[0115] S430. Calculate component runtime coverage and page runtime coverage based on multidimensional coverage; wherein, the coverage results include component runtime coverage and page runtime coverage.

[0116] In this embodiment, the method can output quantified coverage metrics from both component and page dimensions through hierarchical calculation, thereby providing a clear basis for test quality control. At the same time, the method also supports historical data query and trend analysis to help identify coverage change trends.

[0117] In this embodiment, the component runtime coverage and page runtime coverage are obtained through hierarchical calculation, which is the core manifestation of the dynamic delivery quality control system based on page coverage in this application. This method supports page-level coverage statistics and quality control, and the coverage data can effectively guide testing strategies and delivery decisions.

[0118] Please refer to Figure 5 , Figure 5 A visualization of the coverage results is shown.

[0119] To clearly demonstrate the test completeness of the entire page while specifying the operational coverage of individual components, step S430 may also include: S431. Calculate the average of the component rendering coverage, event execution coverage, interface request coverage, and form item change coverage for each component to obtain the component runtime coverage for each component.

[0120] In this embodiment, the method can calculate the component runtime coverage for each component among all components based on this step. Here, "all components" refers to all components in the page to be evaluated.

[0121] In this embodiment, the component operation coverage is calculated by averaging the four-dimensional coverage to comprehensively reflect the overall operation coverage level of the component. This calculation formula is the core component-level four-dimensional coverage determination algorithm protected in this application.

[0122] In this embodiment, the formula for calculating component runtime coverage is: Component runtime coverage = (Component rendering coverage + Event execution coverage + Interface request coverage + Form item change coverage) / 4.

[0123] S432. Calculate the average component runtime coverage of all components to obtain the page runtime coverage.

[0124] In this embodiment, the page runtime coverage can be calculated by averaging the runtime coverage of all components, which can be used to intuitively reflect the overall test coverage of the page.

[0125] In this embodiment, the hierarchical calculation algorithm is the core protection point of the page running coverage statistics algorithm of this application. It can provide the testing team with clear testing goals and improvement directions, and support quality control based on coverage.

[0126] In this embodiment, the formula for calculating page runtime coverage is: Page runtime coverage = (Component runtime coverage 1 + Component runtime coverage 2 + ... + Component runtime coverage n) / n; where n is the total number of components in the page.

[0127] In the above embodiments, the method can decompose the page structure from the dimensions of components, related events, and related interfaces based on preprocessed data, accurately calculate the coverage of multiple dimensions such as component rendering, event execution, interface requests, and form item changes, and then summarize the component operation coverage and page operation coverage to achieve a layered and quantitative evaluation of page coverage. This allows testers to clearly understand the test completeness of each level of the page, while reducing the missed test rate through multi-dimensional detection and fine-grained statistics, improving delivery quality, and reducing the burden of later operation and maintenance.

[0128] Please refer to Figure 6 , Figure 6 The system architecture for performing page coverage detection is shown. The system architecture mainly includes the following core components: low-code platform rendering engine, coverage SDK, coverage cleaning service, and low-code platform visualization coverage report display module.

[0129] Among them, the low-code platform rendering engine, as the core execution unit, is responsible for parsing the schema configuration and rendering page components. At the same time, it actively triggers coverage detection events at key nodes such as component rendering, event triggering, interface requests, and form item changes, providing basic triggering conditions for data collection. The coverage SDK is deeply embedded in the rendering engine, serving as the core carrier for data collection and reporting. It captures multi-dimensional coverage detection data of key nodes in the rendering engine in real time, including data related to component rendering, event triggering, interface requests, and form item changes. It also performs data compression and batch uploading according to a lightweight reporting mechanism. The coverage cleaning service receives the raw data reported by the SDK, verifies and cleans the data, removes invalid, duplicate and abnormal data, and completes the standardization, integration and persistent storage of the data, supporting historical data query, coverage trend analysis and cumulative statistics of multiple rounds of test data; The low-code platform's visual coverage report display module, based on cleaned preprocessed data, intuitively displays component-level and page-level coverage results in a visual interface, realizing the association between coverage data and UI components. It allows users to select components to view detailed coverage information and refresh data in real time. It is also integrated with the low-code platform's intelligent configuration panel to form a closed-loop workflow of "development, testing, and configuration optimization," providing intuitive data support for test optimization and quality control.

[0130] like Figure 7 As shown, some embodiments of this application provide a schematic diagram of a page coverage detection device. It should be understood that this device is related to... Figure 1 The method executed in the middle corresponds to the steps involved in the aforementioned method. The specific functions and effects of the device can be found in the description above. To avoid repetition, detailed descriptions are omitted here.

[0131] The page coverage detection device includes: The acquisition unit 510 is used to acquire multi-dimensional coverage detection data of the page to be evaluated when the rendering engine of the development platform reaches a key node during the testing of the page to be evaluated through the development platform. The preprocessing unit 520 is used to preprocess the multidimensional coverage detection data to obtain preprocessed data; The calculation unit 530 is used to calculate the coverage result based on the preprocessed data; Display unit 540 is used to output coverage results.

[0132] In some embodiments, the page coverage detection device further includes: Configuration unit 550 is used to configure one-to-one corresponding data acquisition strategies for multiple key nodes of the rendering engine in the development platform before the acquisition unit 510 tests the page to be evaluated through the development platform. Among them, key nodes include at least component rendering nodes, event triggering nodes, interface request nodes, and form item change nodes.

[0133] In some embodiments, the acquisition unit 510 is specifically used to acquire multidimensional coverage detection data according to the data acquisition strategy corresponding to the key node; The multidimensional coverage detection data includes component rendering detection data, event triggering detection data, interface request detection data, and form change detection data.

[0134] In some embodiments, the acquisition unit 510 is specifically used to acquire pre-rendering component data and post-rendering component data according to the data acquisition strategy corresponding to the component rendering node when the key node is a component rendering node; wherein, the component rendering detection data includes pre-rendering component data and post-rendering component data. The acquisition unit 510 is further used to acquire event binding phase data and event execution phase data according to the data acquisition strategy corresponding to the event triggering node when the key node is an event triggering node; wherein, the event triggering detection data includes event binding phase data and event execution phase data; The acquisition unit 510 is also specifically used to acquire interface information during the interface configuration parsing phase and to acquire interface request data after triggering the interface request when the key node is an interface request node, according to the data acquisition strategy corresponding to the interface request node; wherein, the interface request detection data includes interface information and interface request data, and the interface request data includes request address, request parameters, request time and associated components; The acquisition unit 510 is further configured to, when the key node is a form item change node, acquire form component initialization data according to the data acquisition strategy corresponding to the form item change node, detect value change events when executing form changes, and acquire form input data based on value change events and form component initialization data; wherein, the form change detection data includes form component initialization data and form input data.

[0135] In some embodiments, the preprocessing unit 520 includes: The standardization subunit 521 is used to standardize the multidimensional coverage detection data to obtain standardized data. Extraction subunit 522 is used to extract key fields from standardized data to obtain key field data; The deduplication subunit 523 is used to deduplicatize the associated data to obtain deduplicated data; Create sub-unit 524 to establish association data, including the relationships between components, events, interfaces, and form items, based on the deduplicated data; The splicing subunit 525 is used to perform time window-based data splicing on the associated data to obtain preprocessed data.

[0136] In some embodiments, the computing unit 530 includes: Subunit 531 is used to determine multiple components in the page to be evaluated and the associated items corresponding to each component based on preprocessed data; wherein, the associated items include associated events and associated interfaces; The calculation subunit 532 is used to calculate the multidimensional coverage of each component based on the preprocessed data and the associated items corresponding to each component; wherein, the multidimensional coverage includes component rendering coverage, event execution coverage, interface request coverage, and form item change coverage; The calculation subunit 532 is also used to calculate component runtime coverage and page runtime coverage based on multidimensional coverage. The coverage results include component runtime coverage and page runtime coverage.

[0137] In some embodiments, the calculation subunit 532 is specifically used to determine the rendering status and form input status of each component based on preprocessed data; wherein, the rendering status is whether the component has been rendered or not, and the form input status includes whether the component is a form component and whether the input has changed; The component rendering coverage of each component is determined based on the rendering results, and the form item change coverage of each component is determined based on the form input results. The associated item data for each component is obtained from the preprocessed data; the associated item data includes associated event data and associated interface data. Calculate the event execution coverage and API request coverage of each component based on the associated item data of each component's corresponding associated items.

[0138] In some embodiments, the calculation subunit 532 is further configured to calculate the average of the component rendering coverage, event execution coverage, interface request coverage and form item change coverage of each component to obtain the component runtime coverage of each component. The average component runtime coverage of all components is calculated to obtain the page runtime coverage.

[0139] like Figure 8As shown, this application provides an electronic device 600, which includes a processor 601 and a memory 602. The processor 601 and the memory 602 are interconnected and communicate with each other through a communication bus 603 and / or other forms of connection mechanism (not shown). The memory 602 stores a computer program that can be executed by the processor 601. When the computing device is running, the processor 601 executes the computer program to perform the method in any of the aforementioned optional implementations.

[0140] This application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the method in any of the aforementioned optional implementations.

[0141] The computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0142] This application provides a computer program product, which includes a computer program that, when run by a processor, executes the method in any of the aforementioned optional implementations.

[0143] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and they should all be covered within the scope of the claims and specification of this application. In particular, as long as there is no conflict, the various technical features mentioned in the embodiments can be combined in any way. This application is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

Claims

1. A method for detecting page coverage, characterized in that, include: During the testing of the page to be evaluated through the development platform, when the rendering engine of the development platform reaches a key node, it acquires the multidimensional coverage detection data of the page to be evaluated. The multidimensional coverage detection data is preprocessed to obtain preprocessed data; The coverage result is calculated based on the preprocessed data and then output.

2. The page coverage detection method according to claim 1, characterized in that, The method further includes: Before testing the page to be evaluated through the development platform, configure one-to-one data collection strategies for multiple key nodes of the rendering engine in the development platform; The key nodes include at least component rendering nodes, event triggering nodes, interface request nodes, and form item change nodes.

3. The page coverage detection method according to claim 1, characterized in that, The process of obtaining the multidimensional coverage detection data of the page to be evaluated includes: Based on the data acquisition strategy corresponding to the key nodes, multidimensional coverage detection data is obtained; The multidimensional coverage detection data includes component rendering detection data, event triggering detection data, interface request detection data, and form change detection data.

4. The page coverage detection method according to claim 3, characterized in that, The step of acquiring multidimensional coverage detection data according to the data acquisition strategy corresponding to the key nodes includes: When the key node is a component rendering node, according to the data acquisition strategy corresponding to the component rendering node, pre-rendering component data is acquired before component rendering, and post-rendering component data is acquired after component rendering is completed; wherein, the component rendering detection data includes the pre-rendering component data and the post-rendering component data; When the key node is an event triggering node, the event binding stage data and the event execution stage data are obtained according to the data collection strategy corresponding to the event triggering node; wherein, the event triggering detection data includes the event binding stage data and the event execution stage data; When the key node is an interface request node, according to the data collection strategy corresponding to the interface request node, interface information is obtained during the interface configuration parsing phase, and interface request data is obtained after the interface request is triggered; wherein, the interface request detection data includes the interface information and the interface request data, and the interface request data includes the request address, request parameters, request time and associated components; When the key node is a form item change node, the form component initialization data is obtained according to the data collection strategy corresponding to the form item change node, and a value change event is detected when the form change is executed. The form input data is obtained according to the value change event and the form component initialization data. The form change detection data includes the form component initialization data and the form input data.

5. The page coverage detection method according to claim 1, characterized in that, The preprocessing of the multidimensional coverage detection data to obtain preprocessed data includes: The multidimensional coverage detection data is standardized to obtain standardized data; Key fields are extracted from the standardized data to obtain key field data; The association data is deduplicated to obtain deduplicated data; Based on the deduplication data, establish association data including the relationships between components, events, interfaces, and form items; The associated data is subjected to time window-based data splicing to obtain preprocessed data.

6. The page coverage detection method according to claim 1, characterized in that, The calculation of coverage results based on the preprocessed data includes: Based on the preprocessed data, multiple components in the page to be evaluated and associated items corresponding to each component are determined; wherein, the associated items include associated events and associated interfaces; Based on the preprocessed data and the associated items corresponding to each component, the multidimensional coverage of each component is calculated; wherein, the multidimensional coverage includes component rendering coverage, event execution coverage, interface request coverage, and form item change coverage; Calculate component runtime coverage and page runtime coverage based on the multidimensional coverage; The coverage results include the component runtime coverage and the page runtime coverage.

7. The page coverage detection method according to claim 6, characterized in that, The step of calculating the multidimensional coverage of each component based on the preprocessed data and the associated items corresponding to each component includes: The rendering status and form input status of each component are determined based on the preprocessed data; wherein, the rendering status is whether the component has been rendered or not, and the form input status includes whether the component is a form component and whether the input has changed; The component rendering coverage rate of each component is determined based on the rendering status, and the form item change coverage rate of each component is determined based on the form input status. Based on the preprocessed data, obtain the associated item data for each component's corresponding associated item; wherein, the associated item data includes associated event data and associated interface data; The event execution coverage and interface request coverage of each component are calculated based on the associated item data of the associated items corresponding to each component.

8. The page coverage detection method according to claim 6, characterized in that, The calculation of component runtime coverage and page runtime coverage based on the multidimensional coverage includes: The component rendering coverage, event execution coverage, interface request coverage, and form item change coverage of each component are averaged to obtain the component runtime coverage of each component. The average component runtime coverage of all components is calculated to obtain the page runtime coverage.

9. A page coverage detection device, characterized in that, The page coverage detection device includes: The acquisition unit is used to acquire multidimensional coverage detection data of the page to be evaluated when the rendering engine of the development platform reaches a key node during the testing process of the page to be evaluated through the development platform. The preprocessing unit is used to preprocess the multidimensional coverage detection data to obtain preprocessed data; A calculation unit is used to calculate the coverage result based on the preprocessed data; The display unit is used to output the coverage results.

10. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory being used to store a computer program, and the processor running the computer program to cause the electronic device to perform the page coverage detection method according to any one of claims 1 to 8.

11. A readable storage medium, characterized in that, The readable storage medium stores a computer program, which, when executed by a processor, performs the page coverage detection method according to any one of claims 1 to 8.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, performs the page coverage detection method according to any one of claims 1 to 8.

Images