Patch acquisition method, electronic device, storage medium and program product

Abstract

The embodiment of the present application provides a patch acquisition method, electronic device, storage medium and program product, including: receiving a patch generation instruction; determining a software version to be tested from a kernel repository, the software version to be tested belongs to a software version sequence formed by a first software version and a second software version, the software version to be tested is a derivative software version of the first software version, the first software version refers to a version of software with a target defect, the second software version is a version of software submitted after the first software version and without the target defect, and the above software version sequence is a sequence formed based on multiple software versions submitted between the first software version and the second software version; detecting that the software of the software version to be tested is software containing the above patch, and generating the above patch according to the software of the software version to be tested. In the technical solution of the embodiment of the present application, the accuracy and efficiency of the acquired patch are improved, and the performance overhead can also be reduced.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a patch acquisition method, electronic device, storage medium and program product. Background Art

[0002] In order to ensure the quality and reliability of software such as operating systems, it is necessary to test the software during the development and maintenance of the software so as to promptly discover and repair defects in the software. For some defects, corresponding patches can be obtained in some software repositories. At present, the binary search method can be used to obtain patches. However, the binary search method is more suitable for simple linear version control systems. If it is applied to complex version control systems with many version branches and complex derivative relationships between versions, the accuracy and efficiency of the obtained patches are low. Summary of the invention

[0003] The embodiments of the present application provide a patch acquisition method, electronic device, storage medium and program product to alleviate or solve one or more technical problems existing in the prior art.

[0004] In a first aspect, an embodiment of the present application provides a patch acquisition method, the method comprising: receiving a patch generation instruction, the patch generation instruction being used to instruct generation of a patch for repairing a target defect based on a kernel repository; determining a software version to be tested from the kernel repository, the software version to be tested belonging to a software version sequence formed by a first software version and a second software version, the software version to be tested being a derivative software version of the first software version, the first software version being a version of software having the target defect, the second software version being a version of software submitted after the first software version and not having the target defect, the software version sequence being a collection of multiple software versions submitted between the first software version and the second software version; detecting that the software of the software version to be tested is software containing the patch, and generating the patch according to the software of the software version to be tested.

[0005] 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.

[0006] 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.

[0007] 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.

[0008] The method provided in the embodiment of the present application, when searching for a patch for repairing a target defect from a kernel repository, first determines the software version to be tested from the software version sequence formed between the first software version and the second software version, and if it is detected that the software of the software version to be tested is software containing a patch, generates a patch based on the software of the software version to be tested. The first software version is a software version with the target defect, the second software version is a version of the software submitted after the first software version and without the target defect, and the determined software version to be tested is a derivative software version of the first software version, that is, there is a direct inheritance relationship between the software version to be tested and the first software version. The software that fixes the defects of a certain software usually has a direct inheritance relationship with the software with the defects. Therefore, in the embodiment of the present application, by considering the inheritance relationship between the software version to be tested and the first software version, that is, only detecting whether the software version that has a direct inheritance relationship with the first software version is the software containing the patch, it is possible to avoid interference with the search for software by the software version that has no inheritance relationship with the first software version, thereby improving the accuracy of the acquired patch; in addition, since only the software version that has a direct inheritance relationship with the first software version is detected, the number of software to be detected is reduced, thereby improving the efficiency of patch search and reducing performance overhead.

[0009] 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

[0010] 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.

[0011] Figure 1 One of the structural diagrams of the version control system is shown;

[0012] Figure 2 The second structural diagram of the version control system is shown;

[0013] Figure 3 A schematic diagram showing an application scenario of the patch acquisition method provided in an embodiment of the present application is shown;

[0014] Figure 4 One of the flowcharts of the patch acquisition method provided in the embodiment of the present application is shown;

[0015] Figure 5 The second flowchart of the patch acquisition method provided in the embodiment of the present application is shown;

[0016] Figure 6 A schematic diagram showing the module composition of a patch acquisition device provided in an embodiment of the present application is shown;

[0017] Figure 7 A block diagram of an electronic device provided by an embodiment of the present application is shown. DETAILED DESCRIPTION

[0018] 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.

[0019] 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.

[0020] The following terms will be used in the following text:

[0021] 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.

[0022] Upstream Kernel Repository: refers to the repository where the upstream kernel source code is stored. It is a centralized repository for kernel code, allowing developers to access, modify and distribute kernel code. The 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 foundation for all release kernels, and it contains the latest features and improvements of the kernel.

[0023] Downstream Kernel Repository: refers to the repository maintained by each distribution for storing downstream kernel source code. Downstream kernel refers to the version customized and optimized by each distribution according to its own needs based on the upstream kernel source code.

[0024] 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.

[0025] Binary search: also known as binary search, is a search algorithm for finding a specific element in an ordered array. Its basic idea is to compare the target value with the middle element of the array, narrow the search range based on the comparison result, and then continue to search in the new range until the target value is found or the search range is empty.

[0026] Generally, for software such as applications or operating systems, such as Linux and Windows, in order to ensure the quality and reliability of these software, testing is required during their development and maintenance, so as to timely discover and repair defects in the software. For some defects, the corresponding repair patches can be directly obtained from other kernel repositories. For example, for a customized version developed with a certain version of software in the upstream kernel repository as the starting version, for the defects existing in this version of software, the corresponding patches may be directly obtained from the upstream kernel repository. Or, for a version developed with a certain version of software in the downstream kernel repository as the starting version, for the defects existing in this version of software, the corresponding patches may be directly obtained from the upstream kernel repository or the downstream kernel repository where the starting version is located. In order to reduce the workload of defect repair, for defects that may be repaired by obtaining a repair patch from the kernel repository, the patch can be obtained from the kernel repository first, and if the repair patch cannot be obtained, it can be repaired.

[0027] Therefore, in some cases, it is necessary to obtain patches for fixing defects in the kernel repository. Currently, the binary search method can be used to achieve patch acquisition. The current binary search method is mainly designed for the scenario of finding software versions that introduce defects. In this scenario, it is required that the software of the previous software version does not have defects, and the software of the later software version has defects. When searching for patches, the software of the previous software version has defects, and the software of the later software version does not have defects. Considering the compatibility of the binary search method in this scenario, when performing a binary search, the software of the software version with defects can be marked as not having defects (for example, marked as good), and the software version without defects can be marked as having defects (for example, marked as bad). However, the binary search method is more suitable for simple linear version control systems. For example, for Figure 1As for the linear version control system shown, it includes software version 1, software version 2, software version 3, software version 4, software version 5, software version 6 and software version 7, and there is a direct inheritance relationship in sequence. The software of software version 1 is defective software, and the software of software version 7 is non-defective software. When using the binary search method to find a repair patch to repair the defect, the software of software version 1 is marked as good, and the software of software version 7 is marked as bad. Software version 4 is determined based on the binary search, and it is detected whether the software of software version 4 has the above-mentioned defect. If the test result shows that software version 4 does not have a defect, the software version is marked as bad, and a repair patch is further searched between software version 1 and software version 4, and so on, until the software with a patch is determined.

[0028] However, for complex version control systems with many version branches and intricate derivative relationships between versions, such as Figure 2 The tree-structured version control system shown in the figure has multiple version branches and also version branch merges. Figure 2 In the version control system shown, the software of software version S has defects, and the software of software version D does not have defects. When the existing binary search method is used to search for patches for fixing defects in the software versions between software version S and software version D, software version S is marked as good and software version D is marked as bad. When a software version branch is merged, for example, software version 13, software version 23, and software version 32 are all merged into software version 24, each software version of the branch needs to be tested. There are many software versions that need to be tested, which greatly reduces the test efficiency and increases the performance overhead of patch search. In addition, assuming that after testing, Figure 2 If the software version 32 in the system does not have defects, it will be marked as bad. If the software version 23 has defects, it will be marked as good. However, according to the default principle of the binary search method, all ancestor versions marked as good are good. Therefore, the binary search method will determine that software version 21 must be good. In this case, since software version 32 is bad and software version 21 is good, it can be determined that the software version that causes the software version to switch from good to bad is software version 31, that is, the software version 31 searched based on the binary search method is the software that fixes the defects. However, the actual verification result is that the software version 13 is the software that fixes the defects, that is, the software with patches searched based on the binary search method is inaccurate. That is, in this complex version control system, the patch search is still performed according to the existing binary search method, resulting in a low accuracy rate of patch search.

[0029] In view of this, an embodiment of the present application provides a patch search method, which considers the inheritance relationship between the software version to be tested and the first software version, that is, only detects whether the software version that has a direct inheritance relationship with the first software is the software containing the patch. This can avoid interference with the search for software by software versions that have no inheritance relationship with the first software version, thereby improving the accuracy of the acquired patches. In addition, since only the software version that has a direct inheritance relationship with the first software version is detected, the number of detections is reduced, thereby improving the efficiency of patch search and reducing performance overhead.

[0030] In order to facilitate the understanding of the embodiments of the present application, the application scenario of the patch acquisition method provided in the embodiments of the present application is first briefly described. Figure 3 A schematic diagram of an application scenario of the patch acquisition method provided in an embodiment of the present application is shown. Figure 3 As shown, the application scenario includes a defect repair device 110 and a test client 120. The test client 120 performs data communication with the defect repair device 110. The test client 120 can be deployed on computing devices such as mobile phones, computers, and tablet computers. The defect repair device 110 can be a test device for software testing or other computing devices. The specific form of the defect repair 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.

[0031] In an application example, when a tester tests that a target defect exists in the software, a patch generation instruction can be sent to the defect repair device 110 through the test client 120. The patch generation instruction is used to instruct the generation of a patch for repairing the target defect based on the kernel warehouse. Exemplarily, the patch generation instruction can carry defect information of the target defect to be repaired and identification information of the kernel warehouse used for patch generation. After receiving the patch generation instruction, the defect repair device 110 determines the software version to be tested from the kernel warehouse indicated by the patch generation instruction, wherein the software version to be tested belongs to a software version sequence formed by a first software version with a target defect and a second software version without the target defect, and the software version to be tested is a derivative software version of the first software version, wherein the second software version is submitted after the first software version. The defect repair device 110 detects whether the software of the software version to be tested is the software containing the patch. If the detection result indicates that the software version to be tested is the software containing the patch, the patch is generated based on the software. Otherwise, the step of determining the software version to be tested is continued until the software containing the patch is determined.

[0032] 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.

[0033] 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.

[0034] Figure 4 A flowchart diagram of a method for obtaining a patch provided in an embodiment of the present application is shown, which can be applied to Figure 3 The defect repair device 110 in the application scenario shown is as follows: Figure 4 As shown, the method may include step S401, step S402 and step S403.

[0035] Step S401: receiving a patch generation instruction, where the patch generation instruction is used to instruct to generate a patch for repairing a target defect based on a kernel repository.

[0036] Step S402: Determine the software version to be tested from the above-mentioned kernel repository, where the software version to be tested belongs to a software version sequence formed by a first software version and a second software version. The software version to be tested is a derivative software version of the first software version, and the second software version refers to a version of the software with a target defect. The second software version is a version of the software submitted after the first software version and without the target defect. The above-mentioned software version sequence is a collection of multiple software versions submitted between the first software version and the second software version.

[0037] Step S403: Detecting that the software version to be tested is software including the patch, generating the patch according to the software version to be tested.

[0038] In one embodiment, the patch generation instruction can be a software tester triggering the test client to send a patch generation instruction for a target defect to the defect repair device 110. Exemplarily, the tester can trigger the test client to send a patch generation instruction to the defect repair device by entering a search command in the test client, or by clicking a related control on the interface of the test client to trigger the test client to send the patch generation instruction to the defect repair device 110. This is only an exemplary description of the triggering method of triggering the test client to send a patch generation instruction to the defect repair device 110, and is not a limitation of the present application scheme. When implementing the scheme, the corresponding triggering method can be set according to the scenario requirements.

[0039] Among them, if the defective software that needs to be repaired is developed with a software version of the upstream kernel warehouse as the baseline version, the above-mentioned kernel warehouse can be the upstream kernel warehouse corresponding to the defective software. If the defective software is developed with a software version of the downstream kernel warehouse as the baseline version, the above-mentioned kernel warehouse can be the upstream kernel warehouse corresponding to the defective software, or it can be the downstream kernel warehouse. The embodiment of the present application does not limit the above-mentioned kernel warehouse. During implementation, the corresponding kernel warehouse can be selected for patch search according to the actual application scenario.

[0040] Exemplarily, the patch generation instruction may carry defect information of the target defect and an identifier of a kernel repository for obtaining patches. After receiving the patch generation instruction, the defect repair device 110 determines the corresponding kernel repository based on the identifier information of the kernel repository, and obtains the patch based on the defect information of the target defect. Alternatively, in one embodiment, the patch generation instruction carries version information of the defective software to be repaired. After receiving the patch generation instruction, the defect repair device 110 obtains the defect information of the target defect existing in the defective software from the target database based on the version information of the defective software carried in the instruction, and determines the kernel repository for patch acquisition based on the version information of the defective software.

[0041] The target database is a warehouse for storing relevant information of defective software, such as test information of defective software, defect information of existing target defects, and baseline version information. The 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 the solution, the specific information content of the defect information can be configured according to the actual scenario requirements. The possible information content of the defect information is only listed here as an example, and it is not a limitation of the embodiments of the present application.

[0042] It should be noted that the software version sequence formed by the first software version and the second software version in the above step S402 refers to a collection of multiple software versions submitted between the first software version and the second software version. Among them, the derivative software version of the first software version refers to a software version that has a direct inheritance relationship with the first software version. Therefore, the multiple software versions in the above software version sequence may include derivative software versions of the first software version, and may also include derivative software versions that are not the first software version. In general, the version of the software that fixes the target defects existing in the first software version is usually a derivative software version of the first software version. Therefore, in the embodiment of the present application, in the above step S402, the software version to be tested obtained is a derivative software version of the first software version.

[0043] In an embodiment of the present application, the first software version refers to a version of the software with a target defect, and the second software version is a version of the software without a target defect. When testing whether the first software version or the second software version of the software has a target defect, it can be achieved by reproducing the target defect. It should be noted that when performing the reproduction operation of the target defect, in addition to the defect information of the target defect, the environment information for reproducing the target defect is also required, and the environment information needs to be consistent with the environment when the target defect is tested on the above-mentioned defective software. Exemplarily, the above-mentioned environment information may include a kernel compilation image, a kernel compilation script, a kernel compilation configuration, a virtual machine image, and a virtual machine startup command. Of course, here are just some possible test environment information exemplarily listed. When actually executed, the specific information content of the above-mentioned environment 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 environment information can be obtained from the target database.

[0044] After determining the software version to be tested from the kernel repository, it is necessary to detect whether the software of the software version to be tested is the software containing the above-mentioned patch. If it is detected that the software of the software version to be tested is the software containing the above-mentioned patch, the above-mentioned patch is generated based on the software of the software to be tested, for example, the patch contained in the software of the software to be tested is obtained from the software of the software to be tested, so as to repair the target defect.

[0045] In one implementation, whether the software of the software version under test is the software containing the patch can be detected by testing whether the software of the software version under test has the target defect. If the test result indicates that the software of the software version under test does not have the target defect, but the software of the software version submitted last time for the software version under test has the target defect, it can be determined that the software of the software version under test is the software containing the patch.

[0046] The method provided in the embodiment of the present application, when searching for a patch for repairing a target defect from a kernel repository, first determines the software version to be tested from the software version sequence formed between the first software version and the second software version, and if it is detected that the software of the software version to be tested is software containing the above-mentioned patch, generates a patch based on the software of the software version to be tested. Among them, the first software version is the software version with the target defect, the second software version is the version of the software submitted after the first software version and without the target defect, and the determined software version to be tested is a derivative software version of the first software version, that is, there is a direct inheritance relationship between the software version to be tested and the first software version. The software that fixes the defects of a certain software usually has a direct inheritance relationship with the software with the defects. Therefore, in the embodiment of the present application, by considering the inheritance relationship between the software version to be tested and the first software version, that is, only detecting whether the software version that has a direct inheritance relationship with the first software version is the software containing the patch, it is possible to avoid interference with the search for software by the software version that has no inheritance relationship with the first software version, thereby improving the accuracy of the acquired patch; in addition, since only the software version that has a direct inheritance relationship with the first software version is detected, the number of software to be detected is reduced, thereby improving the efficiency of patch search and reducing performance overhead.

[0047] In one embodiment, if the software of the software version to be tested is not the software containing the above-mentioned patch, it is necessary to narrow the search range based on the software version to be tested, determine a new software version sequence, and re-determine the software version to be tested from the software version sequence after the narrowing range, and detect whether the software of the re-determined software version to be tested is the software containing the above-mentioned patch, until the software containing the patch is determined. Therefore, the method provided in the embodiment of the present application also includes the following steps: if the software of the software version to be tested is not the software containing the above-mentioned patch, form a new software version sequence according to the software version to be tested and the target software version, and repeat execution from the target step based on the new software version sequence until the software containing the above-mentioned patch is determined; wherein the above-mentioned target software version includes the first software version or the second software version, and the above-mentioned target step refers to the step of determining the software version to be tested from the kernel warehouse.

[0048] Exemplarily, it can be determined whether the software version to be tested forms a new software version sequence with the first software version or with the second software version based on whether the software version to be tested has the target defect. For example, if the software version to be tested has the target defect, it means that the target defect exists in each software version from the first software version to the software version to be tested, that is, the software containing the patch is highly likely not to exist between the first software version and the software version to be tested. Therefore, a new software version sequence can be formed based on the software version to be tested and the second software version, and a patch search can be performed in the new software version sequence. If the software version to be tested does not have the target defect, it means that the target defect has been repaired before the software version to be tested, that is, the software containing the patch exists between the first software version and the software version to be tested. Therefore, a new software version sequence can be formed based on the first software version and the software version to be tested, and a patch search can be performed in the new software version sequence.

[0049] In an embodiment of the present application, the step of repeatedly determining the software version to be tested from the new software version sequence is executed, and it is detected whether the software of the re-determined software version to be tested is the software containing the above-mentioned patch. If so, the above-mentioned patch is generated based on the software of the newly determined software version to be tested, otherwise the step of forming a new software version sequence based on the re-determined software version to be tested is executed again.

[0050] The method provided in the embodiment of the present application forms a new software version sequence by using the software version to be tested and the target software version (the target software version is the first software version or the second software version) when the software version to be tested is not the software containing the above-mentioned patch, and repeats the step of determining the software version to be tested based on the new software version sequence. By constructing a new software version sequence by using the software version to be tested, the patch search scope can be quickly narrowed, unnecessary search and version detection work can be reduced, thereby saving time and resources, and further improving the efficiency of patch search.

[0051] In the embodiment of the present application, the software containing the patch refers to the first software between the first software version and the second software version that does not have the target defect, that is, the first software that fixes the target defect. In one embodiment, the method provided in the embodiment of the present application may also include the following process: detecting whether the software version to be tested has the target defect; if so, repeating the step of forming a new software version sequence according to the software version to be tested and the second software version until the first software that does not have the target defect is determined; otherwise, repeating the step of forming a new software version sequence according to the software version to be tested and the first software version until the first software that does not have the target defect is determined.

[0052] In one embodiment, the target defect can be detected by reproducing the defect in the software version to be tested. That is, the target defect is reproduced on the software version to be tested. If it can be reproduced, it means that the target defect exists in the software version to be tested. If it cannot be reproduced, it means that the target defect does not exist in the software version to be tested.

[0053] For example, when the target defect is reproduced on the software version to be tested, the kernel can be compiled based on the environmental information when the defective software is tested, a virtual machine can be started with the compiled kernel, and a program can be executed in the virtual machine. If the virtual machine crashes, it means that the software version to be tested has the target defect. If the virtual machine does not crash, it means that the software version to be tested does not have the above target defect. The above environmental information can include kernel compilation image, kernel compilation script, kernel compilation configuration, virtual machine image, virtual machine startup command, etc.

[0054] Among them, if it is determined that the software of the software version to be tested has the target defect, a new software version sequence is formed according to the software version to be tested and the second software version, and the software version to be tested is determined based on the new software version sequence, and then the software version to be tested is detected whether there is the target defect, and the above process is repeated until the software containing the above patch is determined. If it is determined that the software of the software version to be tested does not have the target defect, a new software version sequence is formed according to the first software version and the software version to be tested, and the software version to be tested is determined based on the new software version sequence, and then the software version to be tested is detected whether there is the target defect, and the above process is repeated until the software containing the above patch is determined.

[0055] For example, Figure 2 Taking the version control system shown in the figure as an example, the first software version is software version S, the second software version is software version D, and assuming that the determined version to be tested is software version 12, if the software of software version 12 has the target defect, a new software version sequence is formed based on software version 12 and software version D, and the operation of determining the software version to be tested is performed again. If the software of software version 12 does not have the target defect, a new software version sequence is formed based on software version S and software version 12, and the operation of determining the software version to be tested is performed again.

[0056] In an embodiment of the present application, by detecting whether the software of the software version to be tested has the target defect, the critical point where the software version changes from having the target defect to not having the target defect can be accurately identified, thereby achieving accurate positioning of the patch; in addition, by detecting whether the software of the software version to be tested has the target defect, the scope of patch search can be effectively narrowed, unnecessary search and version detection work can be reduced, thereby saving time and resources, and further improving the efficiency of patch search.

[0057] Figure 5 The second flowchart of the patch acquisition method provided in the embodiment of the present application is shown as follows: Figure 5 As shown, the method may include step S501, step S502, step S503, step S504, step S505 and step S506.

[0058] Step S501: receiving a patch generation instruction, where the patch generation instruction is used to instruct to generate a patch for repairing a target defect based on a kernel repository.

[0059] The patch generation instruction may be sent by the client.

[0060] Step S502: Determine the software version to be tested from the kernel repository.

[0061] Exemplarily, the software version to be tested in step S502 belongs to a software version sequence formed by a first software version and a second software version in the kernel repository, and the software version to be tested is a derivative software version of the first software version. The first software version is a version of the software with the target defect, the second software version is a version of the software without the target defect, and the second software version is submitted after the first software version.

[0062] Step S503: Check whether the software of the software version to be tested has the target defect; if so, execute step S504, otherwise execute step S505; if it is determined that the software of the software version to be tested does not have the target defect and the software of the previous version of the software version to be tested has the target defect, execute step S506.

[0063] Exemplarily, the software version to be tested may be detected by means of defect reproduction to determine whether the target defect exists.

[0064] Step S504: forming a new software version sequence according to the software version to be tested and the second software version, and repeating from step S502 based on the new software version sequence.

[0065] Step S505: forming a new software version sequence according to the first software version and the software version to be tested, and repeating the process from step S502 based on the new software version sequence.

[0066] Step S506, generating the above patch according to the software version to be tested.

[0067] The specific implementation of the above steps S501, S502, S503, S504, S505 and S506 can refer to the description of the above embodiments and will not be repeated here.

[0068] In one embodiment, determining the software version to be tested from the kernel repository may include the following steps: searching for a software version located in the middle of the software version sequence, and using the found software version as a candidate software version; determining whether the candidate software version is a derivative software version between the first software version; if so, determining the candidate software version as the software version to be tested; otherwise, repeating the steps of searching for a software version located in the middle of the software version sequence, and using the found software version as a candidate software version, until the software version to be tested is determined.

[0069] In one embodiment, a binary search method may be used to search for candidate software versions in a software version sequence. For example, a packaged binary search method may be called to search for candidate software versions in a software version sequence. Exemplarily, in a kernel repository, a packaged binary search method may be called by executing a Git bisect command to determine a candidate software version in the software version sequence.

[0070] Usually, in a complex version control system, there are often multiple parallel version branches, and the merge or split of version branches may be involved in the middle. Therefore, when using the binary search method to search in the software version sequence, there may be a situation where the candidate software version found is not a derivative version of the first software version, that is, there is no direct inheritance relationship between the candidate software version found and the first software version. For this situation, there is no need to test it. Therefore, in the case that the candidate software version found by the binary search method is not a derivative software version of the first software version, it is necessary to use the binary search method again to search in the above-mentioned software version sequence until the derivative software version of the first software version is found and used as the software version to be tested.

[0071] For example, Figure 2 Taking the version control system shown as an example, the first software version is software version 11, and the second software version is software version D. Assume that the candidate software version determined between software version 11 and software version D using the binary search method is software version 22, and software version 22 is not a derivative software version of software version 11, that is, there is no direct inheritance relationship with software version 11, so software version 22 cannot be used as the software version to be tested; the candidate software version is determined between software version 11 and software version D based on the binary search method again. If the determined candidate software version is software version 13, software version 13 is a derivative software version of software version 11, that is, there is a direct inheritance relationship with software version 11, therefore, software version 13 is determined as the software version to be tested.

[0072] In the embodiment of the present application, by determining the software version to be tested from the middle position of the software version sequence, the search interval can be continuously halved, which significantly improves the speed of patch search in the kernel repository and greatly saves the time for patch search. In addition, by determining whether the candidate software version is a derivative software version of the first software version, the version to be tested can be determined more accurately, avoiding unnecessary testing of irrelevant versions, thereby improving the efficiency and pertinence of the test; in addition, by excluding non-derivative software versions of the first software version, the interference caused by them to the patch search is eliminated, thereby improving the accuracy of the patch search.

[0073] For two software versions that are in a derivative relationship, they usually have the most recent common ancestor version. Therefore, it is possible to determine whether the candidate software version is a derivative software version of the first software version by determining the most recent common ancestor version of the first software version and the candidate software version. In one embodiment, the determination of whether the candidate software version is a derivative software version of the first software version may include the following steps: determining the most recent common ancestor version of the first software version and the candidate software version; if the most recent common ancestor version is the first software version, determining that the candidate software version is a derivative software version of the first software version.

[0074] In a version control system, the most recent common ancestor version usually refers to the most recent common predecessor version of two or more different software versions in the version history tree.

[0075] In an embodiment of the present application, if the obtained latest common ancestor version is the first software version, it means that in the version control system, the node corresponding to the candidate software version is a child node of the node corresponding to the first software version, that is, the candidate software version is a derivative software version of the first software version. If the above-determined latest common ancestor version is the candidate software version, it means that the node corresponding to the first software version is a child node of the node corresponding to the above-mentioned candidate software version, that is, the first software version is a derivative software version of the candidate software version. In this case, the above-mentioned patch does not exist in the software of the candidate software version, that is, in this case, there is no need to perform subsequent detection operations on the candidate software version. If the above-determined latest common ancestor version is neither the candidate software version nor the first software version, it means that there is no direct inheritance relationship between the above-mentioned candidate software version and the first software version, and the candidate software version is not a derivative software version of the first software version. In this case, there is no need to perform subsequent detection operations on the candidate software version. That is, in the embodiment of the present application, only when the above-mentioned most recent common ancestor version is the first software version, the candidate software version is determined as the software version to be tested, and in all other cases, it is necessary to perform the step of determining the candidate software version in the above-mentioned software version sequence using the binary search method again.

[0076] Exemplarily, in one implementation, the first software version is marked as version S, and the candidate software version is marked as version N. Then, the most recent common first version between the first software version and the candidate software version can be determined by executing the git merge-base NS command in the kernel repository. The git merge-base NS command is a tool in git that is used to find the most recent common ancestor version of two software versions. If, after executing the git merge-base NS command, the returned result is S, the candidate software version is determined as the software version to be tested. If the returned result is not S (it can be N or other), the step of determining the candidate software version in the above software version sequence using the binary search method is performed again.

[0077] In the embodiment of the present application, by determining the most recent common ancestor version of the candidate software version and the first software version, it is possible to quickly and accurately identify whether the candidate software version is a derivative software version of the first software version, which not only speeds up the identification speed of the software version to be tested, but also ensures the accuracy of the determined software version to be tested. Through this technical means, the accuracy and efficiency of patch search are significantly improved, thereby providing strong support for software defect repair.

[0078] In addition, it should be noted that the application scenario corresponding to the embodiment of the present application is that the software of the previous software version (that is, the first software version) has the target defect, and the software of the subsequent software version (that is, the second software version) does not have the target defect. When implementing this scheme, a binary search method suitable for this scenario can be designed to realize the search of the above-mentioned candidate software versions. For example, the implementation code of the binary search method can be modified, and the label of the online software version and the label of the subsequent software version in the implementation code of the binary search method can be modified. The search of the above-mentioned candidate software versions can also be realized using the existing binary search method. If the existing binary search method is used to realize the search of the above-mentioned candidate software versions, considering the compatibility of the existing binary search method in this scenario, when performing the above-mentioned search, the software of the software version with defects can be marked as not having defects (for example, marked as good), and the software of the software version without defects can be marked as having defects (for example, marked as bad).

[0079] Therefore, in one embodiment, before executing the above step S402, that is, before determining the software version to be tested from the kernel repository, the method provided in the embodiment of the present application also includes the following steps: marking the first software version with a first label, and marking the second software version with a second label, the first label is used to characterize that the software of the first software version does not have the target defect, and the second label is used to characterize that the software of the second software version has the target defect.

[0080] Based on the foregoing description, it can be known that in the embodiment of the present application, the software of the first software version has a target defect, and the software of the second software version does not have a target defect, and the above-mentioned first label indicates that the software of the first software version does not have a target defect, and the second label indicates that the software of the second software version has a target defect, that is, in the embodiment of the present application, the first software version and the second software version are marked by inverting the mark (using a mark that is opposite to the actual situation of whether there is a target defect), so that the current application scenario is compatible with the application scenario applicable to the existing binary search method, thereby realizing the binary search in the application scenario corresponding to the embodiment of the present application without modifying the existing binary search method.

[0081] For example, the specific expression form of the first label can be good, and the specific expression form of the second label can be bad. Of course, the first label and the second label can also be represented in other forms, such as characters or text, etc. This is just an example of a possible specific expression form of the first label and the second label, and is not a limitation of the embodiments of the present application.

[0082] In an embodiment of the present application, the first software version and the second software version are marked with a mark that is opposite to the actual situation of whether the first software version and the second software version have target defects, so that the application scenario is compatible with the application scenario to which the existing binary search method can be applied. There is no need to modify the existing binary search method to achieve the search for candidate software versions between the first software version and the second software version, which greatly simplifies the operational process of searching for candidate software versions and also reduces the additional computing resource consumption caused by algorithm adjustment.

[0083] In one embodiment, the above-mentioned determining the software version to be tested from the kernel repository also includes the following steps: if the candidate software version is not a derivative software version of the first software version, marking the candidate software version with a first label, the first label is used to indicate that the first software version does not have the target defect.

[0084] In an embodiment of the present application, any software version is marked by inverting the mark, so that the application scenario of this solution can be compatible with the existing binary search method. And when the method provided in the embodiment of the present application is used to search for patches, software versions that are not derivatives of the first software version are not within the scope of concern of the embodiment of the present application, that is, they do not need to be detected. Based on this, in an embodiment of the present application, if the above-mentioned candidate software version is not a derivative version of the first software version, it can be directly marked with the first mark, that is, it indicates that the candidate software version does not have the target defect. Exemplarily, it can be marked with the label good.

[0085] The method provided in the embodiment of the present application can directly mark the candidate software version found by inverting the mark when it is not a derivative software version of the first software version. On the one hand, the application scenario of the present solution can be adapted to the existing binary search method, thereby avoiding the additional computing resource consumption caused by modifying the existing binary search method. On the other hand, the candidate software version in the above situation is not within the scope of concern of the present solution. Therefore, by marking it, it can be excluded from the scope of concern, thereby improving the efficiency of patch search.

[0086] In one embodiment, in the above step S403, generating the above patch based on the software of the software version to be tested may include the following steps: determining the previous version corresponding to the software version to be tested; generating a difference file between the software of the software version to be tested and the previous version of the software, and using the difference file as the above patch.

[0087] The previous version refers to the software version submitted before the software version to be tested. The software of the software version to be tested is the software that does not have the target defect for the first time, that is, there is a patch to fix the target defect in the software of the software version to be tested, and the previous version is the software with the target defect. Therefore, the patch can be determined by comparing the difference between the previous version and the software of the software version to be tested.

[0088] In one implementation, a Git-diff command may be executed in a kernel repository to compare the file differences between the software version to be tested and the previous version of the software, that is, to generate the above-mentioned difference file.

[0089] After obtaining the above difference file, the target defect is repaired based on the difference file. In one embodiment, the above difference file can be merged as a patch into the kernel repository where the defective software is located, so as to modify the defective software based on the difference file, thereby repairing the target defect. Exemplarily, the above difference file can be applied to the source code of the defective software by executing the patch command in the kernel repository where the defective software is located, so as to modify or update the source code of the defective software.

[0090] In one embodiment, after the above-mentioned difference file is merged into the kernel repository where the defective software is located, in order to verify whether the target defect existing in the defective software has been repaired, a test may be further performed to determine whether the defective software has the target defect. Exemplarily, the above-mentioned test may be implemented by reproducing the target defect on the defective software. If the target defect cannot be reproduced on the defective software, it means that the target defect existing in the defective software has been repaired. If the target defect can still be reproduced on the defective software, it means that the target defect existing in the defective software has not been repaired, and an alarm operation may be triggered to notify the engineer to handle it.

[0091] In the embodiment of the present application, by generating a difference file between the software version to be tested and the previous version of the software, the code used to repair the defect can be accurately located, thereby improving the accuracy of the generated patch, and further improving the accuracy of the defect repair. In addition, by using the difference file of the two versions of the software as a patch for repairing the target defect, it is ensured that the patch file contains only necessary changes, which can significantly reduce the time for patch installation, thereby improving the efficiency of patch repair.

[0092] Corresponding to the application scenario and method of the method provided in the embodiment of the present application, the embodiment of the present application also provides a patch acquisition device, Figure 6 The schematic diagram of the module composition of the patch acquisition device provided in the embodiment of the present application is shown. The device can be configured in Figure 3 The defect repair device 110 in the application scenario shown. The device can execute the embodiment of the present application. Figure 4 and Figure 5 The method provided by any of the embodiments shown. Figure 6 As shown, the patch acquisition device may include: a receiving module 601, used to receive a patch generation instruction, wherein the patch generation instruction is used to instruct to generate a patch for repairing a target defect based on a kernel repository; a determining module 602, used to determine a software version to be tested from the kernel repository, wherein the software version to be tested belongs to a software version sequence formed by a first software version and a second software version, the software version to be tested is a derivative software version of the first software version, the first software version refers to a version of the software having the target defect, the second software version is a version of the software submitted after the first software version and not having the target defect, and the software version sequence is a sequence formed based on multiple software versions submitted between the first software version and the second software version; a generating module 603, used to detect that the software of the software version to be tested is software containing the above-mentioned patch, and generate the above-mentioned patch according to the software of the software version to be tested.

[0093] In one embodiment, the device provided by the embodiment of the present application also includes: a forming module, which is used to form a new software version sequence according to the software version to be tested and the target software version if it is detected that the software of the software version to be tested is not the software containing the patch, and the target software version includes the first software version or the second software version; an execution module, which is used to repeatedly execute from the target step based on the new software version sequence until the software containing the patch is determined, and the target step refers to the step of determining the software version to be tested from the kernel repository.

[0094] In one embodiment, the software containing the patch refers to the first software between the first software version and the second software version that does not have the target defect; the device provided in the embodiment of the present application also includes a detection module, which is used to: detect whether the software version to be tested has the target defect; if so, repeat the step of forming a new software version sequence according to the software version to be tested and the second software version until the first software that does not have the target defect is determined; otherwise, repeat the step of forming a new software version sequence according to the software version to be tested and the first software version until the first software that does not have the target defect is determined.

[0095] In one embodiment, the above-mentioned determination module 602 is specifically used to: search for a software version located in the middle position of the software version sequence, and use the found software version as a candidate software version; determine whether the candidate software version is a derivative software version of the first software version; if so, determine the candidate software version as the software version to be tested; otherwise, repeat the steps of searching for a software version located in the middle position of the software version sequence and using the found software version as the candidate software version until the software version to be tested is determined.

[0096] In one implementation, the determination module 602 is further specifically configured to: determine the most recent common ancestor version of the first software version and the candidate software version; if the most recent common ancestor version is the first software version, determine that the candidate software version is a derivative software version of the first software version.

[0097] In one embodiment, the device provided by the embodiment of the present application also includes: a first marking module, used to mark the first software version with a first label, and to mark the second software version with a second label, the first label is used to characterize that the software of the first software version does not have the target defect, and the second label is used to characterize that the software of the second software version has the target defect.

[0098] In one embodiment, the device provided in the embodiment of the present application also includes: a second marking module, which is used to mark the candidate software version with a first label if there is no derivative relationship between the candidate software version and the first software version, and the first label is used to characterize that the software of the first software version does not have the target defect.

[0099] In one embodiment, the above-mentioned generation module 603 is specifically used to: determine the previous version corresponding to the software version to be tested, and the previous version refers to the software version submitted before the software version to be tested; generate a difference file between the software of the software version to be tested and the previous version of the software, and use the difference file as the patch.

[0100] 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.

[0101] 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.

[0102] Understandably, Figure 6 The division of each module is only a division of logical functions. In actual implementation, the functions of the above modules can be integrated into the defect repair device. For example, the receiving module 601 can be integrated into the communication module implementation of the defect repair device, the determination module 602 and the generation module 603 can be integrated into the processor implementation of the defect repair device, etc.

[0103] 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.

[0104] 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.

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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.

[0110] 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.

[0111] 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).

[0112] 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.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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.

[0118] 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.

[0119] 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 obtaining a patch, characterized in that: The method is applied to a tree-structured version control system, wherein the tree-structured version control system has multiple version branches and also has version branch merges, and the method comprises: receiving a patch generation instruction, wherein the patch generation instruction is used to instruct generation of a patch for repairing a target defect based on a kernel repository; Determine a software version to be tested from the kernel repository, the software version to be tested belongs to a software version sequence formed by a first software version and a second software version, the software version to be tested is a derivative software version of the first software version, the first software version refers to a version of software having the target defect, the second software version is a version of software submitted after the first software version and not having the target defect, and the software version sequence is a sequence formed based on multiple software versions submitted between the first software version and the second software version; Detecting that the software of the software version to be tested is software containing the patch, and generating the patch according to the software of the software version to be tested; The method further comprises: detecting that the software of the software version to be tested is not the software containing the patch, forming a new software version sequence according to the software version to be tested and a target software version, wherein the target software version includes the first software version or the second software version; Based on the new software version sequence, the process is repeatedly executed starting from the target step until the software containing the patch is determined, wherein the target step refers to the step of determining the software version to be tested from the kernel repository.

2. The method according to claim 1, characterized in that The software containing the patch refers to the first software between the first software version and the second software version that does not have the target defect; The method further comprises: Detecting whether the software version to be tested has the target defect; If so, repeating the step of forming a new software version sequence according to the software version to be tested and the second software version until the first software that does not have the target defect is determined; Otherwise, the process is repeated starting from the step of forming a new software version sequence according to the software version to be tested and the first software version until the first software that does not have the target defect is determined.

3. The method according to claim 1 or 2, characterized in that: Determining the software version to be tested from the kernel warehouse includes: Finding a software version located in the middle of the software version sequence, and using the found software version as a candidate software version; Determining whether the candidate software version is a derivative software version of the first software version; If yes, the candidate software version is determined as the software version to be tested; Otherwise, the process repeats the steps of searching for a software version in the middle of the software version sequence and taking the searched software version as a candidate software version until the software version to be tested is determined.

4. The method according to claim 3, characterized in that The determining whether the candidate software version is a derivative software version of the first software version includes: Determining the most recent common ancestor version of the first software version and the candidate software version; If the least common ancestor version is the first software version, it is determined that the candidate software version is a derivative software version of the first software version.

5. The method according to claim 3, characterized in that: The step of determining the software version to be tested from the kernel repository further includes: If the candidate software version is not a derivative software version of the first software version, the candidate software version is marked with a first label, where the first label is used to indicate that the software of the first software version does not have the target defect.

6. The method according to claim 1 or 2, characterized in that: Before determining the software version to be tested from the kernel warehouse, the method further includes: The first software version is marked with a first label, and the second software version is marked with a second label, wherein the first label is used to indicate that the software of the first software version does not have the target defect, and the second label is used to indicate that the software of the second software version has the target defect.

7. The method according to claim 1 or 2, characterized in that: Generating the patch according to the software of the software version to be tested includes: Determine the previous version corresponding to the software version to be tested, where the previous version refers to the software version submitted last time before the software version to be tested; A difference file between the software of the software version to be tested and the software of the previous version is generated, and the difference file is used as the patch.

8. 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 7 when executing the computer program.

9. 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 7 is implemented.

10. A computer program product, characterized in that The invention comprises a computer program which, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images