Software exception handling method, exception handling system and storage medium

Abstract

The embodiment of the invention relates to the technical field of software engineering, in particular to a software exception handling method, an exception handling system and a storage medium. According to the embodiment of the invention, the reference exception is captured according to the detection rule in the project rule base of the target project, the exception snapshot information is extracted according to the exception log of the reference exception, and the target information associated with the exception snapshot information is acquired, so that the large language model is called to perform exception diagnosis operation according to the exception snapshot information and the target information. And obtaining an abnormality diagnosis result of the reference abnormality, so that a defect work order and a regression test case are generated according to the abnormality diagnosis result, and a developer develops a corresponding code according to the defect work order to repair the reference abnormality, and automatically executes the regression test case to determine the repair condition of the reference abnormality. The whole exception handling process does not need to switch and use different tools, so that the exception is automatically and intelligently handled, the exception handling efficiency is improved, and mistakes and omissions of exception handling are reduced or avoided.

Description

Technical Field

[0001] This application relates to the field of software engineering technology, and in particular to a software exception handling method, exception handling system and storage medium. Background Technology

[0002] In current software development and operations, with increasingly complex system architectures and the widespread adoption of distributed microservices, the stability and rapid fault recovery capabilities of software systems have become crucial. Traditional exception handling processes employ a combined toolchain: monitoring systems (such as Prometheus and Zabbix) collect metrics and issue threshold alerts; log analysis platforms (such as the ELK stack) aggregate logs; developers manually review logs and analyze code to pinpoint the cause; and defect management systems (such as ZenTao and Jira) manually create and assign work orders. After a fix is ​​completed, testers must manually write regression test cases based on experience for verification. In these technologies, the entire exception handling process involves multiple independent systems, requiring personnel to frequently switch between monitoring, code repositories, project management, and communication tools. This lack of automation and intelligence in exception handling leads to low efficiency and a high risk of errors. Summary of the Invention

[0003] One objective of this application is to provide a software exception handling method, exception handling system, and storage medium to improve the situation in the related art where frequent switching and use of multiple independent systems leads to low exception handling efficiency and easy errors.

[0004] In a first aspect, embodiments of this application provide a software exception handling method, comprising: responding to the creation of a target project, configuring a project rule base for the target project, the project rule base including at least one first detection rule inherited from a public rule base and at least one second detection rule pre-set based on the target project; responding to the first detection rule and the second detection rule capturing a reference exception in the application, obtaining an exception log corresponding to the reference exception; based on the exception log, obtaining exception snapshot information corresponding to the reference exception, the exception snapshot information including an exception stack, a Uniform Resource Locator (URL) of the erroneous interface, and a unique identifier of the user request; and invoking a preset large language model to perform exception diagnosis based on the exception snapshot information and target information associated with the exception snapshot information. The process involves several steps: First, a diagnostic result for the reference anomaly is obtained. Target information represents information in the target project associated with the reference anomaly. Based on the diagnostic result, a defect work order and regression test cases are generated. The application receives the target code and executes the regression test cases. The target code is the code developed based on the defect work order to fix the reference anomaly. Second, user feedback regarding the reference anomaly is received. Based on the feedback, the weights of the target rules are updated. The feedback information represents the accuracy of the reference anomaly capture. The target rules are at least one first detection rule and at least one second detection rule that matches the reference anomaly. Finally, if the regression test cases pass execution and the target rule weights are updated, the reference anomaly repair is confirmed to be complete.

[0005] Secondly, embodiments of this application provide an exception handling system, including a processor and a memory. The processor is communicatively connected to the memory, and the memory stores computer program instructions executable by the processor. When the computer program instructions are executed by the processor, the exception handling system performs the software exception handling method provided in the first aspect.

[0006] Thirdly, embodiments of this application provide a computer-readable storage medium storing processor-executable computer program instructions, which, when executed by a processor, cause the processor to perform the software exception handling method provided in the first aspect.

[0007] The embodiments of this application have the following beneficial effects: Unlike related technologies, the embodiments of this application capture reference anomalies based on the detection rules in the project rule base of the target project, extract anomaly snapshot information from the anomaly log of the reference anomaly, and obtain target information associated with the anomaly snapshot information. Then, a large language model is called to perform anomaly diagnosis based on the anomaly snapshot information and the target information to obtain the anomaly diagnosis result of the reference anomaly. Thus, defect work orders and regression test cases are generated based on the anomaly diagnosis results, so that developers can develop corresponding code to fix the reference anomaly based on the defect work order, and update the weight of the target rule based on the feedback information of the reference anomaly. Regression test cases are automatically executed to determine the repair status of the reference anomaly. The entire anomaly handling process does not require switching or using different tools, realizing automated and intelligent anomaly handling, improving anomaly handling efficiency, and reducing or avoiding errors or omissions in anomaly handling. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the related technologies or embodiments will be briefly introduced below. Obviously, the drawings described below only show some embodiments of this application and should not be considered as limiting the scope of protection. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1A These are schematic diagrams illustrating application scenarios for handling software exceptions in some embodiments of this application; Figure 1B This is a schematic diagram illustrating application scenarios for handling software exceptions in other embodiments of this application; Figure 2 This is a schematic diagram of the structure of an exception handling system provided in some embodiments of this application; Figure 3 This is a flowchart illustrating a software exception handling method provided in some embodiments of this application; Figure 4 This is a schematic diagram illustrating the abnormal diagnosis operation performed by the large language model in some embodiments of this application; Figure 5A This is a schematic diagram of defect work orders generated in some embodiments of this application; Figure 5B This is a schematic diagram illustrating the analysis and generation operations performed by a large language model in some embodiments of this application; Figure 6 This is a flowchart illustrating a software exception handling method provided in other embodiments of this application. Detailed Implementation

[0010] To make the objectives and advantages of the embodiments of this application more readily understood, 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 them. The detailed description of the embodiments of this application in the accompanying drawings is not intended to limit the scope of protection claimed by this application, but only represents selected embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0011] It should be noted that, unless there is a conflict, the various technical features involved in the embodiments of this application described below can be combined with each other, and all are within the protection scope of this application. Furthermore, although functional modules are divided in the device or structural schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. In addition, the terms "first," "second," "third," and other similar expressions used herein do not limit the data or execution order, but are only for illustrative purposes and to distinguish identical or similar items with substantially the same function and effect, and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features.

[0012] Unless otherwise defined, the technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. It should be understood that the term "and / or" as used in this specification includes any and all combinations of one or more of the listed items.

[0013] In current software development and operations, with increasingly complex system architectures and the widespread adoption of distributed microservices, the stability and rapid fault recovery capabilities of software systems have become crucial. Traditional exception handling processes employ a composite toolchain: monitoring systems (such as Prometheus and Zabbix) collect metrics and issue threshold alerts; log analysis platforms (such as the ELK stack) aggregate logs; developers manually review logs and analyze code to pinpoint the cause; and defect management systems (such as ZenTao and Jira) manually create and assign work orders. After a fix is ​​completed, testers must manually write regression test cases based on experience for verification.

[0014] In related technologies, the traditional monitoring and alarm combined with manual troubleshooting method has at least the following drawbacks: 1) Low efficiency: Operation and maintenance personnel need to manually log in to the server to view detailed logs and analyze code logic. The average time to repair (MTTR) usually takes 2 to 4 hours; 2) High dependence on personal experience: The quality of anomaly diagnosis depends entirely on the engineer's technical level and experience accumulation. Novice engineers are prone to missing key clues; 3) Lack of systematic knowledge accumulation: It is impossible to establish a knowledge base of anomaly patterns and a reuse mechanism. Every fault handling is "starting from scratch"; 4) Severe information fragmentation: Monitoring data, log information, and code context are scattered in different systems, requiring manual piecing together of complete information.

[0015] Automated monitoring solutions based on rule engines have at least the following drawbacks: 1) Rigid rules: Static rules are difficult to adapt to system architecture evolution and new abnormal patterns, requiring frequent manual adjustments; 2) High false alarm rate: Simple keyword matching or threshold triggering generates a large number of noisy alarms, with statistics showing that the false alarm rate can reach as high as 40%; 3) Insufficient diagnostic depth: It can only discover surface phenomena and simple patterns, and cannot conduct in-depth root cause analysis; 4) Lack of intelligent learning ability: The rule system cannot learn and optimize from historical processing experience, and false alarm patterns recur.

[0016] The general AI dialogue assistant-assisted analysis solution has at least the following shortcomings: 1) Lack of code context awareness: The AI ​​assistant cannot access and analyze the actual code library, and the generated suggestions lack pertinence and operability; 2) No automated closed loop: It is still necessary to manually create work orders, write test cases, and verify the repair effect, resulting in low automation; 3) Toolchain information silo problem: The integration with the existing DevOps toolchain is low, and information transmission requires manual intervention; 4) Unstable output results: The content generated by AI is not uniform in format, making it difficult to directly integrate into the automated exception handling process.

[0017] In summary, the entire exception handling process in the relevant technologies involves multiple independent systems, requiring personnel to frequently switch between monitoring, code repositories, project management, and communication tools. This fails to automate or intelligently handle exceptions, resulting in low efficiency and a high risk of errors.

[0018] In view of this, embodiments of this application provide a software exception handling method. This method captures reference exceptions based on detection rules in the target project's rule base, extracts exception snapshot information from the reference exception's exception log, and obtains target information associated with the exception snapshot information. Then, a large language model is invoked to perform exception diagnosis based on the exception snapshot information and the target information, resulting in an exception diagnosis result for the reference exception. Based on the exception diagnosis result, defect tickets and regression test cases are generated, enabling developers to develop corresponding code to fix the reference exception. The weights of the target rules are updated based on the feedback information from the reference exception, and regression test cases are automatically executed to determine the status of the reference exception repair. The entire exception handling process does not require switching or using different tools, achieving automated and intelligent exception handling, improving exception handling efficiency, and reducing or avoiding errors in exception handling.

[0019] Please see Figure 1A , Figure 1A The illustrations show application scenarios for handling software exceptions in some embodiments of this application.

[0020] like Figure 1A As shown, this application scenario includes an exception handling system 100. The exception handling system 100 can be any suitable device or apparatus, such as a desktop computer, laptop computer, tablet computer, all-in-one computer, microcontroller, FPGA chip, etc. Figure 1A The exception handling system 100 shown is a laptop computer. The exception handling system 100 can also be any suitable exception monitoring and processing system or platform such as Bonree ONE, Lerwee, ManageEngine, Zabbix, etc.

[0021] For example, when a target project is connected to the exception handling system 100, the exception handling system 100 automatically creates and associates a dedicated project rule base for the target project. The project rule base includes at least one first detection rule and at least one second detection rule. The first detection rule is a detection rule inherited from a public rule base that is "enabled," and the second detection rule is a detection rule pre-set by the target project. When using the project rule base to detect exceptions, the set of detection rules in the project rule base is logically equivalent to the union of the "inherited public enabled rules (i.e., the first detection rule)" and the "target project's dedicated rules (i.e., the second detection rule)."

[0022] For example, the exception handling system 100 has one or more applications installed. The exception handling system 100 uses a project rule base to perform real-time monitoring and detection of the applications, that is, it monitors and detects the applications in real time based on a first detection rule and a second detection rule. When an application experiences a reference exception, the application generates an exception log corresponding to the reference exception and stores the exception log in the local storage of the exception handling system 100. In this embodiment of the application, in response to the first detection rule and the second detection rule detecting that an application has experienced a reference exception, the exception log corresponding to the reference exception is retrieved from the local storage.

[0023] As another example, an application is installed in another system, device, or apparatus. The exception handling system 100 is communicatively connected to this system, device, or apparatus. The exception handling system 100 uses a project rule base to perform real-time monitoring and detection of the application in the system, device, or apparatus, that is, to monitor and detect the application in the system, device, or apparatus in real time based on a first detection rule and a second detection rule. For example, please refer to... Figure 1B Server 200 has an application installed on it. An exception handling system 100 communicates with server 200 via a network and is used to monitor and detect the application on server 200 in real time. When a reference exception occurs in the application, the application generates an exception log corresponding to the reference exception and stores the exception log in local storage on server 200 or in a cloud storage medium. In this embodiment, in response to detecting a reference exception in the application based on a first detection rule and a second detection rule, the exception log corresponding to the reference exception is retrieved from local storage on server 200 or in a cloud storage medium. Alternatively, in some embodiments, server 200 actively sends the exception log to exception handling system 100 via a network.

[0024] Specifically, after obtaining the anomaly log, this embodiment of the application obtains the anomaly snapshot information corresponding to the reference anomaly based on the anomaly log, and obtains the target information associated with the anomaly snapshot information. This embodiment of the application calls a preset large language model to perform anomaly diagnosis operations based on the anomaly snapshot information and the target information to obtain the anomaly diagnosis result of the reference anomaly.

[0025] After obtaining the anomaly diagnosis result, this embodiment generates a defect work order and regression test cases based on the anomaly diagnosis result. The regression test cases are used to test the reference anomaly repair situation. In this embodiment, the generated defect work order is pushed to the relevant repair personnel. The repair personnel develop code (i.e., target code) to repair the reference anomaly based on the defect work order. The repair personnel or other users upload and merge the target code, replacing the original code that caused the reference anomaly. The operation and maintenance personnel or test personnel determine the accuracy of the reference anomaly capture based on the defect work order and the reference anomaly situation, and input feedback information about the reference anomaly into the anomaly handling system 100. This embodiment updates the weight of the target rule based on the feedback information, wherein the target rule is at least one first detection rule and at least one second detection rule that matches the reference anomaly.

[0026] Specifically, when the source code of the reference anomaly in the application is detected to be merged or replaced (i.e., the application receives the target code), this embodiment of the application responds to the application receiving the target code by executing regression test cases to test the reference anomaly repair status. When the regression test cases pass the execution and the weights of the target rules are updated, it indicates that the reference anomaly has been repaired. This embodiment of the application determines that the reference anomaly repair is complete and closes the defect ticket.

[0027] It should be understood that, Figure 1A and Figure 1B The illustrated embodiments are merely illustrative of situations where an exception handling system 100 is used to handle software exceptions in some embodiments of this application, and do not limit the structure, type, or number of exception handling systems in other embodiments. For example, in some other embodiments, the exception handling system may also include... Figure 1A or Figure 1B The laptop shown has more or fewer components, or has the same... Figure 1A or Figure 1B The laptops shown have different configurations.

[0028] To facilitate understanding of the software exception handling method provided in the embodiments of this application, the exception handling system provided in the embodiments of this application will first be described in detail.

[0029] Please see Figure 2 , Figure 2 The schematic diagram illustrates the structure of an exception handling system provided in some embodiments of this application.

[0030] See Figure 2 As shown, the exception handling system 100 includes at least one processor 110 and at least one memory 120 connected in communication, wherein, Figure 2Taking a bus system 130, a processor 110, and a memory 120 as an example, the various components of the exception handling system 100 are coupled together through the bus system 130, which is used to realize the connection and communication between the various components. It is easy to understand that the bus system 130 may include, in addition to the data bus, a power bus, a control bus, and a status signal bus, etc. However, for the sake of clarity and brevity, in... Figure 2 The general labels all buses as Bus System 130. Understandably, Figure 2 The structures shown in the embodiments are merely illustrative and do not limit the structure of the above-described exception handling system. For example, the above-described exception handling system may also include... Figure 2 The structure shown has more or fewer components, or has the same as Figure 2 The diagram shows different configurations of the structure.

[0031] Specifically, processor 110 provides computational and control capabilities to support the exception handling system 100 in executing corresponding business logic and functions. For example, it supports the exception handling system 100 in executing the software exception handling method provided in the embodiments of this application, or in executing the steps of any possible implementation of the software exception handling method provided in the embodiments of this application. It is understood that processor 110 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc., and can also be 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.

[0032] The memory 120, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, instructions, and modules, such as the programs, instructions, and modules corresponding to the software exception handling method in the embodiments of this application. In some embodiments, the memory 120 may include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function, and the data storage area may store data created according to the use of the processor 110. The processor 110 executes various functional applications and data processing of the exception handling system 100 by running the non-transitory software programs, instructions, and modules stored in the memory 120, thereby implementing the software exception handling method provided in the embodiments of this application, or executing the steps in any possible implementation of the software exception handling method provided in the embodiments of this application. In some embodiments, the memory 120 may include high-speed random access memory and may also include non-transitory memory. For example, at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 120 may also include memory remotely located relative to the processor 110, and these remotely located memories may be connected to the processor 110 through a communication network. It is understood that examples of the aforementioned communication networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0033] As can be understood from the above, the entity implementing the software exception handling method provided in this application embodiment can be any suitable type of exception handling system with certain computational and control capabilities, such as the exception handling system 100 described above. In some feasible implementations, the software exception handling method provided in this application embodiment can be implemented by a processor executing computer program instructions stored in memory.

[0034] The software exception handling method provided in this application will be described in detail below with reference to exemplary applications and implementations of the exception handling system provided in the embodiments of this application.

[0035] Understandably, the software exception handling method provided in this application embodiment can be applied to the above-mentioned exception handling system (e.g., exception handling system 100). Specifically, the execution subject of the software exception handling method is one or at least two processors of the exception handling system.

[0036] See Figure 3 As shown, the embodiments of this application implement software exception handling through steps S31 to S38.

[0037] Step S31: In response to the creation of the target project, configure the project rule base for the target project.

[0038] In this embodiment, the project rule base includes at least one first detection rule inherited from the public rule base and at least one second detection rule pre-set based on the target project.

[0039] For example, when the creation of a target project is detected, this embodiment of the application configures a project rule base for the target project. Specifically, it filters at least one detection rule from a public rule base based on the target project, uses the filtered detection rule as a first detection rule inherited from the public rule base, and pre-configures at least one detection rule specific to the target project, using the pre-configured detection rule as a second detection rule. The target project includes any suitable project.

[0040] It is worth noting that the public rule base stores general, validated exception detection rules. These rules, as general-purpose rules, have broad applicability, including detection rules for common programming language exceptions (such as NullPointerException) and common middleware errors (such as database connection timeouts).

[0041] In simple terms, a project rule base is a dedicated rule base configured for each target project connected to the exception handling system. The project rule base includes: a) exception detection rules inherited from the public rule base that are "enabled"; and b) exception detection rules specific to the target project (e.g., detection rules for specific business interfaces or business logic). Operations / testing personnel can locally adjust the weight, status (enabled / disabled), and triggering conditions of any detection rule in the project rule base according to the actual situation of the target project, achieving personalized configuration. Each target project's project rule base is only valid for that target project.

[0042] Understandably, the project rule base and the public rule base together constitute a two-layer dynamic knowledge base system with the capabilities of "public knowledge accumulation" and "project-specific adaptation". It is essentially a dynamically loaded and managed knowledge base, not a flat, static configuration list, and has the ability to "self-evolve". In some embodiments, the core data model design of the rule base is shown in Table 1 below.

[0043] Table 1:

[0044] In Table 1, syntax rules are static content matching based on individual log lines and represent the most basic detection rules. Semantic rules are detection rules that combine dynamic information such as log content, context (e.g., log sequences under the same TraceID), and frequency. Machine learning rules are novel and frequently occurring log patterns discovered by the anomaly handling system through unsupervised learning, suggesting new detection rules. For triggering conditions: projects are described using the powerful expression language SpringSPEL, supporting AND, OR, and NOT logic, regular expression matching, and calling built-in functions. For project / URL: ensuring that detection rules are only effective for specific projects or interfaces, reducing interference between projects or interfaces. For weight values: representing the importance of the problem identified by the detection rule, the weight values ​​of the detection rules can be dynamically adjusted and updated.

[0045] Step S32: In response to the first detection rule and the second detection rule capturing a reference exception in the application, obtain the exception log corresponding to the reference exception.

[0046] For example, embodiments of this application capture reference exceptions occurring during application runtime using an exception detector (e.g., a global exception capture hook) based on at least one first detection rule and at least one second detection rule. When a reference exception is captured, embodiments of this application extract log data for the corresponding time window from a logging system (e.g., ELK, distributed log chain), and perform log association aggregation by combining the unique identifier (TraceID) of the user request to obtain the exception log corresponding to the reference exception.

[0047] In the process of monitoring and capturing anomalies based on detection rules, this embodiment of the application performs two levels of matching and adjudication: 1) Parallel matching: For any log, all enabled detection rules in the target project's rule library are matched simultaneously (including inherited first detection rules and preset second detection rules); 2) Weight adjudication: Among all successfully matched detection rules, the detection rule with the highest weight value is selected as the primary triggering rule (i.e., the target rule, the most relevant and important detection rule in the following text). The weight value of the primary triggering rule determines the severity level of the anomaly alarm, and its information will be used in the subsequent anomaly diagnosis process; 3) Alarm suppression: This weight competition mechanism ensures that the same anomaly is only triggered by the most relevant and important single detection rule, effectively avoiding duplicate alarms.

[0048] Step S33: Based on the exception log, obtain the exception snapshot information corresponding to the reference exception.

[0049] The exception snapshot information includes the exception stack trace, the Uniform Resource Locator (URL) of the interface that caused the error, the unique identifier of the user request (TraceID), request parameters, and the time of occurrence. The exception stack trace includes detailed information such as the class, method, and line number of the error.

[0050] For example, in this embodiment of the application, core information (including exception stack, Uniform Resource Locator of the error interface, unique identifier of the user request, request parameters, occurrence time, etc.) is extracted from the exception log to obtain exception snapshot information corresponding to the reference exception.

[0051] Step S34: Call the preset large language model to perform anomaly diagnosis based on the anomaly snapshot information and the target information associated with the anomaly snapshot information, and obtain the anomaly diagnosis result of the reference anomaly.

[0052] In this embodiment, the anomaly diagnosis results include root cause analysis, scope of impact, remediation recommendations, and recommended responsible parties. Root cause analysis refers to the analysis results obtained from analyzing the causes of the reference anomaly, including direct causes, underlying causes, and root causes. Scope of impact refers to the functions and performance affected by the reference anomaly. Remediation recommendations refer to suggested modifications to the source code corresponding to the reference anomaly. The recommended responsible parties are the relevant personnel responsible for handling the reference anomaly, such as developers or the development team.

[0053] For example, in this application embodiment, target information associated with the abnormal snapshot information is obtained. The target information represents information in the target project associated with the reference abnormality. The target information includes the call information of the erroneous interface (such as the interface call chain, method call chain), the context code data corresponding to the reference abnormality, the requirement content, etc.

[0054] For example, in this application embodiment, the abnormal snapshot information is converted into a unified structure, that is, the abnormal stack is parsed in layers to extract information such as the abnormal type and error code, the Uniform Resource Locator of the error interface is standardized, the log printing is standardized, and the printed log includes the URL of the error interface, request parameters, and the globally unique TraceId (i.e., unique identifier) ​​of the user request. The unique identifier of the user request is extended by association, and upstream and downstream call information is supplemented by TraceID. The context information is trimmed and denoised, duplicate logs are removed, key error fragments (such as ERROR level) are retained, and structured abnormal snapshot information is output, including abnormal summary, call chain log, interface information, and request context.

[0055] Specifically, in this embodiment of the application, a diagnostic prompt template is constructed based on structured anomaly snapshot information and target information. The diagnostic prompt template includes system instructions (including root cause analysis instructions, impact scope assessment rules, remediation suggestion generation constraints, and recommended responsible person constraints), input data (i.e., structured anomaly snapshot information and target information), and inference constraint rules (e.g., root cause analysis must be based on call chain inference, remediation suggestions must match the anomaly type, and the recommended responsible person must be based on code ownership or submission records).

[0056] For example, in this application embodiment, a pre-configured large language model is selected, inference parameters are set, a single-round or multi-round inference mechanism is adopted, inference diagnosis is performed according to the diagnostic prompt template, output results are obtained, the output results are parsed, standard fields are extracted (including root cause analysis (such as null pointer, uninitialized resource), scope of impact (such as the scope of affected interfaces and affected users), repair suggestions (such as modifying code location and repair method) and recommended responsible persons (such as developer or team name)) to obtain the abnormal diagnosis results of the reference anomaly.

[0057] Step S35: Generate defect work orders and regression test cases based on the anomaly diagnosis results.

[0058] The defect work order includes root cause analysis, scope of impact, repair recommendations, repairer, project, and affected version.

[0059] For example, the anomaly diagnosis results are mapped to standardized work order fields. Specifically: a defect title is generated based on the anomaly type and erroneous interface from the anomaly diagnosis results; the anomaly phenomenon, triggering conditions, and root cause analysis from the anomaly diagnosis results are filled into the problem description and root cause fields; the repair suggestions from the anomaly diagnosis results are converted into specific, executable development task descriptions and filled into the repair suggestion field. The impact scope from the anomaly diagnosis results is mapped to a specific list of affected modules and interfaces. The recommended responsible person from the anomaly diagnosis results is assigned as the repairer and filled into the repairer field. The deployment version at the time of the reference anomaly occurrence is obtained from the CI / CD system or configuration center as the affected version, and the deployment project at the time of the reference anomaly occurrence is obtained as the project to which it belongs. These fields are encapsulated into a standard work order data structure. A defect work order is created by calling the work order system interface, returning a unique work order identifier (TicketID), establishing a mapping relationship between the reference anomaly ID and the defect work order ID (i.e., associating the reference anomaly with the defect work order), and finally obtaining the defect work order.

[0060] For example, this application embodiment parses the root cause analysis, scope of impact, and repair suggestions in the anomaly diagnosis results to deduce the test intent and clarify the core scenario that needs to be tested and verified (e.g., "verify XXX null pointer repair"). Combining key information from the anomaly snapshot information (such as the erroneous interface and parameters) with relevant code snippets obtained from the code repository, a test generation context is formed. The deduced test intent and test generation context are submitted to the large language model through a prompt word template specifically generated for testing. The instruction large language model acts as a senior test developer, generating directly executable regression test case code. The regression test case code is standardized into a standard test case format (including name, input, expected output, and assertion conditions, etc.), and the regression test case code is bound to the defect ticket ID to form a tracking relationship.

[0061] Step S36: In response to the application receiving the target code, execute the regression test cases.

[0062] In this embodiment of the application, the target code is code developed by the repairer based on the defect work order to repair the reference anomaly.

[0063] For example, after the fixer submits the target code, this application embodiment determines whether the application has received the target code by receiving the code source, identifying the association between the code and the reference exception, etc. When the application receives the target code, it performs standardized construction of the target code, performs compilation / packaging and dependency checks, builds a test environment consistent with or similar to the environment in which the reference exception occurred, deploys the target code to the test environment, initializes the runtime environment (such as service instances, databases, middleware), constructs or restores the business data at the time of the reference exception, configures environment parameters, selects regression test cases (including core test cases and extended test cases) associated with the reference exception, executes the regression test cases and monitors the execution of test cases, assertion verification, and exceptions in real time, and summarizes and analyzes the test case execution results to obtain the summary analysis results. Core test cases refer to test cases directly associated with the reference exception, and extended test cases refer to historical exception test cases of the same module, test cases related to the same interface, etc.

[0064] Step S37: Respond to user input regarding feedback on reference anomalies, and update the weights of the target rule based on the feedback.

[0065] The feedback information is used to characterize the accuracy of the reference anomaly capture. The target rule is the detection rule that matches the reference anomaly among at least one first detection rule and at least one second detection rule. The detection rule that matches the reference anomaly refers to the most relevant and important detection rule among one or more detection rules triggered by the reference anomaly in the project rule base. In some embodiments, the most relevant and important detection rule among one or more triggered detection rules is determined according to the weight value of the detection rule, wherein the detection rule with the highest weight value is the most relevant and important detection rule.

[0066] This application proposes a dynamic adjustment design for rule weights based on feedback: each detection rule has a corresponding weight value, and the initial weight value is set according to the severity of the detection rule. For example, for high-risk detection rules, the initial weight value is set to 90-95, for medium-risk detection rules, the initial weight value is set to 80-89, and for low-risk detection rules, the initial weight value is set to 60-79.

[0067] For example, when a reference exception occurs in the application but before it is fixed, testers or operations personnel (i.e., users) select to input feedback information in the exception handling system to indicate whether the captured reference exception is accurate (i.e., whether the reference exception exists, is negligible, or does not exist / is a false alarm). Feedback information includes positive feedback, weak negative feedback, and strong negative feedback. For a specific detection rule, inputting "exception exists" indicates that the detection rule has received positive feedback; inputting "exception is negligible" indicates that the detection rule has received weak negative feedback; and inputting "exception does not exist / is a false alarm" indicates that the detection rule has received strong negative feedback.

[0068] For example, in this embodiment of the application, the weight value of the detection rule is adjusted and updated based on the feedback information (such as positive feedback information, weak negative feedback information, or strong negative feedback information) input by the testers or maintenance personnel. The adjustment and update strategy follows the following principles: when positive feedback information is received, the weight value of the detection rule is moved closer to the maximum weight value, and the increase in weight slows down as the current weight of the detection rule increases; when strong negative feedback information is received, the weight value of the detection rule is reduced according to the current weight ratio of the detection rule, and the penalty is strong; when weak negative feedback information is received, the weight value of the detection rule is reduced according to the current weight ratio of the detection rule, and the penalty is halved.

[0069] The embodiments of this application automatically adjust and update the weights of the detection rules based on positive / negative feedback information, enabling the anomaly handling system to have self-learning capabilities, significantly reducing the false alarm rate of anomalies, and achieving better anomaly detection performance than static rule engines.

[0070] Step S38: In response to the successful execution of the regression test case and the completion of the weight update of the target rule, determine that the reference anomaly repair is complete.

[0071] For example, the summary analysis results include the number of passed test cases, the total number of test cases, the list of failed test cases, and the anomaly reproduction status. When all core test cases pass, the reference anomaly is not reproduced, and no new serious anomalies are added, it indicates that the regression test case execution is successful. When it is detected that the regression test case execution is successful and the weight of the target rule is updated, it indicates that the reference anomaly has been fixed, and this application embodiment determines that the reference anomaly fix is ​​complete. This application embodiment obtains relevant data (such as execution results and coverage) from the code execution results, thereby generating a test report (including test coverage, execution results, and anomaly analysis), writing it back to the work order system, and updating the defect work order status (such as "fixed and verified" or "fix failed").

[0072] This application embodiment captures reference anomalies based on detection rules in the target project's rule base, extracts anomaly snapshot information from the anomaly log of the reference anomaly, and obtains target information associated with the anomaly snapshot information. Then, it calls a large language model to perform anomaly diagnosis based on the anomaly snapshot information and target information, obtaining the anomaly diagnosis result of the reference anomaly. Based on the anomaly diagnosis result, a defect ticket and regression test cases are generated, enabling developers to develop corresponding code to fix the reference anomaly. The weights of the target rules are updated based on the feedback information of the reference anomaly, and regression test cases are automatically executed to determine the status of the reference anomaly repair. The entire anomaly handling process does not require switching or using different tools, achieving automated and intelligent anomaly handling, improving anomaly handling efficiency, and reducing or avoiding errors in anomaly handling.

[0073] In some embodiments, the present application implements steps S341 to S342 to call a preset large language model to perform anomaly diagnosis based on anomaly snapshot information and target information associated with the anomaly snapshot information, and obtain anomaly diagnosis results of reference anomalies.

[0074] Step S341: Obtain target information based on abnormal snapshot information.

[0075] The target information includes service call logs for user requests, call information for erroneous interfaces, context code data corresponding to reference exceptions, requirement content, table structure information, and code commit data. The code commit data includes Git commit records, modified files, authors, etc.

[0076] For example, the entire call chain log is retrieved based on the TraceID (i.e., the unique identifier of the user request), and user requests, responses, exception information, etc. are parsed. Irrelevant logs are removed, and the call chain log is structured into an interface call sequence. parameter status codes The service call logs for user requests are obtained in timestamp format, including dependencies between various services. The method signatures, input parameters, and return values ​​of the erroneous interfaces are extracted, the location of the exception and the call point are marked, and the complete call chain of each method in the erroneous interface is obtained, forming a complete call chain sequence to obtain the call information of the erroneous interface. The source code of classes / functions related to the reference exception is obtained, the exception line numbers and key variables are marked, the associated branches and commit versions are obtained, resulting in context code data. The corresponding requirement descriptions, table structures, field constraints, etc., are structured and associated with the exception triggering scenario to obtain requirement content and table structure information. The most recent modification records and author information are obtained, compared with historical versions, and the lines of code that may have been modified to affect the exception are identified, and integrated to obtain code commit data.

[0077] Specifically, in this embodiment of the application, steps S3411 to S3416 are used to obtain target information based on abnormal snapshot information.

[0078] Step S3411: Obtain the service call log of the user request based on the unique identifier.

[0079] Step S3412: Obtain the call information of the erroneous interface based on the Uniform Resource Locator of the erroneous interface.

[0080] Step S3413: Based on the error code in the exception stack, obtain the context code associated with the error code, the metadata of the error code, and the commit record information as context code data.

[0081] Step S3414: Extract the requirement number from the submission record information and obtain the requirement content associated with the requirement number.

[0082] Step S3415: Obtain table structure information based on the metadata of the error code.

[0083] Step S3416: Obtain the code submission data corresponding to the requirement number.

[0084] In step S3411, the service call log of the user request is obtained based on the unique identifier of the user request. That is, the complete call chain of the user request on all relevant services is retrieved from the log storage to form the service call log (i.e., call chain log).

[0085] In step S3412, the call information of the erroneous interface is obtained according to the Uniform Resource Locator of the erroneous interface, that is, the complete call chain information of the erroneous interface is obtained by calling the interface of the integrated development and operation platform. The complete call chain information includes the interface call chain, method call chain, etc.

[0086] In step S3413, based on the error code in the exception stack, the context code associated with the error code, the metadata of the error code, and the commit record information are obtained as context code data. That is, based on the error code in the exception stack, the integrated development and operation platform interface is called to obtain the code context, metadata (including methods and entity classes), and code commit record (i.e., commit record information) corresponding to the error code as context code data.

[0087] In step S3414, the project process specification requires developers to include a requirement number when submitting code (e.g., #2510050 Batch code generation cancels the upper limit of 20, #2510050 is the requirement number). Therefore, in this embodiment, the requirement number is extracted from the submission record information, and then the integrated development and operation platform interface is called to obtain the requirement content associated with the requirement number.

[0088] In step S3415, the metadata of the error code includes the entity class mapped to the database table. By parsing the object of this entity class (such as relational mapping annotations or mapping configuration files), the corresponding database table structure information is extracted. Specifically, the ORM framework defines the mapping rules between entity class attributes and database table fields by using annotations such as @Table, @Column, and @Id on the entity class, or by declaring them in the configuration file. Parsing this mapping metadata obtains complete table structure definition information such as the table name, field name, field data type, and constraints of the target database. For example, when the error code involves an entity class named User, by parsing the class definition of the entity class User, it is found that the entity class User is annotated with @Table(name="user_info") and contains a username attribute annotated with @Column(name="user_name", nullable=false). Based on this, this embodiment of the application can determine the relevant table structure information as follows: there is a data table named user_info, and the data table user_info contains a field named user_name that cannot be null.

[0089] In step S3416, since step S3314 extracts the requirement number corresponding to the error code, this embodiment of the application calls the interface of the version management system to obtain the code submission data (such as all code submission records, modified files, etc.) corresponding to this requirement number.

[0090] Step S342: Call the large language model to perform anomaly diagnosis based on the anomaly snapshot information and target information to obtain the anomaly diagnosis result.

[0091] In this embodiment, the anomaly snapshot information is used to describe the occurrence of a reference anomaly, and the target information is used to describe "the environment, code, data, and historical changes related to the reference anomaly." The anomaly snapshot information and the target information are combined to generate a unified model input, including contextual descriptions (i.e., the anomaly snapshot information) and structured fields (including service call logs, call information, code snippets, requirement descriptions, table structure information, and submitted data). A diagnostic prompt template for the model input is constructed, which includes role definitions (e.g., "You are a software anomaly diagnosis expert, and you need to analyze the root cause of the anomaly, its scope of impact, remediation suggestions, and recommend responsible parties"), input data references (introducing the anomaly snapshot information and target information, specifying key fields (such as call logs, stack traces, code snippets, requirement content, table structure, and submitted data)), and output constraints.

[0092] For example, in this embodiment of the application, a pre-configured large language model is invoked, inference parameters are set, and anomaly snapshots, target information, and a diagnostic prompt template are input. After model inference and diagnosis, anomaly diagnosis results are output. In some embodiments, model inference and diagnosis can adopt a multi-round inference mechanism. The first round outputs the analysis basis (root cause, abnormal path, suspicious code line), and the second round extracts the root cause analysis, scope of impact, remediation suggestions, and recommended responsible persons to generate structured and standardized anomaly diagnosis results.

[0093] For example, in the embodiments of this application, steps S3421 to S3422 are used to call the large language model to perform anomaly diagnosis operations based on the anomaly snapshot information and target information, and obtain anomaly diagnosis results.

[0094] Step S3421: Construct abnormal diagnostic prompts.

[0095] In this embodiment, the anomaly diagnosis prompts include a first prompt regarding the defined model role as an anomaly diagnosis expert and a second prompt regarding the diagnostic analysis requirements. For example, the first prompt is "You have 10 years of full-stack architecture design experience, are a software anomaly diagnosis expert, and need to analyze the root cause of the anomaly, its scope of impact, remediation suggestions, and recommend a responsible person." The second prompt is "You need to locate the problem entry point based on the anomaly stack, analyze the propagation path by combining the call chain, analyze possible causes by combining the code and commit records, analyze whether the reference anomaly conflicts with business rules or data constraints by combining requirements and table structure information, for root cause analysis, point out the specific code defects or errors in business logic / algorithm logic / program flow, for scope of impact, point out the interface / module / user scope, for remediation suggestions, point out the direction of modification, and for recommending a responsible person, determine based on code ownership or commit records."

[0096] For example, in this application embodiment, the model role is designated as "software anomaly diagnosis expert", and the scope of responsibilities is clearly defined: analyze the root cause of the anomaly, determine the scope of impact, provide repair suggestions, determine the recommended responsible person, and construct anomaly diagnosis prompt words.

[0097] Step S3422: Input the anomaly diagnosis prompt, anomaly snapshot information, and target information into the large language model so that the large language model can analyze and diagnose the anomaly snapshot information and target information based on the anomaly diagnosis prompt and obtain the anomaly diagnosis result.

[0098] For example, layered modeling is used for input data (i.e., exception snapshot information and target information) to reduce model complexity and enhance reasoning logic. The first layer is the exception scenario layer. The first input information for this layer includes exception snapshot information (including exception stack trace, exception type, Uniform Resource Locator (URL) of the erroneous interface, request parameters, and occurrence time), used to describe the reference exception itself and quickly locate the problem entry point. The second layer is the call context layer. The first input information for this layer includes service call logs (i.e., call chain logs), return results of request parameters, and upstream and downstream service interaction information, used to describe the occurrence process of the reference exception and analyze the exception propagation path. The third layer is the system implementation layer. The first input information for this layer includes context code data (such as exception functions / classes), data table structure information, key variables, and interface call chains, used to describe the implementation details of the reference exception and locate the code-level root cause. The fourth layer is the business background layer. The first input information for this layer includes requirement documents, requirement change records, and code submission history information (such as change records and submitters), used to describe the business background and changes, and to identify whether the problem is due to requirement changes or code-introduced issues.

[0099] For example, in this embodiment, the anomaly diagnosis prompts and multiple levels of first input information are organized in ascending order of depth, namely, first prompt (role definition), second prompt (diagnostic analysis requirements), first level of first input information, second level of first input information, third level of first input information, and fourth level of first input information. The organized prompts and input information are input into the large language model, explicitly instructing the model to analyze information layer by layer, to indicate the source level of each conclusion (e.g., based on call chain or code), and to prohibit skipping key levels and directly giving conclusions. Finally, the large language model analyzes and diagnoses the first input information at multiple levels based on the anomaly diagnosis prompts and outputs anomaly diagnosis results in JSON format. The anomaly diagnosis results include root cause analysis (e.g., based on stack trace, call chain, code to locate the specific problem cause, pointing out the key code or logic that triggered the anomaly), scope of impact (including affected interfaces, services or modules, and user impact), repair suggestions (including code modification suggestions, data processing suggestions, fault tolerance mechanisms (e.g., null checks and retries)), and recommended responsible party (e.g., determined based on code submission information or module affiliation).

[0100] For example, please see Figure 4 The abnormal diagnosis prompts (including the first and second prompts) and the first input information at multiple levels (including the first input information at the first level, the first input information at the second level, the first input information at the third level, and the first input information at the fourth level) are input into the large language model. The large language model performs anomaly analysis and diagnosis on the first input information at multiple levels based on the abnormal diagnosis prompts to obtain the abnormal diagnosis results.

[0101] For example, in this embodiment of the application, steps S351 to S355 are used to generate defect work orders based on abnormal diagnosis results.

[0102] Step S351: Create an initial work order.

[0103] In this embodiment, the initial work order includes a first field about the person performing the repair, a second field about the project to which the person belongs, a third field about the affected version, a fourth field about the root cause analysis, a fifth field about the scope of the impact, and a sixth field about the repair recommendations.

[0104] For example, a standardized work order data structure is constructed, which includes at least the following fields: a first field (associated repairer), a second field (associated project), a third field (associated affected version), a fourth field (associated root cause analysis), a fifth field (associated impact scope), and a sixth field (associated repair suggestion). In some embodiments, the standardized work order data structure also includes fields such as defect title, priority / severity, creation time, and reference anomaly ID. All fields are initialized to empty values ​​or default placeholder values ​​to obtain the initial work order.

[0105] Step S352: Populate the first field with the recommended person in charge as the person responsible for the repair.

[0106] Step S353: Fill the second field with the project name corresponding to the target rule as the project to which it belongs.

[0107] Step S354: Fill the third field with the preset default value as the affected version.

[0108] Step S355: Fill the root cause analysis, scope of impact, and remediation suggestions into the fourth, fifth, and sixth fields respectively to obtain the defect work order.

[0109] For example, the recommended responsible person from the anomaly diagnosis results is obtained, converted into a system user ID, and populated into the first field as the repairer. In some embodiments, if the recommended responsible person does not exist, a substitute is made based on the code commit record or module owner, or marked as "pending assignment". In some embodiments, the reference anomaly may trigger multiple detection rules simultaneously (e.g., triggering both an anomaly type rule and a service classification rule). Based on a preset priority (e.g., interface attribution rules take precedence over service classification rules), the most relevant and important detection rule is determined as the target rule from all the detection rules triggered by the reference anomaly, and used to extract information such as the project name. The target rule is obtained, and information such as the project name is extracted from the target rule and populated into the second field. Detection rules include anomaly type rules, interface attribution rules, or service classification rules, etc.

[0110] For example, a preset default value (e.g., the trunk version) is obtained, and the preset default value is used as the affected version to fill the third field. In some embodiments, the running version can also be automatically inferred based on the time of the exception, or the running version can be matched with the deployment record, and the running version can be used as the affected version to fill the third field.

[0111] For example, the root cause analysis, scope of impact, and remediation suggestions are extracted from the anomaly diagnosis results. These are then filled into the fourth, fifth, and sixth fields, respectively. The root cause analysis, scope of impact, and remediation suggestions are standardized, such as by removing redundant descriptions and extracting key conclusions. The filled fields are combined into a complete work order, which is then created by calling the work order system interface to obtain a defect work order. In some embodiments, a mapping relationship between a reference anomaly ID and a defect work order ID is established, and the generation time and source are recorded in the defect work order.

[0112] For example, please see Figure 5A , Figure 5A The following are examples of defect work orders generated in some embodiments of this application. Figure 5A The defect ticket shown includes fields 51: Project, 52: Affected Version, 53: Assigned Person (i.e., Fixer), 54: Bug Title (i.e., Defect Title), 55: Severity, 56: Priority, and 57: Reproduction Steps. Each field is populated with its corresponding value. It is understandable that some fields in the defect ticket must be filled with values, while others do not.

[0113] For example, in the embodiments of this application, steps S356 to S357 are used to generate regression test cases based on the anomaly diagnosis results.

[0114] Step S356: Obtain reference information.

[0115] In this embodiment, the reference information includes the call information of the error interface, the context code data corresponding to the reference exception, the requirement content, the table structure information, and the code submission data.

[0116] Specifically, this application embodiment extracts interface identifiers (such as interface name / URL / method signature), call data (such as request parameters, return results), and exception trigger points (such as exception location, call point) as call information for the erroneous interface. This application embodiment obtains code snippets related to the reference exception (including exception functions or classes, key logic branches), annotates exception locations (e.g., line numbers, involved variables), and key variables, associated branches, and commit versions as context code data. This application embodiment extracts requirement content (including functional logic, input / output constraints), extracts requirement change records (including modified content, modification time, change reason, etc.), and the association between change points and exceptions as requirement content change record information. The corresponding table structure, field constraints, etc., are structured and associated with the exception triggering scenario to obtain table structure information. The most recent modification records and author information are obtained, compared with historical versions, and the lines of code that may be affected by the modification are identified and integrated to obtain code commit data.

[0117] Step S357: Call the large language model to perform test case generation operation based on reference information, anomaly diagnosis results and anomaly snapshot information to obtain regression test cases.

[0118] For example, construct prompts for calling a large language model. The prompts include at least the role definition (e.g., "You are a software test engineer and need to generate test cases for verifying anomaly repair"), input information (including reference information, anomaly diagnosis results, and anomaly snapshot information), test case generation constraints (including coverage scenarios, such as anomaly reproduction scenarios, repair verification scenarios, and boundary test scenarios), and output format constraints.

[0119] For example, in this embodiment of the application, a pre-configured large language model is invoked, inference parameters are set, prompt information is input, and regression test cases are generated through model inference and output. In some embodiments, model inference generation can adopt a phased inference generation mechanism, in which the first phase generates test scenarios, the second phase expands them into complete test cases, and the model outputs a set of regression test cases, wherein the set of regression test cases includes regression test cases in a standard test case format.

[0120] For example, in the embodiments of this application, steps S3571 to S3573 are used to call the large language model to perform test case generation operations based on reference information, anomaly diagnosis results and anomaly snapshot information to obtain regression test cases.

[0121] Step S3571: Build test cases and generate prompt words.

[0122] In this embodiment, the test case generation prompts include a third prompt regarding the defined model role as a test case generation expert and a fourth prompt regarding the requirements for test case generation. For example, the third prompt is "You have over 10 years of software testing experience, are a software test case expert, and need to generate test cases." The fourth prompt is "You need to build anomaly reproduction test cases based on anomaly snapshot information, repair verification test cases based on anomaly diagnosis results, and boundary and extension test cases based on reference information. Test cases should at least include anomaly reproduction scenarios, repair verification scenarios, impact scope verification scenarios, and boundary test scenarios. Each output test case must include a test case name, preconditions, input data, execution steps, assertion content, expected results, and test case type."

[0123] For example, in this application embodiment, the model role is designated as "software test case expert", and the scope of responsibilities is clearly defined: generate regression test cases based on anomaly information (including reference information, anomaly snapshot information and target information). The test cases need to cover scenarios such as anomaly reproduction, repair verification and boundary testing, and construct test case generation prompt words.

[0124] Step S3572: Input the test case generation prompts, reference information, anomaly diagnosis results, and anomaly snapshot information into the large language model, so that the large language model can perform test case analysis and generation based on the test case generation prompts, reference information, anomaly diagnosis results, and anomaly snapshot information to obtain regression test cases.

[0125] For example, the input data (including reference information, anomaly diagnosis results, and anomaly snapshot information) is modeled in layers to reduce the complexity of model understanding and enhance the logical reasoning. The first layer is the anomaly scenario layer. The second input information for this layer includes anomaly snapshot information (including the anomaly stack, anomaly type, the Uniform Resource Locator (URL) of the erroneous interface, request parameters, and occurrence time), used to describe the reference anomaly itself and serve as a direct basis for reproducing the anomaly. The second layer is the diagnostic conclusion layer. The second input information for this layer includes root cause analysis, impact scope, and remediation suggestions, used to describe the analysis conclusions and serve as the core input for designing test cases to verify the effectiveness of the remediation and assess the impact. The third layer is the system implementation layer. The second input information for this layer includes context code data, data table structure information, key variables, and interface call chains, used to deduce boundary conditions, anomaly data, and logical branches, thereby generating boundary test cases and logical test cases. The fourth level is the business background layer. The second input information of the fourth level includes requirements documents, requirements change records, code submission history information (such as change records and submitters), etc., which are used to determine whether the exception is related to recent business logic changes or code submissions, thereby generating test cases to ensure business consistency.

[0126] For example, in this embodiment, the test case generation prompts and multiple levels of second input information are organized in ascending order, namely, the third prompt (role definition), the fourth prompt (test case generation requirements), the first level of second input information, the second level of second input information, the third level of second input information, and the fourth level of second input information. The organized prompts and input information are input into the large language model, explicitly instructing the model to analyze information layer by layer and generate different types of test cases for different levels. The large language model generates test cases for the multiple levels of second input information based on the test case generation prompts and outputs regression test cases in a standard test case format. Among them, regression test cases include anomaly reproduction test cases (such as those generated based on anomaly snapshot information and call chains), repair verification test cases (generated based on root cause analysis and repair suggestions), and boundary test cases (generated based on code logic and data structure, covering null values, extreme values, illegal values, etc.).

[0127] For example, please see Figure 5BThe test case generation prompts (including third and fourth prompts) and multiple levels of second input information (including first-level, second-level, third-level, and fourth-level second input information) are input into the large language model. The large language model analyzes the multiple levels of second input information based on the test case generation prompts to generate regression test cases. The test case code includes code related to anomaly reproduction cases, repair verification cases, and boundary test cases. The test configuration set includes environment configuration requirements and parameterized configurations. The test data file includes pre-set data (such as boundary value data, abnormal data, and normal data) and a data generator.

[0128] like Figure 6 As shown, in some embodiments, the software exception handling method provided in this application further includes steps S61 to S65.

[0129] Step S61: Obtain error logs generated within a predetermined period.

[0130] Step S62: Parse the error log and extract the log template corresponding to the error log.

[0131] In this embodiment, the error log is the log with an error level (ERROR) from the acquired exception log. The predetermined period is a duration or time period customized by engineers based on their engineering experience, for example, a predetermined period of 7 days from the current time.

[0132] For example, in this embodiment, all exception logs are obtained from the log storage, and error logs generated within a predetermined period are extracted from the exception logs. That is, all logs with an error (ERROR) level within 7 days from the current time (i.e., the predetermined period) are collected once a week. A log parsing algorithm (e.g., the Drain algorithm) is used to parse each error log and extract the log template corresponding to the error log. For example, in some embodiments, a specific error log is: "ERROR [2025-10-27 14:30:15] OrderService - Deduct inventory failed for order: PO202310271432, sku: A1B2C3, reason: InsufficientStock". The Drain algorithm is used to parse this error log into the log template: "* OrderService - Deduct inventory failed for order: *, sku: *, reason: InsufficientStock".

[0133] Step S63: Cluster all log templates to obtain log clustering results.

[0134] For example, embodiments of this application use unsupervised clustering algorithms (such as DBSCAN (density-based noisy application space clustering algorithm)) to cluster all log templates to obtain log clustering results. The DBSCAN algorithm can automatically discover clusters of arbitrary shapes and can separate very rare and unique noisy log points.

[0135] Step S64: In response to the log clustering results not being covered by candidate rules and being dense and regular log clusters, generate new detection rules based on the log clustering results.

[0136] Step S65: Add the new detection rule as the second detection rule to the project rule library.

[0137] In this embodiment, the candidate rule is any one of at least one first detection rule and at least one second detection rule from the project rule base. The new detection rule is disabled and its weight value is the standard weight value. In this embodiment, the standard weight value is set to 60.

[0138] For example, in this embodiment, the log clustering results are matched with the detection rules in the target rule base. If the log clustering results can be well covered by any detection rule (i.e., candidate rule) in the target rule base, the log clustering results are ignored. If the log clustering results are not covered by candidate rules and are dense and regular log clusters, the log clustering results represent a systematic new abnormal pattern that has not yet been monitored. In this embodiment, a new detection rule is generated based on the log clustering results, the status of the new detection rule is set to disabled, the weight value is set to the standard weight value of 60, and the new detection rule is added as a second detection rule to the list of rules to be reviewed in the project rule base. Operation and maintenance personnel or testers can check, adjust, and enable the new detection rule. If the log clustering result is scattered "noise points", it indicates that the log clustering result is a one-off, occasional anomaly. The log clustering result is temporarily ignored, but it will be recorded for review by operations and maintenance personnel. In this embodiment, a new detection rule is generated based on the log clustering result. The new detection rule is set to disabled, its weight is set to the default weight value of 0, and it is added as a second detection rule to the list of rules to be reviewed in the project rule library. Operations and maintenance personnel or testers can check, adjust, and enable the new detection rule.

[0139] In some embodiments, this application automatically evaluates the promotion value of each second detection rule in the project rule base. Evaluation metrics include: the accuracy of the detection rule (positive feedback ratio > 50%), the number of triggers in the target project (greater than 1 time), and the potential matching degree in other projects discovered through log pattern similarity detection. When the comprehensive evaluation score of a detection rule exceeds a preset threshold, the detection rule is marked as having promotion recommendations. After confirmation by an administrator (such as operations personnel), the detection rule is promoted and synchronized to the public rule base, while simultaneously recording the source information of the detection rule. Through this method, all other projects that inherit rules from the public rule base can benefit, achieving a knowledge-sharing effect of "discovery in one place, global immunity."

[0140] For example, in the embodiments of this application, the weight of the target rule is updated based on the feedback information through steps S371 and S37A, or steps S372 and S37A, or steps S373 and S37A.

[0141] Step S371: If the response feedback information is positive feedback information, add the current weight of the target rule to the first weight change value to obtain the initial update weight of the target rule.

[0142] Among them, positive feedback information is used to characterize the existence of reference anomalies, the first weight change value is the product of the preset learning rate and the weight difference, and the weight difference is the difference between the preset weight upper limit threshold and the current weight.

[0143] In this embodiment, a preset learning rate is used. Set it to 0.1, that is Weight cap threshold Set to 95, that is Weighted lower limit threshold Set to 60, that is The current weight of the target rule is... The weight difference is .

[0144] Specifically, when the feedback information is positive, this embodiment of the application obtains the current weight of the target rule. (like ), and the upper limit threshold of the weight Subtract the current weight The weighted difference is obtained. ,Right now: Set the preset learning rate. Difference from weight Multiply to obtain the first weight change value. ,Right now: Set the current weight of the target rule. Change value of the first weight Add them together to obtain the initial update weights of the target rule. ,Right now: .

[0145] Step S372: The response feedback information is weak negative feedback information. Add the second weight change value to the current weight of the target rule to obtain the initial update weight of the target rule.

[0146] In this embodiment, weak negative feedback information is used to characterize that the reference anomaly is negligible. The second weight change value is the product of the reference ratio and the current weight. The reference ratio is the ratio of the negative of the preset learning rate to the first preset value, and the first preset value is 2.

[0147] Specifically, when the feedback information is weak negative feedback information, this embodiment of the application obtains the current weight of the target rule. (like ), and preset learning rate The ratio of the opposite of the first preset value 2 to the first preset value 2 is used as a reference ratio. ,Right now: Use the reference ratio With current weight Multiply by this to obtain the second weight change value. ,Right now: Set the current weight of the target rule. Compared with the second weight change value Add them together to obtain the initial update weights of the target rule. , that is: .

[0148] Step S373: If the response feedback is strong negative feedback, add the third weight change value to the current weight of the target rule to obtain the initial update weight of the target rule.

[0149] In this embodiment, strong negative feedback information is used to characterize the absence of reference anomalies, and the third weight change value is the product of the negative of the preset learning rate and the current weight.

[0150] Specifically, when the feedback information is strong negative feedback information, this embodiment of the application obtains the current weight of the target rule. (like ), set the preset learning rate The opposite of the current weight Multiply to obtain the change in the third weight. ,Right now: Set the current weight of the target rule. Change in the third weight Add them together to obtain the initial update weights of the target rule. ,Right now: .

[0151] Step S37A: Determine the maximum value between the preset lower weight threshold and the reference weight value as the weight of the updated target rule, wherein the reference weight value is the minimum value between the upper weight threshold and the initial updated weight.

[0152] Obtain the initial update weights of the target rule. Subsequently, in this embodiment of the application, a preset lower threshold weight is applied. Compared with reference weight value The maximum value in the result is determined as the weight of the updated target rule. Among them, the reference weight value Weight upper limit threshold Compared with the initial update weight The minimum value in the formula. To obtain the weights of the final updated target rule. ,in, The function is a maximum value function, used to find the maximum value. It is a minimum value function, used to find the minimum value.

[0153] In summary, this application's embodiments capture reference anomalies based on detection rules in the target project's rule base, extract anomaly snapshot information from the reference anomaly's anomaly log, and obtain target information associated with the anomaly snapshot information. Then, a large language model is invoked to perform anomaly diagnosis based on the anomaly snapshot information and target information, yielding the anomaly diagnosis result for the reference anomaly. Based on the anomaly diagnosis result, defect work orders and regression test cases are generated, enabling developers to develop corresponding code to fix the reference anomaly. The weights of the target rules are updated based on the feedback information from the reference anomaly, and regression test cases are automatically executed to determine the status of the reference anomaly repair. The entire anomaly handling process does not require switching or using different tools, achieving automated and intelligent anomaly handling, improving anomaly handling efficiency, and reducing or avoiding errors in anomaly handling.

[0154] This application provides a computer-readable storage medium storing processor-executable computer program instructions. When executed by a processor, the computer program instructions cause the processor to perform the software exception handling method provided in this application, or to perform the steps in any possible implementation of the software exception handling method provided in this application.

[0155] Those skilled in the art will understand that the embodiments provided in this application are merely illustrative. The order in which the steps in the methods of the embodiments are written does not imply a strict execution order and does not constitute any limitation on the implementation process. The order can be adjusted, merged, and deleted according to actual needs. Modules or sub-modules, units or sub-units in the apparatus or system of the embodiments can be merged, divided, and deleted according to actual needs. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. For another example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed.

[0156] Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, and of course, it can also be implemented using hardware. Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. It should be understood that the storage medium can be flash memory, hard disk, optical disk, register, magnetic surface memory, removable disk, CD-ROM, random access memory (RAM), read-only memory (ROM), electrically programmable ROM, and electrically erasable programmable ROM, etc.

[0157] It should be noted that the above embodiments are for illustrating the technical concept and features of this application, and are intended to enable those skilled in the art to understand the content of this application and implement it accordingly. They should not be construed as limiting the scope of protection of this application. Those skilled in the art can understand that all or part of the processes of the above embodiments can be implemented, modified according to the technical solutions described in the embodiments of this application, or equivalent substitutions can be made to some of the technical features. It is understood that these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and should be considered as equivalent changes and modifications made based on the embodiments of this application, all of which should fall within the scope of the claims of this application.

Claims

1. A software exception handling method, characterized in that, include: In response to the creation of a target project, a project rule base is configured for the target project. The project rule base includes at least one first detection rule inherited from a public rule base and at least one second detection rule pre-set based on the target project. In response to the first detection rule and the second detection rule capturing a reference exception in the application, obtain the exception log corresponding to the reference exception; Based on the exception log, obtain exception snapshot information corresponding to the reference exception. The exception snapshot information includes the exception stack, the Uniform Resource Locator of the error interface, and the unique identifier of the user request. An anomaly diagnosis operation is performed by calling a preset large language model based on the anomaly snapshot information and the target information associated with the anomaly snapshot information to obtain the anomaly diagnosis result of the reference anomaly. The target information represents the information associated with the reference anomaly in the target project. Based on the anomaly diagnosis results, defect work orders and regression test cases are generated. In response to the application receiving the target code, the regression test case is executed, wherein the target code is code developed based on the defect work order to fix the reference anomaly; In response to user input feedback information about the reference anomaly, the weight of the target rule is updated based on the feedback information. The feedback information is used to characterize the accuracy of capturing the reference anomaly. The target rule is at least one of the first detection rule and at least one of the second detection rules that matches the reference anomaly. If the regression test case is executed successfully and the weight of the target rule is updated, the reference anomaly repair is considered complete.

2. The software exception handling method according to claim 1, characterized in that, The invocation of a preset large language model performs anomaly diagnosis based on the anomaly snapshot information and target information associated with the anomaly snapshot information, to obtain the anomaly diagnosis result of the reference anomaly, including: Based on the abnormal snapshot information, the target information is obtained, which includes the service call log of the user request, the call information of the erroneous interface, the context code data corresponding to the reference exception, the requirement content, the table structure information, and the code submission data. The large language model is invoked to perform an anomaly diagnosis operation based on the anomaly snapshot information and the target information, and the anomaly diagnosis result is obtained.

3. The software exception handling method according to claim 2, characterized in that, The step of obtaining the target information based on the abnormal snapshot information includes: Based on the unique identifier, obtain the service call log of the user request; Based on the Uniform Resource Locator (URL) of the error interface, obtain the call information of the error interface; Based on the error code in the exception stack, obtain the context code associated with the error code, the metadata of the error code, and the commit record information as the context code data; Extract the requirement number from the submission record information and obtain the requirement content associated with the requirement number; Based on the metadata of the error code, obtain the table structure information; Based on the requirement number, obtain the code submission data corresponding to the requirement number.

4. The software exception handling method according to claim 2, characterized in that, The step of calling the large language model to perform an anomaly diagnosis operation based on the anomaly snapshot information and the target information to obtain the anomaly diagnosis result includes: Construct anomaly diagnosis prompts, which include a first prompt about defining the model role as an anomaly diagnosis expert and a second prompt about the requirements for diagnostic analysis. The abnormal diagnostic prompts, the abnormal snapshot information, and the target information are input into the large language model, so that the large language model can analyze and diagnose the abnormal snapshot information and the target information based on the abnormal diagnostic prompts to obtain the abnormal diagnostic results.

5. The software exception handling method according to any one of claims 1-4, characterized in that, The anomaly diagnosis results include root cause analysis, scope of impact, remediation recommendations, and recommended responsible parties. The defect work order includes the root cause analysis, scope of impact, remediation recommendations, remediator, project, and affected version. Generating a defect work order based on the anomaly diagnosis results includes: Create an initial work order, which includes a first field about the person performing the repair, a second field about the project they belong to, a third field about the affected version, a fourth field about the root cause analysis, a fifth field about the scope of the impact, and a sixth field about the repair recommendations. Fill the first field with the recommended person in charge as the person responsible for the repair; Fill the second field with the project name corresponding to the target rule as the project to which it belongs; The preset default value is filled into the third field as the affected version; The root cause analysis, the scope of impact, and the repair suggestions are filled into the fourth, fifth, and sixth fields, respectively, to obtain the defect work order.

6. The software exception handling method according to claim 1, characterized in that, The generation of regression test cases based on the anomaly diagnosis results includes: Obtain reference information, wherein the reference information includes the call information of the error interface, the context code data corresponding to the reference exception, the requirement content, the table structure information, and the code submission data; The large language model is invoked to perform a test case generation operation based on the reference information, the anomaly diagnosis results, and the anomaly snapshot information to obtain the regression test cases.

7. The software exception handling method according to claim 6, characterized in that, The step of calling the large language model to perform a test case generation operation based on the reference information, the anomaly diagnosis results, and the anomaly snapshot information to obtain the regression test cases includes: Construct test case generation prompts, which include a third prompt about defining the model role as a test case generation expert and a fourth prompt about the requirements for test case generation; The test case generation prompts, the reference information, the anomaly diagnosis results, and the anomaly snapshot information are input into the large language model, so that the large language model performs test case analysis based on the test case generation prompts, the reference information, the anomaly diagnosis results, and the anomaly snapshot information to obtain the regression test cases.

8. The software exception handling method according to any one of claims 1-4, characterized in that, After obtaining the exception log corresponding to the reference exception, the method further includes: Obtain error logs generated within a predetermined period, wherein the error logs are logs with an error level in the exception logs; Parse the error log and extract the log template corresponding to the error log; Cluster all the log templates to obtain the log clustering results; In response to the log clustering result not being covered by the candidate rule and being a dense and regular log cluster, a new detection rule is generated based on the log clustering result. The candidate rule is any one of at least the first detection rule and at least the second detection rule. The new detection rule is disabled and has a standard weight value. The new detection rule is added to the project rule library as a second detection rule.

9. The software exception handling method according to any one of claims 1-4, characterized in that, The updating of the weights of the target rule based on the feedback information includes: In response to the feedback information being positive feedback, the current weight of the target rule is added to the first weight change value to obtain the initial updated weight of the target rule. The positive feedback information is used to characterize the existence of the reference anomaly, and the first weight change value is the product of a preset learning rate and a weight difference, where the weight difference is the difference between a preset weight upper limit threshold and the current weight; or... In response to the feedback information being weak negative feedback, the current weight of the target rule is added to the second weight change value to obtain the initial updated weight of the target rule. The weak negative feedback information is used to characterize that the reference anomaly is negligible. The second weight change value is the product of the reference ratio and the current weight, and the reference ratio is the ratio of the negative of the preset learning rate to a first preset value; or... In response to the feedback information being strong negative feedback information, the current weight of the target rule is added to the third weight change value to obtain the initial updated weight of the target rule. The weak negative feedback information is used to characterize that the reference anomaly does not exist. The third weight change value is the product of the negative of the preset learning rate and the current weight. The maximum value between the preset lower weight threshold and the reference weight value is determined as the weight of the updated target rule, wherein the reference weight value is the minimum value between the upper weight threshold and the initial updated weight.

10. An exception handling system, characterized in that, The system includes a processor and a memory, the processor being communicatively connected to the memory, the memory storing computer program instructions executable by the processor, and the computer program instructions, when executed by the processor, causing the exception handling system to perform the software exception handling method as described in any one of claims 1-9.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores processor-executable computer program instructions, which, when executed by the processor, cause the processor to perform the software exception handling method as described in any one of claims 1-9.

Images