CN113326189A - Method, system and equipment for tracking submission of introduced defects - Google Patents
Method, system and equipment for tracking submission of introduced defects Download PDFInfo
- Publication number
- CN113326189A CN113326189A CN202110586956.4A CN202110586956A CN113326189A CN 113326189 A CN113326189 A CN 113326189A CN 202110586956 A CN202110586956 A CN 202110586956A CN 113326189 A CN113326189 A CN 113326189A
- Authority
- CN
- China
- Prior art keywords
- submission
- git
- issue
- suspected
- command
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000007547 defect Effects 0.000 title claims abstract description 40
- 238000000034 method Methods 0.000 title claims abstract description 30
- 230000008859 change Effects 0.000 claims abstract description 32
- 238000012986 modification Methods 0.000 claims abstract description 28
- 230000004048 modification Effects 0.000 claims abstract description 28
- 238000003491 array Methods 0.000 claims abstract description 6
- 230000006870 function Effects 0.000 claims description 13
- 230000009471 action Effects 0.000 claims description 7
- 230000000977 initiatory effect Effects 0.000 claims description 7
- 238000012545 processing Methods 0.000 claims description 5
- 238000012163 sequencing technique Methods 0.000 claims description 5
- 239000000284 extract Substances 0.000 claims description 3
- 230000001360 synchronised effect Effects 0.000 claims description 3
- 230000008569 process Effects 0.000 abstract description 8
- 238000011160 research Methods 0.000 abstract description 2
- 238000010586 diagram Methods 0.000 description 3
- 239000003607 modifier Substances 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 230000008676 import Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000000275 quality assurance Methods 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3636—Software debugging by tracing the execution of the program
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/366—Software debugging using diagnostics
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The invention discloses a method, a system and equipment for tracking submission of introduced defects, wherein an Issue list of a project is acquired according to an Api interface provided by a code hosting platform; traversing an Issue list to obtain a join request, and obtaining a submission for solving the Issue; synchronizing the local Git library and the remote Git library, and acquiring the submitted Sha values sequenced according to a time reverse order rule by using the local library; traversing the submission arrays for repairing the defects, and acquiring specific submitted change lines by using a 'show' command for each submission; obtaining the latest modification of the modified line according to the modified file path and the modified line by using a 'blank' command, wherein the submission of the latest modification of the modified line is suspected trapping submission; and comparing the creation time of the suspected trapping submission with the creation time of the corresponding Issue to determine the real trapping submission. The method and the system realize accurate identification of the submission of the introduced defects according to the code hosting platform and the version control tool in the software development process, and facilitate team management and relevant research on software quality.
Description
Technical Field
The invention relates to the technical field of software development, in particular to a method, a system and equipment for tracking submission of introduced defects.
Background
The repair of defects is considered one of the most expensive activities in the software maintenance and development process, and with the increasing complexity of software systems, the task of quality assurance is increasingly challenging. Therefore, it is increasingly important to track and predict defects and thus ensure the quality of software products. In the field of software engineering, the SZZ algorithm, a defect tracking algorithm that relies on high-quality historical data, is accepted by a large number of researchers, SZZ is a popular algorithm for identifying incoming defect submissions, while the SZZ algorithm is a more widely used algorithm in the field of software engineering
In the existing research, the SZZ algorithm is implemented mainly based on the annotated row number to locate the defect, however, when the change contains more modifications, the function provided by the version control tool to record the change by the row number cannot ensure the precise location of the change, and therefore, a method capable of locating the function with higher precision is needed to solve the problem.
Disclosure of Invention
The present invention is directed to a method, system and device for tracking incoming defect submissions to solve the problems set forth in the background art.
In order to solve the technical problems, the invention provides the following technical scheme: a method of tracking incoming defect submissions, the system comprising the steps of: the system comprises the following steps:
step S1: constructing an Http interface, and acquiring an Issue list of a certain item on a code hosting platform according to an Api interface provided by the used code hosting platform;
step S2: traversing an Issue list to obtain a relevant join request, and further obtaining and solving the submission of the Issue;
step S3: synchronizing the local Git library and the remote Git library, and acquiring Sha values submitted by sequencing according to a time reverse order rule by using the local Git library;
step S4: traversing the submission arrays for repairing the defects, and acquiring specific submitted change lines by using a 'show' command for each submission;
step S5: traversing the change dictionary array obtained in the step S4, obtaining the submitted Sha value, obtaining the previous submission according to the Sha value array obtained in the step S3 and submitted according to the time reversal rule, obtaining the latest modification of the change line according to the changed file path and the change line path by using the "blank" command, and obtaining the submission to which the latest modification of the change line belongs as the suspected trapping submission.
Further, in the step 1, the step of constructing the Http interface is as follows:
step S101: the action of initiating the Http request is asynchronized by using an asyncio packet;
step S102: using Token with appointed authority to carry out user identity authentication;
step S103: the Http packet is used to construct the Http client.
Further, the authenticity judgment step of the defect causing submission is as follows:
step S501: obtaining and comparing the creation time of suspected trap submission with the creation time of corresponding Issue;
step S502: when the creation time of the suspected trapping submission is detected to be later than the creation time of Issue, the suspected trapping submission is not the real trapping submission; and when the creation time of the suspected trapping submission is detected to be earlier than the creation time of Issue, the suspected trapping submission is the real trapping submission.
Furthermore, all Issue lists in the project are detected, and after the Issue lists in the project are collected, the lists are stored by using the unstructured database MongoDB.
Further, a system for tracking incoming defect submissions, the system comprising:
a code hosting platform: acquiring and storing data of a code hosting platform;
a Git warehouse acquisition end: the local Git warehouse and the remote Git warehouse can be synchronized;
http client: initiating an Http request according to the client and acquiring data;
the Git tool end: several function executions are performed according to commands provided by the Git tool.
The Git tool performs several of the functions including:
adding an associated remote Git warehouse to the local Git warehouse using the Git tool "remote add" command;
using a Git tool 'Git pull' command to pull all data of a remote Git warehouse;
using a Git tool 'rev-list' command to acquire all information and arranging the information according to a time reverse sequence;
tracking suspicion trap submissions using the Git tool "show" command and the "blank" command allows the authenticity of suspicion trap submissions to be identified by the time of creation.
The device includes a computer device including one or more processors, a network adapter, a memory, a cache, an I/O interface, and a bus connecting the processors, network adapter, memory, cache, and I/O interface, an external device, and a display.
The processor executes a plurality of functions and data processing by executing instructions stored in the memory;
the processor extracts the sorted commit sequence from the memory, identifies commit2 ahead of commit1, compares the creation time of the suspected trapped commit with the creation time of the corresponding Issue, and determines that the suspected trapped commit is a true trapped commit if the creation time of the suspected trapped commit is less than the Issue creation time, otherwise, the suspected trapped commit is not the true trapped commit, thereby obtaining the latest modification of the deleted row.
The apparatus is configured to perform a method of implementing any of claims 1 to 4.
The device is used for implementing the system of any one of claims 5 to 6.
Compared with the prior art, the invention has the following beneficial effects:
1. in the invention, an Api interface provided by a platform is used for acquiring project data, and a large amount of data can be provided for software test, so that the difficulty of defect positioning in the software product is reduced, and the tracking and prediction of defects are facilitated;
2. the established Git warehouse can be suitable for software projects controlled by different versions, so that all project information of the project can be acquired, detailed modification information submitted by different versions can be judged by using a Git tool, and the use range of the Git tool includes and is not limited to Linux, and other projects can be used on the Git tool. The invention calls the commit1 by using the Git tool, finds out all the commit information of the commit2 which is the last commit of the commit1 according to the commit1, and finds out the latest modification of the line in a character matching mode, thereby improving the precision of positioning the defects.
Drawings
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the principles of the invention and not to limit the invention. In the drawings:
FIG. 1 is a flow chart illustrating a method for tracking incoming defect submissions in accordance with the present invention;
FIG. 2 is a schematic diagram of the present invention using a Git tool to provide "show" commands;
FIG. 3 is a schematic diagram of the present invention using the Git tool to provide the "blank" command;
FIG. 4 is a schematic flow chart of a system for tracking incoming defect submissions in accordance with the present invention;
fig. 5 is a schematic structural diagram of a computer device according to the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
Referring to fig. 1-5, the present invention provides the following technical solutions:
a method of tracking incoming defect submissions, the system comprising the steps of:
step S1: constructing an Http interface, and acquiring an Issue list of a certain item on a code hosting platform according to an Api interface provided by the used code hosting platform;
the acquired Issue list is an Issue list comprising three states of opening, solved and closing, and in the process of traversing the Issue list, only the Issue in the solved state needs to be processed according to the field of status;
step S2: traversing an Issue list to obtain a relevant join request, and further obtaining and solving the submission of the Issue;
after acquiring the import request for solving Issue, all submissions under the import request need to be acquired because the basic unit of processing in the defect tracking process is a single submission;
step S3: synchronizing the local Git library and the remote Git library, and acquiring Sha values submitted by sequencing according to a time reverse order rule by using the local Git library;
step S4: traversing the submission arrays for repairing the defects, and acquiring specific submitted change lines by using a 'show' command for each submission;
the modification is stored in a dictionary array mode and is stored in a local database MongoDB, specifically, a set is newly created, the modified dictionary array is stored in the set, and the modified dictionary comprises a submitted sha value, a modified file path and modified specific contents;
step S5: traversing the change dictionary array obtained in the step S4, obtaining a submitted Sha value, obtaining a previous submission according to the Sha value array obtained in the step S3 and submitted according to the time reversal rule sequencing, obtaining the latest modification of a change line according to the changed file path and the change line path by using a 'blank' command, wherein the submission to which the latest modification of the change line belongs is suspected trapping submission;
in the process, the code hosting platform GitLab uses a C/S architecture, various Api interfaces are provided for a user to acquire required data, all that is needed before acquiring the data is to construct an Http client,
in the step 1, the step of constructing the Http interface is as follows:
step S101: the action of initiating the Http request is asynchronized by using an asyncio packet;
step S102: using Token with appointed authority to carry out user identity authentication;
step S103: constructing an Http client by using an aiohttp package;
because the action of acquiring the network data needs to consume more time, the Http request is initiated to be asynchronous, so that program blockage can be prevented, and a plurality of requests can be initiated simultaneously; in order to conveniently realize program automation, the Token is not required to be manually acquired every time, and the GitLab provides a private Token generator, can generate the Token with the specified life cycle and the specified authority, and can be generated and acquired by setting a page by a user, so that convenience is brought;
after the Http client object is constructed, a Url needs to be specified for initiating the request. The Url used by the GitLab to initiate the Api request is divided into two parts, the first part is a general part, and specifically comprises: "https:// gitlab. com/api/v 4". The second part provides a specific function, where an Issue list of a certain item needs to be obtained, specifically: "/projects/: id/issues". Wherein, id is the unique identification of the appointed project;
the specific Url given for a GitLab project page: "https:// gitlab. com/tezos/tezos"; com/"is a common part, the first" tezos "identifies the group name to which the item belongs, and the second tezos represents the item name; GitLab allows the unique identification of an item to be represented using a "group name 2F% item name" approach. Therefore, only one Url list needs to be maintained to automatically run the program;
after the client capable of sending the Http request is constructed, the Issue list can be obtained only by sending the Http request to Url of 'https:// gitlab. com/api/v4/projects/tezos 2F% tezos/issues'. Because the GitLab adopts a paging mode to limit the amount of data acquired by Http at one time, only 20 pieces of Issue information can be acquired by one request. To acquire all Issue lists, a loop needs to be constructed before the request is initiated, and when the number of acquired Issue lists is less than 20, the loop exits.
The authenticity judgment step of the defect causing submission is as follows:
step S501: obtaining and comparing the creation time of suspected trap submission with the creation time of corresponding Issue;
step S502: when the creation time of the suspected trapping submission is detected to be later than the creation time of Issue, the suspected trapping submission is not the real trapping submission; and when the creation time of the suspected trapping submission is detected to be earlier than the creation time of Issue, the suspected trapping submission is the real trapping submission.
Detecting all Issue lists in the project, and storing the lists by using an unstructured database MongoDB after the Issue lists in the project are collected;
specifically, a set is created, the Issue information is stored in the set by a field array method, the key of the dictionary is the Sha value, and the changed file dictionary array is used as a value and stored as a dictionary.
A system for tracking incoming defect submissions, the system comprising:
a code hosting platform: acquiring and storing data of a code hosting platform;
a Git warehouse acquisition end: the local Git warehouse and the remote Git warehouse can be synchronized;
http client: initiating an Http request according to the client and acquiring data;
the Git tool end: several function executions are performed according to commands provided by the Git tool.
The Git tool performs several of the functions including:
adding an associated remote Git warehouse to the local Git warehouse using the Git tool "remote add" command;
using a Git tool 'Git pull' command to pull all data of a remote Git warehouse;
using a Git tool 'rev-list' command to acquire all information and arranging the information according to a time reverse sequence;
tracking suspected trapping submission by using a Git tool 'show' command and a 'blank' command, and identifying the authenticity of the suspected trapping submission according to the creation time;
where the "show" command is used to display various types of objects, the Git tool will give all the modifications corresponding to the submission when the submitted Sha value is used as the target object for the "show" command. An example of a full version of the "show" command is "git show 853cbd6d288d4db4ad4e0eb163ceecc7ac043f 9. Wherein "853 cbd6d288d4db4ad4e0eb163ceecc7ac043f 9" is a submitted Sha value. FIG. 2 shows an example of the result of a "show" command. As shown, the "show" command exposes all of the modification information that was submitted at a time. Specifically, first, the "show" command gives the author and date information of this submission, then Git divides the change information in units of files, each change of file starts with a "diff" keyword, followed by a modified file path, Git treats the pre-and modified files as two files. Next, the "show" command gives the detailed information to modify the line. Git separates the change information into two types: add changes and delete changes. If the user modifies a row, it is revealed that the old row is deleted and the new row is added. For newly added property changes, begin with a "+", for deleted property changes, begin with a "-";
in this embodiment, the deletion change is used, and the addition change has no meaning for this embodiment, and the return value of the "show" command may be obtained first, and traversal is performed on the return value. If a line begins with "diff", then the information that follows is the specific modification information that shows a certain file. That is, the "show" command return value is divided into different blocks with "diff" as a key, each block representing information of a file being modified. After the information values are divided into blocks, for each block, a specific path of the file is recorded first. Specifically, using a data structure such as a dictionary, the head "a/" of a path is deleted and stored as a key, and the value is the deleted line group. The way to get the deleted row array is to parse the deleted row by traversing each row and storing the row beginning with "-" into an array. Since there are two lines beginning with the minus sign "- -" in the return value information, this need to be excluded when finding the deleted line, specifically, a judgment is added at the time of traversal, and if it begins with "- -", this item is skipped. After all submitted change information is obtained, the submitted Sha value is used as a key, the changed file dictionary array is used as a value, and the value is stored as a dictionary;
the "blank" command is provided by the Git tool to see the version to which the last modification of each line of each file belongs and the modifier. The "blank" command needs to specify the file path that needs to be viewed, which is also why the step records the file path. The "blank" command provides a number of parameters for the user to customize for use, with the "-b" parameter specifying the submission that is desired to be viewed. In particular, each line of a file in a given one of the submissions can be checked for the most recent modification in that submission using the "-b" parameter. An example using the "blame" command is given here: "git blame-b 853cbd6d288d4db4ad4e0eb163ceecc7ac043f9 README. md". Wherein "853 cbd6d288d4db4ad4e0eb163ceecc7ac043f 9" is the value of Sha in a certain submission. Md is the path of the file that one wants to view, where the file is under the root directory of the project and therefore only the file name needs to be given.
The display format of the blank command is as follows: "commit Sha | code submission Author | submission time | number of rows the code is in the file | actual code"; FIG. 3 shows one example of a "blame" command; as shown in FIG. 3, after specifying the submitted Sha and file path, the Git tool will give the last modification of all the lines of this file in this version. For each row, the submitted Sha value to which the last modification belongs is first given, where the Sha value is a simplified version. Then, in a bracket, a modifier, a modification date, a line number and an actual code are respectively given;
among other things, the "blank" command provided by the Git tool can provide the most recent modifier for each line of code and the submission to which the modification belongs, and thus is tracked using the "blank" command. However, the "blank" command has a characteristic that if the first line1 of the file sample is modified in the commit1, the "blank" command would make it unreasonable to use commit1 as the commit to which the last modification of the line1 belongs, so finding the commit2 before commit1 in chronological order, and using the "blank" command for commit2 would lead to the desired result;
after the commit and file path are specified using the "blank" command, information needs to be obtained about the modified row processed in step(s). After the information of the change line is acquired, the change line is searched by using a character matching mode. Specifically, after obtaining the modified code line1 with the deletion property, finding the code line same as the modified code line1 in the return value of the "blank" command, analyzing the code line, and obtaining the submitted Sha value of the line, wherein the submission is suspected to be a trap submission;
in the process of character matching, the character string needs to be analyzed and then searched by using a regular expression technology. Here, a general regular expression is given: "(; in the regular expression, commit Sha corresponds to submitted Sha value, and as can be seen from the regular expression, the submitted Sha value is regular in a random combination of upper and lower case letters and numbers. The user modifies the person's nickname correspondence, and due to some location reasons, there may be a case where the modified person's nickname is empty, so here the nickname of the modified person is matched in a "+" -manner; time corresponds to the modification time; lineNum corresponds to the row number. content corresponds to the actual code; after matching is completed, the keywords can be used to extract the corresponding information of a certain line.
An apparatus to track incoming defect submissions, the apparatus comprising a computer device, an external device, and a display, the computer device comprising one or more processors, a network adapter, a memory, a cache, an I/O interface, and a bus connecting the processors, network adapter, memory, cache, and I/O interface;
as with FIG. 5, a bus represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor, or a local bus using any of a variety of bus architectures; by way of example, such architectures include, but are not limited to, Industry Standard Architecture (ISA) bus, micro-channel architecture (MAC) bus, enhanced ISA bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus,
the computer device typically includes a variety of computer system readable media. Such media may be any available media that is accessible by a computing device and includes both volatile and nonvolatile media, removable and non-removable media;
the memory is used to store instructions and may include a computer system readable medium in the form of volatile memory, such as Random Access Memory (RAM) and/or cache memory. The computer device may further include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, the storage system may be used to read from and write to non-removable, nonvolatile magnetic media (commonly referred to as "hard disk drives"); a magnetic disk drive for reading from and writing to a removable, nonvolatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, nonvolatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to the bus by one or more data media interfaces. The memory may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention;
the computer device may also communicate with one or more external devices (e.g., keyboard, pointing device, display, etc.), with one or more devices that enable a user to interact with the computer device, and/or with any devices (e.g., network card, modem, etc.) that enable the computer device to communicate with one or more other computing devices. Such communication may be through an input/output (I/O) interface. Also, the computer device may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the internet) through a network adapter. As shown, the network adapter communicates with other modules of the computer device over a bus;
other hardware and/or software modules may be used in conjunction with the computer device, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.
The processor executes a plurality of functions and data processing by executing instructions stored in the memory;
the processor extracts the sorted submission sequence from the memory, identifies the submission commit2 ahead of the submission commit1, compares the creation time of the suspected trapping submission with the creation time of the corresponding Issue, and determines that the suspected trapping submission is a real trapping submission when the creation time of the suspected trapping submission is less than the creation time of the Issue, otherwise, the suspected trapping submission is not the real trapping submission, so that the latest modification of the deleted row can be obtained;
the processor identifies the previous commit2 of the commit1 in the following manner: for the target commit array, two consecutive pointers are created to point to the first and second commit, respectively. Moving both pointers backwards simultaneously, comparing the commit Sha value pointed to by the second pointer to the target Sha value, and if the two pointers are the same, then the commit pointed to by the first pointer is commit 2;
based on the above embodiments, the processor identifies a suspected trap submission according to the following: converting the creating time of the suspected trapped submitted and the corresponding Issue into a time stamp format, comparing the two time stamps, if the time stamp of the creating time of the suspected trapped submitted is less than the event stamp of the creating time of the corresponding Issue, the suspected trapped submitted is the real trapped submitted, otherwise, the suspected trapped submitted is not.
The apparatus is configured to perform a method of implementing any of claims 1 to 4.
The device is used for implementing the system of any one of claims 5 to 6.
Example (b): the method comprises the following specific steps:
step S1: constructing an Http interface, and acquiring an Issue list of a certain item on a code hosting platform according to an Api interface provided by the used code hosting platform;
step S2: traversing an Issue list to obtain a relevant join request, and further obtaining and solving the submission of the Issue;
obtaining an Http request by:
https:// gitlab. com/api/v4/projects/tezos 2F% tezos/merge _ requests/20/commits; "tezos 2F% tezos is the unique identification of the item," 20 "is the unique identification of the join request within the item;
step S3: synchronizing the local Git library and the remote Git library, and acquiring Sha values submitted by sequencing according to a time reverse order rule by using the local Git library;
extracting related information in a reverse order by the following method;
adding the associated remote Git bins through the remote add provided by Git command, wherein the code for adding the associated remote bins is as follows: git remote add origin https// gitlab. com/tezos. git;
after associating a remote Git warehouse, all data of the associated remote Git warehouse is pulled by using a "pull" command provided by a Git tool, a "Git pull origin", and then all information related to all submissions before the initial submission is pulled by using a "Git rev-list853cbd6d288d4db4ad4e0eb163ceec 7ac043f 9", wherein the "853 cbd6d288d4db4ad4e0eb163ceec 7ac043f 9" is used for the initial submission
Step S4: traversing the submission arrays for repairing the defects, and acquiring specific submitted change lines by using a 'show' command for each submission;
step S5: traversing the change dictionary array obtained in the step S4, obtaining the submitted Sha value, obtaining the previous submission according to the Sha value array obtained in the step S3 and submitted according to the time reversal rule, obtaining the latest modification of the change line according to the changed file path and the change line path by using the "blank" command, and obtaining the submission to which the latest modification of the change line belongs as the suspected trapping submission.
It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.
Finally, it should be noted that: although the present invention has been described in detail with reference to the foregoing embodiments, it will be apparent to those skilled in the art that changes may be made in the embodiments and/or equivalents thereof without departing from the spirit and scope of the invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (10)
1. A method of tracking incoming defect submissions, comprising: the system comprises the following steps:
step S1: constructing an Http interface, and acquiring an Issue list of a certain item on a code hosting platform according to an Api interface provided by the used code hosting platform;
step S2: traversing an Issue list to obtain a relevant join request, and further obtaining and solving the submission of the Issue;
step S3: synchronizing the local Git library and the remote Git library, and acquiring Sha values submitted by sequencing according to a time reverse order rule by using the local Git library;
step S4: traversing the submission arrays for repairing the defects, and acquiring specific submitted change lines by using a 'show' command for each submission;
step S5: traversing the change dictionary array obtained in the step S4, obtaining the submitted Sha value, obtaining the previous submission according to the Sha value array obtained in the step S3 and submitted according to the time reversal rule, obtaining the latest modification of the change line according to the changed file path and the change line path by using the "blank" command, and obtaining the submission to which the latest modification of the change line belongs as the suspected trapping submission.
2. A method of tracking incoming defect submissions as claimed in claim 1, wherein: in the step 1, the step of constructing the Http interface is as follows:
step S101: the action of initiating the Http request is asynchronized by using an asyncio packet;
step S102: using Token with appointed authority to carry out user identity authentication;
step S103: the Http packet is used to construct the Http client.
3. A method of tracking incoming defect submissions as claimed in claim 1, wherein: the authenticity judgment step of the defect causing submission is as follows:
step S501: obtaining and comparing the creation time of suspected trap submission with the creation time of corresponding Issue;
step S502: when the creation time of the suspected trapping submission is detected to be later than the creation time of Issue, the suspected trapping submission is not the real trapping submission; and when the creation time of the suspected trapping submission is detected to be earlier than the creation time of Issue, the suspected trapping submission is the real trapping submission.
4. A method of tracking incoming defect submissions as claimed in claim 1, wherein: and detecting all Issue lists in the project, and storing the lists by using the unstructured database MongoDB after the collection of the Issue lists in the project is finished.
5. A system for tracking incoming defect submissions, comprising: the system comprises:
a code hosting platform: acquiring and storing data of a code hosting platform;
a Git warehouse acquisition end: the local Git warehouse and the remote Git warehouse can be synchronized;
http client: initiating an Http request according to the client and acquiring data;
the Git tool end: several function executions are performed according to commands provided by the Git tool.
6. A system for tracking incoming defect submissions as defined in claim 5, wherein: the Git tool performs several of the functions including:
adding an associated remote Git warehouse to the local Git warehouse using the Git tool "remote add" command;
using a Git tool 'Git pull' command to pull all data of a remote Git warehouse;
using a Git tool 'rev-list' command to acquire all information and arranging the information according to a time reverse sequence;
tracking suspicion trap submissions using the Git tool "show" command and the "blank" command allows the authenticity of suspicion trap submissions to be identified by the time of creation.
7. An apparatus for tracking incoming defect submissions, comprising: the device includes a computer device including one or more processors, a network adapter, a memory, a cache, an I/O interface, and a bus connecting the processors, network adapter, memory, cache, and I/O interface, an external device, and a display.
8. An apparatus for tracking incoming defect submissions as defined in claim 7, wherein: the processor executes a plurality of functions and data processing by executing instructions stored in the memory;
the processor extracts the ordered commit sequence from the memory to identify a commit2 ahead of the commit1, compares the creation time of the suspected trapped commit with the creation time of the corresponding Issue, and determines that the suspected trapped commit is a true trapped commit if the creation time of the suspected trapped commit is less than the Issue creation time, otherwise, the suspected trapped commit is not a true trapped commit.
9. An apparatus for tracking incoming defect submissions as defined in claim 7, wherein: the apparatus is configured to perform a method of implementing any of claims 1 to 4.
10. An apparatus for tracking incoming defect submissions as defined in claim 7, wherein: the device is used for implementing the system of any one of claims 5 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110586956.4A CN113326189A (en) | 2021-05-27 | 2021-05-27 | Method, system and equipment for tracking submission of introduced defects |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110586956.4A CN113326189A (en) | 2021-05-27 | 2021-05-27 | Method, system and equipment for tracking submission of introduced defects |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113326189A true CN113326189A (en) | 2021-08-31 |
Family
ID=77421801
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110586956.4A Pending CN113326189A (en) | 2021-05-27 | 2021-05-27 | Method, system and equipment for tracking submission of introduced defects |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113326189A (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040054688A1 (en) * | 2002-09-16 | 2004-03-18 | Sun Microsystems, Inc., A Delaware Corporation | Method and apparatus for controlling component list in issue tracking system |
| CN104615533A (en) * | 2015-01-15 | 2015-05-13 | 南京大学 | Intelligent software defect tracking management method based on mobile instant messaging software |
| CN108932192A (en) * | 2017-05-22 | 2018-12-04 | 南京大学 | A kind of Python Program Type defect inspection method based on abstract syntax tree |
| CN110532019A (en) * | 2019-06-27 | 2019-12-03 | 北京大学 | A kind of method of software code fragment history retrospect |
| CN111459799A (en) * | 2020-03-03 | 2020-07-28 | 西北大学 | Software defect detection model establishing and detecting method and system based on Github |
| CN111913874A (en) * | 2020-06-22 | 2020-11-10 | 西安交通大学 | Software defect tracing method based on syntactic structure change analysis |
-
2021
- 2021-05-27 CN CN202110586956.4A patent/CN113326189A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040054688A1 (en) * | 2002-09-16 | 2004-03-18 | Sun Microsystems, Inc., A Delaware Corporation | Method and apparatus for controlling component list in issue tracking system |
| CN104615533A (en) * | 2015-01-15 | 2015-05-13 | 南京大学 | Intelligent software defect tracking management method based on mobile instant messaging software |
| CN108932192A (en) * | 2017-05-22 | 2018-12-04 | 南京大学 | A kind of Python Program Type defect inspection method based on abstract syntax tree |
| CN110532019A (en) * | 2019-06-27 | 2019-12-03 | 北京大学 | A kind of method of software code fragment history retrospect |
| CN111459799A (en) * | 2020-03-03 | 2020-07-28 | 西北大学 | Software defect detection model establishing and detecting method and system based on Github |
| CN111913874A (en) * | 2020-06-22 | 2020-11-10 | 西安交通大学 | Software defect tracing method based on syntactic structure change analysis |
Non-Patent Citations (1)
| Title |
|---|
| JTAG特工: "软件缺陷智能分析技术(2) - SZZ的基本流程", pages 1 - 4, Retrieved from the Internet <URL:https://blog.csdn.net/lusing/article/details/114949954> * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8341175B2 (en) | Automatically finding contextually related items of a task | |
| US10417265B2 (en) | High performance parallel indexing for forensics and electronic discovery | |
| CN112287914B (en) | PPT video segment extraction method, device, equipment and medium | |
| CN107787491A (en) | Document for reusing the content in document stores | |
| US20220019739A1 (en) | Item Recall Method and System, Electronic Device and Readable Storage Medium | |
| CN110442847B (en) | Code similarity detection method and device based on code warehouse process management | |
| WO2022048210A1 (en) | Named entity recognition method and apparatus, and electronic device and readable storage medium | |
| CN111709527A (en) | Operation and maintenance knowledge map library establishing method, device, equipment and storage medium | |
| CN110569214A (en) | Index construction method and device for log file and electronic equipment | |
| LU503512B1 (en) | Operating method for construction of knowledge graph based on naming rule and caching mechanism | |
| CN114254158B (en) | Video generation method and device, and neural network training method and device | |
| CN114780370A (en) | Data correction method and device based on log, electronic equipment and storage medium | |
| CN110515958A (en) | Data consistency method, apparatus, equipment and storage medium based on big data | |
| WO2022171093A1 (en) | Method and apparatus for constructing personnel relational graph, and electronic device | |
| CN109636303B (en) | Storage method and system for semi-automatically extracting and structuring document information | |
| CN114419631A (en) | Network management virtual system based on RPA | |
| CN116578612A (en) | Lithium battery finished product detection data asset construction method | |
| US20190340540A1 (en) | Adaptive continuous log model learning | |
| CN113326189A (en) | Method, system and equipment for tracking submission of introduced defects | |
| CN111817867A (en) | Method and system for multi-log collaborative analysis in distributed environment | |
| CN115114297A (en) | Data lightweight storage and search method and device, electronic equipment and storage medium | |
| CN115168085A (en) | Repetitive conflict scheme detection method based on diff code block matching | |
| CN113971403A (en) | Entity identification method and system considering text semantic information | |
| CN113190531A (en) | Database migration method, device, equipment and storage medium | |
| CN1841372A (en) | Method and apparatus for helping user to forming structured diagram according to non-structured information source |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210831 |
|
| RJ01 | Rejection of invention patent application after publication |