CN111258901B - Fault positioning method and system for micro-service combination program - Google Patents
Fault positioning method and system for micro-service combination program Download PDFInfo
- Publication number
- CN111258901B CN111258901B CN202010051172.7A CN202010051172A CN111258901B CN 111258901 B CN111258901 B CN 111258901B CN 202010051172 A CN202010051172 A CN 202010051172A CN 111258901 B CN111258901 B CN 111258901B
- Authority
- CN
- China
- Prior art keywords
- test case
- micro
- service
- microservice
- case set
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3692—Test management for test results analysis
Abstract
The invention provides a fault positioning method and a system of a micro-service combination program, wherein the method comprises the following steps: acquiring micro-service information in the micro-service combination program to be tested based on API description document information of the micro-service combination program to be tested; acquiring an execution result of the test case set; acquiring an execution track set of a test case set based on a monitoring information file of the microservice; based on the micro-service information in the micro-service combination program to be tested, calculating the suspicion degree of each micro-service according to the execution result and the execution track set of the test case set; and sequencing the micro-services in the combined program of the to-be-tested micro-services according to the suspicion degree, screening out the micro-services with the suspicion degree exceeding a preset value, obtaining a high-suspicion degree micro-service set, and generating a fault positioning report. The fault positioning method can improve the efficiency of fault positioning of the micro-service combination program and reduce the difficulty of fault positioning of the micro-service combination program.
Description
Technical Field
The invention relates to the technical field of software testing, in particular to a method and a system for positioning faults of a micro-service combination program.
Background
Micro service Architecture (micro service Architecture) has attracted increasing attention in recent years as a new software Architecture. Under the Microservice architecture, a complex software system consists of a set of single-role microservices (microservices). Each micro service runs in an independent process and can realize automatic independent deployment through an automatic deployment mechanism; communication between the micro services is realized through RPC, HTTP and other lightweight interaction mechanisms.
Compared with a single-body architecture, the micro-service architecture has the advantages of single function, flexible technology type selection, independent component deployment, continuous delivery, strong fault tolerance capability, capability of expanding as required and the like. Meanwhile, the development of the distributed storage technology, the Web container virtualization technology, the big data cloud computing technology and the server cluster technology provides technical support for the implementation of the micro-service architecture. The micro-service architecture is widely applied to the construction of various distributed software systems, and the sharing and integration of various resources in an open network environment are realized.
Compared with the traditional program, the micro-service combination program has the following new characteristics:
1. the micro-services in the micro-service combination program are numerous and have complex dependency relationship; under the condition that the micro-service system is frequently updated, a large number of micro-service instances and the dependency relationship among the micro-service instances are continuously changed;
2. the calling relation among all the micro services in the micro service combination program is complex, and when one micro service fails, the influence of the failure can be continuously diffused along the calling relation;
3. the micro-services constituting the micro-service combination program can be realized by a plurality of languages;
4. each microservice in a microservice combining program is operationally independent of other services, and the only form of communication between services is through its published interface, it is difficult to obtain the specific code of each microservice.
The above features make debugging of the microserver combo facing new challenges. There are many reasons for causing the micro-service combination program to malfunction, such as software design defects, code problems, configuration errors, and the like. The failure may cause the micro-service behavior to be abnormal, which is represented as request failure, response delay, and the like. Because the microservice combining procedure is different from the traditional procedure, the existing fault positioning method is difficult to be directly used for positioning the microservice combining procedure.
Disclosure of Invention
The technical problem to be solved by the present invention is to provide a method and a system for positioning a fault of a micro-service combination program, so as to solve the problem of difficulty in positioning the fault of the micro-service combination program, improve the efficiency of positioning the fault of the micro-service combination program, and reduce the difficulty in positioning the fault of the micro-service combination program.
In order to solve the technical problems, the invention provides the following technical scheme:
a method of fault location for a microservice assembly program, the method comprising:
acquiring micro-service information in a micro-service combination program to be tested based on API description document information of the micro-service combination program to be tested;
acquiring an execution result of the test case set;
acquiring an execution track set of the test case set based on a monitoring information file of the micro service;
based on the micro-service information in the micro-service combination program to be tested, calculating the suspicion degree of each micro-service according to the execution result and the execution track set of the test case set;
and sequencing the micro-services in the micro-service combination program to be tested according to the suspicion degree, screening out the micro-services with the suspicion degree exceeding a preset value, obtaining a high suspicion degree micro-service set, and generating a fault positioning report.
Further, the acquiring micro-service information in the micro-service combination program to be tested includes:
acquiring instance information of all micro services in an API description document of the micro service combination program to be tested, and analyzing to obtain all micro services in the micro service combination program to be tested; the micro service instance information comprises names, hosts and port registries of corresponding micro services;
acquiring all gateway microservices and functional microservices in the microservice combined program to be detected to obtain a front-end gateway set, a rear-end gateway set and a functional microservice set; the functional micro-service is a small functional block focusing on single responsibility and function in the micro-service combination program to be tested.
Further, the obtaining of the execution result of the test case suite includes:
numbering each test case in the selected test case set in sequence;
reading the test cases from the test case set in sequence;
marking the micro service set execution track coverage condition, and judging the execution result of each test case.
Further, the marking of the trace coverage condition by the microservice set includes:
judging whether the test case t passes through multi-instance microservice or not;
if the test case t passes through the multi-instance microservice, acquiring the number m of the instances of the multi-instance microservice;
executing the test case t m times, and if all the test cases fail after the test case t is executed m times, judging that the multi-instance microservice has a fault; and if the part of the test case t fails after the test case t is executed for m times, judging that a certain instance in the multi-instance microservice has a fault.
Further, the determining the execution result of each test case includes:
obtaining the actual output result of each test case in the micro-service combination program to be tested;
obtaining an expected output result of a current test case in the micro-service combination program to be tested;
judging whether the actual output result of the current test case is consistent with the expected output result;
if the actual output result is inconsistent with the expected output result, judging that the execution result of the current test case is failure, and adding the current test case into a failure test case set;
and if the actual output result is consistent with the expected output result, judging that the execution result of the current test case is successful, and adding the current test case into a successful test case set.
Further, the obtaining of the execution trajectory set of the test case set includes:
analyzing the monitoring information file;
obtaining an execution track set after the test case set is executed according to the execution track information of each test case recorded in the monitoring information file;
and collecting and recording the calling track situation among each microservice.
Further, the calculating the suspicion degree of each micro service according to the execution result and the execution trajectory set of the test case set based on the micro service information in the micro service combination program to be tested includes:
when the execution track of the test case t passes through the front-end gateway service, the front-end gateway service is regarded as the functional microservice; when the execution track of the test case t passes through the back-end gateway service, recording the frequency of the back-end gateway service appearing in the execution track corresponding to the test case t as 1 time;
and calculating the suspicion degree of each micro service according to the frequency difference of the successful test case set and the failed test case set in the micro service calling relation.
Further, the calculating the suspicion degree of each micro service according to the frequency difference of the successful test case set and the failed test case set in the micro service call relation includes:
calculating the frequency of the successful test case set passing through different calling edges of the microservice S by using a formula (1):
wherein p istiFrequency, x, representing successful test case set passing through the ith call edge of the microservice SettiRepresenting the number of times, x, that a successful test case set passes through the ith calling edge of the microservice StkRepresenting the times of the successful test case set passing through the kth calling edge of the microservice S;
calculating the frequency of the failed test case set passing through different calling edges of the microservice S by using a formula (2):
wherein p isfiFrequency, x, representing the frequency of failed test case sets passing through the ith call edge of the microservice SfiRepresenting the number of times, x, that the failed test case set passes through the ith calling edge of the microservice SfkRepresenting the times of the failed test case set passing through the kth calling edge of the microservice S;
obtaining the frequency density P of the successful test case set passing through different calling edges of the microservice St＝(pt1,pt2,…,ptn) Frequency density P of different calling edges of failure test case set through microservice Sf＝(pf1,pf2,…,pfn)；
Calculating P using equation (3)tAnd PfSimilarity of (A) SimE (P)t,Pf) A 1 is to PtAnd PfSimilarity of (A) SimE (P)t,Pf) Suspicion as microservice S:
wherein p istkFrequency, p, representing successful test case set passing through the kth calling edge of the microservice SfkTo representAnd the frequency of the failed test case set passing through the kth calling edge of the microservice S.
Further, sorting the micro-services in the combined program of the to-be-tested micro-services according to the suspicion degree, selecting the micro-services with the suspicion degree exceeding a preset value to obtain a high-suspicion degree micro-service set, and generating a fault positioning report, wherein the method comprises the following steps:
sorting the micro-services in the combined program of the services to be tested in a descending order according to the suspicion degree;
and selecting the micro-services with the suspicion degree exceeding a preset value and the example information thereof to generate a fault positioning report.
Accordingly, in order to solve the above technical problems, the present invention further provides the following technical solutions:
a fault location system for a microservice assembly program, the system comprising:
the micro-service information acquisition module is used for acquiring micro-service information in the micro-service combination program to be detected based on API description document information of the micro-service combination program to be detected;
the test case execution result acquisition module is used for acquiring the execution result of the test case set;
the test case execution track set acquisition module is used for acquiring an execution track set of the test case set based on a monitoring information file of the micro service;
the suspicion degree calculation module is used for calculating the suspicion degree of each micro service according to the execution result and the execution track set of the test case set based on the micro service information in the micro service combination program to be tested;
and the fault positioning report generating module is used for sequencing the micro-services in the micro-service combination program to be tested according to the suspicion degree, screening out the micro-services with the suspicion degree exceeding a preset value, obtaining a high suspicion degree micro-service set and generating a fault positioning report.
The technical scheme of the invention has the following beneficial effects:
the method for positioning the fault of the micro-service combination program considers the characteristics of multi-instance micro-service and gateway micro-service, and calculates the suspicion degree from the angle of acquiring the execution track information and utilizing the frequency difference of the successful test cases and the failed test cases in the micro-service calling relation. Therefore, the method and the device can improve the efficiency of positioning the faults of the micro-service combination program and reduce the difficulty of positioning the faults of the micro-service combination program.
Drawings
Fig. 1 is a flowchart of a method for locating a fault of a microservice component program according to an embodiment of the present invention;
FIG. 2 is a schematic diagram of a fault location tool of the microservice assembly process;
fig. 3 is a list of all micro-services in the micro-service composition program MS;
fig. 4 is a diagram of an execution trace of the microserver MS.
Detailed Description
In order to make the technical problems, technical solutions and advantages of the present invention more apparent, the following detailed description is given with reference to the accompanying drawings and specific embodiments.
First embodiment
Referring to fig. 1, the present embodiment provides a method for locating a fault of a micro service combination program, where the method for locating a fault of a micro service combination program includes:
s101, acquiring micro-service information in the micro-service combination program to be tested based on API description document information of the micro-service combination program to be tested;
specifically, in this embodiment, S101 specifically is:
acquiring instance information (including names, hosts and port registries of corresponding micro services) of all micro services in an API description document of the micro service combination program to be tested, and analyzing to obtain all the micro services in the micro service combination program to be tested; acquiring all gateway micro-services and functional micro-services in a micro-service combination program to be tested to obtain a front-end gateway set, a back-end gateway set and a functional micro-service set; the functional micro-services refer to small functional blocks of the micro-service combination procedure to be tested, which focus on single responsibility and function.
S102, obtaining an execution result of the test case set;
specifically, in this embodiment, S102 specifically is:
numbering each test case in the selected test case set in sequence; reading the test cases from the test case set in sequence; judging whether the test case t passes through multi-instance microservice or not; if the test case t passes through the multi-instance microservice, acquiring the number m of the instances of the multi-instance microservice; executing the test case t m times, and if all the test cases fail after the test case t is executed m times, judging that the multi-instance microservice has a fault; if the part of the test case t fails after the test case t is executed for m times, judging that a certain instance in the multi-instance microservice has a fault; marking the micro service set execution track coverage condition, and judging the execution result of the test case t.
Further, the judgment of the execution result of the test case t specifically includes:
obtaining the actual output result of each test case in the micro-service combination program to be tested; obtaining an expected output result of the current test case in the micro-service combination program to be tested; judging whether the actual output result of the current test case is consistent with the expected output result; if the actual output result is inconsistent with the expected output result, judging that the execution result of the current test case is failure, and adding the current test case into a failure test case set; and if the actual output result is consistent with the expected output result, judging that the execution result of the current test case is successful, and adding the current test case into a successful test case set.
S103, acquiring an execution track set of the test case set based on the monitoring information file of the micro service;
specifically, in this embodiment, S103 specifically is: analyzing the monitoring information file; acquiring a test case execution track set; collecting and recording the calling track condition among each microservice;
the method for analyzing the monitoring information file specifically comprises the following steps: the test case execution track set can be obtained by executing the test case set, each microservice in the microservice combination program to be tested is provided with a monitoring plug-in, and each time the test case is executed, the request and response messages among the microservices can be obtained from the monitoring plug-ins, and finally a monitoring information file in a json format is generated.
The method for acquiring the test case execution track set specifically comprises the following steps: and obtaining the execution track of each test case according to the content in the monitoring information file, wherein the monitoring information file contains information about the execution track of each test case, so that an execution track set after the test case set is executed can be obtained. Each test case corresponds to a traceID, the execution sequence of each microservice is analyzed according to the sequence of the traceID and the execution time, execution track information after the test case is executed can be obtained, a plurality of execution tracks can be obtained after the test case is executed for a plurality of times, and therefore a test case execution track set is obtained.
S104, calculating the suspicion degree of each micro service according to the execution result and the execution track set of the test case set based on the micro service information in the micro service combination program to be tested;
specifically, in this embodiment, S104 specifically is: processing the information of the gateway microservice; calculating the suspicion degree of the micro service by using the frequency difference of the successful test cases and the failed test cases in the micro service calling relation;
the method for processing the information of the gateway microservice specifically comprises the following steps: when the execution track of the test case t passes through the front-end gateway service, the front-end gateway service is regarded as the functional microservice; when the execution track of the test case t passes through the back-end gateway service, recording the frequency of the back-end gateway service appearing in the execution track as 1;
the method for calculating the suspicion degree of the micro service by using the frequency difference of the successful test cases and the failed test cases in the micro service calling relation specifically comprises the following steps: for one micro service in the micro service combination program, if the frequency of the micro service for calling other micro services triggered by a successful test case and a failed test case is different, the micro service may have a fault; the larger the difference, the greater the likelihood of failure of the microservice. In order to measure the difference, micro-service examples passed by the success test cases and the failure test cases and execution track information can be used, and the suspicion degree of each micro-service is calculated by adopting a method based on the frequency difference of the micro-service calling relation between the success test cases and the failure test cases, wherein the calculation process is as follows:
firstly, counting the times of the successful test case set and the failed test case set passing through the same calling side of a micro service, and dividing the times by the different times of the successful test case set and the failed test case set passing through the micro service to obtain different frequencies of the successful test case set and the failed test case set on one calling side of the micro service. And then, collecting all successful test case sets and failed test case sets about the frequencies of different calling edges of the micro-service, and obtaining the frequency density of the successful test case sets and the failed test case sets on the micro-service. And finally, calculating the frequency density difference of calling other micro services on a certain micro service by using a similarity calculation formula for the successful test case set and the failed test case set, wherein the larger the difference is, the more possible faults exist.
For the calculation of the similarity, Euclidean is adopted in the embodiment, and is a classic measurement formula for calculating the similarity between two groups of data, and can be used for comparing the frequency density of successful test cases and failed test cases which are displayed on one micro-service to call other micro-services. Therefore, in this embodiment, an Euclidean method is selected to calculate and sort the similarity of the frequency density of each calling relationship of the successful test case and the failed test case through the microservice, and the calculation process is as follows:
calculating the frequency of the test case set passing through different calling edges of a certain microservice by using a formula (1):
wherein x isiRepresenting the number of times, x, that the test case passes the ith call edgekRepresenting the times of the test case passing the k-th calling edge;
calculating the frequency of the successful test case set passing through different calling edges of the microservice S by using a formula (2):
wherein p istiFrequency, x, representing successful test case set passing through the ith call edge of the microservice SettiRepresenting the number of times, x, that a successful test case set passes through the ith calling edge of the microservice StkRepresenting the times of the successful test case set passing through the kth calling edge of the microservice S;
calculating the frequency of the failed test case set passing through different calling edges of the microservice S by using a formula (3):
wherein p isfiFrequency, x, representing the frequency of failed test case sets passing through the ith call edge of the microservice SfiRepresenting the number of times, x, that the failed test case set passes through the ith calling edge of the microservice SfkRepresenting the times of the failed test case set passing through the kth calling edge of the microservice S;
obtaining the frequency density P of the successful test case set passing through different calling edges of the microservice St＝(pt1,pt2,…,ptn) Frequency density P of different calling edges of failure test case set through microservice Sf＝(pf1,pf2,…,pfn)；
Calculating P using equation (4)tAnd PfSimilarity of (A) SimE (P)t,Pf) A 1 is to PtAnd PfSimilarity of (A) SimE (P)t,Pf) Suspicion as microservice S:
wherein p istkFrequency, p, representing successful test case set passing through the kth calling edge of the microservice SfkIndicating the frequency of the failed test case set passing through the kth calling edge of the microservice S.
S105, sequencing the micro-services in the combined program of the to-be-tested micro-services according to the suspicion degree, screening out the micro-services with the suspicion degree exceeding a preset value, obtaining a high-suspicion degree micro-service set, and generating a fault positioning report.
Specifically, in this embodiment, S105 specifically is:
according to the fault positioning method based on the frequency difference of the successful test cases and the failed test cases in the micro-service calling relation, the suspicion degree of each micro-service in the micro-service combination program to be tested can be obtained, the suspicion degrees of the micro-services are sorted in a descending order, part of the micro-services with higher suspicion degrees and example information thereof are selected, a fault positioning report is generated, and a positioning result is output.
Based on the above, as shown in fig. 2, a further detailed description is given below to a fault location method of a micro-service combination program provided in this embodiment by taking a micro-service combination program "bookmanager" (MS) and a fault location tool as an example, where the method includes:
step 1, firstly, obtaining an API description document of a BookManage micro-service combination program, obtaining a micro-service interface to be tested of the BookManage micro-service combination program from the API specification description document of the BookManage micro-service combination program through information obtaining, and obtaining whether the BookManage micro-service combination program has multi-instance micro-services and gateway micro-services, wherein interface information of the micro-service combination program to be tested is http:// localhost: auth/account { (id }) } name } ", two request parameters are id and name, the parameter type of id is int, the parameter type of name is String, and the request mode of the interface is GET.
Step 2, numbering each test case T in the selected test case set T in sequence; reading the test cases t from the selected test case set in sequence, judging whether the test cases t pass through multi-instance microservice, and knowing that the BookManage microservice combination program does not have the multi-instance microservice according to the API specification document, so that the multi-instance microservice does not need to be executed for multiple times; marking micro-service and executing track coverage conditions; and judging the actual output result of t.
The specific method for judging the actual output result of t comprises the following steps: and comparing the actual output with the expected output to obtain an output result set, if the output of the test case after being executed is the same as the expected result, representing the output result as 'true #', and otherwise representing the output result as 'false #', and dividing the output result set into a successful test case result set and a failed test case result set according to the success or failure result.
Step 3, analyzing the monitoring information file; acquiring a test case execution track set; collecting and recording the calling track condition among each microservice;
the specific method for analyzing the monitoring information file comprises the following steps: a json format document can be obtained according to the information monitored and obtained from each micro-service, as shown in fig. 3, the document is a part of the document, the document records the order of initiating call and response of each micro-service, which micro-service passes through the same execution track can be obtained according to the execution track "traceId", the order of executing each micro-service can be known according to the timestamp "timetag", and the name of each micro-service can be known according to the name "serviceName". Execution track information is obtained by processing the json format document, each value in the execution track represents the name of the micro service, the names of the micro services are distinguished and clear conveniently, each micro service is separated by a "#", and a part of execution track set obtained after the fault version program executes the test case set T is shown in fig. 4.
Step 4, processing gateway microservice information; and calculating the suspicion degree of the micro service by using the frequency difference of the successful test cases and the failed test cases in the micro service calling relation. The specific method for processing the information of the gateway microservice comprises the following steps: since only one front-end gateway microservice exists in the BookManage microservice combination program, the front-end gateway service is regarded as a functional microservice.
And carrying out suspicion degree sequencing on each micro-service according to the frequency difference of the successful test cases and the failed test cases in the micro-service calling relation and a formula in the execution track fault positioning. If a fault location algorithm based on statistical analysis is used, the times of different calling relations of the micro-service in the failure execution track set and the success execution track set are counted firstly, the frequencies of the different calling relations of the micro-service in the failure execution track set and the success execution track set are obtained according to a method based on statistical analysis, then the suspicion degree of the micro-service is calculated according to a similarity calculation formula, and the calculated suspicion degree of the micro-service is obtained as shown in the following table 1.
TABLE 1 micro service suspicion
| Micro-services | Degree of doubt |
| book | 0.57 |
| user | 8.54 |
| auth | 0.23 |
| manager | 0.00 |
| unregister | 0.00 |
| add | 0.00 |
| register | 0.00 |
| borrow | 0.00 |
| message | 0.00 |
And 5, obtaining the suspicion degree of each micro service in the micro service combination program to be tested according to the fault positioning method based on the frequency difference of the successful test cases and the failed test cases in the micro service calling relation, sequencing the suspicion degrees of the micro services in a descending order, selecting partial micro services with higher suspicion degrees and example information thereof, generating a fault positioning report, and outputting a positioning result.
The method for positioning the fault of the micro-service combination program in the embodiment considers the characteristics of the multi-instance micro-service and the gateway micro-service, and calculates the suspicion degree from the angle of acquiring the execution track information and based on the frequency difference of the micro-service calling relation between the successful test case and the failed test case. Therefore, the method can improve the efficiency of positioning the micro-service combination program fault and reduce the difficulty of positioning the micro-service combination program fault.
Second embodiment
The present embodiment provides a system for locating a fault of a microservice combined program, where the system includes:
the micro-service information acquisition module is used for acquiring micro-service information in the micro-service combination program to be detected based on API description document information of the micro-service combination program to be detected;
the test case execution result acquisition module is used for acquiring the execution result of the test case set;
the test case execution track set acquisition module is used for acquiring an execution track set of the test case set based on the monitoring information file of the microservice;
the doubtness degree calculation module is used for calculating the doubtness degree of each micro service according to the execution result and the execution track set of the test case set based on the micro service information in the micro service combination program to be tested;
and the fault positioning report generating module is used for sorting the micro-services in the to-be-tested micro-service combination program according to the suspicion degree, screening out the micro-services with the suspicion degree exceeding a preset value, obtaining a high-suspicion degree micro-service set and generating a fault positioning report.
The fault location system of the microservice combined program of the present embodiment corresponds to the fault location method of the microservice combined program of the first embodiment; the functions realized by the functional modules in the fault location system of the micro-service combination program of the present embodiment correspond to the flow steps in the fault location method of the micro-service combination program of the first embodiment one by one; therefore, it is not described herein.
Furthermore, it should be appreciated by those skilled in the art that embodiments of the present invention may be provided as a method, apparatus, or computer program product. Accordingly, embodiments of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present invention may take the form of a computer program product embodied on one or more computer-usable storage media having computer-usable program code embodied in the medium.
Embodiments of the present invention are described with reference to flowchart illustrations and/or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, embedded processor, or other programmable data processing terminal to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing terminal to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks. These computer program instructions may also be loaded onto a computer or other programmable data processing terminal to cause a series of operational steps to be performed on the computer or other programmable terminal to produce a computer implemented process such that the instructions which execute on the computer or other programmable terminal provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
It is further noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or terminal. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or terminal that comprises the element.
Finally, it should be noted that while the above describes a preferred embodiment of the invention, it will be appreciated by those skilled in the art that, once the basic inventive concepts have been learned, numerous changes and modifications may be made without departing from the principles of the invention, which shall be deemed to be within the scope of the invention. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the embodiments of the invention.
Claims (5)
1. A method for locating a fault of a microservice combined program, the method comprising:
acquiring micro-service information in a micro-service combination program to be tested based on API description document information of the micro-service combination program to be tested;
acquiring an execution result of the test case set;
acquiring an execution track set of the test case set based on a monitoring information file of the micro service;
based on the micro-service information in the micro-service combination program to be tested, calculating the suspicion degree of each micro-service according to the execution result and the execution track set of the test case set;
sequencing the micro-services in the micro-service combination program to be tested according to the suspicion degree, screening out the micro-services with the suspicion degree exceeding a preset value to obtain a high suspicion degree micro-service set, and generating a fault positioning report;
the obtaining of the execution result of the test case set includes:
numbering each test case in the selected test case set in sequence;
reading the test cases from the test case set in sequence;
marking the micro service set execution track coverage condition, and judging the execution result of each test case;
the marking of trace coverage by the microservice set comprises:
judging whether the test case t passes through multi-instance microservice or not;
if the test case t passes through the multi-instance microservice, acquiring the number m of the instances of the multi-instance microservice;
executing the test case t m times, and if all the test cases fail after the test case t is executed m times, judging that the multi-instance microservice has a fault; if the part of the test case t fails after the test case t is executed for m times, judging that a certain instance in the multi-instance microservice has a fault;
the judging the execution result of each test case comprises the following steps:
obtaining the actual output result of each test case in the micro-service combination program to be tested;
obtaining an expected output result of a current test case in the micro-service combination program to be tested;
judging whether the actual output result of the current test case is consistent with the expected output result;
if the actual output result is inconsistent with the expected output result, judging that the execution result of the current test case is failure, and adding the current test case into a failure test case set;
if the actual output result is consistent with the expected output result, judging that the execution result of the current test case is successful, and adding the current test case into a successful test case set;
the calculating the suspicion degree of each micro service according to the execution result and the execution track set of the test case set based on the micro service information in the micro service combination program to be tested comprises the following steps:
when the execution track of the test case t passes through the front-end gateway service, the front-end gateway service is regarded as the functional microservice; when the execution track of the test case t passes through the back-end gateway service, recording the frequency of the back-end gateway service appearing in the execution track corresponding to the test case t as 1 time;
calculating the suspicion degree of each micro service according to the frequency difference of the successful test case set and the failed test case set in the micro service calling relation;
the calculating the suspicion degree of each micro service according to the frequency difference of the successful test case set and the failed test case set in the micro service calling relation comprises the following steps:
calculating the frequency of the successful test case set passing through different calling edges of the microservice S by using a formula (1):
wherein p istiFrequency, x, representing successful test case set passing through the ith call edge of the microservice SettiRepresenting the number of times, x, that a successful test case set passes through the ith calling edge of the microservice StkRepresenting the times of the successful test case set passing through the kth calling edge of the microservice S;
calculating the frequency of the failed test case set passing through different calling edges of the microservice S by using a formula (2):
wherein p isfiFrequency, x, representing the frequency of failed test case sets passing through the ith call edge of the microservice SfiRepresenting the number of times, x, that the failed test case set passes through the ith calling edge of the microservice SfkRepresenting the times of the failed test case set passing through the kth calling edge of the microservice S;
obtaining the frequency density P of the successful test case set passing through different calling edges of the microservice St＝(pt1,pt2,…,ptn) Frequency density P of different calling edges of failure test case set through microservice Sf＝(pf1,pf2,…,pfn)；
Calculating P using equation (3)tAnd PfSimilarity of (A) SimE (P)t,Pf) A 1 is to PtAnd PfSimilarity of (A) SimE (P)t,Pf) Suspicion as microservice S:
wherein p istkFrequency, p, representing successful test case set passing through the kth calling edge of the microservice SfkIndicating the frequency of the failed test case set passing through the kth calling edge of the microservice S.
2. The method for locating the fault of the micro-service combination program according to claim 1, wherein the obtaining the micro-service information in the micro-service combination program to be tested comprises:
acquiring instance information of all micro services in an API description document of the micro service combination program to be tested, and analyzing to obtain all micro services in the micro service combination program to be tested; the micro service instance information comprises names, hosts and port registries of corresponding micro services;
acquiring all gateway microservices and functional microservices in the microservice combined program to be detected to obtain a front-end gateway set, a rear-end gateway set and a functional microservice set; the functional micro-service is a small functional block focusing on single responsibility and function in the micro-service combination program to be tested.
3. The method for locating the fault of the micro-service combination program according to claim 1, wherein the obtaining of the execution trace set of the test case set comprises:
analyzing the monitoring information file;
obtaining an execution track set after the test case set is executed according to the execution track information of each test case recorded in the monitoring information file;
and collecting and recording the calling track situation among each microservice.
4. The method for locating the fault of the micro-service combination program according to any one of claims 1 to 3, wherein the method for sorting the micro-services in the micro-service combination program to be tested according to the suspicion degree, screening out the micro-services with the suspicion degree exceeding a preset value to obtain a high suspicion degree micro-service set, and generating the fault locating report comprises the following steps:
sorting the micro-services in the combined program of the services to be tested in a descending order according to the suspicion degree;
and selecting the micro-services with the suspicion degree exceeding a preset value and the example information thereof to generate a fault positioning report.
5. A system for fault location of a microservice assembly, the system comprising:
the micro-service information acquisition module is used for acquiring micro-service information in the micro-service combination program to be detected based on API description document information of the micro-service combination program to be detected;
the test case execution result acquisition module is used for acquiring the execution result of the test case set;
the test case execution track set acquisition module is used for acquiring an execution track set of the test case set based on a monitoring information file of the micro service;
the suspicion degree calculation module is used for calculating the suspicion degree of each micro service according to the execution result and the execution track set of the test case set based on the micro service information in the micro service combination program to be tested;
the fault positioning report generating module is used for sequencing the micro-services in the micro-service combination program to be tested according to the suspicion degree, screening out the micro-services with the suspicion degree exceeding a preset value, obtaining a high suspicion degree micro-service set and generating a fault positioning report;
the obtaining of the execution result of the test case set includes:
numbering each test case in the selected test case set in sequence;
reading the test cases from the test case set in sequence;
marking the micro service set execution track coverage condition, and judging the execution result of each test case;
the marking of trace coverage by the microservice set comprises:
judging whether the test case t passes through multi-instance microservice or not;
if the test case t passes through the multi-instance microservice, acquiring the number m of the instances of the multi-instance microservice;
executing the test case t m times, and if all the test cases fail after the test case t is executed m times, judging that the multi-instance microservice has a fault; if the part of the test case t fails after the test case t is executed for m times, judging that a certain instance in the multi-instance microservice has a fault;
the judging the execution result of each test case comprises the following steps:
obtaining the actual output result of each test case in the micro-service combination program to be tested;
obtaining an expected output result of a current test case in the micro-service combination program to be tested;
judging whether the actual output result of the current test case is consistent with the expected output result;
if the actual output result is inconsistent with the expected output result, judging that the execution result of the current test case is failure, and adding the current test case into a failure test case set;
if the actual output result is consistent with the expected output result, judging that the execution result of the current test case is successful, and adding the current test case into a successful test case set;
the calculating the suspicion degree of each micro service according to the execution result and the execution track set of the test case set based on the micro service information in the micro service combination program to be tested comprises the following steps:
when the execution track of the test case t passes through the front-end gateway service, the front-end gateway service is regarded as the functional microservice; when the execution track of the test case t passes through the back-end gateway service, recording the frequency of the back-end gateway service appearing in the execution track corresponding to the test case t as 1 time;
calculating the suspicion degree of each micro service according to the frequency difference of the successful test case set and the failed test case set in the micro service calling relation;
the calculating the suspicion degree of each micro service according to the frequency difference of the successful test case set and the failed test case set in the micro service calling relation comprises the following steps:
calculating the frequency of the successful test case set passing through different calling edges of the microservice S by using a formula (1):
wherein p istiFrequency, x, representing successful test case set passing through the ith call edge of the microservice SettiRepresenting the number of times, x, that a successful test case set passes through the ith calling edge of the microservice StkRepresenting the times of the successful test case set passing through the kth calling edge of the microservice S;
calculating the frequency of the failed test case set passing through different calling edges of the microservice S by using a formula (2):
wherein p isfiFrequency, x, representing the frequency of failed test case sets passing through the ith call edge of the microservice SfiRepresenting the number of times, x, that the failed test case set passes through the ith calling edge of the microservice SfkRepresenting the times of the failed test case set passing through the kth calling edge of the microservice S;
obtaining the frequency density P of the successful test case set passing through different calling edges of the microservice St＝(pt1,pt2,…,ptn) Frequency density P of different calling edges of failure test case set through microservice Sf＝(pf1,pf2,…,pfn)；
Calculating P using equation (3)tAnd PfSimilarity of (A) SimE (P)t,Pf) A 1 is to PtAnd PfSimilarity of (A) SimE (P)t,Pf) Suspicion as microservice S:
wherein p istkFrequency, p, representing successful test case set passing through the kth calling edge of the microservice SfkIndicating the frequency of the failed test case set passing through the kth calling edge of the microservice S.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010051172.7A CN111258901B (en) | 2020-01-17 | 2020-01-17 | Fault positioning method and system for micro-service combination program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010051172.7A CN111258901B (en) | 2020-01-17 | 2020-01-17 | Fault positioning method and system for micro-service combination program |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111258901A CN111258901A (en) | 2020-06-09 |
| CN111258901B true CN111258901B (en) | 2021-03-16 |
Family
ID=70952243
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010051172.7A Active CN111258901B (en) | 2020-01-17 | 2020-01-17 | Fault positioning method and system for micro-service combination program |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111258901B (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111831556A (en) * | 2020-06-18 | 2020-10-27 | 中国科学院空间应用工程与技术中心 | Software multi-fault decoupling and parallel positioning method and device |
| CN112181818B (en) * | 2020-09-23 | 2023-06-27 | 中国电子技术标准化研究院 | Micro-service architecture industrial APP testing method and system based on variable combination strength |
| CN112286797B (en) * | 2020-09-29 | 2024-05-03 | 长沙市到家悠享网络科技有限公司 | Service monitoring method and device, electronic equipment and storage medium |
| CN112527410A (en) * | 2020-12-17 | 2021-03-19 | 深圳市欢太科技有限公司 | Full link tracking method, device, equipment and storage medium |
| CN113190373B (en) * | 2021-05-31 | 2022-04-05 | 中国人民解放军国防科技大学 | Micro-service system fault root cause positioning method based on fault feature comparison |
| CN117112448B (en) * | 2023-10-18 | 2024-01-30 | 浙江东安检测技术有限公司 | Forest algorithm-based software test fault positioning method, system and medium |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104572474A (en) * | 2015-01-30 | 2015-04-29 | 南京邮电大学 | Dynamic slicing based lightweight error locating implementation method |
| CN108804308A (en) * | 2018-04-27 | 2018-11-13 | 北京信息科技大学 | New version bugs detection method and device |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101231614B (en) * | 2008-02-02 | 2010-06-02 | 南京大学 | Method for locating software unsoundness based on execution track block semblance |
| US20180373865A1 (en) * | 2017-06-26 | 2018-12-27 | Microsoft Technology Licensing, Llc | Call flow-based anomaly detection for layered software systems |
| US10289538B1 (en) * | 2018-07-02 | 2019-05-14 | Capital One Services, Llc | Systems and methods for failure detection with orchestration layer |
| CN110008120A (en) * | 2019-03-18 | 2019-07-12 | 三峡大学 | A kind of software fault positioning method based on frequency spectrum |
| CN110362484B (en) * | 2019-07-03 | 2022-03-01 | 北京航空航天大学 | Method and device for positioning multiple faults of software, electronic equipment and storage medium |
| CN110688277A (en) * | 2019-09-12 | 2020-01-14 | 上海易点时空网络有限公司 | Data monitoring method and device for micro-service framework |
-
2020
- 2020-01-17 CN CN202010051172.7A patent/CN111258901B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104572474A (en) * | 2015-01-30 | 2015-04-29 | 南京邮电大学 | Dynamic slicing based lightweight error locating implementation method |
| CN108804308A (en) * | 2018-04-27 | 2018-11-13 | 北京信息科技大学 | New version bugs detection method and device |
Non-Patent Citations (1)
| Title |
|---|
| 《基于日志可视化分析的微服务系统调试方法》;李文海等;《计算机科学》;20191213(第11期);第145-155页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111258901A (en) | 2020-06-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111258901B (en) | Fault positioning method and system for micro-service combination program | |
| Zhang et al. | Ensembles of models for automated diagnosis of system performance problems | |
| Syer et al. | Leveraging performance counters and execution logs to diagnose memory-related performance issues | |
| US20110276836A1 (en) | Performance analysis of applications | |
| KR100803889B1 (en) | Method and system for analyzing performance of providing services to client terminal | |
| US11429574B2 (en) | Computer system diagnostic log chain | |
| Cotroneo et al. | Fault injection analytics: A novel approach to discover failure modes in cloud-computing systems | |
| CN110457175B (en) | Service data processing method and device, electronic equipment and medium | |
| CN108683564B (en) | Network simulation system reliability evaluation method based on multidimensional decision attributes | |
| CN106911519B (en) | Data acquisition monitoring method and device | |
| CN113037595B (en) | Abnormal device detection method and device, electronic device and storage medium | |
| CN111078432A (en) | Tracking method and device for scheduling between services | |
| CN111078513A (en) | Log processing method, device, equipment, storage medium and log alarm system | |
| US20210133076A1 (en) | System and method for detecting anomalies based on feature signature of task workflows | |
| JP6196196B2 (en) | Inter-log causal estimation device, system abnormality detection device, log analysis system, and log analysis method | |
| CN107203464B (en) | Method and device for positioning service problem | |
| Ghanbari et al. | Stage-aware anomaly detection through tracking log points | |
| CN115237804A (en) | Performance bottleneck assessment method, performance bottleneck assessment device, electronic equipment, medium and program product | |
| CN109639456B (en) | Improvement method for automatic alarm and automatic processing platform for alarm data | |
| CN110543462A (en) | Microservice reliability prediction method, prediction device, electronic device, and storage medium | |
| CN107562621A (en) | The method and apparatus for determining manual test use-case and tested code incidence relation | |
| CN116405412B (en) | Method and system for verifying cluster effectiveness of simulation server based on chaotic engineering faults | |
| CN115658441B (en) | Method, equipment and medium for monitoring abnormality of household service system based on log | |
| CN111368104B (en) | Information processing method, device and equipment | |
| CN113760689A (en) | Interface fault alarm method, device, equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |