WO1995002863A1

WO1995002863A1 - Process for testing an object-oriented programme

Info

Publication number: WO1995002863A1
Application number: PCT/DE1994/000781
Authority: WO
Inventors: Peter JÜTTNER; Sebald Kolb; Stefan Sieber; Peter Zimmerer
Original assignee: Siemens Aktiengesellschaft
Priority date: 1993-07-15
Filing date: 1994-07-07
Publication date: 1995-01-26
Also published as: DE59407929D1; EP0708941A1; DE4323787A1; EP0708941B1

Abstract

In order to test object-oriented programmes, a process instruments the programme locations in which communications between objects are involved. When the programme is run, all communication processes between objects are recorded with their corresponding parameters in a protocol file. This protocol file is then processed in an appropriate manner, so that the results of the object-oriented design may be directly compared with the programme operation, for example by means of a graphic representation.

Description

Procedure for testing an object-oriented program s

The technology of object-oriented programming has become increasingly established when creating extensive programs. This technique offers various advantages both in the creation of the programs and in the execution.

For example, the programmer is structured

Programming made easier. Furthermore, it is easy to adopt classes from existing programs for new programs. Since objects can be created and deleted at runtime, only the currently required memory is used at any point in the process. The technique of OOD (object oriented design) [1] has become established in connection with the creation of object-oriented programs. This technique makes use of graphical input options when creating programs and is explained in more detail in [2] - [5].

Difficulties currently exist in testing object-oriented programs. This is due in particular to the dynamic structure of these programs. Since objects are created and deleted again as well as methods are called during the program run, it is difficult to check all objects and method calls with regard to their correctness and their parameters during a test.

Methods and tools which permit an extensive test of object-oriented programs are currently not known. The object of the invention explained below is to provide a method for testing an object-oriented program.

This object is achieved in accordance with the features of patent claim 1.

Further developments of the invention result from the subclaims.

Since the function of object-oriented programs is based on the communication of the objects with one another, the communication of the objects with one another is advantageously analyzed in the invention. This happens according to the invention in that all communication-relevant points in the programs, i.e. Instrumented in the classes and in the method calls so that the test-relevant information (e.g. method name, parameter values, caller and called object) can be recorded in a separate log when, for example, calling the method or instantiating or deleting an object. Another component of the method according to the invention consists in the advantageous evaluation of a created log file. This clearly shows the program flow to a test end.

The program sequence is illustrated graphically in an advantageous manner. If this representation is selected so that it corresponds to the graphic representation in the object-oriented design, the specification of the program with the actual sequence can be done simply manually or automatically to compare.

The instrumentation for methods provided according to the invention offers the advantage that the test can be easily checked with which parameters which method was called. Furthermore, one can statistically evaluate how often a method has been called. The instrumentation of the method calls provides information about the parameters passed and about which method calls are used to call which methods in which objects. By instrumenting, for example, the method call points in the various objects, information is obtained that is needed above all for the analysis of linked method calls. Chained method calls are method calls that, for example, start from an object and in turn cause a method call in another object and which can then call a method in a next object.

An advantage of the method according to the invention is above all the creation of object balances. This makes it easy to determine statistically which and how many objects from which classes were instantiated during the program run. It can also be seen from this whether all the objects called were actually used and whether the methods were used to address the correct objects. It is also easy to see whether all instantiated objects have also been deleted. This also gives you the opportunity to monitor the activity of the programmer. In larger companies, programmers are often instructed to reuse previously created classes or program parts in new programs. With the method according to the invention, it is now easy to check whether the classes that have been integrated into a new program are also used or whether they only represent a quasi-unnecessary ballast in the program code.

In the following the invention is further explained with the aid of figures and examples. Figure 1 shows an example of a block diagram of the inventive method.

Figure 2 shows the specification of an object-oriented program.

Figure 3 shows the implementation of the program of Figure 2.

FIG. 1 shows an example of a block diagram of the method according to the invention. With I / O is the output and input of the specified and non-instrumented object-oriented

Programs. The instrumented object-oriented program is represented by IP. P denotes the protocol file that is created during the test. TAP represents the test evaluation program with which the log file created during the test is prepared. SD is the specification data with which the object-oriented program was specified. The prepared protocol data can be output, for example, on a PC on a printer and in a file F using the test evaluation program TAP. In this example of the method according to the invention, the following occurs when testing an object-oriented program. The original inputs, the I / O, are fed to the instrumented object-oriented program IP. When the instrumented program IP is processed, the input data I / O is processed, and if program parts instrumented in the program IP are addressed, test protocol data result which are stored in a protocol file P or a protocol P. The output data from IP correspond to the output data of the non-instrumented program. For example, methods and call points for methods in objects are instrumented in the object-oriented program. In particular, in the case of programs created in C ++, all member functions, static member functions, constructors, destructors, overloaded operators, friends and casts can be instrumented. The protocol P is then evaluated, for example, by the test evaluation program TAP. In the course of the evaluation, the log file can be displayed graphically, for example. A particularly suitable form of graphic representation is offered by the graphic format which was used when specifying the program in the course of the object-oriented design. This makes it easy to determine differences between the program and the associated specification by comparing protocol data with the specification data SD. It is possible to output these differences on the screen or on the printer or to save them in a file so that they can be processed further. When analyzing protocol P by the test evaluation program TAP, other evaluation methods are also conceivable. For example, the object landscape can be displayed. That means at a current point in time, or for a period of time all existing objects can be output. It is also conceivable to represent a method call tree. This method call tree shows all other method calls that result from a selected method call. Furthermore, you can think of the

To display the object landscape with the call relationship, it being possible to display all objects that ever exist, including their mutual method calls. In addition, it is conceivable to display the class landscape with its call relationships. As a result, all existing classes, including their method call relationships, are shown among themselves. All of these previously listed representations are used in the various OOD methods for specifying an object-oriented program. The log file can be analyzed for statistical characteristics in an analogous manner. For example, all objects can be counted. All method calls can be counted, and one can analyze the maximum and minimum existing ones Objects or method calls make statements about program complexity.

FIG. 2 shows an object-oriented program in graphical representation according to the type of object-oriented design (OOD). Three objects ol to o3 from associated classes K1 to K3 are shown, ol calls a method ma with the parameters x and y for the object o2. ol also calls a method mb with the parameters z, x and c for object o3. FIG. 2 shows here, for example the specification form of the object-oriented program. The source code of the object-oriented program follows for this specification.

1. C ++ source code

The example is described below in C ++ syntax.

class K1 {pubiic:

void m () {

K2 o2; // standard constructor call K3 o3; // standard constructor call int x = 1, y = 2; ftoat z = 1.5; char c = '*';

// ot er Statements of the method o2.ma (x, y);

// other statements of the method o3.mb (z, x, c);

// other statements of the method

} class K2 {public:

void ma (int p, int q) {

// Statements of the method}

class K3 {public:

void mb (float I, int m, char n) {

// Statements of the method}

}

void main () {K1 o1; // Standard constructor call

// other statements o1.m ();

// other statements

}

The source code instrumented according to the method according to the invention now follows for the example shown. The instrumented areas are highlighted in bold. 2. Instrumented C ++ source code

class K1 {public:

K1 () 0 {// Standard constructor was added protfile «" call K1 :: K1 () \ n "

«" In file ... at line ... happened \ n "; protfile «" Parameters: \ n "; protfile «" no \ n "; 5} void m () {protfile «" call K1 :: m0 \ n "

«" In file ... at line ... happenedVn "; o protfile «" parametersΛn "; protfile «" no \ n ";

K2o2; // Standard constiuctor call protocol «" dcl K2 o2 in K1 :: m () \ n "« "in file ... at line ... \ n"; 5 K3o3; // standard constructor call protocol «" dcl K3 o3 in K1 :: m () \ n "

«" In file ... at line ... \ n "; int x = 1, y = 2; 0 ftoatz = 1.5; charcs ^{1 * 1} ;

// other statements of the method 5 protocol «" call o2.ma (x, y) from class K2 \ n "

«" In K1 :: m () in file ... at line ... started \ n "; protfile «" parametersΛn "; protfile «" int x = "« x «", int y = "« y «" \ n "; o2.ma (x, y); o protfile «" call o2.ma (x, y) from class K2 n "

«" In K1 :: m0 in file ... at line ... ended \ n "; protfile «" parametersΛn "; protfile «" int x = "« x «", int y = "« y «" \ n "; // other statements of the method protfile «" call o3.mb (z, x, c) from class K3 \ n "

«" In K1 :: m () in file ... at line ... started \ n "; protfile «" Parameters: \ n "; 5 protfile «" float z = "« z «", intx = "« x

«", Char c = "« c «" \ n "; o3.mb (z, x, c); protfile «" call o3.mb (z, x, c) from class K3 \ n "}

«" In K1 :: m () in file ... at line ... ended \ n "; l o protfile «" parametersΛn "; protfile «" float z = "« z «", int x = "« x «", char c = "« c «" \ n ";

// other statements of the method

15

20 class K2 {public:

K20 •

25 {// Standard constructor was added protfile «" call K2 :: K2 () \ n "

«" In file ... at line ... happened \ n "; protfile «" parametersΛn "; protfile << "no \ n";

30} void ma (int p, int q) {protfile «" call K2 :: ma (p, q) \ n "

«" In file ... at line ... happenedVn "; 35 protocol "" Parameters at the begin of K2 :: ma (p, q): n "; protfile «" int p "« p «", int q = "« q «" n ";

// Statements of the method protfile «" Parameters at the end of K2 :: ma (p, q): \ n "; 40 protfile «" int p = "« p «", int q = "« q «" \ n ";

}} class K3 {public:

K30

{// Standard constructor was added protfile «" call K3 :: K30 n "

} void mb (ftoat I, int m, char n) {protfile «" call K3 :: mb (l, m, n) \ n "« "in file ... at line ... happened \ n"; protocol "" parameters at the begin of K3 :: mb (l, m, n): \ n "; protfile «" float I = "« I «", int m = "« m «", charn = "« c «" \ n "; // Statements of the method protfile «" parameters at the end of K3 :: mb (l, m, n): \ n "; protfile «" float I = "« I «", int m = "« m «", charn = "« c «" \ n "; }}

void mainQ {

{ofstream protfile ("protoco); // protocol file} protfile« "call main () \ n"

K1 o1; // Standard constructor call protocol «" dcl K1 o1 in main () \ n "« "in file ... at line ... \ n";

// other statements protfile «" call ol.mO from class K1 \ n "

«" In mainO in file ... at line ... started \ n "; protfile «" parametersΛn "; protfile <<"no \ n"; o1.m (); protfile «" call otmO from class K1 \ n "

«" In mainO in file ... at line ... ended \ n "; protfile «" parametersΛn "; protfile «" no \ n ";

// other statements}

Although the source code is instrumented here, it is also possible if you have sufficient knowledge of the hardware used and the corresponding compiler in connection with the object code that is generated for the object-oriented program knows that the corresponding instrumentation also takes place at the object code level.

Only the instrumentation of the source code has been selected here in order to be able to present a clear example. This instrumented source code leads to an output protocol file which follows.

3. Output of the log file

The log file created when the program runs (main function) is listed below. The inserted blank lines are only for better readability.

The specified parameter values are, of course, only exemplary; logically, they depend on the statements in the method trunks that are not detailed here. Likewise, when "in file ... at line ..." is output, the three dots specified ("...") are each replaced by the current file name and the current line number in the (non-instrumented) source code. call mainO in file ... at line ... happened parameters: no

call K1 :: K1 () in file ... at line ... happened parameters: no

dcl K1 o1 in mainO in file ... at line ... call o1.m () from class K1 in mainO in file ... at line ... started parameters: no

call K1 :: mO in file ... at line ... happened parameters: no call K2 :: K20 in file ... at line ... happened parameters: no

dcl K2 o2 in K1 :: mO in file ... at line ...

call K3 :: K30 in file ... at line ... happened parameters: no

dcl K3 o3 in K1 :: mO in file ... at iine ...

call o2.ma (x, y) from class K2 in K1 :: m () in file ... at line ... started parameters: int x = 1, int y = 2 call K2 :: ma (p, q) in file ... at line ... happened parameters at the begin of K2 :: ma (p, q): int p = 1, int q = 2

Parameters at the end of K2 :: ma (p, q): int p = 1, int q = 2

call o2.ma (x, y) from class K2 in K1 :: m0 in file ... at line ... ended Parameters: int x = 1, int y = 2

call o3.mb (z, x, c) from class K3 in K1 :: m0 in file ... at line ... started

Parameters: float z = 1.5, int x = 1, charc = ^* call K3 :: mb (l, m, n) in file ... at line ... happened Parameters at the begin of K3 :: mb (l, m, n): float I = 1.5, int m = 1, char n = *

Parameters at the end of K3 :: mb (l, m, n): float I = 1.5, int m = 1, char n = *

call o3.mb (z, x, c) from class K3 in K1 :: m () in file ... at line ... ended Parameters: float z = 1.5, int x = 1, char c = ^* call o1 .m () from class K1 in mainO in file ... at line ... ended Parameters: no

With the method according to the invention, the graphic representation of FIG. 3 is now generated via the preparation by the test evaluation program TAP. It shows three objects ol, o2 and o4, whereby ol on object o2 shows the method ma with the parameters calls x and y and calls method mb on object o4 with z, x and c. It can clearly be seen here that FIG. 3 has a deviation from the specification which is shown in FIG.

In FIG. 3, the mb method is called on object o4 instead of object o3, which does not correspond to the design. Analogously, further deviations from the design, e.g. missing or additional (and thus possibly superfluous) method calls are determined.

It is important to note in the method according to the invention that the log file, for example determined by the instrumentation of the source code, only serves as a means to an end. It is essential that the log file is processed further and, for example, suitably prepared graphically. In this context, suitable means that the preparation takes place in affinity for the display in the phase of the object-oriented design. One goal here, for example, is to directly link the actual program flow with the design, i.e. to be able to compare with the results from the OOD phase.

In particular, the instrumentation of the program to be tested can also advantageously be automated using an instrumentation program that is not described in more detail here.

Claims

claims

1. Method for testing an object-oriented program (ol, o2, o3, o4), a) in which at least one communication process (ma (x, y)) between objects of the program logs in a protocol (P) is instrumented by at least one part of the program that is affected by the communication process, b) in which the program runs at least once on a computer, c) and in which the test (TAP) is carried out by the protocol (P) is evaluated.

2. The method as claimed in claim 1, in which the protocol (P) is automatically prepared in the graphic format in which the specification of the object-oriented program was carried out, so that the program can be tested against the specification.

3. The method according to any one of claims 1 or 2, in which methods (ma (x, y), mb (z, x, c)) are instrumented.

4. The method according to any one of the preceding claims, in which method calls are instrumented.

5. The method according to any one of the above claims, in which te called up and / or deleted program learning are recorded as a balance sheet.

6. The method according to claim 5, in which balance sheets are created for classes, objects, or methods by comparing the number of calls and deletions.

7. The method according to any one of the above claims, in which the reuse of at least one class inserted in the object-oriented program is checked via a statistical evaluation.