CN112783513B

CN112783513B - Code risk checking method, device and equipment

Info

Publication number: CN112783513B
Application number: CN202110289057.8A
Authority: CN
Inventors: 赵若愚; 沈巍毅; 瞿伟
Original assignee: Industrial and Commercial Bank of China Ltd ICBC
Current assignee: Industrial and Commercial Bank of China Ltd ICBC
Priority date: 2021-03-18
Filing date: 2021-03-18
Publication date: 2024-02-27
Anticipated expiration: 2041-03-18
Also published as: CN112783513A

Abstract

The embodiment of the specification provides a code risk checking method, a code risk checking device and code risk checking equipment, which can be used in the financial field or other fields. The method includes obtaining an object code; detecting the target code based on the error information set to obtain detection data; determining, based on the process control model, whether to perform a corruption test on the object code if the detection data is not at risk; the process control model is established based on the resource information, the generation time of the destructive testing case, the operation judging time of the destructive testing case and the code error rate; under the condition that the destructive testing is determined to be executed on the target code, generating a destructive testing case based on the running node information and the execution path information corresponding to the target code; executing the destructive testing case to obtain an executing result corresponding to the target code; and determining whether the target code is at risk based on the execution result. By using the embodiment of the specification, the code risk detection efficiency can be improved, and the product code quality can be ensured.

Description

Code risk checking method, device and equipment

Technical Field

The present invention relates to the field of software testing, and in particular, to a method, an apparatus, and a device for checking code risk. It should be noted that the code risk checking method, device and equipment disclosed in the present application may be used in the financial field, and may also be used in any field other than the financial field, and the application fields of the code risk checking method, device and equipment disclosed in the present application are not limited.

Background

In the daily development and testing process of a software system, ensuring that the code does not have potential or obvious risks is becoming more and more important for improving the code quality and testing progress.

Currently, in development testing, the submitting process control is mainly through code static scan tools for normalization checking, and then the code passing through the normalization checking is tested by using unit test tools in the unit test driven development (Unit Test Driven Development, UTDD) concept. However, the code static scanning tool, such as SONAR, can only go to the problems possibly caused in the static scanning code based on the rule base established by the industry or the technical departments of the company, and can not capture the problems which can be exposed by running; the unit testing tool based on UTDD has human reasons, which can lead to that unit testing is only written for realizing code level coverage rate in many times, so that quality is uneven, the effect of guarding product quality is difficult to be realized, and whether the unit testing tool really covers branches from a service angle is also difficult to verify, so that the product code quality cannot be ensured.

Therefore, a technical solution for solving the above technical problems is needed in the industry.

Disclosure of Invention

The embodiment of the specification provides a code risk checking method, a code risk checking device and code risk checking equipment, which can improve code risk detection efficiency and ensure product code quality.

The method, the device and the equipment for checking the code risk provided by the specification are realized in the following manner.

A code risk inspection method comprising: acquiring an object code; detecting the target code based on an error information set to obtain detection data; the detection data indicates whether the target code is at risk; determining, based on a process control model, whether to perform a corruption test on the object code if the detection data is not risky; the process control model is established based on resource information, the generation time of the destructive testing case, the operation judging time of the destructive testing case and the code error rate; under the condition that the execution of the destructive test on the target code is determined, generating a destructive test case based on the running node information and the execution path information corresponding to the target code; executing the destructive testing case to obtain an execution result corresponding to the target code; and determining whether the target code is at risk or not based on the execution result.

A code risk inspection apparatus comprising: the acquisition module is used for acquiring the target code; the detection module is used for detecting the target code based on the error information set to obtain detection data; the detection data indicates whether the target code is at risk; a first determination module to determine whether to perform a corruption test on the object code based on a process control model if the detection data is not at risk; the process control model is established based on resource information, the generation time of the destructive testing case, the operation judging time of the destructive testing case and the code error rate; the generation module is used for generating a destructive testing case based on the running node information and the execution path information corresponding to the target code under the condition that the destructive testing is determined to be executed on the target code; the execution module is used for executing the destructive testing case and obtaining an execution result corresponding to the target code; and the second determining module is used for determining whether the target code is at risk or not based on the execution result.

A code risk inspection device comprising at least one processor and memory storing computer-executable instructions which, when executed by the processor, implement the steps of any of the method embodiments of the present specification.

A computer readable storage medium having stored thereon computer instructions which when executed perform the steps of any of the method embodiments of the present description.

The specification provides a code risk checking method, a code risk checking device and code risk checking equipment. In some embodiments, the target code may be acquired, and the target code is detected based on the set of error information to obtain detection data, where the detection data indicates whether the target code is at risk. Further, whether to execute the destructive test on the target code can be determined based on the process control model under the condition that the detection data does not have risk, when the destructive test is determined to be executed on the target code, a destructive test case can be generated based on the operation node information and the execution path information corresponding to the target code, and then the destructive test case is executed, an execution result corresponding to the target code is obtained, and whether the target code has risk is determined based on the execution result; the process control model is built based on the resource information, the generation time of the destructive testing case, the operation judging time of the destructive testing case and the code error rate. By adopting the implementation scheme provided by the specification, the code risk detection efficiency can be improved, and the product code quality can be ensured.

Drawings

The accompanying drawings are included to provide a further understanding of the specification, and are incorporated in and constitute a part of this specification. In the drawings:

FIG. 1 is a flow diagram of one embodiment of a code risk inspection method provided herein;

FIG. 2 is a directed graph corresponding to a service code provided in the present specification;

FIG. 3 is a schematic block diagram illustrating one embodiment of a code risk inspection apparatus provided herein;

fig. 4 is a block diagram of a hardware architecture of one embodiment of a code risk check server provided herein.

Detailed Description

In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments, but not all embodiments in the present specification. All other embodiments, which can be made by one or more embodiments of the present disclosure without inventive faculty, are intended to be within the scope of the embodiments of the present disclosure.

The following describes embodiments of the present disclosure by taking a specific application scenario as an example. Specifically, fig. 1 is a schematic flow chart of an embodiment of a code risk checking method provided in the present specification. Although the description provides methods and apparatus structures as shown in the examples or figures described below, more or fewer steps or modular units may be included in the methods or apparatus, whether conventionally or without inventive effort.

One embodiment provided in this specification may be applied to a client, a server, or the like. The client may comprise a terminal device, such as a smart phone, tablet computer, etc. The server may include a single computer device, a server cluster formed by a plurality of servers, a server structure of a distributed system, or the like.

It should be noted that the following description of the embodiments does not limit the technical solutions in other scalable application scenarios based on the present description. In one embodiment of a code risk checking method provided in the present specification, as shown in fig. 1, the method may include the following steps.

S0: the object code is obtained.

In the embodiment of the present specification, the object code may be a code under test. The code to be tested may be a code that needs to check if there is a risk, such as the code entering the review phase of the code after submitting the Git and leaving the Commit operation, where a series of checks of the code are typically performed, so the code of this phase may be considered as the target code. Wherein, git is an open-source distributed version control system for agilely and efficiently handling any small or large item. Commit operations may be used to save modifications made by transactions to a database. Review may reduce the error rate of the code.

In some embodiments, the object code may be retrieved from a database or other memory, which is not limited in this specification.

S2: detecting the target code based on an error information set to obtain detection data; the detection data indicates whether the object code is at risk.

In the embodiment of the present disclosure, after the target code is acquired, the target code may be detected based on the error information set, so as to obtain detection data. Wherein the detection data may indicate whether the object code is at risk.

In some embodiments, the set of error information may be obtained by: acquiring service codes included in an application code library; carrying out structural conversion on the service codes to obtain a directed graph corresponding to the service codes; wherein, the directed graph comprises the operation node information of the service codes; the operation node information comprises parameter information and code structure information; traversing the directed graph by using a breadth-first algorithm to obtain execution path information corresponding to the service codes; generating a destructive testing case based on the running node information and the execution path information; executing the damage test case to obtain error information; the error information comprises corresponding execution path information, code structure information and parameter information when errors occur in the process of executing the destructive testing cases; and preprocessing the error information to obtain an error information set. Wherein, a plurality of service codes can be prestored in the application code library. The service code may include a code that has been applied to the service, may also include a source code, etc.

In some implementations, structured transformations may also be referred to as nodelized extraction, which may be understood as the decomposition and extraction of the structure of the code itself, which may transform the code into a directed graph. It should be noted that, in some implementation scenarios, one or more program methods (abbreviated as "methods") may be included in the service code, and a method may include information such as input, output, internal logic, and the like. In general, the method internal logic may include certain branch determination conditions. The branch judgment conditions generally start according to own actual service demands, and different code execution paths and output results are given based on different judgment conditions based on the characteristics of programming languages, so that the realization of service logic is satisfied. The branch judgment conditions of the java programming language may include: 1) try, the expression can be used for preventing the program abnormality that may occur generally, put the normal business code into general try module, the branch of the catch can be used for dealing with the program abnormality that may occur generally; 2) if. else if.. Else, the expression being the most common branch judgment condition, if may be used for the first condition of collision, one to a plurality of else if may be used for one to a plurality of conditions after collision, and when all of the foregoing conditions are not satisfied, the statement block of else is executed; 3) switch..case..default, switch statement generally has a unified judged object, matching is carried out according to the values of one to a plurality of cases, corresponding logic is executed after matching, and when all cases cannot be matched, a default statement block is triggered; 4) Ternary expressions, which can be regarded as a simplified version of if.. Var= Boolean EquationA:b, which represents that the ternary expression is based on a boolean expression as a judgment, returns to a when the expression is true, otherwise returns to B.

Based on the branch judgment conditions of the java programming language, the internal logic of one method is generally composed of three types of sequential execution, branch judgment and loop execution. In some embodiments of the present disclosure, when converting a service code into a directed graph, sequential execution and loop execution may be combined, so that the length of a sequential execution link of a method in the service code may determine the depth of the service code, and branch determination may increase the breadth of the service code.

In some implementations, code may be translated into a directed graph based on the following extraction rules:

step1: setting an entry of the method as a start node of the directed graph, and recording an initial code depth as d=1;

step2: judging the form of the next line of sentences;

if the sequence flow statement is the sequence flow statement, skipping; if the identifier is the branch judgment identifier, turning to Step3; if the end identifier is the end identifier, go to Step4; if it is the last line of code, go to Step5.

Step3: depth d=d+1, find the corresponding end, according to the branching of the branching in the directed graph, the depth is uniform. Further, continue searching downward in the same level whether there is a branch judgment structure of the same depth level until the code block of the same level ends, go to Step2.

Step4: the depth is denoted as d _end ＝d _now +1, and denoted end node, go to Step2;

wherein d _end Represents the depth corresponding to the execution path end node, d _now Representing the depth corresponding to the current node.

Step5: recording maximum depthWherein (1)>Representing the maximum value in the depth corresponding to all execution path end nodes in the directed graph, +.>Representing the depth corresponding to the end node of execution path 1 in the directed graph, +.>The depth corresponding to the end node of the execution path K in the directed graph is represented, K represents the number of the execution paths, and K represents the number of the execution paths in the directed graph.

In the embodiment of the specification, the business codes are converted from the programming language into the directed graph by using the extraction rules, so that the structured description codes can be conveniently used, more convenience is provided for the subsequent code analysis, and the analysis efficiency is improved.

In some implementation scenarios, after the service code is structured and converted, a directed graph corresponding to the service code may be obtained. The directed graph represents a start node and an end node of the directed graph by a code entry and an end, and other nodes in the directed graph can be composed of branch structures. The directed graph can comprise running node information of codes, and the running node information can comprise parameter information and code structure information. The parameter information may include input parameters, output parameters, condition parameters, and the like. The code structure information may include inputs, outputs, external dependencies, branch decisions, and the like.

In some implementation scenarios, after the directed graph corresponding to the service code is obtained, the directed graph may be traversed by using a breadth-first algorithm to obtain the execution path information corresponding to the service code. In some implementation scenarios, the corresponding path execution matrix may be obtained while the execution path information corresponding to the service code is obtained.

In some implementations, it is assumed that one method of the service code includes K execution paths, d represents depth,represents maximum depth, b represents single-node branch number, b _max Representing the maximum single-node branch number, the numerical information represents whether the code runs to each execution path when executing the execution path, the numerical information of the start node is 1, the numerical information of the end node is 1, the numerical information of the other nodes is recorded as N according to whether the code runs to a set 0-1 variable _route ＝{N ₁ ,N ₂ ....N _K The path execution matrix is marked as + ->N ₁ Representing execution path information corresponding to the first execution path, N _K And (3) representing execution path information corresponding to the kth execution path, and r (i, K) representing the ith depth and a numerical value corresponding to the kth execution path, traversing the execution steps of the directed graph by using the breadth-first algorithm, wherein the execution steps are as follows:

step1: recording the current depth d from the start node ₁ =1, the numerical information is r (1, k) =1;

step2: based on the branch judgment condition, finding a value corresponding to the kth execution path of the ith depth level, wherein the recording depth is d _i Numerical information r (i, k) =j;

step3: recording the line reaching the end node first, recording the depth of the end node, wherein the execution path information of a certain execution path k is N _k ；

Step4: step2 and Step3 are repeated until all nodes have been traversed.

As shown in fig. 2, fig. 2 is a directed graph corresponding to a service code provided in the present specification. Where d represents depth, the number in the circle represents node number, 10 total nodes, start in the circle represents start node (denoted as node 1), end in the circle represents end node (denoted as node 10), and there are 5 execution paths, and the method makes branch condition judgment at nodes 1, 2, 4, and 5 to form branches. Traversing the directed graph by using breadth-first algorithm, the execution matrix R can be obtained as:

execution path set N _route ＝{N ₁ ,N ₂ ....N _K In }, N ₁ ＝(1,1),(2,1),(3,1),(4,1),(5,1)，N ₂ ＝(1,1),(2,2),(3,0),(4,0),(5,1)，N ₃ ＝(1,1),(2,1),(3,2),(4,1),(5,1)，N ₄ ＝(1,1),(2,1),(3,1),(4,2),(5,1)，N ₅ ＝(1,1),(2,1),(3,2),(4,2),(5,1)。

In some implementation scenarios, after the execution path information corresponding to the service code, a damage test component can be designed based on the operation node information and the execution path information, and a damage test can be executed on the tested method, so that whether the current code writing logic has potential risks or not is verified, and a data basis is provided for subsequent intelligent recognition. Wherein breaking a test component can be understood as breaking a test case.

In some implementation scenarios, when generating a destructive test case based on running node information and execution path information corresponding to an object code, the PowerMockito may be used to simulate external dependency information in a service code, then based on the running node information, design destructive test input, and finally generate the test case based on the execution path information and the destructive test input by using a reflection tool and a code template generation tool. The PowerMockito is an open source mock framework, and can be used for isolating external dependence in a code method, and guaranteeing the unit level and independence of code execution. For example, a method has a database connected internally to perform some operations, so in order to guarantee the unit property of the code when performing the corruption test, the dependency on the outside needs to be blocked, i.e. the database cannot be truly disconnected, and the existence of PowerMockito can simulate the behavior of the external dependency, thereby realizing the effect of "simulation". The code template generation tool may be a vector. The vector may be considered a template engine that may be used to generate test cases. For example, a template of a mail is designed, only part of core content (such as time, recipient and other dynamic information) is transmitted to the template, and a finished mail can be assembled by using the consistency. The reflective means may comprise javaassit, cglib or the like. Java is a class library that edits bytecodes in Java, which can find object properties, methods, modify scopes, call methods by method names, etc. at runtime. cglib is a powerful, high-performance code generation library that is widely used in the AOP framework to provide method interception operations. The corruption test input may be understood as an entry into the corruption test case, the value of which may be inferred based on branching, for example. For example, the entry has an array, and the number of elements of the array is checked in the branches, and depending on whether the branching is null, the entry for the array may be null or a data-bearing array.

In some implementations, the design destruction test component may include: (1) Reading codes, and acquiring input information, output information, externally-dependent information and branch judgment condition information of the codes; (2) design a destructive test input; (3) Based on javaassit, cglib and other reflection kits and the visibility code template generating tool, a destructive test case is automatically generated.

In the above implementation scenario, the input information of the code may be generally divided into three types, one is no input, one is a basic type, including common values, character strings, boolean, collection, map, and the like, and the other is a more complex type. On the one hand, the more complex class can be simulated based on the mock, null can be given for some difficult mock but not used in the method, and the damage test cases are written manually for some difficult mock, but the situation is rare.

In the implementation scenario, for input, which attributes and methods are used in the input can be searched based on the method of object scanning, which assignment and judgment processes are involved, and specific different combination input information can be obtained by combining types and inputs.

In the above implementation scenario, for the output, three types may be generally included, one is no output, i.e. the Void method, one is a basic type output, and the other is a type output. In some implementations, however, in the corruption test, there is also a special set of outputs, namely an Exception class, which is a result of the code that is generated if the Exception is thrown and the code itself is not captured.

In the above implementation scenario, the external dependency is generally referred to as a method of invoking a database in one method, initiating a network request to the outside, or invoking other non-system classes in software development. According to the isolation principle of unit test, for the situation, the mock can be used for isolating dependence, so that the unstable situation of the test operation caused by the change of external environment is avoided. In the embodiment of the present specification, external dependencies are blocked by a PowerMockito tool, which has a simulation of an instance method, a static method, a final method, a private method, and the like.

In the above implementation scenario, for the branch judgment, the input and the external dependence can be combined together, in general, the judgment is performed according to the input of the data and the intermediate variable in the method, and the intermediate variable is generally obtained by the external method, so that the judgment condition of the branch can be analyzed to trace the generation position of the judgment condition, and further different mock realization behaviors are set for different branches.

In some implementations, after the corruption test case is generated, the corruption test case may be executed based on the Junit to obtain error information. The error information may include execution path information, code structure information, parameter information, depth, error type, error stack information, and the like, which correspond to when an error occurs in the process of executing the destructive test case. Junit is a java-based unit test framework that can be used to run method-level unit level tests, driving the execution of test cases.

In the embodiment of the specification, the destructive unit test cases with full path coverage are automatically generated through the design of the destructive test component based on PowerMockito+Junit, through the judgment of input, output, external dependence and branch conditions of the method, and a large amount of error information is acquired through running the generated destructive unit test cases, so that a data basis can be provided for subsequent error classification, and a guarantee is provided for subsequent code risk detection.

In some embodiments, after the error information is obtained, the error information may be preprocessed to obtain the set of error information. In some implementation scenarios, the error information with the same execution path information may be combined first, and then secondary error information is removed from the combined error information set to obtain an error information set.

In some implementations, before merging the error information with the same execution path information, the error stack information may be traced to the position where the code is in error, so as to locate the error stack information in two execution nodes. Since the node with error is not necessarily the position where the error really happens, the position where the error of the code really happens can be further traced back according to the type of the thrown error. In this embodiment of the present disclosure, a root cause (such as a group crossing, a read-write abnormality, a network connection abnormality, etc.) that causes a failure of the present test is referred to as a primary error, and a propagation effect generated by the primary error and a code running, and further a subsequent code execution error is referred to as a secondary error.

In some implementation scenarios, after the error information is located in two execution nodes, the error information corresponding to the same execution path caused by different conditions may be combined, then the secondary error information is removed from the execution nodes, and the primary error information path is reserved, so as to obtain an error information set. For example, in some implementation scenarios, analysis is performed for all failure test success cases of a single method, after all error information of the method is obtained, because possible repeated errors are considered, duplicate removal and merging can be performed according to the primary error occurrence position as the center, and finally an error information set of the method m is obtainedWherein N is _m Is the total number of errors for method M, and M indicates how many methods are in the class.

In some implementation scenarios, after the error information is acquired, a corresponding sub-matrix may be extracted from the execution matrix according to the execution path information corresponding to the error information. For example oneIn some implementation scenarios, based on the error execution path, the corresponding numerical information can be extracted from the execution matrix to form a new error execution matrix R _sub Further, entry and judgment information of each node in the error path is stored and executed, and the entry and judgment information comprises the type of the entry and data information. Thus, the error information can be stripped from the whole information, thereby facilitating subsequent analysis. The parameter information may be parameter information corresponding to the error execution path, and the judgment information may be code structure information corresponding to the error execution path.

In the embodiment of the present disclosure, after the error information set is obtained, the error information in the error information set may be further classified.

In some implementations, each piece of error information in the set of error information may be represented as a vector, and further classification of the error information may be achieved by classifying the vector. For example, in some implementation scenarios, the execution path information corresponding to a certain method may be recorded as an erroneous execution vector v _e The code structure information is noted as code structure vector v _c The parameter information is noted as parameter vector v _p Thus, the error information set can pass through the vector group v= (v) _e ,v _c ,v _p ) To represent. The information covered by each piece of error information can be restored through the vector group.

In some implementations, the error information in the set of error information is passed through the vector set v= (v) _e ,v _c ,v _p ) After the representation, the refined classification of the error information can be realized based on a spectral clustering and simulated annealing algorithm. Specifically, an error classification model based on a multi-path spectral clustering algorithm can be established, and then the error classification model is solved based on a simulated annealing algorithm, so that different error information can be classified. In the embodiment of the present specification, vector group v= (v) _e ,v _c ,v _p ) As an indicator of the similarity of the error messages.

In this implementation scenario, for a vector group consisting of V error information setsA set, may be constructed as a directed graph g= (V, E, w). Where V denotes a node of the directed graph, E denotes an arc between error information sets, and e= { ee= (V) _w ,v _v ),v _w ,v _v ∈V,v _w ≠v _v }，v _w And v _v For two different sets of error information belonging to V, w represents the weight of the arc, with w= { w _e |e∈E}。

In this implementation scenario, for directed graph G _j Defining a weighted adjacency matrix A thereof _j Its dimension is o×o. Matrix A _j The elements of (a) are:

wherein a is as defined above _wv For weighting adjacency matrix A _j The value of the w-th row and v-th column element, x _w 、x _v For two different points, σ is a gaussian kernel function.

In this implementation scenario, the degree matrix D may be defined _j The diagonal elements are:

the remaining elements are all 0. Wherein d is as defined above _ww Degree matrix D _j The value of the w-th row and the w-th column element, a _mn For weighting adjacency matrix A _j The value of the mth row and nth column element.

In the present implementation scenario, L _j Is directed graph G _j Wherein L is _j ＝D _j -A _j . The goal of spectral clustering (spectral clustering) is to cut the directed graph into k sub-graphs and ensure that the interval weights and minima connecting sub-graphs are large within the sub-graphs. Assume that the graph is cut into two subgraphs, for subgraph i and Assume that the connection path set between the two is E _c ThenThe method comprises the following steps: />Wherein a is _e An e-th element in the connection path set; e is an arc; m and n are different points.

In this implementation scenario, connection path set E _c Weight is W _c The numerical values are as follows:the general parameter item set dividing objective function based on spectral clustering is as follows: />Wherein G is a directed graph; k is the number of sub-graphs cut.

In this implementation scenario, a multi-path canonical cutset criterion may be used as an implementation, which has higher execution efficiency compared to other criteria. The recognition model of the multi-path standard cut-set criterion is as follows:wherein G is a directed graph, K is the number of separation clusters, e and f are indexes of classification clusters, and the sum of weights among subgraphs is traversed; se, sf represent subgraph,>the weight between two sub-graphs, u and t are element indexes in the sub-graphs, and are used for traversing the weight sum between the sub-graphs and the full graph; w (w) _ut Is the weight between the sub-graph and the full graph.

In this implementation scenario, after the identification model is built, there are two parameters to be optimized, one is the gaussian kernel function σ, and the other is the partition cluster number K. To determine optimal values of the parameters, the values of the two parameters may be optimized based on an optimization algorithm that simulates annealing. The simulated annealing algorithm accepts a solution worse than the current solution with a certain probability, so that the local optimal solution may be jumped out to reach the global optimal solution.

Thus, the constraints are:

wherein K is the number of partition clusters, S _K V is a subset of V, V is a node of the directed graph, n is the iteration number, te is a temperature threshold, and eta is a temperature decay rate.

In this implementation scenario, the above-mentioned recognition model is solved iteratively to obtain the best error information classification, which can be used to check whether the new code has a known error.

In the implementation scene, the classification of error information is realized by a spectral clustering+simulated annealing algorithm, and at this time, for certain type of error information, there is an E= { v ₁ ,v ₂ ,v ₃ ...v _a I a = 1,2, 3..a }, where a represents the number of such error information vector sets.

In the embodiment of the present disclosure, after classifying the error information in the error information set, the target code may be detected based on the error information set, so as to determine whether there is a risk in the target code.

In some embodiments, before the target code is detected based on the error information set, whether a problem possibly caused exists in the target code can be statically scanned based on a rule base established by industry or a company technical department, and if the problem does not exist, whether the risk exists in the target code is detected based on the error information set. Of course, the foregoing is merely illustrative, and the manner of static scanning of the object code is not limited to the above examples, and other modifications may be made by those skilled in the art in light of the technical spirit of the present application, and all such modifications are intended to be included within the scope of the present application as long as the functions and effects of the present application are the same or similar.

In some embodiments, before the detecting the object code based on the error information set may include: carrying out structural transformation on the target code to obtain a directed graph corresponding to the target code; the directed graph comprises running node information of the target codes; traversing the directed graph by using a breadth-first algorithm to obtain the execution path information corresponding to the target code.

The specific implementation manner of the above-mentioned structural transformation of the object code and obtaining the execution path information corresponding to the object code may refer to the description of the related method embodiments, which is not described herein in detail.

In some embodiments, the detecting the object code based on the set of error information may include: detecting whether a first error information set matched with code structure information of the target code exists in the error information set; detecting whether a second error information set matched with the execution path information corresponding to the target code exists in the first error information set or not when the second error information set exists; and if so, detecting whether a third error information set matched with the parameter information corresponding to the target code exists in the second error information set.

In some implementations, when detecting the object code based on the set of error information, the object code may be first node-wise extracted and then matched in the set of error information. The specific matching sequence is as follows: code structure vector v in vector group corresponding to each error message in error message set _c Comparing, if the vector groups are not matched, carrying out subsequent matching on the vector groups corresponding to the current error information, and carrying out next round of matching; if so, further performing vector v with error _e Matching is carried out, if the matching is not carried out, the subsequent matching is not carried out on the vector group corresponding to the current error information, and the next round of matching is carried out; if it is matched, it is further matched with the parameter vector v _p Matching is carried out; if the error information is matched with the target code, the error category corresponding to the error information is used as the error category corresponding to the target code, and the error category can be further displayed; if the target codes are not matched, the risk that the error information in the error information set corresponds to the error information can be determined.

The existing error information sets are classified as described above, so to speak, as a rule for measuring whether the code under test has an existing error. However, there is a problem in that to what extent the inspected code matches a certain vector set of the error information set, it can be determined that it belongs to the type of error. In some implementation scenarios, in order to determine how well the matching is successful, a similarity threshold is set for each vector matching, and thus whether each set of vectors is successfully matched can be determined through the similarity threshold.

In some implementation scenarios, three similarity thresholds (corresponding to code structure vectors, error execution vectors, and parameter vectors) may be trained by using codes with known errors, then, when detecting whether there is a risk in the target code based on the error information set, based on the similarity thresholds of the three matches, when the result of each match exceeds the corresponding threshold, the next set of matches is performed, otherwise, it is directly determined that there is no risk corresponding to the error information in the error information set in the target code, which is a new code type, and further, whether a destructive test needs to be performed to find a problem may be considered.

In some implementations, the three similarity thresholds may be determined by: and setting an initial similarity threshold, wherein the target is that the number of parameters which are predicted to be positive and the result to be positive is that the percentage TPR of the number of parameters which are positive is larger than a preset value theta, and carrying out iterative training by using an unconstrained optimization algorithm to obtain the target similarity threshold, and specifically, an L-BFGS (Limited memory-BFGS, limited memory quasi-Newton algorithm) can be adopted. The L-BFGS is a BFGS saving memory and can be used for solving the optimization problem. The specific iterative process is as follows:

S21: inputting initial similarity threshold delta ₀ And a sample set B, wherein the sample set is a code class set of historic known error categories, and the output result is a target similarity threshold;

s22: when TPR is less than or equal to theta, executing the steps S23-S27, otherwise executing the step S28;

s23: calculating a similarity threshold delta gradient:wherein g is the gradient of the similarity threshold delta, i is the dimension, L is the derivative function, x ⁽ⁱ⁾ As the component of independent variable in i, y # ⁱ⁾ Is a factor changeA component of quantity i;

s24: calculating a Hessian matrix;

s25: computing the inverse matrix H of the Hessian matrix ^-1 ；

S26: computing and updating: delta ≡ -H ^-1 g。

S27: application update: delta ΣΔ+Δδ.

S28: outputting a result when the similarity threshold value obtained by iteration is basically unchanged: a target similarity threshold δ.

In some implementations, when the optimal similarity threshold delta is obtained _e 、δ _c 、δ _p When the matching degree of the three detection is respectively larger than delta for the new detected code _e 、δ _c 、δ _p And if the similarity threshold is not met, judging that the existing error category does not belong to the existing error category. Wherein delta _e 、δ _c 、δ _p Respectively representing the similarity threshold corresponding to the code structure vector, the error execution vector and the parameter vector.

In the embodiment of the present disclosure, by grouping the code structure vector, the error execution vector, and the parameter vector into the vector group, the efficiency of classifying the error information can be improved, and the error major class can be classified. By using known error codes to determine the corresponding similarity threshold when matching the code structure vector, the error execution vector, and the parameter vector, the accuracy of the code risk check can be effectively improved.

In some embodiments, when a risk is detected in the target code based on the set of error information, countermeasures or modification suggestions may be extracted from the rule base and fed back to the code writer or other administrator. The rule base can be pre-stored with modification suggestions or measures corresponding to different error information, code auditors and technicians can analyze the error information and give suggestions from the code design level, so that the developer can avoid developing similar codes next time and give suggestions, for example, in order to prevent the concurrent control problem of timing tasks, the tasks should be locked to ensure that only one server of the tasks is executing at the same time node.

S4: determining, based on a process control model, whether to perform a corruption test on the object code if the detection data is not risky; the process control model is built based on resource information, destructive testing case generation time, destructive testing case operation judging time and code error rate.

In the embodiment of the present disclosure, in the case that the detection data does not have a risk, it may be determined whether to perform a destructive test on the object code based on the process control model, so as to determine whether the object code has a risk. The process control model may also be referred to as a process control decision model, which may be built based on resource information and the time of destructive test case generation, the time of destructive test case run determination, and the code error rate. The process control model uses the method in the class to execute the damage test as a decision variable and uses the cost as an output value. The resource information may refer to information such as cost, etc.

Since code submission speed and number are increasing under the influence of agile development for day-to-day development, if matching, destructive testing, and result output are performed for each code, the code inspection process may be very complicated, thereby affecting the development efficiency. To this end, in embodiments of the present description, when it is determined that there is no risk in the target code based on the set of error information, it may be determined whether to perform a corruption test on the target code based on the process control model. The process control model may seek a balance between quality and efficiency or be biased toward a strategy. The balancing point is understood to be the point which is sought between the quality optimum and the efficiency optimum in order to achieve the smallest total outlay, with which the partial quality optimum and efficiency optimum are achieved as far as possible. In the present embodiment, the sum of the cost paid for achieving the optimum efficiency and the cost paid for achieving the optimum quality may be referred to as the total cost. The Quality optimization (Quality optimization) may be referred to as a Quality optimization (Quality optimization) for the Quality-focused development process, and an efficiency optimization (Efficiency Optimize) for the Quality-focused development process. The total cost may be represented by the symbol Z and the balance point coefficient may be represented by the symbol α.

In some embodiments, quality and efficiency are first measured when building a process control model.

In this embodiment, for quality measurement, the error rate of the method is used as a measurement index; for the measure of efficiency, the destructive test case generation time and the destructive test case operation judgment time of the branches of the method are taken as measures.

In this embodiment, for the measure of efficiency, one class C can be assumed to have a method of U, denoted as c= { f _u U=1, 2,3, &.u. For method f _u In one embodiment, there are K execution paths, denoted as R _u ＝{r _k I k=1, 2,3,..k }. For a single execution path, the failure test case generation time and the operation judgment time can be expressed asAt this time, for the efficiency measure, the cost charge is denoted as Z _e There is->

For quality metrics, one can assume C method f in a class _u Is mu _u Mu, have _u ＝n _error K, wherein n _error Representation method f _u The number of anomalies that occurred in the destructive test. At this time, for one class, its cost of quality is denoted as Z _q There is

For the entire object code, the total cost model can be expressed as z=αz _e +(1-α)Z _q +β ₀ 。

Substituting the above formula, the total cost model can be expressed as:

wherein alpha represents the balance point coefficient, omega _b 、ω _r 、ω _e Coefficients, beta, representing respectively the time of generation of the destructive test cases, the time of judgment of the operation, and the code error rate ₀ Representing the scan time of the code average.

The corresponding constraints are:

0≤α≤1

C＝{f _u |u＝1,2,3,...,U}

R _u ＝{r _k |k＝1,2,3,...,K}

ω _b 、ω _r 、ω _e ＞0

0≤μ≤1

in the above-described embodiments, by quantifying the quality and efficiency metrics, it is possible to establish whether to perform a destructive test (process control model) versus total cost. By solving the model, the minimum cost of the whole flow can be realized under the condition of a specific balance point coefficient, namely a strategy.

In some embodiments, the model built above may be solved based on genetic algorithms. Wherein the genetic algorithm is based on alternative solutions to cross, mutate, select, inherit to achieve stepwise optimization. Specifically, in the crossover process, it may be assumed that the crossover probability of each iteration is p _cross To ensure reasonable progress of the crossover, it can be assumed that: 1) The gene fragment is inseparable, and takes a group of genes (individuals) as crossing basic units; 2) The two gene points are not crossed at the same time and directly transmitted to the offspring, otherwise, the crossing is implemented. In the mutation process, it can be assumed that each chromosome has p at each generation _mutation The probability of the variation is 0,1, and the variation positions are random. The selection process is to inherit good individuals, wherein a conventional roulette method can be adopted, the individual fitness is an objective function, and the fitness of a certain individual is assumed to be Z (ψ), and the total fitness is Z _total The likelihood of selecting an individual is:/>

in this embodiment, when the model built above is solved based on a genetic algorithm, the object to be solved (i.e., the decision variable) is whether to execute the destructive test for each method in class C, if so, the value is 1, otherwise, the value is 0. Definition of the variable ψ _c To refer to the execution result set, there is ψ _c ＝{φ _u = {0,1} u=1, 2,3,..u }, where Φ _u Indicating whether method U performs a corruption test, U indicating the number of methods in class C; definition of population Ω _T For representing populations of the T-th generation, there is Ω for each population _T ＝{Ψ ₁ ,Ψ ₂ ,Ψ ₃ ,...,Ψ _d D = 1,2,3,..d }, where D represents the population number. Thus, when solving the established model based on the genetic algorithm, the method can aim at the psi _c The crossover and mutation processes are performed on the solutions in (a) and then the fitness (i.e., the model function value) of each solution is calculated, and finally, based on the fitness, which solutions can be inherited is determined. The specific solving steps are as follows:

step1: initializing related parameters, and randomly generating a dynamic test set, namely a population, based on random numbers;

step2: based on different strategies, invoking an inspection module, running out related data, and obtaining related data for calculating fitness;

step3: calculating fitness of individuals and groups based on the data result;

Step4: performing mutation, crossover and selection operations on individuals in the population to generate a new population set;

step5: judging the iteration times, if the iteration times are over, turning to Step6, otherwise turning to Step2;

step6: and outputting the optimal operation strategy.

In the embodiment of the specification, by solving the established model based on the genetic algorithm, a user can intelligently evaluate different method types under the condition of self-defining the balance point, so that balance is sought in quality and efficiency, and the requirement of lowest running cost is met.

In the embodiment of the specification, by establishing the process control model based on the efficiency and the quality, the balance point strategy can be dynamically adjusted according to the current research and development requirements, and the relatively optimal destructive testing execution strategy is obtained, so that the global optimization of the comprehensive cost can be ensured while the local optimization of the code quality and the pipeline efficiency is ensured.

S6: and under the condition that the execution of the damage test on the target code is determined, generating a damage test case based on the running node information and the execution path information corresponding to the target code.

In the embodiment of the present disclosure, when determining to perform the destructive testing on the object code, the destructive testing case may be generated based on the running node information and the execution path information corresponding to the object code.

In some embodiments, the generating the destruction test case based on the running node information and the execution path information corresponding to the object code may include: simulating external dependency information in the target code by using PowerMockito; designing a destructive testing input based on the operation node information; based on the execution path information and the destructive testing input, a test case is generated using a reflection tool and a code template generation tool.

It should be noted that, the specific implementation manner of generating the destruction test case may refer to the description of the related method embodiments, which is not described herein in detail.

In some embodiments, the determination to perform the corruption test on the object code may be performed within a predetermined time. The predetermined time may be set according to an actual scene, for example, may be executed at night, may be executed at other idle times, and the like, which is not limited in this specification.

In some embodiments, the results of the detection with the set of error information may be output when it is determined that the corruption test is not performed on the object code.

S8: and executing the destructive testing case to obtain an execution result corresponding to the target code.

In the embodiment of the present specification, after the corruption test case is generated, the corruption test case may be executed, and an execution result corresponding to the object code is obtained. The execution result may or may not include error information. The error information may include execution path information, code structure information, parameter information, depth, error type, error stack information, and the like, which correspond to when an error occurs in the process of executing the destructive test case.

In some embodiments, after the corruption test case is generated, the corruption test case may be executed based on the Junit, obtaining an execution result corresponding to the object code.

S10: and determining whether the target code is at risk or not based on the execution result.

In the embodiment of the present specification, after the execution result corresponding to the target code is obtained, it may be determined whether the target code is at risk based on the execution result.

In some embodiments, the determining whether the target code is at risk based on the execution result may include: judging whether error information exists in the execution result; and updating the error information set based on the error information when the existence is determined. Wherein, when there is error information in the execution result, it can be stated that the target code is at risk.

In some implementation scenarios, when the error information exists in the execution result, the error information can be automatically collected and put in storage, so that a self-learning and self-supplementing mechanism of the error library is realized, a data base is provided for the subsequent updating of the error information set, and data is provided for a technician to expand a rule library.

The method of the embodiment of the specification can be introduced in a plug-in mode, so that the non-invasive triggering of the construction pipeline is realized, the dynamic risk inspection is carried out according to codes submitted by developers, and inspection results are fed back to the pipeline (such as a Jenkins pipeline). The Jenkins pipeline is a set of plug-in units, and can realize the landing and implementation of continuous delivery information.

The embodiment of the present disclosure may be applied to a software architecture including a storage module, a logic operation module, and an interaction module. The storage module can mainly store needed relevant basic data, calculation results of the optimization part and all needed relevant parameters, and can be developed through an ORACLE database and a mangoDB at present. The logic operation module mainly can comprise three functions: (1) Interaction with the storage module, storing operation result information and reading various basic information, wherein the operation result information can be developed based on JAVA, and the interaction with the storage module can adopt JPA (Java Persistence API, java persistent layer API) as ORM (Object Relational Mapping) framework; (2) performing a logical calculation: the part mainly carries out numerical calculation and flow control of an algorithm; (3) providing data transfer for the interaction module: as a hierarchy between the presentation layer and the storage layer, the logical operation layer may accept API (Application Programming Interface, application program interface) requests initiated by the interaction layer and return corresponding data. The interaction module mainly comprises three functions: (1) code dynamic risk checking: extracting running node information and execution path information of the code information based on code information submitted by a current user, and performing existing error information set matching and dynamic damage test; (2) information push: based on the output of (1), assembling possible error information, extracting countermeasures or modification suggestions from a rule base, and returning to the constructed pipeline; (3) rule base update: the background analyzes the unknown errors in a batch form and executes corresponding algorithms and provides the technical administrator with further analysis. Currently, front-end technology is developed using an open source framework vue.

In the embodiment of the specification, through analyzing the service codes in the code library, a destructive testing case is generated based on the open source tool component, the detected codes are subjected to destructive testing, related information can be obtained when the destructive testing is successful, the potentially existing runtime problem is found, the discovery capability of the potentially existing problem can be improved, and further a foundation can be laid for problem classification and effective suggestion.

In the embodiment of the specification, a large number of error sets can be obtained by carrying out destructive testing on the tested code, and error categories can be determined by classifying the errors, so that a data basis is provided for updating a subsequent rule base, a direction for indicating error avoidance is carried out for technicians, and a certain support is provided for technical departments in updating code development specifications.

In the embodiment of the specification, when a new user code is scanned, the error type is judged by scanning the code structure and dynamic damage test, so that repeated damage can be effectively avoided, and meanwhile, error information is provided for technical departments, and data and guidance are provided for increasing code development specifications.

In the embodiment of the specification, based on the Jenkins pipeline triggered by the Git submitting operation, the code risk can be effectively checked while no invasion is realized, and a new thought is provided for improving the code quality and avoiding the slow test progress caused by low-level problems.

Of course, the foregoing description is merely illustrative, and the embodiments of the present invention are not limited to the examples described above, and other modifications may be made by those skilled in the art in light of the technical spirit of the present application, and all such modifications are intended to be included in the scope of the present application as long as the functions and effects of the present invention are the same or similar to those of the present application.

From the above description, it can be seen that the embodiment of the present application may acquire the target code, detect the target code based on the error information set, and obtain detection data, where the detection data indicates whether the target code has a risk. Further, whether to execute the destructive test on the target code can be determined based on the process control model under the condition that the detection data does not have risk, when the destructive test is determined to be executed on the target code, a destructive test case can be generated based on the operation node information and the execution path information corresponding to the target code, and then the destructive test case is executed, an execution result corresponding to the target code is obtained, and whether the target code has risk is determined based on the execution result; the process control model is built based on the resource information, the generation time of the destructive testing case, the operation judging time of the destructive testing case and the code error rate. Because the method and the device can selectively execute the damage test on the target code based on the process control model, the code risk detection efficiency can be improved, and the product code quality can be ensured.

In the present specification, each embodiment of the method is described in a progressive manner, and the same and similar parts of each embodiment participate in each other, and each embodiment mainly describes differences from other embodiments. For relevance, see the description of the method embodiments.

Based on the above-mentioned code risk checking method, one or more embodiments of the present disclosure further provide a code risk checking device. The apparatus may include a system (including a distributed system), software (applications), modules, components, servers, clients, etc. that employ the methods described in the embodiments of the present specification in combination with the necessary apparatus to implement the hardware. Based on the same innovative concepts, the embodiments of the present description provide means in one or more embodiments as described in the following embodiments. Because the implementation scheme and the method for solving the problem by the device are similar, the implementation of the device in the embodiment of the present disclosure may refer to the implementation of the foregoing method, and the repetition is not repeated. As used below, the term "unit" or "module" may be a combination of software and/or hardware that implements the intended function. While the means described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and contemplated.

Specifically, fig. 3 is a schematic block diagram of an embodiment of a code risk inspection apparatus provided in the present specification, and as shown in fig. 3, the code risk inspection apparatus provided in the present specification may include: the system comprises an acquisition module 120, a detection module 122, a first determination module 124, a generation module 126, an execution module 128 and a second determination module 130.

An acquisition module 120, which may be used to acquire the object code;

the detection module 122 may be configured to detect the object code based on the error information set, to obtain detection data; the detection data indicates whether the target code is at risk;

a first determination module 124 that may be configured to determine whether to perform a corruption test on the object code based on a process control model if the detection data is not at risk; the process control model is established based on resource information, the generation time of the destructive testing case, the operation judging time of the destructive testing case and the code error rate;

the generating module 126 may be configured to generate a destructive testing case based on the running node information and the execution path information corresponding to the target code, where it is determined to perform the destructive testing on the target code;

An execution module 128, configured to execute the destructive testing case, and obtain an execution result corresponding to the target code;

a second determining module 130 may be configured to determine whether the target code is at risk based on the execution result.

It should be noted that the description of the above apparatus according to the method embodiment may further include other embodiments, and specific implementation manner may refer to the description of the related method embodiment, which is not described herein in detail.

The present specification also provides an embodiment of a code risk inspection device comprising a processor and a memory for storing processor executable instructions which when executed by the processor implement the steps comprising: acquiring an object code; detecting the target code based on an error information set to obtain detection data; the detection data indicates whether the target code is at risk; determining, based on a process control model, whether to perform a corruption test on the object code if the detection data is not risky; the process control model is established based on resource information, the generation time of the destructive testing case, the operation judging time of the destructive testing case and the code error rate; under the condition that the execution of the destructive test on the target code is determined, generating a destructive test case based on the running node information and the execution path information corresponding to the target code; executing the destructive testing case to obtain an execution result corresponding to the target code; and determining whether the target code is at risk or not based on the execution result.

It should be noted that the above description of the apparatus according to the method or device embodiments may also include other implementations. Specific implementation may refer to descriptions of related method embodiments, which are not described herein in detail.

The method embodiments provided in the present specification may be performed in a mobile terminal, a computer terminal, a server, or similar computing device. Taking the example of running on a server, fig. 4 is a hardware configuration block diagram of an embodiment of a code risk inspection server provided in the present specification, which may be the code risk inspection apparatus or the code risk inspection device in the above embodiment. As shown in fig. 4, the server 10 may include one or more (only one is shown in the figure) processors 100 (the processor 100 may include, but is not limited to, a microprocessor MCU or a processing device such as a programmable logic device FPGA), a memory 200 for storing data, and a transmission module 300 for communication functions. It will be appreciated by those of ordinary skill in the art that the configuration shown in fig. 4 is merely illustrative and is not intended to limit the configuration of the electronic device described above. For example, server 10 may also include more or fewer components than shown in FIG. 4, for example, may also include other processing hardware such as a database or multi-level cache, a GPU, or have a different configuration than that shown in FIG. 4.

The memory 200 may be used to store software programs and modules of application software, such as program instructions/modules corresponding to the code risk inspection method in the embodiment of the present disclosure, and the processor 100 executes the software programs and modules stored in the memory 200 to perform various functional applications and data processing. Memory 200 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 200 may further include memory located remotely from processor 100, which may be connected to the computer terminal via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission module 300 is used to receive or transmit data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider of a computer terminal. In one example, the transmission module 300 includes a network adapter (Network Interface Controller, NIC) that can connect to other network devices through a base station to communicate with the internet. In one example, the transmission module 300 may be a Radio Frequency (RF) module for communicating with the internet wirelessly.

The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The method or apparatus according to the above embodiments provided in the present specification may implement service logic by a computer program and be recorded on a storage medium, where the storage medium may be read and executed by a computer, to implement the effects of the schemes described in the embodiments of the present specification. The storage medium may include physical means for storing information, typically by digitizing the information before storing it in an electronic, magnetic, or optical medium. The storage medium may include: means for storing information using electrical energy such as various memories, e.g., RAM, ROM, etc.; devices for storing information using magnetic energy such as hard disk, floppy disk, magnetic tape, magnetic core memory, bubble memory, and USB flash disk; devices for optically storing information, such as CDs or DVDs. Of course, there are other ways of readable storage medium, such as quantum memory, graphene memory, etc.

The code risk checking method or device provided in the present disclosure may be implemented in a computer by executing corresponding program instructions by a processor, for example, implemented on a PC side using the c++ language of a windows operating system, implemented on a linux system, or implemented on an intelligent terminal using, for example, android, iOS system programming languages, and implemented on a processing logic of a quantum computer.

It should be noted that the descriptions of the apparatus, the device, and the system according to the related method embodiments described in the foregoing description may further include other embodiments, and specific implementation manners may refer to descriptions of corresponding method embodiments, which are not described in detail herein.

All embodiments in the application are described in a progressive manner, and identical and similar parts of all embodiments are mutually referred, so that each embodiment mainly describes differences from other embodiments. In particular, for a hardware+program class embodiment, the description is relatively simple, as it is substantially similar to the method embodiment, as relevant see the partial description of the method embodiment.

For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when one or more of the present description is implemented, the functions of some of the modules may be implemented in the same piece or pieces of software and/or hardware, or the modules that implement the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus, devices, systems according to embodiments of the invention. It will be appreciated that these computer program instructions may be implemented by a computer program instruction which may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus 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.

One skilled in the relevant art will recognize that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects.

The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. which are within the spirit and principles of the present application are intended to be included within the scope of the claims.

Claims

1. A code risk inspection method, comprising:

acquiring an object code;

detecting the target code based on an error information set to obtain detection data; the detection data indicates whether the target code is at risk;

determining, based on a process control model, whether to perform a corruption test on the object code if the detection data is not risky; the process control model is established based on resource information, the generation time of the destructive testing case, the operation judging time of the destructive testing case and the code error rate;

under the condition that the execution of the destructive test on the target code is determined, generating a destructive test case based on the running node information and the execution path information corresponding to the target code;

Executing the destructive testing case to obtain an execution result corresponding to the target code;

and determining whether the target code is at risk or not based on the execution result.

2. The method according to claim 1, characterized in that the set of error information is obtained by:

acquiring service codes included in an application code library;

carrying out structural conversion on the service codes to obtain a directed graph corresponding to the service codes; wherein, the directed graph comprises the operation node information of the service codes; the operation node information comprises parameter information and code structure information;

traversing the directed graph by using a breadth-first algorithm to obtain execution path information corresponding to the service codes;

generating a destructive testing case based on the running node information and the execution path information;

executing the damage test case to obtain error information; the error information comprises corresponding execution path information, code structure information and parameter information when errors occur in the process of executing the destructive testing cases;

and preprocessing the error information to obtain an error information set.

3. The method of claim 2, wherein the preprocessing the error information to obtain an error information set comprises:

Combining error information with the same execution path information;

and eliminating secondary error information from the combined error information set to obtain an error information set.

4. The method of claim 1, wherein before the detecting the object code based on the set of error information, comprising:

carrying out structural transformation on the target code to obtain a directed graph corresponding to the target code; the directed graph comprises running node information of the target codes;

traversing the directed graph by using a breadth-first algorithm to obtain the execution path information corresponding to the target code.

5. The method of claim 4, wherein detecting the object code based on the set of error information comprises:

detecting whether a first error information set matched with code structure information of the target code exists in the error information set;

detecting whether a second error information set matched with the execution path information corresponding to the target code exists in the first error information set or not when the second error information set exists;

and if so, detecting whether a third error information set matched with the parameter information corresponding to the target code exists in the second error information set.

6. The method of claim 1, wherein generating a destruction test case based on the run node information and the execution path information corresponding to the object code comprises:

simulating external dependency information in the target code by using PowerMockito;

designing a destructive testing input based on the operation node information;

based on the execution path information and the destructive testing input, a test case is generated using a reflection tool and a code template generation tool.

7. The method of claim 1, wherein the determining whether the object code is at risk based on the execution result comprises:

judging whether error information exists in the execution result;

and updating the error information set based on the error information when the existence is determined.

8. A code risk inspection apparatus, comprising:

the acquisition module is used for acquiring the target code;

the detection module is used for detecting the target code based on the error information set to obtain detection data; the detection data indicates whether the target code is at risk;

a first determination module to determine whether to perform a corruption test on the object code based on a process control model if the detection data is not at risk; the process control model is established based on resource information, the generation time of the destructive testing case, the operation judging time of the destructive testing case and the code error rate;

The generation module is used for generating a destructive testing case based on the running node information and the execution path information corresponding to the target code under the condition that the destructive testing is determined to be executed on the target code;

the execution module is used for executing the destructive testing case and obtaining an execution result corresponding to the target code;

and the second determining module is used for determining whether the target code is at risk or not based on the execution result.

9. A code risk inspection device comprising at least one processor and a memory storing computer executable instructions which when executed by the processor implement the steps of the method of any one of claims 1 to 7.

10. A computer readable storage medium, having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any of claims 1 to 7.