Automated batch case failure resolution method, device, storage medium, and product

Abstract

The application discloses an automatic batch case failure solving method and device, a storage medium and a product, relates to the technical field of testing, and comprises the following steps: acquiring the execution batch with the highest success rate and the associated failure case details in the product batch record, accurately positioning the failure case that needs to be paid attention to without manual intervention, and eliminating the hysteresis of the manual monitoring link and the labor cost; according to the failure case details, performing root cause analysis on the related failure cases through a preset large model to obtain a root cause analysis result; the preset large model can extract key information from the failure case details and output the root cause analysis result, and manual log checking is not needed, so that the time for locating the cause is greatly shortened; after the root cause analysis result is obtained, a corresponding solution is directly output based on the root cause analysis result, and manual decision-making based on experience is not needed. Therefore, the efficiency of solving the automatic batch case failure is improved as a whole.

Description

Technical Field

[0001] This application relates to the field of testing technology, and in particular to a solution, device, storage medium and product for automated batch processing failures. Background Technology

[0002] Automated batch processing is an important safeguard for critical business links in business systems, and its operational status and efficiency in handling anomalies directly affect the stability of business system services.

[0003] Currently, monitoring the results of automated batch processing usually requires manual monitoring at regular intervals. The discovery of abnormal states is often delayed by several hours, and the fault handling process is usually a passive response. When a batch processing case fails, the cause needs to be manually traced back a large amount of log data, resulting in high human resource consumption and time costs. At the same time, there is a lack of effective accumulation and reuse mechanisms for historical fault causes and solutions. The same or similar failure cases repeatedly rely on manual repair, making it difficult to improve the overall problem-solving efficiency. Summary of the Invention

[0004] The main purpose of this application is to provide a solution, device, storage medium and product for automated batch processing failure resolution, aiming to solve the technical problem of low efficiency in resolving automated batch processing failures.

[0005] To achieve the above objectives, this application proposes a solution for automated batch processing failures, which includes: Obtain the execution batch with the highest success rate in the product batch running records, as well as the details of the failure cases associated with the execution batch with the highest success rate; Based on the details of the failure cases, root cause analysis is performed on the relevant failure cases using a pre-set large model to obtain the root cause analysis results; Based on the root cause analysis results, a solution is determined.

[0006] In one embodiment, the step of performing root cause analysis on relevant failure cases using a preset large model based on the failure case details to obtain the root cause analysis results includes: Extract the log storage path from the failure case details, and read the complete execution log from the corresponding log storage system according to the log storage path; The complete execution log is assembled with the context information in the failure case details into a structured root cause analysis request; The root cause analysis request is submitted to the large model service interface so that the preset large model can perform root cause analysis based on the complete execution log and the context information in the failure case details to obtain the root cause analysis results. Receive the root cause analysis results returned by the large model service interface, the root cause analysis results including failure type and root cause description.

[0007] In one embodiment, the failure type includes at least one of execution environment problems, data problems, test script problems, and business logic defects, and the step of determining a solution based on the root cause analysis results includes: If the failure type is an execution environment problem, the solution is to wait for the execution set to be re-executed in the next execution cycle, and the corresponding failure case is marked as waiting to be re-run. If the failure type is a data problem or a test script problem, a solution will be matched according to the preset knowledge base; If the failure type is a business logic defect, the corresponding failure case will be marked as requiring manual confirmation, and the solution will be determined as pending manual confirmation.

[0008] In one embodiment, the step of matching a solution based on a preset knowledge base includes: Retrieves maintained solution records from the preset knowledge base. Each solution record contains at least one of the following: a problem description field, a solution type field, and a parameter call template corresponding to the repair method. The solution type includes at least one of the following: interface class, data canvas class, and Q&A class. Based on the preset priorities of different types of solutions, semantic similarity matching is performed between the root cause description and the problem description fields. Based on the matched solution type, a solution is determined from the solution record. The preset priorities are, in descending order, interface type, data canvas type, and Q&A type.

[0009] In one embodiment, the step of determining a solution from the solution record based on the matched solution type includes: If the matched solution type is an interface class or a data canvas class, the input parameters of the repair method are parsed from the root cause description, and the repair request is assembled according to the repair method call parameter template. The repair request is used to call the corresponding internal interface or execute the data canvas command. If the call is successful, the corresponding failure case is marked as repaired, and the execution set to which it belongs is triggered to be re-executed. If the call fails or the matched solution type is Q&A type, the matched Q&A type solution will be written into the recommended solution field of the corresponding record in the failure case details for user reference.

[0010] In one embodiment, after the step of performing semantic similarity matching between the root cause description and the problem description field according to the preset priority of different types of solutions, the method further includes: If no solution is found, the root cause description is written into the failure case details, and the corresponding recommended solution field in the preset knowledge base is left blank. The front-end page prompts the user to provide a reason, and in response to the user's supplementary solution, the user's supplementary solution is recorded in the recommended solution corresponding to the preset knowledge base.

[0011] In one embodiment, after the step of determining the solution based on the root cause analysis results, the method further includes: For unresolved failure cases and failure cases with user-supplied recommended solutions, a summary file containing failure case identifiers, log links, root cause descriptions, and recommended solutions is generated. The summary file is then pushed to the corresponding responsible person via an instant messaging interface for case debugging. The front-end page displays a failed case management interface, allowing users to query cases, debug cases, or update case analysis status; In response to the case analysis status and actual solution filled in by the user, the actual solution and the corresponding failure case are synchronously written into the preset knowledge base; In response to the problem description entered by the user in the test handling method management module of the failure case management interface, the problem description is semantically matched with the problem description field in the preset knowledge base, and the matched solution is returned.

[0012] In addition, to achieve the above objectives, this application also proposes an automated batch processing failure resolution device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the automated batch processing failure resolution method described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the automated batch processing failure solution described above.

[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps for resolving automated batch processing failures as described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: This application obtains the highest success rate execution batches and their associated failure case details from product batch running records. This allows for accurate identification of failure cases requiring attention without manual intervention, eliminating the lag and labor costs of manual monitoring. Based on the failure case details, a pre-set large-scale model is used to perform root cause analysis on the relevant failure cases, obtaining root cause analysis results. This model can extract key information from the failure case details and output root cause analysis results, eliminating the need for manual log-by-log checking and significantly shortening the time for locating the cause. After obtaining the root cause analysis results, corresponding solutions are directly output based on these results, eliminating the need for manual decision-making based on experience. This comprehensively improves the efficiency of automated batch running failure resolution. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating the solution to the failure of the automated batch processing case in this application. Figure 2 The system architecture diagram provided in Implementation Example 1 of the solution to the failure of automated batch processing in this application; Figure 3 The logical architecture diagram provided in Implementation Example 1 of the solution for the failure of automated batch processing in this application; Figure 4 This is a schematic diagram of the hardware operating environment involved in the solution to the failure of the automated batch processing case in the embodiments of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, or an automated batch processing failure resolution device, etc. The following description uses an automated batch processing failure resolution device as an example to illustrate this embodiment and the subsequent embodiments.

[0023] Based on this, the embodiments of this application provide a solution to the failure of automated batch processing, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the solution to the problem of failed automated batch processing in this application.

[0024] In this embodiment, the solution to the automated batch processing failure includes steps S10~S30: Step S10: Obtain the execution batch with the highest success rate in the product batch running records, and the details of failure cases associated with the execution batch with the highest success rate; Step S20: Based on the details of the failure cases, perform root cause analysis on the relevant failure cases using a preset large model to obtain the root cause analysis results; Step S30: Determine a solution based on the root cause analysis results.

[0025] It should be noted that the solutions to the automated batch processing failures described above can be applied to automated batch processing systems; the automated batch processing system includes a channel layer, a capability layer, and a data layer.

[0026] The channel layer provides user interaction entry points, including the tool platform front-end page, instant messaging robot, and automatic task management module; the capability layer provides batch processing result monitoring services, failure case acquisition services, failure reason extraction services, case repair services, solution recommendation services, and knowledge summary services; the data layer stores a preset knowledge base, failure case information, and product configuration information; the case self-healing solution knowledge base can be a Retrieval-Augmented Generation (RAG) generated knowledge base; the failure case information can be error data generated during batch processing by the platform (Test Data Management, TDM) responsible for managing underlying technical data and public technical components; and the product configuration information can be the configuration information of the TDM product.

[0027] The automated batch processing system can pre-store product configuration information in the TDM database of the data layer. This configuration information includes the execution set identifier corresponding to each product, the address of the business key case execution set batch processing result query interface, and the authentication credentials required for access.

[0028] The failure case retrieval service in the capability layer can read the aforementioned product configuration information from the data layer. Based on the read product configuration information, the failure case retrieval service can call the business key case execution set batch result query interface, send a query request to this interface, retrieve the batch record with the highest success rate among the batch records of each product in the current week, and determine the execution batch corresponding to that batch record.

[0029] Among them, the batch run record is the execution log generated by the automated batch run system each time a batch task is executed, including data such as execution time, execution result (success / failure), and success rate statistics. An execution batch is a batch task execution entity initiated by the automated batch run system for a specific product at a specific time. Each execution batch contains multiple batch run cases and has a unique batch identifier.

[0030] After identifying the execution batch with the highest success rate, the failure case retrieval service can further call relevant interfaces to obtain details of all failure cases associated with that execution batch. The retrieved failure case details include, but are not limited to, the execution set case name, links to configuration graphs or dependency graphs related to the failed batch task, failure log links, and case error information.

[0031] Furthermore, the failure case acquisition service can write the above failure case details into the TDM database of the data layer and store them in the corresponding failure case information table.

[0032] This embodiment automatically obtains the execution batches with the highest success rate and their failure case details. The system can accurately locate the target batches that need attention (i.e., failure cases that still occur in the most stable batches) in a massive batch execution record, thereby avoiding the tedious process of manually going through all batch execution records one by one and filtering failure cases based on experience.

[0033] Furthermore, referring to Figure 3 Based on the details of the failure cases, a pre-set large-scale model is used to perform root cause analysis on the relevant failure cases, yielding root cause analysis results. The pre-set large-scale model is a pre-trained, large-scale deep learning model with natural language understanding and generation capabilities. It can receive input data and output analysis conclusions based on its internal parameters and reasoning abilities. Utilizing the semantic understanding and reasoning capabilities of the pre-set large-scale model enables automated and intelligent analysis of failure causes, completely replacing the tedious process of manually reviewing massive amounts of logs and relying on experience to determine root causes.

[0034] The pre-built large model can quickly extract key features from unstructured log text and error messages and perform global inference to output structured root cause analysis results. This significantly shortens the time from discovering a failure to locating the cause, eliminating the uncertainty and efficiency bottlenecks of manual investigation.

[0035] Specifically, log fragments can be concatenated with structured fields such as environment identifier, product name, and execution time from the failure case details into a text block. This text block is used as part of the prompt word, along with a clear analysis instruction template, such as: Please determine the root cause type of the following failure cases and output: type=[a], description=specific reason, that is, to obtain the root cause analysis result.

[0036] Furthermore, the root cause analysis results can be used as input. Based on the failure type and root cause description in the results, a solution that is most suitable for the current failure case can be matched and determined from a set of preset handling strategies. The solution refers to the specific response strategy or operation instructions that can be used to handle the current failure case based on the root cause analysis results. The solution can be an automatically executed operation instruction, a handling suggestion for manual reference, or status information marked as requiring further processing.

[0037] A rule-based decision table can be pre-configured locally, using the failure type from the root cause analysis results as the index key, with each type corresponding to a preset solution template. The decision table can be queried using the field value of the failure type; if the query finds a match, solution text can be generated based on the corresponding template.

[0038] In one feasible implementation, the step of performing root cause analysis on the relevant failure cases based on the failure case details using a preset large model to obtain the root cause analysis results can be implemented as follows: Extract the log storage path from the failure case details, and read the complete execution log from the corresponding log storage system according to the log storage path; assemble the complete execution log and the context information in the failure case details into a structured root cause analysis request; submit the root cause analysis request to the large model service interface, so that the preset large model can perform root cause analysis based on the complete execution log and the context information in the failure case details to obtain the root cause analysis result; receive the root cause analysis result returned by the large model service interface, the root cause analysis result including failure type and root cause description.

[0039] It should be noted that the log storage path is the location identifier of the log files generated during the execution of the failed case in the log storage system. This can be a file system path, an object storage key-value pair, or a Uniform Resource Locator (URL). The complete execution log is the raw log data recorded throughout the entire execution process of the failed case, from start to finish, including timestamps, log levels, code locations, execution steps, variable values, error stack traces, and other information. Context information, in addition to the log content, includes environment-related information in the failed case details used to aid analysis. This information includes structured fields such as product identifier, execution set name, case name, environment parameters, request messages, and comparisons between expected and actual results.

[0040] The system extracts the log storage path from the failure case details and reads the complete execution log from the log storage system based on that path. It then assembles the read execution log with the context information (including test steps, input data, actual results, expected results, error codes, error messages, environment information, product and business modules, etc.) from the failure case details into a structured root cause analysis request according to a predefined format. This request is then submitted to a predefined large model service interface, and the root cause analysis results returned by the large model service interface are received.

[0041] The large model service interface is a pre-defined application programming interface (API) provided by the large model. It receives structured request data, calls the large model to perform inference, and returns the inference results. The root cause analysis results can include failure type and root cause description. Failure type is a category label classifying the root cause of failure cases, including execution environment issues, data issues, test script issues, business logic defects, etc. Root cause description refers to a detailed textual explanation of the failure cause, describing the direct cause or key evidence leading to the failure, such as "Insufficient account balance, unable to complete deduction" or "XX variable parsing failed, original data canvas was XXX".

[0042] Specifically, when performing root cause analysis, the pre-defined large model can perform a global analysis of the failed nodes in the logs. For example, if the log shows that "JSON specified field validation failed", the pre-defined large model will extract the error code and error information, and judge based on the error content: if the error information is a system exception, it will be classified as an environmental problem; if the error information is insufficient account balance, it will be classified as a data problem; if the returned parameters are abnormal, it will trace back to the script node that caused the parameter parsing failure and classify it as a test script problem.

[0043] This embodiment uses a pre-set large model to perform global analysis and root cause judgment on logs, and can directly output structured analysis results, replacing the inefficient process of manually reading logs line by line and classifying them based on experience.

[0044] Specifically, when assembling a root cause analysis request, a prompt word template containing the following can be constructed: System role setting: "You are an expert in root cause analysis of automated batch processing failure cases." Input data segment: List the complete execution log in a structured format (only the key parts are kept, and if the log is too long, 200 lines before and after the error are truncated), test steps, input data, actual results, expected results, error codes, error messages, and environment information.

[0045] Analysis Instruction: "Based on the above information, determine the root cause of this failure. Output format: Failure Type = [Environmental Issue / Data Issue / Test Script Issue / Business Logic Defect], Root Cause Description = [Detailed Root Cause Description]. If the type is a test script issue, please trace back to the earliest script node that caused the failure; if the type is a data issue, please indicate the specific missing or abnormal data items." Encapsulate the above prompts into a JSON request body and send it to the large model service interface via an HTTPS POST request. After the interface returns, parse the failure type and root cause description fields in the response. If the returned root cause description field contains information such as "parameter error, XX variable parsing failed, original data canvas is: XXX", the original data canvas content can be extracted and stored in a separate field for subsequent knowledge base matching.

[0046] Furthermore, the failure type and root cause description obtained from the parsing can be written into the corresponding column in the TDM failure case information table, while retaining the original complete log path for manual review.

[0047] If the large model service interface call fails or returns an abnormal format, it can fall back to a simple rule-based classification, determine the failure type according to the error code dictionary mapping (e.g., error code 500 maps to an environmental problem, and error code 400 maps to a data problem), and use the original error information as the root cause description; record this fallback event for subsequent monitoring of the availability of the model service.

[0048] In one feasible implementation, the failure types include at least one of execution environment problems, data problems, test script problems, and business logic defects. Execution environment problems are failures caused by unavailability, communication anomalies, or performance degradation of environmental factors such as hardware resources, network connections, operating systems, middleware services (e.g., databases, message queues), or third-party interfaces relied upon by the automated batch execution, and are unrelated to the logic or data of the test case itself. Data problems are failures caused by missing test data, incorrect data formats, invalid data associations, expired data, or data that does not conform to business rules (e.g., insufficient account balance). Test script problems are failures caused by errors in the code logic of the automated test case itself, parameter parsing failures, invalid location expressions, incorrect assertion conditions, or script compatibility issues. Business logic defects are failures caused by errors in the business processing logic of the system under test, missing functions, or discrepancies between expected and actual behavior. These defects cannot be resolved through environment recovery or data repair and typically require developers to modify the code.

[0049] In one feasible implementation, refer to Figure 3 The method for determining the solution based on the root cause analysis results can be: If the failure type is an execution environment problem, the solution is to wait for the execution set to be re-executed in the next execution cycle, and the corresponding failure case is marked as waiting to be re-run; if the failure type is a data problem or a test script problem, a solution is matched according to a preset knowledge base; if the failure type is a business logic defect, the corresponding failure case is marked as requiring manual confirmation, and the solution is determined to be pending manual confirmation.

[0050] Specifically, if the failure type is an execution environment issue, the system determines the solution as follows: no repair attempts are made for the current failed case; instead, the system waits for the next execution cycle to automatically re-execute the execution set to which the failed case belongs, while simultaneously marking the case's status in the database as "awaiting rerun." In the automated batch processing system, multiple batch processing cases with business relevance or execution order dependencies are organized according to certain rules to form an independently schedulable and executable task set. Each execution set has a unique identifier, and the system triggers batch tasks, tracks execution status, and summarizes results on a set-by-set basis; therefore, a failed case belongs to a specific execution set.

[0051] If the failure type is a data issue or a test script issue, the system triggers a preset knowledge base matching process, retrieving and matching a suitable solution from the knowledge base based on the root cause description. The preset knowledge base is a pre-built and continuously maintained structured database that stores information such as problem descriptions, solution types, and repair method call parameter templates for historical failure cases.

[0052] If the failure type is a business logic defect, it is determined that the problem cannot be solved by automation. The status of the failure case can be marked as requiring manual confirmation, and the solution can be determined as pending manual confirmation, that is, prompting the user to intervene.

[0053] In this embodiment, a pre-set large model is used to automatically collect and analyze complete execution logs and context information, outputting structured failure types and root cause descriptions, replacing the inefficient mode of manually tracing massive amounts of logs. Differentiated decisions are made based on failure type: environmental issues are automatically marked for reruns, data / script issues trigger knowledge base matching and recommended solutions, and business defects are transferred to manual confirmation. This avoids ineffective repairs and allows for the reuse of historical experience. This solves the efficiency bottlenecks of lagging manual monitoring, time-consuming item-by-item investigation, and repeated reliance on manual repairs, significantly shortening automated debugging time and effectively improving the overall efficiency of automated batch processing.

[0054] Based on the first embodiment of this application, in the second embodiment of this application, the same or similar content as the above embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, refer to... Figure 3The implementation method of matching the solution based on the preset knowledge base can be: The system reads maintained solution records from a preset knowledge base. Each solution record contains at least one of the following: a problem description field, a solution type field, and a parameter call template corresponding to the repair method. The solution type includes at least one of the following: interface type, data canvas type, and Q&A type. Based on the preset priority of different solution types, the root cause description is semantically matched with the problem description field. Based on the matched solution type, a solution is determined from the solution records. The preset priority, from high to low, is interface type, data canvas type, and Q&A type.

[0055] It should be noted that a solution record refers to each structured data entry stored in the knowledge base. A solution record includes at least one of the following: a problem description field, a solution type field, and a parameter call template corresponding to the repair method.

[0056] The problem description field records the characteristic text of the problem that the solution can handle; the solution type field identifies whether the solution belongs to the interface class, data canvas class, or Q&A class; and the parameter call template records the method name, input parameter list, and calling specification required to perform the repair.

[0057] Interface-based solutions address specific problems by calling internal or external interfaces (such as recharge interfaces); data canvas-based solutions address problems by executing data canvas commands (such as updating test data); and Q&A-based solutions provide prompts or suggestions instead of automatic fixes that cannot be achieved through the above two types.

[0058] This embodiment performs semantic similarity matching between the root cause description and the question description field of each record in the knowledge base, based on a preset priority (from high to low: interface type, data canvas type, and Q&A type). Based on the successfully matched solution type, a specific solution is determined from the corresponding solution record.

[0059] Specifically, a vector-based semantic matching method can be adopted: a lightweight text embedding model is used in advance to convert the problem description fields in all solution records into feature vectors of fixed dimensions and store them in a cache; during matching, the current root cause description is also converted into a feature vector of the same dimension, and then the cosine similarity between the vector and the problem description vector under each priority category is calculated in turn.

[0060] In the specific matching process, matching can begin with interface-type solutions: calculate the similarity between the root cause description vector and all interface-type question description vectors, and take the highest similarity value. If this value is greater than a preset threshold (e.g., 0.75), the match is successful, and the interface-type solution is selected. If the highest similarity in the interface-type solution is lower than the threshold, the process can proceed to the data canvas-type solution for the same similarity calculation. If the highest similarity in the data canvas-type solution is greater than the threshold, the match is successful. If no match is found in the data canvas-type solution, the process can proceed to the Q&A-type solution. If the highest similarity in the Q&A-type solution is greater than the threshold, the Q&A-type solution is selected; if it is still lower than the threshold, no solution is found.

[0061] During the matching process, the type and similarity score of each candidate solution can be recorded simultaneously, and the matching results (including the identifier of the matched solution record, the matching type, and the similarity score) can be written to a log file for subsequent analysis of matching accuracy. If the match is successful, the parameter call template corresponding to the solution type field and the repair method can be extracted from the solution record and passed to the subsequent automatic repair or solution recommendation module.

[0062] In one feasible implementation, determining the solution from the solution record based on the matched solution type can specifically be: If the matched solution type is an interface type or a data canvas type, the input parameters of the repair method are parsed from the root cause description, and the repair request is assembled according to the repair method call parameter template. The repair request is used to call the corresponding internal interface or execute the data canvas command. If the call is successful, the corresponding failure case is marked as repaired, and the execution set to which it belongs is re-executed. If the call fails or the matched solution type is a Q&A type, the matched Q&A type solution is written into the recommended solution field of the corresponding record in the failure case details for user reference.

[0063] Specifically, if the matched solution type is an interface or a data canvas, the required input parameters for the repair method can be parsed from the root cause description, and the repair request can be assembled according to the repair method call parameter template recorded in the knowledge base. This repair request is used to call the corresponding internal interface or execute the data canvas command. If the repair call is successful, the corresponding failed case can be marked as repaired, and the scheduling system can be triggered to re-execute the execution set to which the case belongs; if the repair call fails, the case is downgraded to the Q&A processing method.

[0064] A repair request is a structured instruction generated from a repair method call parameter template stored in the knowledge base, used to perform specific repair operations. For interface-based solutions, the repair request includes the interface address, request method, request headers, and request body (including input parameters); for data canvas-based solutions, the repair request includes the canvas command name, parameter list, and execution environment information. Executing a data canvas command means that the system executes preset batch processing instructions (such as updating TDM test data) in the specified data operation environment according to the data canvas command template in the repair request to repair problems caused by data corruption.

[0065] Specifically, if the type is an interface class or a data canvas class, the automatic repair sub-process can be initiated: Step 1: Input Parameter Parsing and Assembly. Using regular expressions or a JSON path extractor, extract the required parameters from the request message and root cause description of the failed case. For example, for the insufficient balance issue, the system extracts the account number from the "Account Information" node of the request message, extracts the environment identifier (such as "dev", "test") from the environment variables configured in the execution set, and sets the amount parameter according to the default value in the daily user behavior configuration file (such as a default recharge of 10,000 yuan). These parameters are then combined with parameter call templates in the knowledge base (such as recharge(env, account, amount)) to generate an executable method call statement or HTTP request body.

[0066] Step 2: Perform the repair operation. For API-based solutions, a POST request can be initiated via a REST client. The target address is obtained from the solution record in the knowledge base, and the request body is the JSON object generated in Step 1. Set the timeout to 10 seconds, with a maximum of 2 retries. For data canvas-based solutions, connect to the data canvas execution engine, submit canvas commands and parameters, and wait for the execution result. During execution, call logs can be recorded in real time, including request time, parameter content, response status, etc.

[0067] Step 3: Result Processing. The return value of the call can be checked: if the return status code is 200 and the business return code indicates success (e.g., code=0), then the repair is considered successful. The case status of the corresponding record in the failed case information table can be updated to "repaired," and the REST interface of the scheduling system can be called, passing in the unique identifier of the execution set to request that the execution set be re-executed immediately or in the next idle period. If a failure is returned (e.g., interface timeout, error code), the system determines that the repair has failed, changes the solution type field of the case from interface class or data canvas class to Q&A class, records the reason for failure (e.g., recharge interface call timeout), and transfers it to the Q&A class processing flow.

[0068] Specifically, if the matched solution type is a Q&A type, or a failure to repair an interface / data canvas type and subsequent degradation, automatic repair will not be performed. Instead, the text of the matched Q&A type solution will be written into the recommended solution field of the corresponding record in the failure case details for the user to refer to during subsequent debugging.

[0069] For example, the problem description and suggested action fields of the corresponding record in the knowledge base can be directly read and concatenated into a readable recommended solution text, such as: "It is recommended to manually check the device status, turn on the peripherals, and rerun the batch process." Then, an SQL update statement is executed to write this text into the recommended_solution column of the TDM failure case information table. At the same time, the processing status field of this case is marked as awaiting manual reference so that it can be highlighted on the front-end page.

[0070] It also supports marking cases that fail to be automatically repaired, allowing for subsequent manual analysis to optimize the knowledge base. For example, if the same interface class solution fails more than 3 times consecutively, the system automatically generates an alarm, prompting the knowledge base administrator to check the interface availability or parameter template of the solution.

[0071] In this embodiment, when automatic repair is performed based on the matched interface class or data canvas class solution, and the execution set still fails to execute again, a new root cause analysis result for the second failure is obtained. If the new root cause analysis result is the same as the original root cause analysis result, the confidence score of the solution in the preset knowledge base is reduced by a preset step size. When the confidence score is lower than the preset failure threshold, the priority of the solution is adjusted to be lower than that of the Q&A class, and the preset large model is triggered to analyze the failure cause of the solution and generate optimization suggestion text to be pushed to the administrator interface.

[0072] By recording the results of each rerun after a repair, the effectiveness of the solution is quantitatively evaluated (confidence score). When a solution repeatedly fails, its confidence score is proactively reduced, and its priority is automatically lowered to below the Q&A category. This avoids blindly adopting the failed solution when encountering the same problem again in the future, thereby reducing the waste of system resources and delays in problem resolution due to ineffective repair operations.

[0073] In this embodiment, the method for obtaining the new root cause analysis result of the recurrence of failure may be as follows: Retrieve at least one reference solution from the preset knowledge base that has the same problem description field as the solution and a confidence score higher than the second threshold; extract the first repair method call parameter template of the solution and the second repair method call parameter template of the reference solution, perform a structured difference comparison between the two, and generate a difference feature list, which includes at least one of parameter value differences, call sequence differences, and precondition differences; jointly submit the difference feature list, the failure log corresponding to the solution, and the original root cause description to the preset large model, along with an analysis instruction, which requires the preset large model to locate the specific difference cause of the failure based on the difference feature list and output a correction suggestion for the first repair method call parameter template; receive the correction suggestion returned by the preset large model and push the correction suggestion as the optimization suggestion text to the administrator interface.

[0074] This embodiment retrieves high-confidence successful solutions from the knowledge base as references. By comparing the differences in repair method invocation parameters between failed and successful solutions, the focus of analysis is precisely shifted from why the solution failed to where it differs from the successful solution. This comparative analysis method effectively eliminates irrelevant factors such as environmental noise, significantly improving the relevance and accuracy of the large model's output results.

[0075] In this embodiment, historical failure case data for each product within N consecutive preset time periods can also be obtained. The failure frequency within each time period is statistically analyzed according to the failure type to form a frequency time series sequence for each failure type. The frequency time series sequence is input into a pre-trained time series prediction model to predict the predicted failure frequency of each failure type in the next preset time period. If the predicted failure frequency of a certain failure type exceeds a preset active intervention threshold, an active pre-generation process is triggered: multiple root cause descriptions of the failure type are extracted from historical failure cases, and after deduplication and clustering, the preset large model is called to generate at least one general candidate solution. The general candidate solution is associated with the failure type and stored in the cached knowledge area, and given a matching weight higher than that of the regular knowledge base record. When the failure type is identified in the subsequent real-time matching process, the general candidate solution in the cached knowledge area is returned first.

[0076] This embodiment obtains the time-series sequence of historical failure frequencies and uses a time-series prediction model to predict the frequency of each failure type in the next time period. When the predicted frequency exceeds a threshold, a general candidate solution is generated in advance. This allows the system to prepare solutions before the peak failure period arrives and can be directly invoked when an actual failure occurs, significantly shortening the handling delay and fundamentally changing the failure handling logic.

[0077] In this embodiment, before triggering the proactive pre-generation process, the following can also be done: obtain the repair success rate of the general candidate solutions generated by each proactive pre-generation process in history after they are actually matched and used, and the computing resource cost consumed by each proactive pre-generation; calculate the proactive pre-generation input-output ratio for each failure type based on the repair success rate and the computing resource cost; dynamically adjust the proactive intervention threshold corresponding to the failure type based on the input-output ratio: when the input-output ratio is higher than a first ratio threshold, decrease the proactive intervention threshold; when the input-output ratio is lower than a second ratio threshold, increase the proactive intervention threshold; if the proactive intervention threshold after adjustment is higher than a preset maximum threshold, then close the proactive pre-generation process for that failure type until the prediction failure frequency exceeds the maximum threshold for multiple consecutive time periods, and then reopen it.

[0078] This embodiment introduces a repair success rate (measuring the actual value of the pre-generated solution) and a resource cost calculation (measuring the economic input of the pre-generation), calculates the input-output ratio, and dynamically adjusts the active intervention threshold based on this ratio. This allows resources to be prioritized for high-return failure types, while low-return types are postponed or shut down, achieving intelligent and refined allocation of pre-generated resources.

[0079] In one feasible implementation, after the step of performing semantic similarity matching between the root cause description and the problem description field according to the preset priority of different types of solutions, the following can also be added: If no solution is found, the root cause description is written into the failure case details, and the corresponding recommended solution field in the preset knowledge base is left blank; the user is prompted on the front-end page to supplement the reason, and in response to the solution supplemented by the user, the solution supplemented by the user is recorded in the recommended solution corresponding to the preset knowledge base.

[0080] If no solution is found after semantic similarity matching according to the preset priority, the root cause description of the current failed case can be written into the corresponding record in the failed case details (e.g., the root cause description field), and the corresponding recommended solution field in the preset knowledge base can be left blank to indicate that there is currently no available solution.

[0081] The front-end page can also prompt users to provide additional reasons, guiding them to manually enter the actual cause and solution for the failure. In response to the user's supplementary solutions, the user's input is recorded as a new solution and written into a pre-defined knowledge base, ensuring continuous accumulation of knowledge.

[0082] Specifically, the root cause description can be written into the root cause description field, the recommended solution field can be explicitly set to an empty string or NULL, and the knowledge base matching status field can be marked as unmatched. At the same time, the current timestamp and the reason for the unmatch (e.g., the highest similarity of the interface class is 0.52, which is lower than the threshold of 0.75) can be recorded to facilitate subsequent analysis of the knowledge base's coverage blind spots.

[0083] The system can also send a notification of pending tasks to the currently logged-in tool platform user interface via a real-time push notification mechanism on the front-end page. The notification includes: the identifier of the failed case, the execution set name, the root cause description, and a shortcut button for a supplementary solution. When the user clicks this button, a modal pops up on the front end with two text input areas: the cause of the problem (pre-filled with a root cause description that the user can modify) and the solution (the user must manually fill in the specific processing steps, API call methods, or canvas commands, etc.). A non-empty validation is performed upon user submission; if the solution is empty, the user is prompted to fill it in.

[0084] After a user submits data, the frontend can send the data to the backend's knowledge base management interface via an HTTP POST request. Upon receiving the request, the backend can perform the following operations: The system automatically categorizes user-input solutions: keyword matching is used (e.g., "interface," "call," "API" are classified as interface solutions; "canvas," "command," "execute" are classified as data canvas solutions; the rest are classified as Q&A solutions). Users can also manually select the type when submitting.

[0085] Generate a new solution record, including: a problem description field (taken from the user-provided description of the problem cause or root cause), a solution type field (automatically categorized or user-selected), a repair method call parameter template (recorded if the user provided a specific parameter format, otherwise left blank), creation time, creator, and other information. Insert the new record into the preset knowledge base table and trigger a cache refresh, so that the record takes effect immediately in subsequent matching.

[0086] At the same time, the recommended solution field of the corresponding record in the failed case information table can be updated to the solution supplemented by the user, and the knowledge base matching status field can be updated to the manually supplemented solution that has been entered into the database.

[0087] It also supports batch processing of unmatched cases: administrators can periodically view the list of unmatched cases, supplement solutions for typical problems, and then import them into the knowledge base in batches, thereby improving the efficiency of knowledge base maintenance.

[0088] For cases where the same failure mode occurs multiple times and is not matched each time, the frequency can be automatically counted. When the frequency exceeds a set threshold (such as 5 times), knowledge base optimization suggestions will be proactively sent to the administrator, indicating the possible high-frequency missing solutions.

[0089] In one feasible implementation, after the step of determining the solution based on the root cause analysis results, the following may also be added: For unresolved failed cases and failed cases with user-supplied recommended solutions, a summary file containing failed case identifiers, log links, root cause descriptions, and recommended solutions is generated. An instant messaging interface is invoked to push the summary file to the corresponding responsible person for case debugging. A failed case management interface is displayed on the front-end page, allowing users to query, debug, or update case analysis status. In response to the case analysis status and actual solution entered by the user, the actual solution and corresponding failed case are synchronously written into the preset knowledge base. In response to the problem description entered by the user in the test processing method management module of the failed case management interface, the problem description is semantically matched with the problem description field in the preset knowledge base, and the matched solution is returned.

[0090] Specifically, for failed cases that remain in a failed state after the aforementioned steps and for which recommended solutions have been recorded, a summary file can be automatically generated. This summary file contains key fields such as the failed case identifier, log link, error message, and recommended solution. An instant messaging interface can be used to push this summary file to the relevant responsible person for case debugging. This avoids the need for the responsible person to frequently log in to the system, reducing the possibility of information omissions. Simultaneously, the summary file includes recommended solutions that the responsible person can directly refer to without re-analyzing, thus improving the efficiency of manual debugging.

[0091] A failure case management interface can also be provided on the front-end page. This interface reads data from the failure case information table in real time, allowing users to query, debug, and update the case analysis status. After the user fills in the case analysis status and the actual solution, the system responds to the user's input by synchronously writing the actual solution and the corresponding failure case information into the problem database table, and simultaneously adding it as a new record to the preset knowledge base. This provides a unified entry point for manual intervention and supports batch processing of cases. At the same time, the actual solutions confirmed by the user after debugging are written back into the knowledge base, improving its accuracy and coverage.

[0092] A test handling method management module can also be provided in the failure case management interface. When a user enters a problem description in the module, the system responds by semantically matching the problem description with the problem description field in the preset knowledge base and returning the matched solution to the user. If no record is matched, or if the user believes that the existing solution is not applicable, the user can manually add a solution record. The system responds by inserting the record into the preset knowledge base. Testers can retrieve existing solutions at any time during development and debugging, enabling immediate knowledge reuse. At the same time, the manual addition mechanism allows any tester to become a contributor to the knowledge base, lowering the threshold for knowledge accumulation, enabling the knowledge base to quickly respond to the emergence of new problems, and improving the self-healing capability and solution recommendation capability of automated batch processing.

[0093] In this embodiment, semantic matching with preset priorities is used to accurately identify high-frequency fault scenarios. For executable solutions, repair requests are automatically assembled and API or canvas commands are invoked, achieving fully automated repair with immediate response upon discovery. For unmatched cases, users are guided to supplement solutions and these are added to the knowledge base. Actual solutions confirmed by users during debugging are synchronously written back to the knowledge base, forming a continuous evolution mechanism. Simultaneously, a front-end management interface and a test processing method management module are provided, supporting active retrieval and manual addition, and automatically generating summary files which are pushed to responsible personnel via instant messaging, replacing manual monitoring. This improves the self-healing capability, management efficiency, and knowledge reuse level of automated batch processing.

[0094] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the solution to the failure of automated batch processing cases in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0095] This application provides an automated batch processing failure resolution device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the automated batch processing failure resolution method in Embodiment 1 above.

[0096] The following is for reference. Figure 4The diagram illustrates a structural schematic suitable for implementing an automated batch processing failure resolution device in the embodiments of this application. The automated batch processing failure resolution device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, tablets, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital televisions and desktop computers. Figure 4 The automated batch processing failure resolution device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0097] like Figure 4 As shown, the automated batch processing failure resolution device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the automated batch processing failure resolution device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the automated batch processing failure resolution device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows an automated batch processing failure resolution device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented alternatively.

[0098] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0099] The automated batch processing failure resolution device provided in this application adopts the automated batch processing failure resolution method in the above embodiments, which can solve the technical problem of low efficiency in resolving automated batch processing failures. Compared with the prior art, the beneficial effects of the automated batch processing failure resolution device provided in this application are the same as those of the automated batch processing failure resolution method provided in the above embodiments, and other technical features in this automated batch processing failure resolution device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0100] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0101] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0102] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the automated batch processing failure solution in the above embodiments.

[0103] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0104] The aforementioned computer-readable storage medium may be included in the automated batch processing failure resolution device; or it may exist independently and not be assembled into the automated batch processing failure resolution device.

[0105] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the automated batch processing failure resolution device, cause the automated batch processing failure resolution device to execute the aforementioned automated batch processing failure resolution method.

[0106] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0107] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0108] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0109] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described automated batch processing failure resolution method, thereby solving the technical problem of low efficiency in resolving automated batch processing failures. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the automated batch processing failure resolution method provided in the above embodiments, and will not be repeated here.

[0110] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps described above for resolving automated batch processing failures.

[0111] The computer program product provided in this application can solve the technical problem of low efficiency in resolving automated batch processing failures. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the automated batch processing failure solution provided in the above embodiments, and will not be repeated here.

[0112] The above descriptions are merely some embodiments of this application and do not limit the scope of protection of this application. Any equivalent structural transformations made based on the technical concept of this application and the content of this specification and drawings, or direct / indirect applications in other related technical fields, are included within the scope of protection of this application. All actions involving the acquisition of signals, information, or data in this application are performed in accordance with the relevant data protection laws and policies of the country where the application is located and with authorization from the owner of the corresponding device.

Claims

1. A solution to the failure of automated batch processing, characterized in that, The solutions for the failure of the automated batch processing case include: Obtain the execution batch with the highest success rate in the product batch running records, as well as the details of the failure cases associated with the execution batch with the highest success rate; Based on the details of the failure cases, root cause analysis is performed on the relevant failure cases using a pre-set large model to obtain the root cause analysis results; Based on the root cause analysis results, a solution is determined.

2. The solution to the automated batch processing failure as described in claim 1, characterized in that, The step of performing root cause analysis on relevant failure cases based on the failure case details and obtaining the root cause analysis results includes: Extract the log storage path from the failure case details, and read the complete execution log from the corresponding log storage system according to the log storage path; The complete execution log is assembled with the context information in the failure case details into a structured root cause analysis request; The root cause analysis request is submitted to the large model service interface so that the preset large model can perform root cause analysis based on the complete execution log and the context information in the failure case details to obtain the root cause analysis results. Receive the root cause analysis results returned by the large model service interface, the root cause analysis results including failure type and root cause description.

3. The solution to the automated batch processing failure as described in claim 2, characterized in that, The failure types include at least one of execution environment problems, data problems, test script problems, and business logic defects. The step of determining a solution based on the root cause analysis results includes: If the failure type is an execution environment problem, the solution is to wait for the execution set to be re-executed in the next execution cycle, and the corresponding failure case is marked as waiting to be re-run. If the failure type is a data problem or a test script problem, a solution will be matched according to the preset knowledge base; If the failure type is a business logic defect, the corresponding failure case will be marked as requiring manual confirmation, and the solution will be determined as pending manual confirmation.

4. The solution to the automated batch processing failure as described in claim 3, characterized in that, The step of matching a solution based on a preset knowledge base includes: Retrieves maintained solution records from the preset knowledge base. Each solution record contains at least one of the following: a problem description field, a solution type field, and a parameter call template corresponding to the repair method. The solution type includes at least one of the following: interface class, data canvas class, and Q&A class. Based on the preset priorities of different types of solutions, semantic similarity matching is performed between the root cause description and the problem description fields. Based on the matched solution type, a solution is determined from the solution record. The preset priorities are, in descending order, interface type, data canvas type, and Q&A type.

5. The solution to the automated batch processing failure as described in claim 4, characterized in that, The step of determining a solution from the solution record based on the matched solution type includes: If the matched solution type is an interface class or a data canvas class, the input parameters of the repair method are parsed from the root cause description, and the repair request is assembled according to the repair method call parameter template. The repair request is used to call the corresponding internal interface or execute the data canvas command. If the call is successful, the corresponding failure case is marked as repaired, and the execution set to which it belongs is triggered to be re-executed. If the call fails or the matched solution type is Q&A type, the matched Q&A type solution will be written into the recommended solution field of the corresponding record in the failure case details for user reference.

6. The solution to the automated batch processing failure as described in claim 4, characterized in that, After the step of performing semantic similarity matching between the root cause description and the problem description field according to the preset priority of different types of solutions, the method further includes: If no solution is found, the root cause description is written into the failure case details, and the corresponding recommended solution field in the preset knowledge base is left blank. The front-end page prompts the user to provide a reason, and in response to the user's supplementary solution, the user's supplementary solution is recorded in the recommended solution corresponding to the preset knowledge base.

7. The solution to the automated batch processing failure as described in claim 6, characterized in that, After determining the solution based on the root cause analysis results, the method further includes: For unresolved failure cases and failure cases with user-supplied recommended solutions, a summary file containing failure case identifiers, log links, root cause descriptions, and recommended solutions is generated. The summary file is then pushed to the corresponding responsible person via an instant messaging interface for case debugging. The front-end page displays a failed case management interface, allowing users to query cases, debug cases, or update case analysis status; In response to the case analysis status and actual solution filled in by the user, the actual solution and the corresponding failure case are synchronously written into the preset knowledge base; In response to the problem description entered by the user in the test handling method management module of the failure case management interface, the problem description is semantically matched with the problem description field in the preset knowledge base, and the matched solution is returned.

8. An automated batch processing failure resolution device, characterized in that, The automated batch processing failure resolution device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the automated batch processing failure resolution method as described in any one of claims 1 to 7.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the automated batch processing failure solution as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the automated batch processing failure solution as described in any one of claims 1 to 7.

Images