SOFTWARE PATCH EVALUATOR

• US 20160259636A1
• Filed: 03/06/2015
• Published: 09/08/2016
• Est. Priority Date: 03/06/2015
• Status: Active Grant

• Current Assignee: SAP SE
• Original Assignee: Antonino Sabetta, Henrik Plate, Serena Ponta
• Inventors: PLATE, Henrik, PONTA, Serena, SABETTA, Antonino
• Granted Patent: US 9,880,832 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 11/366 using diagnostics G06F11/0703 takes precedence
• CPC Class Codes: G06F 8/658 Incremental updates; Differential updates

Abstract

Automated systems and methods for assessing the urgency of installing a patch for a component of a software application are described. The systems and methods involve identifying a set of defective programming constructs of the component that are altered by the patch, collecting execution traces of programming constructs of the software application and programming constructs of the component in a context of application use, and evaluating the execution traces to determine whether one or more defective programming constructs of the component are invoked in the context of application use.

Claims

1. A computer-implemented method for assessing an urgency of installing a patch for a defect in a component of a software application, the method comprising:

identifying a set of defective programming constructs of the component that will be altered by the patch when installed;

collecting execution traces of programming constructs of the component in a context of application use;

evaluating the execution traces to determine whether one or more defective programming constructs of the component that will be altered by the patch when installed are invoked in the context of application use; and

,

based on the determination of the number of the defective programming constructs invoked, determine the urgency of installing the patch.

2. The method of claim 1, wherein identifying a set of defective programming constructs of the component that are altered by the patch includes comparing a pre-patch version and a post-patch version of the source code of the component to identify defective programming constructs of the component that are altered by the patch.

3. The method of claim 2, wherein comparing the pre-patch and post-patch versions of the source code of the component to identify defective programming constructs of the component includes retrieving executable files of the component that have been added, deleted or modified by the patch from the pre-patch and the post-patch versions of the source code of the component.

4. The method of claim 3 further comprising creating abstract syntax tree (AST) representations of the executable files, wherein the AST define programming constructs of the executable files.

5. The method of claim 4, wherein for executable files of the component that have been added or deleted by the patch, all programming constructs identified by the respective AST representations of the added or deleted executable files are added to the set of defective programming constructs of the component.

6. The method of claim 4 further comprising, for an executable file of the component that has been modified by the patch, comparing AST representations of pre-patch and post-patch versions of the executable file to identify programming constructs that have been modified by the patch.

7. The method of claim 1, wherein collecting execution traces of programming constructs of the component in a context of application use includes embedding instrumentation code in the code of the programming constructs.

8. The method of claim 1 further comprising generating a list of all the programming constructs in the software application and comparing the list with the execution traces to quantify a test coverage metric.

9. A computer system for assessing an urgency of installing a patch for a defect in a component of a software application, the system comprising a memory and a semiconductor-based processor, the memory and the processor forming one or more logic circuits configured to:

identify a set of defective programming constructs of the component that will be altered by the patch when installed;

collect execution traces of programming constructs of the component in a context of application use;

evaluate the execution traces to determine whether one or more defective programming constructs of the component that will be altered by the patch when installed are invoked in the context of application use; and

,

based on the determination of the number of the defective programming constructs invoked, determine the urgency of installing the patch.

10. The computer system of claim 9, wherein the logic circuits are configured to identify a set of defective programming constructs of the component that are altered by the patch by comparing a pre-patch version and a post-patch version of the source code of the component to identify defective programming constructs of the component that are altered by the patch.

11. The computer system of claim 10, wherein the logic circuits are configured to compare the pre-patch and post-patch versions of the source code of the component to identify defective programming constructs of the component by retrieving all executable files of the component that have been added, deleted or modified by the patch from the pre-patch and the post-patch versions of the source code of the component.

12. The computer system of claim 11, wherein the logic circuits are configured to create abstract syntax tree (AST) representations of the executable files, wherein the AST define programming constructs of the executable files.

13. The computer system of claim 12, wherein the logic circuits are further configured to, for executable files of the component that have been added or deleted by the patch, add all programming constructs identified by the respective AST representations of the added or deleted executable files to the set of defective programming constructs of the component.

14. The computer system of claim 12, wherein the logic circuits are further configured to, for an executable file of the component that has been modified by the patch, compare AST representations of pre-patch and post-patch versions of the executable file to identify programming constructs that have been modified by the patch.

15. The computer system of claim 9, wherein the logic circuits are further configured to collect execution traces of programming constructs of the software application and programming constructs of the component in a context of application use by embedding instrumentation code in the code of the programming constructs.

16. The computer system of claim 9, wherein the logic circuits are further configured to generate a list of all the programming constructs in the software application and comparing the list with the execution traces to quantify a test coverage metric.

17. A non-transitory computer readable storage medium having instructions stored thereon, including instructions which, when executed by a microprocessor, cause a computer system to:

identify a set of defective programming constructs of a component of a software application that will be altered by a patch when installed;

collect execution traces of programming constructs of the component in a context of application use;

evaluate the execution traces to determine whether one or more defective programming constructs of the component that will be altered by the patch when installed are invoked in the context of application use; and

,

based on the determination of the number of the defective programming constructs invoked, determining an urgency of installing the patch.

18. The non-transitory computer readable storage medium of claim 17, wherein instructions stored thereon include instructions which cause the computer system to identify a set of defective programming constructs of the component that are altered by the patch by comparing a pre-patch version and a post-patch version of the source code of the component to identify defective programming constructs of the component that are altered by the patch.

19. The non-transitory computer readable storage medium of claim 18, wherein instructions stored thereon include instructions which cause the computer system to compare the pre-patch and post-patch versions of the source code of the component to identify defective programming constructs of the component by retrieving all executable files of the component that have been added, deleted or modified by the patch from the pre-patch and the post-patch versions of the source code of the component.

20. The non-transitory computer readable storage medium of claim 19, wherein the instructions stored thereon include instructions which cause the computer system to create abstract syntax tree (AST) representations of the executable files, wherein the AST define programming constructs of the executable files.