Methods, devices, and electronic equipment for locating the causes of failures in automated test cases.

Abstract

This application provides a method, apparatus, and electronic device for locating the failure cause of automated test cases, relating to the field of business operation and maintenance technology. The method includes: acquiring test case failure information when an automated test case fails to execute; locating and analyzing the target business stage at which the automated test case failed based on the test case failure information; searching a successful test case database for information matching the test case identifier based on the test case identifier; and determining the target failure cause of the automated test case based on the successful test case information, the target business stage, and the test case failure information. This method can improve the efficiency of locating the failure cause of automated test cases.

Description

Technical Field

[0001] This application relates to the field of business operation and maintenance technology, and in particular to a method, device, and electronic device for locating the failure cause of automated test cases. Background Technology

[0002] In software automated testing, the execution results of automated test cases directly reflect the functional integrity and stability of the system under test. When automated test cases fail, quickly and accurately locating the cause of failure is crucial for improving testing efficiency and shortening the problem-solving cycle. Current technologies primarily involve directly comparing the actual values ​​of interface-returned fields or database-stored fields with their expected values, only displaying the inconsistent field content to the user. Testers or on-call personnel then manually investigate and deduce the cause of failure based on the displayed discrepancies. Clearly, manual fault location is inefficient in scenarios with a large number of test cases. Summary of the Invention

[0003] This application provides a method, apparatus, and electronic device for locating the failure causes of automated test cases, which can improve the efficiency of locating the failure causes of automated test cases. The technical solution is as follows: According to one aspect of this application, a method for locating the failure cause of automated test cases is provided, the method comprising: In the event that an automated test case fails to execute, obtain the test case failure information for that automated test case. Based on the test case failure information, locate and analyze the target business stage at which the automated test case failed. Based on the test case identifier of the automated test case, search the successful test case database for information on successfully executed test cases that match the test case identifier; Based on the successful test case information, the target business stage, and the test case failure information, the target failure reason for the automated test case is determined.

[0004] According to another aspect of this application, an apparatus for locating the failure cause of automated test cases is provided, the apparatus comprising: The first acquisition module is used to acquire the test case failure information of the automated test case when the automated test case fails to execute. The location module is used to locate and analyze the target business stage where the automated test case fails based on the test case failure information. The search module is used to search the successful test case database for information on successfully executed test cases that match the test case identifier based on the test case identifier of the automated test case. The determination module is used to determine the target failure reason of the automated test case based on the successful test case information, the target business stage, and the test case failure information.

[0005] According to one aspect of this application, an electronic device is provided, comprising: a processor and a memory storing a program, the program including instructions that, when executed by the processor, cause the processor to perform the method for locating the failure cause of automated test cases as described above.

[0006] According to another aspect of this application, a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the method for locating the cause of failure of automated test cases as described above is provided.

[0007] According to another aspect of this application, a computer program product is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned method for locating the failure cause of automated test cases.

[0008] The beneficial effects of the technical solutions provided in this application include at least the following: When automated test cases fail, the system retrieves the test case failure information. Based on this information, it analyzes and locates the target business stage at which the test case failed. Then, based on the test case identifier, it searches the successful test case database for matching identifiers to identify successfully executed test cases. Finally, based on the successful test case information, the target business stage, and the test case failure information, it determines the target cause of the automated test case failure. This automated test case failure cause analysis avoids manual log queries, significantly shortens the failure cause location cycle, and improves the efficiency of failure cause location. Attached Figure Description

[0009] Further details, features, and advantages of this application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 A flowchart is shown for a method for locating the failure cause of an automated test case according to an exemplary embodiment of this application; Figure 2 This is a schematic diagram of the structure of an automated test case failure cause localization device provided in an embodiment of this application; Figure 3 A structural block diagram of an exemplary electronic device that can be used to implement embodiments of this application is shown. Detailed Implementation

[0010] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0011] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0012] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this application are only used to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies. It should be noted that the modifications "a" and "a plurality" mentioned in this application are illustrative and not restrictive, and those skilled in the art should understand that unless explicitly indicated in the context, they should be understood as "one or more". The names of messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0013] The present invention will now be described with reference to the accompanying drawings. The technical solutions provided by the embodiments of this application will be explained in detail through specific examples and application scenarios.

[0014] In software automated testing, the execution results of automated test cases directly reflect the functional integrity and stability of the system under test. When automated test cases fail, quickly and accurately locating the cause of the failure is crucial for improving testing efficiency and shortening the problem-solving cycle.

[0015] In existing technologies, the main method for locating the cause of automated test case execution failure is to directly compare the actual value of the interface returned field or the database stored field with the expected value, and only show the inconsistent field content to the user (for example, the actual return value of the field decisionTransaction.0.IS_PASS is 2, and the expected return value is 1). Then, the testers or on-duty personnel manually check the related database data, system logs and historical experience based on the displayed difference information, and then infer the cause of failure.

[0016] However, existing technologies have the following significant drawbacks: (1) Lack of auxiliary location information capability: It can only provide the difference results at the field level, and cannot directly reflect the business stage to which the failure belongs (such as credit granting, credit use one, credit use two stages), nor can it automatically associate key auxiliary data such as database configuration information, system operation logs, and historical location experience, resulting in the location process relying on manual experience and being inefficient.

[0017] (2) Lack of inference ability: It cannot identify the relationship between multiple execution tasks, cannot define the scope of analysis through the relationship, and has difficulty in exerting the inference ability of the intelligent analysis model. It can only provide single-dimensional difference information and cannot give multiple possible reasons for failure and priorities.

[0018] (3) Lack of indexing and classification capabilities for use cases: The information of historical failed use cases has not been systematically classified and managed, and has not formed a reusable knowledge base asset. Subsequent similar failure scenarios cannot directly refer to historical cases, resulting in repeated investigations and wasted resources.

[0019] Therefore, there is an urgent need for an automated test case failure cause localization system that can integrate multi-dimensional auxiliary information, possess intelligent inference capabilities, and reuse historical cases to address the shortcomings of existing technologies.

[0020] Please refer to Figure 1 This document illustrates a flowchart of a method for locating the failure cause of automated test cases according to an exemplary embodiment of this application. The method is described using an electronic device as an example. Figure 1 As shown, the method includes: Step 101: If the automated test case fails to execute, obtain the test case failure information of the automated test case; Step 102: Based on the test case failure information, locate and analyze the target business stage at which the automated test case failed. Step 103: Based on the test case identifier of the automated test case, search the successful test case database for information on successfully executed test cases that match the test case identifier; Step 104: Based on successful test case information, target business phase, and test case failure information, determine the target failure reason for the automated test case.

[0021] When an automated test case fails to execute, error logs, assertion information, execution step records, global variable and related database access logs of the automated test case can be collected simultaneously. The collected information is then sent to a classifier (classification component module), which uses the test case failure information to locate and analyze the target business stage at which the automated test case failed.

[0022] For example, taking a credit application scenario, the target business stages may include: credit granting stage, credit application stage one, and credit application stage two. In credit application stage one, the system will filter and sort multiple loan assistance codes; in credit application stage two, the system will sequentially or in parallel use the loan assistance codes to inquire with institutions to apply for credit granting or credit application.

[0023] Specifically, the classification component module can receive test case failure information, traverse the preset classification logic, and determine the target business stage (credit granting stage, credit usage stage one, or credit usage stage two) of the failed automated test case through multi-dimensional feature matching (stage-specific data features, interface return field features, execution step features, database association features, etc.). For example, the core feature of credit usage stage one may be the existence of sorting-related database tables such as loan assistance code screening / sorting data, while the core feature of credit usage stage two may be the existence of institutional interface call records and credit application return fields, etc.

[0024] Additionally, based on the test case identifier of the automated test case, the system can search the successful test case database for information on successfully executed test cases that match the identifier, providing a comparative analysis for subsequent failure analysis. Optionally, the successful test case information can be the test case information of the most recently successfully executed test case.

[0025] For example, successful use case information may include: execution parameters, database configuration, assertion results, stage transition records, and other full execution process information of the successful use case.

[0026] Furthermore, after obtaining successful test case information, target business stage, and test case failure information, the target failure reason of the automated test case can be determined based on the successful test case information, target business stage, and test case failure information.

[0027] Specifically, the failure cause analysis mainly consists of two stages: preliminary root cause localization and large-scale model root cause reasoning. In an exemplary example, step 104 may also include steps 104A and 104B.

[0028] Step 104A: Compare the failure information and success information of test cases to obtain the results of the multi-root cause analysis; Step 104B: Based on the multi-root cause analysis results, output the reasons for the target failure using the large language model.

[0029] In one possible implementation, a multi-dimensional root cause localization method is employed to compare test case failure information and successful test case information to obtain multi-dimensional root cause analysis results, providing a preliminary reference for subsequent reasoning analysis of the large language model. Specifically, step 104A may further include: determining the database environment analysis results by comparing the database environments of test case failure information and successful test case information; determining the failure node analysis results by comparing the business execution stages of test case failure information and successful test case information; obtaining the anomaly feature analysis results by performing cluster analysis on the test case failure information and successful test case information; and determining the database environment analysis results, failure node analysis results, and anomaly feature analysis results as the multi-root cause analysis results.

[0030] As can be seen, multi-root cause analysis is mainly conducted through three methods: comparative analysis of the database environment, comparative analysis of the business execution stage, and cluster analysis.

[0031] Among them, the database environment dimension comparative analysis compares the "database environment when the current failed test case was executed" with the "database environment when the test case was last successfully executed" to investigate differences in database configuration and data status, and pinpoint the root cause of failure caused by data / configuration anomalies. Specific content includes: data existence of core business tables: for example, the NO_PLAN_POOL_UNION_CONFIG table (no-plan pool configuration table) is empty when it fails, but has 4 fixed loan assistance code configurations when it succeeds; table data modification time: such as the latest modification time of the UNION_GROUP_RECORD and other switching relationship tables, to determine whether there is "dirty data" within the target time range (in the document example, the modification time is earlier than the target range, excluding the influence of dirty data); table structure / configuration consistency: such as the field structure and fixed rules of the FAIR_POOL_GROUP_CONFIG table (fair pool configuration table), whether they are consistent with those when it succeeds (in the document example, the table data is empty but the structure is normal, determining that "the loan process is normal"); its core purpose is to eliminate or confirm the root causes at the environmental level such as "database data missing, dirty data, configuration changes", and provide key evidence of "normal environment" or "normal environment" for subsequent large model inference.

[0032] The comparative analysis of business execution phases follows the business process sequence of "credit granting phase, credit use phase one, and credit use phase two," comparing the "phase execution data of failed use cases" with the "phase execution data of successful use cases" stage by stage to pinpoint the specific business execution phase in which the problem occurred and the core differences in that business execution phase. The specific comparison includes: Stage entry status: whether the target stage was successfully entered (e.g., if the test case fails, the second stage of credit use is not entered; if successful, the entire stage can be entered, and the problem is determined to be only in the first stage of credit use); Stage-specific data output: such as the loan assistance code filtering results (filteredUnionCodeReasons array) and sorting results (allSortedUnionCodesList array) of the first stage of credit use, compared with the expected results when successful (the sorting in the document is inconsistent with the expected sorting when it fails, but conforms to the rules when it succeeds); Stage core fields: such as the value differences of decisionTransaction.0.IS_PASS (stage execution result) and UNION_CODE_STAGE (stage identifier); Core purpose: to accurately identify the failed business process nodes, avoid blindly investigating across stages, and at the same time obtain the specific differences of the business execution stage (e.g., the sorting anomaly in the first stage of credit use), narrowing down the root cause range.

[0033] Cluster analysis primarily involves a three-step process: feature extraction, grouping and clustering, and difference extraction. Specifically: 1. **Key Feature Extraction:** Extract structured features from successful and failed use cases, such as "stage labels, database table dependencies, input parameters, core field outputs, and execution steps" (e.g., "Credit Usage Stage 1 + Dependency on NO_PLAN_POOL_UNION_CONFIG table + Loan Code Sorting Target"). 2. **Similarity Clustering and Grouping:** Calculate the feature similarity between use cases using algorithms (e.g., cosine similarity, Euclidean distance), grouping use cases with "highly similar features" into one category (e.g., all use cases with "Credit Usage Stage 1 + Loan Code Sorting Failure" grouped together). 3. **Difference Extraction Between Groups:** Compare the feature differences between the "successful use case clustering group" and the "failed use case clustering group," filtering out "abnormal features" that only appear in the failed group (e.g., all failed use cases have "NO_PLAN_POOL_UNION_CONFIG table is empty," while the successful group does not).

[0034] Optionally, based on cluster analysis, the mapping relationship between failed and successful use cases on key features can also be extracted. For example, positive correlation: "normal features" shared by failed and successful use cases (such as "same input parameters + same execution steps") indicate that these features are not the cause of failure; negative correlation: "abnormal features" that exist only in failed use cases and not in successful use cases (such as "NO_PLAN_POOL_UNION_CONFIG table is empty" and "funding plan status assessment is abnormal"), these features are the core correlation factors that lead to failure.

[0035] By calculating the correlation, it is also possible to quickly filter out "abnormal features that are strongly correlated with failure" from a massive number of features, avoiding omissions and inefficiencies in manual screening.

[0036] In the root cause reasoning stage of the large model, in an exemplary example, step 104B may further include: converting the use case failure information into a failure feature vector; recalling associated use case information from the target knowledge base based on the failure feature vector, the associated use case information including failure case information of candidate failed use cases and success case information of candidate successful use cases; inputting the associated use case information, successful use case information, multi-root cause analysis results, and target business logic of the target business stage into the large language model to obtain the target failure cause output by the large language model.

[0037] When performing root cause reasoning, the large language model first recalls related test case information associated with the failed automated test cases. Then, combining this with the results of multi-root cause analysis, it generates the final target failure reason. Specifically, the large language model first extracts multi-dimensional features from the test case failure information to obtain a failure feature vector. Based on this feature vector, it then recalls relevant related test case information from the target knowledge base, which can include successful execution case information as well as failed execution case information. Simultaneously, it retrieves the target business logic from the business logic knowledge base based on the target business stage. Then, based on the target business logic, multi-root cause analysis results, successful test case information, and related test case information, it generates model reasoning prompts, which are input into the large language model. The large language model then infers the target failure reason of the automated test case based on the above information.

[0038] When extracting failure feature vectors, failure feature vectors can be extracted from several dimensions such as stage labels, test targets, core difference features, and dependency association information. The stage label is the target business stage (credit granting stage / credit usage stage 1 / credit usage stage 2) determined by the classification component module. It is used to define the scope of the business process and exclude cross-stage cases (e.g., credit usage stage 2 cases will not match failed cases in credit usage stage 1). The test objective is the core verification purpose of the automated test case, such as "loan assistance code sorting verification" and "no-plan pool configuration verification". It is used to lock the business scenario and ensure that cases matching "the same type of verification objective" are matched (e.g., sorting problems only match sorting-related cases). The core difference feature is the key difference derived from multi-root cause analysis, such as "NO_PLAN_POOL_UNION_CONFIG table is empty", "loan assistance code sorting is inconsistent", and "funding plan status is abnormal". It is used to match cases with "the same type of problem features" (e.g., failures caused by missing table data). The dependency and association information is the database tables that the test case depends on (e.g., NO_PLAN_POOL_UNION_CONFIG, FAIR_POOL_GROUP_CONFIG) and core fields (e.g., decisionTransaction.0.IS_PASS). It is used to strengthen the scenario association. For example, cases that depend on the same data table have higher priority.

[0039] When recalling related use case information, candidate cases with "feature overlap ≥ 60%" are recalled from the target knowledge base; the matching score between the candidate cases and the current failed use cases is calculated using a text similarity algorithm (such as cosine similarity), and cases with "similarity ≥ 80%" are selected as "most matching similar use cases" (the 2-3 with the highest scores are displayed first to avoid information overload); cases with "similar scenarios but different root causes" are excluded (e.g., both failed to sort using XinYi, but the root cause is "interface timeout" rather than "missing table data"), to ensure the root cause reusability of the final recommended cases.

[0040] Optionally, the target failure reasons output by the large language model may include: failure reason analysis, including: reason priority, root cause description, basis for difference, scope of impact and repair direction; and recommended use case information, including successful case references and similar failure repair cases.

[0041] Optionally, a large model optimization mechanism is also provided. The target failure reason output from the large language model can be displayed on the front-end interface, allowing operations personnel to verify and modify it. When operations personnel make modifications, the system can receive the modified failure reason and obtain the revised failure reason. Based on the modified failure reason, the target failure reason, related use case information, successful use case information, multi-root cause analysis results, and the target business logic of the target business stage, the large language model is optimized to gradually improve the accuracy of failure reason localization during actual operations.

[0042] Optionally, in order to obtain successful test case information associated with failed test cases during actual application, successful test cases that have been executed successfully can be obtained, the business execution stage corresponding to the successful test cases can be analyzed, and the successful test cases and the business execution stages can be stored in the successful test case database.

[0043] In summary, this application provides a method for locating the failure cause of automated test cases: when an automated test case fails to execute, the failure information of the automated test case is obtained; based on the failure information, the target business stage at which the automated test case failed is located and analyzed; based on the test case identifier of the automated test case, successful test case information matching the test case identifier is searched from the successful test case database; based on the successful test case information, the target business stage, and the test case failure information, the target failure cause of the automated test case is determined. This achieves automated test case failure cause analysis, avoids manual log querying, significantly shortens the failure cause location cycle, and improves the efficiency of failure cause location.

[0044] Moreover, by "locating the target business stage," the failure is clearly identified in the credit granting / credit usage stage one / credit usage stage two, and then targeted comparison is performed in conjunction with "successful use case information." This avoids blind investigation across stages and directly narrows the investigation scope to the target stage, reducing ineffective operations. Based on "matching successful use cases," the core differences within the stage are accurately identified through targeted comparison of "failure information vs. success information," rather than relying on vague manual inference, significantly improving the accuracy of root cause localization.

[0045] Please refer to Figure 2 This is a schematic diagram of the structure of an automated test case failure cause localization device provided in an embodiment of this application. For example, as shown... Figure 2 As shown, the device 200 includes: The first acquisition module 201 is used to acquire the test case failure information of the automated test case when the automated test case fails to execute. The positioning module 202 is used to locate and analyze the target business stage at which the automated test case fails based on the test case failure information. The lookup module 203 is used to search the successful test case database for information on successful test cases that match the test case identifier based on the test case identifier of the automated test case. The determination module 204 is used to determine the target failure reason of the automated test case based on the successful test case information, the target business stage, and the test case failure information.

[0046] Optionally, the determining module 204 is further configured to: By comparing the failure information of the test cases with the success information of the test cases, the results of the multi-root cause analysis are obtained. Based on the multi-root cause analysis results, the reasons for the target failure are output using a large language model.

[0047] Optionally, the determining module 204 is further configured to: The database environment analysis results are determined by comparing the database environments of the test case failure information and the test case success information. By comparing the business execution stages of the failed and successful test cases, the analysis results of the failure nodes are determined. By performing cluster analysis on the failure information and success information of the test cases, the results of anomaly feature analysis are obtained; The database environment analysis results, the failure node analysis results, and the anomaly feature analysis results are determined as the multi-root cause analysis results.

[0048] Optionally, the determining module 204 is further configured to: The failure information of the test cases is converted into a failure feature vector; Based on the failure feature vector, related use case information is retrieved from the target knowledge base. The related use case information includes failure case information of candidate failed use cases and success case information of candidate successful use cases. The associated use case information, the successful use case information, the multi-root cause analysis results, and the target business logic of the target business stage are input into the large language model to obtain the target failure reason output by the large language model.

[0049] Optionally, the device further includes: The receiving module is used to receive the modification operation on the failure reason of the target and obtain the modified failure reason; The model optimization module is used to optimize the large language model based on the modified failure reasons, the target failure reasons, the associated use case information, the successful use case information, the multi-root cause analysis results, and the target business logic of the target business stage.

[0050] Optionally, the device further includes: The second acquisition module is used to acquire successful test cases that have been executed successfully. The analysis module is used to analyze the business execution phase corresponding to the successful test cases; The storage module is used to store the successful test cases and the business execution phases into the successful test case database.

[0051] In summary, this application provides a method for locating the failure cause of automated test cases: when an automated test case fails to execute, the failure information of the automated test case is obtained; based on the failure information, the target business stage at which the automated test case failed is located and analyzed; based on the test case identifier of the automated test case, successful test case information matching the test case identifier is searched from the successful test case database; based on the successful test case information, the target business stage, and the test case failure information, the target failure cause of the automated test case is determined. This achieves automated test case failure cause analysis, avoids manual log querying, significantly shortens the failure cause location cycle, and improves the efficiency of failure cause location.

[0052] An exemplary embodiment of this application also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, which, when executed by the at least one processor, causes the electronic device to perform a method for locating the failure cause of automated test cases according to an embodiment of this application.

[0053] An exemplary embodiment of this application also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method for locating the failure cause of automated test cases according to an embodiment of this application.

[0054] An exemplary embodiment of this application also provides a computer program product, including a computer program, wherein, when executed by a computer's processor, the computer program is used to cause the computer to perform a method for locating the failure cause of automated test cases according to an embodiment of this application.

[0055] refer to Figure 3The present invention describes a structural block diagram of an electronic device 300 that can serve as a server or client of this application, which is an example of a hardware device that can be applied to various aspects of this application. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the application described and / or claimed herein.

[0056] like Figure 3 As shown, the electronic device 300 includes a computing unit 301, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 302 or a computer program loaded from a storage unit 308 into a random access memory (RAM) 303. The RAM 303 may also store various programs and data required for the operation of the electronic device 300. The computing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0057] Multiple components in electronic device 300 are connected to I / O interface 305, including: input unit 306, output unit 307, storage unit 308, and communication unit 309. Input unit 306 can be any type of device capable of inputting information to electronic device 300. Input unit 306 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 307 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 308 may include, but is not limited to, disk and optical disk. Communication unit 309 allows electronic device 300 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0058] Optionally, the electronic device 300 also includes a single-channel EEG signal acquisition module (not shown in the figure). This module is used to acquire EEG signals and transmit them to the signal processor of the electronic device 300 for EEG signal processing.

[0059] The computing unit 301 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 301 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 301 performs the various methods and processes described above. For example, in some embodiments, the methods shown in the above embodiments can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as storage unit 308. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 300 via ROM 302 and / or communication unit 309. In some embodiments, the computing unit 301 can be configured to perform the methods shown in the above embodiments by any other suitable means (e.g., by means of firmware).

[0060] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0061] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on 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 fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0062] As used in this application, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0063] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0064] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0065] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

Claims

1. A method for locating the failure cause of automated test cases, characterized in that, The method includes: In the event that an automated test case fails to execute, obtain the test case failure information for that automated test case. Based on the test case failure information, locate and analyze the target business stage at which the automated test case failed. Based on the test case identifier of the automated test case, search the successful test case database for information on successfully executed test cases that match the test case identifier; Based on the successful test case information, the target business stage, and the test case failure information, the target failure reason for the automated test case is determined.

2. The method according to claim 1, characterized in that, The determination of the target failure reason for the automated test case based on the successful test case information, the target business stage, and the test case failure information includes: By comparing the failure information of the test cases with the success information of the test cases, the results of the multi-root cause analysis are obtained. Based on the multi-root cause analysis results, the reasons for the target failure are output using a large language model.

3. The method according to claim 2, characterized in that, The comparison of the test case failure information and the test case success information yields the multi-root cause analysis results, including: The database environment analysis results are determined by comparing the database environments of the test case failure information and the test case success information. By comparing the business execution stages of the failed and successful test cases, the analysis results of the failure nodes are determined. By performing cluster analysis on the failure information and success information of the test cases, the results of anomaly feature analysis are obtained; The database environment analysis results, the failure node analysis results, and the anomaly feature analysis results are determined as the multi-root cause analysis results.

4. The method according to claim 3, characterized in that, The step of outputting the reasons for the target failure based on the multi-root cause analysis results using a large language model includes: The failure information of the test cases is converted into a failure feature vector; Based on the failure feature vector, related use case information is retrieved from the target knowledge base. The related use case information includes failure case information of candidate failed use cases and success case information of candidate successful use cases. The associated use case information, the successful use case information, the multi-root cause analysis results, and the target business logic of the target business stage are input into the large language model to obtain the target failure reason output by the large language model.

5. The method according to claim 4, characterized in that, The method further includes: Receive a modification operation on the failure reason of the target, and obtain the modified failure reason; Based on the modified failure reasons, the target failure reasons, the associated use case information, the successful use case information, the multi-root cause analysis results, and the target business logic of the target business stage, the large language model is optimized.

6. The method according to any one of claims 1 to 4, characterized in that, The method further includes: Retrieve successful test cases that were executed successfully; Analyze the business execution phase corresponding to the successful test cases; The successful test cases and the business execution phases are stored in the successful test case database.

7. A device for locating the failure cause of automated test cases, characterized in that, The device includes: The first acquisition module is used to acquire the test case failure information of the automated test case when the automated test case fails to execute. The location module is used to locate and analyze the target business stage where the automated test case fails based on the test case failure information. The search module is used to search the successful test case database for information on successfully executed test cases that match the test case identifier based on the test case identifier of the automated test case. The determination module is used to determine the target failure reason of the automated test case based on the successful test case information, the target business stage, and the test case failure information.

8. The apparatus according to claim 7, characterized in that, The determining module is further configured to: By comparing the failure information of the test cases with the success information of the test cases, the results of the multi-root cause analysis are obtained. Based on the multi-root cause analysis results, the reasons for the target failure are output using a large language model.

9. An electronic device, comprising: processor; as well as Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the failure cause localization method for automated test cases according to any one of claims 1-6.

10. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to execute the method for locating the failure cause of automated test cases according to any one of claims 1-6.

Images