WO2007014874A2

WO2007014874A2 - Method for automatic testing of a software configuration

Info

Publication number: WO2007014874A2
Application number: PCT/EP2006/064611
Authority: WO
Inventors: Horst Eckardt; Sieglinde Kranz; Reiner Müller
Original assignee: Siemens Aktiengesellschaft
Priority date: 2005-08-03
Filing date: 2006-07-25
Publication date: 2007-02-08
Also published as: WO2007014874A3; EP1913469A2; DE102005036524A1

Abstract

The invention relates to a method for automatic testing of software configurations (SWK) comprising several software elements (SWE). Starting with an initial software configuration, comprising the current independently-executable versions (V<SUB>N</SUB>) of all software elements in the software configuration, the software elements (SWE) are each iteratively replaced by a previous version (VN <SUB>N-1</SUB>) of said software element until the software configuration (SEK) under test is an executable software configuration (SWK).

Description

description

Method for automated testing of a software configuration

The invention relates to a method for automated testing of a software configuration consisting of several software elements.

Complex software products consist of a multitude of individual software elements, such as modules, classes, files or documents. This multiplicity of software elements is further increased by the fact that over the course of time in software product development, several software versions are created for each software element, which differ from the original software element versions due to changes or additions. Furthermore, there may be specific versions of the software elements for different countries or customers.

For the maintenance and care of a software package or a software configuration consisting of several software elements, information is to be provided on which versions or variants are contained within the software configuration.

A software configuration is an identified and formally approved set of software elements that are aligned and have a specific function. Software configuration management identifies and manages software configurations. Configuration management generally handles planning, configuration identification, configuration change, and configuration administration. When changing the configuration, a processing, tracking and monitoring of all changes takes place up to a documented conclusion. In today's software development process, CM systems such as CM-Synergy, Clear Case or CVS (Concurrent Version System) are used, among other things, as configuration management systems. These software tools are used to make all project-relevant documents, documentation, requirements as well as changes, comments, software sources accessible at any time and for any time in the past. In addition, these software tools are used to back up all project documents and to allow access to various release versions, either for documentation purposes or in the case of warranty claims. The configuration management systems also offer the developer the option of saving individual non-released or private versions of the software elements as backups for back-up purposes.

During software development, requirements are formulated for a software package or a project, and these requirements are correspondingly implemented in software management elements in a corresponding administration within the configuration management system. The developers working on the project program the various software elements in a high-level programming language as source code. The software elements, which have been revised according to the requirements, are first tested individually for their ability to run in a single test. After a successful individual test of a software element, the software elements programmed in the source code are transferred to the administration of the configuration management system. In the case of conventional configuration management systems, the assignment of the change requests transferred to the developer (change request) for changing a software element to the change made in the software element is the responsibility of each individual developer. As a result, incorrect releases of code programmed in the source code are frequently Goods elements. This endangers further steps in the software development process.

FIG. 1 shows a so-called build process and a software element according to the prior art. In response to a change request or a change request, a developer revises any software element in the source code (QC), such as a module, a file or a document, and enters it into an editor. A compiler translates the source code into a machine-readable object code. A linker or a binding program then supplies an executable software element.

Each software element SWE is individually developed according to the required changes, as shown schematically in Figure 2. Based on an existing version V _{N of} the software element, the developer changes the source code of the software element, thus creating a software element with an increased version number V _{N + 1} .

As shown in FIG. 3, on a change request (CR) or on a change request by a programmer or developer, a revised software element is programmed in the source code QC and a machine-readable in a build process, as shown in FIG Software element generated in the object code. This software element undergoes a test run and determines if the software element is self-executable in a local test environment. If this is the case, the executable software element is stored in a database or a repository for further use. If the revised software item is not executable or functional, the developer must revise the programmed software item to reflect the requested change requests until the software item proves to be executable and functional in the test run. Figure 4 shows the structure of a software configuration as used in a conventional configuration management system. Such a software configuration SWK consists of several data fields for the software elements contained in the software configuration. In the example shown in Figure 4, the software configuration of three software elements SWE, namely SWEi, SWEj, SWE _K is. For each software element SWE of the software configuration, the version number V of the associated software element is stored. In the example shown in Figure 4 is the

Version V _x for the software element SWEi, the version number V _γ for the software element SWEj and the version number V _z for the software element SWE _K stored.

Figure 5 shows schematically the evolutionary evolution over time of the various software element versions stored in a database of the configuration management system. In the example shown in FIG. 5, the current most recently successfully tested software configuration of the present day SWK _day comprises the software element SWEi in the version V _x , the software element SWE-, in the version V _γ the software element SWE _k in the version V ₂ .

FIG. 6 shows the procedure for testing a software configuration SWK consisting of several software elements SWE according to the prior art.

The current software configuration SWK _day , which is programmed in the source code, is compiled and tested in a build process to an executable configuration SWK _dayEXE .

If the current software configuration is functional, it will be marked as successfully tested and stored in a database or repository. If, however, during the test run, the software configuration revised in the source code shows that it is not executable or does not function, a manual procedure takes place on the basis of the error logs generated in the build process and in the test run. Quick troubleshooting by the developer. The test is performed until the test run indicates that the revised software configuration is executable.

FIG. 7 shows an example for explaining the problem occurring in this case. In the example shown in FIG. 7, a software configuration V3, V3, V4 of a software configuration SWK consisting of three software elements SWE ₁ , SWE ₁₁ , SWE _{k was} successfully tested at a previous time, for example on the previous day DAY- ₁ . Over a period of development, for example, over the course of a day, the developers programmed a revised version V4 for the SWE ₁ software element and a revised version V5 for the SWE _R software element according to the change requests received while the software element SWE- was not reprogrammed has been. The version V4 of the software element SWE ₁ and the version V5 of the software element SWE _k are first tested for their operational capability.

After it has been established that all software elements SWE ₁ , SWE ₁₁ , SWE _k in their last version can run on their own, the most up-to-date software configuration SWK _day = V4, V3, V5 in their entirety is checked for their runnability, as shown in FIG. tested. Results in this

Test that the most recent software configuration SWK _{day is} not functional, manually troubleshooting based on the generated error logs by the various developers, as shown in Figure 6.

The procedure shown in Figure 6 in a conventional configuration management system according to the prior art has some serious disadvantages.

The evaluation of the error logs by the developer is naturally very time consuming. In addition, the procedure is very uncertain and leads to a faulty Release of a software configuration that does not work properly or does not meet the required changes. In addition, the conventional approach shown in Figure 6 requires elaborate coordination between the various developers handling the various software elements.

It is therefore the object of the present invention to provide a method for testing a software configuration consisting of multiple software elements, which is automatically feasible without manual debugging by a developer.

This object is achieved by a method having the features specified in claim 1.

The invention provides a method for the automated testing of a software configuration (SWK) consisting of a number of software elements (SWE), starting from a formed initial software configuration which contains the current executable versions (V _N ) of all software elements (SWE). includes, the software elements (SWE) respectively by the previous version (V _N _i) of the respective software element iteratively replaced until the tested software configuration (SWK) is an executable software configuration.

Due to the automated roll-back mechanism used in the method according to the invention, ie by the iterative replacement of the software elements by the associated previous version until the tested software configuration is an executable software configuration, it is ensured at all times that a software configuration that can be delivered for Is available without the hassle, costly and nerve-wracking manual error handling by the developer. In a preferred embodiment of the method according to the invention, an up-to-date version of the software element is generated in response to an incoming change request for a software element (change request) based on an existing version of the software element.

In a preferred embodiment of the method according to the invention, the current version of the software element is individually tested for its operational capability.

In a preferred embodiment of the method according to the invention, each change request of a software element (SWE) has a description of the change to be made to the software element and a status field for indicating a state of the change request.

In a preferred embodiment of the method according to the invention, each change request takes one of four different states, namely a first state indicating that the change request is in progress, a second state indicating that the change request has changed Software element successfully tested and executable by itself, a third state indicating that the software element modified to the change request has been successfully tested in the software configuration under test, and a fourth state indicating that the change has occurred - Requested changed software element in the software configuration to be tested has not been tested successfully.

In a preferred embodiment of the method according to the invention, the iterative replacements of the software element versions made in order to Software configuration to arrive at an executable software configuration, logged and stored.

In a preferred embodiment of the method according to the invention, the change request which has led to a non-executable software configuration is determined on the basis of the logged replacements.

In a preferred embodiment of the method according to the invention, the software configuration (SWK) has data fields which specify the version number of the software elements contained therein.

In a preferred embodiment of the method according to the invention, the software configuration additionally has a status field which indicates whether the software configuration is executable.

In addition, preferred embodiments of the method according to the invention will be described with reference to the attached figures to explain features essential to the invention.

Show it:

FIG. 1 shows a build process for a software element according to the prior art;

FIG. 2 shows the development of various software element versions according to the prior art;

FIG. 3 shows a build process and a test procedure for a

Software element according to the prior art; Figure 4 shows the data structure of a conventional software configuration (SWK) according to the prior art;

Figure 5 is a diagram for explaining the stored in a conventional configuration management system

Data describing a software configuration;

FIG. 6 shows a flow chart for illustrating a conventional procedure for checking the functional capability of a software configuration according to the prior art;

Figure 7 is an example for explaining the problem underlying the invention;

FIG. 8 shows a flow diagram of a preferred embodiment of the method according to the invention for the automated process

Testing a software configuration;

FIG. 9 shows the data structure of a software element change request used in the method according to the invention (change request);

FIG. 10 shows the data structure of a software configuration used in the method according to the invention;

FIG. 11 shows an example for explaining the mode of operation of the method according to the invention for testing a software configuration.

As can be seen from FIG. 8, the method according to the invention for testing a software configuration SWK is an automatic method which requires no manual troubleshooting by a developer. The inventive method includes an automatic rollback mechanism that provides a current executable software configuration. First, after a start step SO in a step Sl, an initial software configuration is generated. For this purpose, the software configuration is set to the software configuration that has already been successfully tested the day before, for example to the software configuration SWK _D shown in FIG. 11 _! = V3, V3, V3.

SWK _day : = SWK _day . i

Subsequently, for all software elements SWE which are contained in the software configuration SWE to be tested, it is checked whether a subsequent version of the software element exists. If this is the case, the software element is replaced by the revised successor version:

For all SWE _QC from SWK _day if successor ^version of SWE 'Q _n C _c ^e χ is substituted, replace SW Ε Q _∞ C ^with i SJW ff JE-J QTC

This leads to the initial software configuration SWKdayo. In the example shown in Figure 11, this initial software configuration is SWKdayo = V5, V3, V4.

In a step S2, a list of the nonintegratable change requests or change requests is initialized, as shown in FIG. Non-integratable change requests CR are change requests for changing a software element SWE that lead to a non-executable software configuration SWK.

In a step S3, the initial software configuration is first subjected to a build process and tested. In a step S4 it is checked whether the last tested software configuration SWK is executable or functional or not.

If this is the case, the change request entries are updated in a step S5, i. H. the status field of the change requests is updated. The change request CR can take one of four different states.

As shown in FIG. 9, a change request CR or a software element change request consists, on the one hand, of a description of the changes to the software element SWE to be made by the developer and of a status field for indicating a state of the change requests. The change request content is the current description of the software element change to be made by the developer in a high level programming language. In a preferred embodiment of the method according to the invention, each software element change request CR additionally has a status field for indicating a state of the change requests. In a particularly preferred embodiment, each change request takes one of four different states.

A first state indicates that the change request CR is in progress.

A second state indicates that the software element SWE changed in response to the change request CR has been sent to a

Single test has been tested successfully and can be implemented or executed on its own.

A third state of the change request CR indicates that the software element changed in response to the change request has been successfully tested in the software configuration SWK under test. A fourth state indicates that the software element SWE changed to the change request CR has not been successfully tested in the software configuration SWK to be tested.

In step S5, after successful tests of the software configuration SWK, the status fields of all software element change requests of those software elements SWE contained in the successfully tested software configuration SWK are transferred to the third state.

FIG. 10 shows the data structure of a software configuration SWK. The software configuration SWK comprises the version numbers V of the software elements SWE contained therein. In addition, an identification of the change request (CR) or software element change request that led to the associated version V is stored for the version number V. In addition, the software configuration data record SWK contains a status field which indicates the state of the software configuration. In a preferred embodiment, the software configuration SWK assumes three different states, namely a first state indicating that the software configuration SWK has not yet been tested, a second state indicating that the software configuration SWK is tested but still has errors, and a third state indicating that the software configuration SWK has been successfully tested.

In a step S6, the status field of the successfully tested software configuration is set to the status "successfully tested" and the software configuration SWK is stored in a database of the software configuration management.

In a step S7, a list of the nonintegratable change requests CR is additionally stored. If it is determined in step S4 that the initial software configuration generated in step S1 is not functional after the build process, an automatic rollback occurs in step S8. For this purpose, based on the initial software configuration formed, which includes the current self-executable versions of all software elements SWE, each software element is iteratively replaced by a previous version until the tested software configuration is executable.

After each iterative replacement of a software element with a previous version, a new build process and a new test run occur in step S3.

As can be seen from the example shown in Figure 11, the initial software configuration consists of:

SWKdayo = V5, V3, V4

If the first test run indicates that the initial software configuration does not become executable, the software configuration is set to SWK _D i in a first iteration step:

SWK _D1 = V4, V3, V4.

If a further test run reveals that this software configuration is also inoperable, the current version V4 of the software element SWE _{K is} replaced by the predecessor version V3 of the software element SWE _K.

SWE _D2 = V4, V3, V3

If, in the example shown in FIG. 11, even after this test run that the software configuration SWK is not yet functional, the version finally becomes V4 of the software element SWEi replaced by the previous version V3 of the software element SWEi.

SWK _D3 = V3, V3, V3

The iteration process, d. H. the loop with the steps S3, S4, S8 is run through until a successful test run can be carried out. This is the case at the latest when the status of the last successful build or the last successfully completed test run is reached. In this case, all newly introduced changes to the software elements, i. H. all new versions, withdrawn. In the example shown in FIG. 11, this is the case when all three software elements have been taken back to the version V3. However, this represents the exceptional case. Usually, after a few iterative replacements of software elements by previous versions, an executable software configuration is achieved, which can be delivered from the initial software configuration.

In a preferred embodiment of the method according to the invention, the iterative replacements of the software element versions that are required in order to move from the initial software constellation to a finally executable software constellation are logged and buffered. Based on the logged replacements, those change requests or change requests CR are determined which have led to a non-executable SWK software constellation.

In the example illustrated in FIG. 11, the initial software constellation SWKD ₀ = V5, V3, V4 can not be executed and the test run results in the software constellation SWK _D i = V4, V3, V4 created after an iterative replacement is executable, it is determined that the change request CR or the change request for the changes in the sion V4 of the software element SWEi for generating the version V5 of the same software element SWEi has led to the execution error or to the integration error, ie it is determined that the self-executable version V5 the software element SWEi with the versions V3 of the software element SWEJ and the Version V4 of the software element SWE _R is incompatible and leads to an integration error. The developer responsible for the software element SWEi can then program a new version V5 goal-oriented, which possibly leads to an executable software constellation SWK.

In a preferred embodiment of the method according to the invention, automatic formal checks that check compliance with coding guidelines are carried out.

All change requests or change requests CR, which have led to an executable software configuration SWK, receive a corresponding status or state. As a result, the successful implementation of all CR change requests can be automatically monitored. In the method according to the invention, the iterative substitutions made are logged and stored. Based on the replacements, a report is automatically generated so that developers involved in the software development project can be kept up to date with the latest developments. By automatically reporting the processed change requests, it is ensured that the programmed available in the configuration management system according to the invention

SWE software components actually meet or meet the requirements formulated in the specifications. In the method according to the invention, the errors occurring during the build process can be recognized at an early point in time and can thus be remedied by the developer at an early stage.

Claims

claims

1. Method for the automated testing of a software configuration (SWK) consisting of a number of software elements (SWE), the software elements being based on an initial software configuration that forms the current self-executable versions (V _N ) of all software elements of the software configuration (SWE) are each iteratively replaced by a previous version (V _N _ i) of the respective software element until the tested software configuration (SWK) is an executable software configuration.

2. The method of claim 1, wherein upon an incoming change request for a software element based on an existing version of the software element SWE, a current version of the software element is generated.

3. The method of claim 2, wherein the current version of each software element (SWE) is tested in each case in a single test for their runnability out.

4. The method of claim 2, wherein each change request of a software element SWE comprises a description of the changes to be made to the software element and a status field for indicating a state of the change requests.

5. The method of claim 4, wherein each change request takes one of four states, namely, a first state indicating that the change request is in progress, a second state indicating that the software element changed in response to the change request has been tested successfully and is executable, a third state indicating that the software element modified for the change requests has been successfully tested in the software configuration under test (SWK), and a fourth state indicating that the changed software element is responsive to the change requests software configuration to be tested (SWK) has not been successfully tested.

6. The method of claim 1, wherein the iterative replacements performed are logged and stored as software item versions to go from the initial software constellation to an executable software constellation.

7. The method of claim 6, wherein based on the logged replacements that change request is determined, which has led to a non-executable software constellation (SWK).

8. The method of claim 1, wherein the software configuration (SWK) comprises data fields indicating the version numbers of the software elements (SWE) contained therein.

The method of claim 8, wherein the software configuration (SWK) comprises a status field indicating whether the software configuration is executable.

10. A configuration management system for automated testing of a multiple software element (SWK) software configuration based on an initial software configuration that includes the current self-executable versions of all of them

Software elements (SWE) of the software configuration to be tested (SWK) comprises, the software elements by the previous version of each software item is iteratively replaced until the software configuration being tested (SWK) is an executable software configuration.