GB2508643A

GB2508643A - Method for Performing a Regression Test after Modifying Source Code File

Info

Publication number: GB2508643A
Application number: GB1222038.0A
Authority: GB
Inventors: Ralf Schaufler; Thomas Pohl; Markus Nosse; Joerg Schulze; Dirk Bolte; Carl Mayer
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2012-12-07
Filing date: 2012-12-07
Publication date: 2014-06-11

Abstract

A method for performing a regression test comprises: the creation of a map of at least one source file to a test case by storing a relationship between the files which was used to verify the source file in the past; assembling exactly the test cases mapped with the modified source file into a test case scenario; and regression testing based in the scenario. Preferably, mappings may provide an unambiguous correlation between the test case and source file, where all test cases may have been previously used for testing the source file. The mapping may be updated (such as deletion of defunct relationships) before initiating the test. The maps may be stored in a database, and provided to a source control management system and regression test entity. The test case scenario assembly may require a valid problem number. Also included is a claim to a system for performing the method.

Description

DESCRIPTION

Method and system for performing regression tests

Field of the invention

The present invention relates generally to the field of testing computer software. More specifically, the present invention is related to a method and system for performing regression tests.

Background

Computing devices typically include a central processing device (CPU) or other control unit that executes instnictions. The instruction may be pack- aged together to form a computer program or executable. These computer pro-grams or executables are generally referred to as software. The computing devices may include memory or other storage media that store the computer programs and, in response to a user's command, the control unit may load or otherwise execute one or more of the computer programs indicated by the user command. In this respect, computing devices may represent a platform on which a wide variety of software may execute. Example computing devices include general purpose computers (e.g., desktop computers, laptops, and network servers) as well as other devices that contain eirbedded CPUs or other control units (e.g., routers, printers, switches, firewalls, moni- tors, disk drives, telephones, television, automobiles or any such com-puter-controlled device).

In software development, a team of one or more programners typically writes code in a high-level prograirming language, such as C, C++, Java, or Visual Basic. The code may comprise a nuirber of functions called by a main execu-table. This development team, upon completing particular portions, e.g. functions, of the software may compile these portions into machine code or other low-level instructions that are executable by the control unit. This low-level code that is executable by the control unit may represent the above mentioned software or executables.

After compiling the high-level code to generate the software, the develop- ment team may proceed to verify the functionality of the software when exe-cuted by the target device. Typically, the development team maintains a test environment which is adapted to test this software when deployed on the target device. For example, when the target computing device is a net- work device to be deployed within a packet-based network, the test environ-ment nay include one or iriore computing devices that can be configured to simulate one or more test cases. These test cases may each represent a par-ticular test scenario with respect to emulated network configurations.

One test case, for example, may test functionality of a particular part of the software, e.g. the software related to establishing a conimunication session and conmunicating data by way of the conimunication session. The development team may manually implement this test case by configuring the computing devices of the test environment such that a first one of the com-puting devices establishes a corrmonication session with a second one of the computing devices that executes the software to be tested (i.e., the target computing device) . The development team may then cause the first computing device to transmit data via the conmunication session to the second comput- ing device and observe the functionality and behavior of the second comput-ing device as it executes the software to respond to these comainications.

The development team may report any functional errors observed during this testing and debug the high-level code to resolve the errors.

The development team may, after debugging the high-level code, recompile the high-level code into the low-level code, and re-implement the test case to determine whether the functional error has been corrected. The develop-ment team may repeat this process until all functional errors have been debugged and, after debugging all of the errors, release the software to the public.

For large-scale software development or software having a large code base, the development team may automate this testing to increase the efficiency with which testing may be accomplished. To automate the testing, the devel- opment team commonly implements each test case as a script or other pro-granmhble module that the test enviroament may execute. These automated test cases may further evaluate the interactions between the computing de-vices in order to assess a particular functionality or behavior of the software. The automated tests may also report the outcome of the test iden- tifying inappropriate behavior, e.g., functional errors, or other deficien-cies of the software. As the automation may not require human intervention, the automation of the test cases may increase testing efficiency.

To ensure each subsequent release of the software is free of software bugs, e.g., functional errors, preferably another team of one or more computer prograirmers or quality assurance specialists may perform regression testing against the software to be released. This regression testing team may col-lect each of the automated tests generated prior to each successive release of the software. Prior to releasing each version of the software, the re-gression testing team may run each of the automated tests collected for previous versions of the software to test the new or next version of the software prior to releasing this new version of the software for public use. This form of full regression testing may ensure consistent behavior of the software by verifying that changes made to previous versions of the software in order to generate the new version have not reintroduced func-tional errors that impacted functionality previously incorporated within older versions of the software.

Tt is emphasized that testing changes to an existing hardware or software system is a more time consuming endeavor than testing a completely new sys-tem, in particular program code, because changes often inadvertently have some impact on other elements of the entire underlying system. Studies show that, compared to new code, changes of a program code are ten times more likely to contain bugs.

The above mentioned approach of running each collected test case when per-forming regression tests has the drawback that a large nunnther of test cases have to be executed, i.e. regression testing takes very long time.

Therefore, it would be advantageous to have a mechanism for selecting a subset of test cases out of all available test cases in order to reduce regression test time.

Simuaxy of the invention It is an objective of embodiments of the invention to provide for an im-proved computer-implemented method, computer-readable medium and system for improving the turnaround time of regression testing. The objeotive is solved by the features of the independent claims. Preferred embodiments are given in the dependent claims. If not explicitly indicated otherwise, em-bodiments of the invention can be freely combined with each other.

In one aspect, the invention relates to a computer-implemented method for performing a regression test of a computer progrem after modifying at least one source code file, the method comprising the following steps: -creating a mapping of at least one source code file to at least one test case by storing a relationship between the source code file and at least one test case which was used to verify said source code file in the past; -assembling a test oase scenario for regression testing of the pro- grauu based on said mapping, wherein the test case scenario com-prises exactly those test cases which are mapped with the at least one modified source code file of the program; -performing the regression test based on said test case scenario.

By selecting the test cases to be executed during regression testing based on the source code file to test case relationship provided by the mapping, the set of test cases is reduced by eliminating unneeded or redundant test cases.

According to preferred embodiments, the mapping provides an unambiguous correlation between at least one test case and a certain source code file.

Assuming there are only modifications within one source code file, the test cases to be executed during regression testing are be determined by inves-tigating the test cases which are unambiguously mapped to said modified source code file. Preferably the source code file to test case mapping may be arranged as a look-up table for easily deriving the test cases corre-lated to the modified source code file.

According to preferred embodiments, the mapping provides an unanbiguous correlation between a set cf test cases and a certain source code file, wherein all test cases of the set of test cases were already used for test-ing the source code file in the past. In other words, the source code file to test case mapping represents a sort of test case history related to a certain source code file. With this approach the set of test cases for a given source code file will grow over the time as more and more code chang-es are committed and/or regression tests are performed.

According to preferred embodiments, the mapping is updated based on infor- mation which test case was used to test the modified source code file be-fore initiating the regression test. Preferably the modified source code file was already checked individually by manually executing certain test cases. Said test cases may be existing test cases which were already avail-able or new generated or modified test cases. Preferably, said test cases used to verify the modified source code files individually may also be used within the regression test which checks the compatibility of different source code files. Therefore, the source code file to test case mapping may be expanded by including the test cases used in prior manually initiated source code file tests.

According to preferred embodiments, the mapping is updated by introducing a new relationship between an added or modified source code file and at least one new test case. Thereby the mapping may be updated with a new test case which covers certain test scenario, e.g. to test a new function of the software.

According to preferred embodiments, the mapping is updated by introducing a new relationship between an added or modified source code file and at least one already existing test case. Thereby the mapping may be extended after realizing, that a certain existing test case may also be useful for testing a particular modified source code file.

According to preferred errbodiments, the mapping is updated by deleting a relationship between a removed source code file and at least one test case.

During the life cycle of a computer program, some source code files may become superfluous. After removing a certain source code file the related mapping may also become superfluous and may be removed to reduce the map-ping data.

According to preferred embodiments, the mapping is updated by deleting a relationship between a source code file and a removed test case. During the life cycle of a computer program, also test oases may become superfluous, e.g. because a certain function, which was checked by the test case, is not included anuore. To avoid superfluous test cases within the regression test, the superfluous test oases may be removed.

According to preferred embodiments, the update is performed before each regression test run to improve the source code file to test case mapping.

Thereby the mapping is adapted based on information of the prior source code file modifications or source code file tests and therefore kept up to date inmediately before the next regression test run.

According to preferred errbodiments, the update of the mapping is initiated by the source control management system after oonmitting the changed source code. The source control management system is a version control software which keeps track of all work and all changes in a source code library.

Therefore the source contrcl management system administrates all versions of source code files and all test cases generated during the life cycle of the software.

According to preferred embodiments, the source code file to test case map-ping is stored on a database which provides the mapping information to the source control management system and a regression test entity. Thereby the information regarding the source code file to test case mapping is accessi-ble by different computing entities to perform the update and/or use the mapping for the assembling of the test case scenario.

According to preferred embodiments, the assembling of the test case sce-nario is included in a software integration process such that the source code changes can only be granted if a valid problem ticket number is pro-vided.

According to preferred errbodiments, the asserrbling of the test case sce-nario is included in a software integration process such that the update of the source code file to test case mapping is only performed if a valid problem ticket number is provided.

Tn a further aspect, the invention relates to a system for performing a regression test of a computer program after modifying at least one source code file comprising -means for creating a mapping of at least one source code file to at least one test case by storing a relationship between the source code file and at least one test case which was used to verify said source code file in the past in a database; -means for assembling a test case scenario for regression test-ing of the program based on said mapping, wherein the test case scenario comprises exactly those test cases which are mapped with the at least one modified source code file of the program; and -a regression test entity adapted to perform the regression test based on said test case scenario.

As will be appreciated by cne skilled in the art, aspects of the present disclosure may be embodied as a system, method or computer program product.

Accordingly, aspects of the present disclosure may take the form of an entirely hardware errbodiment, an entirely software errbcdiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system." Furthermore, aspects of the present disclosure may take the form of a computer program product eat)odied in one or more computer readable medium(s) having computer readable program code ejitbodied thereon.

Iny combination of one or more computer readable medium(s) may be utilized.

The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for exartple, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAN), a read-only memory (ROM), an erasable programmable read-only memory (EPRON or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable coirbination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magrietic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can cornimnicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code errbodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable contination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any contiriatioxi of one or more programming languages, including an obj ect oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C'T programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly 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 (vlAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present disclosure are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to eirbodiments of the present disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and corrbinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instnicticns. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to prod-ice a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, -10 -such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blccks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other prograirifrable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programiiathle apparatus provide processes for implementing the functions/acts specified in the flowchart and/or blcck diagram block or blocks.

The block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the block diagrams may represent a module, seguent, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions discussed hereinabove may occur out of the disclosed order. For example, two functions taught in succession may, in fact, be executed substantially concurrently, or the functions may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams, and combinations of blocks in the block diagrams, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

Tt will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of -11 -stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and eqpivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for perfonriirig the function in coirbiriatiori with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The eritodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various eritodiments with various modifications as are suited to the particular use contemplated.

Brief Description of the Drawings

In the following, preferred embodiments of the invention will be described in greater detail by way of example, only making referenoe to the drawings in which: Fig. 1 shows a schematic flowchart of a prior art software integration pro-cess; Fig. 2 shows a schematic flowchart of a software integration process ac-cording to the invention; Fig. 3 shows a schematic representation of a source code file to test case mapping; Fig. 4 shows a schematic representation the update process of a source code file to test case mapping; Fig. 5 shows a schematic representation of scheduling of a regression test-ing using the source code file to test case mapping; -12 -Fig. 6 shows a schematic flowchart of scheduling of a regression testing using the source code file to test case mapping; Fig. 7 shows a schematic code for updating the source code file to test case mapping; and Fig. 8 shows a schematic code for asserrbling the set of test cases based on the source code file to test case mapping.

Detailed description

As will be appreciated by one skilled in the art, aspects of the present invention may be eirbodied as a system, method or computer program product.

Accordingly, aspects of the present invention may take the form of an en-tirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an eirbcdiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon. Arty combination of one or more computer readable me-dium(s) may be utilized. Ihe computer readable medium may be a computer readable sigrral medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an elec- tronic, magnetic, optical, electromagnetic, infrared, or semiconductor sys-tem, apparatus, or device, or any suitable combination of the foregoing.

More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random ac- cess memory (RAN), a read-only memory (RON), an erasable prograrrnuable read-only memory (EPRON or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-RON), an optical storage device, a magnetic stor-age device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible me-dium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

-13 -A computer readable signal medium may include a propagated data signal with computer readable program code embodies therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any other suitable corrt!ination thereof. A computer readable signal me-dium may be a computer readable medium that is not a computer readable storage jitedium arid that can couuiuriicate, propagate, or transport a program for use by or in connection with an instruction execution system, appara-tus, or device.

Program code embodied on a computer readable medium may be transmitted us- ing any appropriate medium, including but not limited to wireless, wire-line, optical fiber cable, RE', etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the pre-sent invention may be written in any combination of one or more programming languages, including an object oriented program language such as Java, Smalltalk, C++ or the like and conventional procedural programming lan- guages, such as the "C" programming language or similar programming lan- guages. The program code may execute entirely on the user's computer, part-ly on the user's computer or entirely on the remote computer or server. Tn the latter scenario, the remote computer may be connected to the user's computer through any type of network, including local area network (LEN) or a wide area network (WN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Pro-vider).

Referring to Figure 1, a schematic flowchart of a prior art software inte- gration process for an already existing computer program based on a plural-ity of source code files is shown. Assuming, a problem occurs within the computer program, information regarding the problem, also referred to as problem ticket 10, will be created either manually by a person faced with the problem or automatically. Preferably, said problem ticket 10 will be -14 - placed and handled within a release control management system RON. A re-lease control management system RON may be a system for controlling and supporting the life cycle of a software release.

After a progrsrmer has opened the problem ticket 10, he may perform trou-bleshooting and change at least one source code file to fix the problem. As a next step, the changed single source code file stay be debugged to access if the problem is fixed andior if further errors occur (steps 11, 12) . If the error still occurs, the programmer may change the source code again. If the debugging of the single source code file does not cause any error, a source code file test 13 may be performed to test the interaction of sev-eral source code files. At least one test case may be used while executing the source code file test. A test case is a code file which is adapted to test if a specific function of the program is working as expected. The pro-graniner may select certain test cases manually and test the interaction of several source code files based on those test cases.

After finishing the source code file test 13 without causing any error, a regression test 14 may be performed. The intent of regression testing is to ensure that a code change has not introduced any new faults and to deter-mine whether a change in one part of the software affects other parts of the software. Preferably, the regression test 14 is performed automati- cally, wherein a composition of different test cases, hereinafter also re-ferred to as test case scenario, is executed to ensure, that the computer program is working correct. Usually all test cases that are available for a certain computer program may be executed consecutively. Therefore the com-putational expense for performing regression testing is tremendous. In case that an error occurs while executing the regression test, said test may be aborted and the progranmer is informed about the occurred error and the process may start at the beginning (as indicated by arrow 15).

Figure 2 shows the schematic flowchart of software integration process ac- cording to the current invention. The beginning steps of process flow in- cluding the source code file test 13 are identical to the process flow de- -15 - scribed above. In contrary to prior art, the regression test 14 is per-formed based on a source code file to test case mapping which is provided within a database DB, i.e. with a reduced number of test cases which are selected based on said source code file to test case mapping. The mapping may be realized by a table which contains uniope associations of a certain source code file to one or more test oases. Said mapping is built by using the information, which test cases were used to test a modified source code file within the source code file test 13. Said mapping is stored in the database CS. When performing the regression test, the all test cases, which are associated with the modified source code files are used for verifying the program. In other words, the content of the database DB is used to se- lect a group of test oases out of all available test cases to red-ice re-gression test time. rfl1ile iterating the software integration process, the number of test cases which are associated with a particular source file will grow over time, i.e. the set of test cases growth as more and more code changes are conrwitted.

The benefit of the source code file to test case mapping raises the more source code files were changed compared to the last successful regression test, e.g. performing a regression test on a whole software library with a plurality of changed source code files. The source control management sys-tem SCM (e.g. CVS: Concurrent Versioning System) knows which source code files were changed. Based on those modified source code files the set of test oases is composed by selecting the test cases, which are related to the modified source code files. Thereby a reduced number of test cases is selected which reduces the processing time for regression testing.

Figure 3 shows a schematic excerpt of a source code file to test case map-ping comprising three source code files 51, S2, S3 which are mapped to four test cases Ti, 12, 13, 14. The first and second test cases Ti, T2 are asso-ciated with the first source code file Si, i.e. the test oases Ti, T2 have already been used for testing of modifications of source code file Si. In addition, the second and third test cases T2, T3 are associated with the second source code file S2. Finally, a fourth test case T4 is associated -16 -with the third source code file S3. Assuming only the second source oode file 32 was changed since the last regressicn test, only the test cases T2 and 13 have to be executed while performing the regression test, because those test cases are associated to the modified second source code file S2.

For establishing the source code file to test case mapping before running the first regression test cf a certain program or software, an initial map-ping may be generated manually by the programmer, i.e. a set of relations between the source code files of the program and a set of test cases may be pre-detennined. Preferably the mapping is created based on the relationship of the particular source code files and the respective test cases which were used to verify the particular source code file.

After performing the first regression test, source code modifications may be necessary, e.g. to fix problems occurred during the first regression test and/or to add further software features. Before running a further re-gression test to verify the modified source code files, the source code file to test case mapping contained in the database may be updated. As de-scribed above, each modified source code file may be verified by manually initiating a source code file test which is based on at least one test case. Preferably the source code file to test case mapping may be modified by adding further test cases. Those test cases may be generated by the pro-grenner himself to test an added function or feature within the source code file. When adding a new test case, additionally said new test case is as-signed to the modified source code files which were tested based on said test case. If an existing test case is used to test a changed source code file for the first time, the mapping may be updated by the relationship between the changed source code and the test case.

Referring to Figure 4, an example of updating the source code file to test case mapping is shown. An existing mapping stored in the database contains certain already existing relations, e.g. relations of source code file Si to test cases Ti and 12 and the relations of source code file 32 to test cases 12 and 13. Further assuming, the source code of the source code files -17 -Si and S2 was modified. Said source code modifications of source code file Si was tested base on test case T3 and a new generated test case 14 in a manually initiated prior source code file test. Similarly, the test case 13 and new generated test case 14 were also used to test modified source code file S2 while performing said prior source code file test. Before perform-ing the regression test, the source code file to test case mapping stored iii the database is updated based on the source code file to test case rela-tions which were used in the prior source code file test. After updating, the mapping comprises in addition to the prior mapping the new generated test case 14 and the relations which were used for the first time in the prior source code file test, i.e. the relation source code Si -test case 13, source code 31 -test case 14 and source code 52 -test case:4. The updated mapping may be used in a further regression test run which is per-formed afterwards.

Referring to Figures 5 and 6, the scheduling of a regression testing using the source code file to test case mapping is shown. The programmer P inter- acts with a release control management system RCM and a source control man-agement system SCM. After a problem in the software program occurred, the programmer P may open the ticket to fix the problem (step 110). Thereby a unique problem nunter no is generated by the release control management system RCM which is associated with the occurred problem (step 120). After generation of said unique problem nurter no the programmer P may modify at least one source code file of the program to fix the problem (step 130) . As described above, the progranner P may perform debugging and certain test case-based source code file Si -S3 tests to verify the source code modif i-cations thereby using certain test cases Ti -T4. Thereby added source code file to test case relationships Ma are defined, naily relationships be-tween a particular source code file Si -S3 and a test case Ti -T4, which was used to test the source code modifications, in addition the prograniner P may define certain source code file to test case relationships Mr. which were not used any more, i.e. removed source code file to test case rela-tionships Mr. Said removed source code file to test case relationships Mr may be the result of a removal of a certain test case Ii -14 or a source -18 -code ohange after which a certain source code file Si -53 does not fit to a particular test case Ti -T4 anymore. Said added source code file to test case relationships Ma and removed source code file to test case relation- ships Mr may be manually inputted by the progranmer P or automatically de-rived by the computing entity the programmer P is working on (step 140).

The derived added source ccde file to test case relationships Ma and re-moved source code file to test case relationships Mr are courtitted to the release control management system 1CM and stored therein (step 150) Afterwards the programmer P may trigger the scheduling of regression test (step 160), wherein the at least one modified source file Sc and the prob-lem number no are committed to the source control management system SCM.

Additionally one or more removed source files Sr, one or more changed test cases To and/or one or more removed test cases Tr may be committed. After receiving said information, the source control management system SCM may extract the problem number no out of the commit statement (step 170) To ensure that the problem number no was transmitted correctly and /or a problem ticket exists which is correlated with said problem number no, the source control management system SCM may transmit a query to the release control management system RCM, if said problem number no was allocated (step 180). If the problem number no does not exist within the release con-trol management system RCM, the process is aborted (step 190). Otherwise the further committed data are extracted out of the commit statement (step 200). Based on the problem number no, the added source code file to test case relationships Ma and removed source code file to test case rela-tionships Mr are provided by the release control management system 1CM (step 210). Afterwards, the source code file to test case mapping may be updated by adding or removing information within the database DB (step 220). The update procedure is explained in detail afterwards based on Fig-ure 7. For identifying the parameters which are used to run the regression test, a tag with a unique name N is generated (step 230) and the regression run is scheduled (step 240) . Thereby a set of information is provided to at least one regression test entity RT. Based on said information, the regres- -19 -sion test entity RI is able to derive information out of the database DE, which test cases have to be executed during the regression test. The re-gression test run is explained in detail afterwards based cn Figrtre 8.

Figure 7 shows in detail the procedures of updating the database DB, i.e. the source code file to test case mapping stored within the database. The update procedure coIrrises several steps. First of all, the source code file to test case relationships Ma which were used in the prior source code test (step 130, 140) are added to the mapping, if said relationships Ma are currently not contained within the mapping (part of code 221). The added source code file to test case relationships Ma also contain relationships to new generated source code files Sc and new generated test cases To.

In a second step, the source code file to test case relationships Mr. which were marked for removal (step 140) are removed out of the mapping (part of code 222) . Further on, all relationships which refer to removed source code files Sr are deleted (part of code 223). Finally, all relationships which refer to a removed test case Tr are removed out of the mapping (part of code 224) . Thereby the source code file to test case mapping is updated based on the information of a manually initiated prior source code file test. During the program life cycle, i.e. iteratively running a regression test, the database gathers irrproved information regarding the correlation between the source code files and the test cases which were already used to test a source code file, thereby enhancing the test case scenario by im-proving the selection of test cases for the regression test to be performed next.

Figure 8 shows an exenplary procedure of running the regression test. First of all a package of information is extracted out of the source control man-agement system SON, which preferably comprises all data regarding the scheduled regression test (part of code 241) . fterwards the source code files correlated with the program are compiled to archive at least one ex-ecutable file (part of code 242) . The at least one executable file is transferred to the regression test entity RI performing regression test -20 - (part of code 243) -For assembling the set of test cases, first, all test cases related to added or changed source code files Sc are added to the set of test cases to be executed (part of code 244) . In a second step, all test cases which refer to an added source code file to test case relationships Ma is also included, unless the test case is already included within the set of test cases (part of code 245) lkfter assembling the set of test cases, all test cases winch are included within said set of test cases are executed by the regression test entity RI while performing regression test.

If any problem or error occurs, the regression test may be aborted. Other-wise the successful execution of regression test may be reported to the programmer P (part of code 246)

Claims

-21 -C L A I N S1. A method for performing a regression test of a computer program after modifying at least one source code file (Si -53), the method corrpris-ing the following steps: -creating a mapping of at least one source code file (51 -53) to at least one test case (Ti -T4) by storing a relationship between the source code file and at least one test case which was used to ver-ify said source code file (Si -33) in the past; -assembling a test case scenario for regression testing of the pro- gram based on said mapping, wherein the test case scenario com-prises exactly those test cases (Ti -14) which are mapped with the at least one modified source code file (Si -53) of the program; -performing the regression test based on said test case scenario.
2. The method according to claim 1, wherein the mapping provides an unam-biguous correlation between at least one test case (Ti -14) and a certain source code file (Si -53)
3. The method according to claim 1 or 2, wherein the mapping provides an unambiguous correlation between a set of test cases (Ti -T4) and a certain source code file (Si -S3), wherein all test cases (Ti -T4) of the set of test cases were already used for testing the source code file (Si -S3) in the past.
4. The method according to any one of the preceding clairre, wherein the mapping is updated based on information which test case (Ti -T4) was used to test the modified source code file (Si -33) before initiating the regression test.-22 -
5. The method according to claim 4, wherein the mapping is updated by in-troducing a new relationship between an added or modified source code file (Sc) and at least one new test case (Tc)
6. The method according to claim 4, wherein the mapping is updated by in-troducing a new relationship between an added or modified source code file (Sc) and at least one already existing test case (Tl -T3)
7. The method according to any one of previous claims 4 to 6, wherein the mapping is updated by deleting a relationship between a removed source code file (Sr) and at least one test case (Ti -14)
8. The method according to any one of previous claims 4 to 7, wherein the mapping is updated by deleting a relationship between a source code file (Si -S3) and a removed test case (Ir)
9. The method according to any one of previous claims 4 to 8, wherein the update is performed before each regression test run to irrprove the source code file to test case mapping.
10. The method according to any one of previous claims 4 to 9, wherein the update of the mapping is initiated by the source control management system (SCM) after cortmitting the changed source code.
ii. The method according to any one of previous claims, wherein the source code file to test case mapping is stored in a database (DB) which pro-vides the mapping information to the source control management system (SQ'4) and a regression test entity (RT).
12. The method according to any one of previous claims, wherein the assem-bling of the test case scenario is included in a software integration process such that the source code changes can only be granted if a valid problem nuirber (no) is provided.
13. The method according to any one of previous claims 4 to 12, wherein the assembling of the rest case scenario is included in a software in-tegration process such that the update of the source code file to test -23 - case mapping is only performed if a valid problem nunter (no) is pro-vided.
14. A system for performing a regression test of a computer program after modifying at least one source code file comprising -means for creating a mapping of at least one source code file (Si -S3) to at least one test case (Ii -14) by storing a re-lationship between the source code file (Si -53) and at least one test case (Ti -T4) which was used to verify said source code file (Sl -53) in the past in a database (DB); -means for asseithling a test case scenario for regression test-ing of the program based on said mapping, wherein the test case scenario comprises exactly those test cases (Ti -T4) which are mapped with the at least one modified source code file (Si - 53) of the program; and -a regression test entity adapted to perform the regression test based on said test case scenario.
15. A computer-readable medium comprising computer-readable program code entodied therewith which, when executed by a processor, cause the pro-cessor to execute a method according to anyone of the previous claims 1 to 13.