A method and device for repairing application program failure

Abstract

The present application proposes a method and device for repairing application faults, and relates to the field of computer technology. The present application receives abnormal event logs and auxiliary analysis data corresponding to a target application uploaded by a user device, the auxiliary analysis data including at least one of a device performance log corresponding to the user device and a user operation log corresponding to the target application; analyzes the abnormal event logs and auxiliary analysis data to determine the potential fault corresponding to the target application; obtains a first fault category of the potential fault, and obtains real-time performance parameters corresponding to the user device; matches a first target repair strategy corresponding to the potential fault from a repair strategy library based on the first fault category and the real-time performance parameters, and sends the first target repair strategy to the user device for fault repair. The present application can reduce troubleshooting time, repair potential faults in a timely manner, and improve user satisfaction with the target application.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method and device for repairing a fault of an application program. Background Art

[0002] With the widespread use of mobile devices, users have put forward higher requirements for the stability and reliability of applications. The popularity of smartphones and tablets has led to more and more users relying on mobile applications for daily activities, such as social media, online shopping, banking, etc. However, due to the diversity of Android device hardware and software environments, coupled with the vast differences in user operating habits, applications are prone to various problems in different user environments, such as memory leaks, interface freezes, data errors, etc.

[0003] Traditional manual repair methods are inefficient in solving these problems. Developers can often only make repairs after receiving user feedback and are unable to respond to various potential problems in a timely manner. Summary of the invention

[0004] The present disclosure provides a method and device for repairing application faults, so as to at least solve the problem that the traditional manual repair method in the related art is inefficient in solving these problems, and developers can often only repair them after receiving user feedback, and cannot deal with various potential problems in a timely manner.

[0005] The first aspect of the present application proposes a method for fault repairing an application, comprising: receiving an abnormal event log and auxiliary analysis data corresponding to a target application uploaded by a user device, the auxiliary analysis data including at least one of a device performance log corresponding to the user device and a user operation log corresponding to the target application; analyzing the abnormal event log and the auxiliary analysis data to determine a potential fault corresponding to the target application; obtaining a first fault category of the potential fault, and obtaining real-time performance parameters corresponding to the user device; matching a first target repair strategy corresponding to the potential fault from a repair strategy library based on the first fault category and the real-time performance parameters, and sending the first target repair strategy to the user device for fault repair.

[0006] According to one embodiment of the present application, the fault repair method of the application also includes: analyzing the abnormal event log to determine the explicit fault corresponding to the target application; obtaining a second fault category of the explicit fault; matching the second target repair strategy corresponding to the explicit fault from the repair strategy library based on the second fault category and real-time performance parameters; and sending the second target repair strategy to the user device for fault repair.

[0007] According to an embodiment of the present application, a first target repair strategy corresponding to a potential fault is obtained by matching from a repair strategy library based on a first fault category and a real-time performance parameter, or a second target repair strategy corresponding to an explicit fault is obtained by matching from a repair strategy library based on a second fault category and a real-time performance parameter, including: for any fault category in the first fault category and the second fault category, a plurality of candidate repair strategy templates corresponding to any fault category are matched from the repair strategy library; a target repair strategy template is determined from a plurality of candidate repair strategy templates based on the real-time performance parameter and the template content is filled, and the target repair strategy obtained after filling is obtained.

[0008] According to one embodiment of the present application, in response to the auxiliary analysis data including the user operation log, the abnormal event log and the auxiliary analysis data are analyzed to determine the potential faults corresponding to the target application, including: determining the target abnormal event from the abnormal event log, and obtaining a first number of the target abnormal event in the abnormal event log; obtaining a timestamp corresponding to each occurrence of the target abnormal event, and tracing back a preset time period based on the timestamp to obtain multiple target time periods corresponding to the target abnormal event; intercepting the user operation log based on the target time period, and obtaining multiple target operation data obtained after interception; performing user behavior correlation analysis on the target operation data and the target abnormal event in combination with the first number, and obtaining potential faults obtained by analysis.

[0009] According to one embodiment of the present application, a user behavior correlation analysis is performed on the target operation data and the target abnormal event in combination with the first quantity to obtain potential faults obtained by the analysis, including: determining whether there is a target operation behavior that is repeatedly executed more than N times in any target operation data corresponding to the target abnormal event, and if so, marking the target operation data with a target operation behavior label corresponding to the target operation behavior; obtaining a second quantity of each target operation behavior label; for any target operation behavior label, taking the ratio of the second quantity of the target operation behavior label to the first quantity as the occurrence frequency of the target operation behavior label; in response to the occurrence frequency of the target operation behavior label being greater than the first frequency threshold, determining that the target application has a first potential fault related to the target operation behavior label.

[0010] According to one embodiment of the present application, a user behavior correlation analysis is performed on the target operation data and the target abnormal event in combination with the first quantity to obtain potential faults obtained by the analysis, and also includes: obtaining the operation behavior sequence contained in each target operation data corresponding to the target abnormal event; obtaining a third quantity corresponding to each operation behavior sequence; for any operation behavior sequence, taking the ratio of the third quantity corresponding to the operation behavior sequence to the first quantity as the occurrence frequency of the operation behavior sequence; in response to the occurrence frequency of the operation behavior sequence being greater than a second frequency threshold, determining that the target application has a second potential fault related to the operation behavior sequence.

[0011] According to an embodiment of the present application, a user behavior correlation analysis is performed on the target operation data and the target abnormal event in combination with the first quantity to obtain potential faults obtained by the analysis, and also includes: obtaining the first end operation behavior contained in each target operation data corresponding to the target abnormal event, wherein the first end operation behavior refers to the last operation behavior contained in the target operation data; obtaining the fourth quantity of each first end operation behavior; for any first end operation behavior, taking the ratio of the fourth quantity to the first quantity as the occurrence frequency of the first end operation behavior; in response to the occurrence frequency of the first end operation behavior being greater than the third frequency threshold, determining that the target application has a third potential fault related to the first end operation behavior.

[0012] According to one embodiment of the present application, in response to the auxiliary analysis data also including device performance logs, the application fault repair method also includes: intercepting the device performance logs based on the target time period, and obtaining multiple target performance data obtained after the interception; calculating each target performance data corresponding to the target abnormal event, and obtaining the average resource utilization rate corresponding to each target performance data; marking the target performance data whose average resource utilization rate is greater than a preset resource utilization rate threshold as abnormal target performance data, and obtaining the fifth number of abnormal target performance data; taking the ratio of the fifth number to the first number as the frequency of occurrence of abnormal target performance data; in response to the frequency of occurrence of abnormal target performance data being greater than a fourth frequency threshold, determining that a fourth potential fault has occurred in the target application.

[0013] According to one embodiment of the present application, the fault repair method of an application also includes: after determining the abnormal target performance data, determining the associated target operation data related to the abnormal target performance data from the target operation data; obtaining the second last operation behavior contained in each associated target operation data, wherein the second last operation behavior refers to the last operation behavior contained in the associated target operation data; obtaining the sixth quantity of each second last operation behavior; for any second last operation behavior, taking the ratio of the sixth quantity to the fifth quantity as the occurrence frequency of the second last operation behavior; in response to the occurrence frequency of the second last operation behavior being greater than the fifth frequency threshold, determining that the target application has a fifth potential fault.

[0014] According to one embodiment of the present application, the exception event log is analyzed to determine the explicit fault corresponding to the target application, including: obtaining exception stack information in the exception event log; obtaining the exception class name and exception class method included in the exception stack information, and determining the explicit fault corresponding to the target application based on the exception class name and exception class method.

[0015] The second aspect of the present application proposes an application fault repair device, including: a receiving module, used to receive an abnormal event log and auxiliary analysis data corresponding to a target application uploaded by a user device, the auxiliary analysis data including at least one of a device performance log corresponding to the user device and a user operation log corresponding to the target application; an analysis module, used to analyze the abnormal event log and the auxiliary analysis data to determine the potential fault corresponding to the target application; an acquisition module, used to obtain a first fault category of the potential fault, and to obtain real-time performance parameters corresponding to the user device; a sending module, used to match a first target repair strategy corresponding to the potential fault from a repair strategy library based on the first fault category and the real-time performance parameters, and send the first target repair strategy to the user device for fault repair.

[0016] According to one embodiment of the present application, the analysis module is also used to analyze the abnormal event log to determine the explicit fault corresponding to the target application; the acquisition module is also used to obtain the second fault category of the explicit fault; the sending module is also used to match the second target repair strategy corresponding to the explicit fault from the repair strategy library based on the second fault category and real-time performance parameters; and send the second target repair strategy to the user device for fault repair.

[0017] According to one embodiment of the present application, the sending module is also used to: for any fault category in the first fault category and the second fault category, match multiple candidate repair strategy templates corresponding to any fault category from the repair strategy library; determine a target repair strategy template from the multiple candidate repair strategy templates based on real-time performance parameters and fill in the template content, and obtain the target repair strategy after filling.

[0018] According to one embodiment of the present application, the analysis module is also used to: determine the target abnormal event from the abnormal event log, and obtain a first number of the target abnormal events in the abnormal event log; obtain the timestamp corresponding to each occurrence of the target abnormal event, and trace back a preset time period based on the timestamp to obtain multiple target time periods corresponding to the target abnormal event; intercept the user operation log based on the target time period, and obtain multiple target operation data obtained after interception; perform user behavior correlation analysis on the target operation data and the target abnormal event in combination with the first number, and obtain potential faults obtained by analysis.

[0019] According to one embodiment of the present application, the analysis module is also used to: determine whether there is a target operation behavior that is repeatedly executed more than N times in any target operation data corresponding to the target abnormal event, and if so, mark the target operation data with a target operation behavior label corresponding to the target operation behavior; obtain a second number of each target operation behavior label; for any target operation behavior label, take the ratio of the second number of target operation behavior labels to the first number as the occurrence frequency of the target operation behavior label; in response to the occurrence frequency of the target operation behavior label being greater than the first frequency threshold, determine that the target application has a first potential fault related to the target operation behavior label.

[0020] According to one embodiment of the present application, the analysis module is also used to: obtain the operation behavior sequence contained in each target operation data corresponding to the target abnormal event; obtain the third quantity corresponding to each operation behavior sequence; for any operation behavior sequence, take the ratio of the third quantity corresponding to the operation behavior sequence to the first quantity as the occurrence frequency of the operation behavior sequence; in response to the occurrence frequency of the operation behavior sequence being greater than a second frequency threshold, determine that the target application has a second potential fault related to the operation behavior sequence.

[0021] According to one embodiment of the present application, the analysis module is also used to: obtain the first end operation behavior contained in each target operation data corresponding to the target abnormal event, wherein the first end operation behavior refers to the last operation behavior contained in the target operation data; obtain the fourth quantity of each first end operation behavior; for any first end operation behavior, use the ratio of the fourth quantity to the first quantity as the occurrence frequency of the first end operation behavior; in response to the occurrence frequency of the first end operation behavior being greater than the third frequency threshold, determine that the target application has a third potential fault related to the first end operation behavior.

[0022] According to one embodiment of the present application, the analysis module is also used to: intercept the device performance log based on the target time period to obtain multiple target performance data obtained after the interception; calculate each target performance data corresponding to the target abnormal event to obtain the average resource utilization rate corresponding to each target performance data; mark the target performance data whose average resource utilization rate is greater than a preset resource utilization rate threshold as abnormal target performance data, and obtain the fifth number of abnormal target performance data; use the ratio of the fifth number to the first number as the frequency of occurrence of abnormal target performance data; in response to the frequency of occurrence of abnormal target performance data being greater than a fourth frequency threshold, determine that a fourth potential fault occurs in the target application.

[0023] According to one embodiment of the present application, the analysis module is also used to: after determining the abnormal target performance data, determine the associated target operation data related to the abnormal target performance data from the target operation data; obtain the second end operation behavior contained in each associated target operation data, wherein the second end operation behavior refers to the last operation behavior contained in the associated target operation data; obtain the sixth quantity of each second end operation behavior; for any second end operation behavior, take the ratio of the sixth quantity to the fifth quantity as the occurrence frequency of the second end operation behavior; in response to the occurrence frequency of the second end operation behavior being greater than the fifth frequency threshold, determine that the target application has a fifth potential fault.

[0024] According to one embodiment of the present application, the analysis module is also used to: obtain exception stack information in the exception event log; obtain the exception class name and exception class method included in the exception stack information, and determine the explicit fault corresponding to the target application based on the exception class name and exception class method.

[0025] The third aspect embodiment of the present application proposes an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to implement the fault repair method of the application as described in the first aspect embodiment of the present application.

[0026] The fourth aspect embodiment of the present application proposes a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to implement the fault repair method of the application as described in the first aspect embodiment of the present application.

[0027] The fifth aspect embodiment of the present application proposes a computer program product, including a computer program, which, when executed by a processor, implements the fault repair method of the application as described in the first aspect embodiment of the present application.

[0028] The technical solution provided by the embodiments of the present disclosure brings at least the following beneficial effects: by analyzing abnormal event logs and auxiliary analysis data, the present application can quickly identify potential faults of the target application and reduce troubleshooting time; based on the first fault category and real-time performance parameters, it can match the most suitable repair strategy from the repair strategy library, thereby improving the accuracy and effectiveness of the repair; by automatically issuing repair strategies, manual intervention is reduced, the efficiency of fault handling is improved, and the operation and maintenance costs are reduced; timely repair of potential faults can improve user satisfaction with the target application and reduce usage interruptions caused by faults.

[0029] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0031] Figure 1 It is a schematic diagram of an exemplary implementation of a method for repairing a fault of an application program shown in an embodiment of the present application.

[0032] Figure 2 It is a schematic diagram of an exemplary implementation of a method for repairing a fault of an application program shown in an embodiment of the present application.

[0033] Figure 3 It is an exemplary schematic diagram of a fault recovery device for an application program shown in an embodiment of the present application.

[0034] Figure 4 It is a schematic diagram of an electronic device shown in one embodiment of the present application. DETAILED DESCRIPTION

[0035] Embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0036] It should be noted that the acquisition, transmission, storage, use, and processing of data in the technical solution of this application are in compliance with the relevant provisions of national laws and regulations.

[0037] Figure 1 is a schematic diagram of an exemplary implementation of a method for repairing a fault of an application program shown in the present application, such as Figure 1 As shown, the fault repair method of the application includes the following steps:

[0038] S101, receiving an abnormal event log and auxiliary analysis data corresponding to a target application uploaded by a user device, where the auxiliary analysis data includes at least one of a device performance log corresponding to the user device and a user operation log corresponding to the target application.

[0039] In the present application, the fault recovery method of the application is executed by the server.

[0040] The target application refers to the application installed on the user device and for which fault analysis is required.

[0041] The method for obtaining the abnormal event log is as follows: a first monitoring code set on the target application captures unhandled exceptions that occur during the operation of the target application and generates an abnormal event log, and then uploads the abnormal event log to the server.

[0042] Among them, the method for obtaining the device performance log is: the second monitoring code set on the user device regularly monitors the performance status of the user device, such as memory usage, CPU load, network status, device model and other parameters, generates a device performance log, and uploads the device performance log to the server. Among them, in order to avoid excessive interference with performance, the second monitoring code uses low-frequency sampling and lightweight calculation to minimize the impact on the main thread. For example, performance sampling is performed once at a certain time interval, and the data is asynchronously stored to reduce resource overhead.

[0043] Among them, the method for obtaining user operation logs: the operation event listening code set on the target application (the operation event listening code is inserted into the UI interactive components of the target application, such as buttons, sliding areas, input boxes and other components) can monitor the user's click, slide, input and other operation events, and record the time, type and target component of these interactive behaviors in real time; and, based on the life cycle tracking listening code set on the target application, record the user's behavior on different pages and page jump information, and generate a user operation log based on the data recorded by the operation event listening code and the life cycle tracking operation event listening code, and upload the user operation log to the server.

[0044] Among them, the above-mentioned first monitoring code, second monitoring code, operation event monitoring code and periodic tracking monitoring code are inserted using lightweight plug-in technology to insert the monitoring code in as few key locations as possible, such as the entry points of user interaction and key nodes of the core logic of the application, rather than covering a large area. This helps to reduce interference with the main thread of the application and ensure application performance.

[0045] In order to reduce the impact of the instrumented code on the performance of the target application, all abnormal event logs and auxiliary analysis data are stored and uploaded in an asynchronous manner. By first storing the abnormal event logs and auxiliary analysis data in the memory of the user's device, then writing them in batches to files or databases, and uploading them to the server regularly, frequent IO operations are avoided from affecting the smoothness of the application.

[0046] S102, analyzing the abnormal event log and the auxiliary analysis data to determine the potential faults corresponding to the target application.

[0047] Optionally, the server may analyze the abnormal event log and auxiliary analysis data of each user device separately to determine the potential fault corresponding to each user device. For example, the server may analyze the abnormal event log and auxiliary analysis data sent by user device A to determine the potential fault corresponding to the target application installed on user device A. Similarly, the server may analyze the abnormal event log and auxiliary analysis data sent by user device B to determine the potential fault corresponding to the target application installed on user device B.

[0048] Optionally, the server may also collect a large number of abnormal event logs and auxiliary analysis data of each user device for analysis to determine the potential failure of the target application from a large amount of data, and after subsequently determining the first target repair strategy for the potential failure, send the first target repair strategy to the user device with the corresponding potential failure.

[0049] In some embodiments, if the auxiliary analysis data only includes user operation logs, the association between the user's operation behavior and the abnormal event logs is analyzed based on the abnormal event logs and the user operation logs. For example, suppose the abnormal event log records an application crash, and the user operation log shows that the user performed a series of specific operations before the crash, such as opening a certain functional module and submitting data. If the consistency of these operations at the time of the crash is confirmed, it can be inferred that there may be a problem with the functional module, which caused the crash.

[0050] In some embodiments, if the auxiliary analysis data only includes device performance logs, the device performance logs (such as CPU usage, memory usage, network latency, etc.) are combined with abnormal event logs to find the relationship between performance bottlenecks and resource consumption and abnormal events. For example, if the abnormal event log shows that an application crashes frequently, and the device performance log shows that the CPU usage reached 100% and the memory usage was close to the limit at the time of the crash, it can be inferred that the application lacked sufficient resource support under high load conditions, resulting in the crash.

[0051] In some embodiments, if the auxiliary analysis data includes user operation logs and device performance logs, the abnormal event logs are combined with the user operation logs and device performance logs to comprehensively analyze the user operations and device performance conditions when the abnormality occurred, thereby identifying potential faults. For example, suppose a delayed crash event of an application is recorded in the abnormal event log, the user operation log shows that the user tried to load a complex report before the crash, and the device performance log shows that memory usage has reached a peak and network latency has increased. In this case, it can be inferred that the user's specific operation (loading a complex report) caused the device performance to degrade and ultimately caused the crash. This analysis can help the development team optimize the application to handle more complex user requests or improve performance.

[0052] S103: Obtain a first fault category of a potential fault, and obtain a real-time performance parameter corresponding to the user equipment.

[0053] After the potential fault is determined, the first fault category of the potential fault is obtained. For example, the first fault category may be UI operation exception, memory leak, resource conflict, thread competition, null pointer exception, etc.

[0054] And, after the potential fault is determined as described above, the real-time performance parameters corresponding to the user equipment are obtained, such as the real-time CPU usage, memory usage, network latency, mobile phone model and other key performance indicators of the user equipment.

[0055] S104: Based on the first fault category and the real-time performance parameter, a first target repair strategy corresponding to the potential fault is matched from a repair strategy library, and the first target repair strategy is sent to the user equipment for fault repair.

[0056] A set of repair strategy libraries are pre-configured, which contain repair strategies for common problems. For example, for null pointer exceptions, the repair strategy may include adding null value checks to the problem code segment; for memory leaks, the repair strategy may be to release resources that are not managed correctly. Each first fault category corresponds to multiple sets of repair strategies. Then, according to the real-time performance parameters, the most suitable repair strategy for the user device is determined from the multiple sets of repair strategies as the first target repair strategy.

[0057] For example, if it is determined based on real-time performance parameters that the user device has a higher performance space, a repair strategy with the best effect can be determined from multiple sets of repair strategies as the first target repair strategy without excessively considering the performance occupied by the best repair strategy; if it is determined based on real-time performance parameters that the user device has a very low performance space, a repair strategy with the least performance can be determined from multiple sets of repair strategies as the first target repair strategy to avoid increasing the load on the user device.

[0058] Exemplarily, if the first fault category is "performance problem" and it is found that the memory usage is too high, the first target repair strategy obtained by matching may be to improve the memory allocation and recycling mechanism and reduce memory leaks.

[0059] Among them, the first target repair strategy can be in various forms, as follows:

[0060] 1. Instrumentation repair: Insert detection and recovery code into key code segments to prevent the error from happening again.

[0061] 2. Mapping repair: Adjust improper parameters or paths by modifying configuration files or resource files.

[0062] 3. Parameter adjustment: Automatically adjust the application's system configuration parameters, such as memory allocation, network timeout, etc., to adapt to different device environments.

[0063] After the first target repair strategy is determined, the first target repair strategy is sent to the corresponding user equipment. The first target repair strategy can be implemented by automatically updating or prompting the user to manually operate.

[0064] The embodiment of the present application proposes a method for fault repair of an application, including: receiving an abnormal event log and auxiliary analysis data corresponding to a target application uploaded by a user device, the auxiliary analysis data including at least one of a device performance log corresponding to the user device and a user operation log corresponding to the target application; analyzing the abnormal event log and the auxiliary analysis data to determine the potential fault corresponding to the target application; obtaining a first fault category of the potential fault, and obtaining a real-time performance parameter corresponding to the user device; matching a first target repair strategy corresponding to the potential fault from a repair strategy library based on the first fault category and the real-time performance parameter, and sending the first target repair strategy to the user device for fault repair. The present application can quickly identify the potential fault of the target application by analyzing the abnormal event log and the auxiliary analysis data, and reduce the troubleshooting time; based on the first fault category and the real-time performance parameter, it can match the most suitable repair strategy from the repair strategy library, thereby improving the accuracy and effectiveness of the repair; by automatically sending the repair strategy, it reduces manual intervention, improves the efficiency of fault handling, and reduces the operation and maintenance cost; timely repair of potential faults can improve user satisfaction with the target application and reduce the use interruption caused by faults.

[0065] Furthermore, in actual applications, the first monitoring code, the second monitoring code, the operation event monitoring code, the periodic tracking monitoring code and other instrumentation codes can be enabled and disabled through configuration files or dynamic policies. For example, the granularity of monitoring can be reduced or unnecessary logging can be disabled on performance-sensitive devices to meet the performance requirements in different environments.

[0066] Figure 2 is a schematic diagram of an exemplary implementation of a method for repairing a fault of an application program shown in the present application, such as Figure 2 As shown, the fault repair method of the application includes the following steps:

[0067] S201, receiving an abnormal event log and auxiliary analysis data corresponding to a target application uploaded by a user device, where the auxiliary analysis data includes at least one of a device performance log corresponding to the user device and a user operation log corresponding to the target application.

[0068] The specific implementation method of step S201 has been specifically introduced in the above embodiment and will not be repeated here.

[0069] S202: Analyze the abnormal event log and the auxiliary analysis data to determine the potential faults corresponding to the target application.

[0070] In some embodiments, if the auxiliary analysis data includes a user operation log, the target abnormal event is determined from the abnormal event log (the abnormal event that occurs more frequently can be used as the target abnormal event), and a first number of target abnormal events in the abnormal event log is obtained (the first number is the total number of target abnormal events that appear in the abnormal event log); the timestamp corresponding to each occurrence of the target abnormal event is obtained, and based on the timestamp, multiple target time periods corresponding to the target abnormal event are obtained by tracing back a preset time length; the user operation log is intercepted based on the target time period, and multiple target operation data obtained after the interception are obtained; user behavior correlation analysis is performed on the target operation data and the target abnormal event in combination with the first number, and potential faults obtained by the analysis are obtained.

[0071] For example, in the abnormal event log within a period of time, if the "payment failure" event occurs 100 times, the "payment failure" event is used as the target abnormal event, and the first number of the "payment failure" event is determined to be 100. The timestamps corresponding to the 100 "payment failure" events are obtained, that is, a total of 100 timestamps are obtained. Assuming that the preset time length based on the timestamp is 1 minute, then based on the 100 timestamps, each is traced back 1 minute, and a total of 100 target time periods are obtained. For example, if the timestamp of one of the "payment failure" events is: November 1, 2024 08:05:00, then the target time period corresponding to the "payment failure" event is: November 1, 2024 08:04:00~November 1, 2024 08:05:00, and so on. After determining the 100 target time periods, the corresponding user operation logs are intercepted based on the 100 target time periods (if the server collects data from a large number of user devices for unified analysis, it is necessary to intercept the user operation logs uploaded by the user devices corresponding to the target abnormal events), and obtain multiple target operation data obtained after interception. Then, user behavior correlation analysis is performed on the target operation data and the target abnormal events in combination with the first quantity to obtain potential faults obtained by analysis.

[0072] Specifically, a user behavior correlation analysis is performed on the target operation data and the target abnormal event in combination with the first quantity to obtain potential faults obtained through the analysis, with the following three cases being used as examples:

[0073] For the first case (anomaly caused by the user repeatedly performing a certain operation), the analysis process is as follows: determine whether there is a target operation behavior that is repeated more than N times in each target operation data corresponding to the target abnormal event; if so, mark the target operation data with the target operation behavior label corresponding to the target operation behavior (for example, if the continuous clicks exceed N times, then mark it with a continuous click label; if the continuous slides exceed N times, then mark it with a continuous slide label); count the number of labels for all target operation data to obtain the second number of each target operation behavior label; for any target operation behavior label, take the ratio of the second number of target operation behavior labels to the first number as the occurrence frequency of the target operation behavior label; if the occurrence frequency of the target operation behavior label is greater than the first frequency threshold, determine that the target application has a first potential fault related to the target operation behavior label. For example, if the first number of "payment failure" events is 100, and if the continuous click tag in the target operation behavior tag corresponding to the "payment failure" event appears 60 times, it can be considered that the occurrence frequency of the continuous click tag is 0.6. If 0.6 is greater than the second frequency threshold, it is considered that the continuous click behavior will cause the "payment failure" event, that is, it is considered that the target application has the first potential fault caused by the continuous click behavior.

[0074] In the second case (abnormality caused by a user performing a specific operation sequence), the analysis process is as follows: obtain the operation behavior sequence (for example, operation 1→operation 2→operation 3) contained in each target operation data corresponding to the target abnormal event; perform quantitative statistics on the operation behavior sequence of all target operation data, and obtain the third quantity corresponding to each operation behavior sequence; for any operation behavior sequence, take the ratio of the third quantity corresponding to the operation behavior sequence to the first quantity as the occurrence frequency of the operation behavior sequence; if the occurrence frequency of the operation behavior sequence is greater than the second frequency threshold, determine that the target application has a second potential fault related to the operation behavior sequence. For example, if the first quantity of the "payment failure" event is 100, if the operation behavior sequence corresponding to the "payment failure" event is operation 1→operation 2→operation 3 for 70 times, it can be considered that the occurrence frequency of the sequence is 0.7. If 0.7 is greater than the second frequency threshold, it is considered that the operation sequence of operation 1→operation 2→operation 3 will cause the "payment failure" event, that is, it is considered that the target application has a second potential fault caused by the operation sequence of operation 1→operation 2→operation 3.

[0075] In the third case (the abnormality caused by the last operation of the user), the analysis process is as follows: obtain the first last operation behavior contained in each target operation data corresponding to the target abnormal event, wherein the first last operation behavior refers to the last operation behavior contained in the target operation data (for example, the last operation behavior can be a click, a slide, or an exit interface behavior); obtain the fourth number of each first last operation behavior; for any first last operation behavior, take the ratio of the fourth number to the first number as the frequency of occurrence of the first last operation behavior; if the frequency of occurrence of the first last operation behavior is greater than the third frequency threshold, determine that the target application has a third potential fault related to the first last operation behavior. For example, if the first number of "payment failure" events is 100, if the sliding behavior appears 40 times in the first last operation behavior corresponding to the "payment failure" event, it can be considered that the frequency of the first last operation behavior being the sliding behavior is 0.4. If 0.4 is greater than the third frequency threshold, it is considered that the sliding behavior will cause the "payment failure" event, that is, it is considered that the target application has a third potential fault caused by the first last operation behavior being the sliding behavior.

[0076] In some embodiments, if the auxiliary analysis data also includes device performance logs, a fourth analysis situation may also occur (abnormalities caused by insufficient resources). The analysis process is: intercepting the device performance logs based on the target time period, and obtaining multiple target performance data obtained after the interception; calculating each target performance data corresponding to the target abnormal event, and obtaining the average resource utilization rate corresponding to each target performance data (for example, the average CPU utilization rate and the average memory utilization rate in the minute before the target abnormal event occurs); marking the target performance data whose average resource utilization rate is greater than the preset resource utilization rate threshold as abnormal target performance data, and obtaining the fifth number of abnormal target performance data; taking the ratio of the fifth number to the first number as the frequency of occurrence of abnormal target performance data; if the frequency of occurrence of abnormal target performance data is greater than the fourth frequency threshold, determining that the target application has a fourth potential fault. For example, if the first number of "payment failure" events is 100, and if the average CPU usage corresponding to the "payment failure" event exceeds the standard and is recorded as the number of abnormal target performance data is 80, then the frequency of occurrence can be considered to be 0.8. If 0.8 is greater than the fourth frequency threshold, it is considered that the excessive CPU usage will cause the "payment failure" event, that is, it is considered that the target application has the fourth potential fault caused by the excessive average CPU usage.

[0077] In some embodiments, if the auxiliary analysis data includes device performance logs in addition to user operation logs, a fifth situation may also occur (anomalies caused by certain operations performed when resources are insufficient). The analysis process is: after determining the abnormal target performance data, determine the associated target operation data related to the abnormal target performance data from the target operation data (for example, if the 9th target performance data is marked as abnormal target performance data, then the target operation data belonging to the same target time period as the 9th target performance data is taken as the associated target operation data related to the 9th target performance data); obtain the second last operation behavior contained in each associated target operation data, wherein the second last operation behavior refers to the last operation behavior contained in the associated target operation data; obtain the sixth number of each second last operation behavior; for any second last operation behavior, take the ratio of the sixth number to the fifth number as the occurrence frequency of the second last operation behavior; in response to the occurrence frequency of the second last operation behavior being greater than the fifth frequency threshold, determine that the target application has a fifth potential fault.

[0078] Among them, the values ​​of the first frequency threshold, the second frequency threshold, the third frequency threshold, the fourth frequency threshold, and the fifth frequency threshold can be set according to actual conditions, and can be the same or different.

[0079] S203: Obtain a first fault category of a potential fault, and obtain a real-time performance parameter corresponding to the user equipment.

[0080] After the potential fault is determined, the first fault category of the potential fault is obtained. For example, the first fault category may be UI operation exception, memory leak, resource conflict, thread competition, null pointer exception, etc.

[0081] And, after the potential fault is determined as described above, the real-time performance parameters corresponding to the user equipment are obtained, such as the real-time CPU usage, memory usage, network latency, mobile phone model and other key performance indicators of the user equipment.

[0082] S204: Based on the first fault category and the real-time performance parameter, a first target repair strategy corresponding to the potential fault is matched from a repair strategy library, and the first target repair strategy is sent to the user equipment for fault repair.

[0083] Multiple candidate repair strategy templates corresponding to the first fault category are matched from the repair strategy library; based on the real-time performance parameters, a target repair strategy template is determined from the multiple candidate repair strategy templates and the template content is filled (for example, parameters such as filling threshold configuration and storage path configuration), and the first target repair strategy obtained after filling is obtained.

[0084] For example, if it is determined based on real-time performance parameters that the user device has a higher performance space, a repair policy template with the best effect can be determined from multiple sets of repair policy templates as the target repair policy template and the template content can be filled to obtain the first target repair strategy without excessively considering the performance occupied by the repair policy template with the best effect; if it is determined based on real-time performance parameters that the user device has a very low performance space, a repair policy template that occupies the least performance can be determined from multiple sets of repair policy templates as the target repair policy template and the template content can be filled to obtain the first target repair strategy to avoid increasing the load on the user device.

[0085] Among them, if there are multiple potential faults in the target application installed on the same user device, obtain the fault priority corresponding to each potential fault (the multiple potential faults can be prioritized by analyzing the frequency of occurrence and the degree of impact of the exceptions, and frequent exceptions or faults with greater impact will be given priority); sort the first target repair strategies corresponding to the potential faults according to the fault priorities corresponding to the potential faults, and send the generated first target repair strategy list after sorting to the user device.

[0086] S205, analyzing the abnormal event log to determine the explicit fault corresponding to the target application.

[0087] The above are all processes for analyzing potential faults. It is not difficult to understand that since the user device uploads an abnormal event log to the server, the server can directly analyze the explicit fault based on the abnormal event log.

[0088] Specifically, the server obtains exception stack information in the exception event log; obtains the exception class name and exception class method included in the exception stack information, and determines the explicit fault corresponding to the target application based on the exception class name and the exception class method.

[0089] S206: Obtain a second fault category of the explicit fault, and obtain a real-time performance parameter corresponding to the user equipment.

[0090] After the explicit fault is determined, a second fault category of the explicit fault is obtained. For example, the second fault category may be UI operation exception, memory leak, resource conflict, thread competition, null pointer exception, and the like.

[0091] And, after the explicit fault is determined as described above, the real-time performance parameters corresponding to the user equipment are obtained, such as the real-time CPU usage, memory usage, network delay, mobile phone model and other key performance indicators of the user equipment.

[0092] S207, matching a second target repair strategy corresponding to the explicit fault from a repair strategy library based on the second fault category and the real-time performance parameter, and sending the second target repair strategy to the user equipment for fault repair.

[0093] A plurality of candidate repair strategy templates corresponding to the second fault category are matched from the repair strategy library; a target repair strategy template is determined from the plurality of candidate repair strategy templates based on real-time performance parameters and the template content is filled, and a second target repair strategy obtained after filling is obtained.

[0094] The embodiments of the present application can quickly identify potential faults of the target application and reduce troubleshooting time by analyzing abnormal event logs and auxiliary analysis data; directly analyze explicit faults based on abnormal event logs, quickly identify explicit faults of the target application and reduce troubleshooting time; match the most suitable repair strategy from the repair strategy library based on the first fault category / second fault category and real-time performance parameters, thereby improving the accuracy and effectiveness of the repair; by automatically issuing repair strategies, manual intervention is reduced, the efficiency of fault handling is improved, and the operation and maintenance costs are reduced; timely repair of potential faults can improve user satisfaction with the target application and reduce usage interruptions caused by faults.

[0095] Furthermore, after the above-mentioned first target repair strategy and / or second target repair strategy is issued and applied, the server continues to collect the user's abnormal event log, device performance log and user operation log to monitor the running status of the target application and user behavior to confirm whether the repair is effective. If the repair fails to execute, or if the problem occurs again, the repair strategy can be adjusted or optimized, and the repair can be attempted again.

[0096] Furthermore, after the above-mentioned first target repair strategy and / or second target repair strategy are issued and applied, the server collects user feedback data (direct user feedback, such as evaluation or question submission; or indirect feedback, such as application usage frequency, exception reduction, etc.) to verify the effect of the repair. If the repair effect is poor, the repair strategy can be adjusted or optimized, and the repair can be attempted again.

[0097] Furthermore, when adjusting or optimizing the repair strategy, this process can be achieved through rule weighting, condition adjustment, personalized optimization, etc. The details are as follows:

[0098] Condition adjustment: If the server detects that a certain type of problem occurs frequently, or a certain repair strategy is ineffective, the server will dynamically adjust the triggering conditions of the corresponding repair strategy in the repair strategy library. For example, adjust the threshold of the memory management strategy, or change the logic of exception handling.

[0099] Rule weighting: Through data analysis, the server can assign weights to different repair strategies. For example, if a repair strategy works well on most devices but not on certain devices, the server will lower the priority of the repair strategy on these devices.

[0100] Personalized optimization: The server will generate a more personalized repair strategy based on the user's device model, usage habits, and application environment. For example, on devices with limited resources, the system will give priority to lightweight repair methods, while on high-performance devices, more complex repair strategies can be used.

[0101] Furthermore, when adjusting the rules, the server can test the new repair strategy on some users through A / B testing. If the new strategy works well, it will be promoted to more users; if the effect is not good, it will be rolled back to the previous strategy.

[0102] Furthermore, on the user device side, if the first target repair strategy or the second target repair strategy adopts code repair, bytecode instrumentation technology and / or hot repair technology can be used to dynamically modify the application code when the target application is running. For example, the repair code is inserted before and after a method is executed without recompiling the application. The instrumentation operation can be completed by tools (such as ASM or Javassist).

[0103] Furthermore, on the user device side, if the above-mentioned first target repair strategy or second target repair strategy involves modification of a configuration file, the user device can automatically generate a new configuration file according to the first target repair strategy or the second target repair and apply it to the current environment.

[0104] Furthermore, on the user device side, if the modification of the configuration file requires restarting the target application to make the change effective, in this case, the user device will prompt the user to restart in a non-intrusive manner, such as through a notification bar message or a pop-up window prompt. This prompt method is intended to ensure that the user can reasonably arrange the restart time of the application, thereby improving the user experience and operational flexibility.

[0105] Furthermore, on the user device side, the user will only be prompted to perform operations if the repair requires a restart or has a significant impact on the application state. Most repair operations are performed automatically without user intervention.

[0106] Figure 3 is an exemplary schematic diagram of a fault recovery device for an application program shown in the present application, such as Figure 3 As shown, the fault repair device 300 of the application includes a receiving module 301, an analyzing module 302, an acquiring module 303 and a sending module 304, wherein:

[0107] The receiving module 301 is used to receive the abnormal event log and auxiliary analysis data corresponding to the target application uploaded by the user device, where the auxiliary analysis data includes at least one of the device performance log corresponding to the user device and the user operation log corresponding to the target application.

[0108] The analysis module 302 is used to analyze the abnormal event log and the auxiliary analysis data to determine the potential faults corresponding to the target application.

[0109] The acquisition module 303 is used to acquire a first fault category of a potential fault and to acquire a real-time performance parameter corresponding to the user equipment.

[0110] The sending module 304 is used to match a first target repair strategy corresponding to a potential fault from a repair strategy library based on the first fault category and the real-time performance parameter, and send the first target repair strategy to the user equipment for fault repair.

[0111] By analyzing abnormal event logs and auxiliary analysis data, the device can quickly identify potential faults of the target application and reduce troubleshooting time; based on the first fault category and real-time performance parameters, it can match the most suitable repair strategy from the repair strategy library, thereby improving the accuracy and effectiveness of the repair; by automatically issuing repair strategies, it reduces manual intervention, improves the efficiency of fault handling, and reduces operation and maintenance costs; timely repair of potential faults can improve user satisfaction with the target application and reduce usage interruptions caused by faults.

[0112] Furthermore, the analysis module 302 is also used to analyze the abnormal event log to determine the explicit fault corresponding to the target application; the acquisition module 303 is also used to obtain the second fault category of the explicit fault; the sending module 304 is also used to match the second target repair strategy corresponding to the explicit fault from the repair strategy library based on the second fault category and real-time performance parameters; and send the second target repair strategy to the user device for fault repair.

[0113] Furthermore, the sending module 304 is also used to: for any fault category in the first fault category and the second fault category, match multiple candidate repair strategy templates corresponding to any fault category from the repair strategy library; determine the target repair strategy template from the multiple candidate repair strategy templates based on real-time performance parameters and fill the template content, and obtain the target repair strategy after filling.

[0114] Furthermore, the analysis module 302 is also used to: determine the target abnormal event from the abnormal event log, and obtain a first number of the target abnormal events in the abnormal event log; obtain a timestamp corresponding to each occurrence of the target abnormal event, and trace back a preset time period based on the timestamp to obtain multiple target time periods corresponding to the target abnormal event; intercept the user operation log based on the target time period, and obtain multiple target operation data obtained after interception; perform user behavior correlation analysis on the target operation data and the target abnormal event in combination with the first number, and obtain potential faults obtained by analysis.

[0115] Furthermore, the analysis module 302 is also used to: determine whether there is a target operation behavior that is repeatedly executed more than N times in any target operation data corresponding to the target abnormal event, and if so, mark the target operation data with a target operation behavior label corresponding to the target operation behavior; obtain a second number of each target operation behavior label; for any target operation behavior label, take the ratio of the second number of target operation behavior labels to the first number as the occurrence frequency of the target operation behavior label; in response to the occurrence frequency of the target operation behavior label being greater than the first frequency threshold, determine that the target application has a first potential fault related to the target operation behavior label.

[0116] Furthermore, the analysis module 302 is also used to: obtain the operation behavior sequence contained in each target operation data corresponding to the target abnormal event; obtain the third quantity corresponding to each operation behavior sequence; for any operation behavior sequence, take the ratio of the third quantity corresponding to the operation behavior sequence to the first quantity as the occurrence frequency of the operation behavior sequence; in response to the occurrence frequency of the operation behavior sequence being greater than the second frequency threshold, determine that the target application has a second potential fault related to the operation behavior sequence.

[0117] Furthermore, the analysis module 302 is also used to: obtain the first end operation behavior contained in each target operation data corresponding to the target abnormal event, wherein the first end operation behavior refers to the last operation behavior contained in the target operation data; obtain the fourth quantity of each first end operation behavior; for any first end operation behavior, use the ratio of the fourth quantity to the first quantity as the occurrence frequency of the first end operation behavior; in response to the occurrence frequency of the first end operation behavior being greater than the third frequency threshold, determine that the target application has a third potential fault related to the first end operation behavior.

[0118] Furthermore, the analysis module 302 is also used to: intercept the device performance log based on the target time period to obtain multiple target performance data obtained after the interception; calculate each target performance data corresponding to the target abnormal event to obtain the average resource utilization rate corresponding to each target performance data; mark the target performance data whose average resource utilization rate is greater than a preset resource utilization rate threshold as abnormal target performance data, and obtain the fifth number of abnormal target performance data; use the ratio of the fifth number to the first number as the frequency of occurrence of abnormal target performance data; in response to the frequency of occurrence of abnormal target performance data being greater than the fourth frequency threshold, determine that a fourth potential fault occurs in the target application.

[0119] Furthermore, the analysis module 302 is also used to: after determining the abnormal target performance data, determine the associated target operation data related to the abnormal target performance data from the target operation data; obtain the second end operation behavior contained in each associated target operation data, wherein the second end operation behavior refers to the last operation behavior contained in the associated target operation data; obtain the sixth number of each second end operation behavior; for any second end operation behavior, take the ratio of the sixth number to the fifth number as the occurrence frequency of the second end operation behavior; in response to the occurrence frequency of the second end operation behavior being greater than the fifth frequency threshold, determine that the target application has a fifth potential fault.

[0120] Furthermore, the analysis module 302 is also used to: obtain the exception stack information in the exception event log; obtain the exception class name and exception class method included in the exception stack information, and determine the explicit fault corresponding to the target application based on the exception class name and exception class method.

[0121] In order to implement the above embodiment, the present application embodiment also proposes an electronic device 400, such as Figure 4 As shown, the electronic device 400 includes: a processor 401 and a memory 402 communicatively connected to the processor, the memory 402 stores instructions executable by at least one processor, and the instructions are executed by at least one processor 401 to implement the fault repair method of the application as shown in the above embodiment.

[0122] In order to implement the above embodiment, the embodiment of the present application also proposes a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable the computer to implement the fault repair method of the application program shown in the above embodiment.

[0123] In order to implement the above embodiments, the embodiments of the present application further provide a computer program product, including a computer program, which implements the fault repair method of the application program shown in the above embodiments when executed by a processor.

[0124] In the description of the present application, it should be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", "clockwise", "counterclockwise", "axial", "radial", "circumferential" and the like indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the referred device or element must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be understood as a limitation on the present application.

[0125] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of this application, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0126] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0127] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in the field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A method for repairing a fault of an application, characterized in that: include: Receiving an abnormal event log and auxiliary analysis data corresponding to a target application uploaded by a user device, wherein the auxiliary analysis data includes at least one of a device performance log corresponding to the user device and a user operation log corresponding to the target application; In response to the auxiliary analysis data including a user operation log, determining a target abnormal event from the abnormal event log, and obtaining a first number of the target abnormal events in the abnormal event log; Obtain a timestamp corresponding to each occurrence of the target abnormal event, and trace back a preset time period based on the timestamp to obtain multiple target time periods corresponding to the target abnormal event; intercepting the user operation log based on the target time period, and acquiring a plurality of target operation data obtained after interception; performing a user behavior correlation analysis on the target operation data and the target abnormal event in combination with the first quantity, and obtaining potential faults obtained through analysis; Acquire a first fault category of the potential fault, and acquire a real-time performance parameter corresponding to the user equipment; A first target repair strategy corresponding to the potential fault is obtained by matching from a repair strategy library based on the first fault category and the real-time performance parameter, and the first target repair strategy is sent to the user equipment for fault repair.

2. The method according to claim 1, characterized in that The method further comprises: Analyze the abnormal event log to determine the explicit fault corresponding to the target application; Obtaining a second fault category of the dominant fault; Based on the second fault category and the real-time performance parameter, matching and obtaining a second target repair strategy corresponding to the explicit fault from the repair strategy library; The second target repair strategy is sent to the user equipment to perform fault repair.

3. The method according to claim 2, characterized in that The obtaining of a first target repair strategy corresponding to the potential fault from a repair strategy library based on the first fault category and the real-time performance parameter, or the obtaining of a second target repair strategy corresponding to the explicit fault from the repair strategy library based on the second fault category and the real-time performance parameter, includes: For any fault category of the first fault category and the second fault category, obtain multiple candidate repair strategy templates corresponding to the any fault category by matching from the repair strategy library; Based on the real-time performance parameters, a target repair strategy template is determined from the multiple candidate repair strategy templates, the template content is filled, and the filled target repair strategy is obtained.

4. The method according to any one of claims 1 to 3, characterized in that The performing user behavior correlation analysis on the target operation data and the target abnormal event in combination with the first quantity to obtain potential faults obtained through analysis includes: Determine whether any of the target operation data corresponding to the target abnormal event has a target operation behavior that is repeatedly executed more than N times; if so, mark the target operation data with a target operation behavior label corresponding to the target operation behavior; Obtaining a second quantity of each target operation behavior label; For any of the target operation behavior labels, taking a ratio of the second number of the target operation behavior labels to the first number as the occurrence frequency of the target operation behavior label; In response to the occurrence frequency of the target operation behavior tag being greater than a first frequency threshold, it is determined that a first potential fault associated with the target operation behavior tag occurs in the target application.

5. The method according to any one of claims 1 to 3, characterized in that: The performing user behavior correlation analysis on the target operation data and the target abnormal event in combination with the first quantity to obtain potential faults obtained through analysis further includes: Obtaining the operation behavior sequence contained in each target operation data corresponding to the target abnormal event; Obtain a third quantity corresponding to each sequence of the operation behaviors; For any of the operation behavior sequences, taking the ratio of the third number corresponding to the operation behavior sequence to the first number as the occurrence frequency of the operation behavior sequence; In response to the occurrence frequency of the operation behavior sequence being greater than a second frequency threshold, it is determined that a second potential fault associated with the operation behavior sequence occurs in the target application.

6. The method according to any one of claims 1 to 3, characterized in that The performing user behavior correlation analysis on the target operation data and the target abnormal event in combination with the first quantity to obtain potential faults obtained through analysis further includes: Acquire a first last operation behavior contained in each target operation data corresponding to the target abnormal event, wherein the first last operation behavior refers to the last operation behavior contained in the target operation data; Obtaining a fourth quantity of each of the first end operation behaviors; For any of the first final operation behaviors, taking the ratio of the fourth number to the first number as the occurrence frequency of the first final operation behavior; In response to the occurrence frequency of the first end operation behavior being greater than a third frequency threshold, it is determined that a third potential fault associated with the first end operation behavior occurs in the target application.

7. The method according to any one of claims 1 to 3, characterized in that In response to the auxiliary analysis data also including a device performance log, the method further includes: intercepting the device performance log based on the target time period, and acquiring a plurality of target performance data obtained after interception; Calculate each target performance data corresponding to the target abnormal event to obtain an average resource usage rate corresponding to each target performance data; Marking the target performance data whose average resource usage rate is greater than a preset resource usage rate threshold as abnormal target performance data, and obtaining a fifth quantity of the abnormal target performance data; using a ratio of the fifth number to the first number as the occurrence frequency of the abnormal target performance data; In response to the occurrence frequency of the abnormal target performance data being greater than a fourth frequency threshold, it is determined that a fourth potential fault occurs in the target application.

8. The method according to claim 7, characterized in that The method further comprises: After determining the abnormal target performance data, determining associated target operation data related to the abnormal target performance data from the target operation data; Acquire a second last operation behavior included in each of the associated target operation data, wherein the second last operation behavior refers to the last operation behavior included in the associated target operation data; Obtaining the sixth quantity of each of the second end operation behaviors; For any of the second final operation behaviors, taking the ratio of the sixth number to the fifth number as the occurrence frequency of the second final operation behavior; In response to the occurrence frequency of the second end operation behavior being greater than a fifth frequency threshold, it is determined that a fifth potential fault occurs in the target application.

9. The method according to claim 2, characterized in that: The analyzing the abnormal event log to determine the explicit fault corresponding to the target application includes: Obtaining exception stack information in the exception event log; The exception class name and the exception class method included in the exception stack information are obtained, and the explicit fault corresponding to the target application is determined based on the exception class name and the exception class method.

Images