Software defect processing method, electronic equipment, storage medium and program product

Abstract

The embodiment of the invention provides a software defect processing method, electronic equipment, a storage medium and a program product, and the method comprises the steps: in response to a defect processing instruction for to-be-processed software, determining baseline software corresponding to the to-be-processed software, and obtaining defect information of a target defect existing in the to-be-processed software, the baseline software refers to software of a baseline version; based on the baseline software and the defect information, analyzing the version of the target software introducing the target defect according to a preset defect analysis process; and processing the target defect by adopting a mode corresponding to the version of the target software. According to the technical scheme, automatic processing of software defects is achieved, dependence on human resources is remarkably reduced, the human resource cost is reduced, refined and personalized processing of defects of different sources is achieved, the flexibility and applicability of defect processing are improved, and the efficiency of defect processing is further guaranteed.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method for processing software defects, an electronic device, a computer-readable storage medium, and a computer program product. Background Art

[0002] In the development process of software such as operating systems, developers often choose a version of the software in the upstream kernel repository as a starting point to develop a customized software version. During software development and maintenance, developers also regularly perform code synchronization operations, such as merging patches in the upstream kernel repository into their own versions, or feeding back patches they developed to the upstream kernel repository. Therefore, in the software development process, complex upstream and downstream code dependencies are inevitably formed.

[0003] Due to the complex upstream and downstream code dependencies of software, the defects found in downstream software testing may come from the downstream development process or the code of the upstream kernel repository. In the existing technology, the sources of these defects are analyzed and repaired manually, which not only requires a lot of human resources, but also has low efficiency in defect handling. Summary of the invention

[0004] The embodiments of the present application provide a method for processing software defects, an electronic device, a computer-readable storage medium, and a computer program product to alleviate or solve one or more technical problems existing in the prior art.

[0005] In a first aspect, an embodiment of the present application provides a method for processing software defects, the method comprising: in response to a defect processing instruction for software to be processed, determining the baseline software corresponding to the software to be processed, and obtaining defect information of a target defect existing in the software to be processed, wherein the baseline software refers to a baseline version of software; based on the baseline software and the defect information, analyzing the version of the target software that introduces the target defect according to a preset defect analysis process; and processing the target defect in a manner corresponding to the version of the target software.

[0006] In a second aspect, an embodiment of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory, and the processor implements any method of the embodiment of the present application when executing the computer program.

[0007] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, any method of the embodiment of the present application is implemented.

[0008] In a fourth aspect, an embodiment of the present application provides a computer program product, including a computer program, which implements any method of the embodiments of the present application when executed by a processor.

[0009] In an embodiment of the present application, in response to a defect handling instruction for the software to be processed, the baseline software corresponding to the software to be processed is determined, and based on the defect information of the target defect existing in the baseline software and the software to be processed, the version of the target software that introduces the target defect is analyzed according to a preset defect analysis process, and then the target defect is handled in a manner corresponding to the version of the target software. First, the method is used to realize the automated processing of software defects, which significantly reduces the dependence on human resources, thereby reducing human resource costs, and compared with manual defect processing, the defect processing efficiency is greatly improved, thereby shortening the defect processing cycle. In addition, in the present application, by determining the version of the target software that introduces the target defect, and according to the version that introduces the target defect, the target defect is processed in a corresponding manner, so that the refined and personalized processing of defects from different sources is realized, the flexibility and applicability of defect processing are improved, and the efficiency of defect processing is further guaranteed.

[0010] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the multiple drawings represent the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings only depict some embodiments according to the present application and should not be regarded as limiting the scope of the present application.

[0012] Figure 1 A schematic diagram showing an application scenario of a method for processing software defects provided in an embodiment of the present application; Figure 2 One of the flowcharts of the method for handling software defects provided in the embodiment of the present application is shown; Figure 3 A schematic diagram of a version sequence of software to be processed in a method for processing software defects provided in an embodiment of the present application is shown; Figure 4 A schematic diagram showing a version sequence corresponding to the first upstream software in the method for handling software defects provided in an embodiment of the present application is shown; Figure 5 The second flowchart of the method for handling software defects provided in the embodiment of the present application is shown; Figure 6 A schematic diagram showing the module composition of a software defect processing device provided in an embodiment of the present application is shown; Figure 7 A block diagram of an electronic device provided by an embodiment of the present application is shown. DETAILED DESCRIPTION

[0013] In the following, only some exemplary embodiments are briefly described. As those skilled in the art will appreciate, the described embodiments may be modified in various ways without departing from the concept or scope of the present application. Therefore, the drawings and descriptions are considered to be exemplary in nature and not restrictive.

[0014] To facilitate understanding of the technical solutions of the embodiments of the present application, the following describes the related technologies of the embodiments of the present application. The following related technologies can be combined with the technical solutions of the embodiments of the present application as optional solutions, and they all belong to the protection scope of the embodiments of the present application.

[0015] The following terms will be used in the following text: Code Commit: It is an operation in the version control system. In software development, developers will frequently modify the code to add new features, fix bugs or make other improvements. Code Commit is the operation of recording these changes in the repository of the version control system.

[0016] Baseline Version: A fixed version selected during the software development process and used as a reference for subsequent development, testing, and deployment.

[0017] Upstream Kernel: refers to the original, unmodified kernel source code, which is released by kernel developers and serves as the basis for other modifications and releases. For example, in Linux, the upstream kernel is the starting point and basis for all release kernels, and it contains the latest features and improvements of the kernel.

[0018] Upstream kernel repository: refers to the repository that stores the upstream kernel source code. It is a centralized storage place for kernel code, allowing developers to access, modify and distribute kernel code.

[0019] Downstream Kernel: refers to the version customized and optimized by each distribution according to its own needs based on the upstream kernel source code.

[0020] Downstream kernel repository: refers to the repository maintained by each distribution for storing downstream kernel source code.

[0021] Defect reproduction: refers to the process of re-triggering a software defect on a certain kernel version through specific steps and conditions after the defect is discovered.

[0022] In the development process of software such as operating systems, for example, the Linux operating system, each distribution of the operating system is usually customized or optimized based on a version in the upstream kernel repository. During the development and maintenance of each distribution, developers will also regularly perform code synchronization operations, such as merging patches in the upstream kernel repository into their own versions, or feeding back patches developed by themselves to the upstream kernel repository. Therefore, in the software development process, complex upstream and downstream code dependencies are inevitably formed.

[0023] Due to the complex upstream and downstream code dependencies of software, the defects found in the downstream software testing may come from the downstream development process or the code of the upstream kernel warehouse, that is, the sources of downstream software defects are relatively complex. At present, the defect handling measures are usually that whenever a defect is found in the test, the engineer analyzes the cause of the defect and repairs it. Manual defect handling not only requires a large amount of human resources, but also has low defect handling efficiency. Furthermore, for the defects of downstream software, some defects can be repaired based on the upstream kernel warehouse, some defects need to be repaired manually by engineers, and some defects may not be repaired in a hurry. At present, all of them are analyzed and repaired manually in the same way, and reasonable measures cannot be taken to deal with them according to the actual situation of the defects, which further reduces the efficiency of defect handling.

[0024] In view of this, an embodiment of the present application provides a method for processing software defects. Through the processing flow of software defects provided by the embodiment of the present application, in response to the defect processing instruction for the software to be processed, the baseline software corresponding to the software to be processed is determined, based on the defect information of the target defect existing in the baseline software and the software to be processed, the version of the target software that introduces the target defect is analyzed according to the preset defect analysis process, and then the target defect is processed in a manner corresponding to the version of the target software. Through this method, the automatic processing of software defects is realized, which significantly reduces the dependence on human resources, thereby reducing human resource costs, and compared with manual processing of defects, the processing efficiency of defects is greatly improved, thereby shortening the cycle of defect processing. In addition, in the embodiment of the present application, by determining the version of the target software that introduces the target defect, and according to the version of the target defect, the target defect is processed in a corresponding manner, the refined and personalized processing of defects from different sources is realized, the flexibility and applicability of defect processing are improved, and the efficiency of defect processing is further guaranteed.

[0025] In order to facilitate the understanding of the embodiments of the present application, the application scenario of the method for handling software defects provided in the embodiments of the present application is first briefly described. Figure 1 A schematic diagram of an application scenario of the method for handling software defects provided in an embodiment of the present application is shown. Figure 1 As shown, the application scenario includes a defect handling device 110 and a test client 120, wherein the test client 120 performs data communication with the defect handling device 110. The test client 120 can be deployed on computing devices such as mobile phones, computers, and tablet computers. The defect handling device 110 can be a test device for software testing or other computing devices. The specific form of the defect handling device 110 can be a server, and the hardware entity of the test client 120 can be a mobile phone, a tablet computer, a laptop computer, etc.

[0026] In an application example, when the tester tests that the software to be processed has defects, the test client 120 sends a defect handling instruction for processing the defect process in the software to be processed to the defect handling device 110. Among them, the defect handling instruction may carry the version information of the software to be processed. When implementing this solution, the information carried in the defect handling instruction can be configured according to the actual scenario requirements. Here, only the information that may be carried in the defect handling instruction is exemplarily listed, and it is not a restriction on the information carried by the defect handling instruction sequence. After receiving the above defect handling instruction, the defect handling device 110 determines the corresponding baseline version of the software based on the version information of the software to be processed, and obtains the defect information of the target defect in the software to be processed from the database based on the version information of the software to be processed, and then analyzes the version of the target software that introduces the target defect in the software to be processed according to the preset defect analysis process based on the baseline version of the software and the defect information of the above target defect, and handles the target defect in a manner corresponding to the version of the target software.

[0027] It should be noted that the above application scenarios or application examples provided in the embodiments of the present application are for ease of understanding, and the embodiments of the present application do not specifically limit the application of the technical solution. In addition, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0028] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The several specific embodiments listed can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0029] Figure 2 A flowchart of a method for processing software defects according to an embodiment of the present application is shown. Figure 2 The method shown can be applied to Figure 1 The defect handling device 110 in the application scenario shown. Figure 2 As shown, the method may include step S201, step S202 and step S203.

[0030] Step S201: In response to a defect handling instruction for the software to be processed, the baseline software corresponding to the software to be processed is determined, and defect information of a target defect existing in the software to be processed is obtained. The baseline software refers to a baseline version of the software.

[0031] Step S202: Based on the baseline software and the defect information, the version of the target software that introduces the target defect is analyzed according to a preset defect analysis process.

[0032] Step S203: Process the target defect in a manner corresponding to the version of the target software.

[0033] The above-mentioned software to be processed is software that has been found to have defects after software testing. The above-mentioned software to be processed can be an operating system, such as a Linux operating system, or can be software such as an application program or a small program.

[0034] In the embodiment of the present application, the above-mentioned defect handling instruction is sent by the test client. For example, the tester may trigger the test client to send the defect handling instruction for the software to be processed to the defect handling device 110. The tester may trigger the test client to send the above-mentioned defect handling instruction to the defect handling device 110 by inputting a test command in the test client or clicking a target control on the interface.

[0035] In one embodiment, the above-mentioned defect handling instruction carries the version information of the software to be processed, so that the defect handling device 110 determines the corresponding baseline software according to the version information of the software to be processed. In one embodiment, the defect handling device 110 can obtain the corresponding baseline version from the target database based on the version information of the software to be processed, or can determine the corresponding baseline version from the downstream kernel warehouse based on the version information of the software to be processed. Among them, the version information can be the version number of the software. In addition, the version information can also include the release date, change log and other information of the software. It should be noted that during implementation, the version information of the software to be processed can be configured according to the actual needs of the scenario, as long as the software to be processed can be uniquely identified. The possible information content of the above-mentioned version information is only exemplarily listed here, and it is not a limitation on the version information of the software to be processed.

[0036] In one embodiment, when the software to be processed is tested, if the test result indicates that the software to be processed has a defect, the version information of the software to be processed, the defect information of the defect, and the test related information are stored in the target database. Therefore, in the above step S201, after receiving the defect handling instruction for the software to be processed, the defect handling device 110 searches the target database for the defect information of the target defect of the device to be processed based on the version information of the software to be processed.

[0037] The above defect information represents the description information of the target defect, and may include one or more of the defect number, defect title or defect description information of the target defect. When implementing this solution, the specific information content of the above defect information can be configured according to the actual scenario requirements. The possible information content of the above defect information is only listed here for example, and it is not a limitation of the embodiments of this application.

[0038] In another implementation, the defect handling instruction may also carry defect information of the target defect in the software to be handled. In this case, in the above step S201, the above defect information can be directly obtained from the defect handling instruction.

[0039] In an embodiment of the present application, the above-mentioned baseline version refers to the initial version at the beginning of development of the software to be processed. The baseline version can be a software version in the upstream kernel warehouse or a software version in the downstream kernel warehouse.

[0040] In one embodiment, the above-mentioned preset defect analysis process can be used to indicate the processing flow of analyzing the version of the target software that introduces the target defect. Exemplarily, when analyzing the version of the target software that introduces the target defect according to the preset defect analysis process based on the baseline software and the above-mentioned defect information, it is possible to first detect whether the target defect is introduced from the baseline version, and then further search for the version of the target software that introduces the target defect based on the detection result; in addition, it is also possible to simultaneously detect the version of the target software that introduces the target defect in the baseline version and in each version between the baseline version and the version of the software to be processed. Of course, during implementation, other methods can also be used to determine the version of the target software that introduces the target defect. Here, only two possible implementation methods are listed as examples, and it is not a limitation of the embodiments of the present application.

[0041] After determining the version of the target software that introduces the target defect, the target defect is processed in a manner corresponding to the version of the target software. For example, if the version of the target software is the software version in the upstream kernel warehouse, the target defect can be processed by trying to find a patch in the upstream kernel warehouse, or if the target software version is the software version in the downstream kernel warehouse, an engineer can be notified to repair it.

[0042] The method for processing software defects provided in the embodiment of the present application responds to the defect handling instruction for the software to be processed, determines the baseline software corresponding to the software to be processed, analyzes the version of the target software that introduces the target defect according to the preset defect analysis process based on the defect information of the target defect existing in the baseline software and the software to be processed, and then handles the target defect in a manner corresponding to the version of the target software. First, the method is used to realize the automated processing of software defects, significantly reducing the dependence on human resources, thereby reducing human resource costs, and compared with manual defect processing, it greatly improves the defect processing efficiency, thereby shortening the defect processing cycle. In addition, in the present application, by determining the version of the target software that introduces the target defect, and according to the version that introduces the target defect, the target defect is processed in a corresponding manner, so as to realize the refined and personalized processing of defects from different sources, improve the flexibility and applicability of defect processing, and further ensure the efficiency of defect processing.

[0043] In one embodiment, in the above step S202, based on the baseline software and the above defect information, the version of the target software that introduces the target defect is analyzed according to a preset defect analysis process, which may include the following steps: testing whether the target defect originates from the baseline version according to the above defect information; if not, searching for the version of the target software that introduces the target defect in the software version sequence formed by the baseline software and the software to be processed.

[0044] In the embodiment of the present application, a defect reproduction method can be used to test whether the target defect originates from the baseline version. Exemplarily, a defect reproduction operation of the target defect can be performed on the above-mentioned baseline software. If the target defect can be reproduced on the baseline software, it means that the target defect already exists on the baseline software, that is, the target defect of the software to be processed originates from the baseline software, and the baseline version is determined as the version of the target software. If the target defect cannot be reproduced on the baseline software, it means that the above-mentioned target defect does not originate from the baseline software.

[0045] Usually, during the software development process, developers will frequently modify the software code, such as adding new features, fixing bugs, etc. After each modification, a code submission will be made, and each submission corresponds to a version of the software. Therefore, the software version sequence formed by the baseline software version and the software to be processed may include multiple software versions, and the software version sequence uses the baseline software version as the starting software version and the software to be processed as the end software version. If the target defect does not come from the baseline version, it means that the target defect of the software to be analyzed may come from a version submitted after the baseline version. Therefore, in this case, the version of the target software that introduces the target defect is further searched in each software version of the software version sequence formed by the baseline software and the software to be processed.

[0046] It should be noted that when performing the reproduction operation of the target defect on the baseline software, in addition to the defect information of the target defect, it is also necessary to obtain the environmental information for reproducing the target defect, and the environmental information needs to be consistent with the environment when the target defect is tested in the software to be processed. Exemplarily, the above-mentioned environmental information may include kernel compilation images, kernel compilation scripts, kernel compilation configurations, virtual machine images, and virtual machine startup commands. Of course, some possible test environment information is only listed here by way of example. During actual execution, the specific information content of the above-mentioned environmental information can be configured according to actual needs. In addition, it should be noted that in an embodiment of the present application, the above-mentioned environmental information can be obtained from the target database. Exemplarily, the environmental information when the software to be processed is tested can be searched from the target database based on the version information of the software to be processed, as the environmental information for performing the reproduction operation of the target defect on the baseline software.

[0047] In an embodiment of the present application, by testing whether the target defect originates from the baseline version, it is possible to accurately identify whether the target defect already existed during software development, that is, it is possible to accurately identify whether the target defect is a newly introduced defect or a long-existing defect, thereby avoiding the inefficiency caused by blindly searching for the software version that introduced the defect, and significantly improving the efficiency of defect handling.

[0048] In one embodiment, in the case where the target defect originates from the baseline version, the above step S203, processing the target defect in a manner corresponding to the version of the target software, may include the following steps: marking the target defect with a first label, the first label characterizing that the target defect is a defect that already existed during software development.

[0049] In the embodiment of the present application, the label content of the first label can be represented by any form such as numbers, letters or words. For example, the label content of the first label can be Pre-Existing. Of course, it can also be other in implementation. This is just an exemplary description and is not a limitation of the present application.

[0050] Generally speaking, if the target defect comes from the baseline version, it means that the target defect already existed in the early stage of the development of the software to be processed, and it is not a new defect introduced during the development process. This type of defect does not belong to the category of emergency defects, that is, the processing priority of this type of defect is low. Therefore, the target defect can be marked first, and then processed after the processing of the defects with higher priority is completed.

[0051] In an embodiment of the present application, when determining that the target defect originates from the baseline version, the target defect is marked by using the first label, which not only indicates the source of the target defect, but also indicates that the target defect does not fall into the category of defects that require emergency processing. Such a processing strategy helps relevant personnel to reasonably arrange the processing order according to the actual situation of the target defect, thereby achieving efficient defect processing and ensuring that emergency problems can be resolved in a timely manner.

[0052] In one embodiment, the above-mentioned search for the version of the target software that introduces the target defect in the software version sequence formed by the baseline board and the software to be processed may include the following steps: verifying whether the target defect can be reproduced in the software to be processed; if it can be reproduced, searching for the version of the target software that introduces the target defect in the software version sequence formed by the above-mentioned baseline software and the software to be processed.

[0053] In actual application scenarios, some defects obtained from tests, such as occasional defects, environment-dependent defects, time race condition defects or random hardware defects, may only appear in specific environments or conditions. For this kind of defect, the defect may be found when the software to be processed is tested, but the defect cannot be reproduced again on the software to be processed, that is, the defect disappears on the software to be processed. The defect in this case does not belong to the category of defects that need to be urgently processed. Therefore, when searching for the version of the target software that introduces the target defect in the software version sequence formed by the baseline software and the software to be processed, you can first verify whether the target defect can be reproduced in the software to be processed. If it can be reproduced, then further search for the version of the target software that introduces the target defect in the software version sequence formed by the baseline version and the software to be processed.

[0054] The specific implementation process of verifying whether the target defect can be reproduced in the software to be processed can refer to the description of reproducing the target defect on the baseline software mentioned above, which will not be repeated here.

[0055] In the embodiment of the present application, the version of the target software that introduces the target defect can be searched in the software version sequence formed by the baseline software and the software to be processed by binary search. For ease of understanding, the process of performing the binary search will be described below with reference to the diagram.

[0056] In addition, it should be noted that the above-mentioned baseline software and the software to be processed are both software versions in the downstream kernel warehouse. During implementation, in order to be able to find the version of the target software in the software version sequence formed by the baseline version and the software to be processed, the address of the downstream kernel warehouse can be obtained from the target database, and by accessing the address, the version of the target software can be found in the software version sequence formed by the baseline version and the software to be processed. Exemplarily, in one embodiment, if there are multiple version branches in the downstream kernel warehouse, the version branch corresponding to the software to be processed can also be obtained from the target database, so as to find the target software in the version branch.

[0057] Figure 3 A schematic diagram of the version sequence corresponding to the software to be processed stored in the downstream kernel warehouse in an embodiment of the present application is shown, such as Figure 3As shown, the development of the software to be processed started with the baseline version, and then went through version 1, version 2, version 3, version 4, version 5, version 6 and version 7, and finally the version of the software to be processed was obtained. If it is determined that the target defect does not exist in the software of the baseline version, and the target defect exists in the version of the software to be processed, first determine the version located in the middle position between the baseline version and the version of the software to be processed, that is, version 4, and test whether the target defect exists in the software of version 4. If the target defect does not exist in the software of version 4, it means that the target defect is introduced in the version after version 4. Further determine the version in the middle position between version 4 and the version of the software to be processed, that is, version 6, and test whether the target defect exists in the software of version 6. If the target defect exists in the software of version 6, it means that the target defect is introduced in the version between version 4 and version 5. According to the above binary thinking, further determine the software version where the target defect first appears, that is, the version where the target defect is introduced, as the version of the above target software.

[0058] If the target defect exists in version 4 of the software, it means that the target defect was introduced in the software version between the baseline version and version 4. Then, the version in the middle between the baseline version and version 4, that is, version 2, is further determined to test whether the target defect exists in version 2 of the software. If the target defect exists in the target software of version 2, it means that the target defect was introduced in the software version between the baseline version and version 2. The search is continued according to the above binary search idea until the version where the target defect first appears is found, that is, the version where the target defect is introduced, which is used as the version of the above target software.

[0059] In the embodiment of the present application, by verifying whether the target defect can be reproduced in the software to be processed, it is helpful to determine whether the defect really exists, thereby avoiding the mistaken attribution of non-defect problems to the software version, improving the accuracy of defect judgment, and also helping to accurately locate the specific software version that introduced the target defect. In addition, in the embodiment of the present application, only when the target defect can be reproduced, the version of the target software that introduced the target defect is searched in each software version between the baseline software and the software to be processed, which can avoid some unnecessary search work, reduce resource waste, and further ensure the efficiency of defect processing.

[0060] In one implementation, the method provided in the embodiment of the present application further includes: if the target defect cannot be reproduced in the software to be processed, marking the target defect with a second label, the second label characterizing the target defect as a defect that cannot be stably reproduced.

[0061] In the embodiment of the present application, the label content of the second label can be represented by any form such as numbers, letters or words. For example, the label content of the second label can be Disappear. Of course, it can also be other in implementation. This is just an exemplary description and is not a limitation of the present application.

[0062] Generally speaking, if the target defect obtained when testing the software to be processed cannot be reproduced on the software to be processed again, it means that the target defect has been fixed, or the target defect may only appear in a specific environment or condition. Such defects do not belong to the category of defects that need to be handled urgently, that is, the handling priority of such defects is low. Therefore, the target defect can be marked first, and then handled after the handling of high-priority defects is completed.

[0063] In an embodiment of the present application, when the target defect cannot be reproduced in the software to be processed, the target defect is marked by using a second label to illustrate the situation of the target defect. Such a processing strategy helps relevant personnel to reasonably arrange the processing order according to the actual situation of the target defect, thereby achieving efficient processing of the defect and ensuring that urgent problems can be resolved in a timely manner.

[0064] In addition, it should be noted that when searching for the version of the target software that introduces the target defect in the software version sequence formed by the baseline software and the software to be processed, the version of the target software may be found, or the search may fail. Therefore, if the result of the above search is that the version of the target software cannot be found, the process can be terminated directly, or an engineer can be notified to handle it. The situation of failed search is not within the scope of the embodiment of the present application, so its processing flow will not be described in detail here.

[0065] In an embodiment of the present application, if a version of the target software that introduces the target defect is found in the software version sequence formed by the baseline software and the software to be processed, then in the above step S203, the target defect is processed in a manner corresponding to the version of the target software, which may include the following steps: detecting whether there is a first upstream software version corresponding to the version of the target software in the upstream kernel warehouse of the software to be processed; if so, searching for a patch for repairing the target defect in the software version sequence formed by the first upstream software version and the second upstream software version, and repairing the defect of the software to be processed based on the patch, the second upstream software version being the software version submitted in the upstream kernel warehouse after the first upstream software version; if the first upstream software version does not exist in the upstream kernel warehouse, marking the target defect with a third label, and the third label indicating that the target defect cannot be repaired based on the upstream kernel warehouse.

[0066] The first upstream software version is a software version existing in the upstream kernel warehouse and corresponds to the version of the target software. Exemplarily, the existence of the first upstream software version corresponding to the version of the target software in the upstream kernel warehouse may include the following situations: patches, optimized functions, modified functions, or newly developed functions in the first upstream software version are directly returned to the downstream kernel warehouse, patches or features in the first upstream software version are modified and resubmitted to the downstream kernel warehouse, and features or patches in the downstream kernel warehouse are submitted to the upstream kernel warehouse and merged.

[0067] Usually, only when there is a first upstream software version corresponding to the version of the target software in the upstream kernel warehouse, it means that there may be a patch for repairing the target defect in the upstream kernel warehouse, that is, you can try to find a patch for repairing the target defect from the upstream kernel warehouse. If there is no first upstream software version corresponding to the version of the target software in the upstream kernel warehouse, it means that there is no patch for repairing the target defect in the upstream kernel warehouse, that is, the target defect cannot be repaired based on the upstream kernel warehouse. Therefore, if there is no first upstream software version corresponding to the version of the target software in the upstream kernel warehouse, the target defect can be marked with a third tag to mark that the target defect cannot be repaired based on the upstream kernel warehouse, so that the corresponding method can be selected to handle it according to the actual situation of the target defect.

[0068] The label content of the third label can be represented by any form such as numbers, letters or words. For example, the label content of the third label can be Self-Inflicted, that is, self-inflicted. Of course, it can also be other in implementation. This is just an exemplary description and is not a limitation of the present application.

[0069] In addition, it should be noted that the second upstream software version is a software version submitted after the first upstream software version. Exemplarily, the second upstream software version may be the latest version currently existing in the upstream kernel warehouse.

[0070] Usually, a certain software version in the software version sequence formed by the first upstream software version and the second upstream software version fixes the target defect. Therefore, the above search for a patch for fixing the target defect is actually to search for a software version that fixes the target defect. In one implementation, a binary search technique can be used to search for a software version that fixes the target defect in the software version sequence formed by the first upstream software version and the second upstream software version, and the above patch can be obtained based on the found software version.

[0071] In one embodiment, when detecting whether there is a first upstream software version corresponding to the version of the target software in the upstream kernel warehouse of the software to be processed, the address of the upstream kernel warehouse can be obtained from the target database according to the version information of the software to be processed, and the address of the above-mentioned upstream kernel warehouse can be accessed to detect whether there is the first upstream software version in the upstream kernel warehouse; in another embodiment, after obtaining the address of the upstream kernel warehouse from the target database, the address can be accessed to download the software codes of various versions in the upstream kernel warehouse to the defect handling device, thereby realizing the operation of detecting whether there is the first upstream software version in the upstream kernel warehouse locally on the defect handling device.

[0072] Exemplarily, in one implementation, when there are multiple version branches in the upstream kernel repository, the version branch corresponding to the software to be processed may also be obtained from the target database, thereby enabling the search for the first upstream software version in the version branch.

[0073] In an embodiment of the present application, by detecting whether there is a first upstream software version corresponding to the version of the target software in the upstream kernel warehouse, it can be determined whether the target defect is a defect that can be repaired by the upstream kernel warehouse, and then the target defect can be processed in a corresponding manner according to different detection results. If the above-mentioned first upstream software version exists in the upstream kernel warehouse, the target defect can be directly repaired using the upstream patch, avoiding the need to repair the defect from scratch, significantly improving the repair efficiency, and in addition, it can also avoid repeating the same repair work downstream, saving development resources and time. Furthermore, in an embodiment of the present application, if the above-mentioned first upstream software version does not exist in the upstream kernel warehouse, the situation of the target defect can also be explained by marking the target defect, so that relevant personnel can take appropriate treatment measures according to the actual situation of the target defect, ensuring the efficiency and pertinence of the defect handling.

[0074] In one embodiment, the above-mentioned detection of whether the first upstream software version corresponding to the version of the target software exists in the upstream kernel warehouse of the software to be processed may include the following process: obtaining the version submission information of the target software from the downstream kernel warehouse associated with the software to be processed, and searching for the above-mentioned first upstream software version in the upstream kernel warehouse according to the version submission information.

[0075] The above-mentioned version submission information generally refers to the detailed information recorded in the version control system each time a change is made to the code base (such as adding, modifying or deleting a file). Exemplarily, the above-mentioned version submission information may include version submission identification information, version submission declaration information, version submission title information, version submission author information, version submission time information, version modification content information, etc. When implementing this solution, the information content contained in the obtained version submission information of the target software can be selected according to actual needs.

[0076] In one implementation, the version submission information of the target software may be obtained by executing a Git log command in a downstream kernel repository.

[0077] After obtaining the version submission information of the target software, the first upstream software version can be searched in the upstream kernel warehouse based on the version submission information. Exemplarily, the version submission information can be matched to search the upstream kernel warehouse for version submission information that matches the version submission information of the target software, and the software version corresponding to the matched version submission information is used as the first upstream software version.

[0078] In an embodiment of the present application, a first upstream software version corresponding to the version of the target software is searched in the upstream kernel repository in a manner that matches the version submission information. Since the version submission information contains a detailed record of each code change, the corresponding first upstream software version can be accurately matched by matching the version submission information, thereby ensuring the accuracy of the match, and further ensuring the accuracy and effectiveness of the subsequent repair of the target defects.

[0079] In one embodiment, the obtained version submission information may include identification information of the version submission, declaration information of the version submission, title information of the version submission, and author information of the version submission; accordingly, the above-mentioned search for the first upstream software version in the upstream kernel warehouse based on the version submission information can be implemented through the following process: searching the upstream kernel warehouse for a software version that matches the above-mentioned identification information as the first upstream software version; if the upstream kernel warehouse does not have a software version that matches the above-mentioned identification information, searching the upstream kernel warehouse for a software version that matches the submission identification in the above-mentioned declaration information as the first upstream software version; if the upstream kernel warehouse does not have a software version that matches the submission identification in the above-mentioned declaration information, searching the upstream kernel warehouse for a software version that matches the above-mentioned title information and / or author information as the first upstream software version.

[0080] The identification information of the version submission refers to the identification information that can uniquely identify the version submission, and illustratively, it can be composed of a character string.

[0081] Generally, if the patch, optimized function, modified function or newly developed function in the first upstream software version is directly returned to the downstream kernel warehouse, the first upstream software version and the target software version have the same version submission identification information, so the corresponding first upstream software version can be found by directly matching the version submission identification information. If the patch or feature in the first upstream software version is modified and resubmitted to the downstream kernel warehouse, in this case, the identification information of the first upstream software version and the target software version are not the same, but the declaration information submitted by the target software version will declare which version in the upstream kernel warehouse it comes from, that is, the declaration information contains the submission identification of the first upstream software version, so the corresponding first upstream software version can be found by matching the submission identification in the declaration information. If the feature or patch in the downstream kernel warehouse is submitted to the upstream kernel warehouse and merged, in this case, the corresponding first upstream software version cannot be found through the version submission identification information and the version submission declaration information, so the author information and / or title information in the version submission information can be used to match the first upstream software version in the upstream kernel warehouse.

[0082] Exemplarily, when searching for a software version that matches the identification information of a version submission in the upstream kernel repository, the identification information of the version submission corresponding to the target software can be matched with the identification information of the version submission corresponding to each software version in the upstream kernel repository, respectively, to determine the identification information of the target version submission that matches the identification information of the version submission corresponding to the target software, and determine the software version corresponding to the identification information of the target version submission as the first upstream software version.

[0083] Similarly, when searching for a software version that matches the submission identifier in the declaration information in the upstream kernel repository, the submission identifier in the declaration information corresponding to the target software can be matched with the identification information of the version submissions corresponding to each software version in the upstream kernel repository, and the identification information submitted by the target version that matches the submission identifier in the declaration information corresponding to the target software is determined, and the software version corresponding to the identification information submitted by the target version is determined as the first upstream software version.

[0084] When searching the upstream kernel repository for a software version that matches the identification information and / or author information submitted for the version corresponding to the target software, the following implementation methods may be included: searching the upstream kernel repository for a first upstream software version corresponding to the version of the target software based on the title information in the version declaration information, searching the upstream kernel repository for a first upstream software version corresponding to the version of the target software based on the author information in the version declaration information, and searching the upstream kernel repository for a first upstream software version corresponding to the version information of the target software based on both the version information and the author information.

[0085] For ease of understanding, the following will take the example of searching for the first upstream software version corresponding to the version information of the target software in the upstream kernel warehouse based on both the version information and the author information as an example to describe in detail its specific implementation process. Exemplarily, in one implementation, the title information and author information of the version submission corresponding to the target software are matched with the version submission information corresponding to each software version in the upstream kernel warehouse, and if the version submission information that matches the title information and author information of the version submission corresponding to the target software is matched, the software version corresponding to the version submission information is determined as the first upstream software version.

[0086] The solution provided by the embodiment of the present application, when searching for the first upstream software version corresponding to the version of the target software in the upstream kernel warehouse according to the version submission information corresponding to the target software, first matches based on the identification information of the version submission, and if the first upstream software version cannot be matched, further matches using the submission identification in the declaration information of the version submission, and if the first upstream software version still cannot be matched, further matches using the title information and / or author information of the version submission. By adopting this hierarchical matching and gradually deepening matching method, not only various situations that may exist in version matching are taken into account, and the comprehensiveness and accuracy of the matching are guaranteed; but also when matching, matching is performed in the order from simple information to complex information, which reduces the workload of matching, improves matching efficiency, and thus ensures the efficiency of defect handling.

[0087] In an embodiment of the present application, after a first upstream software version matching the version of the target software is matched in the upstream kernel repository, an operation of searching for a patch for repairing the target defect in the software version sequence formed by the first upstream software version and the second upstream software version is performed. In one embodiment, searching for a patch for repairing the target defect in the software version sequence formed by the first upstream software version and the second upstream software version may include the following process: testing whether the target defect exists in the software of the first upstream software version and the software of the second upstream software version; if it is determined that the target defect exists in the software of the first upstream software version and the target defect does not exist in the software of the second upstream software version, searching for a patch for repairing the target defect in the software version sequence formed by the first upstream software version and the second upstream software version.

[0088] In one implementation, the target defect may be reproduced in the software of the first upstream software version and the software of the second upstream software version to test whether the target defect exists in the software of the first upstream software version and the software of the second upstream software version. The specific implementation process of reproducing the target defect in the software of the first upstream software version and the software of the second upstream software version may refer to the description of the aforementioned embodiment, which will not be repeated here.

[0089] If the above test result indicates that the software of the first upstream software version has the target defect, but the software of the second upstream software version does not have the target defect, it means that a certain software version in the software version sequence formed by the first upstream software version and the second upstream software version has fixed the target defect, that is, a patch that can be used to fix the target defect may exist in the software version sequence formed by the first upstream software version and the second upstream software version. In this case, an operation of searching for a patch for fixing the target defect in the software version sequence formed by the first upstream software version and the second upstream software version is performed.

[0090] In an embodiment of the present application, when searching for a patch for repairing a target defect in a software version sequence formed by a first upstream software version and a second upstream software version, first test whether the target defect exists in the software of the first upstream software version and the software of the second upstream software version. By testing whether the target defect exists in the software of the first upstream software version, it is further ensured that the target defect is indeed introduced by the upstream kernel warehouse. By testing whether the target defect exists in the software of the second upstream software version, it can be confirmed whether the target defect has been repaired in the upstream kernel warehouse. When the target defect exists in the software of the first upstream software version and the target defect does not exist in the software of the second upstream software version, the patch for repairing the target defect is searched in each software version between the first upstream software version and the second upstream software version. This can avoid some unnecessary search work, reduce resource waste, and thus achieve more efficient and accurate defect processing.

[0091] It should be noted that testing whether the target defect exists in the software of the first upstream software version and the software of the second upstream software version may include the following test results: the target defect does not exist in the first upstream software version, the target defect exists in the second upstream software version, and the target defect also exists in the software of the second upstream software version.

[0092] Therefore, the method provided by the embodiment of the present application also includes the following steps: if it is determined that the software of the first upstream software version does not have the target defect, perform an operation of marking the target defect using a third label; and / or, if it is determined that the software of the second upstream software version has the target defect, use a fourth label to mark the above target defect, and the fourth label characterizes the target defect as a defect existing in the upstream version.

[0093] The label contents of the third label and the fourth label can be represented in any form such as numbers, letters or words. For example, the label content of the third label can be Self-Inflicted, which means self-inflicted, and the label content of the fourth label can be Upstream-Bug, which means upstream defect. Of course, it can also be other in implementation. This is just an exemplary description and is not a limitation of the present application.

[0094] It should be noted that if the target defect does not exist in the first upstream software version, it means that the target defect cannot be repaired based on the upstream kernel repository. In this case, it may be introduced during the process of merging patches or features from the upstream repository. In this case, the target defect cannot be repaired through the upstream kernel repository, and engineers may need to intervene to repair it.

[0095] In one embodiment, when testing whether the target defect exists in the software of the first upstream software version and the software of the second upstream software version, the testing of the software of the first upstream software version and the testing of the software of the second upstream software version can be performed simultaneously, or the order of precedence can be distinguished. Preferably, the software of the first upstream software version can be tested first to see whether the target defect exists. If the test result indicates that the software of the first upstream software version does not exist the target defect, it means that the target defect cannot be repaired based on the upstream kernel repository, that is, there is no need to perform subsequent operations, and the process can be directly terminated.

[0096] If the first upstream software version has the target defect, and the second upstream software version also has the target defect, it means that the target defect has not been fixed in the upstream kernel repository, that is, the target defect belongs to the upstream defect. In this case, the target defect can be described by marking.

[0097] Therefore, in an embodiment of the present application, when it is determined that the target defect does not exist in the software of the first upstream software version, or when it is determined that the target defect exists in the software of the second upstream software version, the target defect is marked by using a corresponding label, which not only indicates that the target defect does not fall into the category of defects that require emergency processing, but also explains the introduction of the target defect. Such a processing strategy helps relevant personnel to reasonably arrange the processing order according to the actual situation of the target defect, thereby achieving efficient processing of defects and ensuring that emergency problems can be resolved in a timely manner.

[0098] In one embodiment, the above-mentioned searching for a patch for repairing the target defect in the software version sequence formed by the first upstream software version and the second upstream software version may include the following steps: searching for the first appearance of a third upstream software version without the target defect in the software version sequence formed by the first upstream software version and the second upstream software version by a binary search method, generating a difference file between the software of the third upstream software version and the software of the fourth upstream software version as the above-mentioned patch, the fourth upstream software version being the software version submitted last time before the third upstream software version.

[0099] Exemplarily, the second upstream software version may be the latest software version in the upstream kernel repository.

[0100] Normally, for each software version in the software version sequence formed by the first upstream software version and the second upstream software version, the first software version that does not have the target defect is considered to have fixed the target defect, that is, the software of this software version carries a patch for fixing the target defect.

[0101] For ease of understanding, the following will describe, in conjunction with an embodiment, a process of searching for a third upstream software version in a software version sequence formed by a first upstream software version and a second upstream software version using a binary search technique. Figure 4 A schematic diagram of the version sequence corresponding to the first upstream software version in the embodiment of the present application is shown, such as Figure 4 As shown, there are version A, version B, version C, version D and version E between the first upstream software version and the second upstream software version, among which version A, version B, version C, version D and version E are submitted in sequence after the first upstream software version. Therefore, the software version sequence formed by the first upstream software version and the second upstream software version is the first upstream software version, version A, version B, version C, version D, version E and the second upstream software version.

[0102] If it is determined that the software of the first upstream software version has the target defect, and the software of the second upstream software version does not have the target defect, when searching for the third upstream software version through the binary search technology, first determine the version in the middle position between the first upstream software version and the second upstream software version, that is, version C, and test whether the software of version C has the target defect; if the software of version C does not have the target defect, it means that the target defect has been fixed before version C, that is, the patch may exist in the software of version C or in the software version before version C, and further verification is required. That is, determine the version between the first upstream software version and version C. In this embodiment, the middle position between the first upstream software version and version C is two software versions, that is, version A and version B. Any one of version A or version B can be selected as the software version in the middle position between the first upstream software version and version C. Exemplarily, version B is selected as the software version in the middle position between the first upstream software version and version C, and test whether the software of version B has the target defect.

[0103] If version B of the software has the target defect, since the adjacent software version after version B is version C, and the software of the previously tested version C does not have the target defect, it can be concluded that version C is the first software version in the software version sequence that does not have the target defect, that is, there is a patch in version C to fix the target defect, that is, the above version C is the third upstream software version that needs to be found.

[0104] In one implementation, a git-diff command may be executed in the upstream kernel repository to compare the differences between the third upstream software version and the fourth upstream software version to obtain a corresponding difference file. Exemplarily, the commit hash values ​​of the third upstream software version and the fourth upstream software version may be obtained, and when the git-diff command is executed in the upstream kernel, the commit hash values ​​of the two software versions are passed as parameters. For example, a possible form of the executed git-diff command is as follows: git diff<commit_hash1><commit_hash2> ,in,<commit_hash1> is the commit hash of the third upstream software version,<commit_hash2> It is the commit hash value of the fourth upstream software version. After executing the git-diff command in the upstream kernel repository, git-diff will output the difference file between the two software versions. Among them, the difference file is used to characterize the changes in the software content of the two versions, such as which lines are added (marked with +), which lines are deleted (marked with -), etc.

[0105] In the embodiment of the present application, the target defect does not exist in the software of the third upstream software version, and the target defect exists in the software of the fourth upstream software version. Therefore, there is a patch for repairing the target defect in the software of the third upstream software version, but there is no patch for repairing the target defect in the software of the fourth upstream software version. Therefore, the above-mentioned patch can be determined by comparing the difference between the software of the third upstream software version and the software of the fourth upstream software version. Therefore, in the embodiment of the present application, a difference file between the software of the third upstream software version and the software of the fourth upstream software version is generated, and the software to be processed is repaired based on the difference file.

[0106] After obtaining the difference file, the difference file is merged into the downstream kernel repository as a patch package, so as to modify the software to be processed based on the difference file, thereby repairing the target defects existing in the software to be processed.

[0107] In an embodiment of the present application, a third upstream software version is searched between the first upstream software version and the second upstream software version by a binary search method, and the search range is halved each time. This can quickly narrow the search range and reduce unnecessary version checks, thereby saving time and resources and further improving the efficiency of defect handling.

[0108] In one embodiment, after the above-mentioned difference file is merged into the downstream kernel warehouse, in order to verify whether the target defect existing in the software to be processed has been repaired, a test may be further performed to determine whether the software to be processed has the target defect. Exemplarily, the above-mentioned test may be implemented by reproducing the operation of the target defect on the software to be processed. If the target defect cannot be reproduced on the software to be processed, it means that the target defect existing in the software to be processed has been repaired. At this time, the target defect may be marked with a fifth tag, which is used to indicate that the target defect is repairable.

[0109] Exemplarily, the label content of the fifth label can be represented by any form such as numbers, letters or words. Exemplarily, the label content of the fifth label can be Patchable, which means repairable. Of course, it can also be other in implementation. This is just an exemplary description and is not a limitation of the present application.

[0110] To facilitate understanding of the method provided in the embodiments of the present application, the following description will be given in conjunction with the embodiments. Figure 5 The flowchart of the method for handling software defects provided by the embodiment of the present application is shown. For the target defect existing in the software to be processed, firstly test whether the target defect originates from the baseline version. If so, mark the target defect with the first label, that is, characterize the target defect as a defect that already existed during development. If it is determined that the target defect does not originate from the baseline version, test whether the target defect can be reproduced on the software to be processed. If the target defect cannot be reproduced on the software to be processed, mark the target defect with the second label, that is, characterize the target defect as a defect that cannot be stably reproduced.

[0111] If the target defect can be reproduced on the software to be processed, the version of the target software that introduces the target defect is searched in the software version sequence formed by the baseline version and the software to be processed through binary search; if the version of the target software cannot be found, the process is terminated; if the version of the target software is found, the upstream kernel warehouse is searched to see whether there is a first upstream software version that matches the version of the target software.

[0112] If the first upstream software version does not exist in the upstream kernel warehouse, the target defect is marked with the third label, which indicates that the target defect cannot be repaired based on the upstream kernel warehouse; if the first upstream software version exists in the upstream kernel warehouse, test whether the target defect can be reproduced on the software of the first upstream software version. If it cannot be reproduced, the target defect is marked with the third label. If the target defect can be reproduced on the software of the first upstream software version, test whether the target defect can be reproduced on the latest version of the software in the upstream kernel warehouse. If it can be reproduced, the target defect is marked with the fourth label, which indicates that the target defect is an upstream defect; if the target defect cannot be reproduced on the latest version of the software in the upstream kernel warehouse, the third upstream software version that does not have the target defect is searched for the first time in the software version sequence formed by the first upstream software version and the latest version by binary search, and a difference file between the software of the third upstream software version and the software of the fourth upstream software version is generated as a patch for repairing the target defect, and the difference file is merged into the downstream kernel warehouse to repair the target defect of the software to be processed, and the target defect is marked with the fifth label to indicate that the target defect is repairable.

[0113] Corresponding to the method provided in the embodiment of the present application, based on the same idea, the embodiment of the present application also provides a software defect processing device, Figure 6 The schematic diagram of the module composition of the software defect processing device provided in the embodiment of the present application is shown. The device can be configured in Figure 1 In the defect handling device 110 in the application scenario shown. The device can execute the embodiment of the present application Figure 2 and Figure 5 The method provided by any of the embodiments shown. Figure 6 As shown, the software defect processing device may include: a determination module 601, which is used to determine the baseline software corresponding to the software to be processed in response to the defect processing instruction for the software to be processed, and the baseline software refers to the baseline version of the software; an acquisition module 602, which is used to obtain the defect information of the target defect existing in the software to be processed; an analysis module 603, which is used to analyze the version of the target software that introduces the target defect according to a preset defect analysis process based on the above-mentioned baseline software and defect information; a processing module 604, which is used to process the target defect in a manner corresponding to the version of the target software.

[0114] In one embodiment, the analysis module 603 is specifically used to: test whether the target defect originates from the baseline version according to the defect information; if not, search for the version of the target software that introduces the target defect in the software version sequence formed by the baseline software and the software to be processed.

[0115] In one implementation, if the target defect originates from the baseline version, the processing module 604 is specifically configured to: mark the target defect with a first label, where the first label indicates that the target defect is a defect that already existed during software development.

[0116] In one embodiment, the analysis module 603 is further used to: verify whether the target defect can be reproduced in the software to be processed; if it can be reproduced, search for the version of the target software that introduces the target defect in the software version sequence formed by the baseline software and the software to be processed.

[0117] In one embodiment, the device provided in the embodiment of the present application also includes: a first marking module, which is used to mark the target defect with a second label if the target defect cannot be reproduced in the software to be processed, and the second label characterizes the target defect as a defect that cannot be stably reproduced.

[0118] In one embodiment, if a version of the target software that introduces the target defect is found in the software version sequence formed by the baseline software and the software to be processed, the above-mentioned processing module 604 is specifically used to: detect whether there is a first upstream software version corresponding to the version of the target software in the upstream kernel warehouse of the software to be processed; if so, search for a patch for repairing the target defect in the software version sequence formed by the first upstream software version and the second upstream software version, and perform defect repair on the software to be processed based on the patch, the second upstream software version being the software version submitted in the upstream kernel warehouse after the first upstream software version; otherwise, mark the target defect with a third label, and the third label indicates that the target defect cannot be repaired based on the upstream kernel warehouse.

[0119] In one implementation, the processing module 604 is further specifically configured to: obtain version submission information of the target software from a downstream kernel repository associated with the software to be processed; and search for a first upstream software version in an upstream kernel repository according to the version submission information.

[0120] In one embodiment, the version submission information includes identification information of the version submission, declaration information of the version submission, title information of the version submission and author information of the version submission; the processing module 604 is further specifically used to: search for a software version matching the identification information in the upstream kernel warehouse as the first upstream software version; if there is no software version matching the identification information in the upstream kernel warehouse, search for a software version matching the submission identification in the declaration information in the upstream kernel warehouse as the first upstream software version; if there is no software version matching the submission identification in the declaration information in the upstream kernel warehouse, search for a software version matching the title information and / or author information in the upstream kernel warehouse as the first upstream software version.

[0121] In one embodiment, the processing module 604 is further specifically used to: test whether there is a target defect in the software of the first upstream software version and the software of the second upstream software version; if it is determined that the target defect exists in the software of the first upstream software version and the target defect does not exist in the software of the second upstream software version, then search for a patch for repairing the target defect in the software version sequence formed by the first upstream software version and the second upstream software version.

[0122] In one embodiment, the processing module 604 is further specifically used to: search for the first appearance of a third upstream software version that does not have a target defect in a software version sequence formed by the first upstream software version and the second upstream software version by a binary search method; generate a difference file between the software of the third upstream software version and the software of the fourth upstream software version as the patch, and the fourth upstream software version is the software version submitted last time before the third upstream software version.

[0123] In one embodiment, the device provided by the embodiment of the present application also includes: a second marking module, which is used to mark the target defect with a third label if it is determined that the software of the first upstream software version does not have the target defect; and / or, which is used to mark the target defect with a fourth label if it is determined that the software of the second upstream software version has the target defect, and the fourth label characterizes the target defect as a defect existing in the upstream version.

[0124] The functions of each module in each device in the embodiments of the present application can be found in the corresponding description in the above method, and have corresponding beneficial effects, which will not be repeated here.

[0125] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can refer to the partial description of the method embodiments. The device embodiments described above are merely schematic, wherein the modules described as separate components may or may not be physically separated, and the components illustrated as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present application. A person of ordinary skill in the art can understand and implement it without creative work.

[0126] Understandably, Figure 6 The division of the various modules is only a division of logical functions. In actual implementation, the functions of the above modules can be integrated into the defect handling device for implementation. For example, the determination module 601, the acquisition module 602, the analysis module 603 and the processing module 604 can be integrated into the processor of the defect handling device for implementation.

[0127] Figure 7 FIG. 1 is a block diagram of an electronic device used to implement an embodiment of the present application. Figure 7 As shown, the electronic device includes: a memory 701 and a processor 702, and the memory 701 stores a computer program that can be run on the processor 702. When the processor 702 executes the computer program, the method in the above embodiment is implemented. The number of the memory 701 and the processor 702 can be one or more. In a specific implementation, the electronic device may also include a communication interface 703 for communicating with external devices and performing data exchange transmission.

[0128] In specific implementation, if the memory 701, the processor 702 and the communication interface 703 are implemented independently, the memory 701, the processor 702 and the communication interface 703 can be connected to each other through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0129] Optionally, in a specific implementation, if the memory 701, the processor 702 and the communication interface 703 are integrated on a chip, the memory 701, the processor 702 and the communication interface 703 can communicate with each other through an internal interface.

[0130] An embodiment of the present application provides a computer-readable storage medium storing a computer program, which implements the method provided in the embodiment of the present application when the program is executed by a processor.

[0131] An embodiment of the present application provides a computer program product, including a computer program, which implements the method provided in the embodiment of the present application when executed by a processor.

[0132] An embodiment of the present application also provides a chip, which includes a processor for calling and executing instructions stored in the memory from the memory, so that a communication device equipped with the chip executes the method provided by the embodiment of the present application.

[0133] An embodiment of the present application also provides a chip, including: an input interface, an output interface, a processor and a memory, wherein the input interface, the output interface, the processor and the memory are connected via an internal connection path, and the processor is used to execute the code in the memory. When the code is executed, the processor is used to execute the method provided in the embodiment of the application.

[0134] It should be understood that the above processor can be a processor (Central Processing Unit, CPU), and can also be other general-purpose processors, digital signal processors (Digital Signal Processor, DSP), application-specific integrated circuits (Application Specific Integrated Circuit, ASIC), field programmable gate arrays (Field Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc. It is worth noting that the processor can be a processor that supports the Advanced RISC Machines (ARM) architecture.

[0135] Further, optionally, the above-mentioned memory may include a read-only memory and a random access memory. The memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory. Among them, the non-volatile memory may include a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may include a random access memory (RAM), which is used as an external cache. By way of exemplary but not limiting description, many forms of RAM are available. For example, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM) and direct memory bus random access memory (DR RAM).

[0136] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.

[0137] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine different embodiments or examples described in this specification and the features of different embodiments or examples, unless they are contradictory.

[0138] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0139] Any process or method described in the flow chart or otherwise described herein can be understood as a module, fragment or portion of a code representing one or more executable instructions for implementing the steps of a specific logical function or process. And the scope of the preferred embodiment of the present application includes other implementations, in which the functions may not be performed in the order shown or discussed, including in a substantially simultaneous manner or in a reverse order according to the functions involved.

[0140] The logic and / or steps described in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, which can be embodied in any computer-readable medium for use by an instruction execution system, apparatus or device (such as a computer-based system, a system including a processor or other system that can fetch instructions from an instruction execution system, apparatus or device and execute instructions), or used in combination with these instruction execution systems, apparatuses or devices.

[0141] It should be understood that the various parts of the present application can be implemented with hardware, software, firmware or a combination thereof. In the above embodiments, multiple steps or methods can be implemented with software or firmware stored in a memory and executed by a suitable instruction execution system. All or part of the steps of the above embodiment method can be completed by instructing the relevant hardware through a program, which can be stored in a computer-readable storage medium, and when the program is executed, it includes one of the steps of the method embodiment or a combination thereof.

[0142] In addition, each functional unit in each embodiment of the present application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into one module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of a software functional module. If the above-mentioned integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The storage medium can be a read-only memory, a disk or an optical disk, etc.

[0143] The above is only an exemplary embodiment of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of various changes or substitutions within the technical scope recorded in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A method for processing software defects, characterized in that: The method comprises: In response to a defect handling instruction for the software to be processed, determining the baseline software corresponding to the software to be processed, and obtaining defect information of a target defect existing in the software to be processed, wherein the baseline software refers to a baseline version of the software; Based on the baseline software and the defect information, analyzing the version of the target software that introduces the target defect according to a preset defect analysis process; The target defect is processed in a manner corresponding to the version of the target software.

2. The method according to claim 1, characterized in that The step of analyzing the version of the target software that introduces the target defect based on the baseline software and the defect information according to a preset defect analysis process includes: Testing whether the target defect originates from the baseline version according to the defect information; If not, then the version of the target software that introduces the target defect is searched in the software version sequence formed by the baseline software and the software to be processed.

3. The method according to claim 2, characterized in that If the target defect originates from the baseline version, processing the target defect in a manner corresponding to the version of the target software includes: The target defect is marked with a first label, where the first label indicates that the target defect is a defect that already exists during software development.

4. The method according to claim 2 or 3, characterized in that: The step of searching for a version of the target software that introduces the target defect in a software version sequence formed by the baseline software and the software to be processed includes: Verify whether the target defect can be reproduced in the software to be processed; If the defect can be reproduced, the version of the target software that introduces the target defect is searched in the software version sequence formed by the baseline software and the software to be processed.

5. The method according to claim 4, characterized in that Also includes: If the target defect cannot be reproduced in the software to be processed, the target defect is marked with a second label, where the second label indicates that the target defect is a defect that cannot be stably reproduced.

6. The method according to claim 2 or 3, characterized in that: If a version of the target software that introduces the target defect is found in the software version sequence formed by the baseline software and the software to be processed, the target defect is processed in a manner corresponding to the version of the target software, including: Detecting whether there is a first upstream software version corresponding to the version of the target software in the upstream kernel warehouse of the software to be processed; If so, searching for a patch for repairing the target defect in a software version sequence formed by the first upstream software version and the second upstream software version, and repairing the defect of the software to be processed based on the patch, wherein the second upstream software version is a software version submitted in the upstream kernel repository after the first upstream software version; Otherwise, the target defect is marked with a third label, where the third label indicates that the target defect cannot be repaired based on the upstream kernel repository.

7. The method according to claim 6, characterized in that The detecting whether there is a first upstream software version corresponding to the version of the target software in the upstream kernel warehouse of the software to be processed includes: Acquire version submission information of the target software from a downstream kernel repository associated with the software to be processed; The first upstream software version is searched in the upstream kernel warehouse according to the version submission information.

8. The method according to claim 7, characterized in that The version submission information includes version submission identification information, version submission declaration information, version submission title information and version submission author information; The searching the upstream kernel repository for the first upstream software version according to the version submission information includes: Searching the upstream kernel warehouse for a software version that matches the identification information as the first upstream software version; If the software version matching the identification information does not exist in the upstream kernel warehouse, searching the upstream kernel warehouse for a software version matching the submission identification in the declaration information as the first upstream software version; If there is no software version matching the submission identifier in the declaration information in the upstream kernel repository, search the upstream kernel repository for a software version matching the title information and / or the author information as the first upstream software version.

9. The method according to claim 6, characterized in that The searching for a patch for repairing the target defect in a software version sequence formed by the first upstream software version and the second upstream software version includes: Testing whether the target defect exists in the software of the first upstream software version and the software of the second upstream software version; If it is determined that the target defect exists in the software of the first upstream software version and the target defect does not exist in the software of the second upstream software version, a patch for repairing the target defect is searched in the software version sequence formed by the first upstream software version and the second upstream software version.

10. The method according to claim 9, characterized in that The searching for a patch for repairing the target defect in a software version sequence formed by the first upstream software version and the second upstream software version includes: Searching, by a binary search method, for the first occurrence of a third upstream software version that does not have the target defect in a software version sequence formed by the first upstream software version and the second upstream software version; A difference file between the software of the third upstream software version and the software of the fourth upstream software version is generated as the patch, and the fourth upstream software version is the software version submitted last time of the third upstream software version.

11. The method according to claim 9 or 10, characterized in that: Also includes: If it is determined that the software of the first upstream software version does not have the target defect, marking the target defect with a third tag; and / or, If it is determined that the software of the second upstream software version has the target defect, the target defect is marked with a fourth label, and the fourth label indicates that the target defect is a defect existing in the upstream version.

12. An electronic device, characterized in that: The method comprises a memory, a processor and a computer program stored in the memory, wherein the processor implements the method according to any one of claims 1 to 11 when executing the computer program.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 11 is implemented.

14. A computer program product, characterized in that A computer program is included which, when executed by a processor, implements the method according to any one of claims 1 to 11.

Images