Planning: Testing Making your program ‘crash proof’

5
Planning: Testing Making your program ‘crash proof’

Transcript of Planning: Testing Making your program ‘crash proof’

Page 1: Planning: Testing Making your program ‘crash proof’

Planning: Testing

Making your program ‘crash proof’

Page 2: Planning: Testing Making your program ‘crash proof’

Purpose

• Ensures that each separate part of a program works as expected. – Functions() and Procedures()

• Ensures that when combined all parts work as expected: – They receive the correct parameters and return

the correct data• Makes the development cycle more efficient

Page 3: Planning: Testing Making your program ‘crash proof’

What to test

• Expected inputs: – If used as intended are ‘normal inputs’ processed

as expected• Boundary inputs: – Inputs at the top and bottom limits of ‘normal

inputs’• Invalid inputs: – Those which are unacceptable and may crash the

program

Page 4: Planning: Testing Making your program ‘crash proof’

Eg “Enter your age”Example Input Type Result

12 Valid (if Int data type) Program continues

12.5 Valid (if Float data type) Program continues

1 Boundary (minimum) Program continues

120 Invalid (Too high) Error msg displayed.

Abc Invalid (wrong data type) Error msg displayed

NULL (no entry) Invalid (Cannot be “ “) Error msg displayed

Twelve Invalid (wrong data type) Error msg displayed

Each entry MUST be tested and the appropriate response confirmed.Errors MUST be trapped (identified) and addressed.

Failure to do so will crash your program!!

Page 5: Planning: Testing Making your program ‘crash proof’

Good Testing

• Does identify errors.. These are normal• Usually need more time and more code than

the program itself• Must be structured and documented– What you tested– Where in the program– What was the outcome