Method for automatically repairing front-end rendering defects and related equipment
By leveraging high-coverage monitoring and automated processes driven by large language models (LLM), the diversity of front-end rendering defects and the inefficiency of their repair were addressed, enabling rapid and accurate code optimization and deployment, and improving the performance and maintenance efficiency of the component-based architecture.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHENZHEN DADAO CLOUD TECH CO LTD
- Filing Date
- 2025-12-23
- Publication Date
- 2026-04-21
AI Technical Summary
Existing technologies suffer from a wide variety of complex front-end rendering defects and inefficient repair processes. Traditional toolchains lack sufficient intelligence, making it difficult to quickly locate and fix performance and maintenance challenges under a component-based architecture.
By building a closed-loop workflow that integrates high-coverage monitoring, intelligent root cause localization, and automated deployment of Large Language Models (LLM), combined with event logging and issue detection, the entire process from defect occurrence to code generation and deployment is automated, and LLM is used to generate targeted optimized code.
It significantly shortened defect response time, improved code repair cycle, ensured that optimized code addressed the root cause of the problem, resolved core performance defects such as low loading efficiency, and improved user experience.
Smart Images

Figure CN121900756A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of software engineering technology, and in particular to an automated method and related equipment for repairing front-end rendering defects. Background Technology
[0002] The current front-end development widely adopts a component-based architecture, which greatly improves development efficiency and code maintainability by decomposing complex user interfaces into reusable and composable independent components (such as React, Vue or Angular components), and promotes rapid iteration and reconfiguration of functions. However, with the continuous expansion of component scale and the increase in business complexity, this component-based model has exposed serious performance and maintenance challenges in the production environment. The increase in the number of components directly leads to a significant decrease in page performance. Specifically, it is reflected in the following three main defects: (1) Low loading efficiency. When the number of components in a page is too large, it will seriously affect the first contentful paint (FCP). Studies have shown that when the number of components exceeds 50, the first contentful paint (FCP) increases by an average of 1.8 seconds. (2) Poor environmental adaptability. Faced with the differences in screens of multiple devices and unstable network bandwidth, traditional performance optimization methods have limited effect and can only solve about 30% of the performance loss, which cannot meet the requirements for the dynamic adaptability of components. (3) Runtime rendering bottleneck: Frequent and unoptimized DOM operations and inefficient CSS selector design can easily occupy browser main thread resources, resulting in rendering blockage and a drop in frame rate (FPS).
[0003] Faced with the complex and diverse front-end rendering defects mentioned above, existing maintenance and remediation processes are inefficient. Traditional defect localization processes rely on developers manually reviewing the event tracking data of log service systems (such as Alibaba Cloud Log Service (SLS)) for time-consuming manual reproduction and code analysis. Although the Log Service System (SLS) supports data collection, it lacks the root cause analysis capability to directly correlate performance data with the specific code logic causing the problem. Existing automated workflow engines (such as Dify) can orchestrate processes, but their core capabilities do not integrate a knowledge base of code optimization strategies for front-end performance defects, making it difficult to directly generate high-quality, deployable optimized code. Summary of the Invention
[0004] This invention provides an automated method and related equipment for repairing front-end rendering defects, in order to solve the problems of the large variety and complexity of front-end rendering defects and the slow repair process in the prior art.
[0005] This invention provides an automated method for repairing front-end rendering defects, comprising: Identify key events in the front-end application and determine at least one event tracking component corresponding to the key event; The event tracking component is used to track events, and the event tracking logs generated by the event tracking component when the key event occurs are obtained. Based on the aforementioned tracking logs, the system detects whether there are any preset problems and their corresponding problem types on the front-end page, and generates problem information containing the problem type and corresponding path information when a problem is detected. Based on the path information, obtain the code file corresponding to the problem type; The problem information, event logs, and code files are aggregated, analyzed and reasoned using a preset large language model, and code problems are retrieved based on the problem type to generate optimized code. Deploy the optimized code to the preset environment.
[0006] According to the present invention, an automated method for fixing front-end rendering defects includes aggregating the problem information, event logs, and code files, analyzing and reasoning using a preset large language model, retrieving code problems based on the problem type, and generating optimized code. Based on the problem information, the corresponding basic code is identified in the preset knowledge base; When the base code is not empty, optimized code is generated based on the base code, the code file, and the event logs. When the base code is empty, optimized code is generated based on the problem information, the tracking logs, and the code file.
[0007] According to the present invention, an automated method for fixing front-end rendering defects is provided, wherein the key events include user activity events, and the event tracking logs include user activity logs corresponding to the user activity events; the step of deploying the optimization code to a preset environment includes: A simulation test script is generated based on the user activity logs in the aforementioned data collection logs; Based on the simulation test script, the optimized code is subjected to simulation testing; Based on the test results corresponding to the simulation test, the optimized code is deployed to the preset environment.
[0008] According to the present invention, an automated method for fixing front-end rendering defects includes obtaining the code file corresponding to the problem type based on the path information in the problem information, which includes: Based on the path information in the problem information, one or more candidate files corresponding to the problem type are obtained through a preset code repository tool; When no corresponding candidate file is found based on the event logs or the current deployment version identifier, the latest candidate file is used as the code file.
[0009] According to the automated repair method for front-end rendering defects provided by the present invention, the step of obtaining the code file corresponding to the problem type based on the path information in the problem information further includes: Based on the path information in the problem information, the complete file is obtained through a preset code repository tool; Based on the problem type, calculate the association value between the code block in the code file and the problem type; Based on the association value, the target code in the complete file is determined and the target code is used as the code file.
[0010] According to the automated repair method for front-end rendering defects provided by the present invention, the coverage rate of the tracking points corresponding to the key events is greater than 95%.
[0011] According to the present invention, an automated method for repairing front-end rendering defects includes, based on the event tracking logs, detecting whether a preset problem and its corresponding problem type exist on the front-end page, and generating problem information containing the problem type and corresponding path information when a problem is detected, including: Monitor pre-defined core rendering metrics, core resources, and high-frequency errors; When the core rendering metric exceeds a preset time threshold, a slow page loading issue is confirmed. When the core resource fails to load, or the total time taken to load the resource exceeds a preset third time threshold, a resource loading problem is confirmed. When the high-frequency error is detected, it confirms the existence of a historical high-frequency error problem.
[0012] The present invention also provides an automated repair device for front-end rendering defects, comprising: A determination module is used to determine key events in the front-end application and to determine at least one tracking component corresponding to the key events; The event tracking module is used to track events on the event tracking component and obtain the event tracking logs generated by the event tracking component when the key event occurs. The detection module is used to detect whether there are preset problems and corresponding problem types on the front-end page based on the data entry logs, and generate problem information containing problem type and corresponding path information when a problem is detected. The acquisition module is used to acquire the code file corresponding to the problem type based on the path information; The generation module is used to aggregate the problem information, the tracking logs and the code files, analyze and reason through a preset large language model, retrieve code problems based on the problem type and generate optimized code; The deployment module is used to deploy the optimized code to a preset environment.
[0013] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement an automated repair method for any of the aforementioned front-end rendering defects.
[0014] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements an automated repair method for any of the aforementioned front-end rendering defects.
[0015] This invention provides an automated method and related equipment for repairing front-end rendering defects. By constructing a closed-loop workflow integrating high-coverage monitoring, intelligent root cause localization, and automated deployment of Large Language Models (LLM), it completely solves the problems of numerous defect types, complex localization, and lengthy and inefficient manual repair processes in existing front-end applications. This method seamlessly integrates event logs with problem detection and LLM deployment, overcoming the limitations of insufficient intelligence in existing toolchains. It achieves full-process automation from defect occurrence and root cause analysis to code generation and deployment, significantly shortening defect response time. By eliminating time-consuming steps such as manual reproduction, manual localization, and manual code optimization in traditional processes, this method effectively improves the code repair cycle, thus powerfully addressing the challenge of a large number and complexity of front-end defects. LLM utilizes aggregated log data and code files to generate targeted optimized code, directly solving core performance defects such as low loading efficiency. Furthermore, traditional logging systems lack the ability to associate performance metrics with code paths. This invention obtains code files through the paths in the problem information and uses LLM for in-depth analysis of aggregated data to ensure that the generated optimized code targets the root cause of the problem, rather than just superficial patching, thus guaranteeing the effectiveness and high quality of the repair solution. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0017] Figure 1 This is the first flowchart of the automated repair method for front-end rendering defects provided by the present invention; Figure 2 This is a schematic diagram illustrating the main tasks performed before the workflow of the automated front-end rendering defect repair method provided by this invention is started; Figure 3This is a schematic diagram of the main workflow in the automated repair method for front-end rendering defects provided by this invention; Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.
[0019] The following is combined Figures 1-3 This invention describes the specific real-time process of an automated front-end rendering defect repair method. This method primarily utilizes an automated workflow platform (e.g., Dify workflow) to connect a front-end application, a log service system (SLS), a code repository (e.g., GitLab), and a continuous integration tool (e.g., Jenkins). This automated front-end rendering defect repair method can run based on applications, plugins, etc. Specifically, it includes: Step S10: Determine the key events in the front-end application and determine at least one tracking component corresponding to the key events; Specifically, the selection of critical events must cover multiple dimensions leading to front-end rendering defects to ensure that subsequent logs can provide sufficient evidence for root cause analysis. Critical events mainly include page rendering events, component rendering events, user activity events, and resource loading events.
[0020] The page rendering events and component rendering events include performance information and error information during the page or component rendering process. Page rendering events record performance data throughout the entire lifecycle of a page, from request to full interactivity, including but not limited to FCP (First Contentful Paint), LCP (Largest Contentful Paint), and error information (such as loading failure or initialization script errors). Component rendering events focus on the rendering process of core or high-risk components, recording the time consumption in their lifecycle hook functions, the number of repaints / reflows, and runtime error stacks. This allows for precise identification of which component caused the rendering blockage.
[0021] User activity events are used to record user clicks, scrolling, and dwell times on the page. These logs are not only used for routine analysis, but more importantly, for subsequent automated workflows to simulate user behavior to reproduce defects or verify fixes. Resource loading events are used to monitor the loading time, size, and failure status of critical page resources (such as JavaScript, CSS, images, and fonts) to identify resource loading bottlenecks.
[0022] Identify components directly related to the aforementioned critical events as event tracking components. For example, key components on the first screen with the greatest impact from FCP, frequently used interactive components, and high-risk components with a high historical error rate. Implement event tracking on these components to build an event tracking system. As a preferred approach, the event tracking system must have a tracking rate greater than 95% to ensure the integrity and representativeness of log data and avoid root cause analysis errors due to missing data.
[0023] Step S20: Perform event tracking on the event tracking component and obtain the event tracking logs generated by the event tracking component when the key event occurs; Specifically, in the front-end application, technologies such as WebTracking are used to upload the event tracking logs collected in step 1 to a professional log service system (SLS) in real time and in batches. Event tracking logs include performance metrics such as FCP and TTI recorded by the Navigation Timing API, and the log service system includes Alibaba Cloud Log Service. During the upload process, it is necessary to ensure that the event tracking coverage for critical events is greater than 95%, that is, to ensure that core performance and error data have been successfully transmitted to SLS. In a preferred approach, the event tracking logs should contain sufficient information, such as device type, network status, page path, and component ID, to provide context for subsequent analysis.
[0024] Step S30: Based on the event logs, detect whether there are preset problems and corresponding problem types on the front-end page, and when a problem is detected, generate problem information containing the problem type and corresponding path information; Specifically, problem identification rules are pre-configured in the log service system's console. These problem types are based on critical defects that frequently occur during front-end rendering and affect user experience, and their classification. In a preferred embodiment, the problem types mainly include: slow page loading issues, resource loading issues, and historically high-frequency error issues. Performance metric problem type detection can employ a quantified time threshold method. Core rendering metrics for the page lifecycle, such as FCP and LCP, are pre-defined.
[0025] To address slow page loading issues, a slow page loading problem is confirmed when the core rendering metrics during the monitored page lifecycle exceed preset time thresholds. For example, a slow page loading problem is confirmed when the FCP (Fulfilled Capacity Count) exceeds a preset first time threshold or the LCP (Limited Capacity Count) exceeds a preset second time threshold. For instance, the first time threshold might be set to 2 seconds and the second time threshold to 4 seconds.
[0026] Regarding resource loading issues, a resource loading problem is confirmed when core or critical resources fail to load, or when the total resource loading time exceeds a preset third time threshold. For example, the third time threshold is set to 10 seconds.
[0027] Based on historical log statistics, the system performs statistical analysis on the historical log data and identifies runtime errors that occur more than a first frequency threshold as high-frequency errors. For example, the first frequency threshold is set to occur more than 100 times within 24 hours. When a defined high-frequency error is confirmed based on the current log data, the existence of a historical high-frequency error is confirmed. This allows for the rapid capture of defects with a wide impact caused by logical flaws in specific components.
[0028] When a problem and its corresponding problem type are detected, problem information is generated. Problem information must include the detected problem type and the corresponding path information, such as page path or component route identifier. To provide a large language model for accurate root cause analysis, problem information may also include the timestamp of the problem occurrence, the original log fragment that triggered the alarm, device information, and the environmental context at the time. The problem type can be in the form of "LCP timeout slow page".
[0029] Furthermore, to initiate the automated remediation process, the Log Service (SLS) system will utilize its alarm configuration function to immediately send the issue information in the form of data packets to the trigger interface of a pre-configured automated workflow platform (such as the Dify workflow) via a configured webhook. This webhook trigger action signifies a seamless transition of the defect remediation process from the monitoring phase to the LLM-driven automated remediation phase.
[0030] Step S40: Based on the path information in the problem information, obtain the code file corresponding to the problem type; Specifically, once the issue information sent by the Log Service System (SLS) via Webhook in step S30 successfully triggers the automated workflow platform, the workflow immediately starts execution.
[0031] After the workflow of the automated workflow platform is started, its first task node is responsible for parsing the received structured problem information data packet. The workflow accurately extracts path information from the problem information to locate the code file. The path information may include page path, component routing information, file identifier, etc.
[0032] The workflow invokes pre-built-in or integrated code repository tools (such as GitLab file retrieval tools). These tools, using configured security credentials, have read permissions from the target code repository. Based on the extracted path information, the code repository tool locates the code file corresponding to the issue page or component via an API interface. If multiple code files exist, they can be selected as candidate files.
[0033] In one implementation, to ensure the correspondence between code files and the online runtime environment, the tool prioritizes retrieving the precise code version based on the version identifier of the current deployment recorded in the event tracking logs. If no corresponding candidate file exists for the deployed version identifier, the latest version candidate file is retrieved as the code file. "No corresponding file" includes missing or inaccurate matching. In another implementation, to ensure the accuracy of the fix, the tool prioritizes retrieving the version of the code file corresponding to the alarm occurrence time (e.g., by timestamp). If no corresponding candidate file exists, the latest version candidate file is retrieved as the code file. The tool downloads one or more located code files and stores them in the temporary execution environment of the automated workflow platform. Through this step, this method achieves automated bridging from abstract online performance alarms to specific offline code files, significantly reducing the time required for traditional manual code defect location.
[0034] Furthermore, the code file can be a pre-defined code snippet strongly related to the alarm path, located using static analysis tools, rather than an entire lengthy code file. Specifically, this includes: Step S41: Based on the path information in the problem information, obtain the complete file using a preset code repository tool; Specifically, firstly, based on the path information provided in the problem information, the corresponding complete code file is obtained through a preset code repository tool.
[0035] Step S42: Based on the problem type, calculate the association value between the code block in the code file and the problem type; Specifically, the complete code file is structured into discrete code blocks. For structured languages, code blocks can be divided into function definitions, component lifecycle methods, logical branches, or large statement blocks based on the abstract syntax tree; for style files, code blocks can be divided according to selectors or media queries.
[0036] Step S43: Based on the associated value, determine the target code in the complete file and use the target code as the code file.
[0037] Specifically, for each defined code block, the system will calculate the correlation value between the code block and the problem type. For example, for performance issues, the correlation value calculation will focus on the runtime impact of the code block. For instance, if the problem type is "FCP timeout," code blocks with high correlation values include time-consuming parts of the component's lifecycle that perform synchronous logic, large data processing, or loop operations.
[0038] The system sorts all code blocks according to their calculated association values. Finally, based on a preset association value threshold or a limit on the number of code blocks, the set of code blocks with the highest association values is determined as the target code. This code is then used as input to the LLM code file.
[0039] Through this precise positioning process, the system effectively avoids sending the entire lengthy code file into the LLM, significantly improving the efficiency of LLM analysis and ensuring that the LLM can focus on the critical code path most likely to cause defects within a limited context window, thereby improving the accuracy of the final optimized code generation.
[0040] Step S50: Aggregate the problem information, tracking logs, and code files, analyze and reason using a preset large language model, retrieve code problems based on the problem type, and generate optimized code; Specifically, the workflow aggregates three types of data: issue information, event logs, and code files, which are then used as input to the large language model. To reduce model load, the input event logs can be filtered and summarized key log data. For example, only the key performance indicator values that caused the alert, the first N lines of the error stack, and the key event sequence that triggered the issue are included to avoid exceeding the LLM's context window.
[0041] In one implementation, the LLM employs a strategy of retrieval-first, reasoning-supplemented processing when handling input. Specifically, this includes: Step S51: Based on the problem information, confirm the corresponding basic code in the preset knowledge base; First, within the automated workflow platform, a knowledge base containing numerous optimization solutions for front-end component code should be pre-built and integrated. The knowledge base should focus on optimizing code snippets for single rendering problems, such as: best practice code snippets for slow loading within the component lifecycle under specific frameworks, encapsulated functions for batch DOM operations to avoid forced synchronous layout, and flattening optimization solutions for deeply nested CSS selectors to eliminate performance bottlenecks.
[0042] LLM is instructed to prioritize using this knowledge base for semantic retrieval. Search keywords are based on the input question type, code file content, and error keywords in the logs.
[0043] Step S52: When the base code is not empty, generate optimized code based on the base code, the code file, and the event logs; Specifically, if LLM successfully retrieves a corresponding optimization solution from the knowledge base (meaning the base code is not empty), LLM will use this high-quality base code as the starting point for repair. Combining this with the code file to be repaired and the event logs, LLM will perform detailed adaptation and customization modifications. Ultimately, LLM generates a highly adaptable and high-quality optimized code file.
[0044] Step S53: When the basic code is empty, generate optimized code based on the problem information, the tracking logs, and the code file.
[0045] Specifically, if no directly matching optimization solution exists in the knowledge base, LLM activates its code understanding and logical reasoning capabilities. LLM analyzes aggregated log and code snippets, and can also invoke built-in or integrated static code analysis tools to help identify potential performance bottlenecks. Based on the reasoning results and tool feedback, LLM designs and generates entirely new optimization logic code from scratch that meets the requirements of the problem type.
[0046] In one implementation, LLM performs inference solely based on an aggregation of the issue information, event log summaries, and code file snippets. This approach is suitable for newly discovered defect types lacking prior knowledge base examples. Compared to hybrid strategies, this method demands higher accuracy from LLM inference and may result in a lack of standardization and optimality in remediation solutions when dealing with common issues.
[0047] Step S60: Deploy the optimized code to the preset environment.
[0048] Specifically, in one approach, the optimized code contains only minimal code changes made to address the specific issues detected in step S30. This minimizes interference with other code on the page, reduces the risk of introducing new errors, and facilitates quick identification of fixes during subsequent manual verification.
[0049] In another approach, the optimized code can be a complete code file optimized based on the problem, so that subsequent workflow processing can be performed directly or the original file can be overwritten.
[0050] The workflow invokes a code commit tool (such as the GitLab API or Git command-line tools) to push the optimized code as a new commit to a designated test branch. This branch is typically a development branch dedicated to automated bug fixes, ensuring it doesn't pollute the main branch or stable branches. After the code is successfully pushed to the test branch, the workflow then invokes the API of a CI / CD tool (such as Jenkins triggers, GitLab CI / CD, or other automation tools) to trigger a pre-configured continuous integration / continuous deployment (CI / CD) pipeline, starting with the new code commit. This CI / CD pipeline performs compilation and packaging of the optimized code in a pre-defined environment, along with necessary tests, including unit tests, integration tests, and automated regression tests, such as verifying whether the FCP has fallen below the target threshold.
[0051] The default environment can be a test environment or a development environment. Only build artifacts that pass automated testing will be quickly deployed to the test environment or pre-release environment. After deployment, the system awaits subsequent manual acceptance testing or more comprehensive automated regression testing to verify its fix effectiveness and ensure that no new defects have been introduced.
[0052] Furthermore, during the testing phase, to ensure that the optimized code is effective in real-world user scenarios and does not introduce side effects, this embodiment introduces a simulation testing verification mechanism based on user activity event logs. Specifically, this includes: Step S61: Generate a simulation test script based on the user activity logs in the data collection logs; When a problem is detected, the corresponding event logs are extracted and referred to as user activity logs. These logs record the entire process of a user's interaction on the page from the start to the triggering of the defect, including precise click coordinates, scroll positions, dwell time, and interaction sequences. Based on these user activity logs, testing tools in the LLM or workflow automatically generate a set of simulated test scripts.
[0053] Step S62: Based on the simulation test script, perform simulation tests on the optimized code; Specifically, the simulated test script is then executed automatically in a test environment or pre-release environment where optimized code has been deployed. This script precisely simulates the original user's behavioral path and interaction sequence on the page until a critical state is reached that triggers the original defect.
[0054] Step S63: Based on the test results corresponding to the simulation test, deploy the optimized code to the preset environment.
[0055] Specifically, during the execution of the simulation test script, the system simultaneously monitors page rendering, component rendering, and resource loading logs. Only when the monitoring data shows that the original rendering defects have been eliminated and the key performance indicators meet the preset optimization goals is the optimized code deemed to have passed verification and allowed to proceed to the next stage of deployment or manual acceptance. For example, after the slow page issue was resolved, FCP dropped to below 2 seconds.
[0056] By using real user activity logs for simulation testing, this invention greatly improves the testing accuracy and user scenario coverage of automated repair solutions, avoiding performance defects related to user behavior that are difficult to find in traditional unit testing or integration testing.
[0057] The automated repair method described in this invention significantly reduces the code repair cycle from the traditional 1-3 person-days to less than 1 person-day. The time spent on problem localization and code association can be drastically reduced from 4-8 hours per problem in the traditional approach to less than 30 minutes per problem. This method also improves first-screen loading performance (FCP / LCP), effectively optimizing the original first-screen loading time of more than 3 seconds to less than 2 seconds, significantly improving the user experience.
[0058] The automated front-end rendering defect repair device provided by the present invention will be described below. The automated front-end rendering defect repair device described below can be referred to in correspondence with the automated front-end rendering defect repair method described above. The device includes: A determination module is used to determine key events in the front-end application and to determine at least one tracking component corresponding to the key events; The event tracking module is used to track events on the event tracking component and obtain the event tracking logs generated by the event tracking component when the key event occurs. The detection module is used to detect whether there are preset problems and corresponding problem types on the front-end page based on the data entry logs, and generate problem information containing problem type and corresponding path information when a problem is detected. The acquisition module is used to acquire the code file corresponding to the problem type based on the path information; The generation module is used to aggregate the problem information, the tracking logs and the code files, analyze and reason through a preset large language model, retrieve code problems based on the problem type and generate optimized code; The deployment module is used to deploy the optimized code to a preset environment.
[0059] The generation module includes: The retrieval unit is used to identify the corresponding basic code in a preset knowledge base based on the question information; Basic code generation unit: used to generate optimized code based on the basic code, the code file, and the data tracking logs when the basic code is not empty; Inference generation unit: used to generate optimized code based on the problem information, the tracking logs, and the code file when the base code is empty.
[0060] The deployment module includes: Script generation unit: used to generate simulation test scripts based on user activity logs in the aforementioned data collection logs; Simulation test unit: used to perform simulation tests on the optimized code based on the simulation test script; Deployment control unit: used to deploy the optimized code to a preset environment based on the test results corresponding to the simulation test.
[0061] The acquisition module includes: Candidate file acquisition unit: used to acquire one or more candidate files corresponding to the problem type based on the path information in the problem information and through a preset code repository tool; Version matching unit: When there is no corresponding candidate file based on the event log or the currently deployed version identifier, the latest candidate file is used as the code file.
[0062] The acquisition module further includes: Complete file acquisition unit: used to acquire the complete file based on the path information in the problem information using a preset code repository tool; Association value calculation unit: used to calculate the association value between the code block in the code file and the problem type based on the problem type; Target code determination unit: used to determine the target code in the complete file based on the associated value and use the target code as a code file.
[0063] Among them, the coverage rate of the tracking points corresponding to the key events is greater than 95%.
[0064] The detection module includes: Monitoring unit: Used to monitor pre-defined core rendering metrics, core resources, and high-frequency errors; Page loading detection unit: used to confirm the existence of a slow page loading problem when the core rendering metric exceeds a preset time threshold; Resource loading detection unit: used to confirm the existence of a resource loading problem when the core resource fails to load or the total resource loading time exceeds a preset third time threshold; High-frequency error detection unit: used to confirm the existence of historical high-frequency error problems when the high-frequency error is detected.
[0065] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4 As shown, the electronic device may include: a processor 310, a communication interface 320, a memory 330, and a communication bus 340, wherein the processor 310, the communication interface 320, and the memory 330 communicate with each other via the communication bus 340. The processor 310 can call logical instructions in the memory 330 to execute an automated method for repairing front-end rendering defects, the method including: Identify key events in the front-end application and determine at least one event tracking component corresponding to the key event; The event tracking component is used to track events, and the event tracking logs generated by the event tracking component when the key event occurs are obtained. Based on the aforementioned tracking logs, the system detects whether there are any preset problems and their corresponding problem types on the front-end page, and generates problem information containing the problem type and corresponding path information when a problem is detected. Based on the path information, obtain the code file corresponding to the problem type; The problem information, event logs, and code files are aggregated, analyzed and reasoned using a preset large language model, and code problems are retrieved based on the problem type to generate optimized code. Deploy the optimized code to the preset environment.
[0066] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0067] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program that can be stored on a non-transitory computer-readable storage medium, wherein when the computer program is executed by a processor, the computer is capable of executing the automated front-end rendering defect repair method provided by the above methods, the method comprising: Identify key events in the front-end application and determine at least one event tracking component corresponding to the key event; The event tracking component is used to track events, and the event tracking logs generated by the event tracking component when the key event occurs are obtained. Based on the aforementioned tracking logs, the system detects whether there are any preset problems and their corresponding problem types on the front-end page, and generates problem information containing the problem type and corresponding path information when a problem is detected. Based on the path information, obtain the code file corresponding to the problem type; The problem information, event logs, and code files are aggregated, analyzed and reasoned using a preset large language model, and code problems are retrieved based on the problem type to generate optimized code. Deploy the optimized code to the preset environment.
[0068] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements an automated method for repairing front-end rendering defects provided by the methods described above, the method comprising: Identify key events in the front-end application and determine at least one event tracking component corresponding to the key event; The event tracking component is used to track events, and the event tracking logs generated by the event tracking component when the key event occurs are obtained. Based on the aforementioned tracking logs, the system detects whether there are any preset problems and their corresponding problem types on the front-end page, and generates problem information containing the problem type and corresponding path information when a problem is detected. Based on the path information, obtain the code file corresponding to the problem type; The problem information, event logs, and code files are aggregated, analyzed and reasoned using a preset large language model, and code problems are retrieved based on the problem type to generate optimized code. Deploy the optimized code to the preset environment.
[0069] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.
[0070] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.
[0071] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention 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 of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. An automated method for repairing front-end rendering defects, characterized in that, include: Identify key events in the front-end application and determine at least one tracking component corresponding to the key events; The event tracking component is used to track events, and the event tracking logs generated by the event tracking component when the key event occurs are obtained. Based on the aforementioned tracking logs, the system detects whether there are any preset problems and their corresponding problem types on the front-end page, and generates problem information containing the problem type and corresponding path information when a problem is detected. Based on the path information, obtain the code file corresponding to the problem type; The problem information, event logs, and code files are aggregated, analyzed and reasoned using a preset large language model, and code problems are retrieved based on the problem type to generate optimized code. Deploy the optimized code to the preset environment.
2. The automated repair method for front-end rendering defects according to claim 1, characterized in that, The process of aggregating the problem information, event logs, and code files, analyzing and reasoning using a pre-defined large language model, retrieving code issues based on the problem type, and generating optimized code includes: Based on the problem information, the corresponding basic code is identified in the preset knowledge base; When the base code is not empty, optimized code is generated based on the base code, the code file, and the event logs. When the base code is empty, optimized code is generated based on the problem information, the tracking logs, and the code file.
3. The automated repair method for front-end rendering defects according to claim 1, characterized in that, The key events include user activity events, and the event tracking logs include user activity logs corresponding to the user activity events; deploying the optimized code to the preset environment includes: A simulation test script is generated based on the user activity logs in the aforementioned data collection logs; Based on the simulation test script, the optimized code is subjected to simulation testing; Based on the test results corresponding to the simulation test, the optimized code is deployed to the preset environment.
4. The automated repair method for front-end rendering defects according to claim 1, characterized in that, The step of obtaining the code file corresponding to the problem type based on the path information in the problem information includes: Based on the path information in the problem information, one or more candidate files corresponding to the problem type are obtained through a preset code repository tool; When no corresponding candidate file is found based on the event logs or the current deployment version identifier, the latest candidate file is used as the code file.
5. The automated repair method for front-end rendering defects according to claim 1 or 4, characterized in that, The step of obtaining the code file corresponding to the problem type based on the path information in the problem information further includes: Based on the path information in the problem information, the complete file is obtained through a preset code repository tool; Based on the problem type, calculate the association value between the code block in the code file and the problem type; Based on the associated value, the target code in the complete file is determined and the target code is used as the code file.
6. The automated repair method for front-end rendering defects according to claim 1, characterized in that, The coverage rate of the tracking points corresponding to the key events is greater than 95%.
7. The automated repair method for front-end rendering defects according to claim 1, characterized in that, The step of detecting whether a preset problem and its corresponding problem type exist on the front-end page based on the event logs, and generating problem information including the problem type and corresponding path information when a problem is detected, includes: Monitor pre-defined core rendering metrics, core resources, and high-frequency errors; When the core rendering metric exceeds a preset time threshold, it is confirmed that there is a slow page loading issue. When the core resource fails to load, or the total time taken to load the resource exceeds a preset third time threshold, a resource loading problem is confirmed. When the high-frequency error is detected, it confirms the existence of a historical high-frequency error problem.
8. An automated repair device for front-end rendering defects, characterized in that, include: A determination module is used to determine key events in the front-end application and to determine at least one tracking component corresponding to the key events; The event tracking module is used to track events on the event tracking component and obtain the event tracking logs generated by the event tracking component when the key event occurs. The detection module is used to detect whether there are preset problems and corresponding problem types on the front-end page based on the data entry logs, and generate problem information containing problem type and corresponding path information when a problem is detected. The acquisition module is used to acquire the code file corresponding to the problem type based on the path information; The generation module is used to aggregate the problem information, the tracking logs and the code files, analyze and reason through a preset large language model, retrieve code problems based on the problem type and generate optimized code; The deployment module is used to deploy the optimized code to a preset environment.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the automated repair method for front-end rendering defects as described in any one of claims 1 to 7.
10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the automated repair method for front-end rendering defects as described in any one of claims 1 to 7.
Citation Information
Cited By
Front-end code generation method, electronic device, storage medium and program product
CN122152313A