Black box testing (an introduction to)

44
Università degli Studi dell’Aquila L21: Black Box/Functional Testing Henry Muccini DISIM, University of L’Aquila www.henrymuccini.com , [email protected]

description

An introduction to black box testing, as part of the Advanced Software Engineering course at www.di.univaq.it/muccini/SE+/2012

Transcript of Black box testing (an introduction to)

Page 1: Black box testing (an introduction to)

Università degli Studi dell’Aquila

L21: Black Box/Functional Testing

Henry Muccini

DISIM, University of L’Aquila

www.henrymuccini.com, [email protected]

Page 2: Black box testing (an introduction to)

The material in these slides may be freely reproduced anddistributed, partially or totally, as far as an explicitreference or acknowledge to the material author ispreserved.

Partially based on material from Alex Orso, Mauro Pezze’, and Michal Young.

Page 3: Black box testing (an introduction to)

White box testing

Representative values

Systematic vs Random Testing

Equivalence Partitioning

Category Partition Method

AGENDA

Category Partition Method

Page 4: Black box testing (an introduction to)

Where is the boundary between testing and other

(analysis/verification) methods?

What distinguishes software testing from “other” approaches

is execution. This requires the ability to:

launch the tests on some executable version (traceability problem), → launch the tests on some executable version (traceability problem),

and

→ analyse (observe and evaluate) the results (not granted for embedded

systems)

I am not saying testing is superior and we should disregard other

approaches: on the contrary, testing and other methods

should complement/support each other

Page 5: Black box testing (an introduction to)

Any software test campaign involves a trade-off

between

→ Limiting resource utilization (time, effort)

⇒ as few tests as possible

→ Augmenting our confidence

Augmenting our confidence

⇒ as many tests as possible

Two research challenges:

→ Determining a feasible and meaningful stopping rule

→ Evaluating test effectiveness (reliability, “coverage notion”,

....very tough problem

Page 6: Black box testing (an introduction to)

BLACK BOX/FUNCTIONAL TESTING

Page 7: Black box testing (an introduction to)

Functional testing: Deriving test cases from program

specifications

─ Functional refers to the source of information used in test case

design, not to what is tested

Also known as:

→ specification-based testing (from specifications)

→ black-box testing (no view of the code)

Functional specification = description of intended

program behavior

→ either formal or informal

(C) 2007 MAURO PEZZÈ & MICHAL YOUNG

Page 8: Black box testing (an introduction to)

Exploit some knowledge to choose samples that are more

likely to include “special” or trouble-prone regions of the

input space

→ Failures are sparse in the whole input space ...

→ ... but we may find regions in which they are dense

Desirable case: Each fault leads to failures that are dense

(easy to find) in some class of inputs

→ sampling each class in the quasi-partition selects at least one

input that leads to a failure, revealing the fault

→ seldom guaranteed; we depend on experience-based heuristics

(C) 2007 MAURO PEZZÈ & MICHAL YOUNG

Page 9: Black box testing (an introduction to)

Failure (valuable test case)

No failure

Failures are sparse

in the space of

possible inputs ...

... but dense in some

parts of the space

The s

pace o

f possib

le input

valu

es

(the h

aysta

ck)

(C) 2007 MAURO PEZZÈ & MICHAL YOUNG

If we systematically test some

cases from each part, we will

include the dense parts

Functional testing is one way of

drawing pink lines to isolate

regions with likely failures

The s

pace o

f possib

le input

valu

es

(the h

aysta

ck)

Page 10: Black box testing (an introduction to)

Random (uniform):

→ Pick possible inputs uniformly

→ Avoids designer bias

─ A real problem: The test designer can make the same logical mistakes and bad assumptions as the program designer (especially if they are the same person)logical mistakes and bad assumptions as the program designer (especially if they are the same person)

→ But treats all inputs as equally valuable

(C) 2007 MAURO PEZZÈ & MICHAL YOUNG

Page 11: Black box testing (an introduction to)
Page 12: Black box testing (an introduction to)

Defects are not distributed uniformly!

•  Assume our printSum program fails if both

inputs are 0!

•  Random sampling is unlikely to choose a = 0 •  Random sampling is unlikely to choose a = 0

and b = 0!

We want bias!!

Page 13: Black box testing (an introduction to)

Systematic (non-uniform):

→ Try to select inputs that are especially valuable

→ Usually by choosing representatives of classes that are apt to fail often or not at all

Functional testing is systematic testing

Page 14: Black box testing (an introduction to)
Page 15: Black box testing (an introduction to)

•An independently testable feature (ITF) is a

functionality that can be tested independently of other

functionalities of the software under test.

•It need not correspond to a unit or subsystem of the

software. software.

•For example, a file sorting utility may be capable of

merging two sorted files, and it may be possible to test

the sorting and merging functionalities separately,

even though both features are implemented by much

of the same source code.

Page 16: Black box testing (an introduction to)

It is recommended to devise separate test cases for each functionality of the system, whenever possible.

The design of different tests for different functionalities can simplify the test generation problem

Thus, identifying functional features does not correspond to identifying single modules at the design level, but rather to suitably slicing the specifications to be able to attack their complexity incrementally

Feature-based view of the system

Page 17: Black box testing (an introduction to)
Page 18: Black box testing (an introduction to)

Functional testing uses the specification (formal or

informal) to partition the input space

→ E.g., specification of “roots” program suggests division

between cases with zero, one, and two real rootsbetween cases with zero, one, and two real roots

Test each category, and boundaries between boundaries between

categoriescategories

→ No guarantees, but experience suggests failures often lie at

the boundaries (as in the “roots” program)

(C) 2007 MAURO PEZZÈ & MICHAL YOUNG

Page 19: Black box testing (an introduction to)

•Try to select inputs that are especially valuable!

• Usually by choosing representatives of equivalence classes!

•Assumption: inputs in different categories behave inputs in different categories behave

equivalently equivalently

⇒⇒I can select I can select one input per categoryone input per category⇒⇒I can select I can select one input per categoryone input per category

Page 20: Black box testing (an introduction to)

Consider a software module that is intended to accept the name of a grocery item and a list of the different sizes the item comes in, specified in ounces. The specifications state that the item name is to be alphabetic characters 2 to 15 characters in length. Each size may be a value in the range of 1 to 48, whole numbers only. The sizes are to be entered in ascending order (smaller sizes first). A of 1 to 48, whole numbers only. The sizes are to be entered in ascending order (smaller sizes first). A maximum of five sizes may be entered for each item. The item name is to be entered first, followed by a comma, then followed by a list of sizes. A comma will be used to separate each size. Spaces (blanks) are to be ignored anywhere in the input.

Taken from: http://users.csc.calpoly.edu/~jdalbey/205/Resources/grocerystore.

Page 21: Black box testing (an introduction to)

Consider a software module that is intended to accept the name of a grocery item and a list of the different sizes the item comes in, specified in ounces.

The specifications state that the item name is to be alphabetic characters 2 to 15 characters in length. Each size may be a value in the range of 1 to 48, whole numbers only.

The sizes are to be entered in ascending order (smaller sizes The sizes are to be entered in ascending order (smaller sizes first). A maximum of five sizes may be entered for each item. The item name is to be entered first, followed by a comma, then followed by a list of sizes. A comma will be used to separate each size. Spaces (blanks) are to be ignored anywhere in the input.

Page 22: Black box testing (an introduction to)

Item name is alphabetic (valid)Item name is not alphabetic (invalid)Item name is less than 2 characters in length (invalid)Item name is 2 to 15 characters in length (valid)Item name is greater than 15 characters in length (invalid)Size value is less than 1 (invalid)Size value is in the range 1 to 48 (valid)Size value is greater than 48 (invalid)Size value is a whole number (valid)Size value is a decimal (invalid)Size value is numeric (valid)Size value is numeric (valid)Size value includes nonnumeric characters (invalid)Size values entered in ascending order (valid)Size values entered in nonascending order (invalid)No size values entered (invalid)One to five size values entered (valid)More than five sizes entered (invalid)Item name is first (valid)

Page 23: Black box testing (an introduction to)

# Test DataExpected

OutcomeClasses Covered

1 xy,1 T 1,4,7,9,11,13,16,18,20,22

2 AbcDefghijklmno,1,2,3 ,4,48 T 1,4,7,9,11,13,16,18,20,23

3 a2x,1 F 2

4 A,1 F 3

5 abcdefghijklmnop F 55 abcdefghijklmnop F 5

6 Xy,0 F 6

7 XY,49 F 8

8 Xy,2.5 F 10

9 xy,2,1,3,4,5 F 14

10 Xy F 15

11 XY,1,2,3,4,5,6 F 17

12 1,Xy,2,3,4,5 F 19

13 XY2,3,4,5,6 F 21

14 AB,2#7 F 12

Page 24: Black box testing (an introduction to)
Page 25: Black box testing (an introduction to)

Item name is alphabetic (valid)Item name is not alphabetic (invalid)Item name is less than 2 characters in length (invalid)Item name is 2 to 15 characters in length (valid)Item name is greater than 15 characters in length (invalid)Size value is less than 1 (invalid)Size value is in the range 1 to 48 (valid)Size value is greater than 48 (invalid)Size value is a whole number (valid)Size value is a decimal (invalid)Size value is numeric (valid)Size value is numeric (valid)Size value includes nonnumeric characters (invalid)Size values entered in ascending order (valid)Size values entered in nonascending order (invalid)No size values entered (invalid)One to five size values entered (valid)More than five sizes entered (invalid)Item name is first (valid)

Page 26: Black box testing (an introduction to)

The main idea is to partition the input domain of

function being tested, and then select test data for

each class of the partition.

The problem of all the existing techniques is the lack of The problem of all the existing techniques is the lack of

systematic.

Solution: the Category Partition Method

Page 27: Black box testing (an introduction to)

Steps:

�ITF (Independently testable feature)

�Identify parameters and Environmental conditions

� Parameters: Explicit input to the functional unit

Environmental Conditions: Characteristics of the � Environmental Conditions: Characteristics of the

system’s state

�Find categories that characterize each parameter and

environment condition.

�Every category should be partitioned into distinct choices

�Test Spec

Page 28: Black box testing (an introduction to)

Command: find (a pattern into a file)

Syntax: find <pattern> <file>

Function:Function: The find command is used to locate one or more instance of a given

pattern in a text file. All lines in the file that contain the pattern are written to

standard output. A line containing the pattern is written only once, regardless of the

number of times the pattern occurs in it.

The pattern is any sequence of characters whose length does not exceed the

maximum length of a line in the file .To include a blank in the pattern, the entire

pattern must be enclosed in quotes (“).To include quotation mark in the pattern ,two

quotes in a row (“ “) must be used.

Page 29: Black box testing (an introduction to)

Example:

find john myfile

display lines in the file myfile which contain john

find “john smith” in myfilefind “john smith” in myfile

display lines in the file myfile which contain john smith

find “john”” smith” in myfile

display lines in the file myfile which contain john” smith

Page 30: Black box testing (an introduction to)

Example:

find john myfile

display lines in the file myfile which contain john

find “john smith” in myfile

sizesize

quotequote emb blankemb blank

Parameters (explicit input to the functional unit)

find “john smith” in myfile

display lines in the file myfile which contain john smith

find “john”” smith” in myfile

display lines in the file myfile which contain john” smith

emb quotesemb quotes

Page 31: Black box testing (an introduction to)

Parameters:

Pattern size:

empty

single character

many character

longer than any line in the file

Quoting:Quoting:

pattern is quoted

pattern is not quoted

pattern is improperly quoted

Embedded blanks:

no embedded blank

one embedded blank

several embedded blanks

Page 32: Black box testing (an introduction to)

Embedded quotes:

no embedded quotes

one embedded quotes

several embedded quotes

File name:

good file name

no file with this name

Environments (characteristics of the system’s state):Environments Number of occurrence of pattern in file:

none

exactly one

more than one

Pattern occurrences on target line:

one

more than one

Total Tests frames:

1944

Page 33: Black box testing (an introduction to)

Pattern size : empty

Quoting : pattern is quoted

Embedded blanks : several embedded blanks

Embedded quotes : no embedded quoteEmbedded quotes : no embedded quote

File name : good file name

Number of occurrence of pattern in file : none

Pattern occurrence on target line : one

However, not all combinations of value classes

correspond to reasonable test case specifications!!!

Page 34: Black box testing (an introduction to)

• Properties

– [property A, B, …]

– A and B are property names

– E.g., [property Empty]– E.g., [property Empty]

• Selector expression

– [if A]

– E.g., [if Empty]

Page 35: Black box testing (an introduction to)

Parameters:

Pattern size:

empty [ property Empty ]

single character [ property NonEmpty ]

many character [ property NonEmpty ]

longer than any line in the file [ property NonEmpty ]

Quoting:

pattern is quoted [ property quoted ]

pattern is not quoted [ if NonEmpty ]

pattern is improperly quoted [ if NonEmpty ]

Embedded blanks:

no embedded blank [ if NonEmpty ]

one embedded blank [ if NonEmpty and Quoted ]

several embedded blanks [ if NonEmpty and Quoted ]

Page 36: Black box testing (an introduction to)

Embedded quotes:

no embedded quotes [ if NonEmpty ]

one embedded quotes [ if NonEmpty ]

several embedded quotes [ if NonEmpty ]

File name:

good file name

no file with this name

Environments: Total Tests frames:

678Number of occurrence of pattern in file:

none [ if NonEmpty ]

exactly one [ if NonEmpty ] [ property Match]

more than one [ if NonEmpty ] [ property Match ]

Pattern occurrences on target line:

one [ if Match ]

more than one [ if Match ]

678

Page 37: Black box testing (an introduction to)

The label [error] indicates a value class that need be

tried only once, in combination with non-error values

of other parameters.

Page 38: Black box testing (an introduction to)

Parameters:

Pattern size:

empty [ property Empty ]

single character [ property NonEmpty ]

many character [ property NonEmpty ]

longer than any line in the file [ error ]

Quoting:

pattern is quoted [ property quoted ]

pattern is not quoted [ if NonEmpty ]

pattern is improperly quoted [ error ]

Embedded blanks:

no embedded blank [ if NonEmpty ]

one embedded blank [ if NonEmpty and Quoted ]

several embedded blanks [ if NonEmpty and Quoted ]

Page 39: Black box testing (an introduction to)

Embedded quotes:

no embedded quotes [ if NonEmpty ]

one embedded quotes [ if NonEmpty ]

several embedded quotes [ if NonEmpty ]

File name:

good file name

no file with this name [ error ]

Environments:

Number of occurrence of pattern in file:

Total Tests frames:

125

Total Tests frames:

40

[ single ]

Number of occurrence of pattern in file:

none [ if NonEmpty ]

exactly one [ if NonEmpty ] [ property Match]

more than one [ if NonEmpty ] [ property Match ]

Pattern occurrences on target line:

one [ if Match ]

more than one [ if Match ]

12540

[ single ]

[ single ]

Page 40: Black box testing (an introduction to)

• Use a constraint solver

• Choose specific values that satisfy the

constraints

Page 41: Black box testing (an introduction to)
Page 42: Black box testing (an introduction to)

A completely different approach:

→We cannot realistically presume to find and remove the last

failure.

→Then, we should invest test resources to find out the

“biggest” ones.

“Goodness” here means to minimise the user

perceived faults, i.e.

→Try to find earlier those bugs that are more frequently

encountered (neglect “small” bugs)

→Not suitable for safety critical applications

Page 43: Black box testing (an introduction to)

Identify:

• Typical usage scenario

• Frequency of those scenarios

Test more, more frequent scenariosTest more, more frequent scenarios

Page 44: Black box testing (an introduction to)