1. Programming
Translators

2. Learning Objectives Explain: What translators do
The process of source-object code
The three major error types which will need to be tested
The concept of developing a test plan.
Black box testing
White box testing
The concepts of Alpha tests and Beta tests
Translator diagnostics
Cross referencing
Program traces
Variable dumps
Dry runs (desk checks)

3. Software
The general term used to describe all the programs, routines or procedures that run on a computer.
Makes a computer do something and are written to run on the hardware.
Computer instructions or data.
Any instructions that can be stored electronically are software.

4. Software Software Hardware Computer instructions or data.
Makes a computer do something and are written to run on the hardware.
Hardware
Software

5. e.g. Pascal, Visual Basic, C, Fortran
Software is usually written in a high level language which is fairly similar to our own spoken languages.
This makes it easier for us humans to use.
However, computers only understand machine code which is in binary form (1s and 0s).
Hardware
High Level Languages
e.g. Pascal, Visual Basic, C, Fortran
Machine Code

6. Translators
Translate high level languages (the translator’s source code) into machine code (the translator’s object code) which can be executed by a computer.
Translators
High Level Languages
Machine Code
Source
Code
Object
Code written in a high level language.
Code in executable form.

7. There are three types program error (bug)

8. 1. Syntax errors
Errors in a program that break the grammar rules of the language being used.
e.g.
PLINT instead of PRINT
3*(2+A) = X instead of X = 3*(2+A)
Simplest errors to solve as the translator will find these errors before the program is run.

9. Translator diagnostics
The translator looks up each word from a program in a dictionary.
The dictionary tells the translator program what the rules are for that particular word.
A wrongly typed word will not appear in the dictionary.
If rules governing how it should be used have not been followed properly, the translator will know that there is something wrong.
Either way, the translator program knows that a mistake has been made, it knows where the mistake is and, often, it also knows what mistake has been made.

10. Translator diagnostics
Messages detailing syntax errors sent to the programmer and usually giving hints as to what to do.

11. 2. Logic errors (also known as run-time errors if found when a program is run)
A mistake in the way the program solution has been designed.
e.g.
An instruction in a program may tell the computer to jump to the wrong part of the program.
Total_number = Previous_total – New_number
Known as logic errors if found whilst not running a program and using white box testing – see later slide 24.
Known as run-time errors if found when actually running a program (black box testing – see slide 17).

12. 3. Arithmetic Errors (also known run-time errors if found when a program is run)
Inappropriate use of arithmetic.
E.g. dividing by zero
Known as arithmetic errors if found whilst not running a program and using white box testing – see later slide 24.
Known as run-time errors if found when actually running a program (black box testing – see slide 17).

13. The last two errors (logic and arithmetic) will not be found by the translator, so the program will run but won’t work properly.
Known collectively as run-time errors if found when actually running a program (black box testing – see slide 17).

14. Program Development Testing: Debugging: Are there any errors (bugs)?
Where is the error (bug) and what is causing it?
Solve the error (bug).

15. Test Plan
A schedule drawn up which contains a test for every type of input that could be made and methods of testing that the program actually does what it was meant to do.

16. Alpha Testing
Performed by the programmers involved in writing the program.
Focus on error free processing.

17. Black box testing
Use of different input values to determine whether the program can cope with them.
These values should include
Different types of input e.g.
Typical values
Borderline values
Unacceptable values
Cannot see into the box (program) all you see is what comes out at the end.

18. Example 1 of Black Box Testing
A program which uses marks out of 100 from a math's examination as input.
Typical data like: 27, 73..,
Borderline data: 0 and 100
Unacceptable data like: –34, 123,

19. Example 2 of Black Box Testing
A program to work out the mean of three numbers.
1, 2, 3 Will integers give an integer answer?
1, 2, 4 Can the software cope with a recurring decimal answer?
(Note that “1, 2, 4 to test a different set of integers” would not get a mark because the reason for the test is not different)
1, 2.5, 3 Can the program handle decimal inputs?
1, 2½, 3 Are fractions allowed?
-1, -2, -3 Can negative numbers be handled?
1, 2 What happens when only two values are input?

20. Debugging Tools
Debugging tools to allow programmers to investigate conditions where errors occur.
The following slides describe some debugging tools.

21. Cross-referencing
This software checks the program that has been written and finds places where particular variables have been used.
This lets the programmer check to make sure that the same variable has not been used twice for different things.

22. Tracing variable values / Variable Watching / Stepping
Where the program is run and the values of all the relevant variables are printed out, as are the individual instructions, as each instruction is executed.
In this way, the values can be checked to see where they suddenly change or take on an unexpected value.

23. Break Points / Variable dumps / Variable Watches
At specified parts of the program, the values of all the variables are displayed to enable the user to compare them with the expected results.
This enables the programmer to see where sudden, unexpected changes occur.
Often used in conjunction with tracing variable values / Variable Watching / Stepping
i.e. set breakpoints and then use tracing from these points as required.
Particularly useful for long programs where errors are believed to be only in certain parts of the code.

24. White Box Testing / Dry Runs / Desk Checking
The user works through every logical path of the program instructions manually, keeping track of the values of the variables.
Basically manual tracing or variable watches.
Most computer programs require a very large number of instructions to be carried out, so it is usual to only dry run small segments of code that the programmer suspects of harboring an error.
Testing knowing the code.
Testing the structure and logic of all the algorithms within the code.
Known as “white box” as testing is done by looking at the code so the program is like a transparent box.

25. Beta Testing Testing carried out by the users of the program.
Eventually, the company will want ordinary users to test the program because they are likely to find errors that the programmers did not find.
Focus on usability, functionality, and performance.

26. Plenary
What is:
Source code?
Code written in hll.
Object code?
Code in executable form
Machine code?
Code in binary form.
What is the process which connects source and object code?
A translator turns the source code into the object code.

27. Plenary
Explain how the translator program prepares the programmer’s code into a program that the machine can run.
Translator program turns source into object.
Spots some of the errors in the source code.
Wrong (reserved) words
Wrong syntax in instruction construction
Reports errors to user.

28. Plenary State the meaning of the following types of testing.
White box testing.
Testing all possible routes through the program logic/Testing knowing the code/Test the algorithm. Note: not dry run on its own
Black box testing.
Test that the outcome is as expected for a given input/Testing not knowing the code
Alpha testing.
Testing by programmer/in-house
Beta testing.
Testing by public/end users/potential users/unconnected with writing

29. Plenary
State three types of program error and give an example of each.
Syntax error
Mistyping a reserved word, e.g. typing plint instead of print
Logic error
A jump instruction that tells the computer to jump to the wrong place
Arithmetic error
Inappropriate use of arithmetic.
Dividing by zero

30. Plenary
Describe the techniques that can be used to help debug a program.

31. White Box Testing / Dry Runs / Desk Checking
The user works through the program instructions manually, keeping track of the values of the variables.
Most computer programs require a very large number of instructions to be carried out, so it is usual to only dry run small segments of code that the programmer suspects of harboring an error.
Testing knowing the code.
Testing specific algorithms within the code.
Known as “white box” as testing is done by looking at the code so the program is like a transparent box.

32. Cross-referencing
This software checks the program that has been written and finds places where particular variables have been used.
This lets the programmer check to make sure that the same variable has not been used twice for different things.

33. Traces
A trace is where the program is run and the values of all the relevant variables are printed out, as are the individual instructions, as each instruction is executed.
In this way, the values can be checked to see where they suddenly change or take on an unexpected value.

34. Variable dumps
At specified parts of the program, the values of all the variables are displayed to enable the user to compare them with the expected results.