0% found this document useful (0 votes)
17K views

Week 11

Here are the test cases I would generate from the decision table: TC1: Flight less than half full, ticket cost < Rs. 3000, international flight. Expected output: No meals served TC2: Flight less than half full, ticket cost > Rs. 3000, international flight. Expected output: No meals served TC3: Flight less than half full, ticket cost < Rs. 3000, domestic flight. Expected output: Meals charged TC4: Flight less than half full, ticket cost > Rs. 3000, domestic flight. Expected output: Meals charged TC5: Flight more than half full, ticket cost < Rs. 3000, international flight. Expected output: No meals served

Uploaded by

Saikat Mondal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17K views

Week 11

Here are the test cases I would generate from the decision table: TC1: Flight less than half full, ticket cost < Rs. 3000, international flight. Expected output: No meals served TC2: Flight less than half full, ticket cost > Rs. 3000, international flight. Expected output: No meals served TC3: Flight less than half full, ticket cost < Rs. 3000, domestic flight. Expected output: Meals charged TC4: Flight less than half full, ticket cost > Rs. 3000, domestic flight. Expected output: Meals charged TC5: Flight more than half full, ticket cost < Rs. 3000, international flight. Expected output: No meals served

Uploaded by

Saikat Mondal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 77

Combinatorial

Testing

03/08/10 1
1
Combinatorial Testing: Motivation
• The behavior of a program may be affected by many factors:
– Input parameters, Combinatorial: Relating to,
or involving combinations
– Environment configurations (global variables),
– State variables. ..
• Equivalence partitioning of an input variable:
– Identify the possible types of input values requiring different
processing.
• If the factors are many:
– It is impractical to test all possible combinations of values of all factors.

2
Combinatorial Testing: Motivation
• Many times, the specific action to be performed depends
on the value of a set of Boolean variable:
– Controller applications
– User interfaces

3
Combinatorial Testing
• Several combinatorial testing strategies exist:
– Decision table-based testing

– Cause-effect graphing

– Pair-wise testing (reduced number of test cases)

4
• Applicable to requirements involving conditional actions.
• This is represented as a decision table: Decision table-
–Conditions = inputs based Testing
–Actions = outputs (DTT)
–Rules =test cases Condition1
Rule1
Yes
Rule2
Yes
Rule3
No
Rule4
No

• Assume independence of inputs Condition2


Condition3
Yes
No
X
Yes
No
No
X
X

• Example Condition4
Action1
No
Yes
Yes
Yes
No
No
Yes
No

–If c1 AND c2 OR c3 then A1 Action2


Action3
No
No
No
No
Yes
No
No
Yes

5
Combinations

Rule1 Rule2 Rule3 Rule4


Condition1 Yes Yes No No

Condition2 Yes X No X
Conditions
Condition3 No Yes No X

Condition4 No Yes No Yes

Action1 Yes Yes No No

Actions Action2 No No Yes No

Action3 No No No Yes

6
• A decision table consists of a number of columns r1 r2 … rn
(rules) that comprise all test situations C1 0 1 0
• Example: the triangle problem
c2 - 1 0
– C1: a, b,c form a triangle
– C2: a=b C3 - 1 1

– C3: a= c C4 - 1 0
– C4: b= c a1 1 0 0
– A1: Not a triangle
– A2:scalene
Sample a2 0 0 1

– A3: Isosceles Decision a3 0 0 0

– A4:equilateral table a4 0 1 0
– A5: Right angled a5 0 0

7
Test cases from Decision Tables
C1: a, b,c form
Test Case
ID a b c Expected
output a triangle
C2: a=b
TC1 4 1 2 Not a
Triangle
C3: a= c
C4: b= c
TC2 2888 2888 2888 Equilateral
TC3 ? | ) Impossible
TC4

TC11

8
Conditions
C1: a < b+c? F T T T T T T T T T T
C2: b < a+c? - F T T T T T T T T T
C3: c < a+b? - - F T T T T T T T T
C4: a=b? - - - T T T T F F F F
More Complete C5: a=c? - - - T T F F T T F F
Decision Table C6: b-c? - - - T F T F T F T F
for the Triangle Actions

Problem A1: Not a Triangle X X X


A2: Scalene X
A3: Isosceles X X X
A4: Equilateral X
A5: Impossible X X X

9
Case ID a b c Expected
Output
DT1 4 1 2 Not a
Triangle
DT2 1 4 2 Not a
Test Cases for Triangle
the Triangle DT3 1 2 4 Not a
Triangle
Problem
DT4 5 5 5 Equilateral

DT5 ? ? ? Impossible

DT6 ? ? ? Impossible

DT7 2 2 3 Isosceles

DT8 ? ? ? Impossible

DT9 2 3 2 Isosceles

DT10 3 2 2 Isosceles

DT11 3 4 5 Scalene 10
Printer does not print Y Y Y Y N N N N
Decision Table
Conditions A red light is flashing
– Example 2 Y Y N N Y Y N N

Printer is unrecognized Y N Y N Y N Y N

Check the power cable X

Check the printer-computer cable


X X
Printer Actions
Troubleshooting Ensure printer software is installed
X X X X

Check/replace ink X X X X

Check for paper jam X X

11
Quiz: Develop BB Test Cases
• Policy for charging customers for certain in-flight services:

If the flight is more than half-full and ticket cost is more than
Rs. 3000, free meals are served unless it is a domestic flight.
Otherwise, no meals are served. Meals are charged on all
domestic flights.

12
Fill all POSSIBLE COMBINATIONS
combinations more than half-
N N N N Y Y Y Y
in the table. full

CONDITONS
more than
Rs.3000 per N N Y Y N N Y Y
seat

domestic flight N Y N Y N Y N Y
ACTIONS

13
POSSIBLE COMBINATIONS
Analyze
column by more than half-full N N N N Y Y Y Y
column to
determine

CONDITONS
which actions more than Rs. 3000
N N Y Y N N Y Y
per seat
are appropriate
for each
combination domestic flight N Y N Y N Y N Y

Y Y Y Y
ACTIONS

serve meals

free Y
14
POSSIBLE COMBINATIONS
Reduce the more than half-full N N N N Y Y Y Y
table by

CONDITONS
eliminating more than Rs. 3000
N N Y Y N N Y Y
redundant per seat
columns.
domestic flight N Y N Y N Y N Y
ACTIONS

serve meals X X X X

free X

15
Final Combinations
solution more than half-full N Y Y Y

CONDITONS
more than 3000 per seat - N Y Y

ACTIONS domestic flight - - N Y

serve meals X X X

free X

16
–Rules need to be complete:
Assumptions •That is, every combination of decision table
regarding
values including default combinations are
rules
present.
–Rules need to be consistent:
•That is, there is no two different actions for the
same combinations of conditions

17
Guidelines and Observations
• Decision table testing is appropriate for programs:
– There is a lot of decision making
– Output is a logical relationship among input variables
– Results depend on calculations involving subsets of inputs
– There are cause and effect relationships between input and
output

• Decision tables do not scale up very well


18
Quiz: Design test Cases
• Customers on a e-commerce site get following
discount:
– A member gets 10% discount for purchases lower than
Rs. 2000, else 15% discount
– Purchase using SBI card fetches 5% discount
– If the purchase amount after all discounts exceeds Rs.
2000/- then shipping is free.
19
Cause-effect Graphs
• Overview:
–Explores combinations of possible inputs
–Specific combination of inputs (causes) results in outputs
(effects)
–Represented as nodes of a cause effect graph
–The graph also includes constraints and a number of
intermediate nodes linking causes and effects
20
• If depositing less than Rs. 1 Lakh, rate of interest:
– 6% for deposit upto 1 year Cause-Effect
– 7% for deposit over 1 year but less than 3 yrs Graph
– 8% for deposit 3 years and above Example

• If depositing more than Rs. 1 Lakh, rate of interest:


– 7% for deposit upto 1 year
– 8% for deposit over 1 year but less than 3 yrs
– 9% for deposit 3 years and above

21
Cause-Effect Graph Example
Causes Effects
C1: Deposit<1yr e1: Rate 6%

C2: 1yr<Deposit<3yrs e2: Rate 7%

C3: Deposit>3yrs e3: Rate 8%

C4:Deposit <1 Lakh e4: Rate 9%

C5: Deposit >=1Lakh

22
c4 e10 e1

c5 e2
e20
Cause-Effect
c1 e30 e3 Graphing
c2 e40
e4
c3 e50

e60
23
Develop a Decision Table
C1 C2 C3 C4 C5 e1 e2 e3 e4
1 0 0 1 0 1 0 0 0
1 0 0 0 1 0 1 0 0
0 1 0 1 0 0 1 0 0
0 1 0 0 1 1 0 1 0
• Convert each row to a test case

24
Pair-wise Testing

03/08/10 25
25
Combinatorial Testing of User
Interface

0 = effect off
1 = effect on

210 = 1,024 tests for all combinations


* 10 3 = 1024 * 1000 …. Just too many to tests

26
26
Combinatorial Testing Problem
X1 X2 X3 . . . Xn

System S

•Combinatorial testing problems generally follow a simple input-process-


output model;
•The “state” of the system is not the focus of combinatorial testing.

27
27
• Instead of testing all possible combinations:
– A subset of combinations is generated. t-way Testing
• Key observation:
– It is often the case that a fault is caused by interactions among a
few factors.
• t-way testing can dramatically reduce the number of test
cases:
– but remains effective in terms of fault detection.
28
28
t-way Interaction Testing
Interest Rate | Amount | Months | Down Pmt | Pmt Frequency

All combinations: etc. . .


every value of
every parameters
.
All pairs: every
value of each
pair of
parameters

t-way interactions:
every value of every t-
way combination of
parameters

29
Pairwise Testing
Pressure | Temperature | Velocity | Acceleration | Air Density

Α Τ1 1 10 1.1
Β Τ2 2 0 2.1
Τ3 3 20 3.1
Pressure Temperature 4 0
5
A T1 6
A T2
A T3
B T1
B T2
B T3

10/3/2018 30
Pairwise Reductions
Number of Number of Number of Size of pair
inputs selected test combinations wise test
data values set

7 2 128 8

13 3 1.6 x 106 15

40 3 1.2 x 1019 21

31 31
• A t-way interaction fault: Fault-Model

–Triggered by a certain combination of t input values.

– A simple fault is a 1-way fault

– Pairwise fault is a t-way fault where t = 2.

• In practice, a majority of software faults consist of simple


and pairwise faults.

32
Single-mode Bugs
• The simplest bugs are single-mode faults:
–Occur when one option causes a problem regardless of
the other settings

–Example: A printout is always gets smeared when you


choose the duplex option in the print dialog box
• Regardless of the printer or the other selected options

33
Double-mode Faults
• Double-mode faults
–Occurs when two options are combined
–Example: The printout is smeared only when duplex is
selected and the printer selected is model 394

34
34
Multi-mode Faults
• Multi-mode faults
–Occur when three or more settings produce the bug

–This is the type of problems that make complete coverage


necessary

35
• begin
– int x, y, z;
Example of Pairwise Fault
– input (x, y, z);
– if (x == x1 and y == y2)
• output (f(x, y, z));

– else if (x == x2 and y == y1)


• output (g(x, y));

– Else // Missing (x == x2 and y == y1) f(x, y, z) – g(x, y);


• output (f(x, y, z) + g(x, y))

• end
• Expected: x = x1 and y = y1 => f(x, y, z) – g(x, y);
x = x2, y = y2 => f(x, y, z) + g(x, y)

36
36
HARDKEYBOARDHIDDEN_NO ORIENTATION_LANDSCAPE
Example: HARDKEYBOARDHIDDEN_UNDEFINED
HARDKEYBOARDHIDDEN_YES
ORIENTATION_PORTRAIT
ORIENTATION_SQUARE

Android smart KEYBOARDHIDDEN_NO


ORIENTATION_UNDEFINED

KEYBOARDHIDDEN_UNDEFINED
phone testing KEYBOARDHIDDEN_YES
SCREENLAYOUT_LONG_MASK
SCREENLAYOUT_LONG_NO
SCREENLAYOUT_LONG_UNDEFINED
• Apps should work on all KEYBOARD_12KEY
combinations of platform options, KEYBOARD_NOKEYS
SCREENLAYOUT_LONG_YES
but there are 3 x 3 x 4 x 3 x 5 x 4 x KEYBOARD_QWERTY
KEYBOARD_UNDEFINED
4 x 5 x 4 = 172,800 configurations SCREENLAYOUT_SIZE_LARGE
NAVIGATIONHIDDEN_NO SCREENLAYOUT_SIZE_MASK
NAVIGATIONHIDDEN_UNDEFINED SCREENLAYOUT_SIZE_NORMAL

NAVIGATIONHIDDEN_YES SCREENLAYOUT_SIZE_SMALL
SCREENLAYOUT_SIZE_UNDEFINED
NAVIGATION_DPAD
NAVIGATION_NONAV TOUCHSCREEN_FINGER
NAVIGATION_TRACKBALL TOUCHSCREEN_NOTOUCH
NAVIGATION_UNDEFINED TOUCHSCREEN_STYLUS
NAVIGATION_WHEEL TOUCHSCREEN_UNDEFINED

37
White-Box Testing

03/08/10 38
What is White-box Testing?
• White-box test cases designed based on:

–Code structure of program.

–White-box testing is also called structural testing.


White-Box Testing Strategies
• Coverage-based:
– Design test cases to cover certain program elements.

• Fault-based:
– Design test cases to expose some category of faults
• Several white-box testing strategies have become very popular :
– Statement coverage
– Branch coverage
– Path coverage White-Box Testing
– Condition coverage
– MC/DC coverage
– Mutation testing
– Data flow-based testing
Why Both BB and WB Testing?
Black-box White-box
• Impossible to write a test case • Does not address the question
for every possible set of inputs of whether a program matches
and outputs the specification
• Some code parts may not be
reachable • Does not tell if all functionalities
have been implemented
• Does not tell if extra
functionality has been • Does not uncover any missing
implemented. program logic
Coverage-Based Testing Versus Fault-Based Testing
• Idea behind coverage-based testing:
– Design test cases so that certain program elements are executed
(or covered).
– Example: statement coverage, path coverage, etc.
• Idea behind fault-based testing:
– Design test cases that focus on discovering certain types of
faults.
– Example: Mutation testing.
• Statement: each statement executed at least once
• Branch: each branch traversed (and every entry point
taken) at least once
• Condition: each condition True at least once and False at
least once
• Multiple Condition: All combination of Condition covered
• Path:
Types of program element Coverage
• Dependency:
Stronger and
Coverage Weaker Testing

Stronger
Weaker
Complementary Testing

Coverage
Strategy
1 Strategy
2
Stronger, Weaker, and Complementary Testing

Complementary

Weaker
Statement Coverage
• Statement coverage strategy:

–Design test cases so that every statement in the


program is executed at least once.
Statement Coverage
• The principal idea:
–Unless a statement is executed,

–We have no way of knowing if an error exists in


that statement.
Statement Coverage Criterion
• However, observing that a statement behaves properly
for one input value:

–No guarantee that it will behave correctly for all input


values!
Statement Coverage
• Coverage measurement:
# executed statements
# statements

• Rationale: a fault in a statement can only be


revealed by executing the faulty statement
• int f1(int x, int y){ Example
• 1 while (x != y){
• 2 if (x>y) then
•3 x=x-y;
• 4 else y=y-x;
• 5}
• 6 return x; }
int f1(int x,int y){
Example
1 while (x != y){
2 if (x>y) then
3 x=x-y;
4 else y=y-x;
5 }
6 return x; }
Euclid's GCD Algorithm

• By choosing the test set {(x=3,y=3),(x=4,y=3),


(x=3,y=4)}

–All statements are executed at least once.


Branch Coverage
• Also called decision coverage.
• Test cases are designed such that:

–Each branch condition


•Assumes true as well as false value.
int f1(int x,int y){
Example
1 while (x != y){
2 if (x>y) then
3 x=x-y;
4 else y=y-x;
5 }
6 return x; }
Example
• Test cases for branch coverage can be:

• {(x=3,y=3),(x=3,y=2), (x=4,y=3), (x=3,y=4)}


Branch Testing
• Adequacy criterion: Each branch (edge in the CFG)
must be executed at least once
• Coverage:
# executed branches
# branches
Quiz 1: Branch and Statement Coverage:
Which is Stronger?
• Branch testing guarantees statement
coverage:

–A stronger testing compared to the statement


coverage-based testing.
Stronger Testing
• Stronger testing:
–Superset of weaker testing
–A stronger testing covers all the elements covered by a
weaker testing.
–Covers some additional elements not covered by
weaker testing
Sample
Coverage
Report
Statements vs Branch Testing
• Traversing all edges of a graph causes all nodes to be visited

– So a test suite that satisfies branch adequacy criterion also satisfies


statement adequacy criterion for the same program.

• The converse is not true:

– A statement-adequate (or node-adequate) test suite may not be branch-


adequate (edge-adequate).
– Statement coverage
– Branch coverage (aka decision coverage) White-box
– Basic condition coverage Testing
– Condition/Decision coverage
– Multiple condition coverage
– MC/DC coverage
– Path coverage
– Data flow-based testing
– Mutation testing

64
All Branches can still miss testing specific conditions
• Assume failure occurs when c==DIGIT

if((c == ALPHABET) || (c ==DIGIT))

• Branch adequacy criterion can be satisfied by c==alphabet and


c==splchar

– The faulty sub-expression might not be tested!

– Even though we test both outcomes of the branch


Basic Condition Coverage
• Also called condition coverage or simple condition
coverage .

• Test case design: ((c == ALPHABET) || (c== DIGIT))

–Each component of a composite conditional expression


• Made to assume both true and false values.
Basic Condition Testing
• Simple or (basic) Condition Testing:
– Test cases make each atomic condition assume T and F values
– Example: if (a>10 && b<50)
• Following test inputs would achieve basic condition coverage
– a=15, b=30
– a=5, b=60
• Does basic condition coverage subsume decision coverage?
Example: BCC
• Consider the conditional expression
–((c1.and.c2).or.c3):

• Each of c1, c2, and c3 is exercised with all possible


values,
–That is, given true and false values.
Basic condition testing
• Adequacy criterion: each basic condition must be
executed at least once
• Coverage:
# truth values taken by all basic conditions
2 * # basic conditions
Is BCC Stronger than Decision Coverage?
• Consider the conditional statement:
–If(((a>5).and.(b<3)).or.(c==0)) a=10;

• Two test cases can achieve basic condition coverage: (a=10,


b=2, c=2) and (a=1, b=10, c=0)

• BCC does not imply Decision coverage and vice versa


Condition/Decision Coverage Testing
• Condition/decision coverage:
– Each atomic condition made to assume both T and F values
– Decisions are also made to get T an F values

• Multiple condition coverage (MCC):


– Atomic conditions made to assume all possible combinations of
truth values
MCC
• Test cases make Conditions to assume all possible
combinations of truth values.
• Consider: if (a || b && c) then …
Test a b c
(1) T T T
(2) T T F Exponential in the
(3) T F T
(4) T F F number of basic
(5) F T T
(6)
(7)
T
F
T
F
F
T
conditions
(8) F F F
Multiple Condition Coverage (MCC)
• Consider a Boolean expression having n
components:
–For condition coverage we require 2n test cases.
• MCC testing technique:
–Practical only if n (the number of component conditions)
is small.
MCC for Compound conditions: Exponential complexity
(((a || b) && c) || d) && e

Test a b c d e 25=32
Case
(1) T — T — T
(2) F T T — T •Short-circuit
(3) T — F T T
(4) F T F T T evaluation often
(5) F F — T T
(6) T — T — F reduces number of
(7) F T T — F
(8) T — F T F test cases to a more
(9)
(10)
F
F
T
F
F

T
T
F
F manageable
(11)
(12)
T
F

T
F
F
F
F


number, but not
(13) F F — F — always…
Subsumption
Multiple Condition
• Condition testing:
–Stronger testing than branch Condition/Decision

testing.
Decision
• Branch testing:
–Stronger than statement
Basic Condition Statement
coverage testing.
Shortcomings of Condition Testing
• Redundancy of test cases: Condition evaluation could be
compiler-dependent:
– Reason: Short circuit evaluation of conditions
• Coverage may be Unachievable: Possible dependencies
among variables:
– Example: ((chr==`A ́)||(chr==`E ́)) can not both be true at the
same time
Short-circuit Evaluation
• if(a>30 && b<50)…

– If a>30 is FALSE compiler need not evaluate (b<50)

• Similarly, if(a>30 || b<50)…

– If a>30 is TRUE compiler need not evaluate (b<50)

You might also like