Home  Back Topics CD Orders  INDEX 
Algorithm Testing

How do you know if your algorithm (program) works?

Well..you test it...Try it out with a variety of test data and see if any problems arise.

One technique is to dry run the program.

This involves writing down a table of the instructions which are executed and noting the values of all the constants and variables as each instruction is executed. Such a table is called a trace table.

Example

This is a procedure which does nothing sensible (except illustrate how a dry run should be done!).

Suppose we wanted to test a procedure called 'Frenzy' which uses a parameter 'Num'. 

procedure Frenzy( Num : integer);
var i ,fred : integer;
begin  
  set fred = 5;
  for i = 1 to Num do
  begin
    set fred = fred - i;
    output(fred);
  end;  
  output('Done');
end;  

To dry-run this procedure we need to create a trace table with column headings:

  • the instruction being executed
  • the values of each variable after execution (Num, i and fred)
  • any output done

The trace table for the procedure Frenzy(3) would be...

Instruction

 Num i fred Output
Start up.. 3      
set fred = 5 3   5  
for i = 1 to Num do 3 1 5  
set fred = fred - i 3 1 4  
output(fred) 3 1 4 4
for i = 1 to Num do 3 2 4  
set fred = fred - i 3 2 2  
output(fred) 3 2 2 2
for i =1 to Num do 3 3 2  
set fred = fred - i 3 3 -1  
output(fred) 3 3 -1 -1
output('Done') 3 3 -1 Done

Notes about the above...

  • begins and ends are ignored - they do not affect any values
  • each time the loop instruction (for i := 1 to Num) is executed the value of i is incremented.
  • the parameter value is immediately entered at the beginning.

Even if this procedure does nothing sensible, it is a good procedure because it does not use values or results from other procedures. ie we can test it on its own.

Okay..so you need a lot of paper...but it is a useful technique if you have a program which does not work properly....and it really is useful when doing Assembly Language programming...but that's another story....

 

 

Selection of Test Data

When testing an algorithm, you need to run a sequence of tests. If one test works, that does not mean the program will work every time!

Select...

  • data which is 'normal'
  • data which is extreme
  • data which is incompatible ie data of the wrong type
  • data which is non-existent ie zero or null data

Example

If you are testing a procedure which calculates the VAT on the price of a purchased item, choose

  • sensible prices eg £12.50
  • very large or very small prices eg £0.01 or £12,000,000,000,000,000.00
  • try giving it a string! eg 'Hello'
  • try £0.00 or even a null input.