Programming Translators

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)

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.

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

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

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.

There are three types program error (bug)

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.

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.

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

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).

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).

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).

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

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.

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

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.

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, 16.345

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?

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

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.

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.

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.

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.

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.

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.

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.

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

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

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

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.

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.

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.

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.