Software testing techniques
Download
1 / 146

lecture - PowerPoint PPT Presentation


  • 151 Views
  • Uploaded on

lecture 7 of cmsc420

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'lecture' - guest17101


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Software testing techniques2 l.jpg
Software testing techniques

  • Software must be tested to uncover as many errors as possible through a series of test cases.

  • How to design test cases?


Software testing techniques3 l.jpg
Software testing techniques

  • Software testing techniques provide systematic guidance for designing tests that

    • Exercise the internal logic and interfaces of every software component

    • Exercise the input and output domains of the program to uncover errors in program function, behavior, and performance


Test case design l.jpg
Test Case Design

"Bugs lurk in corners

and congregate at

boundaries ..."

OBJECTIVE

to uncover errors

CRITERIA

in a complete manner

CONSTRAINT

with a minimum of effort and time


Software testing l.jpg
Software Testing

black-box

methods

white-box

methods

Methods

Strategies


Black box testing l.jpg
Black-Box Testing

requirements

1. Incorrect or missing function

2. Interface error

3. External data base access

4. Behavior or performance error

5. Initialization and termination errors

output

input


Black box testing7 l.jpg
Black-Box Testing

  • Can be applied at all levels of system development

  • Procedures

    • Analyze the requirements or specifications

    • Determine inputs

      • Valid input: software under test (SUT) processes the input correctly

      • Invalid input: SUT detects them and handles them properly

    • Expected outputs for those inputs are determined

    • Construct the test, and execute the test

    • Actual outputs are compared with the expected outputs


Black box testing techniques l.jpg
Black box testing techniques

  • Equivalence class testing

  • Boundary value testing

  • Decision table testing

  • Use case testing


Example l.jpg
Example

ages

Hire

Hire status


Example10 l.jpg
Example

  • A human resources system processes employment applications based on a person’s age. The rules are

    • 0-16 do not hire

    • 16-18 can hire on a part-time basis only

    • 18-75 can hire as a full-time employee

    • 75-99 do not hire


Example cont l.jpg
Example (cont.)

If (applicantage >=0 && applicationage <16)

HireStatus = “NO”

If (applicantage >=16 && applicationage <18)

HireStatus = “PART”

If (applicantage >=18 && applicationage <75)

HireStatus = “FULL”

If (applicantage >=75 && applicationage <=99)

HireStatus = “NO”


Equivalence class testing l.jpg
Equivalence class testing

  • Divides the input domain of a program into classes of data. Then identify the valid or invalid states for input conditions

    • The input domain is usually too large for exhaustive testing.

    • It is therefore partitioned into a finite number of sub-domains for the selection of test inputs.

    • Each sub-domain is known as an equivalence class and serves as a source of at least one test input.


Example cont13 l.jpg

Input domain

2

1

3

4

Example (cont.)

Input domain

partitioned into four

classes.

15

17

37

82

Four test inputs, one

selected from each class.

Too many test inputs.

(100 inputs) 0-99


Equivalence class testing14 l.jpg
Equivalence class testing

  • Any data value in a class is equivalent

    • if one test input in an equivalence class can detect a defect, all other test cases in the same equivalence class are likely to detect the same defect.

    • If one test input in an equivalence class does not detect a defect, no other test cases in the same equivalence class is likely to detect the defect


Testing invalid input l.jpg
Testing invalid input?

  • Test 100, 106?

  • Based on the design

    • Design-by-contract -> testing-by-contract

    • Defensive design -> defensive testing


Testing by contract l.jpg
Testing-by-contract

  • Its approach is to create test cases only for the situations in which the pre-conditions are met.

  • Openfile module

    • File must exist

    • Has the name of the file

    • File must be openable

    • Has the access rights to the file….


Defensive testing l.jpg
Defensive testing

  • An approach that tests under both normal and abnormal preconditions

    • If the normal preconditions are met, test if the module achieve its normal postcondition

    • If the pre-conditions are not met, test if the modules notify the caller by returning an error code or throwing an exception correctly


Example hire l.jpg
Example - hire

  • Invalid inputs like -42, FRED, &*#?

  • Testing-by-contract

    • The answer is NO

  • Defensive testing

    • The answer is YES


Example19 l.jpg
Example

ages

Function Hire

  • If (applicantage >=0 && applicationage <16)

    • HireStatus = “NO”

  • If (applicantage >=16 && applicationage <18)

    • HireStatus = “PART”

  • If (applicantage >=18 && applicationage <75)

    • HireStatus = “FULL”

  • If (applicantage >=75 && applicationage <=99)

    • HireStatus = “NO”

  • if (age == 96 )

  • HireStatus = “FULL” strange statement

Hire status


How to partition l.jpg
How to partition?

  • Inputs to a program provide clues to partitioning.

  • Example 1:

    • Suppose that program P takes an input X, X being an integer.

    • For X<0 the program is required to perform task T1 and for X>=0 task T2.


How to partition continued l.jpg
How to partition?-continued

  • The input domain is prohibitively large because X can assume a large number of values.

  • However, we expect P to behave the same way for all X<0.

  • Similarly, we expect P to perform the same way for all values of X>=0.

  • We therefore partition the input domain of P into two sub-domains.


Two sub domains l.jpg

One test case:

X=-3

Equivalence class

X<0

X>=0

Equivalence class

Another test case:

X=15

Two sub-domains

All test inputs in the X<0 sub-domain are considered equivalent.

All test inputs in the X>=0 sub-domain are considered equivalent.


Exercise l.jpg
Exercise

years

Less than 1 year, 5 days

1 – 5 years, 10 days

5 – 10 years, 15 days,

> = 10 years, 20 days

vacation

days


Example24 l.jpg
Example

  • Goofy Mortgage Company (GMC)

    • Income: writes mortgages incomes between $1,000/month and $80,000/month

    • Number of dwellings: Write a single mortgage for one through five houses

    • Applicant: Make mortgages only for a person

    • Dwelling types: Make mortgages on Condominisums, Townhouses, and Single


Write mortgage l.jpg
Write mortgage

Income

Number of dwelling

Applicant

Dwelling types

Mortgage Qualification

Qualified or unqualified


Example cont first input l.jpg
Example (cont.) – first input

  • Income: is a continuous range of value

    • One class of qualified values and two classes of unqualified values

Qualified (valid)

Three test inputs:

$500

$1,500

$90,000

$80,000

$1,000

Unqualified (invalid)


Example cont second input l.jpg
Example (cont.) – second input

  • Number of dwellings: is a discrete values within a range of permissible values

    • One qualified class and two unqualified classes

Three test inputs:

2

8

0

Qualified

0

5

1

2

3

6

4

Unqualified


Example cont third input l.jpg
Example (cont.) – third input

  • applicant: a single qualified value

  • One qualified and one unqualified classes

Corporation

Partnership

Person

two test inputs:

Person

Corporation

Qualified

Unqualified


Example cont fourth input l.jpg
Example (cont.) – fourth input

  • Dwelling types: a set of qualified values

  • One qualified and one unqualified classes

Farm

Mobile Home

….

Single Family

Townhouse

Condo

Two test inputs:

Condo

Farm

qualified

unqualified


Example cont test cases l.jpg
Example (cont.) - Test cases

  • Income: 3

    • 1 qualified (valid), 2 unqualified (invalid)

  • Number of dwelling: 3

    • 1 qualified, 2 unqualified

  • Applicant: 2

    • 1 qualified, 1 unqualified

  • Dwelling types: 2

    • 1 qualified, 1 unqualified


Example cont test cases31 l.jpg
Example (cont.) - Test cases

All inputs are qualified


Example cont test cases32 l.jpg
Example (cont.) - Test cases

All inputs are unqualified

Which field is rejected?


Example cont test cases33 l.jpg
Example (cont.) - Test cases

Only one input is unqualified


Partitioning guidelines l.jpg
Partitioning guidelines

  • Testing by contract? Defense testing?

    • By contract: test valid value

    • Defensive testing: test invalid value

  • Identify the equivalence classes of input or output.

    • By contract: at least one class – valid class

    • Defensive testing:

      • Take at least 2 classes

      • One class that satisfies the condition – valid class

      • Second class that does not satisfy the condition – invalid class

  • Design test cases based on the equivalence classes


Partitioning guidelines35 l.jpg
Partitioning guidelines

  • Testing by contract

  • If an input condition specifies a range,

    • One valid class

  • If an input condition requires a specific value,

    • One valid class

  • If an input condition specifies a member of set,

    • One valid class

  • If an input condition is Boolean,

    • One valid class


Partitioning guidelines36 l.jpg
Partitioning guidelines

  • Defensive testing

  • If an input condition specifies a range,

    • Three equivalence classes are defined

      • One valid class, two invalid classes

  • If an input condition requires a specific value,

    • Two equivalence classes

      • One valid class, one invalid class

  • If an input condition specifies a member of set,

    • Two equivalence classes are defined

      • One valid class, one invalid class

  • If an input condition is Boolean,

    • Two equivalence classes are defined

      • One valid class, one invalid class


Exercise37 l.jpg
Exercise

  • In a computer store, the computer item can have a quantity between -500 to +500. What are the equivalence classes?


Exercise38 l.jpg
Exercise

  • In a computer store, the computer item type can be P2, P3, P4 and P5 (each type influences the price ) What are the equivalence classes?


Exercise39 l.jpg
Exercise

  • Bank account can be 500 to 1000, or 0 to 4999, or 2000 (integer). What are the equivalence classes?


Exercise40 l.jpg
Exercise

  • Suppose that program P takes one character X and one string Y as inputs.

    • For character X: P performs task T1 for all lower case characters and T2 for upper case characters.

    • For string Y: P performs task T3 for the null string and T4 for all other strings.

    • Let us consider testing by contract


Exercise41 l.jpg
Exercise

  • We can select only 2 test inputs to cover all four equivalence classes. These are:

    • X: lower case, Y: null string

    • X: upper case, Y: not a null string

  • Or we can select 4 test inputs to cover all the combinations

  • How many should we have?

    • Will answer it later


Exercise42 l.jpg
Exercise

  • Payroll office uses the following rules to calculate the monthly net income (testing by contract)

    • Income

      • If the gross income is less than $3000, federal tax bracket is 15%

      • If the gross income is grater than or equal to $3000, and less than $5000, federal tax bracket is 20%

      • Otherwise, federal tax bracket is 25%

    • Status (F or T):

      • The full-time employees pay 8% to the retirement account.

      • The temporary employees pay 0% to the retirement account.


Exercise consider invalid input l.jpg
Exercise – consider invalid input

  • Payroll office uses the following rules to calculate the monthly salary

    • Income: should be greater than or equal to $500, and less than or equal to $20,000

      • If gross income is less than $3000, federal tax is 15%

      • If gross income is between $3000 and $5000, federal tax is 20%

      • Otherwise, federal tax is 25%

    • Status: should be F or T. Display error message if user gives wrong status

      • The full-time employees pay 8% to the retirement account.

      • The temporary employees pay 0% to the retirement account.


Non overlapping partitions l.jpg
Non-overlapping partitions

  • An equivalence class is considered covered when at least one test has been selected from it.

  • In the previous example, the two equivalence classes are non-overlapping. In other words the two sub-domains are disjoint.


Example45 l.jpg
Example

  • Suppose that program P takes three integers X, Y and Z. It is known that:

    • X<Y  T1, otherwise T2

    • Z>Y  T3, otherwise T4


Example cont46 l.jpg

X<Y, Z<=Y

X=4, Y=7, Z=1

X>=Y, Z<=Y

X=4, Y=2, Z=1

X<Y

X<Y, Z>Y

X=1, Y=7, Z=9

X>=Y

Z>Y

Z<=Y

X>=Y, Z>Y

X=4, Y=2, Z=9

Example (cont.)


Example cont47 l.jpg
Example (cont.)

  • In this example, we could select 4 test cases as:

    • X=4, Y=7, Z=1 satisfies X<Y

    • X=4, Y=2, Z=9 satisfies X>=Y

    • X=1, Y=7, Z=9 satisfies Z>Y

    • X=1, Y=7, Z=2 satisfies Z<=Y

  • Thus, we have one test case from each equivalence class combination.


Example cont48 l.jpg
Example (cont.)

  • Can we reduce it to 2 test inputs and satisfy all four equivalence classes?

    • X=4, Y=7, Z=1 satisfies X<Y and Z<=Y

    • X=4, Y=2, Z=9 satisfies X>=Y and Z>Y


Weak normal equivalence testing l.jpg
Weak Normal Equivalence testing

  • Assumes the ‘single fault’ or “independence of input variables.”

    • e.g. If there are 2 input variables, these input variables are independent of each other.

  • Partition the test cases of each input variable separately into different equivalent classes.

  • Choose the test case from each of the equivalence classes for each input variable independently of the other input variable


Example of weak normal equivalence testing l.jpg
Example of : Weak Normal Equivalence testing

Assume the equivalence partitioning of input X is: 1 to 10; 11 to 20, 21 to 30

and the equivalence partitioning of input Y is: 1 to 5; 6 to 10; 11 to 15; and 16 to 20

We have covered everyone

of the 3 equivalence classes

for input X.

X

30

For ( x, y )

we have:

(24, 2)

(15, 8 )

( 4, 13)

(23, 17)

20

10

1

Y

1

5

10

15

20

General rule for # of test cases?

What do you think?

# of partitions of the largest set?

We have covered each of the 4 equivalence classes for input Y.


Strong normal equivalence testing l.jpg
Strong Normal Equivalence testing

  • This is the same as the weak normal equivalence testing except for

    “multiple fault assumption”

    or

    “dependence among the inputs”

  • All the combinations of equivalence classes of the variables must be included.


Example of strong normal equivalence testing l.jpg
Example of : Strong Normal Equivalence testing

Assume the equivalence partitioning of input X is: 1 to 10; 11 to 20, 21 to 30

and the equivalence partitioning of input Y is: 1 to 5; 6 to 10; 11 to15; and 16 to 20

X

30

We have covered everyone

of the 3 x 4 Cartesian product of equivalence

classes

20

10

1

Y

1

5

10

15

20

General rule for # of test cases?

What do you think?


Weak robust equivalence testing l.jpg
Weak Robust Equivalence testing

  • Up to now we have only considered partitioning the valid input space.

  • “Weak robust” is similar to “weak normal” equivalence test except that the invalid input variables are now considered.

A note about considering invalid input is that there may not

be any definition “specified” for the various, different invalid

inputs - - - making definition of the output for these invalid

inputs a bit difficult at times. (but fertile ground for testing)


Example of weak robust equivalence testing l.jpg
Example of : Weak Robust Equivalence testing

Assume the equivalence partitioning of input X is 1 to 10; 11 to 20, 21 to 30

and the equivalence partitioning of input Y is 1 to 5; 6 to 10; 11 to 15; and 16 to 20

X

30

We have covered everyone of the 5 equivalence classes for input X.

20

10

1

Y

1

5

10

15

20

We have covered each of the 6 equivalence classes for input Y.


Better one weak robust equivalence testing l.jpg
Better one: Weak Robust Equivalence testing

Assume the equivalence partitioning of input X is 1 to 10; 11 to 20, 21 to 30

and the equivalence partitioning of input Y is 1 to 5; 6 to 10; 11 to 15; and 16 to 20

X

30

We have covered everyone of the 5 equivalence classes for input X.

20

10

1

Y

Every time, only one invalid

1

5

10

15

20

We have covered each of the 6 equivalence classes for input Y.


Strong robust equivalence testing l.jpg
Strong Robust Equivalence testing

  • Does not assume “single fault” - - - assumes dependency of input variables

  • “Strong robust” is similar to “strong normal” equivalence test except that the invalid input variables are now considered.


Example of strong robust equivalence testing l.jpg
Example of : Strong Robust Equivalence testing

Assume the equivalence partitioning of input X is: 1 to 10; 11 to 20, 21 to 30

and the equivalence partitioning of input Y is: 1 to 5; 6 to 10; 11 to 15; and 16 to 20

X

30

We have covered everyone

of the 5 x 6 Cartesian product of equivalence

classes (including invalid

inputs)

20

10

1

Y

1

5

10

15

20


Equivalence class testing58 l.jpg
Equivalence class testing

Divide the outputs into equivalence classes

Find out what input values would cause those outputs

Ages

Function Hire

NO

PART

FULL


Exercise59 l.jpg
Exercise

years

  • Less than 1 year, 0-5 days

  • 1 – 5 years, 6-10 days

  • 5 – 10 years, 11-15 days,

  • >= 10 years, 16-20 days

  • Find out the equivalence classes based on the output

vacation

days


Exercise60 l.jpg
Exercise

  • The airport parking office based on the type of parking lot, and hours to determine the rate

  • Testing by contract


Sufficiency of partitions l.jpg
Sufficiency of partitions

  • In the previous examples we derived equivalence classes based on the conditions satisfied by the input or output data.

  • Then we selected just enough tests to cover each partition.

  • Think of the advantages and disadvantages of this approach!


Boundary value analysis bva l.jpg
Boundary value analysis (BVA)

  • Errors occur at the boundaries of the input domain rather than in the center

  • Rather than selecting any element of an equivalence class, testing at the edge of the class

  • Suited to systems in which the input data takes on values within ranges


Example63 l.jpg
Example

ages

Hire

  • If (applicantage >=0 && applicationage <16)

    • HireStatus = “NO”

  • If (applicantage >=16 && applicationage <18)

    • HireStatus = “PART”

  • If (applicantage >=18 && applicationage <75)

    • HireStatus = “FULL”

  • If (applicantage >=75 && applicationage <=99)

    • HireStatus = “NO”

Hire status


Example cont boundary l.jpg
Example (cont.) – boundary

18

99

16

0

75

boundary


Technique l.jpg
Technique

  • Identify the equivalence classes

  • Identify the boundaries of each equivalence class

  • Create test cases

    • One point on the boundary

    • One point just below the boundary

    • One point just above the boundary


Example cont66 l.jpg
Example (cont.)

  • {-1,0,1} {15,16,17} {17,18,19} {74,75,76}

    {98,99,100}

18

99

16

0

75

boundary


Bva continued l.jpg

14

5

2

1

y2

10

11

6

9

8

13

12

y1

3

4

7

x1

x2

BVA: continued

  • Now suppose that a program takes two integers X and Y and that x1<=X<=x2 and y1<=Y<=y2.

    In this case the four sides of the rectangle represent the boundary.

    The heuristic for test selection in this case is:

    Select one test at each corner (1, 2, 3, 4).


Bva continued68 l.jpg
BVA-continued

Select one test just outside of each of the four sides of the boundary (5, 6, 7, 8)

Select one test just inside of each of the four sides of the boundary (10, 11, 12, 13).

Select one test case inside of the bounded region (9).

Select one test case outside of the bounded region (14).

How many equivalence classes do we get?


Exercise69 l.jpg
Exercise

  • GMC

    • Valid income $1000 to $80,000

    • Valid number of dwelling: 1 to 5

    • Applicant: Make mortgages only for a person

    • Dwelling types: Make mortgages on Condominisums, Townhouses, and Single


Bva testing discount l.jpg
BVA testing - Discount

Order charge

<$100, no discount

>=$100 and <$500, 10% discount

>=$500, 15% discount

Final charge


Bva applied to output variables l.jpg
BVA applied to output variables

Just as we applied BVA to input data, we can apply it to output data.

Doing so gives us equivalence classes for the output domain.

We then try to find test inputs that will cover each boundary.


Bva output testing l.jpg
BVA output testing

Order charge

10% discount

Discount

discount <= $100



Decision table testing74 l.jpg
Decision table testing

Marriage

History

Insurance discount

Discount


Decision table testing75 l.jpg
Decision table testing

Suited to complex business rules


Decision table testing76 l.jpg
Decision table testing

Each rule becomes a test case




Exercise79 l.jpg
Exercise

  • OrderCharge: This component is used to calculate the charge of the order based on the customer type and the special discount

  • Based on the customer type

    No discount for “regular” customers

    8% discount for “silver” customers

    15% discount for “gold” customers

  • If we have special discount:

    • 10% discount applies to all customers





Exercise83 l.jpg
Exercise

  • Suppose you want to buy some funds, if all the following conditions are valid

    • Symbol

    • Quantity

    • Sufficient money in your account

      Then you can buy the funds

      Build the decision table, and the test cases.


Exercise84 l.jpg
Exercise

  • The airport parking office based on the type of parking lot, and time (hours) to determine the rate

  • Testing by contract


Use case testing l.jpg
Use case testing

  • Based on the use cases

  • Use case: a scenario that describes the use of a system by an actor to accomplish a specific goal

  • The set of use cases makes up the functional requirements of a system



Example87 l.jpg
Example

  • VCU registration system

    • A student wants to register for a course




Example cont90 l.jpg
Example (cont)

  • Create at least one test case for the main success scenario

  • at least one test case for each exception


Exercise91 l.jpg
Exercise

  • Withdraw money from ATM machine


Exercise place order l.jpg
Exercise – Place order

  • Normal flow:

    • The user will indicate that she wants to order the items that have already been selected.

    • The system will present the billing and shipping information that the user previously stored.

    • The user will confirm that the existing billing and shipping information should be used for this order.

    • The system will present the amount that the order will cost, including applicable taxes and shipping charges.

    • The user will confirm that the order information is accurate.

    • The system will provide the user with a tracking ID for the order.


Exercise place order93 l.jpg
Exercise – Place order

  • Alternative flow:

  • 3A: The user enters billing and shipping information for the order. The user desires to use shipping and billing information that differs from the information stored in her account. This alternate flow also applies if the user does not maintain billing and / or shipping information in their account, or if the user does not have an account.

    • The user will indicate that this order should use alternate billing or shipping information.

    • The user will enter billing and shipping information for this order.

    • The system will validate the billing and shipping information.

    • The use case continues


Exercise place order94 l.jpg
Exercise – Place order

  • Alternative flow:

  • 5A: The user will discover an error in the billing or shipping information associated with their account, and will change it.

    • The user will indicate that the billing and shipping information is incorrect.

    • The user will edit the billing and shipping information associated with their account.

    • The system will validate the billing and shipping information.

    • The use case returns to step 2 and continues.

  • 5B: The user will discover an error in the billing or shipping information that is uniquely being used for this order, and will change it.

    • The user will indicate that the billing and shipping information is incorrect.

    • The user will edit the billing and shipping information for this order.

    • The use case returns to step 3A step 3.


White box testing l.jpg
White- box testing

  • Based on the internal paths, structures, and implementation of software under test (SUT)

  • Require detailed programming skills


White box testing96 l.jpg
White- box testing

  • General process:

    • Analyze the SUT’s implementation

    • Paths through the SUT are identified

    • Inputs are chosen to cause the SUT to execute selected paths. Expected results are determined

    • Run tests

    • Actual outputs are compared with expected outputs


Disadvantages vs advantages l.jpg
Disadvantages vs. advantages

  • Disadvantages:

    • The number of execution paths may be large

    • The tester must have the programming skills to understand and evaluate the SUT. Unfortunately, many testers today do not have this background.

  • Advantages:

    • Every path through the software under test has been identified and tested.


Oot methods partition testing l.jpg
OOT Methods: Partition Testing

  • Partition Testing

    • reduces the number of test cases required to test a class in much the same way as equivalence partitioning for conventional software

    • state-based partitioning

      • categorize and test operations based on their ability to change the state of a class

    • attribute-based partitioning

      • categorize and test operations based on the attributes that they use

    • category-based partitioning

      • categorize and test operations based on the generic function each performs


State transition testing l.jpg
State – transition testing

  • Based on the state transition diagram

    • State: a condition in which a system is waiting for one or more events

    • Transition: represents a change from one state to another caused by event

    • Event: causes the system to change state

    • Actions: an operation initiated because of a state change


Intraclass state machine testing l.jpg
Intraclass State Machine Testing

Basic idea:

The state of an object is modified by operations

Methods can be modeled as state transitions

Test cases are sequences of method calls that traverse the state machine model

15.4/5


Informal state full specifications l.jpg
Informal state-full specifications

Slot: represents a slot of a computer model.

.... slots can be bound or unbound. Bound slots are assigned a compatible component, unbound slots are empty. Class slot offers the following services:

Incorporate: slots can be installed on a model as required or optional....

Bind: slots can be bound to a compatible component....

Unbind: bound slots can be unbound by removing the bound component.

IsBound: returns the current binding, if bound; otherwise returns the special value empty.


Identifying states and transitions l.jpg
Identifying states and transitions

From the informal specification we can identify three states:

Not_present

Unbound

Bound

and four transitions

incorporate: from Not_presentto Unbound

bind: from Unbound to Bound

unbind: ...to Unbound

isBound: does not change state


Deriving an fsm and test cases l.jpg
Deriving an FSM and test cases

TC-1: incorporate, bind

TC-2: incorporate, unBind, bind,

TC-3: incorporate, isBind, bind, isBound, unBind


Example 1 l.jpg
Example (1)

  • Airline reservation

Paid

Made

StartPayTimer

Pay

money

print

Ticketed

give

Info

cancel

cancel

cancel

expires

giveticket

Used

Cancelled by customer

Refund

Cancelled Nonpay


Example 2 l.jpg
Example (2)

  • Create a set of test cases such that

    • All states are visited at least once

    • All events are triggered at least once

    • All transitions are exercised at least once under test


Example 3 l.jpg
Example (3)

  • All states are visited at least once

Paid

Made

StartPayTimer

Pay

money

print

Ticketed

give

Info

cancel

cancel

cancel

expires

giveticket

Used

Cancelled by customer

Refund

Cancelled Nonpay


Example 4 l.jpg
Example (4)

  • All events are triggered at least once

Paid

Made

StartPayTimer

Pay

money

print

Ticketed

give

Info

cancel

cancel

cancel

expires

giveticket

Used

Cancelled by customer

Refund

Cancelled Nonpay


Example 5 l.jpg
Example (5)

  • All transition are triggered at least once

Paid

Made

StartPayTimer

Pay

money

print

Ticketed

give

Info

cancel

cancel

cancel

expires

giveticket

Used

Cancelled by customer

Refund

Cancelled Nonpay


Oot methods intra class level l.jpg
OOT Methods –intraclasslevel

Class Account{

balance;

creditLimit;

……

Open()

Setup()

Deposit()

Withdraw()

Balance()

Summarize()

Creditlimit()

Close()

}



Oot methods state based partitioning l.jpg
OOT Methods: state-based partitioning

  • Divide the operations into state operations and nonstate operations

  • Design tests exercises operations that change state and those do not change state separately.

  • Example

    • Account class

      • open(), setup(), deposit(), withdraw(), balance(), summarize(), creditlimit(), close(),

      • P1: open-setup-deposit-withdraw-close

      • P2: open-setup-deposit-deposit-withdraw-close

      • P3: open-setup-deposit-withdraw-withdraw-close

      • P4: open-setup-deposit-balance-withdraw-close

      • P5: open-setup-deposit-summarize-withdraw-close

      • P6: open-setup-deposit-creditlimit-balance-withdraw-close




Inspectors and modifiers l.jpg
Inspectors and modifiers

Classify methods (execution paths) as

inspectors: use, but do not modify, instance variables

modifiers: modify, but not use instance variables

inspector/modifiers: use and modify instance variables

others: do not use or modify instance variables


Deriving an fsm and test cases115 l.jpg
Deriving an FSM and test cases

Example – class slot:

Slot() modifier

Incorporate () modifier

bind() modifier

unbind() modifier

isbound() inspector


Oot methods attribute based partitioning l.jpg
OOT Methods: attribute-based partitioning

  • Categorizes class operations based on the attributes that they use

  • Design tests

    • Operations that use attributes

    • Operations that modify attributes

    • Operations that do not use or modify attributes

  • Example

    • Account class

      • open(), setup(), deposit(), withdraw(), balance(), summarize(), creditlimit(), close(),

      • Attribute balance

      • Inspector: balance(), summarize()

      • Modifier: deposit(), withdraw()

      • Others: open(), setup(), creditlimit(), close()


Oot methods category based partitioning l.jpg
OOT Methods: category-based partitioning

  • Categorize class operations based on the generic function that each perform

  • Example

    • Account class

      • open(), setup(), deposit(), withdraw(), balance(),summarize(),creditlimit(),close(),

    • Initialization: open, setup

    • Computational: deposit, withdraw

    • Queries: balance, summaries, creditlimit

    • Termination:close


Oot testing methods l.jpg
OOT—Testing Methods

  • Test cases and class hierarchy

    Class Base{

    Inherited()

    Redefined()

    }

    Class Derived : public Base

    {

    Redefined() ?? Test it or not?

    Inherited() ??Test it or not?

    }


Control flow testing l.jpg
Control flow testing

  • Identify the execution paths through a module of program code and then creates and executes test cases to cover those paths


Control flow testing120 l.jpg
Control flow testing

... our goal is to ensure that all

statements and conditions have

been executed at least once ...

120


Control flow testing121 l.jpg

1

2

3

4

5

6

7

8

Control flow testing

  • Flow chart

121


Control flow graph l.jpg
Control flow graph

  • Process blocks: sequence of program statements

  • Decision point: at which the control flow can change

  • Junction point: control flows join together


Levels of coverage l.jpg
Levels of coverage

  • Level 1: 100% statement coverage

    if (a>0) {x = x+1;}

    if (b==3) {y = 0;}

    a=1,b=3


Levels of coverage124 l.jpg
Levels of coverage

  • Level 2: 100% decision coverage

    if (a>0) {x = x+1;}

    if (b==3) {y = 0;}

    Test each decision: true and false

    if (a>0 && c==1) {x = x+1;}

    if (b==3|| d<0) {y = 0;}


Levels of coverage125 l.jpg
Levels of coverage

  • Level 3: 100% condition coverage

    if (x && y) {x = x+1;}

    x= true, y = false

    x = false, y = true


Levels of coverage126 l.jpg
Levels of coverage

  • Level 4: 100% multiple condition coverage

    if (a>0 && c==1) {x = x+1;}

    if (b==3|| d<0) {y = 0;}

    a>0, c=1, b=3, d<0 both decisions true

    a<=0, c=1, b=3, d>=0 both decisions false

    a>0, c ≠ 1, b≠3, d<0

    a<=0, c ≠ 1, b ≠ 3, d>=0


Levels of coverage127 l.jpg
Levels of coverage

  • Level 5: 100% path coverage

    if (a>0) {x = x+1;}

    if (b==3) {y = 0;}

    a=1, b=3

    a=1, b=2

    a =-1, b =3


Why cover l.jpg
Why Cover?

logic errors and incorrect assumptions

are inversely proportional to a path's

execution probability

we often

believe

that a path is not

likely to be executed; in fact, reality is

often counter intuitive

typographical errors are random; it's

likely that untested paths will contain

some

128


White box testing129 l.jpg
White-box testing

  • Design the test case to

    • Guarantee that all independent paths within a module have been exercised at least once

    • Exercise all logical decision on their true and false sides

    • Execute all loops at their boundaries and within their operational bounds

    • Execute internal data structures at least once to ensure their validity

129


Control flow testing basis path testing l.jpg
Control flow testing/ Basis path testing

  • First, we compute the cyclomatic complexity

  • Cyclomatic complexity defines the number of independent paths in the basis set of a program and provides us with an upper bound for the number of test that must be conducted to ensure that all statements have been executed at least once

130


Basis path testing l.jpg
Basis Path Testing

Cyclomatic complexity:

1. number of simple decisions

(predicate nodes) + 1

2. Number of enclosed areas

3. E-N +2 (flow graph)

In this case, V(G) = 4

131


Example132 l.jpg
Example

get number x and y 1

if x> y 2

Display “x > y” 3

else

Display “x < = y” 4

End 5

132


Compound logic l.jpg
Compound logic

  • if (a or b)

    then x

    else y

  • if (a and b)

    then X

    else y

133


Example134 l.jpg
Example

Procedure average:

This procedure computes the average of 100 or fewer numbers that lie between bounding values; it also computes the sum and the total number valid

Interface returns average, total.input, total.valid

Interface accepts value, minimum, maximum

Type value [1:100] is scalar array

Type average, total.input, total.valid,minimum, maximum, sum is scalar

Type i is integer

134


Example135 l.jpg
Example

i=1;

total.input = total.valid =0;

sum =0;

do while value[i]<>-999 and total.input <100

increment total.input by 1;

if value[i] >=minimum and value[i] <=maximum

then increment total.valid by 1;

sum = sum + value[i];

else skip

endif

increment i by 1;

enddo

if total.valid >0

then average = sum/total.valid

else average = -999;

endif

end average

135


Example draw a flow graph l.jpg
Example – draw a flow graph

i=1;

total.input = total.valid =0;

sum =0;

do while value[i]<>-999 and total.input <100

increment total.input by 1;

if value[i] >=minimum and value[i] <=maximum

then increment total.valid by 1;

sum = sum + value[i];

else skip

endif

increment i by 1;

enddo

if total.valid >0

then average = sum/total.valid

else average = -999;

endif

end average

1

3

2

4

6

5

7

8

9

10

11

12

13

14

136


Example draw a flow graph137 l.jpg
Example – draw a flow graph

i=1;

total.input = total.valid =0;

sum =0;

do while value[i]<>-999 and total.input <100

increment total.input by 1;

if value[i] >=minimum and value[i] <=maximum

then increment total.valid by 1;

sum = sum + value[i];

else skip

endif

increment i by 1;

enddo

if total.valid >0

then average = sum/total.valid

else average = -999;

endif

end average

1

2

3

4

6

5

7

8

9

10

11

12

13

137


Example138 l.jpg
Example

  • Determine the cyclomatic complexity of the flow graph

    • 5 predicate nodes +1

    • 17 edges -13 nodes +2

    • 6 regions

138


Basis path testing139 l.jpg

1

2

3

4

5

6

7

8

Basis Path Testing

Next, we derive the

independent paths:

Since V(G) = 4,

T

there are four paths

F

T

F

Path 1: 1,2,3,6,7,8

Path 2: 1,2,3,5,7,8

Path 3: 1,2,4,7,8

Path 4: 1,2,4,7,2,4,7,8

T

Finally, we derive test

F

cases to exercise these

paths.

139


Example140 l.jpg
Example

  • Determine the independent paths

    • Path 1: 1,2,10,11,13

    • Path 2: 1,2,10,12,13

    • Path 3: 1,2,3,10,11,13

    • Path 4: 1,2,3,4,5,6,8,9,2…

    • Path 5: 1,2,3,4,5,6,7,8,9,2….

    • Path 6: 1,2,3,4,5,8,9,2….

  • Prepare test cases that will force execution of each path in the basis set

140


Exercise141 l.jpg
Exercise

Procedure cashback:

This procedure computes the cashback for the Costco members based on their memberships and the credit card used for the purchase.

Interface returns cashback

Interface accepts members, given_number

Type member [1:100] is array. member[i] has four attributes: membership, card,expenditure, cashback

Type i is integer

141


Exercise142 l.jpg
Exercise

sum =0; i =0;

do while i <=given_number

if membership ==‘Gold’ and card == “amex”

then member can get 2% cash back

calculate sum

endif

if membership ==‘Executive’

if Card = =“amex”

then member can get 4% cash back

calculate sum

else

member can get 2% cash back

calculate sum

endif

endif

increment i by 1;

Enddo

142


Exercise143 l.jpg
Exercise

1

sum =0; i =0;

do while i <=given_number

if membership ==‘Gold’ and card == “amex”

then member can get 2% cash back

calculate sum

endif

if membership ==‘Executive’

if Card = =“amex”

then member can get 4% cash back

calculate sum

else

member can get 2% cash back

calculate sum

endif

endif

increment i by 1;

Enddo

2

3

4

5

6

7

8

9

10

143


Loop testing l.jpg
Loop Testing

Simple

loop

Nested

Loops

Concatenated

Loops

Unstructured

Loops

144


Loop testing simple loops l.jpg
Loop Testing: Simple Loops

Minimum conditions—Simple Loops

1. skip the loop entirely

2. only one pass through the loop

3. two passes through the loop

4. m passes through the loop m < n

5. (n-1), and n passes through

the loop

where n is the maximum number

of allowable passes

145


Loop testing nested loops l.jpg
Loop Testing: Nested Loops

Nested Loops

1. Start at the innermost loop. Set all outer loops to their

minimum iteration parameter values.

2. Test the min, min+1, typical, max-1 and max for the

innermost loop, while holding the outer loops at their

minimum values.

3. Move out one loop and set it up as in step 2, holding all

other loops at typical values. Continue this step until

the outermost loop has been tested.

Concatenated Loops

If the loops are independent of one another

then treat each as a simple loop

else* treat as nested loops

endif*

for example, the final loop counter value of loop 1 is

used to initialize loop 2.

146


ad