Method for locating defects within a new version of a software program, method for an alternative order of procedures of a new version of a program causing a defect, and computer system (efficient defect location in a new code version)

Abstract

To provide methods and a computer system that efficiently locate codes causing defects of upgraded programs.SOLUTION: A method comprises: receiving a source code of a golden version program and a source code of a next version program; generating a first entry point table (first EPT) of a new version program and a second entry point table (second EPT) of a golden version program; performing a series of substitutions of sets of procedures between the second EPT of the golden version program and the first EPT of the new version program; and identifying an individual procedure determined to produce a defect by performing substitution until change in the presence of the defect is detected, and proceeding to next substitution if the change is not detected.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present invention generally relates to the field of application development debugging, and more specifically, to efficiently locating code that causes defects by prioritized alternatives.

Background Art

[0002] Software applications may have large and complex architectures and lines of code. Often, applications are developed that include multiple modules that each execute a specific area of operation or a group of related functions. The modules of an application are often developed independently and are part of a program that is combined by linking the modules. A module includes one or more procedures, and a procedure performs a specific task and is referenced or called within the operation of the program.

[0003] Software applications are tested in an environment to locate and resolve errors and defects, sometimes referred to as "bugs". The test environment often includes a debugger used to facilitate locating and correcting code defects. Source code includes the programming statements of an application, typically created in a text-based programming language and compiled by a compiler function to produce an executable program.

[0004] Software applications are often upgraded by modifying the existing code of the application or adding to the existing code. An upgrade is called a new version of the software application and can be identified by a version numbering scheme. The upgraded software may cause problems with the functions of the previous version, which requires investigation and exploration to locate and correct the defects. A previous version of a software application without defects may be called the golden code or golden version, while the upgraded application can simply be called the new version of the software application.

Summary of the Invention

Problems to be Solved by the Invention

[0005] Large-scale and complex applications may have multiple modules and thousands of lines of code, which makes it difficult to locate the code defects of the upgraded program.

Means for Solving the Problems

[0006] Embodiments of the present invention disclose a method, a computer program product, and a system for locating defects within a new version of a software program. The method provides a step in which one or more processors receive the source code of a golden version program and the source code of a next version program, where the source code of the golden version program and the source code of the next version program are modified to direct procedure calls within each program to index numbers within an entry point table (EPT), and each index number corresponds to a respective procedure memory address. One or more processors receive the next version and the golden version of the program, where the next version program is executable and includes at least one defect, and the golden version program is executable and defect-free. One or more processors generate a first entry point table (first EPT) for the new version program and a second entry point table (second EPT) for the golden version program. One or more processors perform a series of substitutions of procedures from the second EPT of the golden version program to the first EPT of the new version program, where the series of substitutions of procedures includes the order of a set of modules, individual modules of the set of modules, a set of procedures of an individual module, and individual procedures of the set of procedures, and one or more processors identify an individual procedure that is determined to cause a defect by performing substitutions of the order until no defect is observed and proceed to the next substitution of the order.

[0007] Embodiments of the present invention also disclose a method, a computer program product, and a computer system for determining an alternative order for identifying a procedure of a new version of a program that causes a defect. The method provides a step in which one or more processors determine factors associated with a new version of a program related to the occurrence of a defect. One or more processors respectively determine the weight of factors for modules of the new version program and determine the weight of factors for procedures of each module. One or more processors receive a module call tree and a procedure call tree of the new version program.

[0008] One or more processors determine an alternative priority value for a set of modules in a call sequence identified by the module call tree based on the weight of each module included in the set of modules of the new version program. One or more processors determine an alternative order of a set of modules of the new version program with a corresponding set of modules from the golden version program. The golden version program is a previous version of the program without defects, and the module set alternative order is executed in a sequence from the highest priority value to the lowest priority value and continues until the module set alternative results in a defect-free state.

[0009] In response to determining that there are no defects during the execution of the new version program with the replacement of the module set, one or more processors replace the individual modules included in the identified module set in a sequential order from the highest priority value to the lowest priority value.

[0010] In response to determining that the identified module set included in the identified modules replaced by the corresponding module of the Golden Version Program results in a defect-free state, one or more processors replace the procedure set from the Golden Version Program with the procedure set from the Golden Version Program for the identified module's procedure set based on the priority value determined for the procedure set. In response to determining that the identified procedure set included in the identified module replaced by the corresponding procedure set of the Golden Version Program results in a defect-free state, one or more processors replace the procedure of the identified procedure set from the Golden Version Program with the corresponding procedure of the new version program based on the priority value determined for the procedure. The replacement order is arranged from the procedure with the highest priority value to the procedure with the lowest priority value.

Brief Description of the Drawings

[0011]

Figure 1

Figure 2

Figure 3

Figure 4

Modes for Carrying Out the Invention

[0012] Embodiments of the present invention recognize that when software applications are updated with changes and new additions to programming code, it often includes defects or errors that cause previously correctly executed program functions to stop working or result in errors. Large-scale and complex applications may have multiple modules and thousands of lines of code, making it difficult to locate code defects in the upgraded program. Embodiments recognize that the difficulty is even greater when developers need to read and correct program code written by other developers.

[0013] Embodiments of the present invention recognize that software applications include modules that are distinct and distinguishable components of the program and can be developed independently, and each module can execute a specific set of operations. Complex software applications may have a large number of modules, and new versions of the application may include updates and additions to one or more of the modules, including deletions and replacements. Embodiments recognize that a module includes one or more procedures that are a set of programming instructions for performing a specific task. Modules and procedures are often configured according to the program so as to be called or initiated by including corresponding terms as function arguments, such as including a term "P2" defined to correspond to the procedure of a specific module.

[0014] Embodiments of the present invention also recognize that a new version of an application program has a previous version that has been tested and debugged, and in the previous version, identified defects have been located and corrected. The previous version of the code without defects immediately preceding the new version of the program code is often called the golden code or golden version of the program.

[0015] Embodiments of the present invention provide a method, a computer program product, and a computer system for locating defects in a new version program of a software application program. The embodiments apply alternative methodologies and include alternative prioritizations for narrowing the scope of the defect to the procedure level by referring to components of the golden version of the software application. The embodiments selectively replace a set of modules of the golden version of the software application code with corresponding modules of the new version of the program based on a determined priority value and a module call sequence provided by a call trace tool. The embodiments further replace modules within the set of modules based again on the priority value and, similarly, repeat the replacement at the procedure level for modules identified as containing defects.

[0016] Embodiments of the present invention include a new version of a software application that includes possible changes, additions, and deletions to the programming code of a previous error-free version of the same software application. The new version of the software application is referred to herein as the new version program, and the previous error-free version of the same software application without the edits included in the new version is referred to herein as the golden version program. The use of the terms "software application," "application," and "program" herein is used interchangeably.

[0017] In some embodiments, the replacement is enabled by the generation of an entry point table (EPT) that assigns an index number to each procedure of a module for both the new version program and the golden version program. The EPT is generated when an executable instance of each program is installed in a development test environment that includes a debugger function. An application programming interface (API) for the EPT creates the EPT, identifies each module and procedure by module, searches for the memory location of each procedure of each module, and assigns the memory location to the index number of the respective EPT for the new version and the golden version of the software program.

[0018] The EPT enables one or more golden version procedures to replace the corresponding one or more procedures of the new version of the program. In some embodiments, the new version program is modified by replacing each procedure call in the source code with a corresponding EPT index number call for each procedure such that the index number of the EPT is used within the arguments for calling the appropriate procedure. In some embodiments, the modification to the source code is done by manual programming edits.

[0019] A new version program that is executable is run under the control of a debugger in a test environment, and defects are typically determined by detecting deviations from the expected results of use cases. Based on the priority values of the module call sequences, a set of modules of the golden version is used to replace the corresponding set of modules in the new version program. The new version program is run in the test environment and checked for the presence or absence of defects (or, if multiple defects are present, one of the defects). If a defect still exists, another set of modules is replaced based on the priority values, and the process is repeated until the replacement of individual modules removes the defect. Embodiments proceed with similar replacement steps at the procedure level for the identified modules until the replacement of an individual procedure removes the defect and identifies the procedure that is the cause.

[0020] Embodiments of the present invention use calculating priority values for modules and procedures of a new version program to efficiently locate defects in the new version program. In some embodiments, factors related to potential defects within each module and procedure are determined, weights are determined for the factors, and the weights are assigned to each module and procedure based on the contribution of the factors to each module and procedure of the new version program.

[0021] In an exemplary embodiment, an entropy weighting method is used to determine the weight of each factor. Exemplary factors can include: i) determining the lines of code that have been changed for each module or procedure of the new version program; ii) the quality assurance history of the defect occurrence rate in a specific module or procedure of the previous version release; iii) information from the call stack of the modules and procedures that exist in the call stack when a defect occurs (if available); iv) the frequency with which a module or procedure is called as indicated by a static source code analyzer. Embodiments of the present invention can include additional or fewer factors that are considered when establishing weights for priority value calculation.

[0022] In some embodiments, factor-based weights are calculated and assigned to the modules and procedures of the new version program, and a tracing tool is applied to generate a module call tree for the new version program and a procedure call tree for a given module. The sequence of method calls and procedure calls within the new version program is determined, and the priority value calculated based on the factors considered is applied to the sequence of modules to obtain an overall priority value for each set of modules within the sequence.

[0023] In some embodiments of the present invention, a set of module sequences having the highest priority value among all sets of module sequences of the new version program is selected and replaced with a corresponding set of modules from the golden version executable program installed in the test environment. The new version program includes the replaced set of modules and is executed to check for the presence of defects. If not found, the new version set of modules replaced by the golden version set of modules contains defective code. If defects remain, the next set of module sequences of the new version program having the next highest priority value is replaced by the corresponding set of module sequences from the golden version. The new version program having the replaced modules is executed and checked for the presence of defects. The replacement methodology is repeated until the new version program operates without defects.

[0024] By selecting the highest priority value for a set of module trace sequences to determine the set of modules from the module call trace sequences containing defects, embodiments of the present invention repeat the replacement methodology for individual modules of the set of modules previously replaced in the new version program, followed by replacement of the procedures of the individual modules identified as containing defects. By sequentially replacing procedures based on the highest priority value, the procedure causing the defect is identified.

[0025] The present invention will now be described in detail with reference to the drawings. FIG. 1 is a functional block diagram showing a distributed application test environment generally designated 100 in accordance with an embodiment of the present invention. FIG. 1 provides only an example of one implementation and does not imply any limitation with respect to the environments in which different embodiments may be implemented. Many modifications to the illustrated environment may be made by those skilled in the art without departing from the scope of the present invention as recited by the claims.

[0026] The distributed application test environment 100 includes a computing device 110, a new version 120 of the source code, a golden version 130 of the source code, a new version 140 of the executable program, and a golden version executable program 160, all of which are interconnected via a network 150. The network 150 may be, for example, a local area network (LAN), a wide area network (WAN) such as the Internet, a virtual local area network (VLAN), or any combination that may include wired, wireless, or optical connections. Generally, the network 150 may be any combination of connections and protocols that support communication and data transmission between the servers 110.

[0027] Computing device 110 includes a compiler 113, a debugger 115, and an EPT API 117 (Entry Point Table Application Programming Interface 117). In some embodiments, computing device 110 may be a blade server, a web server, a laptop computer, a desktop computer, a stand-alone mobile computing device, a smartphone, a tablet computer, or another electronic device or computing system capable of receiving, transmitting, and processing data. In other embodiments, computing device 110 may be a computing device that interacts with applications and services hosted and operating in a cloud computing environment. In another embodiment, computing device 110 may be a netbook computer, a personal digital assistant (PDA), or another programmable electronic device capable of compiling new version source code 120 and golden version source code 130, as well as performing debug operations on new version executable program 140 and golden version executable program 160, and performing the operations of defect location identification program 300. Alternatively, in some embodiments, computing device 110 may be communicatively connected to a remotely operating defect location identification program 300. Computing device 110 may include internal and external hardware components, as shown in more detail in FIG. 4.

[0028] The defect location identification program 300 is an application for efficiently identifying defects, sometimes called "bugs," in new versions of software programs such as the new version executable program 140. The defect location identification program 300 adopts an alternative methodology to selectively and sequentially replace a set of modules and procedure components of a new version program with the corresponding modules and procedures of the golden version of the program, where the set includes one or more modules or one or more procedures. The defect location identification program 300 applies a priority value to the modules and procedures of the new version program and selects a set of modules based on the priority value assigned to the modules within the call sequence determined by the tracking tool output of the module and procedure call tree. The defect location identification program 300 selects the set of modules having the highest priority value for replacement. When the replacement of the set of modules (module set) of the golden version module for the new version module results in a defect-free state in the program being executed, the defective code is determined to be within the set of modules of the replaced new version program.

[0029] The defect location identification program 300 replaces individual modules with the identified set of modules containing defective programming code based on the priority value assigned to the modules. The defect location identification program 300 identifies the modules containing defective programming code based on the defect-free result of the golden version module replacement. The defect location identification program 300 proceeds to replace the procedures within the identified individual modules following a similar selection of the set of procedures having the highest assigned priority value, followed by the individual procedures within the set of procedures identified as containing defects. By identifying the individual procedures where the defect source can be found, the search for developers to correct the code errors causing the defects is significantly narrowed, saving time and resources.

[0030] Compiler 113 performs a software operation that converts source code written in a high-level language into machine-readable instructions, often called machine code. Compiler 113 performs a compilation operation on new version source code 120 and golden version source code 130, resulting in new version executable program 140 and golden version executable program 160, respectively. In an embodiment of the present invention, Compiler 113 performs a compilation operation on new version executable program 140 after alternative operations are performed on a module set, individual modules, and procedures, to identify the location of code that causes one or more defects in new version executable program 140 and generate a new version executable program 140 having modules and procedure components replaced from golden version executable program 160.

[0031] Debugger 115 is a computer program software tool used to test, determine errors, and enable the repair or correction of errors in the program code of software application development. Debugger 115 provides control over the testing and execution of new version executable program 140 within distributed application test environment 100. Debugger 115 enables both new version executable program 140 and golden version executable program 160 to be installed within distributed application test environment 100. Thereby, defect location identification program 300 can perform the replacement of the module set, modules, and procedures from golden version executable program 160 to new version executable program 140.

[0032] The EPT API 117 is a set of application programming interfaces that are initiated by the installation of new version executable program 140 and golden version executable program 160 into the distributed application test environment 100 under the control of the debugger 115. The EPT API 117 generates an entry point table for the new version executable program 140 and the golden version executable program 160, and the memory addresses of the procedures for each module of each program are included in the EPT and are identified by the index numbers corresponding to the respective procedure memory addresses. The EPT API 117 generates an EPT table that enables modifications to be made to procedure calls in the new version source code 120 and the golden version source code 130, enabling replacement of module sets, individual modules, and procedures from the golden version executable program 160 to the new version executable program 140.

[0033] The new version source code 120 is text-based code for a newly developed version of a program included in the distributed application test environment 100. The new version source code 120 includes updates and changes from previous versions of the same program, such as the golden version source code 130. In an embodiment of the present invention, the new version source code 120 is created using one or more programming languages and is processed by the compiler 113 of the computing device 110 to generate the new version executable program 140 whose defects are being determined by the debugger 115. The new version source code 120 is developed in an architecture that includes multiple modules and one or more procedures included in each module.

[0034] The golden version source code 130 is text-based programming code for an error-free version prior to the new version source code 120, without updates and changes made to the new version source code 120. In an embodiment of the present invention, the golden version source code 130 is created using one or more programming languages and processed by a compiler 113 of the computing device 110 to generate a defect-free golden version executable program 160. The golden version source code 130 is developed in an architecture that includes a plurality of modules and one or more procedures included in each module.

[0035] In one embodiment of the present invention, the new version executable program 140 is the compiled output of the new version source code 120 processed by a compiler 113 of the computing device 110. The new version executable program 140 is executed in a distributed application test environment 100 under the control of a debugger 115 operating on the computing device 110. In an embodiment of the present invention, the new version executable program 140 is executed using use case inputs and includes one or more programming defects. In some embodiments, the new version 120 of the code, the golden version 130 of the code, the new version executable program 140, and the golden version executable program 160 may be hosted, stored, or both, on one or more respective computing devices (not shown). The new version 120 of the code, the golden version 130 of the code, the new version executable program 140, and the golden version executable program 160 are communicatively accessible to the defect location identification program 300, the compiler 113, the debugger 115, and the EPT API 117.

[0036] Figure 2 shows an example of a procedure call of an application module referenced by the corresponding index of an entry point table (EPT) according to an embodiment of the present invention. Software applications such as the new version executable program 140 and the golden version executable program 160 include a plurality of modules, and one or more procedures constitute each module. Figure 2 includes an EPT 210, a procedure call correction 220, and a module list 230. The EPT (entry point table) 210 is a programming structure existing in the memory of the computing device 110 and includes, for example, the memory addresses of the procedures of each module of the new version executable program 140. The EPT is generated by the EPT_API of the defect location identification program 300 following the installation of the new version executable program 140 and the golden version executable program 160 of the compiled program.

[0037] The memory address of the EPT 210 is represented in Figure 2 by text identifying the procedure and the module containing the procedure, such as procedure 1 of module 1. The EPT 210 links an index number, such as index number "0" for procedure 1 of module 1, with the respective procedure address in the memory. The EPT 210 is shown as including procedure 0 of module 1 to procedure m of module N.

[0038] In an embodiment of the present invention, when a procedure call is made within a new version executable program 140 operating under the control of a debugger 115, the modified procedure call identifies an index number corresponding to the memory address of the procedure. For both the new version executable program 140 and the golden version executable program 160, when their respective versions are installed in a test environment under the control of the debugger 115, an EPT table is generated by the EPT API 117. The EPT 210 enables replacement of a corresponding procedure from the golden version executable program 160 to the EPT 210 of the new version executable program 140, and this replacement is used by the defect location program 300 to locate a defect in the new version executable program 140.

[0039] The procedure call modification 220 indicates a change to the procedure call that enables the procedure to be called by the corresponding index number. The procedure call modification 220 includes a change to the call code such that the index number of the EPT 210 is included in the procedure call code. The structure and use of the EPT support replacement of the procedure memory address of the golden version with the procedure memory address of the new version executable program 140 with only minor programming modifications, and this may utilize an automatic replacement function to simplify the modification.

[0040] The module list 230 indicates a plurality of modules associated with software applications such as the new version executable program 140 and the golden version executable program 160. In some embodiments of the present invention, the defect location identification program 300 starts the EPT API 117 and generates the EPT 210 in response to the installation of the new version executable program 140 and the golden version executable program 160 in the development test environment under the control of the debugger 115. The EPT 210 includes index numbers corresponding to the respective procedures of each module of each program.

[0041] FIG. 3 is a flowchart showing the operation steps of the defect location identification program 300 operating in the distributed application test environment of FIG. 1 according to an embodiment of the present invention. In some embodiments, the defect location identification program 300 identifies the location of a procedure in a specific program that results in a defect where a code error is detected by the debugger 115 of the computing device 110. The defect location identification program 300 performs an alternative of the memory address of the procedure code from the golden version of the executable program code (e.g., the golden version executable program 160) to the corresponding new version executable program code (e.g., the new version executable program 140) based on the index numbers associated with the module procedures in the EPT of the golden version and the new version executable programs.

[0042] The defect location identification program 300 also includes an efficient methodology for identifying defects in the new version program code by selecting a module set, individual modules, procedure sets, and individual procedures based on calculating the priority values of the modules and procedures, which includes determining factors that are likely to be associated with the occurrence of the defect.

[0043] The defect location identification program 300 receives a new version program and a golden version program in which the procedure calls have been edited (step 310). Embodiments of the present invention include modifications made to the source code of the new version of the program and the golden version of the program that replace the procedure calls of the modules of the program using index numbers corresponding to the memory addresses of the procedures of the modules. The programming modification results in a procedure call based on a reference to an entry point table (EPT) index corresponding to the memory address of a particular procedure. In some embodiments, the modification is performed manually. In other embodiments, the modification utilizes an automated or assisted replacement of code elements. The defect location identification program 300 receives source code in which modifications enabling procedure calls from the EPT for the new version of the program and the golden version of the program have been performed.

[0044] For example, the defect location identification program 300 receives a new version source code 120 and a golden version source code 130. The new version source code 120 and the golden version source code 130 have been modified to include references to the index numbers of the EPTs for the respective source codes in the procedure calls, and the index numbers correspond to the memory addresses where the called procedures are stored.

[0045] The defect location identification program 300 generates an EPT for the new version and the golden version programs (step 315). The defect location identification program 300 includes an EPT API that is started in response to detecting an executable version of a program loaded into a test environment with debugger control. The defect location identification program 300 constructs an EPT as a data structure that associates index numbers with the memory addresses of program procedures through the EPT API. In some embodiments, the EPT API obtains the memory addresses of all procedures for all modules of each executable program (i.e., the new version and the golden version), and includes the memory addresses within each EPT associated with the index numbers.

[0046] The defect location identification program 300 generates an EPT for the new version executable program and the golden version executable program such that the index numbers of the procedures in the EPT of the golden version program match the index numbers of the corresponding procedures in the EPT of the new version program, enabling replacement of similar procedures. The modifications previously made to the source code of each of the new version and the golden version programs replace the direct procedure calls with the respective programs having the index numbers of the EPT to obtain the memory addresses of the procedures and execute the program operations.

[0047] For example, the defect location identification program 300 determines that the new version executable program 140 and the golden version executable program 160 are installed in the distributed application test environment 100 under the control of the debugger 115. The defect location identification program 300 starts the EPT API 117 to construct an EPT for the new version executable program 140 and the golden version executable program 160. The EPT API 117 obtains the memory addresses of the procedures for the modules of each program and includes the memory addresses in the respective EPTs. The compiled code of the new version executable program 140 and the golden version executable program 160 includes a modification in which the procedure calls having the index numbers of the respective EPTs corresponding to the memory addresses of the procedures are replaced.

[0048] The defect location identification program 300 determines the factor weights and priority values of each module and procedure (step 320). The defect location identification program 300 receives an input for identifying factors that may cause the occurrence of defects within a module set, a module, a procedure set, or a procedure. In an exemplary embodiment, the defect location identification program 300 may calculate the weights for the factors and apply them to each module and procedure of a new version executable program such as the new version executable program 140.

[0049] Embodiments of the present invention are not limited by the number of factors to be considered. Factors that may be considered to be related to possible defect occurrences often include, for example, modules and procedures in which a large amount of code changes are made, as determined by the measurement criteria of code line updates, modules and procedures in which instances of defect occurrences exist in the history, identifying modules and procedures that exist in the call stack when a defect occurs, the program version quality assurance history, and the frequency with which modules and procedures are called during the operation of the program.

[0050] The applicability and degree of factors are determined for each module and procedure, weights for each factor are calculated, and assigned to respective modules and procedures. The weight determination methodology can be applied to calculate priority values for each module set, individual module, procedure set, and individual procedure of the new version executable program. An example of the weight determination methodology is the Entropy Weighting Method (EWM), but embodiments of the present invention are not limited to one method of determining and assigning weights to modules and procedures of the new version executable program.

[0051] For example, factors that are likely to contribute to the occurrence of one or more defects within a module or procedure of the new version executable program 140 include: i) the number of lines of code changes made within the module or procedure, ii) the quality assurance history of previous defects found within the module or procedure or both, iii) the presence of modules and procedures within the call stack in the occurrence of the defect, and iv) the number of calls made to a particular module or procedure. Each factor is given a weighting range, and the weights for each module and procedure are calculated, for example, by using the Entropy Weighting Method. The calculated weights provide priority values used for the selection of the module set (by combining the weighted values of each module in the module set), individual modules, procedure set (by combining the weighted values of each procedure in the procedure set), and individual procedures of the new version executable program 140.

[0052] The defect location identification program 300 determines the call sequence of the module set and the procedure set based on call tree tracing (step 325). The defect location identification program 300 receives information regarding the module call tree of the executable program from the output of the tracing tool applied to the new version program. The tracing of the module call tree provides a set of modules for the sequential calls of the modules during the operation of the new version executable program. A specific sequence of module calls defines the module set, and the module set is determined for the new version executable program. The module set includes all the procedures of each module of the module set that are executed in the specific sequence. The alternative of the module set includes the alternatives of all the procedures of all the modules within the module set.

[0053] The defect location identification program 300 also determines the procedure set based on the procedure call tree output from the call tracing tool applied to the new version executable program. The procedure set includes the sequence of procedure calls that are executed in the new version executable program. Each procedure set includes one or more individual procedures that are executed in the specific sequence.

[0054] For example, the defect location identification program 300 receives the output from a tracing tool that includes a module call tree indicating the call sequence. The call sequence indicates the modules included in each set. In the presented example, the modules are represented by "M" and numbers. The tracing tool identifies the module sets of M1; M2 - M3 - M10 - M4; M8 - M9 - M10; M5 - M10; M6, M7, M10 as the module sets for the new version executable program 140. The defect location identification program 300 also determines the procedure set from the tracing tool output of the procedure call tree for the new version executable program 140.

[0055] The defect location identification program 300 replaces the priority value module set of the new version executable program with the corresponding module set from the golden version executable program (step 330). The defect location identification program 300 cumulatively combines the priority values of each module of the module set determined from the received module call tree. This combination results in an overall priority value for each module set. The defect location identification program 300 determines the module set of the executable new version program having the highest priority value among the plurality of module sets, and replaces the modules of the module set with the highest priority value with the corresponding modules from the golden version executable program. The golden version executable program has been previously confirmed to be defect-free. Therefore, if a defect is located within the original module set of the new version executable program, replacing the module set of the new version executable program with the module set from the golden version executable program will have the effect of removing the defect. The new version executable program includes module set replacement and operates within a test environment.

[0056] Embodiments of the present invention replace the memory addresses of procedures associated with modules in each EPT for a new version executable program (hereinafter more simply referred to as the new version program) and a golden version executable program (hereinafter more simply referred to as the golden version program). To clarify the features of the embodiments of the present invention, the EPT replacement performed by the defect location identification program 300 is recognized as replacing the memory address of a procedure in the EPT of the new version program with the corresponding EPT memory address of the procedure of the golden version program.

[0057] For simplicity, hereinafter, the alternative is referred to by including the term "procedure" for the purpose of omitting the term "memory address", and for the procedure substitution of a module set, individual module, procedure set, and individual procedure of a new version program including defects with the corresponding procedure from the golden version program without defects. When the procedure of the new version program corresponding to index 0 is replaced, the procedure corresponds to the EPT procedure of the golden version program corresponding to the same index 0 and is replaced or exchanged.

[0058] The defect location identification program 300 executes the replacement by replacing the procedure of the new version program included in the module set, which is determined by the defect location identification program 300 to have the highest priority value. The defect location identification program 300 replaces the procedure of the module set of the new version program with the procedure of the same module set and the same EPT index number of the golden version program. The defect location identification program 300 executes the replacement of each golden version program procedure to the corresponding index position of the EPT of the new version program.

[0059] For example, the defect location identification program 300 determines that the module set of M2 - M3 - M10 - M4 has the highest priority value of 2.3 and all other module sets have priority values lower than 2.3. The defect location identification program 300 replaces the procedures in modules M2, M3, M10, and M4 of the golden version executable program 160 with the EPT of the new version executable program 140, and replaces the procedures for modules M2, M3, M10, and M4 of the new version executable program 140 with the defect - free procedures for the same modules M2, M3, M10, and M4 from the golden version executable program 160.

[0060] The defect location identification program 300 determines whether the defect still exists in the new version program (decision step 335). The defect location identification program 300 determines whether the new version program with the set of modules to be replaced from the golden version program still exhibits a defect. If the defect location identification program 300 determines that the defect still exists (step 335, "yes" branch), the defect location identification program 300 returns to step 330 and replaces the procedure of the next set of modules having the next highest priority value in the new version program with the corresponding procedure of the next set of modules in the golden version program (step 330), and proceeds as described above. Steps 335 and 330 are repeated until the module set replacement results in a state where no defect occurs, which indicates that the defect is in the code of one of the modules in the module set.

[0061] If the defect location identification program 300 determines that the defect no longer exists (step 335, "no" branch), the defect location identification program 300 replaces the priority module of the new version module set with the corresponding golden version of the module (step 340). The defect location identification program 300 identifies the set of modules to be replaced in the new version program as including the defect code, which is hereinafter referred to as the "identified module set". The defect location identification program 300 replaces the module having the highest priority value in the identified module set of the new version program with the corresponding golden version module (step 340).

[0062] In some embodiments, the defect location identification program 300 resets the EPT of the new version program for the modules of the identified module set with the original procedure replaced by the corresponding golden version procedure of the golden version program. The defect location identification program 300 determines the specific module of the identified module set with the highest priority value, and replaces the EPT procedure of the specific module of the new version program with the procedure of the corresponding module of the golden version program.

[0063] Embodiments of the present invention alternatively recognize that defects can be located by compiling a golden version program having a module set, module, procedure set, and procedure replaced from the new version program EPT to the EPT of the golden version program, and checking for the occurrence of defects. Alternative embodiments identify the module within the module set where the defect code is located by restoring the original new version program procedure for the module with the highest priority value and determining whether the defect occurs again. In the subsequent discussion of the defect location identification program 300, it is assumed that the original new version program procedure is reset prior to subsequent alternatives, but embodiments of the present invention recognize that the identification of the module, procedure set, and procedure containing the code causing the defect can also be achieved by replacing the new version program procedure from the new version program EPT to the EPT of the golden version code and determining whether the defect appears.

[0064] The defect location identification program 300 determines whether the defect still exists (decision step 345). The defect location identification program 300 determines whether the defect still exists after replacing the procedure of the corresponding procedure in the EPT of the new version program with the module without the known defect from the EPT of the golden version program. If the defect location identification program 300 determines that the defect still exists (step 345, "yes" branch), the defect location identification program 300 returns to step 340, replaces the module with the next highest priority value among the modules in the previously identified module set (step 340), proceeds as described above, and repeats the replacement with the procedure of the module with the next highest priority value until the defect no longer exists.

[0065] For example, the defect location identification program 300 determines that module 2 (M2) has the highest priority value among the modules included in the identified module set. The defect location identification program 300 replaces the procedure of module 2 from the EPT of the golden version program with the EPT of the new version program, executes the new version program with the replaced procedure, and checks whether the defect exists. If the defect remains, the defect location identification program 300 proceeds to replace the procedure of the module with the next highest priority value in the identified module set, executes the new version program with the replaced procedure, and checks whether the defect still exists.

[0066] When the defect location identification program 300 determines that the defect no longer exists (branch of "No" in step 345), the defect location identification program 300 replaces the procedure set of the identification module of the new version with the corresponding golden version procedure set that has the highest priority value (step 350). The procedure set of the new version program is determined by a tracing tool that generates a procedure call tree for the new version program. The defect location identification program 300 determines the procedure set of the identification module of the new version program that has the highest priority value as judged by the cumulative priority values of the individual procedures in the procedure set. The defect location identification program 300 replaces the procedure corresponding to the procedure set of the new version program with the highest priority value from the EPT of the golden version program to the corresponding index of the EPT of the new version program.

[0067] For example, the defect location identification program 300 determines the identified module of the new version program that contains the defect. The defect location identification program 300 identifies the procedure set of the identified module from the procedure call tree created by the tracing tool for the new version executable program 140. The defect location identification program 300 determines that the sequence of procedures (P) identified by the sequence of procedure numbers with the highest priority value is P6 - P7 - P10 - P5 - P8 - P9 - P5. The defect location identification program 300 replaces the procedures of P6 - P7 - P10 - P5 - P8 - P9 - P5 from the EPT of the golden version executable program 160 with the corresponding procedures within the EPT of the new version executable program 140.

[0068] The defect location identification program 300 determines whether the defect still exists (decision step 355). The defect location identification program 300 executes a new version program with an alternative procedure for the identified module and determines whether the defect still exists. If the defect location identification program 300 determines that the defect still exists (step 355, "Yes" branch), the defect location identification program 300 returns to step 350, replaces the procedure with the next highest priority value of the previously identified module (step 350), and proceeds as described above.

[0069] If the defect location identification program 300 determines that the defect no longer exists (step 355, "No" branch), the defect location identification program 300 replaces the priority procedure of the identified procedure set of the new version program with the procedure of the corresponding golden version program (step 360). The defect location identification program 300 determines the priority values of the procedures within the identified procedure set, selects the procedure with the highest priority value, and replaces the corresponding golden version procedure from the golden version program EPT to the EPT of the new version program. After compiling and executing the new version program with the replaced procedure, the defect location identification program 300 checks whether the defect remains.

[0070] For example, the defect location identification program 300 determines that the procedure set with the next highest priority value contains defect code. The identified procedure set includes procedures P1, P2, P3, and P5. The defect location identification program 300 determines that procedure 2 (P2) has the highest priority value and replaces procedure 2 from the golden version program EPT with procedure 2 of the new version program EPT at the corresponding position. The new version program is executed, and the defect location identification program 300 checks whether the defect still exists.

[0071] The defect location identification program 300 determines whether the defect still exists (decision step 365). If the defect location identification program 300 determines that the defect still exists (step 365, "yes" branch), the defect location identification program 300 returns to step 360, then selects the procedure of the identification procedure set with the next highest priority value, and then replaces the golden version procedure from the EPT of the golden version program corresponding to the procedure in the EPT of the new version program with the next highest priority value, and proceeds as described above.

[0072] If the defect location identification program 300 determines that the defect no longer exists, the defect location identification program 300 presents the identification of the new version program procedure having the defect (step 370). The defect location identification program 300 identifies the individual procedure replacement that removes the occurrence of the defect in the new version program. In some embodiments, the defect location identification program 300 may present a detailed replacement history that emphasizes the final procedure replacement for identifying the location of the defective code to enhance developer debugging. In some embodiments, the defect location identification program 300 may present a warning or notification displayed on the user interface of the computing device 110. By applying priority values to the modules and procedures of the new version program based on the factor weighting technique, the defect location identification program 300 brings about technical improvements in upgrading the existing program code and debugging the new version, effectively and efficiently locating the procedure where the defective code is found, and avoiding excessive steps of replacement, recompilation, and defect presence checking.

[0073] When the defect in the individual procedure of the new version program is located, the defect location identification program 300 ends.

[0074] FIG. 4 shows a block diagram of components of a computing system 400 that includes a computing device 405 configured to include or operatively connect to the components shown in FIG. 1 and having the ability to operatively execute the defect location identification program 300 of FIG. 2.

[0075] The computing device 405 includes components and functional capabilities similar to those of the components of the computing device 110 (FIG. 1) according to an exemplary embodiment of the present invention. FIG. 4 provides only an illustration of one implementation and is not to be construed as suggesting any limitation with respect to the environments in which different embodiments may be implemented. Many modifications may be made to the illustrated environment.

[0076] The computing device 405 includes a communication fabric 402 that provides communication between a computer processor 404, a memory 406, a persistent storage device 408, a communication unit 410, and an input / output (I / O) interface 412. The communication fabric 402 can be implemented in any architecture designed to pass data, control information, or both, between processors (such as microprocessors, communications, and network processors), system memory, peripheral devices, and any other hardware components within the system. For example, the communication fabric 402 can be implemented with one or more buses.

[0077] The memory 406, cache memory 416, and persistent storage device 408 are computer-readable storage media. In this embodiment, the memory 406 includes a random access memory (RAM) 414. Generally, the memory 406 can include any suitable volatile or nonvolatile computer-readable storage media.

[0078] In one embodiment, the defect position identification program 300 is stored in the persistent storage device 408 for execution by one or more of the respective computer processors 404 via one or more memories of the memory 406. In this embodiment, the persistent storage device 408 includes a magnetic hard disk drive. As an alternative to or in addition to the magnetic hard disk drive, the persistent storage device 408 may include a solid state hard drive, a semiconductor memory device, a read only memory (ROM), an erasable programmable read only memory (EPROM), a flash memory, or any other computer readable storage medium capable of storing program instructions or digital information.

[0079] The medium used by the persistent storage device 408 may also be removable. For example, a removable hard drive may be used for the persistent storage device 408. Other examples include optical and magnetic disks, thumb drives, and smart cards that are inserted into a drive for transfer onto another computer readable storage medium that is also part of the persistent storage device 408.

[0080] In these examples, the communication unit 410 provides communication with other data processing systems or devices that include resources of the distributed data processing environment 100. In these examples, the communication unit 410 includes one or more network interface cards. The communication unit 410 may provide communication through the use of either or both physical and wireless communication links. The defect position identification program 300 may be downloaded to the persistent storage device 408 through the communication unit 410.

[0081] The I / O interface 412 enables the input and output of data with other devices that can be connected to the computing system 400. For example, the I / O interface 412 may provide a connection to an external device 418 such as a keyboard, keypad, touch screen, or any other suitable input device, or a combination thereof. The external device 418 may also include a portable computer-readable storage medium such as, for example, a thumb drive, portable optical or magnetic disk, and memory card. Software and data used to implement embodiments of the present invention, such as the defect location identification program 300, may be stored on such a portable computer-readable storage medium and loaded onto the persistent storage device 408 via the I / O interface 412. The I / O interface 412 is also connected to a display 420.

[0082] The display 420 provides a mechanism for displaying data to the user and may be, for example, a computer monitor.

[0083] The programs described herein are identified based on the uses in which they are implemented in particular embodiments of the present invention. However, the terminology of any particular program herein is used for convenience only, and thus the present invention should not be understood to be limited to use in any particular application that is identified or suggested, or both, by such terminology.

[0084] The present invention may be a system, method, or computer program product, or a combination thereof, at any possible integrated technical detail level. The computer program product may include a computer-readable storage medium (or media) having thereon computer-readable program instructions for causing a processor to execute aspects of the present invention.

[0085] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing, but is not limited thereto. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, punch cards, or mechanically encoded devices such as raised structures in grooves in which instructions are recorded thereon, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed to be a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through an optical fiber cable), or an electrical signal transmitted through a wire.

[0086] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to respective computing / processing devices or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each respective computing / processing device.

[0087] The computer-readable program instructions for carrying out the operations of the present invention may be source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or any combination of object-oriented programming languages such as Smalltalk® and C++, and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN). Alternatively, the connection may be made to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to customize the electronic circuit to implement aspects of the present invention.

[0088] Aspects of the invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0089] The computer-readable program instructions may be provided to a processor of a computer, or other programmable data processing apparatus, to cause the instructions executed by the processor to implement the functions / acts specified in one or more blocks of a flowchart, a block diagram, or both. The computer-readable program instructions may also be stored in a computer-readable storage medium that includes instructions for causing a computer, or other programmable data processing apparatus, to function in a particular manner so as to implement the aspects of the functions / acts specified in one or more blocks of a flowchart, a block diagram, or both. A computer-readable storage medium having instructions stored therein includes a product that includes instructions for implementing the aspects of the functions / acts specified in one or more blocks of a flowchart, a block diagram, or both.

[0090] The computer-readable program instructions may also be loaded onto a computer, other programmable apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of a flowchart, a block diagram, or both.

[0091] The flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of a module that includes one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions described in the blocks may occur out of the order described in the drawings. For example, two blocks shown in succession may, in fact, be implemented as one step that executes simultaneously, substantially simultaneously, partially or wholly in temporal overlap, or the blocks may be executed in the reverse order depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, as well as combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by a dedicated hardware-based system that performs the specified function or operation, or by a combination of dedicated hardware and computer instructions.

Explanation of Signs

[0092] 100 Distributed Application Test Environment 110 Computing Device 113 Compiler 115 Debugger 117 Entry Point Table Application Programming Interface (EPT API) 120 New Version Source Code 130 Golden Version Source Code 140 New Version Executable Program 150 Network 160 Golden Version Executable Program 210 Entry Point Table (EPT) 220 Procedure Call Correction 230 Module List 300 Defect Location Identification Program 400 Computing System 402 Communication Fabric 404 Computer Processor 405 Computing Device 406 Memory 408 Persistent Storage Device 410 Communication Unit 412 Input / Output (I / O) Interface 414 Random Access Memory (RAM) 416 Cache Memory 418 External Device 420 Display

Claims

1. A method for locating defects in a new version of a software program, comprising: receiving, by one or more processors, source code of a golden version program and source code of a next version program, both of which are modified to direct procedure calls in their respective programs to index numbers in an entry point table (EPT), each index number corresponding to a respective procedure memory address; receiving, by the one or more processors, the next version program in executable form and the golden version program in executable form, the next version program including at least one defect and the golden version program being defect-free; generating, by the one or more processors, a first entry point table (first EPT) for the new version program and a second entry point table (second EPT) for the golden version program; executing, by the one or more processors, a series of replacements of a set of procedures between the second EPT of the golden version program and the first EPT of the new version program, the procedures to be replaced being identified by matching index numbers in their respective entry point tables; identifying, by the one or more processors, an individual procedure determined to cause the defect by executing replacements until a change in the presence of the defect is detected, and proceeding to the next replacement if no change is detected; A method comprising the above steps.

2. The method according to claim 1, wherein the new version program is the next successive program updated from the golden version program.

3. The index number of the procedure of the second EPT corresponds to the same index number of the similar procedure of the first EPT, and the procedure of the module of the first EPT corresponds to the procedure and module of the second EPT, including the corresponding index number, the method according to claim 1 or 2.

4. The method according to any one of claims 1 to 3, wherein the first EPT and the second EPT are generated based on the fact that an EPT application programming interface (API) detects the installation of the new version program and the golden version program in a test environment.

5. The method according to any one of claims 1 to 4, wherein the set of procedures of the new version program is determined by receiving a module sequence tree and a procedure sequence tree included in each module from a tracking tool.

6. The method according to any one of claims 1 to 5, wherein the replacement of the set of procedures is a procedure from the second EPT of the golden version program to the first EPT of the new version program, and the new version program is executed to determine whether the defect is no longer observed.

7. The method according to any one of claims 1 to 5, wherein the replacement of the set of procedures is a procedure from the first EPT of the new version program to the second EPT of the golden version program, and the golden version program is executed to determine whether the defect appears.

8. Assigning a priority weight by the one or more processors based on one or more factors associated with the expected occurrence of the defect; Executing the selection of modules and procedures in an alternative order by selecting each module and procedure by the one or more processors based on the priority weight; The method according to any one of claims 1 to 7, further comprising.

9. The method according to any one of claims 1 to 8, wherein the series of alternatives of the procedure includes the order of a module set, individual modules of the module set, a procedure set of the individual modules, and individual procedures of the procedure set.

10. A method for an alternative order of procedures of a new version of a program that causes a defect, comprising: Determining, by one or more processors, factors associated with a new version program regarding the occurrence of a defect; Determining, by the one or more processors, an alternative priority value for each module of the new version program and each procedure of each module based on the weights of the factors assigned to each module and each procedure; Receiving, by the one or more processors, a module call tree and a procedure call tree of the new version program; Replacing, by the one or more processors, components from a golden version program, which are one or more sets of modules identified by the call tree without defects, into the new version program until the defect disappears; Replacing, by the one or more processors, individual modules of the set of modules that produced a defect-free result from the golden version program into the original instance of the new version program until the defect disappears; Replacing, by the one or more processors, a set of procedures of the individual modules that produced a defect-free result from the golden version program into the original instance of the new version program until the defect disappears; Replacing, by the one or more processors, individual procedures of the set of procedures that produced a defect-free result from the golden version program into the original instance of the new version program until the defect disappears, wherein the alternative selection is based on the order of alternatives from the highest priority value to the lowest priority value. Replacing. identifying the procedure of the set of procedures that cause the defect; A method comprising the above. **Claim 11** The method according to claim 10, wherein the received module call tree and the procedure call tree are generated by a program tracing tool. **Claim 12** determining, by the one or more processors, the factor that contributes to the occurrence of the defect; determining, by the one or more processors, the weight of each factor for each module and each procedure; determining, by the one or more processors, the priority value based on the sum of the weights of each factor for each of the respective modules and each of the respective procedures; determining, by the one or more processors, the priority value of the set of modules and the set of procedures based on the sum of the priority values of the individual modules of the set of modules and the sum of the priority values of the individual procedures of the set of procedures; The method according to claim 10 or 11, further comprising the above. **Claim 13** The factors associated with each module of the new version program and each procedure of each module are selected from the group consisting of the number of lines of code changes, the number of defect instances determined from the program history, the presence in the call stack when the defect occurs, and the number of instances where a procedure is called by another procedure, including one or a combination thereof. The method according to any one of claims 10 to 12. **Claim 14** The method according to any one of claims 10 to 13, wherein the weights used in determining the priority values for the modules and procedures of the new version program are generated by using the entropy weighting method. **Claim 15** The method according to any one of claims 10 to 14, wherein the module call tree and the procedure call tree show the sequence in which each of the respective modules and each of the respective procedures of each module are called during the operation of the new version program. **Claim 16** A computer system for identifying defects in a new version of a software program, the computer system comprising: One or more computer processors; One or more computer-readable storage media, and program instructions stored on the one or more computer-readable storage media, the program instructions comprising: Program instructions for receiving the source code of the golden version program and the source code of the next version program, wherein the source code of the golden version program and the source code of the next version program are modified to direct procedure calls in each program to index numbers in an entry point table (EPT), and each index number corresponds to a respective procedure memory address, the program instructions for receiving; Program instructions for receiving the next version program in executable form and the golden version program in executable form, wherein the next version program includes at least one defect and the golden version program has no defects, the program instructions for receiving; Program instructions for generating a first entry point table (first EPT) for the new version program and a second entry point table (second EPT) for the golden version program; Program instructions for performing a series of substitutions of a set of procedures between the second EPT of the golden version program and the first EPT of the new version program, the procedures to be substituted being identified by matching index numbers in their respective entry point tables, the program instructions for performing; Program instructions for identifying an individual procedure determined to cause the defect by performing substitutions until a change in the presence of the defect is detected, and proceeding to the next substitution if the change is not detected; A computer system including. Claim 17 The computer system according to claim 16, wherein the set of procedures of the new version program is determined by program instructions that receive, from a tracing tool, a module call tree sequence and a procedure call tree sequence of procedures included in each module.

18. Program instructions for assigning a priority weight based on one or more factors associated with the expected occurrence of the defect; Program instructions for executing the selection of modules and procedures in an alternative order by selecting each module and procedure based on the priority weight; The computer system according to claim 16 or 17, further comprising:

19. The computer system according to any one of claims 16 to 18, wherein the series of alternatives of the procedure includes an order of a module set, individual modules of the module set, a procedure set of the individual modules, and individual procedures of the procedure set.

20. Stored on the one or more computer-readable storage media for execution by at least one of the one or more processors, Program instructions for determining factors associated with a new version program regarding the occurrence of the defect; Program instructions for determining alternative priority values for each module of the new version program and each procedure of each module based on the weights of the factors assigned to each module and each procedure of each module; Program instructions for receiving a module call tree and a procedure call tree of the new version program; Program instructions for replacing one or more sets of modules from the golden version program identified by the module call tree with the new version program until the defect disappears; Program instructions for replacing individual modules of the set of modules that produced a defect-free result from the golden version program with the original instances of the new version program until the defect disappears; Program instructions to replace the set of procedures of the individual module that produced a defect-free result from the golden version program with the original instance of the new version program until the defect disappears; Program instructions to replace the individual procedures of the set of procedures that produced a defect-free result from the golden version program with the original instance of the new version program until the defect disappears; The alternative selection is based on the order of alternation from the highest priority value to the lowest priority value; Program instructions to identify the procedures of the set of procedures that cause the defect; The computer system according to any one of claims 16 to 19, further comprising.

Images