CIS 4932 Special Topics Software Testing Fall 2001 Practice -- Testing Forms © 2001, Dr. E.L. Jones

CIS 4932 Special Topics Software Testing

Fall 2001 Practice -- Testing Forms

© 2001, Dr. E.L. Jones

7/30/01 Unit Test Practice 2

What is Unit Testing?

• Executing a software element to determine whether it meets its specification

• Executing a software element to discover defects or anomalies

• Inspecting software element code to discover defects or anomalies.


What Is A Unit?

• Named software element with properties and behavior

• Separately invokable• Performs single function• Logically cohesive set of the above


Examples of Units

• User-Visible software elements• Fields on forms

• Buttons on forms

• Entire forms (reports)

• Program-Internal software elements• Subprograms (procedures, functions, mains)

• Classes

• Databases


Elementary Units

• Form• Field

• Navigation Button

• Operation Button

• Database• Field

• Stored Procedure

• Query

• Program Code• Main

• Method

• Function

• Script


WHY IS A FIELD A UNIT?

• Field has properties• Data type and domain (size, value set, default)• Visual appearance (color, case, alignment)• Accesibility" Read-only, write-only, R/W

• Field has behavior• Validation -- reject if property rule violated• Messaging -- to report violation• Global status -- bad field invalidates form


FIELD ATTRIBUTES and BEHAVIOR

• Data type

• Length

• Format

• Domain

• Default value

• Validation rules

• Error messages


TESTING AN INPUT FIELDAn Error-Handling Approach

• A primary function of an input field is to validate data entered into a field, and to notify the user if an error occurs.

• Properties of the field determine error conditions and the correct response

• Input field testing ensures that only valid input is accepted, and proper error handling occurs.


RELATIONSHIP BETWEEN ATTRIBUTES and VALIDATION

• Validation rules perform self-checking at field, form, and/or database level

• Lotus Notes prevents some input errors• Input masking prevents formatting and data

type errors

• List boxes prevent input errors

• Certain "semantic" errors still must be checked (inconsistency)


BEFORE WE CONTINUE … A LOOK AHEAD

• We derive generic test case specifications

for certain types of fields

• Text boxes -- string and numeric data

• List boxes -- string and numeric data

• These become worksheet templates for

designing field test cases


WHERE IS THE WORK? … A LOOK AHEAD

• Developer must supply actual test cases for each test case specification• Some specs expand into multiple test cases

• Developer may derive additional generic test case specs for new field types

• Developer combines test cases into a test worksheet.


Deriving Generic Test Case Specs for a Text Box

a1: PREVENTED | Action

a2: Data Type Error Msg | X a3: Length Error Msg | X a4: Format Error Msg | X a5: Domain Error Msg | X a6: Field set to Default | Xa7: Truncated/padded | Xa8: Input accepted | Xa9: FIELD ERROR | X

c1: Wrong Data type | Y N N N N Condition c2: Wrong Length | - Y N N N c3: Wrong format | - - Y N N c4: Illegal value | - - - Y N c5: Default value used | N Yc6: Wrong default value | Y


TEXT BOX Functional TEST CASES (Generic)

Case Stimulus Expected Response

1 Wrong data type Data type error message

2 Length error message

3 Length error message, truncate

4* Format error message

5 Value error message

7 ACCEPT Default value.

6 ACCEPT value

Default value selected

Non-Default value entered

Illegal value only.

Good type, length; bad format

Good type, too long

Good type, too short

8 UNEXPECTED: FIELD Error.Wrong Default value displayed

* Expand based on format syntax


TEXT BOX Boundary TEST CASES (Generic)


9 GOOD: Length = minimum ACCEPT field

101112 GOOD: value = "maximum"

GOOD: value = "minimum"

GOOD: Length = maximum

Tester sees only the Generic Test Cases, not the process followed to derive them.

ACCEPT field

ACCEPT field

ACCEPT field


DOSAGE CALCULATION FORM -- Specification

Field/Button Description (Specification)Patient Name

Patient Age

DosageCalculate Dosage ButtonClear Button

Name. 1-20 alpha/comma chars. Format: Last, First Middle

Computed output field. Whole number, in range 0-5.Action button. Compute dosage based on Age, Weight, and display in Dosage field.

List box: {12 and under, 13-65 (default), 65-80, over 80}.

Form button. Clear all input and output fields.

Patient Weight Weight in pounds. Whole number, in range 1-900.

Save Button Action button. Save form data to Trials Database.

GoBack Button Navigation button. Return to previous screen.


a) Fill in FIELD NAME

b) Create TEST DATA for each row.

c) Complete the expected result -- at minimum, issue a

message if an error occurs.

d) If a test condition does not apply for the field, delete

the row from the worksheet.

Your Turn -- Error Test Cases (Dosage Form Name Field)

1. Remove the Form Test Worksheet after Tab4

2. You will use Section A -- Field Unit Test

3. Complete the TextBox-Text Data template.


FORM TEST WORKSHEET – DOSAGE CALCULATION

Section A. FIELD UNIT TEST WORKSHEET

INPUT FIELD NAME: Patient Name FIELD CONTROL TYPE: Text Box DATA TYPE: Text

Test Case Description #FAILURES in Test RunCase

# Test Condition Test Case Data/Action Expected Result 1 2 3 4 5

1 Wrong data type

2 OUT: min length

3 OUT: max length

4 Bad Format

5 Illegal Value

6 Legal Value Accept

7 DEFAULT value

8 AT: min value Accept

9 AT: max value Accept

10 OUT: min value

11 OUT: max value

12 Wrong Default Observation UNEXPECTED

Total Failures for Test Run

Name Field Test WorksheetText Box (Text)








Your Turn -- Error Test Cases (Dosage Form Weight Field)

1. Use the Form Test Worksheet, Section A.

2. Complete the TextBox-Numeric Data template




INPUT FIELD NAME: Patient Weight FIELD CONTROL TYPE: Text Box DATA TYPE: Numeric (integer)



1 Wrong data type

2 OUT: min length

3 OUT: max length

4 Bad Format

5 Illegal Value

6 Legal Value Accept

7 DEFAULT value

8 AT: min value Accept

9 AT: max value Accept

10 OUT: min value

11 OUT: max value



Weight Field Test Worksheet Text Box (Numeric)


Deriving Generic Test Case Specs for a List Box

a1: PREVENTED | X X X X Action a2: Field set to Default | X a3: Input accepted | X a4: FIELD ERROR | X

Condition c1: Wrong Data type | N c2: Wrong Length | N c3: Wrong format | N c4: Invalid value | N c5: Default selected | Y N -c6: Wrong default value | N N Y

List boxes prevent these input errors.


LIST BOX Functional/Boundary TEST CASES (Generic)


1 Select Default value. ACCEPT DefaultValue

2 ACCEPT ListValue_k

3 FIELD Error, no message.Wrong Default value displayed.

Select k'th value from List.

* Boundary test cases.

4 First list item ACCEPT first ListValue.

5 Last list item ACCEPT last ListValue








Your Turn -- Error Test Cases (Dosage Form Age Field)

1. Use the Form Test Worksheet, Section A.

2. Complete the ListBox template.




INPUT FIELD NAME: Patient Age FIELD CONTROL TYPE: List Box DATA TYPE: N/A



1 Default value

2 First value

3 Interior value

4 Last value



Age Field Test WorksheetList Box


Other Form-Field Attributes(verify using checklist *)

• Form-Level Test– Data source

– Data destination

– Correlated fields

– Tab/Cursor sequence *

• Field-Level Test– Required Field

– Input only access*

– Output only access*

– Input/Output access*

– Visual appearance *


WHEN IS VALIDATION PERFORMED?

• At the field level, immediately upon changing focus from field (e.g., client side)• Supports field build & test

• At the form level, upon clicking a button that requires the data (e.g., server side)• Deferred field test, rolled into form test.


GOOD NEWS!A FIELD IS REUSABLE!

• Same field used on many forms

• Most attributes are the same, so are the validation rules

• Field implementation and test are reusable

• Only form-specific attributes may change

Insight: There are reusable test patterns based on field attributes.


Agenda

• Products & Deliverables

• Testing Forms: Fields & Buttons

• Testing Classes

• What is Unit Testing?

• Testing Callable Modules

• Putting It All Together


ObjectiveTesting a button is testing a function that uses form input field data, and may produce form output fields. There may be additional stimuli and responses beyond those observable from the form.

A button test is a black-box test.


Testing the SAVE Button

• Identify stimuli and responses• Schematic diagram

• Develop decision table• Ask questions about required behavior

• Identify conditions for certain behavior

• Develop test cases• Functional and boundary test cases


SAVE Button Black-Box Schematic

Stimulus Type Response Type

SAVEButton

ArgumentArgument

Inputs

GlobalsGlobals

Database

ExceptionException

ArgumentArgument

Outputs

GlobalsGlobals

Database

ExceptionException

Name, Age, Weight

Trials DB

Error Msg?

Trials DB


Asking the Right Questions

• Preconditions?• Trials database OPEN

and available

• Form fields are valid

• Postconditions?• Entry for patient in

Trials database

• #entries per patient?

• How are entries stored?

• Errors Detected, Messages?

• Field data not valid

• Unable to update, given field data


SAVE Button DECISION TABLE

c1: Trials DB open | N Y Y Y Y Y

c2: Valid Age | Y Y N Y Y

c3: Valid Weight | Y Y N Y

c4: Valid Name | Y Y N

c5: Name already in DB | N Y

a1: "DB not ready" msg | X

a2: Save | X

a3: "Duplicate entry" msg | X

a4: "Invalid Field" msg | X X X

* Impossible to have invalid Age: list box with default.* (a4) Possibly a different message for each field.


SAVE Button Functional Test Cases


1

1a

3

5

6

Trials DB not ready, good fields "DB not ready" msg, no save.

Trials DB not ready, bad Name field "??" msg, no save.

DB ready, duplicate Name "Duplicate" msg, no save.

DB ready, bad Weight only. "Bad Field" msg, no save.

DB ready, bad Name only "Bad Field" msg, no save.

2 DB ready, unique Name SAVED, no msg.

4x Impossible -- drop N/A

* Multiple errors: which one takes precedence?* Infeasible test case, given list box!


Your Turn -- Testing the CalculateDosage Button






Your Turn -- CalculateDosage Button Black-Box Schematic


Calculate DosageButton

Argument

Inputs

Globals

Database

Exception

Argument

Outputs

Globals

Database

Exception



• Preconditions?

• Postconditions?• patient?

Your Turn -- CalculateDosage Button -- Questions


Your Turn -- CalculateDosage Button Decision Table

c1: |

c2: |

a1: Dosage = calculated #pills |

a2: |

a3: |

a4: |

a5: |

NOTE: This table deals with the activation of the button in terms of visible form elements (input/output fields and error messages). Detailed rules for calculating the value were treated in Unit Testing Concepts session.


Your Turn -- CalculateDosage Button Test Cases

Case Test Data/Actions Expected Response

1

NOTE: These cases begin with form-level error handling for the CalculateDosage button, and contains functional test cases from the Concepts session.

2

3

4


Button Testing -- Summary

Testing a button is easy when the test analysis has already been performed on the underlying function. The form expands the scope of the function to include visible fields and hidden effects (e.g., database updates).

The basic question remains "what should happen, and where should I look for it?"


Form Testing -- Process

• Perform field tests• Perform button tests

• Form buttons*• Navigation*• Action buttons

• Perform cursor tests*• Initial position, tab sequence, position

after data entry or button activation------------------* via checklist


Section C. FORM BUTTON and NAVIGATION UNIT TEST CHECKLIST

CURSOR PLACEMENT and MOVEMENT


# Action Expected Result 1 2 3 4 5

1 Open form. Cursor in Patient Name field.

2 Enter valid Patient Name, then TAB. Cursor is in the Age field.

3 Accept valid Age value, then TAB. Cursor in Patient Weight field.

4 Enter valid Patient Weight, thenTAB.

Cursor on CalculateDosage button.

5 TAB from CalculateDosage button. Cursor on CLEAR button

6 TAB from CLEAR button. Cursor on SAVE button.

7 TAB from SAVE button. Cursor on CLEAR button.

Cursor on Dosage field.8 CLICK on CalculateDosage button.

Dosage field contains a value.

9 TAB from Dosage field. Cursor on SAVE button.

All fields are clear.10 CLICK on CLEAR button.

Cursor on Patient Name field.


Form Test WorksheetCursor Movement & Navigation


Section D. VISUAL PROPERTIES CHECKLIST

#FAILURES in TestRun

Case

#

Expected Result (Observed) 1 2 3 4 51 Each link brings up the correct Web page.

2 Form/page has a unique title that serves as effective web page bookmark.

3 Each Link on form has descriptive name.

4 Background color does not interfere with text readability.

5 Form/page is free of spelling errors.

6 Form/page is free of grammatical errors.

7 Field labels and data align in tabular form.

8 Form/page has consistent look and feel as other forms/pages in system.


Visual Properties Checklist


Form Testing -- Set Up

• Isolated Testing• Form visual attributes• Individual field testing -- validation

• Integrated Testing• Form connected to other forms for

navigation• Buttons connected to underlying code• Database connected


Form Testing -- Results

• Perform tests specified on Checklists and Worksheets created during design, and record results

• Form test checklist • visuals • cursor movement • navigation

• Form test worksheet • field test section*• buttons test section

------------* Generic based on field type.


Form Testing Worksheets

• Stored in Domino• Master template• Separate templates for each form element

• Construct Worksheet by including templates for form elements

• Preview Worksheets


Form Testing -- Summary

Form testing is a bottom-up process involving testing of visual properties, cursor movement, data entry and display, and actions triggered by buttons. Certain properties can be tested immediately; others require varying degrees of system integration.


Testing Classes -- Drivers(Black-Box)

ClassTest

Driver Method Args/Results

Test setData

Test Set Results

Class

Class-state

Method(s)


Example -- Stack Class

class Stack{ public: Stack(); void push(int n); int pop(); int top(); bool empty(); private: int Size; int Top; int Values[100];};

Notes:

(1) Class state -- variables Size, Top and the first 'Size' values in array Values.(2) Methods push and pop modify class state; top and empty inquire about the state.(3) Stack does not require any test environment of its own.(4) Class state HIDDEN from test, i.e., black box.


Test Driver Files (Stack class)

Test Data File (tdi-stack.txt)File content:----- 1 8 1 7 3 7 2 7 2 8 4 true------Note: No test environment setup.Methods: 1-push, 2-pop, 3-top, 4-empty

Test Results File (trs-stack.txt)File content:-----1 1 8 2 1 73 3 7 84 2 7 85 2 8 76 4 1------Note: Results file must be inspected for pass/fails.

--- Top should be 7.

--- Push .

--- Pop, should be 8.--- Stack should be empty.

FailFailFailPass


Class Test Driver Design

Driver dCuses class C{ c = new (C); testcase_no = 0; open tdi_file("tdi_stack.txt"); open trs_file("trs_stack.txt"); while (more data in tdi_file) { op = read(tdi_file); switch (op) {

case 1: //Push. read(tdi_file, value); c.push(value); write(trs_file, testcase_no, 1, value); break;

case 2: //Pop. read(tdi_file, expect); value = c.pop(); write(trs_file, testcase_no, 2, expect, value); break;



… default:

} //switch

}//while

close tdi_file, trs_file;

}//class-driver

case 3: //Top. read(tdi_file, expect); value = c.top(); write(trs_file, testcase_no, 3, expect, value); break;

case 4: //Empty. read(tdi_file, expect); value = c.empty(); write(trs_file, testcase_no, 4, expect, value); break;


Implementing Class Test Drivers

• Interactive vs Batch (files) • Extend Unit Driver

– switch to handle multiple methods– Method-specific test cases– Method interactions tested– All results stored in common results file

• Major Benefits -- comprehensive driver– Automated, repeatable, documented– Minimized set-up


Class Test Driver -- Summary

• Data Driven -- flexible, extensible

• Varying levels of detail– black-box (method calls, no class state)

– clear-box (class state, advanced topic)

– global effects (test environment)

• A driver is a reusable pattern for testing.




INPUT FIELD NAME: Patient Name FIELD CONTROL TYPE: Text Box DATA TYPE: Text



1 Wrong data type 123, Jones “Bad data type”

2 OUT: min length <null string> “Missing data”

3 OUT: max length A, Bcdefghijklmnopqrstuv “Too much data”

4 Bad Format Jordan Michael “Bad format”

5 Legal Value McEnroe, John Accept

6 AT: min value A, A Accept

7 AT: max value Z…Z[17], Z Accept



Name Field Test Worksheet


Weight Field Test Worksheet

INPUT FIELD NAME: Patient Weight CONTROL TYPE: Text Box DATATYPE: integer



1 Wrong data type 2#4 “Bad data type”

2 OUT: min length <null string> “Missing data”

3 OUT: max length 0085 “Too long”

4 Bad Format 8.5 “Bad format”

5 Illegal Value -11 “Illegal value”

6 Legal Value 185 Accept

7 AT: min value 1 Accept

8 OUT: min value 0 “Illegal value”

9 AT: max value 900 Accept

10 OUT: max value 901 “Illegal value”

11 Wrong Default Observation UNEXPECTEDTotal Failures for Test Run


Age Field Test WorksheetList Box



INPUT FIELD NAME: Patient Age FIELD CONTROL TYPE: List Box DATA TYPE: N/A



1 Default value Tab thru field [13-65] accepted

2 Default value Click on default [13-65] [13-65] accepted

3 First value [12-under] [12-under] accepted

4 Interior value [13-65] [13-65] accepted

5 Last value [over 80] [over 80] accepted.




Your Turn -- Testing the CalculateDosage Button






Your Turn -- CalculateDosage Button Black-Box Schematic


CALCULATEDOSAGE

Button

ArgumentArgument

Inputs

GlobalsGlobals

DatabaseDatabase

ExceptionException

ArgumentArgument

Outputs

GlobalsGlobals

DatabaseDatabase

ExceptionException

Age, Weight ErrorMsg?Dosage field


Your Turn -- CalculateDosage Button -- Questions

• Preconditions?• Form fields are valid

• Initial value of Dosage field (e.g., blank)?

• Postconditions?• Dosage field computed

• No other fields updated

• Cursor position

• Dosage blank if error


• Form field data not valid

• Unable to calculate (Dosage field value: blank or ZERO?)


Your Turn -- CalculateDosage Button Decision Table

c1: Weight = blank | Y N N

c2: Valid Weight | - N Y*

c3: Valid Weight | - N Y*a1: Dosage = calculated #pills | X*

a2: Dosage field = blank | X X

a3: Error msg = "can't compute" | X X

a4: Cursor at Dosage field | X

a5: Cursor at Weight field | X

*NOTE: This table deals with the activation of the button in terms of visible form elements (input/output fields and error messages). Detailed rules for calculating the value were treated in Unit Testing Concepts session.


Your Turn -- CalculateDosage Button Test Cases

NOTE: These cases begin with form-level error handling for the CalculateDosage button, and contains functional test cases from the Concepts session.

Case Test Data/Actions Expected Response

1

2

3

4

Enter Name = "Doe, Joe"Enter Default AgeTab through BLANK Weight field

Enter Name = "Doe, Joe"Enter Default AgeEnter Weight = 925

Enter Name = "Test, Joe"Enter Age from functional test setEnter Weight from functional test set

… Remaining functional test cases …

1." Invalid Weight" message2. Dosage = blank3. Cursor at Weight

1." Missing Weight" message2. Dosage = blank3. Cursor at Weight

1. Dosage = computed value (from test case)2. Cursor at Dosage


Section B. ACTION BUTTON UNIT TEST WORKSHEET

ACTION BUTTON NAME: Calculate Dosage


# Test Condition Test Case Data/Action(left click

CALCULATE DOSAGE)

Expected Result 1 2 3 4 5

1 Form Error: NoWeightentered.

Enter Default AgeTab through blankWeight field.

1. Missing-Weight msg2. Dosage = blank3. Cursor at Weight

2 Form Error:Invalid Weight.

Weight = 925 1. Invalid-Weight msg2. Dosage = blank3. Cursor at Weight

3 Functional test(from decisiontable)

Name = ”Test, Joe”(throughout)Age = [12-under]Weight = 40

1. Dosage = 12. Cursor at Dosage.

4 “ “ Age = [12-under]Weight = 305

1. Dosage = 02. Cursor at Dosage.

Action Button Test Worksheet


Example -- Stack Class

class Stack{ public: Stack(); void push(int n); int pop(); int top(); bool empty(); void SetState(int,int,int[]); void GetState(int &,int &,int[]); private: int Size; int Top; int Values[100];};

Notes:

(1) Class state -- variables Size, Top and the first 'Size' values in array Values.(2) Methods push and pop modify class state; top and empty inquire about the state.(3) "Hooks" can be created to set and retrieve the class state.(4) Stack does not require any test environment of its own.



Driver dCuses Test_Env T;uses class C{ // Set up external environment // c = new (C); testcase_no = 0; open tdi_file (filename); open trs_file (filename)

case -4: //Set test env// read(tdi_file. t_env); T.setenv(t_env); break;case -3: //Get test env// T.getenv(t_env); write(trs_file, t_env); break;case -2: //Set class state// read(tdi_file, c_state); c.setstate(c_state); break;



// If the internal state of the class // must be set or checked, a (-2) // precedes case "m", and a (-1) // follows case "m".

// Remaining methods … // default: } //switch }//while close tdi_file, trs_file; }//driver

case -1: //Get class state. c.getstate(c_state); write(trs_file, c_state); break;

case m: // test class method #m. read(tdi_file, args); read(tdi_file, expect); result = method(args); write (trs_file, testcase_no++, args, expect, result); break;

Documents

CIS 4932 Special Topics Software Testing Fall 2001 Practice -- Testing Forms © 2001, Dr. E.L. Jones