CN113448825A

CN113448825A - Method, device, equipment and storage medium for determining newly added software defect

Info

Publication number: CN113448825A
Application number: CN202010221332.8A
Authority: CN
Inventors: 刘鹏
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2020-03-26
Filing date: 2020-03-26
Publication date: 2021-09-28

Abstract

The application provides a method, a device, equipment and a storage medium for determining a newly added software defect; the method comprises the following steps: executing static scanning under the current directory based on a review operation initiated aiming at the current directory to obtain a first scanning result; when the first scanning result comprises a software defect, acquiring a second scanning result, wherein the second scanning result is obtained by performing static scanning on a reference code file corresponding to the current directory; and determining the newly added software defect of the code file corresponding to the current directory based on the first scanning result and the second scanning result. Therefore, the new software defect generated by code change in the current directory can be accurately determined.

Description

Method, device, equipment and storage medium for determining newly added software defect

Technical Field

The present application relates to the field of computer science and technology, and in particular, to a method, an apparatus, a device, and a storage medium for determining a newly added software defect.

Background

As software development becomes more complex, the size of software code increases accordingly, and at the same time, the number of bugs (bugs) in software increases as the size of software increases. To minimize Bug during software execution, static analysis of software code may be performed to find and correct Bug before execution of the software code. In addition, with the update of the software version, the software code is changed, and new bugs may be introduced into the software code, and many code evaluation standards require that new bugs cannot be introduced, but a static analysis tool cannot distinguish which bugs are newly added, so that the newly added bugs need to be manually checked, and the checking efficiency is low, and the checking is easy to miss.

Disclosure of Invention

The embodiment of the application provides a method, a device and a storage medium for determining software defects, which can accurately determine new software defects generated due to code change in a current directory.

The technical scheme of the embodiment of the application is realized as follows:

the embodiment of the application provides a method for determining a newly added software defect, which comprises the following steps:

executing static scanning under the current directory based on a review operation initiated aiming at the current directory to obtain a first scanning result;

when the first scanning result comprises a software defect, acquiring a second scanning result, wherein the second scanning result is obtained by performing static scanning on a reference code file corresponding to the current directory;

and determining the newly added software defect of the code file corresponding to the current directory based on the first scanning result and the second scanning result.

An embodiment of the present application provides a device for determining a newly added software defect, including:

the first scanning module is used for executing static scanning under the current directory based on review operation initiated aiming at the current directory to obtain a first scanning result;

the first obtaining module is used for obtaining a second scanning result when the first scanning result comprises a software defect, wherein the second scanning result is obtained by performing static scanning on a reference code file corresponding to the current directory;

and the first determining module is used for determining the newly added software defect of the code file corresponding to the current directory based on the first scanning result and the second scanning result.

a memory for storing executable instructions;

and the processor is used for realizing the method provided by the embodiment of the application when executing the executable instructions stored in the memory.

Embodiments of the present application provide a computer-readable storage medium, which stores executable instructions for causing a processor to implement the method provided by the embodiments of the present application when the processor executes the executable instructions.

The embodiment of the application has the following beneficial effects:

in the method for determining a newly added software defect provided in the embodiment of the present application, after receiving an audit operation initiated on a current directory, a static scan is performed under the current directory to obtain a first scan result, if the first scan result includes a software defect, a second scan result obtained by performing the static scan on a reference code file corresponding to the current directory is obtained, and then a newly added software defect of the code file corresponding to the current directory is determined based on the first scan result and the second scan result, because the newly added software defect is obtained by comparing the first scan result of the current directory with the second scan result of the reference code file, all the newly added software defects can be determined, the newly added software defect which is not in a changed code line is avoided from being omitted, and thus the newly added software defect generated due to code change in the current directory can be accurately determined, the accuracy of code review is improved.

Drawings

FIG. 1A is a schematic diagram of a network architecture of a method for determining a defect in newly added software according to an embodiment of the present application;

FIG. 1B is a schematic diagram of a network architecture of a method for determining a new software defect according to an embodiment of the present application;

fig. 2 is a schematic structural diagram of the first terminal 100 according to an embodiment of the present disclosure;

fig. 3 is a schematic flow chart of an implementation of the method for determining a newly added software defect according to the embodiment of the present application;

fig. 4 is a schematic flowchart of another implementation of the method for determining a newly added software defect according to the embodiment of the present application;

fig. 5 is a schematic flowchart of another implementation of the method for determining a newly added software defect according to the embodiment of the present application;

fig. 6 is a schematic diagram of an implementation process of performing code review by using the method for determining a newly added software defect according to the embodiment of the present application.

Detailed Description

In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be described in further detail with reference to the attached drawings, the described embodiments should not be considered as limiting the present application, and all other embodiments obtained by a person of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

In the following description, references to the terms "first \ second \ third" are only to distinguish similar objects and do not denote a particular order, but rather the terms "first \ second \ third" are used to interchange specific orders or sequences, where appropriate, so as to enable the embodiments of the application described herein to be practiced in other than the order shown or described herein.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the present application only and is not intended to be limiting of the application.

1) Program static analysis: refers to a process of analyzing a program by analyzing or checking only syntax, structure, procedure, interface, etc. of the program without running the computer program. Most of the objects analyzed by static programs are source code for a specific version, and some of the objects analyzed by static programs are target code. Static program analysis generally refers to analysis performed in conjunction with a static program analysis tool.

2) The dynamic program analysis refers to program analysis required to be performed in a program.

3) Program understanding, also known as code review, refers to systematic review of computer source code by human, often by software peer review, for the purpose of finding and correcting errors not found at the early stage of software development.

4) Check (Checker): the static analysis tool component finds potential security holes in software, such as memory leakage or array boundary crossing, by analyzing the source code of the program line by line.

5) Static scanning: and (5) executing the static analysis tool.

6) Newly adding a bug: and modifying the bug introduced by the code.

7) Static scan before Code Review (CR, Code Review): a static analysis tool (typically controlled within 3-5 minutes) is selected that is executed quickly and automatically scans the code when the programmer initiates a CR, thus saving the reviewer's time.

In order to better understand the embodiments of the present application, a method for confirming a newly added software defect after modifying a program code and the existing disadvantages in the related art will be described first.

In the related art, the changed file and line number are determined first, and if the line number of the Bug reported by the static analysis tool falls within the changed line number, the Bug is considered to be the newly added Bug.

For example, the following steps are carried out:

determining the changed file and line number includes:

a.cpp 12 13 14 15 20 21

b.cpp 233 234 235 238 239

bug reported by static analysis tool:

BugA at a.h 13

BugB at a.cpp 5

BugC at b.cpp 234

since only the file and line number corresponding to the BugC are in the changed file and line number, the newly added Bug is determined to be the BugC, but the BugA may also be the newly added Bug (for example, the initialization of a member variable is deleted from the constructor in a. cpp, and the Bug reported by the static analysis tool is likely to be reported in the a.h file defined by the member variable).

The disadvantages existing in the related art include: when the Bug reported by the tool is not in the change code column list, the prior art is in the infancy that the Bug is definitely regarded as the Bug of the stock, and then the newly added Bug is easily omitted, and an inaccurate evaluation result is obtained.

Based on this, the embodiment of the present application provides a method for determining a newly added software defect, in which a source program file of a current directory and a corresponding reference code file are respectively statically scanned, and two scanning results are correspondingly obtained. And comparing the two scanning results to determine all the newly added software defects.

An exemplary application of the apparatus implementing the embodiment of the present application is described below, and the apparatus provided in the embodiment of the present application may be implemented as a terminal device. In the following, exemplary applications covering terminal devices when the apparatus is implemented as a terminal device will be explained.

Fig. 1A is a schematic diagram of a network architecture of a method for determining a new software defect according to an embodiment of the present application, as shown in fig. 1A, the network architecture includes: a first terminal 100, a code server 200, a network 300, and a second terminal 400. In order to support an exemplary application, the first terminal 100 and the second terminal 400 are respectively connected to the code server 200 through the network 300, wherein the first terminal 100 may be a software development terminal, the second terminal 400 may be a review terminal, a developer may utilize the first terminal 100 to perform software development and software update, and send newly developed or modified codes to the second terminal 400 to request for code review, at this time, a reviewer may initiate review operation after receiving a code requesting for review, perform static scanning on the code requesting for review to obtain a first scanning result, obtain a reference code corresponding to the code requesting for review or a second scanning result of the reference code from the code server 200, and further compare the first scanning result with the second scanning result, thereby determining a new software defect. After determining the new software defect, the second terminal 400 may determine a review result based on the determined new software defect, and when the review result indicates that the newly developed or changed code may be uploaded to the code server 200, the second terminal 400 uploads the newly developed or changed code to the code server 200 and returns the review result to the first terminal 100; when the review result indicates that the newly developed or changed code cannot be uploaded to the code server 200, the second terminal 200 returns the review result to the first terminal 100 to notify the first terminal 100 of overcoming the defect of the newly added software based on the review result.

Fig. 1B is another schematic diagram of a network architecture of a method for determining a newly added software defect according to an embodiment of the present application, as shown in fig. 1B, the network architecture includes a code server 200, a network 300, and a first terminal 100, where the first terminal 400 may be a development terminal such as a desktop computer, a tablet computer, and a notebook computer, and a developer may perform software development and software update by using the first terminal 100, and may perform code review on a newly developed or modified code on the first terminal 100 to ensure that the code uploaded to the code server 200 does not have a newly added software defect. At this time, the first terminal 100 statically scans a code to be uploaded to the code server 200, obtains a first scanning result, further obtains a reference code corresponding to the code requested to be reviewed or a second scanning result of the reference code from the code server 200, further compares the first scanning result with the second scanning result, thereby determining a newly added software defect, determines a review result based on the determined newly added software defect, and when the review result indicates that a newly developed or changed code can be uploaded to the code server 200, the first terminal 100 uploads the newly developed or changed code to the code server 200; when the review result indicates that it is impossible to upload newly developed or changed code to the code server 200, then the first terminal 100 overcomes the defect of the newly added software based on the review result.

The apparatus provided in the embodiments of the present application may be implemented as hardware or a combination of hardware and software, and various exemplary implementations of the apparatus provided in the embodiments of the present application are described below.

Other exemplary configurations of the first terminal 100 are envisioned in accordance with the exemplary configuration of the first terminal 100 shown in fig. 2, and thus the configuration described herein should not be considered limiting, e.g., some of the components described below may be omitted, or components not described below may be added to accommodate the particular needs of certain applications.

The first terminal 100 shown in fig. 2 includes: at least one processor 110, memory 140, at least one network interface 120, and a user interface 130. Each of the components in the first terminal 100 are coupled together by a bus system 150. It will be appreciated that the bus system 150 is used to enable communications among the components of the connection. The bus system 150 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are labeled as bus system 150 in fig. 2.

The user interface 130 may include a display, a keyboard, a mouse, a touch-sensitive pad, a touch screen, and the like.

The memory 140 may be either volatile memory or nonvolatile memory, and may also include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read Only Memory (ROM). The volatile Memory may be Random Access Memory (RAM). The memory 140 described in embodiments herein is intended to comprise any suitable type of memory.

The memory 140 in the embodiment of the present application is capable of storing data to support the operation of the first terminal 100. Examples of such data include: any computer program for operating on the first terminal 100, such as an operating system and an application program. The operating system includes various system programs, such as a framework layer, a core library layer, a driver layer, and the like, and is used for implementing various basic services and processing hardware-based tasks. The application program may include various application programs.

As an example of the method provided by the embodiment of the present application implemented by software, the method provided by the embodiment of the present application may be directly embodied as a combination of software modules executed by the processor 110, the software modules may be located in a storage medium located in the memory 140, and the processor 110 reads executable instructions included in the software modules in the memory 140, and completes the method provided by the embodiment of the present application in combination with necessary hardware (for example, including the processor 110 and other components connected to the bus 150).

By way of example, the Processor 110 may be an integrated circuit chip having Signal processing capabilities, such as a general purpose Processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or the like, wherein the general purpose Processor may be a microprocessor or any conventional Processor or the like.

The method for determining the newly added software defect provided by the embodiment of the present application will be described in conjunction with the exemplary application and implementation of the terminal provided by the embodiment of the present application.

Referring to fig. 3, fig. 3 is a schematic flow chart of an implementation of the method for determining a newly added software defect provided in the embodiment of the present application, and is applied to the second terminal in fig. 1A and the first terminal in fig. 1B, in the embodiment of the present application, the method for determining a newly added software defect is applied to the second terminal in fig. 1A, and is described with reference to the steps shown in fig. 3.

Step S101, based on the review operation initiated aiming at the current directory, executing static scanning under the current directory to obtain a first scanning result.

Here, in the embodiment of the present application, the review operation may be initiated by a developer corresponding to the first terminal, and may also be initiated by a reviewer corresponding to the second terminal. In actual implementation, the review operation may be an operation of executing a review script, and may also be a button control for starting the review in the review tool by clicking or touching.

After receiving a review operation for initiating review, statically scanning the files under the current directory and obtaining a first scanning result, wherein if the files under the current directory have software defects, namely bugs, the first scanning result comprises the related attribute information of the bugs, and if the files under the current directory do not have bugs, the first scanning file can be empty.

Step S102, when the first scanning result includes a software defect, a second scanning result is obtained.

And the second scanning result is obtained by performing static scanning on the reference code file corresponding to the current directory.

In the implementation of step S102, a second scan file corresponding to the version information may be obtained from the code server according to the version information of the code file included in the current directory, so that the code corresponding to the version information in the code server needs to be statically scanned in advance to obtain the second scan file. Further, when the change of the code in the code server is monitored, the latest code file is statically scanned, so that the timeliness of the second scanning file is ensured.

In addition, when step S102 is implemented, an unchanged directory may be created in the second terminal, a code baseline (base line) may be stored in the unchanged directory, and a static scan may be performed by the second terminal under the unchanged directory, so as to obtain a second scan result.

Step S103, determining the newly added software defect of the code file corresponding to the current directory based on the first scanning result and the second scanning result.

In this embodiment of the present application, the bugs in the first scanning result may be sequentially compared with the bugs in the second scanning result, and since the second scanning result may be considered as a scanning result of the reference code, that is, the bugs in the second scanning result are all stock bugs, if the Bug in the first scanning result exists in the second scanning result, the Bug is considered as the stock Bug, and if the Bug in the first scanning result does not exist in the second scanning result, the Bug is considered as the new Bug.

In some embodiments, as shown in fig. 3, after step S103, step S104 and step S105 may also be performed:

and step S104, determining a review result based on the newly added software defect.

Here, the step S104 may be implemented to determine the result of the review according to the number of the newly added software defects, for example, when the number of the newly added software defects is less than a certain threshold, the result of the review is obtained, and when the number of the newly added software defects is greater than or equal to the threshold, the result of the review is not obtained. In addition, the evaluation result also includes the determined related attribute information of the newly added software defect, such as the type, serial number, file where the newly added software defect exists, line number of the file where the newly added software defect exists, and the like.

And step S105, outputting the evaluation result.

In actual implementation, outputting the review result may be displaying the review result in a display interface of the terminal. In some embodiments, outputting the review result may also be sending the review result to the first terminal or the code server. Also after step S105, the reviewer may select to send the code to be reviewed to the code server based on the review result to update the code in the code server, or not send the code to be reviewed to the code server and send the review result to the developer to notify the developer to solve or avoid bugs existing in the software based on the review result.

In some embodiments, there are two implementations of step S102: the first is to directly obtain the second scanning result from the server, and the second is to perform static scanning on the unchanged directory corresponding to the current directory to obtain the second scanning result, and the following two implementation manners are respectively explained.

When step S102 is implemented in the first implementation manner, then step S102 may be implemented by:

step S1021a, when the first scanning result includes a software defect, obtain version information corresponding to the current directory.

Step S1022a, the request information for obtaining the scan result is sent to the code server.

Wherein the request information carries the version information. And after receiving the request information, the code server analyzes the request information to obtain version information, further determines whether a second scanning file corresponding to the version information is stored, and when the second scanning file corresponding to the version information is stored, carries the second scanning file in a response message and sends the response message to the second terminal.

Step S1023a, receiving the response information sent by the code server, and obtaining a second scanning result carried in the response information.

Here, after receiving the response message sent by the code server, the response message is parsed to obtain a second scanning result.

When the second scanning result is obtained in this way, the second scanning result can be directly obtained from the code server without the need for the second terminal to perform one static scanning, which can improve the processing efficiency of the second terminal. However, in step S1022a, there may be a case that the server only returns a response message indicating that the second terminal failed to acquire the second scanning result when the server receives the request message for acquiring the scanning result and does not find the second scanning result corresponding to the version information, which may result in that the second terminal cannot acquire the second scanning result in this manner. At this point, the second scan may be selected to be acquired in the second manner.

When step S102 is implemented in the second implementation manner, then step S102 may be implemented by:

step S1021b, when the first scanning result includes a software defect, determining an unchanged directory corresponding to the current directory.

Here, the unchanged directory may be the same level of the unchanged directory as the current directory, and in some embodiments may be referred to as the same level of unchanged directory.

The unchanged directory may be created when it is determined that the first scanning result includes the software defect, or may be created after the review operation is initiated. And the content in the unchanged record is the code baseline corresponding to the current directory.

In step S1022b, a static scan is performed under the unchanged directory to obtain a second scan result.

Here, if there is a software defect, that is, a Bug in the file in the unchanged directory, the second scan result may include related attribute information of these bugs, and if there is no Bug in the file in the unchanged directory, the second scan file may be empty.

When the second scan result is obtained in steps S1021b through S1022b, the second terminal needs to perform a static scan to obtain the second scan result, but the second terminal does not fail to obtain the second scan result because the code server does not have the second scan result.

In practical implementation, when step S102 is implemented in the second manner, before step S1021b, it is further necessary to create an unchanged directory and store a reference code in the unchanged directory by the following steps:

step S001, creating the same level unchanged directory of the current directory.

For example, if the current directory is main/app/module b, i.e. module b is in the main/app directory, the peer unchanged directory should also be in the main/app directory, for example, the peer unchanged directory may be main/app/module b _ no _ change.

Step S002, comparing each content in the current directory with the code repository, and determining the first type content and the second type content.

Here, the first type content is content that is not changed from the code repository, and the second type content is content that is changed from the code repository, where the content under the current directory may be a code file or a subdirectory.

And step S003, creating each soft link with the same identification as each first-type content in the unchanged directory, wherein the soft link points to the corresponding first-type content.

In the embodiment of the application, the original file does not need to be stored in the unchanged directory for the first type content, but a soft link with the same name as the first type content is created in the unchanged directory to point to the first type content in the current directory.

For example, if the first type of content is an ab.cpp code file, then a soft link is created in the unaltered directory for the ab.cpp that points to the ab.cpp code file in the current directory.

And step S004, acquiring the reference code file corresponding to the second type of content from the code warehouse.

Here, step S004 can be realized by the following steps;

step S0041, if the second type content is a code file, obtaining a reference code file corresponding to the code file from a code repository, and storing the reference code file in the unchanged directory.

Step S0042, if the second type content is a subdirectory, comparing the content of the subdirectory with a code warehouse, and determining the first type content and the second type content in the subdirectory;

step S0043, creating each soft link with the same identification as each first type content in the subdirectory in the unchanged directory, wherein the soft link points to the corresponding first type content;

step S0044, a reference code file corresponding to the second type of content in the subdirectory is obtained from the code repository.

Here, in step S0044, it is further determined whether or not the second type content in the subdirectory is a file, and if the second type content in the subdirectory is a file, the corresponding reference code file in the code repository is stored in the unchanged directory, and if the second type content is a subdirectory, the method is recursively executed until the second type content is obtained as a file.

Step S005 stores the reference code file in the unchanged directory.

Through the steps S001 to S005, the soft link is established when the content that has not been changed in the current directory is not changed, if the content is changed, the last step is traced back to the changed code file, and the reference code file corresponding to the changed code file is obtained from the code repository and stored in the unchanged directory. Because code files under the current catalog can be hundreds of thousands, and only a few changed files are obtained, all the files can be slowly taken from the code warehouse, the time of the whole process is greatly prolonged, and a code baseline can be obtained very quickly through the implementation mode, so that the review efficiency is improved.

In some embodiments, step S101 may be implemented by:

step S1011, performing static scanning on the code file in the current directory.

Step S1012, when the header file is scanned, comparing the identifier of the header file with a pre-established header file white list;

step S1013, when the identification of the header file exists in the header file white list, scanning the header file;

step 1014, acquiring attribute information of each scanned software defect;

step S1015, determining a first scanning result based on the attribute information of each software defect.

Here, the attribute information at least includes the type of the software defect, the serial number of the software defect, the identification of the file in which the software defect is located, and the row number of the file in which the software defect is located. In practical implementation, in order to prevent the false determination of the software defect caused by the line number change, the step S1015 may be implemented by:

and step S151, performing signature processing on the type of each software defect, the serial number of the software defect, the identification of the file in which the software defect is located and the line number of the file in which the software defect is located to obtain a signature result of each software defect.

In implementation, the MD5 value of "type of software defect, serial number of software defect, identification of file in which the software defect is located, and row number of file in which the software defect is located" may be obtained, and the MD5 value may be used as the signature result of the software defect.

In step S152, the attribute information of each software defect and the corresponding signature result are determined as the first scanning result.

Here, in the first scanning result, one software defect may be counted per row, and when step S152 is implemented, the signature result of each software defect may be stored in the first column of each row, and the attribute information of each software defect may be stored in the subsequent columns in sequence, so that when a new software defect is determined, only the data in the first column may be compared.

On the basis of signing the attribute information of the software defect, step S103 may be implemented by steps S1031 to S1033 as follows:

step S1031, searching each signature result in the first scanning result in the second scanning result.

Here, when step S1031 is implemented, each signature result in the first scan result may be sequentially compared with the signature result in the second scan result, and it may be determined whether the signature result in the first scan result exists in the second scan result, and when a certain signature result in the first scan result exists in the second scan result, it is considered that the software defect corresponding to the signature result is the stock Bug and is not the increment Bug.

In step S1032, a signature result of which the first scan result does not exist in the second scan result is determined as a target signature result.

Here, if a certain signature result in the first scanning result does not exist in the second scanning result, it indicates that the software defect corresponding to the signature result is the incremental Bug, and at this time, the signature result is determined as the target signature result.

Step S1033, determining the software defect corresponding to the target signature result as a new software defect corresponding to the current directory.

In the embodiment of steps S1031 to S1033, the determination of the newly added software defect is implemented by comparing the signature results in the first scanning result and the second scanning result, so that the erroneous determination caused by the line number variation can be avoided.

In some embodiments, since the code files in the unchanged directory are either obtained from a code repository in the code server or pointed to the current directory by soft linking, the replacement of the header path is required before performing a static scan on the unchanged directory by:

step S201, obtaining each header file path in the code file in the current directory.

For example, the current directory includes two header files in the code file, and the corresponding header file paths are main/app/module b/a.h and main/app/module b/b.h.

Step S202, before performing static scanning under an unchanged directory, replacing the identifier of the current directory in each header file path with the identifier of the unchanged directory.

Here, the identifier of the current directory refers to the identifier of the last stage in the current directory path, and similarly, the identifier of the unchanged directory refers to the identifier of the last stage in the unchanged directory path. Taking the current directory as main/app/module b and the unchanged directory as main/app/module b _ no _ change as an example, the last level of the current directory path is identified as module b, and the last level of the unchanged directory path is identified as module b, so that in the implementation of step S202, the last level of the current directory path in the header file path is replaced with the last level of the unchanged directory path, that is, main/app/module b/a.h is replaced with main/app/module b _ no _ change/a.h, and main/app/module b/b.h is replaced with main/app/module b _ no _ change/b.h.

Only after the path of the header file is replaced before the static scan is performed on the unchanged directory through steps S201 to S202, it can be ensured that an erroneous header file is not introduced when the static scan is performed on the code file under the unchanged directory, thereby ensuring correct execution of the static scan.

Based on the foregoing embodiments, an embodiment of the present application further provides a method for determining a newly added software defect, which is applied to the network architecture shown in fig. 1A, and fig. 4 is a schematic view of another implementation flow of the method for determining a newly added software defect provided by the present application, as shown in fig. 4, the method includes:

in step S401, the first terminal updates the code based on the operation of the developer.

Here, in the process of software development or software update, a developer corresponding to the first terminal may need to perform operations such as changing, deleting, or adding on a completed code file, and the first terminal updates the code based on the operations of the developer.

Step S402, after the code updating is completed, the first terminal sends a code review request to the second terminal.

Here, the review request may carry the file of the code to be reviewed, and in some embodiments, the review request may also carry version information of the file of the code to be reviewed, or version information of the reference code in the code server corresponding to the file of the code to be reviewed.

Step S403, after receiving the code review request, the second terminal obtains the code file to be reviewed and stores the code file to be reviewed.

Here, after receiving the code review request, the second terminal parses the code review request to obtain a code file to be reviewed, and stores the code file to be reviewed locally.

And step S404, the second terminal enters the directory where the code file to be evaluated is located and initiates evaluation operation.

Step S405, the second terminal executes static scanning under the current directory based on the review operation initiated aiming at the current directory, and a first scanning result is obtained.

In step S406, the second terminal determines whether the first scanning result includes a software defect.

Here, when the first scanning result includes a software defect, the process proceeds to step S407; when the first scanning result does not include the software defect, the process proceeds to step S416.

Step S407, the second terminal creates an unchanged directory corresponding to the current directory.

Step S408, the second terminal compares each content in the current directory with the code repository to determine the first type content and the second type content.

The first type content is the content which is not changed compared with the code warehouse, the second type content is the content which is changed compared with the code warehouse, and the content is a code file or a subdirectory.

In step S409, the second terminal creates each soft link in the unchanged directory, which is the same as each first-type content identifier.

Here, each soft link points to a corresponding first type of content.

Step S410, the second terminal obtains the reference code file corresponding to the second type of content from the code repository.

In step S411, the second terminal stores the reference code file in the unchanged directory.

Through the steps S407 to S411, a code base line can be quickly obtained from the unchanged directory, and thus the inventory Bug can be determined by statically scanning the unchanged directory.

In step S412, the second terminal performs static scanning on the unchanged directory to obtain a second scanning result.

Here, since the file under the unchanged directory is the reference code file in the code repository, the second scan result obtained by performing the static scan under the unchanged directory is a software defect existing in the reference code file, that is, the stock Bug.

In step S413, the second terminal determines the new software defect of the code file corresponding to the current directory based on the first scanning result and the second scanning result.

Here, in step S413, the first scanning result and the second scanning result may be compared, and if there is a software defect that does not exist in the second scanning result in the first scanning result, that is, there is a new software defect in the code file corresponding to the current directory.

In step S414, the second terminal determines a review result based on the newly added software defect.

Here, when implemented, the step S414 may determine the review result based on a preset rule, where the preset rule may be that when the number of the newly added software defects is less than a preset number threshold, the review result is determined to pass the review, and correspondingly, when the number of the newly added software defects is greater than or equal to the number threshold, the review result is determined to not pass the review. In some embodiments, the predetermined rule may be that a certain type or types of the newly added software defects are smaller than a predetermined number threshold. The number threshold is a positive integer.

In step S415, the second terminal determines whether the review result indicates that the code to be reviewed passes the review.

Here, when the evaluation result represents that the code to be evaluated passes the evaluation, the process proceeds to step S416, and step S417 is executed; and when the evaluation result represents that the code to be evaluated does not pass the evaluation, directly entering the step S417.

In step S416, the second terminal sends the code to be evaluated to the code server.

In some embodiments, the second terminal may further send the review result to the code server at the same time as or after sending the code to be reviewed to the code server, so that other developers or reviewers can query the review result of the code change.

And step S417, the second terminal sends the evaluation result to the first terminal.

Here, the second terminal sends the review result to the first terminal, so that developers corresponding to the first terminal can know the review progress in time, and when the review is not passed, the developers can solve or avoid the defect of the newly added software according to the review result.

In the method for determining the defect of the newly added software, provided by the embodiment of the application, when a developer submits the code to a second terminal for evaluation after completing code updating through a first terminal, the second terminal not only performs static scanning on the code file requiring evaluation, but also needs to scan a reference code file corresponding to the code file requiring evaluation, and then compares the results of the two scans, so that the newly added Bug introduced due to code updating is determined, the evaluation result is obtained, and thus, the phenomenon that the newly added Bug is missed because of wrong line number can be avoided, and the accuracy of evaluation is improved.

Next, an exemplary application of the embodiment of the present application in a practical application scenario will be described.

In an embodiment of the present application, a method for determining a newly added software defect is provided, and fig. 5 is another implementation flowchart of the method for determining a newly added software defect provided in the embodiment of the present application, as shown in fig. 5, the implementation flowchart includes:

in step S501, a static scan command CMD _1 is executed in the current directory. Executing the command scans out the Bug of the current directory and stores the Bug in the Bug _1 file.

Step S502, checking the BUG _1 file, and judging whether the BUG _1 file has the BUG.

If there is a BUG in the BUG _1 file, the step S503 is performed, and if there is no BUG in the BUG _1 file, the step S507 is performed.

In step S503, a DIR _ NO _ CHANGE directory is created.

Step S504, create soft link or take file from code warehouse.

If the sum code warehouse ratio has two CHANGEs, if the sum code warehouse ratio has a CHANGE, a copy is taken from the code warehouse and put into the DIR _ NO _ CHANGE directory, if the sum code warehouse ratio has a CHANGE, the method is called recursively until the file is changed.

The effect that so finally reaches is: if the current directory is not changed, a soft link is established, if the current directory is changed, the code is fetched from the code warehouse, and a code baseline can be quickly obtained under the condition that the current directory is not modified.

In step S505, the directory is switched to DIR _ NO _ CHANGE, and the static scan command CMD _2 is executed.

Executing the static scan command CMD _2 will scan out the Bug of the DIR _ NO _ CHANGE directory and store it in the Bug _2 file.

And step S506, comparing the Bug _1 file with the Bug _2 file to determine the newly added Bug.

Step S507, a null is generated.

Here, in the embodiment of the present application, a signature mechanism may be added to the Bug file generated by the static analysis tool, so that misjudgment caused by row number change may be avoided. Further, one available Bug signature: the MD5 value is evaluated for "checker name + BUG serial number + file name + line code found by the checker in this document" and this signature is placed in the first column of the generated BUG file, and the following contents are separated by space characters, so that step S506, when implemented, traverses each line of the BUG _1 file, uses the 1 st column (i.e. BUG signature) to search in BUG _2, and if not found, is a new BUG.

In the embodiment of the present application, the static scan execution time may be optimized in the following manner:

1. aiming at c/c + + language, adding a head file path white list mechanism, for example, only loading the dependent head files of the module and concerned in the head file path white list;

2. aiming at Jvm type languages, such as java/scala language, adding a package name white list mechanism, such as including the package of the module and the concerned dependent package in the package name white list;

for modules which depend on a lot of modules by using the optimization mode, the reduction of the time required for static scanning is often in order of magnitude, because a static analysis tool usually only pays attention to the module, most other modules cannot be used, but much time is required, and the scanning time after removing the independent header files or packets can be greatly shortened.

In addition, in the embodiment of the present application, the header file path needs to be replaced before static scanning:

for example, a module is called module A, the warehouse path is main/app/module A, and the header file introduction habit is as follows: # include app/module A/a.h

#include common/moduleB/b.h

Then app/moduleA needs to be replaced with app/DIR _ NO _ CHANGE when DIR _ NO _ CHANGE is executing, otherwise an erroneous header file would be introduced.

Fig. 6 is a schematic diagram of an implementation process of performing code review by using the method for determining a newly added software defect according to the embodiment of the present application, and as shown in fig. 6, the process includes:

step S601, the programmer initiates CR in the module directory after modifying the code.

Here, the action to initiate the CR may be to execute a script or click a button control within the IDE.

In step S602, the CR tool sends a request for obtaining new bugs to a tool (hereinafter, referred to as a tool in this embodiment) corresponding to the method for determining a new software defect provided in this embodiment.

Here, the request for obtaining the newly added Bug carries: under the current directory, a command (corresponding to CMD _1) for performing static scanning, a file (corresponding to the output of CMD _1, namely, a Bug _1 file) for storing BUGs, a directory name (namely, DIR _ NO _ CHANGE) which does not contain CHANGEs at the same level to be created (for example, the current directory is main/module a, DIR _ NO _ CHANGE can be module a _ NO _ CHANGE and is also located under the main/directory), and a command (corresponding to CMD _2) for performing static scanning and a file (corresponding to Bug _2 file) for storing BUGs at the same level under the directory which does not contain CHANGEs.

In step S603, the CR tool receives the new Bug information sent by the tool in the embodiment of the present application.

In step S604, the CR tool determines whether a new Bug exists.

Here, the step S604 may be implemented, if the newly added Bug information received by the CR tool is not null, the new Bug is considered to exist, and then the process proceeds to step S605; if the newly added Bug information received by the CR tool is null, the new Bug is considered to exist, and the process proceeds to step S605

Step S605, displaying the Bug.

Here, the display Bug is also the newly added Bug determined by the output display.

Step S606, it is confirmed whether an operation instruction to continue execution is received.

Here, if an operation instruction to continue execution is received, proceed to step S607; if no operation instruction for continuing execution is received, the process proceeds to step S609, and execution is terminated.

In step S607, newly added bugs are organized.

Here, when the step S607 is implemented, the related information of the Bug may be organized, for example, the file where the Bug is located, the Bug serial number, the Bug type, and the like, so as to obtain complete and comprehensive Bug information.

In step S608, a CR is created.

Here, creating a CR may be understood as outputting a CR result based on the newly added Bug organized in step S607.

In step S609, execution is terminated.

It should be noted that, in fig. 6, for convenience of explaining the method for determining the newly added Bug provided in the embodiment of the present application, a CR tool and a tool in the embodiment of the present application are separately shown, and in an actual implementation process, the tool in the embodiment of the present application may be integrated in the CR tool.

In some embodiments, a pipeline may be introduced during implementation of the method provided by the embodiment of the present application, the change of the code warehouse is monitored, the static scanning is executed if there is a change, then the result is stored, a developer performs local scanning after performing the code change, and obtains the scanning result of the corresponding version, and then compares the two scanning results to determine the newly added Bug.

By using the method provided by the embodiment of the application, the static scanning speed can be increased, the waiting time of a developer can be reduced, and the newly added bug of the non-changed code line can be found, so that the burden of CR is reduced, and the risk of missing the bug of the type to the production environment is reduced.

Continuing with the exemplary structure of the determination device 80 for the newly added software defect (hereinafter referred to as the determination device 80) provided in the embodiment of the present application, in some embodiments, as shown in fig. 2, the software modules stored in the determination device 80 of the memory 140 may include:

the first scanning module 81 is configured to execute static scanning under the current directory based on a review operation initiated for the current directory to obtain a first scanning result;

a first obtaining module 82, configured to obtain a second scanning result when the first scanning result includes a software defect, where the second scanning result is obtained by performing static scanning on a reference code file corresponding to the current directory;

and a first determining module 83, configured to determine, based on the first scanning result and the second scanning result, a new software defect of the code file corresponding to the current directory.

In some embodiments, the first obtaining module 82 is further configured to:

when the first scanning result comprises a software defect, determining an unchanged directory corresponding to the current directory;

and executing static scanning under the unchanged directory to obtain a second scanning result.

In some embodiments, the first obtaining module 82 is further configured to:

when the first scanning result comprises a software defect, acquiring version information corresponding to the current directory;

sending request information for obtaining a scanning result to a server, wherein the request information carries the version information;

and receiving response information sent by the server, and acquiring a second scanning result carried in the response information.

In some embodiments, the determining means further comprises:

the first creating module is used for creating an unchanged directory of the current directory;

the second determining module is used for comparing each content in the current directory with the code warehouse and determining a first type of content and a second type of content, wherein the first type of content is unchanged compared with the code warehouse, the second type of content is changed compared with the code warehouse, and the content is a code file or a subdirectory;

a second creating module, configured to create, in the unchanged directory, each soft link that is the same as each first-type content identifier, where the soft link is directed to a corresponding first-type content;

the second acquisition module is used for acquiring the reference code file corresponding to the second type of content from the code warehouse;

and the storage module is used for storing the reference code file to the unchanged directory.

In some embodiments, the second obtaining module is further configured to:

if the second type content is a code file, acquiring a reference code file corresponding to the code file from a code warehouse, and storing the reference code file to the unchanged directory;

if the second type content is a subdirectory, comparing the content of the subdirectory with a code warehouse, and determining the first type content and the second type content in the subdirectory;

creating each soft link with the same identification as each first-type content in the subdirectory in the unchanged directory, wherein the soft link points to the corresponding first-type content;

acquiring a reference code file corresponding to the second type content in the subdirectory from a code warehouse;

and storing the reference code file to the unchanged directory.

In some embodiments, the first scanning module 81 is further configured to:

performing static scanning on the source program under the current directory;

when a header file is scanned, comparing the identifier of the header file with a pre-established header file white list;

when the identification of the header file exists in the header file white list, scanning the header file;

acquiring attribute information of each scanned software defect;

and determining a first scanning result based on the attribute information of each software defect.

In some embodiments, the attribute information at least includes a type of the software defect, a serial number of the software defect, an identifier of the file in which the software defect is located, and a line number of the file in which the software defect is located, and correspondingly, the first scanning module is further configured to:

signing the type of each software defect, the serial number of the software defect, the identification of the file in which the software defect is located and the line number of the file in which the software defect is located to obtain a signature result of each software defect;

and determining attribute information of each software defect and a corresponding signature result as a first scanning result.

In some embodiments, the first determining module 81 is further configured to:

searching each signature result in the first scanning result in the second scanning result;

determining a signature result of which the first scanning result does not exist in the second scanning result as a target signature result;

and determining the software defect corresponding to the target signature result as a newly added software defect corresponding to the current directory.

In some embodiments, the determining means further comprises:

a third obtaining module, configured to obtain each header file path in the code file in the current directory;

and the replacing module is used for replacing the identification of the current directory in each head file path with the identification of the unchanged directory before static scanning is executed under the unchanged directory.

In some embodiments, the determining means further comprises:

the third determining module is used for determining a review result based on the newly added software defect;

and the output module is used for outputting the evaluation result.

Embodiments of the present application provide a storage medium having stored therein executable instructions, which when executed by a processor, will cause the processor to perform the methods provided by embodiments of the present application, for example, the methods as illustrated in fig. 3, 4 and 5.

In some embodiments, the storage medium may be memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories.

In some embodiments, executable instructions may be written in any form of programming language (including compiled or interpreted languages), in the form of programs, software modules, scripts or code, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

By way of example, executable instructions may correspond, but do not necessarily have to correspond, to files in a file system, and may be stored in a portion of a file that holds other programs or data, such as in one or more scripts in a hypertext Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code).

By way of example, executable instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network.

The above description is only an example of the present application, and is not intended to limit the scope of the present application. Any modification, equivalent replacement, and improvement made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A method for determining a newly added software defect is characterized by comprising the following steps:

2. The method of claim 1, wherein obtaining a second scan result when the first scan result includes a software defect comprises:

3. The method of claim 1, wherein obtaining a second scan result when the first scan result includes a software defect comprises:

4. The method of claim 2, further comprising:

creating an unchanged directory corresponding to the current directory;

comparing each content in the current directory with the code warehouse, and determining a first type of content and a second type of content, wherein the first type of content is unchanged compared with the code warehouse, the second type of content is changed compared with the code warehouse, and the content is a code file or a subdirectory;

creating each soft link with the same identification as each first-type content in the unchanged directory, wherein the soft link points to the corresponding first-type content;

acquiring a reference code file corresponding to the second type of content from a code warehouse;

and storing the reference code file to the unchanged directory.

5. The method of claim 4, wherein the obtaining the reference code file corresponding to the second type of content from the code repository comprises:

and storing the reference code file to the unchanged directory.

6. The method of any of claims 1 to 5, the performing a static scan under a current directory resulting in a first scan result, comprising:

performing static scanning on the source program under the current directory;

acquiring attribute information of each scanned software defect;

7. The method of claim 6, wherein the attribute information at least includes a type of the software defect, a serial number of the software defect, an identifier of a file in which the software defect is located, and a line number of the file in which the software defect is located, and correspondingly, the determining the first scanning result based on the attribute information of each software defect includes:

8. The method of claim 7, wherein determining the new software defect corresponding to the current directory based on the first scanning result and the second scanning result comprises:

9. The method of claim 2, further comprising:

acquiring each head file path in the code file in the current directory;

and replacing the identifier of the current directory in each head file path with the identifier of the unchanged directory before performing static scanning under the unchanged directory.

10. The method of claim 1, further comprising:

determining a review result based on the newly added software defect;

and outputting the evaluation result.

11. An apparatus for determining a defect in newly added software, the apparatus comprising:

12. An apparatus for determining a new software defect, comprising:

a memory for storing executable instructions;

a processor for implementing the method of any one of claims 1 to 10 when executing executable instructions stored in the memory.

13. A computer-readable storage medium having stored thereon executable instructions for causing a processor, when executing, to implement the method of any one of claims 1 to 10.