written by: Noel Kalicharan•edited by: J. F. Amprimoz•updated: 10/1/2008
In this article on C Programming basics we discuss the last three stages of the program development process - testing and debugging, documentation and maintenance.
slide 1 of 4
Test and debug the program
Having written the program, the next job is to test it to find out whether it is doing its intended job. Testing a program involves the following steps:
1.compile the program: a computer can only execute a program written in machine language. Before the computer can run our C program, the latter must be converted to machine language. We say that the source code must be converted to object code or machine code. The program which does this job is called a compiler.
Among other things, a compiler will check the source code for syntax errors—errors which arise from breaking the rules for writing statements in the language. For example, a common syntax error in writing C programs is to omit a semicolon or to put one where it is not required.
If the program contains syntax errors, these must be corrected before compiling it again. When the program is free from syntax errors, the compiler will convert it to machine language and we can go on to the next step.
2.run the program: here we request the computer to execute the program and we supply data to the program for which we know the answer. Such data is called test data. Some values we can use for the length of a side are 3, 12 and 20.
If the program does not give us the answers 9, 144 and 400, respectively, then we know that the program contains at least one logic error. A logic error is one which causes a program to give incorrect results for valid data. A logic error may also cause a program to crash (come to an abrupt halt).
If a program contains logic errors, we must debug the program—we must find and correct any errors that are causing the program to produce wrong answers.
To illustrate, suppose the statement which calculates the area was written (incorrectly) as:
a = s + s;
and when the program is run, 10 is entered for the length. We know that the area should be 100. But when we run the program, we get:
Enter length of side: 10
Area of square is 20
Since this is not the answer we expect, we know that there is an error (perhaps more than one) in the program. Since the area is wrong, the logical place to start looking for the error is in the statement which calculates the area. If we look closely, we should discover that + was typed instead of *. When this correction is made, the program works fine.
slide 2 of 4
Document the program
The final job is to complete the documentation of the program. So far, our documentation includes:
the statement of the problem;
the algorithm for solving the problem;
the program listing;
comments in the program as seen in the previous article
test data and the results produced by the program.
These are some of the items that make up the technical documentation of the program. This is documentation that is useful to a programmer, perhaps for modifying the program at a later stage.
The other kind of documentation which must be written is user documentation. This enables a non-technical person to use the program without needing to know about the internal workings of the program. Among other things, the user needs to know how to load the program in the computer and how to use the various features of the program. If appropriate, the user will also need to know how to handle unusual situations which may arise while the program is being used.
slide 3 of 4
Maintain the program
Except for things like class assignments, programs are normally meant to be used over a long period of time. During this time, errors may be discovered which previously went unnoticed. Errors may also surface because of conditions or data that never arose before. Whatever the reason, such errors must be corrected.
But a program may need to be modified for other reasons. Perhaps the assumptions made when the program was written have now changed due to changed company policy or even due to a change in government regulations (e.g. changes in income tax rates). Perhaps the company is changing its computer system and the program needs to be migrated to the new system. We say the program must be maintained.
Whether or not this is easy to do depends in large part on how the original program was written. If it was well-designed and properly documented, then the job of the maintenance programmer is made so much easier.