Testing in the Small (aka Unit Testing, Class Testing) 1209.

Testing in the Small (aka Unit Testing, Class Testing)

Unit Testing

• Focus on the smallest units of code: – Functions– Methods– Subroutines

• Frequently done (at least partially) during code development by code developers

• Often the target of testing frameworks such as JUnit

Each component is

• Tested in isolation from the rest of the system• Tested in a controlled environment

– Uses appropriately chosen input data

– Uses component-level design description as guide

During Unit Tests

• Data transformations across the module are tested• Data structures are tested to ensure data integrity

Unit Test Procedures

Driver

Module to be tested

Stub Stub

Results Testcases

Two fundamental approaches:

• Black box– Based on specification– Inner structure of test object is not considered

• White box– Based on specification– Inner structure of test object is the basis of test case

selection

• Effectiveness of black box is similar to white box, but the mistakes found are different. (Hetzel 1976, Myers 1978)

Black Box Unit Testing

What is black-box testing?

• Unit (code, module) seen as a black box

• No access to the internal or logical structure

• Determine if given input produces expected output.

Input Output

Black Box Testing

• Test set is derived from requirements • Goal is to cover the input space• Lots of approaches to describing input space:

– Equivalence Classes– Boundary Value Analysis– Decision Tables– State Transitions– Use Cases– . . .

Advantage and Disadvantage

• Advantage: it does not require access to the internal logic of a component

• Disadvantage: in most real-world applications, impossible to test all possible inputs

• Need to define an efficient strategy to limit number of test cases

General Black Box Process

• Analyze requirements

• Select valid and invalid inputs

• Determine expected outputs

• Construct tests

• Run tests

• Compare actual outputs to expected outputs

Equivalence classes: Basic Strategy

• Partition the input into equivalence classes– This is the tricky part– It’s an equivalence class if:

• Every test using one element of the class tests the same thing that any other element of the class tests

• If an error is found with one element, it should be found with any element

• If an error is not found with some element, it is not found by any element

• Test a subset from each class

Basic strategy:

Example: fact(n): if n<0, or n>=200 errorif 0<=n<=20, exact valueif 20<n<200, approximate value within .1%

What classes can you see?

Basic strategy:

Example: fact(n): if n<0, or n>=200 errorif 0<=n<=20, exact valueif 20<n<200, approximate value within .1%

Obvious classes are n<0, 0<=n<=20, 20<n<200, and 200<=n.

Might be some subclasses here, also, but this is a good start.

Simple Example:

• Suppose you are building an airline reservation system. A traveler can be a child, an adult, or a senior.

• The price depends on the type of traveler. • The seat reservation does not depend on the type

of traveler.• How many test cases can you identify for the

reservation component and the billing component?

Finding equivalence classes:

• Identify restrictions for inputs and outputs in the specification

• If there is a continuous numerical domain, create one valid and two or three invalid classes (above, below, and NaN)

• If a number of values is required, create one valid and two invalid classes (one invalid, two invalid)

• If a number of values is required, create one valid and two invalid classes

• If a set of values is specified where each may be treated differently, create a class for each element of the set and one more for elements outside the set

• If a number of values is required, create one valid and two invalid classes

• If a set of values is specified where each may be treated differently, create a class for each element of the set and one more for elements outside the set

• If there is a condition, create two classes, one satisfying and one not satisfying the condition

Boundary Values:

• Programs that fail at interior elements of a class usually fail at the boundaries too.

• Test the boundaries. – if it should work for 1-99, test 0, 1, 99, 100.– if it works for A-Z, try @, A, Z, [, a, and z

• The hard part is identifying boundaries

• If a domain is a restricted set, check the boundaries. e.g., D=[1,10], test 0, 1, 10, 11– It may be possible to test the boundaries of outputs,

also.• For ordered sets, check the first and last elements• For complex data structures, the empty list, full

lists, the zero array, and the null pointer should be tested

• Extremely large data sets should be tested• Check for off-by-one errors

More Hints

• Some boundaries are not obvious and may depend on the implementation (use gray box testing if needed)– Numeric limits (e.g., test 255 and 256 for 8-bit

values)– Implementation limits (e.g., max array size)

Boundary Value: in class

• Determine the boundary values for US Postal Service ZIP codes

• Determine the boundary values for a 15- character last name entry.

Decision Tables

• Construct a table (to help organize the testing)

• Identify each rule or condition in the system that depends on some input

• For each input to one of these rules, list the combinations of inputs and the expected results

Decision Table Example

Test Case C1

Student

Senior

Result

Discount?

1 T T T

2 T F T

3 F T T

4 F F F

Theater ticket prices are discounted for senior citizens and students.

Pairwise Testing

Problem 1From Lee Copeland, A Practitioner’s Guide to Software Test Design, Artech

House Publishers, 2004.

• A web site must operate correctly with different browsers: IE 5, IE 6, and IE 7; Mozilla 1.1; Opera 7; FireFox 2, 3, and 4, and Chrome.

• It must work using RealPlayer, MediaPlayer, or no plugin.• It needs to run under Windows ME, NT, 2000, XP, and

Vista, 7.0, and 8.0• It needs to accept pages from IIS, Apache and WebLogic

running on Windows NT, 2000, and Linux servers

• How many different configurations are there?

Problem 1

• A web site must operate correctly with different browsers: IE 5, IE 6, and IE 7; Mozilla 1.1; Opera 7; FireFox 2, 3, and 4, and Chrome.

• It must work using RealPlayer, MediaPlayer, or no plugin.• It needs to run under Windows ME, NT, 2000, XP, Vista,

7.0, and 8.0• It needs to accept pages from IIS, Apache and WebLogic

running on Windows NT, 2000, and Linux servers

• How many different configurations are there?• 9 browsers x 3 plugins x 7 OS x 3 web servers x 3 server

OSs = 1701 combinations

Problem 2

• A bank is ready to test a data processing system• Customer types

– Gold (i.e., normal)– Platinum (i.e., important)– Business– Non profits

• Account types– Checking– Savings– Mortgages – Consumer loans– Commercial loans

• States (with different rules): CA, NV, UT, ID, AZ, NM

• How many different configurations are there?

From Lee Copeland, A Practitioner’s Guide to Software Test Design, Artech House Publishers, 2004.

When given a large number of combinations: (options improve …)

• Give up and don’t test

• Give up and don’t test• Test all combinations … miss targets, delay

product launch, and go out of business

product launch, and go out of business• Choose one or two cases

product launch, and go out of business• Choose one or two cases• Choose a few that the programmers already ran

product launch, and go out of business• Choose one or two cases• Choose a few that the programmers already ran• Choose the tests that are easy to create

product launch, and go out of business• Choose one or two cases• Choose a few that the programmers already ran• Choose the tests that are easy to create• List all combinations and choose first few

product launch, and go out of business• Choose one or two cases• Choose a few that the programmers already ran• Choose the tests that are easy to create• List all combinations and choose first few• List all combinations and randomly choose some

product launch, and go out of business• Choose one or two cases• Choose a few that the programmers already ran• Choose the tests that are easy to create• List all combinations and choose first few• List all combinations and randomly choose some• “Magically” choose a small subset with high

probability of revealing defects

Orthogonal Arrays

• A 2-D array with the property– All pairwise combinations occur in every pair of

columns

• Example: consider 3 variables (columns) with {A,B}, {1,2}, and (α,β)

1 1 A α

2 1 B β

3 2 A β

4 2 B α

Orthogonal Array Example

1 1 A α

2 1 B β

3 2 A β

4 2 B α

Look at each pair of columns (1 and 2),( 1 and 3), and (2 and 3)

Does each of the 4 pairings appear in each?

(Yes, of course!)

Pairwise Testing Algorithm

1. Identify variables

2. Determine choices for each variable

3. Locate an orthogonal array

4. Map test cases to the orthogonal array

5. Construct tests

Example using Bank

1. Identify variables1. Customers (4)2. Account types (5)3. States (6)

2. Determine choices for each variable1. Customer types (Gold, Platinum, Business, Non Profit)2. Account types (Checking, Savings, Mortgages, Consumer loans,

Commercial loans3. States (CA, NV, UT, ID, AZ, NM)

3. Locate an orthogonal array 4. Map test cases to the orthogonal array5. Construct tests

Locate an orthogonal array (look up on web)

Map Test Cases (30)CA Check Gold

CA Save Plat

CA Mort Busi

CA Cons NonP

NV Check Plat

NV Save Gold

NV Mort NonP

NV Cons Busi

UT Check Busi

UT Save NonP

UT Mort Gold

UT Cons Plat

ID Check NonP

ID Save Busi

ID Mort Plat

ID Cons Gold

AZ Comm Gold

AZ Check Plat

AZ Save Busi

AZ Mort NonP

NM Comm Plat

NM Check Gold

NM Save NonP

NM Mort Busi

CA Comm Busi

NV Comm NonP

UT Comm Gold

ID Comm Plat

AZ Cons Gold

NM Cons Plat

Pairwise Summary• When the combination is large, test all pairs,

not all combinations

• Studies indicate that most defects are single or double-mode effects – Can be found in pairing– Few defects require more than two modes

• Orthogonal arrays have the pairwise property and can be found or generated

State Transition Testing

• Build STD of system or component• Cover the STD

– Visit each state– Trigger each event– Exercises each transition– Exercise each path*

* Might not be possible

Example

Res MadePaid

CancelledNon Pay

Ticketed

CancelledCust

Cust Order/start timer

Payment madeTicket Printed

Time Expires

Ticket DeliveredCancel/refund

Cancel/refund

Cancel

Customer makes reservation and haslimited time to pay. May cancel at anytime.

Groups: How many tests to visit each state?

Example: Each State

Res MadePaid

CancelledNon Pay

Ticketed

CancelledCust

Time Expires

Cancel/refund

Cancel

3 tests needed: From start to final From start to cancelled non-pay From start to Res Made to Cancelled Cust

Example: Each Event

Res MadePaid

CancelledNon Pay

Ticketed

CancelledCust

Time Expires

Cancel/refund

Cancel

3 tests needed: From start to final From start to cancelled non-pay From start to Res Made to Cancelled Cust

Example: Each Transition

Res MadePaid

CancelledNon Pay

Ticketed

CancelledCust

Time Expires

Cancel/refund

Cancel

5 tests needed

Use Case Testing

• Use the use cases to specify test cases

• Use case specifies both normal, alternate, and exceptional operations

• Use cases may not have sufficient detail– Beizer estimates that 30-40% of effort in testing

transactions is generating the test data– Budget for this!

White-Box Testing

Pfleeger, S. Software Engineering Theory and Practice 2nd Edition. Prentice Hall, 2001.Ghezzi, C. et al., Fundamentals of Software Engineering. Prentice Hall, 2002.Pressman, R., Software Engineering A Practitioner’s Approach, Mc Graw Hill, 2005.Hutchinson, Marnie, Software Testing Fundamentals, Wiley, 2003.

White Box Testing

• Also known as: – Glass box testing– Structural testing

• Test set is derived from structure of code • Code structure represented as a Control Flow Graph• Goal is to cover the CFG

Control Flow Graphs• Programs are made of three kinds of statements:

– Sequence (i.e., series of statements)

– Condition (i.e., if statement)

– Iteration (i.e., while, for, repeat statements)

Control Flow Graphs• Programs are made of three kinds of statements:

– Sequence (i.e., series of statements)

– Condition (i.e., if statement)

– Iteration (i.e., while, for, repeat statements)

• CFG: visual representation of flow of control.– Node represents a sequence of statements with single entry

and single exit

– Edge represents transfer of control from one node to another

Control Flow Graph (CFG)

Sequence If-then-else If-then Iterative

Control Flow Graph (CFG)

Sequence If-then-else If-then Iterative

When drawing CFG, ensure that there is one exit: include the join node if needed

Example 1: CFG

1. read (result);2. read (x,k)3. while result < 0 then {4. ptr false5. if x > k then6. ptr true7. x x + 18. result result + 1 }9. print result

Draw CFG

Example 1: CFG

In Class: Write CFGsExample 2

1. if (a < b) then 2. while(a < n)3. a a + 1;4. else 5. while(b < n)6. b b + 1;

Example 3

1. read (a,b); 2. if (a 0 && b 0) then {3. c a + b;4. if c > 10 then 5. c max6. else c min }7. else print ‘Done’

Example 4

1. read (a,b); 2. if (a 0 || b 0) then {3. c a + b4. while( c < 100)5. c a + b; }6. c a * b

Write a CFG

Example 2

1. if (a < b) then 2. while (a < n)3. a a + 1;4. else 5. while (b < n)6. b b + 1;

Answers

Example 3

1. read (a,b); 2. if (a 0 && b 0) then {3. c a + b;4. if c > 10 then 5. c max6. else c min }7. else print ‘Done’

Answers

Example 4

1. read (a,b); 2. if (a 0 || b 0) then {3. c a + b4. while( c < 100)5. c a + b; }6. c a * b

Coverage

• Statement

• Branch

• Condition

• Path

• Def-use

• Others

Statement Coverage

• Every statement gets executed at least once

• Every node in the CFG gets visited at least once

Examples: number of paths needed

for Statement Coverage? (from Hutchinson, Software Testing Fundamentals, Wiley, 2003)

Branch coverage

• Every decision is made true and false• Every edge in a CFG of the program gets

traversed at least once• Also known as

– Decision coverage– All edge coverage– Basis path coverage

• Branch is finer than statement• C1 is finer than C2 if

T1C1 T2C2 T2 T1

for Branch Coverage? (from Hutchinson, Software Testing Fundamentals, Wiley, 2003)

Condition coverage

• Every complex condition is made true and false by every possible combination– E.G., (x and y)

• x = true, y = true• x=false, y=true• x = true, y= false• x =false, y = false

• There are lots of different types of condition coverage: Condition, multiple condition, condition/decision, modified condition/decision (MCDC), …I’m only covering the simplest.

• Condition coverage is not finer than branch coverage – There are pathological cases where you can achieve Condition and not

Branch– Under most circumstances, achieving Condition achieves Branch

Condition Coverage: CFGs• One way to determine the number of paths is to break the compound

conditional into atomic conditionals• Suppose you were writing the CFG for the assembly language

implementation of the control construct If (A AND B) then

CEndif

(short circuit eval) (no short circuit eval) LD A LD A ; in general, lots of BZ :endif LAND B ; code for A and

B LD B BZ :endif BZ :endif JSR C JSR C :endif nop:endif nop

AND Condition

1. read (a,b); 2. if (a == 0 && b == 0) then {3. c a + b }4. else c a * b

paths:1, 2A,2B,3, J1, 2A, 2B, 4, J1, 2A, 4, J

OR Condition

1. read (a,b); 2. if (a == 0 || b == 0) then }3. c a + b;4. while( c < 100)5. c a + b;}

Paths:1, 2A, 3, 4, 5, 4 … J1, 2A, 3, 4, J1, 2A, 2B, 3, 4, 5, 4, … J1,2A, 2B, J

• A path is a sequence of statements

• A path is sequence of branches

• A path is a sequence of edges

for Path Coverage? (from Hutchinson, Software Testing Fundamentals, Wiley, 2003)

Path Coverage-1• Every distinct path through code

is executed at least once

• Example1. read (x)2. read (z)3. if x 0 then begin4. y x * z;5. x z end6. else print ‘Invalid’ 7. if y > 1 then8. print y9. else print ‘Invalid’

• Test Paths:1, 2, 3, 4, 5, J1, 7, 8, J21, 2, 3, 4, 5, J1, 7, 9, J21, 2, 3, 6, J1, 7, 8, J2,1, 2, 3, 6, J1, 7, 9, J2

Counting Paths

• It is not feasible to calculate the total number of paths

Linearly independent paths

• It is feasible to calculate the number of linearly independent paths

• The number of linearly independent paths is the number of end-to-end paths required to touch every path segment at least once

• A linearly independent path introduces at least one new set of process statements or a new condition

Cyclomatic Complexity• Software metric for the logical complexity of a

program.• Defines the number of independent paths in the

basis set of a program• Provides the upper bound for the number of tests

that must be conducted to ensure that all statements been have executed at least once

• For Edges (E) and Nodes (N) V(G) = E – N + 2

Examples: Complexity of CFGs

N=3E=2E-N+2= 2-3+2= 1=V(G)

N=1E=0E-N+2= 0-1+2= 1=V(G)

N=4E=4E-N+2= 4-4+2= 2=V(G)

N=3E=3E-N+2= 3-3+2= 2=V(G)

Example1

V(G) = 11 – 9 + 2 = 4

Independent paths:1-111-2-3-4-5-10-1-111-2-3-6-8-9-10-1…-111-2-3-6-7-9-10-1…-11

In Class: Compute the cyclomatic complexity

Example 1: CFG

1,2N=7E=8E-N+2= 8-7+2= 3=V(G)

Example 21

N=6E=8E-N+2= 8-6+2= 4=V(G)

Answers

N=7E=8E-N+2= 8-7+2= 3=V(G)

Answers

N=6E=7E-N+2= 7-6+2= 3=V(G)

Independent Path Coverage• Basis set does not yield minimal

test set• Example

1. read (x)2. read (z)3. if x 0 then begin4. y x * z;5. x z end6. else print ‘Invalid’ 7. if y > 1 then8. print y9. else print ‘Invalid’

• Cyclomatic complexity: 3• Test Paths:

1, 2, 3, 4, 5, J1, 7, 8, J21, 2, 3, 4, 5, J1, 7, 9, J21, 2, 3, 6, J1, 7, 8, J2,

Def-Use Coverage• Def-use coverage: every path

from every definition of every variable to every use of that definition is exercised in some test.

• Example1. read (x)2. read (z)3. if x 0 then begin4. y x * z;5. x z end6. else print ‘Invalid’ 7. if y > 1 then8. print y9. else print ‘Invalid’

Def: x, zUse: x

Def: y, xUse: x, z

Use: none

Use: y

Use: yUse: none

Test Path: 1, 2, 3, 4, 5, 7, 8, J

Strength of Coverage

Statement

Branch

Def-Use

Arrows point from weaker to stronger coverage.

Stronger coverage requires more test cases.

Condition

What paths don’t tell you

• Timing errors

• Unanticipated error conditions

• User interface inconsistency (or anything else)

• Configuration errors

• Capacity errors

Testing in the Small (aka Unit Testing, Class Testing) 1209.

invalid classes

blackbox testing

gfinding equivalence

nanfinding equivalence

black box unit testing1209what

black boxbased

unit code

outputsequivalence classes

Documents

Marlton - 1209.pdf

marketing 1209

Drug Testing: Processes & Good...

financenet 1209

Μίκυ μάους 1209

PHA FacilitiesBrochure 1209

130822 pubmtg3 1209

Week 1209 Westerkrant

Moorestown - 1209.pdf

Folha Extra 1209

1209-FLYER-F9-FINAL€¦ · Title: 1209-FLYER-F9-FINAL...

retail 1209

Condominio 1209

The unknown spice girl. Aka NineCollective Jasmine Testing.

1209 Master Sistemics

eastarjet 1209