1 IPC144 Session 5 Problem Analysis and Program Design Continued.

1

IPC144Session 5

Problem Analysis and Program DesignContinued

2

Objectives

Design good test dataSynthesize a Test Plan from test dataApply a rigorous approach to testing flowcharts using Walkthroughs

3

Test Data

Test DataFrom the PDC:

PDC: Test the Algorithm for Correctness

One of the most important stepsIdentifies major logic errorsWalkthroughs are a technique for testingTest plans are used to document and plan the tests necessary to prove your algorithm performs as required

4

Test Data, continued

Test Data, continuedThere could exist an infinite number of possible values that a program can accept as input.

For example, write a program that accepts three numbers, adds them together and displays their total and average.

There are an infinite number of possible input values- does this mean that we must try all possible values to ensure that the program works correctly?

There must be a reasonable set of test data we can use to prove the algorithm works empirically.

5


Test Data, continuedThere are two general types of testing:

Black Box TestingWhite Box testing

6


Black box testingThe system, or program, is tested without knowing what is inside it

Tests are developed based solely on the requirements statement - based on the inputs, what are the expected outputs

Used to test the system or a multi-module program as a whole

Can be used to help clarify the requirements statement as you find test data that does not appear to be accounted for in the requirements

7


White box testingThe algorithm is tested knowing what is inside it

It can only be developed by a programmer (typically the programmer that created the software)

Everything about the program is known- therefore everything is tested for

You must test every possible program instruction and every possible situation.

8


White box testing, continuedStart identifying test data during the Design Phase

As you build your flowchart & pseudocode look for test cases, document them as you find them

Look for unusual conditions / situations to be added to your testing

As you find conditions that are not handled by your algorithm- enhance your algorithm and add the test to your Test Plan.

What is good test data for both Black Box Testing and White Box Testing? What do we look for?

9


Test DataBlack BoxLook at requirementsGet test data and expected results from the user.What if user ends program as their first action?Unexpected values (user types words instead of a number)

White BoxLook at the Program and how it was writtenDefine data that will result in all branches of all decisions being testedEnsure that ranges are tested for their minimum and maximum valuesLook for ways that a divide by zero may happenSimulate all possible error conditions (even if you have to alter your program to ensure they occur)

10

Test Plans

Test PlansWhy all the trouble?

User groups and Audit departments look for them

Provides a concise description of WHAT was tested

Provides a concise description of HOW it was tested

Provides a concise description of the ENVIRONMENT it was tested in

A well design and documented test plan can break the 'finger pointing'

11

Test Plans, continued


Provides a concise description of WHAT was tested

At some time software comes under scrutiny:The system has failed - was this scenario tested?Somebody (maybe you) months later asks the question was ______ tested?

12



Provides a concise description of HOW it was tested

What were the test cases?

What data was used?

Was certain sequence of events tested for?

Again, a system failure may precipitate the question: Was this sequence of events tested for?

13



Provides a concise description of the ENVIRONMENT is was tested in

What other programs where part of the package?

What was the version of these other programs?

What hardware was it tested on?

What was the version of the operating system?

It "NEVER" happens that after you have certified a system somebody changes a component and doesn't tell you!

14



An example of the parts of a Test Plan:

Cover Page

Environment setup

Black Box Testing

White Box Testing (can include “negative tests” to ensure the program does not crash or have undesired side-effects)

15


Test Plans - Cover Page

A brief description of what the program or system does.

Not too technical - just enough that somebody non-technical can understand what the program does

An extract of the requirements statement may form part of the cover page

16


Test Plans - Environmental Setup

Optional – depending on nature of your work environment

More technical description

What hardware is being used (as specific as necessary)

What version of the operating system is being used

What is the version of YOUR program that is being tested

The files that are used to makeup your program

What are the versions of the other programs that interface with yours

Are there versions of test data files?

17


Test Plans - Black Box Testing

These tests are to ensure that the program meets the requirements statement

Predominately positive testing is performed

Hopefully the Business Analyst has provided test cases that can be incorporated into the Test Plan

Concentrate on obtaining the correct outputs for the test inputs

Each test has two parts: the test, the expected results

18


Test Plans - White Box Testing

These tests are to ensure that the program handles all expected and unexpected data

Every path within the program must (at least in this course) be tested.

Can become very complex with the inter-relationships between variables

One philosophy behind White Box Testing is that "it would be nice that whenever a program prompts a user for a number, the users always enter a legitimate value that the program can handle"

May require modifications to the code to simulate error conditions (be sure to perform these modifications and tests on a COPY of the program)

Each test has two parts: the test, the expected results

19


Test Plans - Negative Testing

The intent is to maliciously attack your code - to see where (if) is breaks

Can be an easy task or frustrating task depending on how well constructed the code is

You will normally have built into your code a means to detect error conditions

The goal of your program is to shut down gracefully (return an error code or error message) as opposed to crashing or affecting other programs or systems

20


ExampleWrite a program to help a local Elementary School's library with the overdue fines on books. The librarians don't wish to always charge students for overdue books, however sometimes the number of books that are overdue is too much. When this happens the librarians enter into the program the student's name, the name of the overdue book they borrowed, and the date it was signed out (the librarian reads these fields from the sign-out card). The colour of the card is also entered, as this indicates what the normal sign-out period is for that book. White cards are due back in 14 days, Blue cards in 7 days, Green cards the next day, and Orange cards in 28 days. The colour code of the card is entered as a single character into the program (W, B, G and O). When this information has been entered, the program determines by how much the book is overdue (based on the date the program is run) and the overdue charge, ($0.05 per day). A list is produced that will show the student's name, the name of the book, the number of days the book is overdue and the fine that is payable.

21


Library Fines Test Plan

The program is a tool that will allow librarians to assess fines on overdue library books. The fine is calculated as $0.05 / day.

The fines are based on the colour code of the sign-out cards, where:Orange Cards - 28 day sign-out periodWhite Cards - 14 day sign-out periodBlue Cards - 7 day sign-out periodGreen Cards - 1 day sign-out period

The librarian is responsible for entering the student name, book name and the sign-out date.

22


Environmental Setup

Program and Version:library.c Version 1.0

Hardware:IBM RS/6000

O/S:AIX 4.3

Compiler:cc

Other files:no other files are required

23


Black Box Testing

1) Enter 'Stu1', 'Book1', 'O', today's date - 30Expected result: overdue = 2, fine = $0.10

2) Enter 'Stu2', 'Book2', 'W', today's date - 30Expected result: overdue = 16, fine = $0.80

3) Enter 'Stu3', 'Book3', 'B', today's date - 30Expected result: overdue = 23, fine = $1.15

4) Enter 'Stu4', 'Book4', 'G', today's date - 30Expected result: overdue = 29, fine = $1.45

5) Enter 'Stu5', 'Book5', 'G', today's dateExpected result: overdue = 0, fine = $0.00

24


White Box Testing

1) Enter a colour code other than 'O', 'W', 'B', 'G'.Expected Result: error message “Invalid card colour code entered”. Program to prompt for the colour code again.

2) Enter a future date (i.e. the book is not yet overdue)Expected Result: error message “Invalid Future date entered”. Program to prompt for the date again.

25

Walkthroughs

Walkthroughs

Walkthroughs are a means to test the algorithm BEFORE it has been coded

Walkthroughs are a tool to test that your algorithm behaves correctly

Because the computer is a mindless automaton - in order to check the program YOU must become the mindless automaton!

You 'play computer' - turn OFF your mind and follow the instructions EXACTLY as written

Remember to follow the instructions and perform what is asked for, not what you want to happen

26

Walkthroughs, continued


It is hard to keep track of the many variables in a program, so take a sheet a paper: List the variables, and their values. Keep track of the new values of a program as you execute the instructions

For output, reserve a space on your paper to track any information that is displayed to the user.

This can be very tough, as it is very easy at this stage to execute the instructions as you WANT them to be executed.

When we talk about pseudo code, walkthroughs can be used to test the INTEGRITY of the code after it has been translated from flowcharts to pseudo code.

27


Walkthroughs, continuedstar

t

num = 1var = 0

var = num+ var

DISPLAY var

num <= 7

num = num + 2

TRUE

stop

FALSE

28



Start

i > 0

i = 5

Stop

FALSE

TRUE

f = f * j

j = i

j > 1

j = j - 1

i = i - 1

f = 1

FALSE

TRUE

DISPLAY “Done” DISPLAY f

Date post:	16-Jan-2016
Category:	Documents
Upload:	kristian-raymond-osborne
View:	223 times
Download:	0 times

1 IPC144 Session 5 Problem Analysis and Program Design Continued.

Documents