Software fault positioning method, computer equipment and readable medium
Through AOP technology and business interception point record call information to generate fault location files, combined with unit testing technology, the problems of low fault location efficiency and environmental damage of existing software are solved, and fast and accurate fault location is achieved.
Patent Information
- Application Number
- CN202310781334.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-06-28
- Publication Date
- 2024-12-31
AI Technical Summary
Existing software fault location methods are inefficient, and using log location requires a lot of time and incomplete information. Remote debugging will damage the environment when reproducing a fault, resulting in failures that cannot be reproduced.
AOP technology is used to create business interception points during software operation, record call information from inbound to outbound, generate fault location files, and combine AOP and unit testing technology to locate faults to avoid guessing and experimental verification.
Fast and accurate software fault location is achieved, shortening fault location time, and avoiding inefficiency and environmental damage problems in traditional methods.
Smart Images
Figure CN119226122A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the technical field of software testing, and in particular to a software fault locating method, a computer device and a readable medium. Background Art
[0002] Commercial software systems are generally very complex. The complexity is reflected in complex business logic, complex software technology and complex runtime status. Once a failure occurs during runtime, it is difficult to quickly locate the cause of the failure.
[0003] There are two main types of software fault location methods at present: one is to use logs to locate software faults, and the other is to use remote debugging to locate software faults.
[0004] The solution of using logs to locate software faults is to locate software faults by searching logs, but the log volume is large and the log information is incomplete. Software fault location can only repeatedly guess the cause of the fault and repeatedly verify whether the guess is correct, which takes a lot of time and leads to low efficiency of software fault location. The solution of using remote debugging to locate software faults is that even if remote debugging is enabled after a fault occurs, the software needs to be restarted to make remote debugging effective, which will destroy the fault environment and make the fault unable to be reproduced. Summary of the invention
[0005] The present disclosure provides a software fault locating method, a computer device and a readable medium.
[0006] In a first aspect, an embodiment of the present disclosure provides a software fault locating method, including:
[0007] During the operation of the target software, first call information is obtained by using a pre-created business interception point; the first call information is information about calling a business class in the target software, each of the business interception points corresponds to each call boundary of the target software, and the call boundary includes an entry boundary and an exit boundary, the entry boundary is a position where other classes call the business class in the target software, and the exit boundary is a position where the business class in the target software calls other classes;
[0008] A fault location file is generated according to all the first call information from the entry boundary to the exit boundary, and the fault location file is used to locate the fault of the target software.
[0009] On the other hand, an embodiment of the present disclosure further provides a computer device, comprising: one or more processors; a storage device on which one or more programs are stored; when the one or more programs are executed by the one or more processors, the one or more processors implement the software fault location method as described above.
[0010] On the other hand, an embodiment of the present disclosure further provides a computer-readable medium having a computer program stored thereon, wherein the program, when executed, implements the software fault locating method as described above.
[0011] The software fault location method provided by the embodiment of the present disclosure includes: during the operation of the target software, using the pre-created business interception point to obtain the first call information; the first call information is the information of calling the business class in the target software, each business interception point corresponds to each call boundary of the target software, and the call boundary includes an entry boundary and an exit boundary, the entry boundary is the position where other classes call the business class in the target software, and the exit boundary is the position where the business class in the target software calls other classes; a fault location file is generated based on all the first call information from the entry boundary to the exit boundary, and the fault location file is used to locate the fault of the target software. The embodiment of the present disclosure can accurately locate the cause of the fault at one time, greatly shorten the software fault location time, and realize fast and easy location of software faults. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] Figure 1 Schematic diagram of software fault location process provided by the embodiment of the present disclosure Figure 1 ;
[0013] Figure 2 A schematic diagram of a call boundary provided for an embodiment of the present disclosure;
[0014] Figure 3 Schematic diagram of software fault location process provided by the embodiment of the present disclosure Figure 2 ;
[0015] Figure 4 A schematic diagram of a process for obtaining second call information according to a service interception point and a fault location file provided in an embodiment of the present disclosure;
[0016] Figure 5 A schematic diagram of a process for generating a fault location file provided in an embodiment of the present disclosure. DETAILED DESCRIPTION
[0017] Example embodiments will be described more fully below with reference to the accompanying drawings, but the example embodiments may be embodied in different forms and should not be construed as limited to the embodiments set forth herein. On the contrary, the purpose of providing these embodiments is to make the present disclosure thorough and complete and to enable those skilled in the art to fully understand the scope of the present disclosure.
[0018] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.
[0019] The terms used herein are only used to describe specific embodiments and are not intended to limit the present disclosure. As used herein, the singular forms "a", "an" and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It will also be understood that when the terms "comprising" and / or "made of" are used in this specification, the presence of the features, wholes, steps, operations, elements and / or components is specified, but the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or groups thereof is not excluded.
[0020] The embodiments described herein may be described with reference to plan views and / or cross-sectional views by means of idealized schematic diagrams of the present disclosure. Therefore, the example illustrations may be modified according to manufacturing techniques and / or tolerances. Therefore, the embodiments are not limited to the embodiments shown in the accompanying drawings, but include modifications of the configurations formed based on the manufacturing process. Therefore, the regions illustrated in the accompanying drawings have schematic properties, and the shapes of the regions shown in the figures illustrate the specific shapes of the regions of the elements, but are not intended to be limiting.
[0021] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by those of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and the present disclosure, and will not be interpreted as having an idealized or overly formal meaning unless explicitly defined as such herein.
[0022] In the related art, there is a solution for locating software faults using logs. Developers add log codes to print the software execution status in the business code. When the software is running, the runtime status is continuously output to the log file, and the log file is used to analyze the cause of the fault. This solution has the following disadvantages: a. It is difficult for developers to predict where the code will go wrong. The business code with the problem often does not add log codes, resulting in no logs to assist in locating the problem, or the log information recording the problem is incomplete. You can only spend a lot of time repeatedly guessing the cause of the fault and repeatedly verifying whether the guess is correct. b. Runtime logs are generated very frequently, and the logs recording the problem are easily and quickly overwhelmed. Finding the fault requires repeated searching of the summary logs, resulting in very low fault location efficiency.
[0023] The solution of using remote debugging to locate software faults is to use the remote debugging function provided by the development language to analyze faults. It is a common fault location method during internal development. This solution has the following disadvantages: a. Remote debugging is not allowed for commercial software. b. If it is a development environment or test environment shared by multiple people, remote debugging will not be enabled because it will affect other people's use. Even if remote debugging is enabled after a fault occurs, the software needs to be restarted for remote debugging to take effect, which will destroy the fault environment and make the fault unable to be reproduced.
[0024] In order to solve the above problems, an embodiment of the present disclosure provides a software fault location method, which adopts AOP (Aspect Oriented Programming) technology to locate faults in the target software. AOP technology realizes unified maintenance of program functions through precompilation and dynamic proxy during runtime.
[0025] like Figure 1 As shown, the software fault locating method comprises the following steps:
[0026] Step S11, during the operation of the target software, the first call information is obtained by using the pre-created business interception point; the first call information is the information of calling the business class in the target software, each business interception point corresponds to each call boundary of the target software, and the call boundary includes an entry boundary and an exit boundary. The entry boundary is the position where other classes call the business class in the target software, and the exit boundary is the position where the business class in the target software calls other classes.
[0027] The embodiment of the present disclosure provides a simple and convenient fault information recording method, that is, recording logs at a call boundary, where the call boundary includes an inbound boundary and an outbound boundary. Figure 2 A schematic diagram of a call boundary provided for an embodiment of the present disclosure, such as Figure 2 As shown, the target software includes multiple business classes. Figure 2 The target software shown includes business class A, business class B, business class C and business class D. There is a calling relationship between the business classes according to the business process of the target software. Figure 2 Indicated by arrows. Other classes refer to classes of functional modules of other systems outside the target software. For example, other classes may be classes of data modification modules of a database. Figure 2 As shown, the location where class X of other module A calls business class A of the target software is the entry boundary of the target software, the location where business class B in the target software calls class Y of other module B is an exit boundary of the target software, and the location where business class C in the target software calls class Z of other module C is another exit boundary of the target software.
[0028] The service interception point is created at the initialization node of the target software. There are multiple service interception points, and one service interception point corresponds to an entry boundary or an exit boundary of the target software.
[0029] In this step, the user starts recording. There are many ways for the user to enable recording, such as enabling recording through a configuration file. The system reads the configuration file at intervals (such as 1 minute) and decides whether to enable recording based on the configuration file. Then, AOP technology is used to obtain the first call information using the business interception point. After the user enables recording, if the business operation triggers the business interception point, the call boundary information (including class name, method name, call parameters and their types, return value and its type, exception and its type) process is recorded, and finally the complete call information of an operation is obtained, that is, all the first call information from the entry boundary to the exit boundary. The first call information may include information such as the class name, method name, input parameters and their types, return value and its type, exception and its type.
[0030] Step S12, generating a fault location file according to all the first call information from the entry boundary to the exit boundary, wherein the fault location file is used to locate the fault of the target software.
[0031] In this step, all the first call information obtained in step S11 are summarized, and each of the summarized first call information is used to generate a fault location file in a preset format. If the target software has an entry boundary and / or an exit boundary fault, such as an entry boundary call parameter error or an exit boundary return value error, the software fault can be located by directly reading the first call information recorded in the fault location file.
[0032] In some embodiments, the format of the fault location file may be in JSON (JavaScript Object Notation) format. JSON is a lightweight data exchange format that uses a text format that is completely independent of the programming language to store and represent data. It has the characteristics of good readability and is conducive to software developers to quickly locate faults. It should be noted that the format of the fault location file is not limited to the JSON format. For example, it may also be in XML format. In the embodiments of the present disclosure, a fault location file in JSON format is used as an example for description.
[0033] The software fault location method provided by the embodiment of the present disclosure includes: during the operation of the target software, using the pre-created business interception point to obtain the first call information; the first call information is the information of calling the business class in the target software, each business interception point corresponds to each call boundary of the target software, and the call boundary includes an entry boundary and an exit boundary, the entry boundary is the position where other classes call the business class in the target software, and the exit boundary is the position where the business class in the target software calls other classes; a fault location file is generated according to all the first call information from the entry boundary to the exit boundary, and the fault location file is used to locate the fault of the target software. The embodiment of the present disclosure does not need to adopt the traditional "guessing the cause of the fault + experimental verification" processing method, and can accurately locate the cause of the fault at one time, greatly shorten the software fault location time, and realize fast and easy location of software faults.
[0034] In some embodiments, the fault location file is used to locate the boundary entry and / or boundary exit faults of the target software. Figure 3 As shown, after generating a fault location file according to all the first call information from the entry boundary to the exit boundary (i.e., step S12), the software fault location method may further include the following steps:
[0035] Step S13, when the fault location file cannot be used to locate the target software fault, simulate the operation of the target software's service code, and in the process of simulating the operation of the target software's service code, obtain the second call information according to the service interception point and the fault location file.
[0036] In this step, the target software can be simulated in the simulation system, and the return value of the corresponding call boundary can be obtained by using the business interception point during the simulation. The return value is the second call information to achieve software playback. That is, when the code is executed to the call boundary, the business interception point uses the return value recorded in the JSON file to simulate the return of other modules to the business module. Specifically, the real execution process of the software can be replayed by combining AOP technology, unit testing technology (such as JUnit) and fault location files. The local debugging function of the development language can be used to track the execution of each step of the target software to obtain the second call information.
[0037] Step S14: locating the fault of the target software according to the second calling information.
[0038] By analyzing the second call information, the fault can be located quickly and accurately.
[0039] If the target software cannot be fault-located according to the fault location file, it means that the fault in the target software is a non-call boundary fault, such as a business logic error, which cannot be located by the fault location file. In this case, the software fault can be further located by replaying the fault information, that is, the user sets the current state to playback. In the playback state, the business interception point no longer calls other corresponding modules, but directly simulates the operation of the target software using the return value or exception information recorded in the JSON file.
[0040] In some embodiments, Figure 4 As shown, the simulation runs the business class code of the target software, and in the process of simulating the business class code of the target software, obtains the second call information according to the business interception point and the fault location file (i.e., step S13), including the following steps:
[0041] Step S131, creating a call boundary execution queue according to the fault location file, each element in the call boundary execution queue is all the second call information from the entry boundary to the exit boundary.
[0042] In some embodiments, the character string of the fault location file is deserialized to obtain the second call information, and a call boundary execution queue is generated according to the second call information. Specifically, the fault location file in JSON format can be parsed using Gson and FastJson technologies, and the JSON string can be deserialized into the second call information as the target software runtime object. The second call information in the call boundary execution queue is arranged in the call order from the entry boundary to the exit boundary.
[0043] The second call information may include information such as class name, method name, input parameters and their types, return value and its type, exception and its type, etc.
[0044] Step S132, obtaining the boundary entry call parameters, and using the boundary entry call parameters to trigger the execution of the business class code of the target software.
[0045] Get the boundary call parameters and use them as input parameters for the playback execution process. With the help of unit testing technology, such as JUnit, use the boundary call parameters to trigger the running of business class code.
[0046] Step S133, during the operation of the business class code, the second call information satisfying the playback condition in the call boundary execution queue is obtained according to the business interception point.
[0047] The playback conditions include one or any combination of the following: class name, method name, and calling parameter type.
[0048] In some embodiments, during the operation of the target software, before obtaining the first call information (i.e., step S11) using the pre-created service interception point, the process also includes setting the call boundary of the target software and creating the service interception point according to the call boundary. The call boundary of the target software and the creation of the service interception point can be set during the initialization of the target software.
[0049] In some embodiments, setting the call boundary of the target software includes: setting the call boundary of the target software according to a boundary configuration file, or setting the call boundary of the target software by means of code annotation.
[0050] When the target software system starts, the target software is initialized. During the initialization process, the call boundary of the target software is set. There are two ways to set the call boundary: one is to set the call boundary using a configuration file. Users can configure the class name + method name of the call boundary in the configuration file; the other is to set the call boundary of the target software through code annotations, such as the Java Annotation method, adding @Record to the method of the call boundary class. The JavaAnnotation format is @XXX, which annotates the code without affecting the business code. The annotation can be used by the Java interpreter during compilation or runtime. Using the Java Annotation method or the configuration file method to set the call entry and exit boundaries does not require developers to write additional log code, and is easy to use.
[0051] In some embodiments, creating a service interception point according to a call boundary includes: determining a target service class for which a service interception point needs to be created according to a boundary configuration file and / or an annotation code of the call boundary, and creating a service interception point for the target service class.
[0052] In the process of initializing the business class in the target software, the AOP technology is used to create a business interception point for each target business class. The business interception point can be created for each target business class by traversing the boundary configuration file alone, or by traversing the annotation code of the call boundary alone, or by combining traversing the boundary configuration file with traversing the annotation code of the call boundary.
[0053] In some embodiments, Figure 5 As shown, the generation of the fault location file according to all the first call information from the entry boundary to the exit boundary (i.e., step S12) includes the following steps:
[0054] Step S121: Cache the first call information into the memory according to the thread.
[0055] Since the system has concurrent call problems, such as an operation being called by multiple threads at the same time, in order to ensure that the records are not confused, the execution thread can be used to cache the first call information. For example, in Java development, ThreadLocal (thread local variable) can be directly used to implement it.
[0056] Step S122, when the service interception point obtains the return value at the input boundary, after the target software is finished running, the first call information is obtained from the memory according to the thread, and a fault location file is generated according to the first call information.
[0057] If the service interception point obtains the return value at the entry boundary, it means that a complete call process from the entry boundary to the exit boundary is completed. After the target software runs, the first call information cached by the thread is written into the file in JSON format, thereby generating a fault location file in JSON format. For example, Gson, FastJson and other technologies can be used to serialize the call parameters, return values and exception information into JSON objects.
[0058] The solution of the embodiment of the present disclosure is implemented based on the AOP technology. All software supporting the AOP technology can use the software fault location method of the embodiment of the present disclosure to locate faults.
[0059] The disclosed embodiment proposes the concept of "call boundary", uses AOP technology to create a business interception point according to the call boundary set by the user, and after the user starts recording, uses the business interception point to record the call information (including class name, method name, call parameters and their types, return value and its type, exception and its type) at the call boundary, and generates a fault location file in JSON format with the complete call information of a business call. Then, by combining AOP technology, call boundary configuration, unit testing technology and fault location file, the execution process of the software can be replayed in the development environment, and the local debugging function provided by the development language can be used to accurately locate the cause of the fault. There is no need to adopt the previous processing method of "guessing the cause of the fault + experimental verification", and the cause of the fault can be accurately located at one time, greatly shortening the fault location time.
[0060] The embodiments of the present disclosure also provide a computer device, which includes: one or more processors and a storage device; wherein one or more programs are stored on the storage device, and when the one or more programs are executed by the one or more processors, the one or more processors implement the software fault location method provided in the aforementioned embodiments.
[0061] The embodiments of the present disclosure further provide a computer-readable medium on which a computer program is stored, wherein when the computer program is executed, the software fault locating method provided in the aforementioned embodiments is implemented.
[0062] It will be appreciated by those skilled in the art that all or some of the steps in the method disclosed above, the functional modules / units in the device may be implemented as software, firmware, hardware, and appropriate combinations thereof. In hardware implementations, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some physical components or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium). As known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those of ordinary skill in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.
[0063] Example embodiments have been disclosed herein, and although specific terms are employed, they are used and should be interpreted only in a general illustrative sense and not for limiting purposes. In some instances, it will be apparent to those skilled in the art that, unless otherwise expressly stated, features, characteristics, and / or elements described in conjunction with a particular embodiment may be used alone or in combination with features, characteristics, and / or elements described in conjunction with other embodiments. Therefore, it will be understood by those skilled in the art that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.
Claims
1. A software fault location method, characterized in that: include: During the operation of the target software, the first call information is obtained by using the pre-created service interception point; The first call information is information about calling a service class in the target software, each of the service interception points corresponds to each call boundary of the target software, and the call boundary includes an entry boundary and an exit boundary, the entry boundary is a position where other classes call the service class in the target software, and the exit boundary is a position where the service class in the target software calls other classes; A fault location file is generated according to all the first call information from the entry boundary to the exit boundary, and the fault location file is used to locate the fault of the target software.
2. The method according to claim 1, characterized in that The fault location file is used to locate the boundary entry and / or boundary exit fault of the target software. After the fault location file is generated according to all the first call information from the boundary entry to the boundary exit, the method further includes: In the case where the fault location of the target software cannot be located according to the fault location file, simulating the operation of the service class code of the target software, and obtaining second call information according to the service interception point and the fault location file during the process of simulating the operation of the service class code of the target software; The target software is fault located according to the second calling information.
3. The method according to claim 2, characterized in that The simulating operation of the service class code of the target software and obtaining the second call information according to the service interception point and the fault location file during the simulating operation of the service class code of the target software include: Creating a call boundary execution queue according to the fault location file, each element in the call boundary execution queue is all the second call information from the entry boundary to the exit boundary; Acquire an entry boundary call parameter, and use the entry boundary call parameter to trigger the execution of the business class code of the target software; During the operation of the business class code, second call information satisfying the playback condition in the call boundary execution queue is obtained according to the business interception point.
4. The method according to claim 3, characterized in that The playback condition includes one or any combination of the following: class name, method name, and calling parameter type.
5. The method according to claim 3, characterized in that The step of creating a call boundary execution queue according to the fault location file includes: Performing a reverse sequence operation on the character string of the fault location file to obtain the second call information; A call boundary execution queue is generated according to the second call information.
6. The method according to claim 1, characterized in that During the operation of the target software, before obtaining the first call information by using the pre-created service interception point, the method further includes: Set the call boundary of the target software and create a service interception point according to the call boundary.
7. The method according to claim 6, characterized in that The step of setting the call boundary of the target software includes: The calling boundary of the target software is set according to a boundary configuration file, or the calling boundary of the target software is set by code annotation.
8. The method according to claim 7, characterized in that The creating a service interception point according to the call boundary includes: The target business class for which a business interception point needs to be created is determined according to the boundary configuration file and / or the annotation code of the calling boundary, and a business interception point is created for the target business class.
9. The method according to claim 1, characterized in that The generating of the fault location file according to all the first call information from the entry boundary to the exit boundary includes: Cache the first call information into the memory according to the thread; In the case where the service interception point obtains the return value at the input boundary, after the target software is finished running, the first call information is obtained from the memory according to the thread, and the fault location file is generated according to the first call information.
10. The method according to any one of claims 1 to 9, characterized in that: The format of the fault location file is JSON format.
11. A computer device, wherein: include: one or more processors; a storage device having one or more programs stored thereon; When the one or more programs are executed by the one or more processors, the one or more processors implement the software fault locating method according to any one of claims 1 to 10.
12. A computer readable medium having a computer program stored thereon, wherein: When the program is executed, the software fault locating method according to any one of claims 1 to 10 is implemented.