IT201800004297A1 - METHOD FOR AUTOMATIC TESTING OF THE ERROR CONDITIONS OF SOFTWARE PROGRAMS - Google Patents

Description

DESCRIPTION

METHOD FOR THE AUTOMATIC TEST OF THE ERROR CONDITIONS OF

SOFTWARE PROGRAMS

TECHNICAL FIELD

The method proposed by the following invention allows to automatically test the error conditions of a software application that uses the technology of the so-called "error traps"

STATE OF THE ART

Assuming the software program is divided into subprograms, called routines or methods, as it is universally adopted in languages from generation IV onwards, methods that are characterized by a name or signature that is called up from other parts of the program with a whole series of variable parameters.

Software applications or programs may, in each line of code being processed, face an error condition in which the program is unable to move forward, for example the division of u number where the divisor has a value of zero.

In Generation IV languages this leap in the dark is framed towards a jump on particular lines of code where a coded error message or other code managed by the programmer is inserted. For languages inheriting C we have, within each routine or method, the construct TRY (observe this group of lines of code) and CATCH, followed by a group of lines of code. When a line of code belonging to the group under observation TRY goes into any error, the processing of the program jumps into the group of lines of code of the CATCH construct, processing them sequentially.

SUMMARY OF THE INVENTION

The source code is reworked by adding lines of code that are useful only for testing error conditions: It doesn't matter which error is generated, as the CATCH lines of code are universal for all error conditions. The source code is then rewritten by manually inserting the TRY CATCH construct on all the routines or methods of the program. This preliminary operation of the programmer allows to activate the methodology described by the following invention automatically with a special software that reads the source code and returns it modified.

It is then inserted automatically, at the beginning of each routine or method, after the TRY construct, a line with a known error, for example the aforementioned division by zero, and then, at the end of the group of lines of code of the CATCH construct some code that clears the error condition, for example re-evaluating the variable that was zero with a non-zero value, and then calling the same method or procedure in recursive mode.

Obviously the division by zero is just an example, the methodology of the present invention simply provides that a known error is inserted in the TRY construct and that in the CATCH construct, before calling the routine in recursive mode this error is resolved in order to make the program in error-free mode. Advantageously, this test is carried out when the true errors of the program have already been corrected. The methodology is applicable to all software developed with languages that use the technology of the "error trap" which only in some languages is called "CATCH",

BRIEF DESCRIPTION OF THE DRAWINGS

In figure 1 we can distinguish:

START ROUTINE

BUILT TRY

LINES OF CODE INSERTED WITH KNOWN ERROR (1)

BUILT CATCH

CODE LINES INSERTED WITH KNOWN ERROR RESET (2)

RECURRING REQUEST START ROUTINE (3)

In the processing, when the program finds (2) it jumps into the CATCH construct, processes all the lines of the CATCH construct and then finds (2) which cancels the error condition (1), then with the instructions (3) it returns to the start of the routine processing the source code with no added errors.

Claims (1)

CLAIMS 1] Method for testing error conditions written in software in the so-called "error traps" characterized by the following steps: a) Verify that the software is written in a language structured in subroutines, otherwise called routines or methods b) Verify that all subprograms have the error trap and a group of lines of code under observation where an error causes you to jump into the error trap e) Insertion of additional lines of code, for the sole purpose of the test, lines of code involving a known and certain error in any position in the group of lines of code under observation d) Insertion of additional lines of code, for the sole purpose of the test, after the original lines of code of the error trap, the lines of code that reset the known error referred to in point e) e) Insertion, after the lines of code of point d), of the recursive call of the subroutine in which we are operating, whose execution at this point will no longer go into error because the code of point e) will no longer give an error thanks to the code of point d) 2) Automatic realization of points e) d) e) of claim 1) with software that reads the source code and rewrites it modified 3] Extension of the method of claim 1 also to the case that in a subroutine there are several groups of code lines under observation and therefore more error traps by repeating points e) d) and e) of claim 1 several times 41 Automatic realization with a software that reads the source code and rewrites it, also modified, of the semantic construct described in claim 3)