A general local reproduction system and method in multiple environmental scenarios

Abstract

The application discloses a general local reproduction system and method in a multi-environment scene, relates to the field of problem reproduction and positioning in a multi-environment scene in an information system, and comprises the following steps: a simulation request end adds a specific identification bit to interface input parameters of a problem environment to obtain specific identification bit request input parameters and sends the specific identification bit request input parameters to a server; the server receives the specific identification bit request input parameters, applies AOP notification to obtain the specific identification bit and the value of the specific identification bit, and when the value of the specific identification bit is equal to a set threshold value, stores business data in and out of memory in a preset custom annotation method of the problem environment into a cookie and returns the simulation request end; and a local troubleshooting end switches code to a code version corresponding to the problem environment in a local environment, and troubleshoots and positions a bug in the local environment according to business data of the problem environment, so that the efficiency of bug positioning and troubleshooting by a developer in a non-local environment can be improved.

Description

Technical Field

[0001] This invention relates to the field of problem reproduction and localization in multi-environment scenarios in information systems, and in particular to a general local reproduction system and method for multi-environment scenarios. Background Technology

[0002] From the initial requirements definition to final deployment, an information system goes through various operating environments. Typical environments include, but are not limited to, testing environments, frozen environments, acceptance environments, pre-production environments, and production environments. The development environment is where developers develop and self-test locally. This environment is ideal for troubleshooting and locating problems. Developers can use rich breakpoint features to create a "dynamic" troubleshooting environment locally and control program execution. The testing environment is used by the project team's testing team to perform functional testing on the features developed by the developers. The frozen environment is used to deploy applications that have passed the project team's testing, for joint debugging between different project teams and user acceptance. The acceptance environment is used by the testing center to test the test tasks submitted by the development team. The pre-production environment is used for production verification after the testing center's tests are passed and the system is released to operations and maintenance. The production environment is used to officially provide services to the public after all the above environments have passed.

[0003] Currently, when developers perform bug localization and troubleshooting in non-local environments, they often use a log + code review approach. This approach has several drawbacks: 1. Log retention in specific environments has time limits, and log files may be deleted when searching for them; 2. Logs in specific environments (production, pre-production, acceptance) require the cooperation of relevant support personnel, making the troubleshooting chain lengthy and inefficient; 3. Obtaining logs related to specific requests in high-concurrency environments such as production often involves a significant workload; 4. Missing or incomplete logs can lead to problems that cannot be located, requiring changes to the log level, service restarts, or even code modifications to increase logging, re-issuance, and redeployment, resulting in a lengthy troubleshooting cycle; 5. Printing as many logs as possible for bug localization often leads to high disk usage and I / O on the deployment host machine, but in most scenarios, these logs are of no value; 6. Excessive logging code can be mixed with business logic code, causing intrusion and pollution of the business logic code. Summary of the Invention

[0004] The purpose of this invention is to provide a universal local reproduction system and method for multiple environment scenarios, which can improve the efficiency of developers in non-local environments for bug location and troubleshooting.

[0005] To achieve the above objectives, the present invention provides the following solution:

[0006] A general local reproduction system for multiple environment scenarios, the general local reproduction system includes a simulated request terminal, a server and a local investigation terminal;

[0007] The simulated request client is used to add a specific identifier bit to the interface input parameters of the problem environment, obtain the specific identifier bit request input parameter, and send the specific identifier bit request input parameter to the server;

[0008] The server is used to receive the specific identifier request input parameter, and apply AOP notification to obtain the specific identifier and the value of the specific identifier in the specific identifier request input parameter. When the value of the specific identifier is equal to a set threshold, the server stores the business data of memory entry and exit in the preset custom annotation method of the problem environment into a cookie and returns it to the simulated request end.

[0009] The local troubleshooting terminal is used to switch the code to the code version corresponding to the problem environment in the local environment, and to investigate and locate bugs in the code version corresponding to the problem environment in the local environment based on the business data of the corresponding problem environment obtained in the cookie.

[0010] Optionally, the server includes:

[0011] The receiving module is used to receive the specific identifier request parameters;

[0012] The acquisition module is used to apply AOP notifications to obtain the specific flag bit and the value of the specific flag bit in the specific flag bit request input parameters;

[0013] The storage module is used to apply AOP notifications to determine whether the value of the specific flag bit is equal to a set threshold, and when the value of the specific flag bit is equal to the set threshold, to store the business data entering and leaving memory in the preset custom annotation method of the problem environment into a cookie.

[0014] Optionally, the simulated request terminal includes:

[0015] The annotation module is used to add specific flag bits to the interface input parameters of the problem environment to obtain the request input parameters with specific flag bits;

[0016] The sending module is used to send the specific identifier request parameters to the server.

[0017] Optionally, the local investigation terminal includes:

[0018] The code switching module is used to switch the code in the local environment to the code version corresponding to the problem environment;

[0019] The troubleshooting module is used to investigate and locate bugs in the corresponding code version of the problematic environment in the local environment based on the business data of the corresponding problematic environment obtained in the cookie.

[0020] Optionally, the investigation module includes:

[0021] The judgment unit is used to determine whether there is a program vulnerability in the code version corresponding to the problem environment based on the business data of the corresponding problem environment obtained in the cookie.

[0022] The repair unit is used to locate the program vulnerability and apply the corresponding program patch to upgrade the code corresponding to the problematic environment when the code version corresponding to the problematic environment has a program vulnerability;

[0023] The feedback unit is used to return a result indicating that there are no program vulnerabilities in the code version corresponding to the problem environment.

[0024] Optionally, the local investigation terminal uses a JAVA integrated development environment.

[0025] A general local reproduction method for multiple environment scenarios is provided, applied to the aforementioned general local reproduction system for multiple environment scenarios. The general local reproduction method includes:

[0026] Receive specific flags from the problem environment as input parameters;

[0027] The AOP notification is used to retrieve the specific flag bit and its value from the input parameters of the specific flag bit request.

[0028] The AOP notification is used to determine whether the value of the specific flag bit is equal to a set threshold.

[0029] When the value of the specific flag bit is not equal to the set threshold, return the request value of the interface parameter in the specific flag bit request input parameter;

[0030] When the value of the specific flag bit is equal to the set threshold, the business data entering and leaving memory in the preset custom annotation method of the problem environment is stored in a cookie;

[0031] Based on the business data of the corresponding problem environment obtained from the cookie, the bugs in the corresponding code version of the problem environment are investigated and located in the local environment.

[0032] According to specific embodiments provided by the present invention, the present invention discloses the following technical effects:

[0033] This invention provides a general local reproduction system and method for multiple environments. By utilizing the characteristics of setting flag bits (custom annotations) and aspect-oriented programming, it dynamically and in real time acquires business parameters related to memory entry and exit in information systems under test, freeze, acceptance, pre-production, and production environments. This achieves "plug-and-play" acquisition of all business parameters needed for bug investigation and localization. By adding specific custom annotations to methods involving memory entry and exit, it flexibly controls and specifies which code logic methods' results are used as business data for investigation and localization without intruding on business logic. Furthermore, it returns the business parameters of memory entry and exit to the local investigation end in the form of cookies without affecting normal business logic parsing, thus improving the efficiency of developers in local bug localization and investigation. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This invention provides a module diagram of a general local reproduction system for multiple environmental scenarios.

[0036] Figure 2 The flowchart of the general local reproduction system for multiple environment scenarios provided by the present invention;

[0037] Figure 3 The flowchart illustrates the general local reproduction method for multiple environment scenarios provided by this invention.

[0038] Explanation of reference numerals in the attached figures:

[0039] Server—1, Simulated Request Client—2, Local Troubleshooting Client—3. Detailed Implementation

[0040] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0041] The purpose of this invention is to provide a universal local reproduction system and method for multiple environment scenarios, which can improve the efficiency of developers in non-local environments for bug location and troubleshooting.

[0042] The evaluation of a bug detection and localization solution mainly depends on whether the solution can quickly obtain the relevant business parameters of the bug-generating environment and quickly create a dynamic and controllable reproduction environment corresponding to the code version based on the relevant parameters.

[0043] Information systems are essentially composed of data and logic (code). Different operating environments have different business data, and different business data will trigger different business logic in the corresponding code version of the environment. The ideal environment for troubleshooting is to use the business data of the corresponding environment and the code version of the corresponding environment to reproduce the bug on the developer's local machine, so as to debug, troubleshoot and locate in a dynamic and controllable integrated development environment.

[0044] Logs are used to record descriptions of time, actions, and other related operations during the operation of an information system. Aspect-Oriented Programming (AOP) can dynamically add specific functionalities to a program without modifying the source code through pre-compilation and runtime dynamic proxies. It allows for the separation of business logic from system-level services (logging, transaction support, etc.), decoupling system-level services from business logic to achieve high cohesion and low coupling. The main function of AOP advice is to enhance existing functionality without intruding on the original program. This enhancement is achieved by adding advice, which is essentially adding extra functionality to a method. Advice can be categorized into before, after, around, exception, and with return values. Annotations, introduced in Java 5, provide a safe, annotation-like mechanism for associating any information or metadata with program elements (classes, methods, member variables, etc.). They add more intuitive and clear descriptions to program elements (classes, methods, member variables). These descriptions are independent of the program's business logic and are used by specified tools or frameworks, and can be customized according to actual development needs. AOP allows for the definition of pointcuts based on custom annotations, specifying the relevant logic functionality corresponding to the custom annotation within the pointcut. Breakpoints, a feature of debuggers, allow the program to pause at necessary points, controlling the execution process and facilitating analysis; they are powerful tools for troubleshooting and locating problems. Clusters are used by information systems to handle high concurrency scenarios, providing services through multi-node deployment and load balancing. Various unexpected bugs can occur in different operating environments of information systems, including runtime anomalies and logical errors; troubleshooting and locating bugs is a frequent scenario encountered by developers in their work.

[0045] The core of this invention is to leverage the features of custom annotations and AOP to dynamically and in real-time acquire business parameters related to memory entry and exit in information systems under various environments (testing environment, frozen environment, acceptance environment, pre-production environment, and production environment). (The differences in business data between different operating environments only exist in the memory entry and exit process; the execution of logic under the memory stage can be achieved by switching the local environment to the corresponding code version.) This allows for "plug-and-play" acquisition of all business parameters needed for bug investigation and localization while ensuring controllable log volume. By adding specific custom annotations to methods involving memory entry and exit, the invention flexibly controls and specifies which code logic methods' results are used as business data for investigation and localization without intruding on business logic. The business parameters of memory entry and exit are returned to the simulated request end in the form of cookies, without affecting normal business logic parsing. Through unit testing, the business parameters related to memory entry and exit in the bug-generating environment are "injected" into the code logic of the corresponding environment version, creating a dynamically controllable environment in the developer's local development environment for rapid bug investigation and localization. Because the business data needed for troubleshooting and localization can be dynamically and in real-time acquired when needed, the amount of log printing can be significantly reduced, as can disk usage and IO pressure.

[0046] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0047] Example 1

[0048] like Figure 1 As shown, this invention provides a universal local reproduction system for multiple environment scenarios. The universal local reproduction system includes a simulated request terminal 2, a server 1, and a local troubleshooting terminal 3. The server 1, the simulated request terminal 2, and the local troubleshooting terminal 3 are connected sequentially.

[0049] The simulated request terminal 2 is used to add a specific identifier bit to the interface input parameters of the problem environment to obtain the specific identifier bit request input parameter, and send the specific identifier bit request input parameter to the server 1.

[0050] The server 1 is used to receive the specific identifier request input parameter, and to apply AOP notification to obtain the specific identifier and the value of the specific identifier in the specific identifier request input parameter. When the value of the specific identifier is equal to a set threshold, the server stores the business data of memory entry and exit in the preset custom annotation method of the problem environment into a cookie and returns it to the simulated request end.

[0051] The local troubleshooting terminal 3 is used to switch the code to the code version corresponding to the problem environment in the local environment, and to investigate and locate the bugs in the code version corresponding to the problem environment in the local environment based on the business data of the corresponding problem environment obtained in the cookie.

[0052] In one specific implementation, the server 1 includes a receiving module, an acquiring module, and a storage module connected in sequence. Wherein:

[0053] The receiving module is used to receive the specific identifier request parameters.

[0054] The acquisition module is used to apply AOP notifications to obtain the specific flag bit and the value of the specific flag bit in the specific flag bit request input parameters.

[0055] The storage module is used to apply AOP notifications to determine whether the value of the specific flag bit is equal to a set threshold, and when the value of the specific flag bit is equal to the set threshold, to store the business data entering and leaving memory in the preset custom annotation method of the problem environment into a cookie.

[0056] In one specific implementation, the simulated request terminal 2 includes an annotation module and a sending module; the annotation module is connected to the sending module; wherein:

[0057] The annotation module is used to add specific flag bits to the interface input parameters of the problem environment to obtain the request input parameters with specific flag bits.

[0058] The sending module is used to send the specific identifier request parameters to the server 1.

[0059] In one specific implementation, the local investigation terminal 3 includes a code switching module and an investigation module; the code switching module is connected to the investigation module; wherein:

[0060] The code switching module is used to switch the code in the local environment to the version of the code corresponding to the problem environment.

[0061] The troubleshooting module is used to investigate and locate bugs in the corresponding code version of the problematic environment in the local environment based on the business data of the corresponding problematic environment obtained in the cookie.

[0062] Specifically, the investigation module includes a judgment unit, a repair unit, and a feedback unit; the repair unit is connected to both the judgment unit and the feedback unit; wherein:

[0063] The judgment unit is used to determine whether there is a program vulnerability in the code version corresponding to the problem environment based on the business data of the corresponding problem environment obtained in the cookie.

[0064] The repair unit is used to locate the program vulnerability and apply the corresponding program patch to upgrade the code corresponding to the problematic environment when the code version corresponding to the problematic environment has a program vulnerability.

[0065] The feedback unit is used to return a result indicating that there are no program vulnerabilities in the code version corresponding to the problem environment.

[0066] As a specific implementation method, the local investigation terminal 3 uses a JAVA integrated development environment.

[0067] Preferably, the local investigation terminal 3 further includes a display module. The display module is used to display the business data of the specific identifier request parameter.

[0068] In this embodiment, the local inspection terminal 3 is the local environment. Developers perform bug location and inspection on the local inspection terminal 3. The various scenario environments include a test environment, a frozen environment, an acceptance environment, a pre-production environment, and a production environment.

[0069] This invention utilizes the features of setting flag bits (custom annotations) and AOP to dynamically and in real-time acquire business parameters related to memory entry and exit in information systems under various environments (test environment, freeze environment, acceptance environment, pre-production environment, and production environment). While ensuring controllable log volume, it achieves "plug-and-play" acquisition of all business parameters needed for bug investigation and localization. By adding specific custom annotations to methods involving memory entry and exit, it flexibly controls and specifies which code logic methods' results are used as business data for investigation and localization without intruding on business logic. The business parameters related to memory entry and exit are returned to the simulated request client 1 in the form of cookies, without affecting the normal business logic parsing of the caller in a normal call chain scenario, thereby improving the efficiency of bug localization and investigation for developers in a local environment.

[0070] Now, let's take a problem environment in a certain development environment as an example, such as... Figure 2 As shown, the working process of the general local reproduction system for multiple environment scenarios provided by the present invention includes input parameters of the problem environment, simulated request, parsing of server input parameters, determination of whether to collect, putting business data into cookie, local version switching of investigators, and local reproduction and location of investigators.

[0071] Specifically, it is described as follows:

[0072] First, obtain the request parameters (business-related parts) of the problematic environment. Add specific flags to the obtained business-related parameters and request the corresponding interface of the problematic environment (this can be specified beforehand and needs to be consistent with the server-side parameter parsing steps; this document uses `isDebugModel` as an example, the same applies below). Parse and obtain the `isDebugModel` parameter in the AOP notification in the development environment. This parsing logic is implemented in the AOP notification and is isolated from the business logic processing code. Check if `isDebugModel` is 1 or another value that needs to be collected (the specific value here needs to be consistent with the logic in the AOP notification). Collect the memory ingress / egress related business data from methods annotated with specific custom annotations and return it in cookies. This code logic is placed in the AOP notification and isolated from the business logic processing code. The investigators switch the code version in their local IDE to the version corresponding to the problematic environment to ensure consistency between the code logic and the problematic environment. Based on the business-related data and business logic of the problematic environment (after version switching), the investigators in the local IDE use various investigation methods (unit testing, local simulation, etc.) to locate the problem.

[0073] Throughout the process, only the development and operations personnel need to know about the specific flag (isDebugModel) and the related parsing logic, trigger assignment (under what circumstances the collection and return actions are triggered), collection actions, and cookie-based returns. It can be understood as a "backdoor" for troubleshooting. Moreover, the implementation code is in AOP notifications, which isolates the implementation from the business logic processing code.

[0074] Furthermore, taking the example of an error occurring when querying the number of insurance policies and the total insured amount for the insured based on the ID number and ID type in the input parameters, the implementation process of this solution will be discussed in detail.

[0075] The normal business call process for querying the number of insurance policies and the total insured amount for the insured as indicated by the ID number and ID type in the input parameters involves sending the corresponding request parameters through the interface in various scenarios. For example, the value of the request parameter is "123" and the data type of the request parameter is "01".

[0076] The server's processing logic consists of the following two steps:

[0077] 1. Database Query: Based on the input parameters of the request, query the database to obtain the policy number and sum insured of the policy that are equal to the input parameters for the insured's information.

[0078] 2. Logical calculation: Based on the policy number and insured amount returned by the database, the total number of policies and insured amount are summed and returned.

[0079] Database queries involve non-memory data, and since the database data varies across different environments, there will be differences between them. Custom annotations need to be set in the AOP notification in advance to provide data support when problems occur. Logical calculations, on the other hand, are in-memory calculations. The same data performing the same calculations in memory will not differ due to different environments, so no custom annotations are needed.

[0080] When an error occurs when querying the number of insurance policies and the total insured amount for the insured as indicated by the ID number and ID type in the input parameters, the development team adds a specific identifier to the original interface input parameters. Specifically, the value of the request input parameter is "123", the data type of the request input parameter is "01", and the specific identifier is "isDebugModel" with a value of "01". This interface input parameter simulates the problematic environment. When the server receives the request and finds that the input parameter contains "isDebugModel" with a value of 01, it will collect the return of the method marked with the custom annotation and put the return of the method marked with the custom annotation into a cookie, which means putting the database query result into a cookie.

[0081] Developers obtain the memory ingress and egress data of the problem environment from cookies, which is the database query result in this example. Then, they switch the code to the version of the problem environment. In this way, developers have both the data and logic (code) of the problem environment locally, so they can reproduce and troubleshoot the problem locally.

[0082] On the server side, the checks for a specific flag (isDebugModel) in the input parameters, whether the flag equals a preset value, and, if it equals the preset value, the collection of returns from methods with specific custom annotations and their placement in cookies are all handled within AOP advice to isolate them from business logic. The only point of interaction with business logic code throughout this process is the application of custom annotations to specific methods. These custom annotations are external to the method hierarchy and do not involve any specific operations within the business logic, thus ensuring zero intrusion and zero infection of the business logic.

[0083] The universal local reproduction system for multiple environments provided by this invention has the following advantages:

[0084] 1. Dynamically acquire business data from various environments in real time; dynamically acquire business data from various operating environments in real time through AOP, custom annotations, and special input parameter parsing, providing a data foundation for subsequent troubleshooting and localization.

[0085] 2. Zero intrusion into business logic: Using custom annotations, we can flexibly control and specify the methods that need to return results without intruding into business logic, thus separating bug investigation and localization and program-related logic from business-related logic.

[0086] 3. Seamless parsing by the caller in normal call chain scenarios; By writing cookies, the business data needed to locate bugs is returned without changing the reverse parameter structure, and the normal reverse parameter parsing logic of the caller in normal call chain scenarios is not affected.

[0087] 4. Dynamically controllable troubleshooting environment: By using unit testing, business data from the bug-generating environment is "injected" into the corresponding code version in the local integrated development environment, thus achieving a dynamically controllable troubleshooting environment.

[0088] 5. Low disk usage and IO pressure; Since the business data needed for troubleshooting and locating problems can be dynamically and in real time when needed, the amount of log printing can be greatly reduced, thus reducing disk usage and IO pressure.

[0089] 6. Reduce non-business-related code; reduce the non-business-related parts in business methods by writing non-business-related code into AOP pointcuts, thereby enhancing the "purity" of business code.

[0090] Example 2

[0091] In order to execute the system corresponding to Embodiment 1 above and achieve the corresponding functions and technical effects, a general local reproduction method for multiple environment scenarios is provided below, such as... Figure 3 As shown, the general local reproduction method includes:

[0092] Step S1: Receive the specific flag request parameters for the problem environment.

[0093] Step S2: Apply AOP notification to obtain the specific flag bit and the value of the specific flag bit in the specific flag bit request input parameters.

[0094] Step S3: Apply AOP notification to determine whether the value of the specific flag bit is equal to the set threshold.

[0095] Step S4: When the value of the specific flag bit is not equal to the set threshold, return the request value of the interface parameter in the specific flag bit request input parameter.

[0096] Step S5: When the value of the specific identifier bit is equal to the set threshold, store the business data entering and leaving memory in the preset custom annotation method of the problem environment into the cookie.

[0097] Step S6: Based on the business data of the corresponding problem environment obtained in the cookie, investigate and locate the bugs in the corresponding code version of the problem environment in the local environment.

[0098] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0099] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A universal local reproduction system for multiple environment scenarios, characterized in that, The general local reproduction system includes a simulated request client, a server, and a local troubleshooting client; The simulated request client includes: The annotation module is used to add specific flag bits to the interface input parameters of the problem environment to obtain the request input parameters with specific flag bits; The sending module is used to send the specific identifier request parameters to the server; The server includes: The receiving module is used to receive the specific identifier request parameters; The acquisition module is used to apply AOP notifications to obtain the specific flag bit and the value of the specific flag bit in the specific flag bit request input parameters; The storage module is used to apply AOP notifications to determine whether the value of the specific flag bit is equal to a set threshold, and when the value of the specific flag bit is equal to the set threshold, to store the business data of memory entry and exit in the preset custom annotation method of the problem environment into a cookie; The local investigation terminal includes: The code switching module is used to switch the code in the local environment to the code version corresponding to the problem environment; The troubleshooting module is used to investigate and locate bugs in the corresponding code version of the problematic environment in the local environment based on the business data of the corresponding problematic environment obtained in the cookie. The investigation module specifically includes: The judgment unit is used to determine whether there is a program vulnerability in the code version corresponding to the problem environment based on the business data of the corresponding problem environment obtained in the cookie. The repair unit is used to locate the program vulnerability and apply the corresponding program patch to upgrade the code corresponding to the problem environment when the code version corresponding to the problem environment has a program vulnerability; The feedback unit is used to return a result indicating that there are no program vulnerabilities in the code version corresponding to the problem environment.

2. The universal local reproduction system for multiple environment scenarios according to claim 1, characterized in that, The local troubleshooting terminal uses a Java integrated development environment.

3. A universal local reproduction method for multiple environment scenarios, applied to the universal local reproduction system for multiple environment scenarios as described in claim 1 or 2, characterized in that, The general local reproduction method includes: Receive specific flags from the problem environment as input parameters; The AOP notification is used to retrieve the specific flag bit and its value from the input parameters of the specific flag bit request. The AOP notification is used to determine whether the value of the specific flag bit is equal to a set threshold. When the value of the specific flag bit is not equal to the set threshold, return the request value of the interface parameter in the specific flag bit request input parameter; When the value of the specific flag bit is equal to the set threshold, the business data entering and leaving memory in the preset custom annotation method of the problem environment is stored in a cookie; Based on the business data of the corresponding problem environment obtained from the cookie, the bugs in the corresponding code version of the problem environment are investigated and located in the local environment.

Images