Test fault processing method and device, equipment, medium and program product

Abstract

The invention provides a test fault processing method which can be applied to the fields of cloud computing, artificial intelligence and software testing. The test fault processing method comprises the following steps: in response to a service test request of a target service, determining an initial service scene according to the service test request; according to the initial service scene, determining a target service unit link and a target service success log, the target service unit link comprising a plurality of test units and each test unit having test time, and the target service success log representing a log of the last successful execution record in the service scene; determining a fault unit from the plurality of test units according to the target service unit link; performing self-learning modification on the fault message information of the fault unit according to the target service success log to obtain modified message information; and sending the modified message information to a downstream unit of the fault unit so as to continue testing. The invention further provides a test fault processing device and equipment, a storage medium and a program product.

Description

Test fault handling methods, devices, equipment, media and procedures products Technical Field

[0001] This application relates to the fields of cloud computing, artificial intelligence and software testing technology, specifically to the handling of test faults, and more specifically to a test fault handling method, apparatus, equipment, medium and program product. Background Technology

[0002] With the widespread adoption of microservice architectures and distributed systems, the complexity of cross-component transaction chains has increased exponentially. In scenarios with extremely high real-time requirements, a single node failure can cause the entire transaction chain to be interrupted. For example, during testing, environmental issues in upstream and downstream business processes often lead to interruptions in the testing and verification process.

[0003] When troubleshooting, business testers need to collaborate with technical and development teams to analyze logs and other methods to eliminate the cause of program defects. Especially in current projects involving application decoupling and localization transformation, which involve many switching operations, cross-environmental troubleshooting between applications requires significant manpower and time. In rapidly iterating version planning, lengthy troubleshooting can affect the progress of overall testing. Summary of the Invention

[0004] In view of the above problems, this application provides a test fault handling method, apparatus, equipment, medium and program product, which can skip the problematic application unit in a short time and ensure that the core application can be successfully tested during business testing.

[0005] According to the first aspect of this application, a test fault handling method is provided, comprising: responding to a business test request of a target business; determining an initial business scenario based on the business test request; determining a target business unit link and a target business success log based on the initial business scenario, wherein the target business unit link includes multiple test units and each test unit is accompanied by a test time, and the target business success log represents the log of the most recent successful execution record under the business scenario; determining a fault unit from the multiple test units based on the target business unit link, wherein the fault unit is not the test unit with the latest test time; performing self-learning modification on the fault message information of the fault unit based on the target business success log to obtain modified message information; and sending the modified message information to the downstream unit of the fault unit to continue testing, wherein the downstream unit represents the next test unit of the fault unit in the target business unit link.

[0006] According to an embodiment of this application, determining the target business unit link and the target business success log based on the initial business scenario includes: obtaining a historical business scenario library, which stores multiple historical business scenarios, each of which stores a corresponding historical business unit link and a historical business log; determining a matching target business scenario from the multiple historical business scenarios based on the initial business scenario; determining the historical business unit link and historical business log corresponding to the target business scenario from the historical business scenario library; and determining the target business unit link and the target business success log based on the historical business unit link and historical business log.

[0007] According to an embodiment of this application, the historical service log includes historical message information; the test fault handling method further includes: updating the historical message information according to the modified message information.

[0008] According to an embodiment of this application, determining a faulty unit based on a target service unit link includes: running the target service unit link and obtaining the running result; and based on the running result, determining the test unit where the link interruption occurred and identifying the test unit as a faulty unit.

[0009] According to an embodiment of this application, running the target business unit link and obtaining the running results includes: establishing a running trace view based on the target business unit link; and displaying the running results through the running trace view.

[0010] According to an embodiment of this application, self-learning modification of the fault message information of a faulty unit based on the target service success log includes: obtaining a responsible person relationship database, which stores multiple responsible person information, each of which corresponds to a test unit; determining the matching target responsible person information from the multiple responsible person information based on the faulty unit; sending a runtime tracking view to the target responsible person corresponding to the target responsible person information, wherein the runtime tracking view is established based on the target service unit link; and, in response to receiving a processing instruction from the target responsible person, performing self-learning modification of the first message information based on the processing instruction and the target service success log.

[0011] According to an embodiment of this application, the test fault handling method further includes: updating the runtime trace view based on the modified message information.

[0012] According to an embodiment of this application, the target service success log includes success message information. The self-learning modification of the fault message information of the fault unit based on the target service success log further includes: modifying the key fields of the fault message information based on the key fields of the success message information; and setting the message data of the success message information as the message data of the fault message information.

[0013] A second aspect of this application provides a test fault handling apparatus, comprising: a response module, configured to respond to a business test request of a target business and determine an initial business scenario based on the business test request; a first analysis module, configured to determine a target business unit link and a target business success log based on the initial business scenario, wherein the target business unit link includes multiple test units and each test unit is accompanied by a test time, and the target business success log represents the log of the most recent successful execution record under the business scenario; a second analysis module, configured to determine a fault unit from the multiple test units based on the target business unit link, wherein the fault unit is not the test unit with the latest test time; a self-learning modification module, configured to perform self-learning modification on the fault message information of the fault unit based on the target business success log to obtain the modified message information; and a transmission module, configured to send the modified message information to the downstream unit of the fault unit to continue testing, wherein the downstream unit represents the next test unit of the fault unit in the target business unit link.

[0014] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0015] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0016] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0017] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0018] Figure 1 schematically illustrates an application scenario of the test fault handling method according to an embodiment of this application;

[0019] Figure 2 schematically illustrates a flowchart of a test fault handling method according to an embodiment of this application;

[0020] Figure 3 schematically illustrates a flowchart of matching target business scenarios according to an embodiment of this application;

[0021] Figure 4 schematically illustrates a flowchart of the process handled by the person in charge according to an embodiment of this application;

[0022] Figure 5 schematically illustrates a structural block diagram of a test fault handling apparatus according to an embodiment of this application; and

[0023] Figure 6 schematically illustrates a block diagram of an electronic device suitable for implementing a test fault handling method according to an embodiment of this application. Detailed Implementation

[0024] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0025] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0026] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0027] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0028] It should be noted that the fault handling method and apparatus of this application can be used in the field of financial technology, or in any field other than financial technology. The application field of the fault handling method and apparatus of this application is not limited.

[0029] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0030] In scenarios involving automated decision-making using personal information, the methods, devices, and systems provided in this application all offer users corresponding entry points for choosing to agree to or reject the automated decision-making results. If the user chooses to reject, the process proceeds to the expert decision-making stage. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making a decision. Here, "expert decision-making" refers to the activity of making decisions by personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0031] The embodiments of this application provide a test fault handling method, which automatically learns the problem component handling method, analyzes the method of enabling successful execution records, takes the most recent successful execution record node to replace the current transaction data and triggers the breakpoint, so as to meet the core application to complete the verification in a short time, thereby improving and solving the need to complete the test verification in a short time.

[0032] Figure 1 schematically illustrates an application scenario of the test fault handling method according to an embodiment of this application.

[0033] As shown in Figure 1, the application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0034] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0035] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0036] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0037] It should be noted that the test fault handling method provided in this application embodiment can generally be executed by server 105. Correspondingly, the test fault handling device provided in this application embodiment can generally be located in server 105. The test fault handling method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the test fault handling device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0038] It should be understood that the number of terminal devices, networks, and servers shown in Figure 1 is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0039] The following will describe in detail the test fault handling method according to the embodiments of this application based on the scenario described in Figure 1, with reference to Figures 2 to 6.

[0040] Figure 2 schematically illustrates a flowchart of a test fault handling method according to an embodiment of this application.

[0041] As shown in Figure 2, the test fault handling method of this embodiment includes operations S210 to S250, and this transaction processing method can be executed by the server.

[0042] In operation S210, in response to the business test request of the target business, the initial business scenario is determined based on the business test request.

[0043] In some embodiments, when a test request for a target service is received, the parameters in the request (such as service type, input data, and environment configuration, etc.) are parsed, and an initial service scenario is generated according to preset service scenario matching rules (such as keyword matching, configuration mapping).

[0044] In operation S220, a target service unit link and a target service success log are determined according to the initial service scenario. The target service unit link includes multiple test units, and each test unit is attached with a test time.

[0045] In some embodiments, for example, according to the initial service scenario, the corresponding target service unit link can be extracted from a predefined link library. The target service unit link is composed of multiple test units in the execution order, and each unit is attached with a test timestamp. Among them, the above-mentioned multiple test units can be multiple different application components.

[0046] Synchronously obtain the "target service success log" in this scenario, which can be the output message, status code, and timestamp of each unit during the most recent successful execution, etc.

[0047] In operation S230, a faulty unit is determined from multiple test units according to the target service unit link.

[0048] In some embodiments, for example, the target service unit link can be run. If the link is interrupted (such as timeout, error code return) at a non-terminal unit (that is, the unit with the latest test time), then this unit is marked as a faulty unit.

[0049] For example, A, B, and C are three different test units respectively. If the execution order of the link is A→B→C, and the test times are T1<T2<T3 in sequence, if test unit B fails, then test unit B is set as the faulty unit.

[0050] In operation S240, the faulty message information of the faulty unit is self-learned and modified according to the target service success log, and the modified message information is obtained.

[0051] In some embodiments, based on the historical successful message (such as field structure, data format) of the faulty unit in the target service success log, its current faulty message is automatically corrected. The specific correction methods can include: replacing missing fields, adjusting data encoding, and repairing the message header check value, etc.

[0052] In operation S250, the modified message information is sent to the downstream unit of the faulty unit to continue the test.

[0053] In some embodiments, the corrected message can be sent to the downstream unit of the faulty unit (for example, when unit B fails, the downstream is unit C), and the subsequent link test is re-triggered.

[0054] In addition, after downstream processing, the message log returned by the previous downstream unit can be retrieved, and information comparison and data replacement operations can be performed with the message returned by the current downstream unit. The recombined message can then be sent to the subsequent unit.

[0055] Through link timing analysis, the embodiments of this application can eliminate interference from end-units and quickly locate intermediate fault points. Furthermore, it utilizes historical successful logs to self-learn and correct messages, reducing manual troubleshooting time. Finally, it automatically resumes downstream testing after fault repair, avoiding repeated execution across the entire link.

[0056] Figure 3 schematically illustrates a flowchart of matching target business scenarios according to an embodiment of this application.

[0057] As shown in Figure 3, the test fault handling method of this embodiment includes operations S310 to S340.

[0058] When operating S310, the historical business scenario library is obtained. The historical business scenario library stores multiple historical business scenarios. Each historical business scenario stores a corresponding historical business unit link and a historical business log.

[0059] In some embodiments, as shown in Table 1, each record in the historical business scenario library may include, for example, a triple: historical business scenario, historical business unit link (including unit order and timestamp), and historical business log (including message, status code, time, etc.).

[0060] Table 1

[0061] Historical business scenarios, historical business unit links, historical business logs: CR1-R2-R3-R4 2024.02.28 15:01 log; YR1-R3-R5-R7 2024.02.28 15:01 log. surface

[0062] For example, historical scenario "C" corresponds to the link "R1→R2→R3→R4", and the success logs for this link are stored. Historical scenario "Y" corresponds to the link "R1→R3→R5→R7", and the success logs for this link are stored. Here, R1~R7 can represent application components of the application under test.

[0063] When operating S320, a matching target business scenario is determined from multiple historical business scenarios based on the initial business scenario.

[0064] In some embodiments, key fields can be matched with each of the aforementioned multiple historical business scenarios based on the key fields of the initial business scenario to determine the matching target business scenario.

[0065] When operating S330, the historical business unit links and historical business logs corresponding to the target business scenario are determined from the historical business scenario database.

[0066] In some embodiments, please refer to Table (1) to find the historical business unit link and historical business log corresponding to the target business scenario after obtaining the target business scenario.

[0067] When operating S340, the target business unit link and target business success log are determined based on the historical business unit link and historical business log.

[0068] In some embodiments, the identified historical service unit links and historical service logs can be directly used as the current target service unit links and target service success logs.

[0069] This application embodiment can quickly identify the links and logs corresponding to the target business scenario by building a historical business scenario library, thereby improving the efficiency of test fault handling.

[0070] According to an embodiment of this application, the historical service log includes historical message information; the test fault handling method further includes: updating the historical message information according to the modified message information.

[0071] In some embodiments, after a fault message is corrected, the corrected message can be stored in the historical business scenario database as the latest successful historical message information to overwrite the old version log. Furthermore, the fault unit identifier and modification time can be associated with the message during storage for easier subsequent retrieval.

[0072] This application embodiment improves the accuracy of correcting target service success logs by continuously updating historical message information in historical service logs.

[0073] According to an embodiment of this application, determining a faulty unit based on a target service unit link includes: running the target service unit link and obtaining the running results. Based on the running results, identifying the test unit where the link interruption occurred, and determining that test unit as a faulty unit.

[0074] In some embodiments, test units can be called sequentially according to the order of the target business unit link, and the return status of each unit (such as HTTP status code, exception stack) can be monitored in real time by dynamically capturing it. If a unit does not return a response or returns an error code, it is determined that the link is interrupted. The faulty unit is marked according to the interruption location, and the reason for the interruption (such as timeout, data verification failure) is recorded.

[0075] This application embodiment can quickly identify faulty units by dynamically capturing the execution status of the link.

[0076] According to an embodiment of this application, running the target service unit link and obtaining the running results includes: establishing a running trace view based on the target service unit link. The running trace view then displays the running results.

[0077] In some embodiments, the execution order, time consumption, and status of each unit in the link can be displayed in the form of visual charts (such as Gantt charts or topology diagrams). It also supports functions such as clicking on a unit to view detailed messages, error logs, and highlighting faulty units.

[0078] This application embodiment can intuitively display the entire chain through the running trace view, reducing the threshold for understanding the problem. At the same time, managers can also quickly locate the problem through the view without manually analyzing logs, which greatly improves the efficiency of fault handling.

[0079] Figure 4 schematically illustrates a flowchart of the process handled by the person in charge according to an embodiment of this application.

[0080] As shown in Figure 4, the test fault handling method of this embodiment includes operations S410 to S440.

[0081] When operating S410, the responsible person relationship database is obtained. The responsible person relationship database stores information on multiple responsible persons, and each responsible person information corresponds to a test unit.

[0082] In some embodiments, as shown in Table 2, the person in charge relationship database may, for example, store the mapping relationship between test units and persons in charge.

[0083] Table 2

[0084] Test Unit R1R2R3R4 Person in Charge Information: Zhang San, Li Si, Wang Wu, Cui Liu surface

[0085] For example, test units R1 to R4 can correspond to the responsible persons Zhang San, Li Si, Wang Wu, and Cui Liu, respectively.

[0086] When operating S420, the target responsible person information is determined from multiple responsible person information based on the faulty unit.

[0087] In some embodiments, the information of the person in charge corresponding to the faulty unit can be accurately found based on the mapping relationship in the person in charge relationship database, wherein the person in charge information may include, for example, name, contact information and work department, etc.

[0088] When operating S430, the run trace view is sent to the target person in charge corresponding to the target person in charge information. The run trace view is established based on the target business unit link.

[0089] In some embodiments, once a faulty unit is marked, the system can automatically push the operation tracking view and fault details (such as error messages and historical comparisons) to the corresponding responsible person.

[0090] For example, when test unit R2 malfunctions and is marked as a faulty unit, the operation tracking view information will be sent to Li Si, the person in charge of test unit R2.

[0091] When operating S440, in response to receiving the processing instruction from the person in charge of the target, the first message information is modified through self-learning based on the processing instruction and the business log.

[0092] In some embodiments, after receiving the operation tracking view information, the person in charge can give instructions on how to handle the current fault (such as "ignore the error" and "manually correct the message"). After receiving the instructions from the target person in charge, the first message information will be automatically modified based on the instructions and the target service success log.

[0093] This application embodiment improves the accuracy of fault handling by constructing a responsible person relationship database to ensure that faulty units can be handled by professional responsible persons.

[0094] According to an embodiment of this application, the test fault handling method further includes: updating the runtime trace view based on the modified message information.

[0095] In some embodiments, after a message is corrected, the status of the corresponding unit in the run trace view can be dynamically updated (e.g., from "Failed" to "Fixed"), and the differences in messages before and after the correction can be displayed. The updated view can be viewed in real time by all test participants.

[0096] This embodiment of the disclosure achieves synchronization of fault handling status by dynamically updating the operation tracking view, ensuring that the person in charge can obtain the latest test progress.

[0097] According to an embodiment of this application, the target service success log includes success message information. The self-learning modification of the fault message information of the fault unit based on the service log also includes: modifying the key fields of the fault message information based on the key fields of the success message information; and setting the message data of the success message information as the message data of the fault message information.

[0098] A message consists of a header and a body. The header is generally fixed and can be directly copied and used. If unique identifying elements such as event numbers or sequence numbers exist, they can be selected as independent variables, and rules can be manually set (such as automatically incrementing the number by one). The body mainly includes the core transaction elements of the current business, such as account information and agreement information. These are extracted from the upstream and then used to form new messages through self-learning before being sent downstream.

[0099] In some embodiments, key fields (such as event number and sequence number) can be extracted from the success message information, and then the key fields can be automatically incremented by one. The key fields represent unique identifiers.

[0100] After modifying the key fields, the message data of the current successful message is set as the message data of the failure message. This message data can include core transaction elements of the current business (such as account information and agreement information).

[0101] For example, operations such as comparing the message data of successful messages with the message data of fault messages, replacing transaction data, and incrementing the unique identifier element can be performed.

[0102] For example, if the identifier number in a success message is 2, then the identifier number of the message data in the failure message information will be corrected to 3.

[0103] Furthermore, embodiments of this application can also apply the data template of a successful message to a fault message to ensure downstream unit compatibility.

[0104] This application embodiment avoids the risk of data loss caused by full message replacement through field-level repair, and also quickly skips faulty units by self-learning and modifying message data while ensuring downstream compatibility, greatly improving the efficiency of test fault handling.

[0105] Based on the above-described test fault handling method, this application also provides a test fault handling device. The device will be described in detail below with reference to Figure 5.

[0106] Figure 5 schematically illustrates a structural block diagram of a test fault handling apparatus according to an embodiment of this application.

[0107] As shown in Figure 5, the test fault handling device 500 of this embodiment includes a response module 510, a first analysis module 520, a second analysis module 530, a self-learning modification module 540, and a transmission module 550.

[0108] The response module 510 is used to respond to a business test request from the target business and determine the initial business scenario based on the business test request. In one embodiment, the response module 510 can be used to perform the operation S210 described above, which will not be repeated here.

[0109] The first analysis module 520 is used to determine the target business unit link and the target business success log based on the initial business scenario. The target business unit link includes multiple test units, and each test unit is accompanied by a test time. In one embodiment, the first analysis module 520 can be used to perform the operation S220 described above, which will not be repeated here.

[0110] The second analysis module 530 is used to determine the faulty unit from multiple test units based on the target service unit link. In one embodiment, the second analysis module 530 can be used to perform the operation S230 described above, which will not be repeated here.

[0111] The self-learning modification module 540 is used to perform self-learning modification on the fault message information of the faulty unit based on the target service success log, so as to obtain the modified message information. In one embodiment, the self-learning modification module 540 can be used to execute the operation S240 described above, which will not be repeated here.

[0112] The transmission module 550 is used to send the modified message information to the downstream unit of the faulty unit to continue testing. In one embodiment, the transmission module 550 can be used to perform the operation S250 described above, which will not be repeated here.

[0113] According to embodiments of this application, any multiple modules among the response module 510, the first analysis module 520, the second analysis module 530, the self-learning modification module 540, and the transmission module 550 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the response module 510, the first analysis module 520, the second analysis module 530, the self-learning modification module 540, and the transmission module 550 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the response module 510, the first analysis module 520, the second analysis module 530, the self-learning modification module 540, and the transmission module 550 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0114] Figure 6 schematically illustrates a block diagram of an electronic device suitable for implementing a test fault handling method according to an embodiment of this application.

[0115] As shown in FIG6, an electronic device 600 according to an embodiment of the present application includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present application.

[0116] RAM 603 stores various programs and data required for the operation of electronic device 600. Processor 601, ROM 602, and RAM 603 are interconnected via bus 604. Processor 601 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 602 and / or RAM 603. It should be noted that the programs may also be stored in one or more memories other than ROM 602 and RAM 603. Processor 601 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0117] According to embodiments of this application, the electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output (I / O) interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output (I / O) interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0118] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0119] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 602 and / or RAM 603 and / or one or more memories other than ROM 602 and RAM 603 described above.

[0120] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the test fault handling method provided in the embodiments of this application.

[0121] When the computer program is executed by the processor 601, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0122] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0123] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by the processor 601, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0124] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0125] 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 a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may 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.

[0126] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A method for handling test faults, characterized in that, The method includes: responding to a business test request for a target business; determining an initial business scenario based on the business test request; determining a target business unit link and a target business success log based on the initial business scenario, wherein the target business unit link includes multiple test units and each test unit has a test time, and the target business success log represents the log of the most recent successful execution record under the business scenario; determining a faulty unit from the multiple test units based on the target business unit link, wherein the faulty unit is not the test unit with the latest test time; performing self-learning modification on the fault message information of the faulty unit based on the target business success log to obtain modified message information; and sending the modified message information to the downstream unit of the faulty unit to continue testing, wherein the downstream unit represents the next test unit of the faulty unit in the target business unit link.

2. The method according to claim 1, characterized in that, The step of determining the target business unit link and the target business success log based on the initial business scenario includes: obtaining a historical business scenario library, which stores multiple historical business scenarios, each of which stores a corresponding historical business unit link and a historical business log; determining a matching target business scenario from the multiple historical business scenarios based on the initial business scenario; determining the historical business unit link and the historical business log corresponding to the target business scenario from the historical business scenario library; and determining the target business unit link and the target business success log based on the historical business unit link and the historical business log.

3. The method according to claim 2, characterized in that, The historical service log includes historical message information; the method further includes updating the historical message information according to the modified message information.

4. The method according to claim 1, characterized in that, The step of determining the fault unit based on the target service unit link includes: running the target service unit link and obtaining the running result; and determining the test unit where the link interruption occurred based on the running result, and identifying the test unit as the fault unit.

5. The method according to claim 4, characterized in that, The process of running the target business unit link and obtaining the running results includes: establishing a running tracking view based on the target business unit link; and displaying the running results through the running tracking view.

6. The method according to claim 1, characterized in that... The step of self-learning and modifying the fault message information of the fault unit based on the target service success log includes: obtaining a responsible person relationship database, which stores multiple responsible person information, each of which corresponds to one test unit; determining a matching target responsible person information from the multiple responsible person information based on the fault unit; sending a runtime tracking view to the target responsible person corresponding to the target responsible person information, wherein the runtime tracking view is established based on the target service unit link; and, in response to receiving a processing instruction from the target responsible person, performing self-learning and modification of the first message information based on the processing instruction and the target service success log.

7. The method according to claim 5, characterized in that, The method further includes updating the runtime tracking view based on the modified message information.

8. The method according to claim 1, characterized in that, The target service success log includes success message information. The self-learning modification of the fault message information of the fault unit based on the target service success log further includes: modifying the key fields of the fault message information based on the key fields of the success message information; and setting the message data of the success message information as the message data of the fault message information.

9. A test fault handling device, characterized in that, The apparatus includes: a response module, configured to respond to a business test request of a target business and determine an initial business scenario based on the business test request; a first analysis module, configured to determine a target business unit link and a target business success log based on the initial business scenario, wherein the target business unit link includes multiple test units and each test unit is accompanied by a test time, and the target business success log represents the log of the most recent successful execution record under the business scenario; a second analysis module, configured to determine a faulty unit from the multiple test units based on the target business unit link, wherein the faulty unit is not the test unit with the latest test time; a self-learning modification module, configured to perform self-learning modification on the fault message information of the faulty unit based on the target business success log to obtain modified message information; and a transmission module, configured to send the modified message information to the downstream unit of the faulty unit to continue testing, wherein the downstream unit represents the next test unit of the faulty unit in the target business unit link.

10. An electronic device, comprising: One or more processors; A memory for storing one or more computer programs, characterized in that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

Images