Abnormal reproduction method, system and equipment and computer storage medium
By acquiring runtime data from the application frontend and sending operation logs to the reproduction backend, and using multi-dimensional features and Markov chains to simulate and reproduce anomalies, the problem of application anomaly detection relying on user feedback is solved, thereby improving the success rate of anomaly reproduction and the efficiency of anomaly location and repair.
Patent Information
- Application Number
- CN202511739763.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-24
- Publication Date
- 2026-04-28
AI Technical Summary
In existing technologies, application anomaly detection lacks a proactive mechanism and relies on subjective user feedback, which leads to the neglect of subtle or intermittent anomalies, resulting in a low success rate of anomaly reproduction and a prolonged period for localization and repair.
The application frontend obtains runtime data to identify abnormal phenomena and sends operation logs to the reproduction backend. The backend simulates and reproduces the abnormal phenomena, using regular expressions, multi-dimensional features, and Markov chains to generate multiple operation paths and detects simulator logs in real time to determine the cause of the abnormality.
It improved the success rate of anomaly reproduction, shortened the anomaly location and repair cycle, avoided the shortcomings of relying on user feedback, and obtained accurate operation trajectory and key parameters.
Smart Images
Figure CN121935133A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of application exception testing, and in particular to an exception reproduction method, system, device, and computer storage medium. Background Technology
[0002] In the application development process, user testing serves as a crucial link between product design and market demand: users perform various operations during the application trial, which may trigger abnormal situations such as functional failures, interface lag, and data corruption; users report these abnormal situations to the development team, and the development team reproduces the abnormal situations based on the data provided by the users, providing a basis for troubleshooting the causes of the abnormalities and developing repair solutions. In related technologies, during trial testing, anomalies discovered during the trial process lack an active detection mechanism and often rely on subjective user feedback. This leads to some minor or intermittent anomalies being overlooked. Furthermore, during anomaly reproduction, the process is only described by vague memory, making it difficult for developers to obtain precise operation trajectories or trace back the key parameters when the anomaly occurred. This results in a low success rate for anomaly reproduction and prolongs the cycle of anomaly location and repair in the application. Summary of the Invention
[0003] To address the aforementioned technical problems, this application proposes an anomaly reproduction method, system, device, and computer storage medium.
[0004] To address the aforementioned technical problems, this application proposes an anomaly reproduction method applied to an anomaly reproduction system. The anomaly reproduction system includes an application front-end and a reproduction back-end. The anomaly reproduction method includes: The application front-end acquires the application's runtime data and determines whether the application is experiencing any abnormalities based on the runtime data. In the event of an anomaly in the application, the application frontend sends the application's operation logs to the reproduction backend; The reproduction backend simulates and reproduces the abnormal phenomenon multiple times based on the operation log; The backend determines the cause of the abnormal phenomenon based on the results of multiple simulations.
[0005] The reproduction backend simulates and reproduces the abnormal phenomenon multiple times based on the operation logs, including: The reproduction backend obtains exception stack information from the operation log using regular expressions, and constructs a first operation path based on the exception stack information. The reproduction backend extracts multi-dimensional features from the operation log and determines the target scenario based on the multi-dimensional features; The reproduction backend simulates and reproduces the abnormal phenomenon multiple times based on the target scenario and the first operation path.
[0006] The reproduction backend, based on the target scenario and the first operation path, repeatedly simulates and reproduces the abnormal phenomenon, including: The reproduction backend constructs a simulated scene using multiple simulators based on the target scene, wherein the device states of the multiple simulators differ. The reproduction backend constructs a Markov chain based on the first operation path and generates multiple second operation paths; The replication backend injects boundary conditions into the multiple second operation paths respectively to obtain multiple third operation paths; The reproduction backend simulates the multiple third operation paths in each of the multiple simulators, and determines the reproduction rate of the abnormal phenomenon corresponding to each operation path during the simulation process.
[0007] The method further includes: The reproduction backend monitors the simulator logs corresponding to each simulator in real time. When the backend for reproducing the phenomenon shows an error code in the simulator log, it determines that the corresponding simulator has successfully reproduced the phenomenon.
[0008] The application frontend sends the application's operation logs to the reproduction backend, including: The application front-end obtains sensitive information from the operation log, wherein the sensitive information includes user identity information and / or user password; The application front-end replaces the sensitive information with preset characters to obtain the desensitized operation log. The application frontend sends the anonymized operation logs to the reproduction backend.
[0009] The process of determining whether the application is experiencing abnormal behavior based on the operational data includes: The application front end obtains the first running data corresponding to the first time window, and determines the first anomaly confidence level based on the first running data; If the first abnormal confidence level is greater than the preset confidence threshold, the application front end will increase the collection frequency of the running data to the target collection frequency; The application front end acquires multiple sets of second running data corresponding to multiple second time windows collected at a target collection frequency, and determines multiple second anomaly confidence levels based on the multiple sets of second running data; If the confidence levels of multiple second anomalies are all greater than the preset confidence threshold, the application front-end determines that the application has an anomaly.
[0010] The operational data includes user behavior data, system operation data, and device environment data. The user behavior data includes at least one of the following: user click coordinates, mouse movement trajectory, click force, and text input interval; The system operation data includes at least one of the following: frame rate, main thread response status, and network request time. The device environment data includes at least one of the following: device temperature, screen refresh list, background process list, and signal strength.
[0011] To address the aforementioned technical problems, this application also proposes an anomaly reproduction system, which includes an application front-end and a reproduction back-end. The application frontend is used to acquire the application's running data and determine whether the application is experiencing any abnormalities based on the running data; if the application is experiencing abnormalities, the application's operation logs are sent to the reproduction backend. The reproduction backend is used to simulate and reproduce the abnormal phenomenon multiple times based on the operation log; and to determine the cause of the abnormal phenomenon based on the reproduction results of the multiple simulations.
[0012] To address the aforementioned technical problems, this application also proposes an anomaly reproduction device, which includes a memory and a processor coupled to the memory; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the anomaly reproduction method as described above.
[0013] To address the aforementioned technical problems, this application also proposes a computer storage medium for storing program data, which, when executed by a computer, is used to implement the above-mentioned method for reproducing anomalies.
[0014] Compared with the prior art, the beneficial effects of this application are as follows: In the above embodiments, the application front-end actively determines whether the application has any abnormal phenomena during operation based on the application's running data. When an abnormal phenomenon occurs, the operation log is sent to the reproduction back-end. The reproduction back-end simulates and reproduces the abnormal phenomenon to determine the cause of the abnormal phenomenon. Compared with related technologies, this can actively capture abnormal phenomena during the operation of the application without relying on the user's active feedback, avoiding the neglect of some minor or intermittent abnormalities. At the same time, during the simulation reproduction process, the operation log of the application can be used to obtain a precise operation trajectory and trace back the key parameters when the abnormal phenomenon occurred, which improves the success rate of abnormal phenomenon reproduction and shortens the cycle of abnormal location and repair in the application. Attached Figure Description
[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein: Figure 1 This is a schematic diagram of the framework of an embodiment of the anomaly reproduction system provided in this application; Figure 2 This is a flowchart illustrating an embodiment of the anomaly reproduction method provided in this application; Figure 3 This is a schematic diagram of the operation log provided in this application; Figure 4 This is a schematic diagram of the operation log after desensitization processing provided in this application; Figure 5 This is a schematic diagram of the structure of an embodiment of the anomaly reproduction device provided in this application; Figure 6 This is a schematic diagram of the structure of an embodiment of the computer storage medium provided in this application. Detailed Implementation
[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.
[0017] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0018] The anomaly reproduction method of this application is applied to an anomaly reproduction system. Please refer to [link / reference] for details. Figure 1 ,in, Figure 1 This is a schematic diagram of the framework of an embodiment of the anomaly reproduction system provided in this application.
[0019] like Figure 1 As shown, the anomaly reproduction system of this application includes an application front-end and a reproduction back-end.
[0020] The application frontend serves as the operational platform for testers, where the application to be tested is installed. During the trial period, testers directly perform various test operations (such as functional verification) on the installed application through the application frontend. The system automatically captures anomalies occurring during the trial testing (such as crashes, functional malfunctions, etc.), acquiring the application's runtime data and determining whether the application exhibits any abnormalities based on this data. It also records operation logs during the trial testing process (such as operation steps, error screenshots, etc.). In the event of application anomalies, the application's operation logs are sent to the reproduction backend.
[0021] The backend receives operation logs submitted by the application frontend and simulates the anomalies that occur on the application frontend. After multiple simulations, the cause of the anomaly is determined.
[0022] based on Figure 1 For system framework details, please refer to [link / reference]. Figure 2 , Figure 2 This is a flowchart illustrating one embodiment of the anomaly reproduction method provided in this application.
[0023] like Figure 2 As shown, the specific steps are as follows: Step S11: The application front-end obtains the application's runtime data and determines whether the application has encountered any abnormalities based on the runtime data.
[0024] In this embodiment of the application, the tester performs trial testing of the application at the application front end, and the application front end obtains the application's running data in real time during the application's operation.
[0025] The operational data includes user behavior data, system operation data, and device environment data.
[0026] User behavior data refers to data generated during basic interactions between testers and the application front-end. User behavior data includes at least one of the following: user click coordinates, mouse movement trajectory, click force, and text input interval. During operation, the system front-end actively collects data generated by the testers' user behavior. Examples include the specific coordinates of the click location and the click circuit when clicking on the screen or page with a mouse or finger; the mouse movement trajectory, which records the path the cursor moves on the screen or page; and the input time interval when entering text in the application, such as passwords or search terms.
[0027] System operation data is a series of data reflecting the state and performance of the application front-end when running the application, including at least one of the following: frame rate, main thread response status, and network request time.
[0028] Device environment data refers to various types of data related to the operating environment of an application, including at least one of the following: device temperature, screen refresh list, background process list, and signal strength.
[0029] By collecting multi-dimensional operational data such as user behavior data, system operation data, and device environment data, the accuracy and comprehensiveness of anomaly detection are significantly improved.
[0030] In an optional embodiment, determining whether the application exhibits an anomaly based on the runtime data includes: the application frontend acquiring first runtime data corresponding to a first time window and determining a first anomaly confidence level based on the first runtime data; if the first anomaly confidence level is greater than a preset confidence threshold, the application frontend increasing the collection frequency of the runtime data to a target collection frequency; the application frontend acquiring multiple sets of second runtime data corresponding to multiple second time windows collected at the target collection frequency and determining multiple second anomaly confidence levels based on the multiple sets of second runtime data; if all multiple second anomaly confidence levels are greater than the preset confidence threshold, the application frontend determining that the application exhibits an anomaly.
[0031] In this embodiment, when the application is running normally, it collects running data at a preset collection frequency and sets a time window of a predetermined duration. Each time window when collecting running data at the preset collection frequency is denoted as a first time window. The abnormal confidence level corresponding to the first time window is determined based on the running data collected in each first time window and is denoted as a first abnormal confidence level. An abnormal phenomenon is initially judged based on whether the first abnormal confidence level is greater than a preset confidence threshold. If an abnormal phenomenon is initially judged to be possible, i.e., the first abnormal confidence level is greater than the preset confidence threshold, the frequency of collecting running data is increased, that is, the frequency of collecting running data by the application front end is increased to a target collection frequency to further verify whether an abnormal phenomenon has occurred. Each time window after increasing the collection frequency is denoted as a second time window. Multiple sets of running data corresponding to multiple second time windows after increasing the collection frequency are obtained, i.e., multiple sets of second running data. The abnormal confidence level corresponding to each second time window is determined based on multiple sets of second running data, resulting in multiple second abnormal confidence levels. When multiple second abnormal confidence levels are all greater than the preset confidence threshold, an abnormal phenomenon is determined to have occurred.
[0032] By collecting operational data in stages using different collection frequencies and verifying the presence of anomalies across multiple time windows, the randomness of data from a single time window is avoided, thus improving the accuracy of anomaly detection.
[0033] In determining the anomaly confidence level, a model calculation method can be used. Specifically, the running data is input into the LSTM-CNN (Long Short-Term Memory Network-Convolutional Neural Network) hybrid model, which outputs multiple anomaly labels and the anomaly confidence level corresponding to each anomaly label.
[0034] Step S12: In the event of an anomaly in the application, the application frontend sends the application's operation logs to the reproduction backend.
[0035] In this embodiment of the application, the application's runtime data is used to determine whether the application is experiencing any abnormal phenomena. These abnormal phenomena include crashes, slow responses, and functional failures. When it is determined that the application is experiencing an abnormal phenomenon, the error code of the current abnormal phenomenon is recorded, and the application's operation log is sent to the reproduction backend.
[0036] Operation logs are structured log information that records various operations performed by testers on the application. The operation logs allow you to trace the tester's operation process, including operation time, operation type, operation content, operation result, etc. At the same time, the running data of the application during the running process is also stored in the operation logs after being structured.
[0037] When sending operation logs to the reproduction backend, the application frontend de-identifies sensitive information in the operation logs before sending them. Sensitive information in the operation logs includes identity information and / or user passwords, etc. Sensitive information in the operation logs is replaced with preset characters, such as the symbol "*" or a randomly generated alphanumeric combination.
[0038] Please see Figure 3 , Figure 3 This is a schematic diagram of the operation log provided in this application, such as... Figure 3 The operation log shown is the operation log corresponding to the login account. When verifying whether the login environment is secure, it is divided into multiple steps: clicking the login button, entering the username, entering the user password, and clicking the confirm login button. The operation log records the operation time, operation type, operation content, and operation result of the above multiple operation steps respectively.
[0039] like Figure 3 As shown, the operation log contains sensitive information, namely the user password, in the section where the user password was entered. Please refer to [link / reference needed]. Figure 4 , Figure 4 This is a schematic diagram of the operation log after desensitization processing provided in this application, such as... Figure 4 As shown, the user password is replaced with preset characters, corresponding to... Figure 4 The symbol “***” in the text.
[0040] By identifying and replacing sensitive information in the operation logs on the application front end, the leakage of users' privacy data during transmission is prevented. The operation logs after desensitization still retain the operation sequence and results of each operation step, enabling the reproduction backend to simulate and reproduce the data based on the desensitized operation logs.
[0041] Step S13: The backend simulates and reproduces the abnormal phenomenon multiple times based on the operation log.
[0042] In this embodiment of the application, after receiving the operation log, the reproduction backend simulates the tester's operation multiple times based on the operation log in order to reproduce the corresponding abnormal phenomenon on the reproduction backend.
[0043] Step S14: The backend determines the cause of the abnormal phenomenon based on the results of multiple simulations.
[0044] In this embodiment, the reproducibility backend controls the runtime environment and simulates the application running in the application frontend, so that the abnormal phenomenon can be repeatedly triggered in the reproducibility backend, and the cause of the abnormal phenomenon can be located based on the reproducibility results of each simulation.
[0045] The occurrence of anomalies is strongly correlated with specific conditions, such as the settlement interface lag occurring only on a certain model of mobile phone. By repeatedly simulating and recording the changes of key variables during different simulations, the scope of anomalies is gradually narrowed down, and finally the cause of the anomalies is determined.
[0046] In the above embodiments, the application frontend proactively determines whether any abnormal phenomena occur during the application's operation based on the application's runtime data. When an abnormal phenomenon occurs, the frontend sends the operation log to the reproduction backend. The reproduction backend then simulates and reproduces the abnormal phenomenon to determine its cause. Compared to related technologies, this approach proactively captures abnormal phenomena during application operation, without relying on user feedback, thus preventing some minor or intermittent abnormalities from being overlooked. Furthermore, during the simulation reproduction process, the application's operation log can be used to obtain precise operation trajectories and trace back key parameters when the abnormal phenomenon occurred, improving the success rate of abnormal phenomenon reproduction and shortening the cycle of abnormal location and repair in the application.
[0047] In an optional embodiment, the reproduction backend simulates and reproduces the abnormal phenomenon multiple times based on the operation log, including: the reproduction backend obtains exception stack information from the operation log using regular expressions, and constructs a first operation path based on the exception stack information; the reproduction backend extracts multi-dimensional features from the operation log, and determines a target scenario based on the multi-dimensional features; the reproduction backend simulates and reproduces the abnormal phenomenon multiple times based on the target scenario and the first operation path.
[0048] In this embodiment, the exception stack information corresponding to the abnormal phenomenon is extracted from the operation log by regular expressions. The exception stack information records the function call chain of the system and the specific information of the exception when the abnormal phenomenon occurs. The execution sequence of the program is parsed from the function call chain in the exception stack information. Based on the sequence, a directed graph of the operation path, namely the first operation path, is generated to represent the operation process before the abnormal phenomenon occurs.
[0049] Multi-dimensional features are extracted from the operation day data. Based on these features, the operating scenario (target scenario) at the time of the anomaly is determined. The scenario features at the time of the anomaly are analyzed using multi-dimensional features, such as the combination of equipment status, network environment, and user operation mode. Based on the target scenario and the first operation path, the anomaly is simulated and reproduced multiple times.
[0050] In an optional embodiment, the reproduction backend constructs a simulated scenario of multiple simulators based on the target scenario; the reproduction backend constructs a Markov chain based on the first operation path to generate multiple second operation paths; the reproduction backend injects boundary conditions into the multiple second operation paths to obtain multiple third operation paths; the reproduction backend simulates multiple third operation paths in each of the multiple simulators, and determines the reproduction rate of the abnormal phenomenon corresponding to each operation path during the simulation process.
[0051] like Figure 1 As shown, the reproduction backend includes a processor and multiple simulators. The simulators execute specified operation paths in a designated simulation scenario, simulating and reproducing the abnormal phenomenon in parallel. Specifically, a simulation scenario for each simulator is constructed based on the target scenario. The simulation scenarios constructed by each simulator are different. Specifically, one simulator's simulation scenario is constructed as the target scenario. Data in a certain dimension of the target scenario is modified multiple times to obtain multiple simulation scenarios different from the target scenario. These multiple simulation scenarios are then applied to different simulators.
[0052] The processor constructs multiple simulated scenarios based on the target scenario and generates multiple third operation paths based on the first operation path. It then sends the simulated scenarios and the corresponding third operation paths to the corresponding simulators to reproduce the abnormal phenomena in the simulators.
[0053] Multiple different third operation paths are generated based on the first operation path. The multiple third operation paths include the first operation path and other operation paths that differ from the first operation path.
[0054] After each simulator constructs the corresponding simulation scenario, it performs multiple simulations based on multiple third operation paths. For example, in each simulator, a preset number of simulations are performed based on one of the third operation paths, and the reproduction rate of the abnormal phenomenon based on the third operation path is counted in the preset number of simulations. Then, a preset number of simulations are performed based on the next third operation path in the same simulator, until the simulation is completed based on all third operation paths.
[0055] The reproduction backend monitors the emulator logs of each emulator in real time; when the error code of the abnormal phenomenon appears in the emulator log, the reproduction backend determines that the corresponding emulator has successfully reproduced the abnormal phenomenon.
[0056] Each simulator generates simulator logs during the simulation process. If an abnormal phenomenon is reproduced in the simulator, a corresponding error code will be recorded in the simulator log. Therefore, whether the abnormal phenomenon has been successfully reproduced can be determined by whether the error code of the abnormal phenomenon appears in the simulator log.
[0057] When generating multiple third operation paths based on the first operation path, a Markov chain is first constructed based on the first operation path. Specifically, each node in the first operation path is regarded as a state in the Markov chain. For example, if the first operation path is A→B→C, the corresponding state set is {A, B, C}. By setting the transition probability between states, multiple second operation paths are generated by randomly sampling from the state set based on the transition probability. The Markov chain is then used to extend multiple second operation paths that differ from the first operation path but are logically related to the first operation path.
[0058] Based on obtaining multiple second operation paths, boundary conditions are injected, such as the fastest click speed and the worst network speed, to form operation paths that include extreme cases. Multiple third operation paths are then generated. Simulations are performed based on these multiple third operation paths, and the reproduction results under different operation paths and different simulators are compared to intuitively determine the cause of the anomaly.
[0059] To implement the above-mentioned anomaly reproduction method, this application also proposes an anomaly reproduction device, for details please refer to [link / reference needed]. Figure 5 , Figure 5 This is a schematic diagram of an embodiment of the anomaly reproduction device provided in this application.
[0060] The anomaly reproduction device 400 in this embodiment includes a processor 41, a memory 42, an input / output device 43, and a bus 44.
[0061] The processor 41, memory 42, and input / output device 43 are respectively connected to the bus 44. The memory 42 stores program data, and the processor 41 is used to execute the program data to implement the abnormal reproduction method described in the above embodiment.
[0062] In this embodiment, processor 41 can also be referred to as a CPU (Central Processing Unit). Processor 41 may be an integrated circuit chip with signal processing capabilities. Processor 41 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor, or processor 41 can be any conventional processor.
[0063] This application also provides a computer storage medium; please refer to the following:Figure 6 , Figure 6 This is a schematic diagram of a computer storage medium according to an embodiment of the present application. The computer storage medium 600 stores a computer program 61, which, when executed by a processor, is used to implement the abnormal reproduction method of the above embodiment.
[0064] When the embodiments of this application are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or 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.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. 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.
[0065] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.
Claims
1. A method for reproducing an anomaly, characterized in that, Applied to an anomaly reproduction system, the anomaly reproduction system includes an application front-end and a reproduction back-end, and the anomaly reproduction method includes: The application front-end acquires the application's runtime data and determines whether the application is experiencing any abnormalities based on the runtime data. In the event of an anomaly in the application, the application frontend sends the application's operation logs to the reproduction backend; The reproduction backend simulates and reproduces the abnormal phenomenon multiple times based on the operation log; The backend determines the cause of the abnormal phenomenon based on the results of multiple simulations.
2. The anomaly reproduction method according to claim 1, characterized in that, The reproduction backend simulates and reproduces the abnormal phenomenon multiple times based on the operation logs, including: The reproduction backend obtains exception stack information from the operation log using regular expressions, and constructs a first operation path based on the exception stack information. The reproduction backend extracts multi-dimensional features from the operation log and determines the target scenario based on the multi-dimensional features; The reproduction backend simulates and reproduces the abnormal phenomenon multiple times based on the target scenario and the first operation path.
3. The anomaly reproduction method according to claim 2, characterized in that, The reproduction backend simulates and reproduces the abnormal phenomenon multiple times based on the target scenario and the first operation path, including: The reproduction backend constructs simulated scenarios using multiple simulators based on the target scenario; The reproduction backend constructs a Markov chain based on the first operation path and generates multiple second operation paths; The replication backend injects boundary conditions into the multiple second operation paths respectively to obtain multiple third operation paths; The reproduction backend simulates the multiple third operation paths in each of the multiple simulators, and determines the reproduction rate of the abnormal phenomenon corresponding to each operation path during the simulation process.
4. The anomaly reproduction method according to claim 3, characterized in that, The method further includes: The reproduction backend monitors the simulator logs corresponding to each simulator in real time. When the backend for reproducing the phenomenon shows an error code in the simulator log, it determines that the corresponding simulator has successfully reproduced the phenomenon.
5. The anomaly reproduction method according to claim 1, characterized in that, The application frontend sends the application's operation logs to the reproduction backend, including: The application front-end obtains sensitive information from the operation log, wherein the sensitive information includes user identity information and / or user password; The application front-end replaces the sensitive information with preset characters to obtain the desensitized operation log. The application frontend sends the anonymized operation logs to the reproduction backend.
6. The anomaly reproduction method according to claim 1, characterized in that, Determining whether the application exhibits abnormal behavior based on the aforementioned operational data includes: The application front end obtains the first running data corresponding to the first time window, and determines the first anomaly confidence level based on the first running data; If the first abnormal confidence level is greater than the preset confidence threshold, the application front end will increase the collection frequency of the running data to the target collection frequency; The application front end acquires multiple sets of second running data corresponding to multiple second time windows collected at a target collection frequency, and determines multiple second anomaly confidence levels based on the multiple sets of second running data; If the confidence levels of multiple second anomalies are all greater than the preset confidence threshold, the application front-end determines that the application has an anomaly.
7. The anomaly reproduction method according to claim 1, characterized in that, The operational data includes user behavior data, system operation data, and device environment data; The user behavior data includes at least one of the following: user click coordinates, mouse movement trajectory, click force, and text input interval; The system operation data includes at least one of the following: frame rate, main thread response status, and network request time. The device environment data includes at least one of the following: device temperature, screen refresh list, background process list, and signal strength.
8. An anomaly reproduction system, characterized in that, The anomaly reproduction system includes an application front-end and a reproduction back-end. The application frontend is used to acquire the application's running data and determine whether the application is experiencing any abnormalities based on the running data; if the application is experiencing abnormalities, the application's operation logs are sent to the reproduction backend. The reproduction backend is used to simulate and reproduce the abnormal phenomenon multiple times based on the operation log; and to determine the cause of the abnormal phenomenon based on the reproduction results of the multiple simulations.
9. An anomaly reproduction device, characterized in that, The anomaly reproduction device includes a memory and a processor coupled to the memory; The memory is used to store program data, and the processor is used to execute the program data to implement the anomaly reproduction method as described in any one of claims 1 to 7.
10. A computer storage medium, characterized in that, The computer storage medium is used to store program data, which, when executed by the computer, is used to implement the anomaly reproduction method as described in any one of claims 1 to 7.